More real-life DHCPv6 Prefix Delegation gotchas
The murky details of IPv6 implementations never crop up till you start deploying it (or, as Randy Bush recently wrote: “it is cheering to see that the ipv6 ivory tower still stands despite years of attack by reality”).
Here’s another one: in theory the prefixes delegated through DHCPv6 should be static and
permanently assigned to the customers .
Quoting from RFC 3633: Even though this mechanism makes automatic renumbering easier, it is expected that prefixes have a long lifespan. During renumbering it is expected that the old and the new prefix co-exist for some time. It's almost impossible to implement coexistence of old and new prefixes with today's BRAS software; the only reliable approach is to make delegated prefixes as stable as possible.
In practice, you never know how many of your customers will actually ask for the delegated prefix, so it might be simpler to use a local BRAS pool to serve the customers that ask for a delegated prefix out of the blue, and static RADIUS-based prefix delegation for people who actually ask for a static prefix.
Fortunately, Cisco IOS/IOS-XE already has a tool to do exactly that: RADIUS-based DHCPv6 prefix delegation works according to RFC 4818 in recent IOS releases, and you can use the Delegated-IPv6-Prefix-Pool to specify the local BRAS pool for those customers that don’t have the Delegated-IPv6-Prefix attribute.
If you’re using freeRADIUS it seems you can create a rule that would add the Delegated-IPv6-Prefix-Pool to users that don’t have the Delegated-IPv6-Prefix attribute. Suggestion highly welcome ;)
Detailed description of DHCPv6 prefix delegation mechanisms and RADIUS integration is part of the Building Large IPv6 Service Provider Networks webinar. You can buy its recording or get it as part of the IPv6 trilogy or yearly subscription.
2012-12-13: Updated the first part of the blog post based on feedback from Eric Vyncke.
After PD subnet change the CPE should send RA on it LAN with lifetime 0 for the old prefix and send RA with non-zero lifetime for the new prefix.
See L-13 in http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-08
I hope they will do it correctly or we will have a lot of problems.
As for 6204bis - hope springs eternal, but the historical data points in vendor reality indicate otherwise.
My own provider also gives me the same delegated prefix (through AAA) but without any guarantee as my BRAS could change if they need to redesign their network.
And for having worked on DHCP-PD on low cost CPE code, this is indeed tricky because all low cost CPE (or at least most) rely on Linux and there is little interconnection between the several buggy DHCPv6 clients and RADVD or quagga or ...
PS: thanks for your post as usual :-)
RADIUS: Unsupported  5 RADIUS: 4C 41 42 [ LAB]