Yesterday I described how the IPv6 architects split the functionality of IPCP into three different protocols (IPCPv6, RA and DHCPv6). While the split undoubtedly makes sense from the academic perspective, the service providers offering PPP-based services (including DSL and retrograde uses of PPP-over-FTTH) went berserk. They were already using RADIUS to authenticate PPP users ... and were not thrilled by the idea that they should deploy DHCPv6 servers just to make the protocol stack look nicer.
As expected, Cisco’s first response was a royal kludge: let’s trigger the first RADIUS request when the PAP/CHAP packet arrives and set interface IPv6 parameters from the RADIUS response attributes ... and then when the DHCPv6 request arrives, let’s do another RADIUS request, this time with a different username to get the IPv6 prefix that should be delegated to the CPE. Oh, and by the way, we don’t really support the IPv6 DNS-related RADIUS attributes yet, so if you want to pass IPv6 DNS server address to the CPE, just configure local DHCPv6 pools on the BRAS routers (did we mention you need them anyway to support DHCPv6-RADIUS integration?).
Update 2012-01-19: Cisco IOS release 15.1S and IOS XE release 3S support RFC 4818.
Various methods a service provider can use to handle DHCPv6 prefix delegation are described in my Building IPv6 Service Provider Core webinar (buy the recording or register for an online session); you’ll also get tested router configurations that you can use in your IPv6 deployment. If you’re an enterprise engineers running a decently large network, you’ll probably find the webinar useful despite its title.
The webinar is also available as part of the yearly subscription package.