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

["Wojciech Dec (wdec)" <wdec@cisco.com>]

> -----Original Message-----
> From: Peter Deacon [mailto:peterd@iea-software.com] 
> Sent: 02 March 2010 16:28
> To: Wojciech Dec (wdec)
> Cc: radiusext@ops.ietf.org
> Subject: RE: RADEXT WG last call on RADIUS attributes for 
> IPv6 Access Networks
> 
> On Tue, 2 Mar 2010, Wojciech Dec (wdec) wrote:
> 
> >> If the /128 prefix approach is used should I expect that 
> an IP would 
> >> be assigned to the end user?
> >> Just don't want existing stuff to become broken :(
> 
> > Precisely that's the reason for having the new attribute as 
> opposed to 
> > overloading the previous one for the case when the full 
> /128 is to be 
> > passed down instead of a /64 (or less) for use in SLAAC. Having the 
> > two separated ensures that existing stuff doesn't get broken.
> 
> Up until the point where the draft is accepted, how would 
> someone have assigned or accounted for a single IPv6 address?

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)

> 
> From my read of RFC 3162 there is no mention of an underlying 
> technology association with Framed-IPv6-Prefix - be it 
> SLAAC/ND, DHCPv6 or a future technology yet to exist.

Well, the Framed-Interface-Id is quite specific to its use with PPP and
IPCPv6, so one could say that the underlying technology is being
reflected in Radius...
> 
> Given the design of IPv6 is a shift to assignment and 
> identification via prefix it seems reasonable /128 prefixes 
> would already be used in this way at the very least in 
> accounting messages for sessions or sub-sessions involving 
> individual hosts.
> 
> 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?

Thanks,
Woj.
> 
> 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/>