Cassidy Larson from InfoWest sent me an interesting challenge: using the sample configurations I provided in the Building Large IPv6 Service Provider Networks webinar he was getting weird DHCPv6 errors when a residential CPE device requested a delegated prefix from the BRAS router (before moving forward, have to mention how nice it is to see an US ISP deploying IPv6 ;).

The symptoms

He was using a configuration very similar to this one with local PPPoE address pool and local prefix delegation pool ...

Simple IPv6-over-PPPoE configuration with local pools

ipv6 dhcp pool Clients
 prefix-delegation pool DhcpPool
 address prefix FEC0:1:23FF:FFFF::/64
 dns-server FEC0::CCCC:4
 domain-name example.com
!
interface Virtual-Template10
 mtu 1480
 peer default ipv6 pool PPP
 ipv6 enable
 ipv6 nd other-config-flag
 no ipv6 nd ra suppress
 ipv6 dhcp server Clients
 no keepalive
 ppp authentication pap
 ppp direction callin
!
ipv6 local pool DhcpPool FEC0:1:2200::/40 56
ipv6 local pool PPP FEC0:1:2300::/48 64

... and observing DHCPv6 debugging printouts similar to the one below (reproduced in my lab):

DHCPv6 SOLICIT packet

IPv6 DHCP: Received SOLICIT from FE80::C804:7FF:FEE6:8 on Virtual-Access2.1
IPv6 DHCP: detailed packet contents
  src FE80::C804:7FF:FEE6:8 (Virtual-Access2.1)
  dst FF02::1:2
  type SOLICIT(1), xid 2333403
  option ELAPSED-TIME(8), len 2
    elapsed-time 0
  option CLIENTID(1), len 10
    00030001CA0407E60008
  option ORO(6), len 4
    DNS-SERVERS,DOMAIN-LIST
  option IA-NA(3), len 12
    IAID 0x000B0001, T1 0, T2 0

DHCPv6 request processing

IPv6 DHCP: Using interface pool Clients
IPv6 DHCP: Binding for IA_NA 000B0001 not found
IPv6 DHCP: Allocating IA_NA 000B0001 in binding for FE80::C804:7FF:FEE6:8
IPv6 DHCP: Freeing IA_NA 000B0001 from binding for FE80::C804:7FF:FEE6:8
IPv6 DHCP: Binding for IA_NA 000B0001 not found

DHCPv6 ADVERTISE response

IPv6 DHCP: Sending ADVERTISE to FE80::C804:7FF:FEE6:8 on Virtual-Access2.1
IPv6 DHCP: detailed packet contents
  src FE80::C800:7FF:FEE5:8
  dst FE80::C804:7FF:FEE6:8 (Virtual-Access2.1)
  type ADVERTISE(2), xid 2333403
  option SERVERID(2), len 10
    00030001CA0007E50008
  option CLIENTID(1), len 10
    00030001CA0407E60008
  option IA-NA(3), len 31
    IAID 0x000B0001, T1 0, T2 0
    option STATUS-CODE(13), len 15
      status code NOADDRS-AVAIL(2)
      status message: NOADDRS-AVAIL
  option DNS-SERVERS(23), len 16
    FEC0::CCCC:4
  option DOMAIN-LIST(24), len 13
    example.com

A bit of a background

DHCPv6 is used for (at least) three purposes in IPv6 access networks:

• To assign IPv6 addresses to DHCPv6 clients (IA-NA option);
• To pass DNS information (DNS server address, default domain) to the clients (DNS-SERVERS and DOMAIN-LIST options);
• To delegate prefixes to CPE routers (IA-PD option).

The use of DHCPv6 for the first two purposes SHOULD be controlled by the flags sent by the routers in Router Advertisement messages:

• If the M flag is set, hosts COULD use DHCPv6 to get their addresses;
• If the O flag is set, hosts COULD use DHCPv6 to get other information.

You cannot force an end host to use DHCPv6 by setting the M flag in the RA messages (but you could prevent an end hosts from using SLAAC by not advertising SLAAC-able prefixes in RA messages).

Based on the information Cassidy sent me some CPE devices ignore the M flag as well; virtual access template was configured with ipv6 nd other-config-flag and debugging printouts indicated M flag was not set in RA messages:

Dump of RA packet

ICMPv6-ND: Request to send RA for FE80::C800:7FF:FEE5:8
ICMPv6-ND: Setup RA from FE80::C800:7FF:FEE5:8 to FF02::1 on Virtual-Access2.1
ICMPv6-ND: Setup RA common:Other stateful configuration
ICMPv6-ND:  MTU = 1480
ICMPv6-ND:     prefix = FEC0:1:2300::/64 onlink autoconfig
ICMPv6-ND:           2592000/604800 (valid/preferred)
ICMPv6: Sent R-Advert, Src=FE80::C800:7FF:FEE5:8, Dst=FF02::1

I used ipv6 address dhcp on a Cisco IOS-based CPE to force this behavior; Cassidy was using a Linksys CPE on which he could only enable or disable IPv6.

Where’s the problem?

Depending on the DHCPv6 client code in the CPE, you could observe one of these behaviors:

• CPE gets annoyed when it can’t get an IPv6 address with DHCPv6 and never asks for the delegated prefix. User has no IPv6 connectivity (this is how my Cisco IOS release behaves ... but then I forced it to use DHCPv6);
• CPE asks for IPv6 address and delegated prefix in the same request, but never completes the DHCPv6 address allocation because it’s upset by the STATUS-CODE in IA-NA option (yeah, you really couldn’t expect half of your request to fail, could you?). Seems the Linksys router Cassidy is using is in this category;
• CPE survives the partial DHCPv6 response failure, but still doesn’t use SLAAC on the outside interface and thus never gets a globally routable outside IPv6 address. This shouldn’t be a big problem unless the customer tries to do a ping from the CPE (or configures NAT66 ;).

Anyhow, history shows we cannot rely on CPEs doing the right thing (after all, why would a CPE use DHCPv6 IA-NA if the BRAS never tells it to do so), so we have to cope with whatever is thrown at us.

Can we fix it? Yes we can!

DHCPv6 server in Cisco IOS was doing IA-PD prefix delegation for a long time. They added IA-NA address allocation somewhere in the 15.x M&T train, so it’s pretty easy to add an address-prefix to ipv6 dhcp pool:

IPv6 DHCP pool with address and prefix delegation

ipv6 dhcp pool Clients
 prefix-delegation pool DhcpPool
 address prefix FEC0:1:23FF:FFFF::/64
 dns-server FEC0::CCCC:4
 domain-name example.com

This configuration would work great on a Metro Ethernet or a WiFi subnet, but not so well in PPPoE environments – every PPPoE session is a separate virtual access interface and thus needs a separate IPv6 subnet for clients who prefer to do SLAAC (or don’t have DHCPv6 IA-NA support at all).

To support all possible (and impossible) combinations of client hosts and CPEs, you’d have to:

• Assign a /64 prefix to every PPPoE link to support hosts expecting to use SLAAC;
• Support prefix delegation and assign another prefix (anything from /48 to /64 depending on your L8-10 persuasions) to CPEs requesting the prefix;
• Assign an IPv6 address from IA-NA pool to clients or CPEs who want to use DHCPv6 for address assignment.

However, it’s impossible to make the IPv6 address CPE gets from the IA-NA pool be in the dynamic subnet allocated to each PPPoE link. To make the CPE device reachable from the IPv6 Internet, you need another static route (similar to the one generated by prefix delegation) ... and the ipv6 dhcp iana-route-add global configuration command is here to help you. After configuring it, the BRAS generates static /128 routes for DHCPv6-allocated IPv6 addresses.

IPv6 routes on virtual access interface

PE-A#show ipv6 route interface vi2.1 | begin ^[SC]_
S   FEC0:1:2200::/56 [1/0]
     via FE80::C804:7FF:FEE6:8, Virtual-Access2.1
C   FEC0:1:2300::/64 [0/0]
     via Virtual-Access2.1, directly connected
S   FEC0:1:23FF:FFFF:C1D7:32FE:F4C7:DF8C/128 [1/0]
     via FE80::C804:7FF:FEE6:8, Virtual-Access2.1

The final gotcha

And thus it seems our problem is solved ... unless you’re a lucky owner of an ASR or any other Cisco IOS device running 15.2S software – they accept ipv6 dhcp iana-route-add configuration command but never generate the /128 static route. Neat, isn’t it? Who would ever need that in a service provider environment?

Related webinars

You’ll find detailed description of DHCPv6 address allocation and prefix delegation mechanisms, and related design, deployment and configuration guidelines in the Building Large IPv6 Service Provider Networks webinar (you can get it as individual recording, or as part of the IPv6 trilogy or yearly subscription).