{"id":10303,"date":"2024-06-26T08:00:31","date_gmt":"2024-06-26T15:00:31","guid":{"rendered":"https:\/\/blogs.infoblox.com\/?p=10303"},"modified":"2025-04-02T11:08:07","modified_gmt":"2025-04-02T18:08:07","slug":"dhcp-and-dhcpv6-commonalities-and-differences","status":"publish","type":"post","link":"https:\/\/www.infoblox.com\/blog\/ipv6-coe\/dhcp-and-dhcpv6-commonalities-and-differences\/","title":{"rendered":"DHCP and DHCPv6: Commonalities and Differences"},"content":{"rendered":"

Just like IPv4 and IPv6 have their similarities and differences, there are commonalities and differences between DHCP and DHCPv6. On IPv4 networks, nodes can either have their IP addresses statically configured or they can be dynamically configured with DHCP. IPv6<\/strong><\/a> offers several methods of assigning IPv6 addresses to end nodes. Of course, nodes can have their IPv6 address statically configured, but there are also two dynamic address configuration methods: StateLess Address AutoConfiguration (SLAAC) and stateful DHCPv6. When to chose SLAAC or DHCPv6 was covered in a very early set of Infoblox IPv6 COE blogs: Part 1<\/a>, Part 2<\/a>, Part 3<\/a>, and Part 4<\/a>. This article will compare DHCP and DHCPv6.<\/p>\n

Commonalities<\/h3>\n

Both protocols are standards published by the Internet Engineering Task Force (IETF) within the Dynamic Host Configuration Working Group<\/a> (DHC WG). DHCP was originally defined in RFC 1531<\/a> in 1993 (over 30 years ago) and then refined in RFC 2131<\/a> in 1997. DHCPv6 was first defined in RFC 3315<\/a> in 2003 (a decade after DHCP\u2019s first RFC was published) and the current version is defined in RFC 8415<\/a>.<\/p>\n

DHCP and DHCPv6 have many fundamental characteristics in common. Both protocols perform the function of dynamically assigning an IP address to an end host. They both have the concept of a scope or range and a lease of an individual address to an end node. Both protocols share the functional components of a DHCP\/DHCPv6 client end node, a DHCP\/DHCPv6 relay intermediary, and a DHCP\/DHCPv6 server. The same clients, relays, and servers can use DHCP and DHCPv6 simultaneously in a dual-protocol scenario.<\/p>\n

It is often recommended that organizations follow the same operational model for IPv4 and IPv6. It makes sense that if an organization uses DHCP today in their IPv4 networks that they would select DHCPv6 for their IPv6 networks. For enterprises, it may prove administratively burdensome to use DHCP for IPv4 and SLAAC with Recursive DNS Server (RDNSS) and DNS Search List (DNSSL) (RFC 8106<\/a>) for IPv6. If that is the case, it may be best to keep things simple and deploy DHCPv6 alongside DHCP. However, there may still be devices, like those running the Android OS or ChromeOS that don\u2019t support DHCPv6. <\/p>\n

Different UDP Port Numbers<\/h3>\n

DHCP and DHCPv6 both use a connectionless service model using User Datagram Protocol (UDP) messages on the access segment. IPv4 DHCP servers (or relays) listen on UDP port 67, and the client listens on UDP port 68 (the same ports as BOOTP). For IPv6, DHCPv6 clients listen on UDP port 546 and the DHCPv6 servers and relay agents listen on UDP port 547. These port numbers are well-known registered port numbers documented by the Internet Assigned Number Authority (IANA) in the \u201cService Name and Transport Protocol Port Number Registry<\/a>\u201d.<\/p>\n

DORA versus SARR<\/h3>\n

DHCP and DHCPv6 are functionally equivalent in how a client statefully sends messages, often through a relay, and onward to the server. However, the message types and names are different. IPv4 DHCP clients start by sending a DHCPDISCOVER message to the IPv4 broadcast address (e.g., 255.255.255.255) and the server will respond with a DHCPOFFER message. The client then sends a DHCPREQUEST message, and finally the server completes the transaction by sending an DHCPACK acknowledgement message. This is shortened to Discover, Offer, Request, Acknowledge, or \u201cDORA\u201d). With DHCPv6, the four messages that go between the client and the server are SOLICIT, ADVERTISE, REQUEST, REPLY (or \u201cSARR\u201d). The following is a table that lists the functionally equivalent DHCP and DHCPv6 message types and names.<\/p>\n\n\n\n\n\n\n\n\n\n\n
DHCP Message Types<\/a><\/strong><\/td>\nDHCPv6 Message Types<\/a><\/strong><\/td>\n<\/tr>\n
DHCPDISCOVER<\/td>\nSOLICIT<\/td>\n<\/tr>\n
DHCPOFFER<\/td>\nADVERTISE<\/td>\n<\/tr>\n
DHCPREQUEST<\/td>\nREQUEST<\/td>\n<\/tr>\n
DHCPACK<\/td>\nREPLY<\/td>\n<\/td>\n<\/tr>\n
DHCPRELEASE<\/td>\nRELEASE<\/td>\n<\/tr>\n
DHCPINFORM<\/td>\nINFORMATION-REQUEST<\/td>\n<\/tr>\n
DHCPDECLINE<\/td>\nDECLINE<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

This table lists the more common messages, but there are many other DHCP and DHCPv6 message types that we don\u2019t discuss.<\/p>\n

Efficient Use of Multicast Rather Than Broadcast<\/h3>\n

One key difference between IPv4 and IPv6 is in how they use broadcast messages and\/or multicast messages. IPv4 networks could use subnet broadcast messages sent to all local nodes using 255.255.255.255, or IPv4 could use multicast (224.0.0.0\/4) destination addresses. IPv6 does not have any mechanism or addresses type that function as a broadcast. Instead, IPv6 uses multicast (ff00::\/8) addresses for all one-to-many communications.<\/p>\n

This difference carries over to how DHCP and DHCPv6 function on a client access network. DHCP clients send their DHCPDISCOVER and DHCPREQUEST messages as a broadcast to 255.255.255.255. All other nodes on the local segment receive this message and are forced to process it and determine if they need to act upon that message. The DHCP relay will receive this unsolicited broadcast and forward it on to the DHCP server. For example, a Cisco router\u2019s IPv4 access-network interface will be configured with an \u201cip helper\u201d command with the unicast IPv4 address of the DHCP server.<\/p>\n

With DHCPv6<\/a>, clients send their initial SOLICIT message to the All_DHCP_Relay_Agents_and_Servers link-local scope multicast address of ff02::1:2. The on-link DHCPv6 relay (or DHCPv6 server) is tuned into this multicast address and will receive and process these messages. The DHCPv6 relay could also use the All_DHCP_Servers site-local scope multicast address of ff05::1:3 to send messages to all DHCPv6 servers in the environment. Similarly, on a Cisco router\u2019s IPv6 access network interface, it will use the \u201cipv6 dhcp relay destination\u201d command with the global unicast address of the DHCPv6 server.<\/p>\n

Client Source Address Differences<\/h3>\n

End hosts using DHCP and\/or DHCPv6 both start out in a \u201cchicken or the egg<\/a>\u201d dilemma whereby they need to send a packet to initiate the process of obtaining a unicast address, but also need a source address to use for their initial DHCP or DHCPv6 communications. IPv4 DHCP clients use 0.0.0.0 as their initial source address to send their DHCPDISCOVER and DHCPREQUEST messages. DHCPv6 clients use their link-local IPv6 address (on the fe80::\/10 network) when sending their SOLICIT and REQUEST messages for communicating with the relay or server. DHCP relies on broadcasts to send messages to the relay or server and the relay or server uses unicast addresses to send back the responses. With DHCP, the client receives their address in the DHCPOFFER message destination address. DHCPv6 clients and relay\/servers use their link-local addresses as their source address, and the relay\/server is tuned into link-local multicasts to receive messages from clients. DHCPv6 clients don\u2019t receive their global unicast address until the full four-way protocol exchange has finished.<\/p>\n

Router Advertisement Messages Initiate DHCPv6<\/h3>\n

One of the key differences between how IPv4 and IPv6 function on a LAN segment is IPv6\u2019s use of ICMPv6 for router discovery. IPv6 routers send ICMPv6 type 134 Router Advertisement (RA) messages to the all-nodes link-local multicast address of ff02::1 to share information about the local network with all the nodes on the segment. These RAs sent by the first-hop router are a vital message that initiates the boot-up process for end nodes<\/a>. In fact, it is the RA with the \u201cManaged Address Configuration\u201d flag set to \u201c1\u201d that triggers a client to begin the DHCPv6 stateful address assignment process. IPv4 doesn\u2019t have any equivalent of the router discovery function. A DHCP client simply starts up and broadcasts the DHCPDISCOVER message to start the process.<\/p>\n

MACs Versus DUIDs<\/h3>\n

DHCP uses the link-layer MAC address as the identifier for the client. The client\u2019s MAC address is noted by the relay and the server, and associated with the address lease. DHCPv6 uses what is known as a DHCP Unique Identifier (DUID)<\/a> for the client identifier. There are four DUID types defined in DHCPv6 (RFC 8415<\/a>) and the choice of the DUID format is left to the client.<\/p>\n

    \n
  1. Link-layer address plus time (DUID-LLT) \u2013 used by Windows 10\/11 clients and Apple MacOS<\/li>\n
  2. Vendor-assigned unique ID based on Enterprise ID (DUID-EN) \u2013 used by some Linux distros<\/li>\n
  3. Link-layer address (DUID-LL)<\/li>\n
  4. UUID-Based DUID (DUID-UUID) (RFC 6355<\/a>) \u2013 used by some Linux distros<\/li>\n<\/ol>\n

    This can cause an operational challenge for organizations because DHCP and DHCPv6 don\u2019t simply both use the client\u2019s MAC address. Tom Coffeen wrote a 2-part blog series (Part 1<\/a>, Part 2<\/a>) and Ed Horley also wrote a blog on the challenges<\/a> of maintaining MAC addresses for DHCP and DUIDs for DHCPv6. <\/p>\n

    DHCP and DHCPv6 both allow for the creation of a static reservation. For IPv4, DHCP allows for creating a fixed address binding between an IP address based on the MAC address of the client. Leveraging IPAM DHCP<\/strong><\/a> ensures streamlined management of address allocations and lease tracking for both DHCP and DHCPv6 environments. For IPv6, DHCPv6 uses the DUID for the static reservation mapping to the IPv6 global address within the range.<\/p>\n

    High Availability<\/h3>\n

    For IPv4 networks that required a high availability set of DHCP servers in case one fails, leases could be preserved and new leases served by the surviving DHCP server(s). Initially the DHCP Failover Protocol<\/a> was conceived and then later the \u201cDHC Load Balancing Algorithm\u201d (RFC 3074<\/a>) was proposed.<\/p>\n

    High availability has historically been a challenge for DHCPv6 servers<\/a> because there wasn\u2019t any equivalent redundancy method specified as a standard. The IETF documented these issues in \u201cDHCPv6 Redundancy Deployment Considerations\u201d (RFC 6853<\/a>) and \u201cDHCPv6 Failover Requirements\u201d (RFC 7031<\/a>). Now, with the DHCPv6 Failover Protocol (RFC 8156<\/a>), DHCPv6 server redundancy is equivalent to DHCP server redundancy. In fact, Infoblox worked with Internet Systems Consortium<\/a> (ISC) on other forms of DHCPv6 redundancy, which are now supported in the Kea DHCPv6 server<\/a>.<\/p>\n

    Lease Times for DHCP and DHCPv6<\/h3>\n

    Because IPv4 address space is a scarce commodity, scopes are typically small and lease times are set aggressively low to preserve address space. In fact, DHCP networks can even be configured to have clients release their address before they leave a network. Alternatively, IPv6 subnets are large (typically a \/64), without any danger of exhausting the pool. Therefore, clients can request a new address each time they join a network. The maximum number of nodes on an IPv4 subnet may be limited to a few hundred because of the potential for subnet broadcast storms. On the other hand, IPv6\u2019s efficient use of multicast allows networks to have far more nodes on an IPv6-only segment<\/a>.<\/p>\n

    DHCPv6 lease times don\u2019t have to be the same as the network\u2019s IPv4 DHCP lease time. For both protocols, renewal occurs at half the lease time, but this can be adjusted and is implementation-specific. However, DHCPv6 lease times may be different than customary IPv4 DHCP lease times<\/a> and you may want to have different lease times for DHCP and DHCPv6.<\/p>\n

    DHCPv6 ranges are typically \/64 prefixes and DHCPv6 servers have enough available addresses to randomly assign a new one each time a client requests a lease. On an Infoblox NIOS system you can configure DHCP Scope\/Leases and DHCPv6 Lease Affinity<\/a>. The DHCPv6 server will renew and reuse leases up to the interval but will reuse, renew and scavenge expired leases after that interval. The interval is configurable, from 7 (default in Infoblox) up to a maximum of 180 days.<\/p>\n

    DHCP and DHCPv6 Options<\/h3>\n

    Another difference between DHCP and DHCPv6 is the way they handle options. Options allow for DHCP (RFC 2132<\/a>) and DHCPv6 servers to share additional configuration information with clients. DHCPv6 Options are different from but functionally equivalent to DHCP for IPv4. Both DHCP and DHCPv6 protocols provide options to the end node to provide additional information, but DHCP uses a single octet option field while DHCPv6 has a larger 16-bit option type code length. Often, there are functionally equivalent options, but the option numbers and names are different. IANA maintains a full list of all the DHCP options<\/a> and the DHCPv6 options<\/a>.<\/p>\n

    Summary<\/h3>\n

    DHCP and DHCPv6 are functionally equivalent with the basic service they provide (i.e., dynamic host addressing). Integrating DHCP and DHCPv6 into a unified DDI<\/strong><\/a> solution can enhance operational efficiency and simplify network management. But they each have their own nuances and unique characteristics and it is beneficial to understand these differences. And even though DHCP and DHCPv6 have their differences, they can both coexist. Best of all, hosts, networks, and servers can all use both at the same time.<\/p>\n