Re: IPv6

[Alan DeKok <aland@deployingradius.com>]

Glen Zorn wrote:
> Alan DeKok [mailto:aland@deployingradius.com] writes:
>>   Ah... the RFC 2486 definition that the NAS-IP-Address attribute is an
>> "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?

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

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

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

  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)

>>   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.
> 
> But that's not true, either - a single counterexample would suffice & I've
> 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!

>>   New formats require new encoders/decoders.  Is that controversial?
>>
>>   Re-using existing formats is usually good.  Is that controversial?
> 
> 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.

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