TheDynamic Host Configuration Protocol version 6 (DHCPv6) is anetwork protocol for configuringInternet Protocol version 6 (IPv6)hosts withIP addresses,IP prefixes, and other configuration data required to operate in an IPv6 network. It is not just the IPv6 equivalent of theDynamic Host Configuration Protocol forIPv4.

IPv6 hosts may automatically generate IP addresses internally usingstateless address autoconfiguration (SLAAC), or they may be assigned configuration data with DHCPv6, or both.

DHCPv6 and SLAAC are complementary services. Unlike theNeighbor Discovery Protocol (NDP) used by SLAAC, DHCPv6 can not only assign single unicast addresses, but also entire prefixes inprefix delegation. For example, an ISP's router can provide a prefix to a customer's router via DHCPv6 so that the customer's router can assign addresses to the customer's many devices via either DHCPv6 or SLAAC. This allows routers for residential networks to be configured with no operator intervention.

DHCPv6 also allows the distribution of information other than what SLAAC/NDP provides on a given network: this works even without DHCPv6 managing the distribution of network addresses. The standard method for a SLAAC/NDP network to hand outDomain Name System (DNS) server settings is via setting a flag in the Router Advertisement (RA) message telling the clients to ask for such settings over DHCPv6,^[1]: §4.2 although this specific use case is being replaced via a nonstandard extension of the RA message.^[2] Still, there remains a plethora of DHCPv6 options for providing additional information not handled by SLAAC/NDP, much like the wide range of information conveyed by legacy DHCP options.^[3]

Finally, DHCPv6 also offers a stateful approach, which provides more control over SLAAC's stateless approach.

DHCPv6 usesIPv6 multicast addresses to enable communication between clients, relay agents, and servers when unicast addresses are not yet known. RFC 9915 defines two well-known multicast groups for this purpose.

All DHCPv6 servers and relay agents must join the appropriate multicast groups on relevant interfaces.

Notes

• Link-local multicast traffic (ff02::1:2) is never forwarded beyond the local link.
• Site-local multicast (ff05::1:3) requires the relay agent to have an address with sufficient scope to reach servers within the site.
• Multicast support is mandatory for correct DHCPv6 operation.

Clients listen for DHCP messages onUDP port 546. Servers and relay agents listen for DHCP messages on UDP port 547.^[4]: §7.2

The DHCP unique identifier (DUID) is used by a client to get an IP address from a DHCPv6 server. It has a 2-byte DUID type field, and a variable-length identifier field up to 128 bytes. Its actual length depends on its type. The server compares the DUID with its database and delivers configuration data (address, lease times, DNS servers, etc.) to the client.

Four DUID types are identified:^[4]: §11

Due to the fact that it is difficult to manage multiple identifiers in a dual-stack environment, and the fact that DUIDs are simply not optimal for some situations,RFC 6939 was released, giving a way to identify a host based on itsMAC address. It defines a way for a DHCPv6 relay to pass that information to a DHCPv6 server.

In this example, without rapid-commit present, the server's link-local address isfe80::0011:22ff:fe33:5566 and the client's link-local address isfe80::aabb:ccff:fedd:eeff.

• Client sends asolicit from [fe80::aabb:ccff:fedd:eeff]:546 to multicast address [ff02::1:2]:547.^[4]: §14
• Server replies with anadvertise from [fe80::0011:22ff:fe33:5566]:547 to [fe80::aabb:ccff:fedd:eeff]:546.
• Client replies with arequest from [fe80::aabb:ccff:fedd:eeff]:546 to [ff02::1:2]:547.
• Server finishes with areply from [fe80::0011:22ff:fe33:5566]:547 to [fe80::aabb:ccff:fedd:eeff]:546.

DHCP messages utilize a fixed-format header followed by a variable-format options area.

All values in the message header and options are encoded innetwork byte order.

msg-type: 8 bits

Identifies the DHCP message type

transaction-id: 24 bits

Value to synchronize server responses to client messages. Random number generated by client.

Options: Variable bits

Options have up to three fields: Option-code (2 octet), Option-Length (2 octet), Option-Data (variable). Depending on Option-code value, the next two fields may be set. Option-Length indicates the total length of the option, and Option-Data contains data associated with the option, if applicable.

Message types

This table lists the DHCPv6 message types.

Option codes

This table lists some of DHCPv6 Option codes. Full list can be for herIANA DHCPv6 Option Codes

All devices participating in a DHCPv6 exchange^[4]: §11, whether acting as a client or a server, must possess a single DHCP Unique Identifier (DUID) to establish a persistent identity within the network. This identifier is carried in theOPTION_CLIENTID (1) andOPTION_SERVERID (2) fields to ensure that transactions remain consistent even if hardware interfaces are swapped or addresses are reassigned. The DUID is designed to be permanent across reboots and reconfigurations, acting as the definitive anchor for the server’s binding database and the client’s server-selection logic.

DUID-LLT (Type 1)^{[4]: §11.2} consists of:

• DUID type (1)
• Hardware type (IANA-assigned)
• Time value (seconds since 00:00 UTC, 1 January 2000, modulo 2³²)
• link-layer address

The time component reduces the likelihood of collisions if the same link-layer address is reused on another device. Devices using DUID-LLT must store the generated identifier in stable, non-volatile storage and continue using it even if the original network interface is removed.

This type is recommended for general-purpose computing devices such as desktops, laptops, and printers, that provide writable persistent storage.

DUID-EN (Type 2)^{[4]: §11.3} is assigned by the device vendor and consists of:

• DUID type (2)
• Vendor’s IANA-assigned Private Enterprise Number
• Vendor-defined unique identifier

The identifier must be unique per device and stored in non-volatile storage. This type is commonly assigned during manufacturing or at first boot in virtualized environments.

DUID-LL (Type 3)^{[4]: §11.4} consists of:

• DUID type (3)
• Hardware type
• link-layer address

Unlike DUID-LLT, no time value is included. This type is intended for devices with a permanently attached network interface and no writable persistent storage. It should not be used if the permanence of the interface cannot be guaranteed.

DUID-UUID (Type 4)^{[4]: §11.5} uses a 128-bit UUID as its identifier.

DUID-UUID consists of:

• DUID type (4)
• Universally Unique Identifier

Its usage and UUID selection rules are defined in RFC 6355. This type is suitable for devices that already store a UUID in firmware or platform configuration.

TheOption Request Option (ORO)^{[4]: §21.7}, identified byOPTION_ORO (6), is the mechanism used by a DHCPv6 client to inform the server which configuration parameters it is interested in receiving. Rather than the server blindly pushing all available data, the client provides a list of option codes within the ORO to tailor the response to its specific needs.

The Option Request Option is defined byIANA DHCPv6 Option Codes

Client Responsibility: The client MUST include an ORO in messages like Solicit, Request, Renew, and Rebind if it requires specific information (such as DNS recursive name servers or domain search lists).

Server Responsibility: The server uses the ORO as a guide. It should include the requested options in its response, provided those options are configured and appropriate for the client's link.

Common DHCPv6 Option Request Codes

In a standard network deployment, a client typically includes the following option codes in itsOPTION_ORO (6) to ensure a functional IPv6 environment:

• RFC 8415, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" - Obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, RFC 7550.
• RFC 3319, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers"
• RFC 3646, "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
• RFC 4704, "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option"
• RFC 5007, "DHCPv6 Leasequery" support
• RFC 6221, "Lightweight DHCPv6 Relay Agent" (LDRA) - Updates RFC 3315, Errata
• RFC 6355, "Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)"
• RFC 6939, "Client Link-Layer Address Option in DHCPv6"
• RFC 7653, "DHCPv6 Active Leasequery"

• Comparison of DHCP server software
• Dynamic Host Configuration Protocol (DHCP)
• Neighbor Discovery Protocol, which also supportsDNS Configuration
• Prefix delegation, which allows a DHCPv6 client to obtain a whole prefix.

Wikiversity has learning resources about DHCPv6

• IANA DHCPv6 Parameters
• IPv6 Intelligence: DHCPv6, comparison of DHCPv6 packages and implementations (Last updated: April, 2009)
• IPv6 Ready: DHCPv6, list of IPv6 Phase II Certified DHCPv6 implementations (Last updated: December, 2012)

• IPv6
• Application layer protocols

• Articles with short description
• Short description matches Wikidata