Suppose you had a problem, you want to use a provider assigned globally unique IPv6 address space for your network’s clients and you’d like to do this as dynamically as possible because either you can’t guarantee that the provider won’t change the address block on you or you just want to use a standardized template on your network equipment. How can you accomplish this? A cool feature added to DHCPv6 called Prefix Delegation (PD).

The basic idea is that the ISP allocates a larger IPv6 address block to the customer's router, and the customer's router then further subdivides this block into smaller subnets and assigns them to different segments of the local network. This allows for efficient utilization of the IPv6 address space and simplifies network management.

Of course, this feature set isn’t limited to only being used by ISP for clients. You could certainly choose to use this in an enterprise. Say I want to maintain a standard template across my WAN sites and assign interface addresses via a centralized server. If you wanted to centralized the management of the PD pools further, you can use DHCPv6 relaying or manage the pools using AAA.

Here's a configuration example using common networking devices, such as a router from the ISP and a customer-premises router. In this example, the ISP assigns a /48 IPv6 address block to the customer's router and the customer-premises router delegates /64 subnets to its LAN interfaces.

Setup:

• ISP router Gig1 Interface: 2001:db8:55:22::1/64

• Assigned Prefix Pool: 2001:db8:2200::/40

• Customer-premises router LAN interface: GigabitEthernet1

• LAN subnets: 2001:db8:2200:1::/64, 2001:db8:2200:2::/64, ...

Configuration steps:

• ISP Router Configuration:

1. Enable IPv6 routing

2. Configure the DHCPv6 prefix pool and the size of prefixes that we want to assign to customers.

3. Configure the interface facing the customer’s router with an IPv6 address and enable it to act as a DHCPv6 server.

4. Assign the /48 IPv6 prefix to the WAN interface of the customer's router using DHCPv6 Prefix Delegation.

• Customer-Premises Router Configuration:

1. Enable IPv6 routing

2. Configure the WAN interface to obtain an address using SLAAC

3. Configure the WAN interface to obtain the IPv6 prefix from the ISP using DHCPv6 Prefix Delegation.

4. Assign the LAN interface addresses using the obtained prefix.

DHCPv6 Process

You may be familiar with the message types used in DHCP(v4) by remembering the acronym DORA. DORA, or Discover, Offer, Request, Acknowledge is the back and forth messages between a DHCP client and server.

1. A clients sends a Discover message to the broadcast MAC address (FF:FF:FF:FF:FF:FF)

2. The DHCP server responds with a unicast Offer message to the client with a potential IP address

3. The client responds with a unicast Request message to the server asking for the address sent in the Offer message

4. The server responds to the client Acknowledging that it has been leased the IP address to the client

This process may seem a little bit redundant at first glance, but there’s good reason why it’s so verbose, and that is for three main reasons

• There may be multiple DHCP servers on a LAN segment without knowledge of each other

• The client may not want the IP address in the offer message for one reason or another and can send a NAK (Negative Acknowledgement)

• The client could have been removed from the network before receiving the offer and we don’t want to unnecessarily tie up unused IP addresses

Now that we’ve quickly reviewed the DHCPv4 process, let’s understand the DHCPv6 process. It’s largely the same but with some tweaks to the message names.

1. Router Advertisement - The client receives a router advertisement packet from the router telling it that either the managed-config-flag or other-config-flag have been set

2. Solicit - The client sends a solicit message to the “All_DHCP_Relay_Agents_and_Servers” link-local multicast group of FF02::1:2 UDP 547

3. Advertise - The server sends a potential IPv6 address (or option information) to the client on UDP 546

4. Request - The client confirms that it wants the IPv6 address from the server

5. Reply - The server acknowledges that the lease has been created for the client

The basic premise is the same between DHCPv4 and DHCPv6, with different names. Prefix Delegation information is communicated in the Advertise message. Annoyingly, the simple to remember acronym DORA is now replaced with the less elegant SARR process.

Rapid Commit

One interesting change with DHCPv6 though is the introduction of the Rapid commit process. The client is given the option to skip the last two steps, of the previously discussed exchange, the request and the reply. The client sends a solicit message that indicates that it’s willing to accept an IPv6 address from the server and the server responds with an Advertise message back providing the address. The client does not continue with a request message but instead immediately starts to use the provided address. Both the client and the server have to agree to use the rapid commit option.

If you have multiple servers prepared to use rapid commit, all but the server who’s response was accepted by the client will have incorrect lease associated with that client. Some DHCP servers may mitigate against this with a process between the servers but this could cause an issue with incorrect DNS entries if you DHCP servers are configured to update DNS servers.

Rapid commit is enabled with the keyword “rapid-commit” after the interface subcommand “ipv6 dhcp server…” and “ipv6 dhcp client pd…”.

ISP Router Configuration

Customer Router Configuration

Customer Router Verification

Once configuration has been completed for both the ISP and Customer router, let’s use a couple of show commands to verify our work. First up is to check that IPv6 addresses are being assigned to the interfaces that we expect. Below is the output of “show ipv6 interface brief” that shows an EUI-64 address assigned to the GigabitEthernet1 interface that it learned via SLAAC. Additionally, the GigabitEthernet2 and GigabitEthernet3 interfaces have addresses configured using the PD assigned prefix of “2001:DB8:2200::/48”.

You can investigate the DHCPv6 information with “show ipv6 dhcp interface”. The output of this command will show us the prefix assigned from the server, the lifetime information, and the prefix name, or the variable that we’ve assigned to it.

The last step in verifying the Customer1 router’s configuration is correct is to check the routing table. The output of “show ipv6 route” gives us a default route (::), a static route for the 2001:db8:2200::/48 prefix that goes to Null0, and the subnets that were assigned to the LAN interfaces GigabitEthernet2 and GigabitEthernet3.

The default route is learned via the ICMP Neighbor Discovery (ND) Protocol also known as Stateless Address Autoconfiguration. You’ll note that the next hop address is a link-local address (FE80::) rather that the GUA that is assigned to the interface.

ISP Router Verification

A couple of verification commands from the ISP point of view, we can verify that the interface that we expect to be in server mode (GigabitEthernet1) is correct and that the DHCPv6 pool is correct. Below is the output for “show ipv6 dhcp interface”, “show ipv6 dhcp pool”, and “show ipv6 local pool”.

The “show ipv6 dhcp binding” command will let us see which prefix has been assigned to which customer router.

Lastly, we can check the IPv6 routing table to see that the prefix 2001:db8:2200::/48 is present and shows up as a static route with the next-hop address of our Customer1 routers GigabitEthernet1 interface. Just like the routing table on the Customer1 router, the static route for the assigned /48 has a link-local next-hop address.

Packet Capture

Here’s a packet capture from my lab that contains the DHCP prefix delegation between the ISP router (FE80::5054:FF:FE12:74AD) and the Customer1 router (FE80::5054:FF:FE01:3B88).

DHCPv6 Relay

In larger environments, it makes more sense to deploy DHCP onto centralized servers and simply relay the messages to the server from the default-gateway of the subnet. This centralizes management and makes it easier to make network-wide configuration changes. Additionally, it provides a single logging point for all clients and can allow you to enforce a security policy if needed.

The IPv4 feature-set was known on Cisco devices as “IP helper”, however, Cisco has renamed the feature to “DHCP Relay” in IPv6 to more accurately reflect its purpose. In addition to end-device address assignment, DHCP relay can be used for prefix-delegation.

To configure DHCPv6 relay, configure the command under the interface facing the clients. It’s generally easier to use a global unicast address (GUA) but you can also use a link-local address to forward RA solicitation messages to, but you must specify the outgoing interface if you do so.

DHCP Relay Verification

You can verify the configuration of the DHCP relay with the command “show ipv6 dhcp interface”.