Some suggestions for/comments on draft-ietf-radext-ipv6-access-01

[Mark Smith <msmith@internode.com.au>]

Hi,

I've just come across this draft today, and have some 
suggestions/comments, based on the work we're doing for our IPv6 
production ADSL deployment.


---
2.  Deployment Scenarios

If found this section a bit confusing, particularly "RG host", as it has 
seemed to me that the more common deployment model, in particular when 
using PPPoE, would be that the 'RG' would most commonly be an IPv6 
router, not a host. It also seems to be a bit too specific to DSL 
deployments, using Broadband Forum terminology.

Perhaps the more generic "IPv6 End-user Network Architecture" diagram 
and terminology in the IPv6 Customer Edge Router draft might be a bit 
less confusing and less specific to Broadband Forum terminology.

---
2.1. IPv6 Address Assignment / 3.1. Framed-IPv6-Address

"While SLAAC provides a host with a /64 IPv6 prefix from which to 
construct its address, the host is free to construct a 64-bit Interface 
ID that when concatenated with the /64 prefix provides a unique address. 
By providing a host only a /64 network operators are unaware of the 
exact IP addresses in use by a device."

In the implementation we've been working with, by quite a well known 
vendor, we haven't had these sorts of issues. When we have the PPP/PPPoE 
PE router choose the /64s to assign to the PPP/PPPoE customer session, 
via a router local prefix pool, we have that assigned prefix reported in 
the RADIUS Accounting packets via the Framed-IPv6-Prefix attribute, and 
receive the IID, chosen by the CE device, reported via the 
Framed-Interface-Id attribute. We've also been able to specify the IID 
that the CE device should use, using Framed-Interface-Id in RADIUS 
Access-Accepts and provided to the CE via IPv6CP, in combination with a 
Framed-IPv6-Prefix, provided by RAs.

Based on that quite successful experience, I'm not sure I can see a 
strong need for a RADIUS attribute that explicitly combines both the 
prefix and IID information, either during RADIUS based authentication 
and accounting.

---
2.2 Recursive DNS Servers / 3.2. DNS-Server-IPv6-Address

Generally OK with this.

I was going to suggest another RADIUS attribute to supply the domain 
name to router, in the context of the PE router operating as DHCPv6 
server. However, that starts to suggest that RADIUS attributes should be 
created for all possible DHCPv6 options that the PE located DHCPv6 
server could supply to the downstream device, as there may be cases 
where different authenticated CE receive different sets of DHCPv6 
supplied options, with RADIUS Access-Accept being used to supply them to 
the PE router.

It seems a bit redundant to replicate DHCPv6 Options as RADIUS options 
and it also seems that people have thought of this sort of problem 
before - RFC4580, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 
Relay Agent Subscriber-ID Option", describes an DHCPv6 option that can 
be used to supply subscriber-ID information for DHCPv6 response option 
selection.

Maybe a more general solution, rather than IPv6 DNS specific RADIUS 
attribute, would be to have a RADIUS Access-Accept attribute that 
indicates to the PE router that, for the authenticated CE, it should 
query the specified DHCPv6 server, supplying the Subscriber-ID, for 
DHCPv6 options to provide to then supply to the CE via DHCPv6 or, in the 
case of IPv6 DNS, RDNSS options.

---
2.3. IPv6 Route Information / 3.3. Route-IPv6-Information

Fine with this.

I'm a bit curious if any thought was put into creating a RADIUS 
attribute to express router preference?


---
Delegated Prefix IPv6 Pool Attribute

We'd find it really useful to have an IETF RADIUS attribute that allows 
us to specify the local IPv6 prefix pool that the PE router DHCPv6 
server uses to choose prefixes it delegates via DHCPv6-PD. Currently 
we're using a vendor specific attribute.

This would be a Delegated Prefix oriented version of the existing 
Framed-IPv6-Pool attribute.


HTH,
Mark.
















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