RE: IPv6

["Wojciech Dec (wdec)" <wdec@cisco.com>]

> -----Original Message-----
> From: Alan DeKok [mailto:aland@deployingradius.com] 
> Sent: 07 October 2009 11:11
> To: Wojciech Dec (wdec)
> Cc: Bernard Aboba; David B. Nelson; radiusext@ops.ietf.org
> Subject: Re: IPv6
> 
> 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.

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.

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

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.

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