[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: RADEXT WG last call on RADIUS attributes for IPv6 Access Networks

On Tue, 2 Mar 2010, Wojciech Dec (wdec) wrote:


Well, so rfc3162 was perhaps a bit too generous with the options here.
It pretty much allows any combination of Framed-IPv6-Prefix,
Framed-Interface-Id and Framed-IPv6-Pool to be used. A couple of
examples:
Things get interesting for a server given that we have the possibility
of the NAS picking a prefix/address from a pool, and then sending an
accounting record which may contain that address encoded as
a) nothing (ie for the pool option the accounting record does not
include the address, but only the pool name)
b) a combination of a /64 ipv6-prefix and 64 bit interface-id
c) a /128 in the ipv6-prefix (possibly coming also with a 64 interface
id)
D) Various vendor VSAs (which have been devised to work around the
ambiguities of the above)



A non trivial story applies for the client when the "to be assigned"
numeral address can come down by any of the latter combinations, which
the client needs to interpret for their sanity (eg how should a /120
ipv6-prefix with a /64 interface id be handled). This is further
compounded by the issue of having to potentially assign multiple
addresses to a client (say a GUA and a ULA), using different methods
(SLAAC and DHCP).



With hindsight it may have been better to simply call out for a fixed
length /128 address attribute to simplify some of these situations,
especially when the intent is really that of communicating the exact
/128 address. That's the role I see for the framed-ipv6-address
attribute. It's role is to:
1) Be semantically very clear that this address doesn't need to be
combined with some other attribute to form an address (it's a fixed
length 128 field)
2) Allow for a distinction between multiple address assignment
mechanisms on the interface and their source info (pretty much why
rfc4818 could not have used the framed-ipv6-prefix attribute, even
though all it does is communicate a prefix)
3) Allow for the /128 address to be un-ambiguously communicated in
accounting messages (as opposed to having to guess between the
combinations)



Paradoxically I like the idea of the new attribute...
Ideas:
Make IPv6-Framed-Address valid for authentication only.
Relabel the attribute (ie IPv6-Framed-DHCP-Address)
Given the above examples/reasons, would you still see a need to restrict the use/naming of the attribute as suggested. What is your concern with the proposed use? 

None WRT assignment/auth, thank you.

My suggestion WRT an accounting restriction is based on a scenario:

Accounting system relies on RFC 3162 to report client IP.

NAS decides to send IPv6-Framed-Address rather than RFC 3162 method.
Accounting system requires modification to continue to understand the same information.
From an accounting perspective specific to any one NAS with a known behavior use of IPv6-Framed-Address can certainly simplify matters.
Globally it can have the opposite effect as an additional attribute/RFC possibly needs to be consulted to figure out the users IP..especially in instances where NAS are not under direct administrative control.
Perhaps another way to resolve is to make a SHOULD/MAY recommendation to also send Framed-IPv6-Prefix/128 for accounting. Realistically IMHO its still early WRT IPv6 deployment and not likely to be a big deal either way. 

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