IPv6 DHCP configuration starts with an architecture decision, not a server form. An IPv6 endpoint can learn network information from router advertisements, create addresses through Stateless Address Autoconfiguration, obtain addresses and prefixes from DHCPv6, or use a combination. The first-hop router and DHCPv6 service therefore have related but different responsibilities.
This differs from familiar DHCPv4 operations. DHCPv4 can deliver an address, subnet mask, default gateway, DNS servers, and other options in one exchange. In IPv6, the endpoint learns the default router through ICMPv6 Router Advertisement messages. DHCPv6 does not simply reproduce every DHCPv4 option with a larger address.
ZDNS describes DHCP for IPv4 and IPv6, flexible configuration modules, standard and custom options, DDNS, endpoint classification, and IPv4-IPv6 correlation. To use those capabilities effectively, teams should define the control model, prefix plan, RA behavior, client support, and evidence requirements before enabling a production scope.
Choose the Address-Delivery Model First
There are three common operational patterns. SLAAC allows hosts to form addresses from prefix information advertised by routers. Stateless DHCPv6 can provide additional configuration while addresses come from SLAAC. Stateful DHCPv6 can assign addresses and other configuration through DHCPv6, while the router advertisement still supplies default-router information.
The right choice depends on endpoint support and operational goals. A network may prioritize centralized lease records, predictable addressing, lightweight autoconfiguration, privacy addresses, or compatibility with a diverse device population. One organization can use different models for managed workstations, servers, voice systems, guest devices, and specialized equipment.
Before selecting a mode, answer:
- Which endpoint operating systems and device types must connect?
- Do they support stateful DHCPv6, stateless DHCPv6, SLAAC, or several methods?
- Is a server-side address lease record required for operations or investigations?
- Will endpoints use temporary or stable privacy addresses in addition to managed addresses?
- Which system supplies DNS resolver and search-domain information?
- How will device identity be correlated across IPv4 and IPv6?
- What must happen when the router, relay, or DHCPv6 server is unavailable?
Test actual clients. Standards define protocol behavior, but operating systems and embedded devices do not all implement the same combinations. A design that works for one managed desktop image may fail for mobile or specialized endpoints.
Build the IPv6 Prefix Plan in IPAM
DHCPv6 configuration depends on an intentional prefix plan. Record the aggregate, site, routing domain, VLAN or segment, purpose, owner, allocation method, and lifecycle state. A typical LAN uses a /64 prefix, but the organizational hierarchy above that segment should support route aggregation, delegation, growth, and policy.
ZDNS IPv6 address planning includes semantic templates for bit-width planning and IPv6 management. Such a model can help teams reserve bits consistently for region, site, environment, and subnet instead of inventing a different pattern for every deployment.
Define the relationship between the on-link prefix and any DHCPv6 address range. Reserve infrastructure identifiers according to policy. Record excluded or manually assigned addresses. Decide how delegated prefixes will be tracked if routers, customer equipment, or downstream networks receive prefix delegation.
IPv6 abundance does not remove the need for governance. Poorly documented prefixes create routing, security, and ownership problems even when address exhaustion is unlikely.
Configure Router Advertisements as Part of the Service
Router advertisements are fundamental to IPv6 host configuration. They identify the first-hop router, communicate prefix information and lifetimes, and carry flags that help indicate available configuration methods. For stateful DHCPv6, the Managed Address Configuration flag is commonly used to signal that addresses are available through DHCPv6. The Other Configuration flag can signal that other information is available through DHCPv6.
Do not configure the DHCPv6 server in isolation and assume clients will start sending requests. Verify the RA configuration on every relevant first-hop router. Check the advertised prefix, prefix length, valid and preferred lifetimes, autonomous-address flag, managed and other-configuration flags, router lifetime, and maximum transmission unit.
The combination must be intentional. If SLAAC is not part of the design, the autonomous behavior and prefix flags should reflect that decision. If SLAAC and DHCPv6 coexist, document which addresses applications should prefer and how temporary addresses affect logging and identity.
Understand the DHCPv6 Exchange
DHCPv6 is a separate protocol from DHCPv4. RFC 8415 defines the current DHCPv6 specification. A typical stateful exchange uses Solicit, Advertise, Request, and Reply, often abbreviated SARR. A client sends a Solicit to locate available DHCPv6 servers. Servers can Advertise configuration, the client selects one and sends a Request, and the selected server returns a Reply.
DHCPv6 clients listen on UDP port 546. Servers and relay agents listen on UDP port 547. IPv6 multicast and link-local addressing are part of the local exchange, while relays carry messages between client segments and centralized servers.
RFC 8415 also defines a Rapid Commit option that can allow a two-message Solicit/Reply exchange when client and server support and policy permit it. Use it deliberately. A normal four-message exchange makes server selection explicit and is easier to compare with the familiar DHCPv4 acquisition sequence.
Plan Identity around DUIDs, Not Only MAC Addresses
DHCPv4 operations often associate a lease with a MAC address or client identifier. DHCPv6 uses a DHCP Unique Identifier, or DUID, to identify a client. DUID formats and persistence are controlled by the client implementation. An endpoint can also have multiple interfaces and multiple IPv6 addresses.
This changes reservation, troubleshooting, and asset-correlation workflows. Copying a DHCPv4 reservation based on a MAC address into a DHCPv6 plan may not produce the expected identity. Collect DUID behavior from representative clients and decide how reservations, naming, and inventory will use it.
ZDNS DHCP describes MAC-based correlation to map IPv4-IPv6 associations and integration with identity and asset systems. Correlation is valuable, but teams should still preserve the native DUID and lease evidence. A correlation field should not erase the distinction between protocol identifiers.
Select DHCPv6 Options by Function
DHCPv4 and DHCPv6 option numbers are not interchangeable. IPv4 DHCP option 6 commonly supplies DNS server addresses, while DHCPv6 uses option 23 for DNS Recursive Name Server information. DHCPv6 option 24 provides a domain search list. Client FQDN behavior can use DHCPv6 option 39.
The default gateway is a particularly important difference. IPv4 DHCP can supply a router option. IPv6 endpoints learn the default router from router advertisements, not a DHCPv6 default-gateway option. If a client has an IPv6 address and DNS information but no usable default route, inspect RA behavior before changing DHCPv6.
Create an option catalog that includes:
- Option number and official name.
- Business and technical purpose.
- Expected client types and support status.
- Scope, policy, or class where the option applies.
- Authoritative owner and change process.
- Validation method on the endpoint.
- Equivalent IPv4 behavior when one exists.
ZDNS DHCP supports standard and custom DHCP options. Custom options should be introduced only with a verified specification, client requirement, and test. An option that the client ignores adds complexity without delivering configuration.
Configure Relays with the Correct Segment Context
Central DHCPv6 servers rely on relay agents to serve remote links. The relay needs to forward the client's message with enough context for the server to select the correct link, scope, and policy. Routing and security controls must permit the relay-server exchange.
For each segment, document the first-hop device, relay addresses, server destinations, redundancy, and expected source behavior. Verify that the server can distinguish links that may use similar local patterns. If several relay layers exist, confirm that the resulting relay-forward information remains correct.
Troubleshoot in sequence: confirm the client receives an RA, confirm it sends the expected DHCPv6 message, confirm the relay receives and forwards it, confirm the server selects the intended range, and confirm the Reply returns through the relay to the client. This sequence prevents a server configuration change from masking a router or path problem.
Align Lifetimes without Treating Them as One Timer
IPv6 configuration can contain several lifetimes. Router advertisements can communicate preferred and valid lifetimes for prefixes used by SLAAC. DHCPv6 leases also have preferred and valid lifetimes for assigned addresses. Router lifetime controls default-router validity. DNS information can have its own refresh behavior.
These values serve related but different purposes. A preferred address can become deprecated before it becomes invalid. A client can keep an address while selecting a newer address for new connections. An RA prefix lifetime and a DHCPv6 address lifetime do not have to be identical, but contradictory settings can produce confusing transitions.
Model planned changes and failures. Ask what happens if the DHCPv6 service is unavailable, if the router stops advertising, if a prefix is renumbered, or if one HA peer fails. Choose lifetimes that allow safe recovery without leaving obsolete configuration active longer than intended.
Connect DHCPv6 to DNS and Address History
Dynamic IPv6 addresses still need useful naming and lifecycle context. Decide whether the client or DHCPv6 service performs DDNS, who owns forward and reverse updates, how stale records age, and how conflicts are handled. ZDNS DHCP supports DDNS updates into DNS, while ZDNS dual-stack DNS operations provide the resolution layer.
Address history should preserve DUID, hostname, prefix, address, interface or endpoint relationship, lease time, and relevant timestamps. When temporary SLAAC addresses coexist with DHCPv6 assignments, document which data sources observe each address type. DHCPv6 alone will not provide a lease record for an address created independently through SLAAC.
Security teams also need access context. Network access and topology visibility can help connect an IPv6 identity to where and how a device joined the network. The goal is a time-aware chain of evidence rather than a flat list of long addresses.
Validate One Segment End to End
Begin with a lab or pilot VLAN that represents the target production environment. Include the actual router platform, relay, DHCPv6 service, DNS path, security controls, and representative endpoints. Test both fresh attachment and renewal.
Validate the following:
- The router advertisement contains the intended prefix, flags, and lifetimes.
- Each client type selects the expected SLAAC or DHCPv6 behavior.
- SARR messages pass through the relay and reach the intended server.
- The client receives the correct address or prefix and DHCPv6 options.
- The default router comes from RA and is usable.
- DNS server and search-domain settings are correct.
- Forward and reverse DNS behavior follows policy.
- IPAM records the planned and observed address context.
- HA and failure behavior match the approved design.
- Unauthorized RA or DHCPv6 behavior is detectable by the selected controls.
Capture packets during the pilot and save a known-good sequence. It becomes a useful baseline when a later segment behaves differently. Expand gradually, comparing each deployment with the approved template and client-support matrix.
Conclusion
IPv6 DHCP configuration is a coordinated design across router advertisements, SLAAC, DHCPv6, relays, DUIDs, options, DNS, and IPAM. Starting with a server scope skips the decisions that determine whether clients will request configuration and how operations teams will identify them.
Choose the address-delivery model, build the prefix plan, configure RA and DHCPv6 as complementary services, test real endpoints, and retain lifecycle evidence. With that foundation, organizations can extend familiar DHCP operations into IPv6 without pretending the two protocols are identical.