DHCPv6 Provisioning

ISPs have been performing device provisioning in the IPv4 world using DHCPv4 for many years. With the advent of IPv6, and DHCPv6 now being deployed on networks, many of the concerns about DHCPv6 provisioning mirror those from DHCPv4. This document aims to map the provisioning details of DHCPv4 into the DHCPv6 world.

Address Allocation

In order to obtain an address in IPv4, you had to use DHCPv4. IPv6 defines a lower-level protocol called Stateless Address Autoconfiguration (SLAAC). While this protocol is sufficient for a device to find or select its own IP address and locate its default router, it doesn’t provide sufficient configuration information to fully complete the provisioning process. DHCPv6 is used to provide an IP address, as well as other configuration details necessary to complete the full provisioning process in IPv6.

DHCP Packet Relay

In DHCPv4, the client sends its first communications as a broadcast onto the network. This broadcast is picked up by a DHCP relay agent (which may also be known as a BOOTP relay agent, or perhaps a cable helper). This agent receives the broadcast and makes certain modifications to the message and then (generally) unicasts it to the DHCPv4 server(s). A similar operation occurs on the path back from the DHCPv4 server.

For the future communications of the device to renew its IP address, the device will unicast the renewal to the DHCP server. Some of the router vendors just route the unicast packet like any other packet on the network. Other router vendors will promiscuously sniff for these DHCP packets and will intercept them and treat them as if they were broadcast and picked up by a relay agent on the router. This makes it potentially unreliable as to whether the router will have the opportunity to modify every DHCP packet that crosses it.

In DHCPv6, the client sends its first communications as a multicast message onto the network. Much like DHCPv4, this multicast is received by a relay agent. But in DHCPv6 it does not modify the client packet and forward it along to the DHCP servers. Instead, the client packet is wrapped by a new “relay-forward” packet to give the relay an opportunity to add additional information to this relay-forward packet. The DHCPv6 server will be able to clearly distinguish data that is client-supplied data (and thus may be suspect) from data supplied by a relay agent (which is more likely to be a trusted device).

Screen Shot 2015-03-26 at 3.50.00 PMIt is also possible that the single DHCPv6 packet may travel through multiple relays. Each one will add its own relay-forward wrapper over the previous one. When the DHCPv6 server responds, it constructs the client packet and wraps it the same number of times as the relays that had to process the original packet.

The reply will retrace its path through the same set of relays. Each relay will unwrap one level of relay-reply and hand the encapsulated packet to the next relay (which in turn unwraps the next relay-reply and hands the packet along) until the last relay unwraps the final client-destined packet and sends it to the client.  Unless otherwise configured, the renewal traffic from the DHCPv6 client will travel in exactly the same way as the original packet. Thus in DHCPv6, each relay always has the opportunity to add its information to every DHCPv6 packet.

Other Configuration Details

In DHCPv4, the other configuration details necessary for provisioning are carried in DHCP Options. DHCPv6 has the same concept. Only that the information that is supplied by the relays is more clearly separated from the information that is supplied by, or to, the client. The following table shows where information is passed in DHCPv4 vs. DHCPv6 for a DOCSIS 3.0 based provisioning system:




TFTP Server

Option 66, or the siaddr field (RFC 2132/RFC 2131)

Option 17, CableLabs, Sub-option 32 (CL-SP-CANN-DHCP-Reg-I10-130808)

TFTP File Name

Option 67, or the filename field (RFC 2132/RFC 2131)

Option 17, CableLabs, Sub-option 33 (CL-SP-CANN-DHCP-Reg-I10-130808)

ToD Server

Option 4 (RFC 2132)

Option 17, CableLabs, Sub-option 37 (CL-SP-CANN-DHCP-Reg-I10-130808)

Remote ID

Option 82, Sub-option 2 (RFC 3046)

From the deepest Relay-Forward packet that supplied either of:

Option 17, CableLabs, Sub-option 1026 (CL-SP-CANN-DHCP-Reg-I10-130808)


Option 37, CableLabs (RFC 4649)


Option 12 (RFC 2131)

Option 39 (RFC 4704)

Domain name

Option 15 (RFC 2131)

Option 39 (RFC 4704)

DNS Servers

Option 6 (RFC 2131)

Option 23 (RFC 3646)

Link Selection (in order of preference)

Option 82, Sub-option 5 (RFC 3527)

Option 118 (RFC 3011)

giaddr (RFC 2131)

The link-address field from the deepest Relay-Forward packet that is not all zeros. (RFC 6221)

Client MAC Address

chaddr (RFC 2131)

Option 79 from the deepest Relay-Forward packet (RFC 6939)


Option 17, CableLabs, Sub-option 36 (CL-SP-CANN-DHCP-Reg-I10-130808)

Cable Modem Capabilities

DOCSIS 3.0+: Option 125, CableLabs, Sub-option 5 (RFC 3925 + CL-SP-CANN-DHCP-Reg-I10-130808)

Previously: Encoded into Option 60 (CL-SP-CANN-DHCP-Reg-I10-130808)

Option 17, CableLabs, Sub-option 35 (CL-SP-CANN-DHCP-Reg-I10-130808)

Advanced Provisioning Options

DHCPv6 also offers more advanced provisioning features. In DHCPv6, it is possible for the provisioning system to provide an entire subnet to the client using prefix delegations. The client is then responsible for the provisioning of the further downstream clients. To find out more about DHCPv6 provisioning features, download our free ebook.

Glossary of Terms



DHCPv6 Prefix Delegation

A mechanism for assigning a network address prefix to a user site, configuring the user’s router with the prefix to be used for each LAN

Stateless Address Autoconfiguration (SLAAC)

A mechanism that enables an IPv6 host to generate its own IP address using a combination of locally available information and information advertised by routers


The sending of messages to a single network destination identified by a unique address


Communication between a single sender and multiple receivers on a network

  • Share: