Re: Last call on extensions document?

[Avi Lior <avi@bridgewatersystems.com>]

I also support the notion of having a "family-specific" attribute set.

My reasons are somewhat different.

In the case of carrying a "pure" IPv6 address and a pure IPv4 address then
the argument for having a single attribute to carry both makes sense.

However, IPv6 addresses have different flavours.  Sometime I want to carry
a "pure" IPv6 address, sometimes I want to convey just the prefix and
sometimes I want to convey the prefix and the interface and thus I need to
include the prefix length in the address.  There are examples of these
encodings already in the IETF.

A family-specific approach is good.  Thus if we want to create such a
beast for IPv6 addresses we should create an attribute that can meet all
the use cases or have an attribute type for each use case.

Avi

On 11-08-04 20:52 , "Alan DeKok" <aland@deployingradius.com> wrote:

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


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