Re: IPv6

[Alan DeKok <aland@deployingradius.com>]

Wojciech Dec (wdec) wrote:
> 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".

  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
> 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.

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

> 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.

  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.

> 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?

  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.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>