DHCPv6 Prefix Delegation, RADIUS and Shared Usernames

Jernej Horvat sent me the following question:

I know DHCPv6-based prefix delegation should be as stable as possible, so I plan to include the delegated prefix in my RADIUS database. However, for legacy reasons each username can have up to four concurrent PPPoE sessions. How will that work with DHCPv6 IA_PD?

Short answer: worst case, DHCPv6 prefix delegation will be royally broken.

In spite of this, things are not as gloomy as they seem. The reason this ISP allows up to four concurrent sessions for each username is simple: years ago DSL modems were annoyingly stupid, so their users terminated PPPoE sessions on the hosts, and it was quite likely that someone would have two or more hosts at home (today, some of the more creative users use this functionality for roaming within the ISP network).

Obviously the users starting PPPoE sessions on their hosts consumed more IPv4 addresses and BRAS resources than users with properly-configured CPEs, but let’s not chase that particular squirrel.

Also, remember that the CPE device has to trigger the DHCPv6 prefix delegation process with a DHCPv6 REQUEST packet. At that time, access server (BRAS) using old Cisco IOS software might send another RADIUS request; more recent software would already have the value of the delegated-IPv6-prefix RADIUS attribute and use that. However, the prefix is not delegated, and the corresponding static route not installed, until the CPE asks for it.

Summary: If you allow concurrent sessions for a single username, but only one of them is a CPE using DHCPv6, you won’t experience prefix delegation problems.


Regardless of the “it just might work” conclusion above, keep the following in mind:

  • If you’re using framed-IPv6-prefix RADIUS attribute (or equivalent Cisco AV-pair), you MUST limit the number of concurrent sessions to one.
  • If you’re using delegated-IPv6-prefix RADIUS attribute, you SHOULD limit the number of concurrent sessions to one.
  • If you allow concurrent sessions for a single username, you SHOULD use BRAS local pools for directly connected (/64) PPPoE prefixes and either BRAS local pools or central DHCPv6 (not RADIUS) server for delegated prefixes.
  • If you use BRAS local pools, you SHOULD use short lifetimes for delegated prefixes to ensure the CPE doesn’t get totally stuck if the BRAS reloads and forgets the prefixes it delegated

More information

You’ll find detailed description of DHCPv6, prefix delegation mechanisms, RADIUS integration, and corresponding design, deployment and configuration guidelines in 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.


  1. now i just need to figure out how to log [AAA] delegated IPs from BRAS's local pools.

    i hope that using radius attrib "Delegated-IPv6-Prefix" or "Framed-IPv6-Pool" does the trick...
  2. I've another question. Is "delegated-IPv6-prefix" supposed to bootstrap the per-user static? I had this working in 15.1S on ASR1K and suddenly it stopped working after upgrading. I now have to accompany each user with their own routing attributes as well as the delegation. Is this intentional? does anybody know?
    1. Assuming the CPE asks for the prefix through DHCPv6 IA_PD REQUEST it sounds like a bug to me.
  3. Thanks Ivan, it turns out, as you say, the client has to ask in order for us to create the per-user static. In the previous release we were running ,the client didn't have to ask, the per-user static was just automatically created, we then assumed we could just provision PD attr in RADIUS and it would cover all clients (those supporting PD and those not) , it seems when we went to the next release, the behaviour changed to "only install the per-user static if the client asks for it" so we've now started including the framed-ipv6-route attr along with the PD attr.
    Saying this, the latest build of the next (i.e after ours) release has reverted to the previous behaviour! perhaps it just doesn't have this new behaviour committed to it.
Add comment