Re: Last call on extensions document?

[Peter Deacon <peterd@iea-software.com>]

On Tue, 2 Aug 2011, Alan DeKok wrote:

> > As IPv6 is deployed following the current scheme of keeping address
> > families separated into separate attributes wherever addresses are used
> > will become problematic as cases where the address family is not known
> > in advance creep up.

>  My $0.02 is that it would be better to use TLVs.  But I welcome an
> inspired discussion on the topic. :)

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.

Some examples:

Naming services
Access control and filtering
Flow export and logging servers
Application proxies (smtp, web content filter..etc)
App specific services


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.

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.

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!

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.





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.

regards,
Peter

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