DHCPv6 Prefix Delegation in Edge Routers

4 min read

In the course of developing the test suite for DHCPv6 prefix delegation, QA Cafe encountered a number of implementation issues that impact the functionality of IPv6 connectivity. Some of these potential implementation issues are discussed below.


Implementation Issues with IPv6 Prefix Delegation in DHCP

Now that IPv6 is moving out of the core and into residential networks, DHCPv6 prefix delegation has emerged as the leading technique to provision IPv6 CPE devices. In the IPv4 world, NAT is used to allow a single subscriber to share an IPv4 address with multiple devices. With IPv6, providers are looking to provision subscribers with an IPv6 prefix to allow each device in the residential network to have its own global address. DHCPv6 prefix delegation accomplishes this goal by allowing a CPE device to dynamically obtain an IPv6 prefix using DHCPv6. The IPv6 prefix is then used on the LAN side of the CPE device using either autoconf, DHCPv6, or a combination of both techniques.

The CDRouter IPv6 add-on supports prefix delegation configurations on the CPE and provides the testing framework needed to ensure a robust implementation. Beyond the DHCPv6 protocol interactions, the CPE device must maintain synchronization between the WAN side DHCPv6 server and its own LAN side DHCPv6 server and router advertisements. In the course of developing the test suite for DHCPv6 prefix delegation, QA Cafe encountered a number of implementation issues that impact the functionality of IPv6 connectivity. Some of these potential implementation issues are discussed below.


CDRouter IPv6

CDRouter IPv6 is an add-on for CDRouter that adds additional functionality and test cases around IPv6. Once enabled, CDRouter IPv6 provides an automated IPv6 testing environment for IPv6 CPE devices running dual IPv4 and IPv6. Similar to CDRouter with IPv4, the CDRouter IPv6 test setup is created by connecting CDRouter to both the LAN and WAN sides of a device under test. CDRouter maintains IPv6 clients on the LAN side of the device and provides IPv6 connectivity on the WAN side of the device using native IPv6 or tunnels. Within this test environment, a number of test modules can be executed to look at a range of IPv6 behavior including router discovery, neighbor discovery, ICMPv6, path MTU discovery, DHCPv6 with IA_NA and IA_PD, 6to4/6rd tunneling, IPv6 firewall, and IPv6 forwarding.


IPv6 Prefix not announced

For devices using DHCPv6 on the LAN to obtain a global IPv6 address, learning an IPv6 prefix in the router advertisement is not required. However, without any prefix information, all local unicast traffic must be sent to the default router. This usually ends up triggering an ICMPv6 redirect back to the LAN client. Unfortunately, not all devices consistently generate ICMPv6 redirects making this type of LAN configuration very inefficient and undesirable.* ### DHCPv6 DUID changes after reboot

The DUID is the DHCP Unique Identifier. DHCPv6 clients and servers use this to identity each other. RFC 3315 recommends that the DUID remain constant over time and not change across reboots, etc. QA Cafe has already encountered CPEs that are changing their DHCPv6 server DUID after each reboot. This leads to poorly performing DHCPv6 networks on the LAN side and over consumption of IPv6 addresses and prefixes on the WAN side. Each time you reboot the CPE device, the provider treats the new DHCPv6 request as a unique DHCPv6 host since the DUID has changed.* ### No DHCPv6 Solicit response on LAN if WAN is down

With DHCPv6 prefix delegation, the LAN side configuration is tied to learning an IA_PD on the WAN. If the WAN link is not established, no LAN side global address is available. This means that IPv6 connectivity on the LAN may be appear broken until the WAN is fully established. The use of Unique Local Addresses (RFC4193) is recommended to provision local global address that is not dependent on WAN connectivity. However, ULA is not widely implemented in current CPE devices.* ### DHCPv6 protocol okay, but packets are not forwarded

Unlike DHCPv4, DHCPv6 does not provision the default gateway for a client. CPE devices running DHCPv6 on the WAN should be learning and installing a default gateway based on router advertisements. However, in some DHCPv6 PD configurations, this behavior is inconsistent leaving CPE devices unable to forward IPv6 packets even though DHCPv6 appears to be working on the WAN and LAN.* ### Inconsistencies in learning DNS information on WAN

Most CPEs will request DNS information when running DHCPv6 on the WAN. However, when running DHCPv6-PD without requesting an IPv6 address, some devices leave out the DNS request options. In these configurations, DNS must be statically configured.* ### Lots of modes to test


Testing in CDRouter

The deployment model for residential IPv6 is evolving. CDRouter IPv6 helps with this evolution by providing the testing framework needed to quickly verify the IPv6 protocols at play in a residential IPv6 network. Use of CDRouter will help minimize potential implementation issues and lead to a smoother roll out of residential IPv6.