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

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 1 Mar 2010 11:43:05 -0800

This is an announcement of RADEXT WG last call on "RADIUS attributes for
IPv6 Access Networks" before sending the document off to the IESG for
consideration as a Proposed Standard.  A copy of the document is available
for inspection here:

http://tools.ietf.org/html/draft-ietf-radext-ipv6-access

The RADEXT WG last call will last until March 21, 2010.    Please send
comments to the RADEXT WG mailing list using the format described in the
RADEXT Issues list (http://www.drizzle.com/~aboba/RADEXT )

---

From: Peter Deacon <[email-masked]>
Date: Mon, 1 Mar 2010 12:12:20 -0800 (Pacific Standard Time)

On Mon, 1 Mar 2010, Bernard Aboba wrote:

> This is an announcement of RADEXT WG last call on “RADIUS attributes for IPv6
> Access Networks” before sending the document off to the IESG for

> http://tools.ietf.org/html/draft-ietf-radext-ipv6-access

3.1.

I'm confused on IPv6-Framed-Address and Framed-IPv6-Prefix from RFC 3162. 
It looks as if both attributes accomplish the same goal.  Is there a 
difference between IPv6-Framed-Address and Framed-IPv6-Prefix of /128?

regards,
Peter

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 1 Mar 2010 12:23:45 -0800 (PST)

Hi Peter,

----- Original Message ----
> From: Peter Deacon <[email-masked]>
> To: [email-masked]
> Sent: Mon, March 1, 2010 2:12:20 PM
> Subject: Re: RADEXT WG last call on RADIUS attributes for IPv6 Access Networks
> 

> This is an announcement of 
> RADEXT WG last call on “RADIUS attributes for IPv6
> Access Networks” 
> before sending the document off to the IESG for
> consideration as a 
> Proposed Standard.  A copy of the document is available
> for inspection 
> here:

3.1.

I'm 
> confused on IPv6-Framed-Address and Framed-IPv6-Prefix from RFC 3162. It looks 
> as if both attributes accomplish the same goal.  Is there a difference 
> between IPv6-Framed-Address and Framed-IPv6-Prefix of 
> /128?

I don't think Framed-IPv6-Prefix was intended to be an attribute for an address. Yes Framed-IPv6-Prefix could become like an address but /128 is the only case, data point.

Regards,

Behcet

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 1 Mar 2010 12:48:56 -0800

Yes, there is a difference.  Framed-IPv6-Prefix is specifically for use within a Router Advertisement. 
So if the RADIUS server were to send a Framed-IPv6-Prefix of /128 to the NAS, this would be inserted
in the RA by the NAS (which is probably not what you want). 

An IPv6-Framed-Address on the other hand, is for use within the NAS's embedded DHCPv6 server.  

Note that it is possible for a NAS to support *both* stateless autoconfig and DHCPv6, so that both
attributes could be present in the same Access-Accept.    This is yet another reason why distinct
attributes are required -- how else could the NAS figure out which attribute is to be used for what
purpose?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Deacon
Sent: Monday, March 01, 2010 12:12 PM
To: [email-masked]
Subject: Re: RADEXT WG last call on RADIUS attributes for IPv6 Access Networks

3.1.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Mon, 1 Mar 2010 15:14:43 -0800 (Pacific Standard Time)

On Mon, 1 Mar 2010, Bernard Aboba wrote:

> Yes, there is a difference.  Framed-IPv6-Prefix is specifically for use 
> within a Router Advertisement. So if the RADIUS server were to send a 
> Framed-IPv6-Prefix of /128 to the NAS, this would be inserted in the RA 
> by the NAS (which is probably not what you want).

RFC3162 does not mention which underlying technology is used for 
assignment.

> An IPv6-Framed-Address on the other hand, is for use within the NAS's 

DHCPv6 is capable of assignment of both single addresses and prefixes.

> Note that it is possible for a NAS to support *both* stateless 
> autoconfig and DHCPv6, so that both attributes could be present in the 
> same Access-Accept.  This is yet another reason why distinct attributes 
> are required -- how else could the NAS figure out which attribute is to 
> be used for what purpose?

The way I see consistancy is leaving "how" up to the NAS and authorization 
attributes "what" (Prefixes, Ipv6 or both) up to the draft.

A more to the point and salient question - what is the expected difference 
in behavior for an access server should Framed-IPv6-Prefix /128 be used in 
lieu of IPv6-Framed-Address?

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 :(

regards,
Peter

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 2 Mar 2010 02:44:27 -0800

> DHCPv6 is capable of assignment of both single addresses and prefixes.

Delegation is addressed in RFC 4818.
 
> If the /128 prefix approach is used should I expect that an IP would be assigned to the end user?

You should not expect a DHCPv6 address to be assigned.  On some NASes I wouldn't expect *any* address to be assigned.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 2 Mar 2010 12:29:55 +0100

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Peter Deacon
> Sent: 02 March 2010 00:15
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: RE: RADEXT WG last call on RADIUS attributes for 
> IPv6 Access Networks
> 
> > Yes, there is a difference.  Framed-IPv6-Prefix is specifically for 
> > use within a Router Advertisement. So if the RADIUS server were to 
> > send a Framed-IPv6-Prefix of /128 to the NAS, this would be 
> inserted 
> RFC3162 does not mention which underlying technology is used 
> for assignment.
> 
> > An IPv6-Framed-Address on the other hand, is for use within 
> the NAS's 
> > embedded DHCPv6 server.
> 
> > same Access-Accept.  This is yet another reason why distinct 
> > attributes are required -- how else could the NAS figure out which 
> > attribute is to be used for what purpose?
> 
> The way I see consistancy is leaving "how" up to the NAS and 
> authorization attributes "what" (Prefixes, Ipv6 or both) up 
> to the draft.
> 
> A more to the point and salient question - what is the 
> expected difference in behavior for an access server should 
> Framed-IPv6-Prefix /128 be used in lieu of IPv6-Framed-Address?
> 

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.

Regards,
Woj.

> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Peter Deacon
> > Subject: Re: RADEXT WG last call on RADIUS attributes for 
> IPv6 Access 
> > Networks
> >
> >> This is an announcement of RADEXT WG last call on "RADIUS 
> attributes 
> >> for IPv6 Access Networks" before sending the document off 
> to the IESG 
> >> for consideration as a Proposed Standard.  A copy of the 
> document is 
> >> available for inspection here:
> >

---

From: Peter Deacon <[email-masked]>
Date: Tue, 2 Mar 2010 07:27:55 -0800 (Pacific Standard Time)

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

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

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)

regards,
Peter

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 2 Mar 2010 20:16:50 +0100

> From: Peter Deacon [mailto:[email-masked]] 
> Sent: 02 March 2010 16:28
> To: Wojciech Dec (wdec)
> >> If the /128 prefix approach is used should I expect that 
> an IP would 
> >> be assigned to the end user?
> > 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.
> 

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.

---

From: Peter Deacon <[email-masked]>
Date: Tue, 2 Mar 2010 13:09:25 -0800 (Pacific Standard Time)

> the use/naming of the attribute as suggested. What is your concern with 

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

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 3 Mar 2010 10:19:14 +0100

> 
> > 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?
> 
> Accounting system requires modification to continue to 
> understand the same information.

Yes, I see your point. Don't you think however that this could be
handled by a client knob/implementation? I.E. If in an access-accept a
server sends the IPv6-Framed-Address, then the NAS client can interpret
it to mean that its ok to use this attribute in accounting messages. If
an IPv6-Framed-Address does not come down in an access-accept, then the
NAS would use by default "whatever it uses today", unless it has been
explicitly configured to send accounting info with using
IPv6-Framed-Address.
This would seem to cover your concerns. What do you think?

-Woj.

---

From: Peter Deacon <[email-masked]>
Date: Wed, 3 Mar 2010 12:18:47 -0800 (Pacific Standard Time)

> This would seem to cover your concerns. What do you think?

Yes, sounds reasonable.

regards,
Peter