DHCPv6
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) is a network protocol that provides a framework for hosts and routers to dynamically obtain IPv6 addresses and other configuration parameters required for operation on an IPv6 network.[1] It enables both stateful address assignment, where the DHCPv6 server directly manages address allocation, and stateless configuration, which can complement Stateless Address Autoconfiguration (SLAAC) by delivering additional options like DNS server addresses.[1] Developed by the Internet Engineering Task Force (IETF), DHCPv6 operates on a client-server model, using UDP ports 546 (client) and 547 (server), and supports communication via multicast addresses such as ff02::1:2 for server discovery on the local link.[1] Unlike its IPv4 counterpart (DHCP), DHCPv6 is a distinct protocol without backward compatibility, emphasizing IPv6-specific features like prefix delegation for routers to assign subnets to downstream interfaces.[1] Key message types include Solicit (for server discovery), Advertise (server responses), Request (client requests), and Reply (server grants), typically exchanged in a four-message sequence, though a two-message exchange (Solicit/Reply) is possible for rapid configuration.[1] Relay agents extend DHCPv6 across routed networks by encapsulating messages in Relay-forward and Relay-reply types, appending link-specific information like interface identifiers.[1] Configuration data is conveyed through extensible options, such as the Identity Association for Non-temporary Addresses (IA_NA) for client addresses, Identity Association for Temporary Addresses (IA_TA) for privacy-enhanced temporary addresses, and Identity Association for Prefix Delegation (IA_PD) for routing scenarios.[1] Security is enhanced via authentication options, including Reconfigure Key Authentication Protocol (RKAP), while status codes provide feedback on operations like address declines due to duplicates.[1] The current specification, RFC 8415 (November 2018), obsoletes the original RFC 3315 (2003) and incorporates updates from related standards, ensuring a unified and robust protocol for modern IPv6 deployments.[1]Introduction
Overview
DHCPv6, or Dynamic Host Configuration Protocol for IPv6, is a network protocol that enables DHCP servers to dynamically assign IPv6 addresses, prefixes, and other configuration parameters to IPv6 nodes, facilitating automated network setup.[2] Introduced in RFC 3315 in July 2003, it serves as the IPv6 adaptation of the original DHCP protocol, providing flexibility for reusable address allocation and extensible options for additional parameters.[2] In IPv6 networks, DHCPv6 supports both stateful and stateless operational modes to meet diverse configuration needs. The stateful mode handles full address assignment and tracks client states, while the stateless mode delivers only non-address configuration details, such as DNS server information, and works alongside IPv6 Stateless Address Autoconfiguration (SLAAC) as defined in RFC 4862.[2] This dual-mode approach allows networks to balance centralized management with decentralized autoconfiguration. DHCPv6 addresses IPv6's design choice to eliminate broadcast messaging by using multicast addresses for discovery and unicast or anycast for direct communication between clients, relays, and servers.[2] Its key benefits include minimizing manual intervention in device setup, supporting plug-and-play connectivity for diverse IPv6 hosts, and seamlessly integrating with core IPv6 features to enhance network scalability and efficiency.[2] The protocol has since been updated and obsoleted by RFC 8415 in November 2018, incorporating refinements while preserving its foundational role.[3]Background and Motivation
The development of DHCPv6 emerged as part of the broader effort to create protocols supporting IPv6, which addressed key limitations of IPv4 such as the exhaustion of its 32-bit address space by introducing a 128-bit addressing scheme capable of supporting vastly more devices. Unlike IPv4, IPv6 eliminated broadcast mechanisms in favor of multicast for efficiency in larger networks, necessitating a redesigned dynamic configuration protocol that could operate without relying on broadcasts for client discovery and message propagation. These fundamental changes in IPv6's architecture, initiated through IETF discussions in the mid-1990s, required a new protocol to handle address assignment and parameter distribution in environments with potentially trillions of addresses and no inherent broadcast support. A primary motivation for DHCPv6 was to complement IPv6's built-in Stateless Address Autoconfiguration (SLAAC), which relies on Router Advertisements from Neighbor Discovery (ND) to enable hosts to self-configure addresses autonomously. While SLAAC provides simplicity and stateless operation, it lacks centralized control over address allocation, DNS server assignment, and other network parameters, creating a need for a stateful mechanism to enable administrators to manage configurations uniformly across large-scale deployments. DHCPv6 thus fills this gap by offering dynamic, server-mediated assignment of IPv6 addresses and options, supporting scenarios where policy enforcement or integration with existing management systems is essential, even as IPv6's address abundance reduces the urgency of address conservation seen in IPv4. The protocol's development began with early IETF drafts in the Dynamic Host Configuration (DHC) Working Group during the late 1990s, including initial proposals like "Options for DHCPv6" in November 1995 and subsequent "DHCPv6" drafts that evolved through iterations addressing IPv6-specific requirements. Formalization accelerated around 2000 within the DHC WG, which extended its charter from IPv4 DHCP to IPv6, culminating in the publication of RFC 3315 as a Proposed Standard in July 2003, defining the core DHCPv6 specification. This timeline aligned with the maturation of IPv6 standards, such as RFC 2460 in 1998, ensuring DHCPv6 integrated seamlessly with ND protocols for router discovery and address configuration.[4][5][6][7] Adoption of DHCPv6 has been gradual, hampered by the overall slow transition to IPv6, which reached approximately 45% global deployment as of November 2025 due to compatibility issues, transition costs, and the sufficiency of SLAAC for many basic use cases.[8] Integrating DHCPv6 with ND protocols presented additional challenges, as networks had to balance stateful DHCPv6 for managed environments against ND's stateless mechanisms, often requiring hybrid configurations during dual-stack IPv4/IPv6 phases. This slower rollout reflects broader IPv6 hurdles, including the need for updated infrastructure and training, delaying widespread reliance on DHCPv6 for centralized IPv6 management.Protocol Fundamentals
Differences from DHCPv4
DHCPv6 eliminates the use of broadcasts present in DHCPv4, instead employing link-local multicast addresses for server discovery and unicast for direct communication between clients and servers. Specifically, clients send Solicit messages to the All_DHCP_Relay_Agents_and_Servers multicast address (ff02::1:2), which reduces network overhead in IPv6 environments where broadcasts are inefficient due to the larger address space.[9] This shift aligns with IPv6's design principles, avoiding the flood of packets that broadcasts can cause on shared links.[10] Unlike DHCPv4, which operates independently for initial configuration, DHCPv6 integrates closely with IPv6 Neighbor Discovery (ND) to facilitate discovery and configuration. Clients rely on Router Advertisements (RAs) from routers—sent via ND—to determine whether to initiate DHCPv6 requests, using flags like the Managed-address Configuration (M) flag or Other Configuration (O) flag in the RA to trigger Solicit messages.[11] This dependency on ND contrasts with DHCPv4's standalone broadcast-based discovery, enabling a hybrid stateless/stateful configuration model that complements Stateless Address Autoconfiguration (SLAAC).[12] The message structure in DHCPv6 diverges from DHCPv4 by adopting a fully IPv6-native format without the BOOTP compatibility layer that DHCPv4 inherits from its predecessor. DHCPv6 uses a four-message exchange (Solicit, Advertise, Request, Reply) for address assignment, allowing multiple servers to advertise before the client selects one via unicast Request, avoiding the DHCPv4-style broadcast Request that can lead to conflicts; an optional two-message exchange (Solicit/Reply) is supported via the Rapid-Commit option.[13] This cleaner structure supports extensible options without legacy hardware address fields, focusing instead on IPv6-specific needs.[14] DHCPv6 expands address handling beyond DHCPv4's focus on individual host addresses to include prefix delegation and support for global IPv6 addresses, accommodating the hierarchical nature of IPv6 routing. It manages prefixes via Identity Association for Prefix Delegation (IA_PD) options, enabling routers to request and assign entire subnets, and supports temporary addresses through Identity Association for Temporary Addresses (IA_TA) to enhance user privacy by randomizing addresses periodically.[15] In contrast, DHCPv4 leases are limited to single addresses with no native prefix mechanism or privacy-oriented temporality.[16] Client identification in DHCPv6 mandates the use of a DHCP Unique Identifier (DUID), a flexible, up to 130-octet value that persists across network interfaces and reboots, replacing DHCPv4's reliance on the client hardware address (chaddr) field tied to MAC addresses.[17] DUIDs, conveyed in Client Identifier and Server Identifier options, enable stable bindings without hardware dependencies. Additionally, DHCPv6 relays operate differently from their DHCPv4 counterparts, using interface identifiers rather than subnet-specific forwarding to handle multi-link environments, avoiding the broadcast domain limitations of IPv4 relays.[18]Transport and Ports
DHCPv6 employs UDP as its transport protocol over IPv6 to exchange messages between clients, servers, and relay agents.[19] All DHCPv6 communications occur via UDP datagrams, enabling stateless and connectionless delivery suitable for dynamic configuration in IPv6 networks.[19] DHCPv6 designates specific UDP ports for message transmission: clients use source port 546 and destination port 547 when sending messages to servers or relay agents, while servers and relay agents use source port 547 and destination port 546 when responding to clients.[20] Clients listen for incoming messages on port 546, and servers or relay agents listen on port 547.[20] This port assignment facilitates directed communication and allows firewalls to permit DHCPv6 traffic by filtering on these well-known ports.[21] For discovery and initial exchanges, DHCPv6 utilizes IPv6 multicast addresses to reach multiple recipients efficiently without prior unicast address knowledge. Client messages destined for servers or relay agents, such as Solicit messages, are sent to the link-local multicast address FF02::1:2 (All_DHCP_Relay_Agents_and_Servers).[20] Relay agents forwarding client requests to servers may use the site-local multicast address FF05::1:3 (All_DHCP_Servers) if no specific server is known, though unicast is preferred when possible.[20] Server responses to clients are typically unicast to the client's address but can employ multicast in specific scenarios.[20] Relay agents play a crucial role in extending DHCPv6 across subnets by encapsulating client messages in Relay-Forward messages and server responses in Relay-Reply messages, both transmitted using UDP port 547 between the relay and server.[22] The relay agent includes the link-address (its address on the client-facing interface) and peer-address (the client's source address) in these messages to maintain context.[10] Initial DHCPv6 messages from clients employ link-local addresses as the source, with multicast destinations scoped to the link for locality.[23] Once a global unicast address is assigned, subsequent messages can use global addressing for end-to-end communication, improving scalability in routed networks.[23] Transport errors in DHCPv6, such as unreachable destinations, are handled through IPv6's ICMPv6 mechanisms, which provide feedback on delivery failures, while protocol-specific errors use embedded status codes rather than retransmission timers defined elsewhere.[24]Message Handling
Message Types
DHCPv6 employs a set of standardized message types to facilitate communication between clients, servers, and relay agents in IPv6 networks. These messages enable dynamic configuration of addresses, prefixes, and other parameters, with each type serving a distinct role in the protocol's operation. Unlike DHCPv4, DHCPv6 messages lack fixed fields for specific parameters and instead rely on a flexible options structure following the core header. Note that an update to the specification (draft-ietf-dhc-rfc8415bis, in RFC Editor Queue as of November 2025) incorporates errata, clarifies UDP port usage, and obsoletes certain options like IA_TA and server unicast.[25] The basic format of a DHCPv6 message begins with a 1-octet message type field, which identifies the message's purpose using numeric codes defined by the Internet Assigned Numbers Authority (IANA), followed by a 3-octet transaction ID for matching requests and responses, and then a variable-length options field containing configuration data.[22][26] This design allows for extensibility without rigid field allocations.[22]Core Unicast Messages
The protocol defines ten primary unicast message types for direct client-server interactions. The following table enumerates these messages, their codes, and roles:| Message Type | Code | Role |
|---|---|---|
| Solicit | 1 | Sent by a client to locate available DHCPv6 servers and initiate configuration discovery.[27] |
| Advertise | 2 | Sent by a server in response to a Solicit, advertising its availability and offering configuration parameters such as addresses or prefixes.[28] |
| Request | 3 | Sent by a client to request specific configuration parameters, typically in reply to an Advertise message during initial assignment.[29] |
| Confirm | 4 | Sent by a client to verify the validity of assigned addresses, often after detecting a link change or potential conflict.[30] |
| Renew | 5 | Sent by a client to the assigning server to extend the lifetimes of leased addresses or prefixes.[31] |
| Rebind | 6 | Sent by a client to any available server to extend lease lifetimes when the original server is unreachable.[32] |
| Decline | 9 | Sent by a client to inform the server that an assigned address is unusable, such as due to a detected duplicate address.[33] |
| Release | 8 | Sent by a client to release leased addresses or prefixes back to the server, relinquishing their use.[34] |
| Information-Request | 11 | Sent by a client to obtain configuration parameters without requesting address leases, supporting stateless DHCPv6.[35] |
| Reconfigure | 10 | Sent by a server to a client to initiate a configuration refresh or update, prompting the client to request new parameters.[36] |