Subject: Re: IPv6

From: Alan DeKok <[email-masked]>
Date: Mon, 05 Oct 2009 17:02:30 +0200

Bernard Aboba wrote:
> How about this?
...
>    For these reasons, the tagging scheme described in RFC 2868 is
>    not suitable for use as a generic grouping mechanism.  Where
>    a tagging scheme is required for use with arbitrary data types,
>    it is RECOMMENDED that:
>       
>         * A fixed tagging field be used so as to remove potential
>           interoperability issues associated with determining whether
>           an optional tag is present; 
> 
>         * The design make no assumption about the content of the
>           data within tagged attributes."  

  Hmm... OK.  This sounds an awful lot like making recommendations on
later RADEXT documents.  I'm not sure that's useful.

  The alternative is to interpret this as recommending a new data type:
tagged attributes with a format defined outside of RADEXT.  I'm not sure
I like that much better.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 5 Oct 2009 10:50:46 -0700

> later RADEXT documents.  I'm not sure that's useful.

Assuming that the first sentence makes sense, the next question that
a reader will ask is "What is the alternative?"  

> tagged attributes with a format defined outside of RADEXT.  I'm not sure

Given that existing tagged types are not suitable for generic use,  there
doesn't seem to be an alternative to a new data type.  The question is
what this document can or should say about that. 

While the Extended Attributes document is probably the right place to
deal with this issue in depth, the question is whether something can
be said in the Design Guidelines document, and if so, what.

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 5 Oct 2009 17:59:49 -0400

> be said in the Design Guidelines document, and if so, what.

This sounds like we're coming full circle.  I think where we started  
was with the Design Guidelines for "RADIUS Classic" directing  
developers who wanted to make effective use tagging to the Extended  
RADIUS Attributes draft / RFC.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 06 Oct 2009 00:35:02 +0200

> what this document can or should say about that.

  I agree with David.  It should stick to recommended practices, and not
define new standards.

> be said in the Design Guidelines document, and if so, what.

  It should say what's bad about the current tags, and leave it to later
documents to decide how to fix them.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 5 Oct 2009 18:18:45 -0700

> documents to decide how to fix them.

One approach might be to say just that:

"For these reasons, the tagging scheme described in RFC 2868 is
not suitable for use as a generic grouping mechanism.   Further
guidance in this area is left to future documents."

---

From: Alan DeKok <[email-masked]>
Date: Tue, 06 Oct 2009 16:22:18 +0200

> guidance in this area is left to future documents."

  Sounds good to me.  I'll see if I can rev the document this week.

  Alan DeKok.

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 6 Oct 2009 10:42:51 -0400

> guidance in this area is left to future documents."

All of this dancing around, simply to avoid a non-normative reference  
to the RADIUS Extended Attributes document?  Why?

---

From: Alan DeKok <[email-masked]>
Date: Tue, 06 Oct 2009 16:54:28 +0200

David B. Nelson wrote:
> All of this dancing around, simply to avoid a non-normative reference to
> the RADIUS Extended Attributes document?  Why?

  It doesn't matter too much to me.  But I don't see a need to reference
future documents, when those documents can simply state that they update
this one.

  Alan DeKok.

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 6 Oct 2009 10:59:17 -0400

On Oct 6, 2009, at 10:54 AM, Alan DeKok wrote:

 > ...I don't see a need to reference future documents, when those
 >  documents can simply state that they update this one.

True.  OTOH, I don't see any need to be coy about "future documents"  
when we know exactly what document we're talking about and exactly  
what it recommends.  Often the best approach is the most  
straightforward approach.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 6 Oct 2009 08:31:21 -0700

> straightforward approach.

Do we know exactly which document we're talking about?  Both the
IPv6 document and Extended Attributes define tagging schemes.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 6 Oct 2009 18:54:46 +0200

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bernard Aboba
	Sent: 06 October 2009 17:31
	To: David B. Nelson; Alan DeKok
	Cc: [email-masked]
	Subject: RE: IPv6

	 
	Woj> Indeed... What's the IPv6 document being referred to here?
If it happens to be draft-lourdelet-radext-ipv6-access, then it does not
define any new tagging scheme.

	- Woj.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 06 Oct 2009 21:47:07 +0200

Wojciech Dec (wdec) wrote:
>     Woj> Indeed... What's the IPv6 document being referred to here? If
>     it happens to be draft-lourdelet-radext-ipv6-access, then it does
>     not define any new tagging scheme.

  Uh... have you compared it to RFC 2868?

3.3 IPv6-Prefix

  Defines an IPv6 prefix with a tag.  There are NO existing tagged IPv6
attributes.  RFC 2868 defines tagged integers and strings *only*.  This
data type is new.

3.5 IPv6-Route-Option-Lifetime

  Defines an 8-bit tag, followed by a 32-bit integer.  RFC 2868 defines
a 32-bit integer where the 8-bit tag over-writes the highest 8 bit of
the integer.  This data type is new.

  3.6 and 3.7 have the same issue.

3.8.  Auth-IPv6-Prefix-User-ID

  Defines an 8-bit tag followed by a 64-bit integer.  There are NO
existing attributes that are tagged 64-bit integers.  This data type is new.

  This draft defines a number of new tagged data types which are not
previously used in any RFC, or on any vendor equipment, or in any
specification from another standards body.

  Alan DeKok.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 6 Oct 2009 23:14:11 +0200

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]] 
> Sent: 06 October 2009 21:47
> To: Wojciech Dec (wdec)
> Cc: Bernard Aboba; David B. Nelson; [email-masked]
> Subject: Re: IPv6
> 

That same RFC 2865, in section 5, states:

      string    1-253 octets containing binary data (values 0 through
                255 decimal, inclusive).  Strings of length zero (0)
                MUST NOT be sent; omit the entire attribute instead.

With that, Ipv6 Prefix, Route options, Auth-IPv6-Prefix-User-ID, etc
would be pretty much covered by using the string term.

> 
> 3.3 IPv6-Prefix
> 
>   Defines an IPv6 prefix with a tag.  There are NO existing 
> tagged IPv6 attributes.  RFC 2868 defines tagged integers and 
> strings *only*.  This data type is new.
> 
>   Defines an 8-bit tag, followed by a 32-bit integer.  RFC 
> 2868 defines a 32-bit integer where the 8-bit tag over-writes 
> the highest 8 bit of the integer.  This data type is new.
> 
>   Defines an 8-bit tag followed by a 64-bit integer.  There 
> are NO existing attributes that are tagged 64-bit integers.  
> This data type is new.

Are unsigned 64-bit integers really a new thing to Radius?  That would
seemingly contradict what's presented as de facto in
http://tools.ietf.org/html/draft-ietf-radext-design-08#section-2.1.1

-Woj.

> 
> 
>   This draft defines a number of new tagged data types which 
> are not previously used in any RFC, or on any vendor 
> equipment, or in any specification from another standards body.
> 
>   Alan DeKok.
>

---

From: Alan DeKok <[email-masked]>
Date: Tue, 06 Oct 2009 23:33:53 +0200

> would be pretty much covered by using the string term.

  The document says that attributes are of type "string", and not IPv6
prefix or integer.  Re-defining "32-bit integer" to mean "string" is an
argument from absurdity.

> Are unsigned 64-bit integers really a new thing to Radius? 

  You missed the word "tagged" in the sentence above.  That makes my
comment meaningful, instead of nonsensical.

> That would

  Only if you take a discussion about "tagged" attributes, and ignore
key words like "tagged".

  Alan DeKok.

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 6 Oct 2009 17:38:50 -0400

> would be pretty much covered by using the string term.

With all due respect, the String data type is just a string of  
undistinguished octets.   While you may conceptually overlay it with a  
structure, i.e define sub-fields, that action creates a new data  
type.  In other words, the String type is just a string.  You may  
lament the fact that RADIUS, as defined in RFCs up through 2865, has  
no method to formally define structured data, but the fact is that it  
has none.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 7 Oct 2009 09:53:25 +0200

> Sent: 06 October 2009 23:34
> To: Wojciech Dec (wdec)
>   The document says that attributes are of type "string", and 
> not IPv6 prefix or integer.  Re-defining "32-bit integer" to 
> mean "string" is an argument from absurdity.

Guess someone forgot to add a character encoding set limitation to the
definition of "string" above. Without it, any sequence of 1-253 octets
falls neatly under the "a string". That said, rfc 3162 clearly already
has a "call it whatever you want" data-type for "Framed-IPv6-Prefix",
which happens to be the same type of data as in the IPv6-Prefix in
draft-lourdelet.
Re Auth-IPv6-Prefix-User-ID, changing it to a string would definitely
work (and I see no problem in that).

The odd one out is probably the IPv6-Route-Option-Preference in
draft-lourdelet, which has an rfc4191 derived 2 bit signed integer. No
problem in changing that to a simple signed integer, while restricting
the values.

>   You missed the word "tagged" in the sentence above.  That 
> makes my comment meaningful, instead of nonsensical.

I'm still finding the issue rather nonsensical. Do you really mean to
say that the addition of an attribute, the tag, requires the
re-definition of each and every data type that radius has, eg "the
tagged 64-bit unsigned integer", etc? That's bizzarre at best... Why?

-Woj.

>   Only if you take a discussion about "tagged" attributes, 
> and ignore key words like "tagged".
> 
>   Alan DeKok.
>

---

From: Alan DeKok <[email-masked]>
Date: Wed, 07 Oct 2009 11:10:35 +0200

Wojciech Dec (wdec) wrote:
> falls neatly under the "a string".

  Is this a joke?

  Here's a short explanation, as it's clear you are completely
unfamiliar with RADIUS.

  RADIUS attributes are typed.  The list of types is small.  Each type
is statically defined in an RFC.  RADIUS implementations use these
definitions to determine how to manipulate the attributes (parse, print,
wire-encode, wire-decode).  The types cannot be changed, because they
have existing definitions.  Defining new encoding/decode means defining
new types... because you can't encode the OLD type in a NEW way, and you
can't encode the NEW type in the OLD way.

  Otherwise... please suggest how implementations can do the impossible,
and encode these new attributes using a novel format, without adding a
new encoding method.

> That said, rfc 3162 clearly already

  Absolute nonsense.  Framed-IPv6-Prefix has a different on-the-wire
format than IPv6-prefix.  Therefore, they are different data types.

> problem in changing that to a simple signed integer, while restricting

  RADIUS has no support for signed integers.  See:

http://tools.ietf.org/html/draft-ietf-radext-design-08

  I suggest reading the document before posting any more confusion about
data types in RADIUS.  It describes the RADIUS data model, along with
supported and not-supported data types.

> tagged 64-bit unsigned integer", etc? That's bizzarre at best... Why?

  Because that's how RADIUS works.  DHCP works the same way.  As does
DNS.  As does SNMP.  As does NTP.  The list goes on...

  In fact, *any* protocol that has bit-packing of data (as opposed to
text encoding like FTP or SMTP) has pretty much fixed data types.  You
can't change the interpretation of a "32-bit integer", because its
meaning is already defined.

  Try updating your C compiler to interpret "uint32_t" as "struct foo".
See how many third-party programs compile without error.  Those programs
make assumptions base on the definitions of the data types.  Changing
the data types means that the assumptions are no longer valid, and the
programs no longer work as intended.

  I'm surprised that this behavior is novel to you.  Binary packed
protocols have worked this way for a *long* time.

  Alan DeKok.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 7 Oct 2009 14:07:46 +0200

> Sent: 07 October 2009 11:11
> To: Wojciech Dec (wdec)
>   Here's a short explanation, as it's clear you are 
> completely unfamiliar with RADIUS.
> 
>   RADIUS attributes are typed.  The list of types is small.  
> Each type is statically defined in an RFC.  RADIUS 
> implementations use these definitions to determine how to 
> manipulate the attributes (parse, print, wire-encode, 
> wire-decode).  The types cannot be changed, because they have 
> existing definitions.  Defining new encoding/decode means 
> defining new types... because you can't encode the OLD type 
> in a NEW way, and you can't encode the NEW type in the OLD way.

So a number of points: Draft-lourdelet clearly defins NEW Attributes NOT
changing existing attributes and the draft does not propose anything for
which there isn't a precedent (see rfc2868, rfc3162). 
Overall, thanks for educating me, but perhaps you should take a step
back: In draft-lourdelet we're defining the on-the-wire format of these
new attributes. The data-type used for internal bindings of these
attributes is an implementation detail, which you (and perhaps others)
appear to make a business of the Radext WG (it seems that while new to
Radext, I haven't been missing out on much fun after all). 
Now, even if that were justfiied, with a definition of "string" like the
one above you have no right to claim that a "string" data-type cannot be
used for sending an arbitrary sequence of 1-255 octets of/in whatever
encoding. You're clearly basing your point on non-atomic data-types,
which I comment on further below...

> 
>   Otherwise... please suggest how implementations can do the 
> impossible, and encode these new attributes using a novel 
> format, without adding a new encoding method.

Uhm, for the IPv6-Prefix attribute one could have one of the following
abstract definitions (all of them with no new exotic data-types other
than those likely already used)

struct IPv6-Prefix { uint8_t tag; uint8_t prefix-length; uint128_t
prefix; };
OR
struct IPv6-Prefix { uint8_t tag; uint8_t prefix-length; string_t
prefix; };
Etc.

>   Absolute nonsense.  Framed-IPv6-Prefix has a different 
> on-the-wire format than IPv6-prefix.  Therefore, they are 
> different data types.

May I suggest that once more you're confusing on-the-wire format with
internal data-type representation. It would seem that according to you
each attribute in Radius with some internal structure not seen
previoulsy is effectively a new data-type and that this needs to be
enforced by the Radius specs. I'll call these non-atomic-data-types to
differentiate from what I consider common atomic data-types that rely on
common types/units of data (unit 32, etc). It's from the perspective of
non-atomic-data-types that draft-lourdelet *may* indeed be seen to call
for something new. It "may* but *it doesn't have* because that's again
all up to *implementation detail*. I'll use the following example to
illustrate. 
RFC3162 defines the framed-ipv6-attribute, and so presumably an
implementation also has a pseudo-data-type to support it:

Framed-IPv6-Prefix

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |  Reserved     | Prefix-Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                Prefix
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                Prefix
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                Prefix
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                Prefix                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Implementation wise, the difference between the above and the
IPv6-Prefix attribute in draft-lauderlet is the semantic of the Reserved
field vs the Tag field. If, when coding the psudeo-data-type one chose
to have the Reserved field modelled as a unit8 then it would be the same
pseudo-data-type that would apply to draft-lourdelet. If a different
choice was made, then a new psudo-data-type need to be cast.
Coincidentally, the Radius spec doesn't say which data-type should the
Reserved field be cast as.
All this shows how pointless is defining the protocol *and* such
non-atomic-data-type implementation specifics at the same time. The
protocol spec should not go into implementation specifics and your
argument around why it should be otherwise is rather unsubstatiated.
Draft-ietf-radext-design-08.txt doesn't do better, if actually being
misguided in some of these aspects.

It would help all if you could be a bit more constructive... 

-Woj.

>   I suggest reading the document before posting any more 
> confusion about data types in RADIUS.  It describes the 
> RADIUS data model, along with supported and not-supported data types.
> 
>   Because that's how RADIUS works.  DHCP works the same way.  
> As does DNS.  As does SNMP.  As does NTP.  The list goes on...
> 
>   In fact, *any* protocol that has bit-packing of data (as 
> opposed to text encoding like FTP or SMTP) has pretty much 
> fixed data types.  You can't change the interpretation of a 
> "32-bit integer", because its meaning is already defined.
> 
> See how many third-party programs compile without error.  
> Those programs make assumptions base on the definitions of 
> the data types.  Changing the data types means that the 
> assumptions are no longer valid, and the programs no longer 
> work as intended.
> 
>   I'm surprised that this behavior is novel to you.  Binary 
> packed protocols have worked this way for a *long* time.
> 
>   Alan DeKok.
>

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 7 Oct 2009 14:22:21 +0200

> [mailto:[email-masked]] On Behalf Of David B. Nelson
> Sent: 06 October 2009 23:39
> To: [email-masked]
> Subject: Re: IPv6
> 
> 
> structure, i.e define sub-fields, that action creates a new 
> data type.  In other words, the String type is just a string. 
>  You may lament the fact that RADIUS, as defined in RFCs up 
> through 2865, has no method to formally define structured 
> data, but the fact is that it has none.

Sure, that's fair. The point I was making is that with the string
definition above, passing an IPv6 prefix (or anything else up to 255
bytes really) did not require any new data-type and in terms of say the
IPv6-prefix. Furthermore rfc2868 provides plenty of precedent for
structured attributes with "String", if one wants, eg Tunnel-Password.

-Woj.

> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 07 Oct 2009 15:01:25 +0200

> which there isn't a precedent (see rfc2868, rfc3162). 

  I think we're really talking about different things.  I keep trying to
explain that the draft is doing something *new*.  You keep claiming it
isn't.

> Radext, I haven't been missing out on much fun after all). 

  The "implementation detail" you're arguing about is discussed in the
design guidelines document.  It's something that comes up in this WG,
and in others.  Implementation details are relevant, and cannot be
dismissed with a wave of the hand.

> encoding.

  I think you have a problem reading my messages.  I didn't claim the
"string" type wasn't suitable for sending arbitrary strings.  I said
that you couldn't have it both ways:  (1) claim that it's an attribute
with a strongly typed definition (tag + integer), and (2) claim that
it's also an arbitrary sequence of octets.

  It's about consistency.  I like it.  You're not following it.

> struct IPv6-Prefix { uint8_t tag; uint8_t prefix-length; uint128_t

  Please point out where the "struct" type is defined in the RADIUS
specifications.

  You can't.  It isn't defined anywhere.  You invented it, and claimed
that it can be used in RADIUS, and that it's just an "implementation
detail".  It's not.

  If this was Diameter, this would be possible.  Diameter defines a
grouped attribute, which can be used to group arbitrary other attributes
(i.e. data types) into a "struct" like object.

> internal data-type representation.

  Uh... the internal data types represent at *least* the on-the-wire
format.  If they didn't, the data types couldn't be encoded onto the wire.

> It would seem that according to you
> previoulsy is effectively a new data-type

  Don't blame me.  That would appear to be the consensus of this WG, as
written in the design guidelines document.

> and that this needs to be
> all up to *implementation detail*.

  Ignoring implementation details won't make them go away.  This draft
*gratuitously* introduces new data types where existing ones could be
re-used.

  That's not an implementation detail: it's bad design.

> argument around why it should be otherwise is rather unsubstatiated.

  Strange.  I could have sworn I was writing messages explaining my
position.  Did you read them?

  RADIUS servers have historically been been driven by data
dictionaries.  See Section 2 of the design guidelines document.  This
isn't an "implementation detail".  It is billions of dollars of
equipment in hundreds of thousands of sites.

  Some implementations have simple dictionary support, others support
complex dictionaries.  But this "implementation detail" needs to be
taken into account when writing new specifications.

> misguided in some of these aspects.

  I suggest that you post a separate review of the document. It's clear
that you have valuable input which could make the document better.

> It would help all if you could be a bit more constructive... 

  By all means.  Simple specifications that leverage existing
implementations are good.  Specifications that follow historical
practices are usually a good idea, too.

  I am encouraging good practice.  Part of this involves pointing out
bad practices, and explaining why they're bad.  If you think this is not
constructive, I suggest you avoid peer review entirely.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 7 Oct 2009 20:04:41 +0700

>   Here's a short explanation, as it's clear you are completely

Well, _someone_ is...
> 
>   RADIUS attributes are typed.  

In your mind, perhaps; in the real world (where RFC 2865 exists), one may
read page after page without ever seeing an attribute "typed".  A brief
example:

5.4.  NAS-IP-Address

   Description

      This Attribute indicates the identifying IP Address of the NAS
      which is requesting authentication of the user, and SHOULD be
      unique to the NAS within the scope of the RADIUS server. NAS-IP-
      Address is only used in Access-Request packets.  Either NAS-IP-
      Address or NAS-Identifier MUST be present in an Access-Request
      packet.

      Note that NAS-IP-Address MUST NOT be used to select the shared
      secret used to authenticate the request.  The source IP address of
      the Access-Request packet MUST be used to select the shared
      secret.

   A summary of the NAS-IP-Address Attribute format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Address (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      4 for NAS-IP-Address.

   Length

      6

   Address

      The Address field is four octets.

5.5.  NAS-Port

   Description

      This Attribute indicates the physical port number of the NAS which
      is authenticating the user.  It is only used in Access-Request
      packets.  Note that this is using "port" in its sense of a
      physical connection on the NAS, not in the sense of a TCP or UDP
      port number.  Either NAS-Port or NAS-Port-Type (61) or both SHOULD
      be present in an Access-Request packet, if the NAS differentiates
      among its ports.

   A summary of the NAS-Port Attribute format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      5 for NAS-Port.

   Length

      6

   Value

      The Value field is four octets.

5.6.  Service-Type

   Description

      This Attribute indicates the type of service the user has
      requested, or the type of service to be provided.  It MAY be used
      in both Access-Request and Access-Accept packets.  A NAS is not
      required to implement all of these service types, and MUST treat
      unknown or unsupported Service-Types as though an Access-Reject
      had been received instead.

   A summary of the Service-Type Attribute format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      6 for Service-Type.

   Length

      6

   Value

      The Value field is four octets.

       1      Login
       2      Framed
       3      Callback Login
       4      Callback Framed
       5      Outbound
       6      Administrative
       7      NAS Prompt
       8      Authenticate Only
       9      Callback NAS Prompt
      10      Call Check
      11      Callback Administrative

      The service types are defined as follows when used in an Access-
      Accept.  When used in an Access-Request, they MAY be considered to
      be a hint to the RADIUS server that the NAS has reason to believe
      the user would prefer the kind of service indicated, but the
      server is not required to honor the hint.

      Login               The user should be connected to a host.

      Framed              A Framed Protocol should be started for the
                          User, such as PPP or SLIP.

      Callback Login      The user should be disconnected and called
                          back, then connected to a host.

      Callback Framed     The user should be disconnected and called
                          back, then a Framed Protocol should be started
                          for the User, such as PPP or SLIP.

      Outbound            The user should be granted access to outgoing
                          devices.

      Administrative      The user should be granted access to the
                          administrative interface to the NAS from which
                          privileged commands can be executed.

      NAS Prompt          The user should be provided a command prompt
                          on the NAS from which non-privileged commands
                          can be executed.

      Authenticate Only   Only Authentication is requested, and no
                          authorization information needs to be returned
                          in the Access-Accept (typically used by proxy
                          servers rather than the NAS itself).

      Callback NAS Prompt The user should be disconnected and called
                          back, then provided a command prompt on the
                          NAS from which non-privileged commands can be
                          executed.

      Call Check          Used by the NAS in an Access-Request packet to
                          indicate that a call is being received and
                          that the RADIUS server should send back an
                          Access-Accept to answer the call, or an
                          Access-Reject to not accept the call,
                          typically based on the Called-Station-Id or
                          Calling-Station-Id attributes.  It is
                          recommended that such Access-Requests use the
                          value of Calling-Station-Id as the value of
                          the User-Name.

      Callback Administrative
                          The user should be disconnected and called
                          back, then granted access to the
                          administrative interface to the NAS from which
                          privileged commands can be executed.

5.7.  Framed-Protocol

   Description

      This Attribute indicates the framing to be used for framed access.
      It MAY be used in both Access-Request and Access-Accept packets.

   A summary of the Framed-Protocol Attribute format is shown below.
   The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      7 for Framed-Protocol.

   Length

      6

   Value

      The Value field is four octets.

      1      PPP
      2      SLIP
      3      AppleTalk Remote Access Protocol (ARAP)
      4      Gandalf proprietary SingleLink/MultiLink protocol
      5      Xylogics proprietary IPX/SLIP
      6      X.75 Synchronous

5.8.  Framed-IP-Address

   Description

      This Attribute indicates the address to be configured for the
      user.  It MAY be used in Access-Accept packets.  It MAY be used in
      an Access-Request packet as a hint by the NAS to the server that
      it would prefer that address, but the server is not required to
      honor the hint.

   A summary of the Framed-IP-Address Attribute format is shown below.
   The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Address (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      8 for Framed-IP-Address.

   Length

      6

   Address

      The Address field is four octets.  The value 0xFFFFFFFF indicates
      that the NAS Should allow the user to select an address (e.g.
      Negotiated).  The value 0xFFFFFFFE indicates that the NAS should
      select an address for the user (e.g. Assigned from a pool of
      addresses kept by the NAS).  Other valid values indicate that the
      NAS should use that value as the user's IP address.

> The list of types is small.  Each type
> is statically defined in an RFC.  

In what RFC is the "8-bit Tag + 24-bit Integer" "data type" defined?  That's
easy, none.  The fact that some implementations _treat_ it as a "data type"
doesn't make it so, since there are other ways to implement a tag.

> RADIUS implementations use these
> impossible,

Alan, who's spouting nonsense here?  Are you claiming that entire attributes
are "data types" now?  

> data types in RADIUS.  It describes the 

DeKok

> data model, along with

...

---

From: Alan DeKok <[email-masked]>
Date: Wed, 07 Oct 2009 15:08:21 +0200

Wojciech Dec (wdec) wrote:
> IPv6-prefix.

  From the design guidelines document:

   If the RADIUS Server simply passes the contents of an attribute to
   some non-RADIUS portion of the network, then the data is opaque, and
   SHOULD be defined to be of type String.  A concrete way of judging
   this requirement is whether or not the attribute definition in the
   RADIUS document contains delineated fields for sub-parts of the data.
   If those fields need to be delineated in RADIUS, then the data is not
   opaque, and it SHOULD be separated into individual RADIUS attributes.

> Furthermore rfc2868 provides plenty of precedent for

  From the design guidelines document:

   As can be seen in Appendix B, most of the existing complex attributes
   involve authentication or security functionality.  Supporting this
   functionality requires code changes on both the RADIUS client and
   server, regardless of the attribute format.  As a result, in most
   cases, the use of complex attributes to represent these methods is
   acceptable, and does not create additional interoperability or
   deployment issues.

  All of these arguments are familiar, and have been hashed through in
detail in this WG.  There are good reasons for the current behavior.
The document explains that *changes* in behavior need good reasons, too.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 07 Oct 2009 15:21:11 +0200

Glen Zorn wrote:
> read page after page without ever seeing an attribute "typed".

  Ah... the RFC 2486 definition that the NAS-IP-Address attribute is an
"ipv4 address" is just there for joviality.  It can really be anything
you want.

  Or, as the design guidelines document says:

   Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does
   not define a formal data definition language.  A handful of basic
   data types are provided, and a data type is associated with an
   attribute when the attribute is defined.

> doesn't make it so, since there are other ways to implement a tag.

  Strange.  I was talking about the protocol, and the definition of
attributes.  Having done some minor programming from time to time, I am
aware of the difference between wire encoding and data structures
internal to an implementation.

  Would you be happier if I said "there are a limited number of data
formats that are encoded/decoded on the wire" ?  Maybe that would make
it clearer that I am talking about the protocol.

  New formats require new encoders/decoders.  Is that controversial?

  Re-using existing formats is usually good.  Is that controversial?

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 7 Oct 2009 20:30:00 +0700

David B. Nelson [mailto://[email-masked]]:

> undistinguished octets.   

Reference, please (don't tell me you've adopted the DeKok method of just
making it up as you go, as you please!).

> While you may conceptually overlay it with a

There are a number of problems with this little fantasy (along with the idea
that so-called "complex" attributes are not a "traditional" RADIUS data
type), among them that a) RFC 2548 contains oodles of "structured data" in
_very_ widely implemented and deployed attributes, b) RFC 2865 itself
contains "structured data" in the CHAP-Password attribute and c) RFC 2868
(which was published the same day as 2865 -- in fact it was delayed in the
queue to let 2865 go first), again, has lots of "complex" attributes and,
for that matter, structured data.  You may lament the fact that RADIUS has
methods to define "structured data" and even try to write it out of history
(as Alan apparently wishes to) but the fact is that it does.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 7 Oct 2009 21:06:32 +0700

Alan DeKok [mailto:[email-masked]] writes:

> "ipv4 address" is just there for joviality.  

Must be a typo -- RFC 2486 nowhere mentions the NAS-IP-Address attribute &
doesn't contain the (case-folded) string "IPv4".  What are you actually
talking about?

> It can really be anything
> you want.

This is how RFC 2865 defines the attribute:

5.4.  NAS-IP-Address

   Description

    0                   1                   2                   3

   Type

      4 for NAS-IP-Address.

   Length

      6

   Address

That's all, "four octets".  Note that the "Address" data type is defined
previously in the document but it's not used here.  Could be a "string" of
length 4, could be an "Integer", could be an "Address".  This may seem
frivolous, but it's related to David's comments in another message: it
actually doesn't matter what the data type is because everybody _knows_ that
it's an IPv4 address -- we are 'conceptually overlaying' the 4 octet field
with a contiguous sub-field interpreted as an IPv4 address.  The same thing
happens all over the place in RFC 2865 and if David is correct then  the
"data" fields in probably half the attributes defined therein are unique
data types.

>    attribute when the attribute is defined.

But that's not true, either - a single counterexample would suffice & I've
already given half a dozen.

> attributes.  Having done some minor programming from time to time, 

I just want to note that I deserve MAJOR style points for letting that one
pass ;-).

> I am

I'd be happier if you didn't use the same term to name two entirely
different things.

>   Re-using existing formats is usually good.  Is that controversial?

Both those statements seem implementation-specific to me.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 07 Oct 2009 17:56:11 +0200

> doesn't contain the (case-folded) string "IPv4".  What are you actually

  You're right.  It defines a 32-bit IP address that is completely
unrelated to IPv4.

> with a contiguous sub-field interpreted as an IPv4 address.

  Of course.  Just like we're conceptually overlaying "octets", where
there are really groups of "0" and "1" bits.

  At some point this abstraction becomes absurd.

>  The same thing

  See my previous audit of RFC and vendor attributes posted to this
list.  About 95% use the simple standard data types. (IP address,
integer, text, etc. but not string)

> already given half a dozen.

  See my previous audit of RFC and vendor attributes posted to this
list.  There are 8 common data types.  That's "a handful".  And 95% of
attributes use this "handful".

  I think the confusion here is I'm talking about real-world, imprecise,
imperfect practice.  So "common use" means "95%".  And "a handful" means
"8".

  You're arguing from a point of perfection.  Because ONE attribute is
of a unique complex type, it means that any attempt to use standard
types is useless.

  OK... let's give up trying to re-use common types.  Let's define novel
on-the-wire encodings for every single new attribute.  That will really
accelerate the progress of documents in this WG!

> Both those statements seem implementation-specific to me.

  I welcome an implementation which can encode and decode novel formats
with zero changes to the software (binaries, config files, dictionaries,
etc.)  That's some kind of magic bean you're selling.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 7 Oct 2009 23:28:27 +0700

...

>   You're arguing from a point of perfection.  

No, I'm arguing what the standards _actually_ say, while you are arguing
what you _want_ them to say.

> Because ONE attribute is

It's hardly just one, but the point is that "complex" types are as standard
as any other of those either specifically defined in RFCs or those that were
not (like 64-bit integers) of which you apparently approve.

...

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 7 Oct 2009 09:48:16 -0700

We have reserved time on the October 13 Virtual Interim agenda for discussion of the IPv6 document. 

In order to structure the discussion, I would like to solicit presentations relating to the following aspects:

a. Broadband Forum requirements for IPv6 over PPP support
b. Pros and Cons of potential encoding approaches
    1.  Use of Extended Attributes tagging mechanism
    2.  RA string encoding
    3.  Definition of new tagged data types

Do we have volunteers for these presentations?  

In order to make the slides available in time, I'd like get all presentation materials by October 11.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 07 Oct 2009 20:26:13 +0200

> what you _want_ them to say.

  I can't recall making statements about what I want the standards to
say.  Perhaps you could point to one of my messages which says that?

> not (like 64-bit integers) of which you apparently approve.

  Ah.  Like the "standard" attributes defined in RFC 2548, which is
"Category: Informational".

  In case you haven't read my messages, I'm *not* objecting to complex
types.  I'm objecting to the *gratuitous* use of complex types.

  Alan DeKok.