[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last call on extensions document?
On Thu, 4 Aug 2011, Alan DeKok 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.
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.
It is unecessary, redundant and wasteful.
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.
Its a problem that does not need to exist. Regardless of where you punt
for those attributes taking advantage of combo IP the issue goes away.
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.
Use of naming services to abstract network addresses is universal. Kind
of the whole point of using these systems in the first place.
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?
Of course you can enumerate the result of name lookups and send multiple
attributes if there are multiple results. I never suggested otherwise.
Without combo IP the system needs *extra* intelligence to know the IPv4
and IPv6 analogue for each attribute. With combo IP this is unnecessary as
the same attribute can be used and the system just works.
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.
64-bit integers are not required to convey 64-bit data types. There are
thousands of attributes available. The same result can be achieved with
gigawords.
*require* is not the point. I think this was made pretty clear in the "we
can live without" language used above.
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/>