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.