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 for long periods of time.

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 ;)

More information

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.

9 comments:

  1. But what do you do for CPE which doesn't do / support PD? if they don't ask then they never get a site prefix routed to them?
  2. That's a deep swamp you are heading there :)

    Jan
  3. Do you think it's safe to assume we're only going to have 6204 compliant CPE which is always asking for PD?
  4. The missing part is how fast the clients will replace their global IP address in case the user will connect to a different BRAS.

    Nitzan
    Replies
    1. You have to specify that with the lifetime in the DHCP pool.
    2. If I understand it correctly the problem is not the BRAS pool its the CPE.
      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.

      Nitzan
    3. You're absolutely right - the problem is CPE's inability to clear delegated prefix after PPPoE session fails.

      As for 6204bis - hope springs eternal, but the historical data points in vendor reality indicate otherwise.
  5. I was unaware that the delegated prefix was assumed to be static in theory...

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

    -éric

    PS: thanks for your post as usual :-)
  6. I was wondering if anyone has successfully implemented the Delegated-IPv6-Prefix-Pool in PPPoE environment. When I pass this attribute to my ASR1002x on IOS-XE 16.3.2, the RADIUS debug says unsupported. Any help is really appreciated.

    sample debug:
    RADIUS: Unsupported [171] 5 RADIUS: 4C 41 42 [ LAB]
Add comment
Sidebar