Re: Last call on extensions document?

[Alan DeKok <aland@deployingradius.com>]

Peter Deacon wrote:
> In most cases where an attribute of type IP Address needs to be defined
> there will be a need for an IPv6 analogue of that same attribute.

  OK.

> There are implementation costs and operational costs associated with the
> approach of segregating address families.  Costs can be reduced somewhat
> with a ComboIP (Payload Len 4 = IPv4, 16 = IPv6) data type.
> 
> Currently:
> 
> 1. Multiple attributes need to be defined.

  With 1000+ new attributes and TLVs, I'm not sure this is an issue.

> 2. Operators entering an IP Address into fields need to make sure they
> select the correct attribute based on the address family they are
> targeting.

  That's a UI problem.  The system in which they enter the IP should
know (a) the address family, and (b) the relevant attribute.  There's no
reason to force the admin to make those choices.

> Operators may enter a hostname and have the system enter the resolved
> address.  In this case the operator may have no knowledge of the address
> family or it may change tomorrow!

  Which is a disaster for maintainable systems.  Having the RADIUS
response change because of modifications to DNS is terrible.  I strongly
oppose that kind of setup.

> The system will need to provide additional intelligence during the name
> lookup process to select the proper attribute based on address family
> for each instance.

  It can send multiple attributes.  Foo-IPv4, Foo-IPv6, Foo-IPv4, etc.

  Why select?  If the DNS lookup provides 2 IPv4s, and 1 IPv6, why not
send that in RADIUS?

> We can live without however much like gigawords I believe with the new
> attribute space comes some opportunity to improve the standard framework
> for future attributes.

  Of course.

  While adding "combo IP" seems OK for WiMAX, I'm not convinced that the
above use-cases *require* it.  The same result can be achieved with
family-specific attributes.

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