High Availability DHCPv6
Much has been said regarding the sometimes-subtle, sometimes-obvious ways that “shiny new” IPv6 is different from the “legacy” IPv4 protocol. One subtle example is how IPv6 uses ICMPv6 for the Neighbor Discovery Protocol (NDP) compared to IPv4’s broadcast messages and ARP method. One overt example is how IPv6 uses behemoth 128-bit addresses where IPv4 uses petite 32-bit addresses. Another subtle example is how IPv4 uses inefficient broadcast messages on a LAN and IPv6 makes far greater use of efficient multicast. Another noticeable difference is how IPv4 addresses may be assigned statically to end nodes or they could use Dynamic Host Configuration Protocol (DHCP). Compare this with how IPv6 routers use ICMPv6 Router Advertisement (RA) messages to signal how the end nodes will acquire their IPv6 addresses.
DHCPv6 and DHCP for IPv4
One of the more subtle differences between IPv4 and IPv6 is how DHCP is used by these two distinct network protocols. The recognizable fact is that DHCP for IPv4 (RFC 2132) is a completely separate protocol from DHCPv6 for IPv6 (RFC 3315). However, these protocols share some characteristics because, frankly, DHCP helped pave the way for DHCPv6. The following is a list of similarities between DHCP for IPv4 and DHCPv6.
- Both protocols use the concepts of a DHCP client, DHCP relay and DHCP server
- Both protocols use the concepts of scopes and leases
- Both protocols use a 4-message stateful exchange between client and server (DHCP for IPv4 uses Discover/Offer/Request/Acknowledge (DORA), andDHCPv6 uses Solicit/Advertise/Request/Reply (SARR))
- Both protocols provide DHCP options to the end-node to provide additional information (but DHCPv6 has a larger 16-bit option type code length)
- Both protocols support Rapid Commit functionality
Following is a list of the differences between DHCP for IPv6 and DHCPv6.
- DHCPv6 uses DHCP Unique Identifiers (DUIDs) (RFC 6355) whereas DHCP for IPv4 uses MAC addresses to identify the client.
- Their message type names are different, but perform many of the same functions (DHCP message types, DHCPv6 message types).
- Obviously, DHCP for IPv4 messages are transmitted over IPv4 packets and DHCPv6 is transmitted over IPv6 packets.
- DHCPv6 uses ICMPv6 Router Advertisement (RA) and IPv6 multicast messages and DHCP uses broadcast IPv4 messages on the LAN.
- DHCPv6 uses link-local IPv6 addresses when communicating between client and relay/server (RFC 6939), and DHCP for IPv4 uses unsolicited broadcasts.
- DHCP for IPv4 and DHCPv6 UDP port numbers are different. DHCP servers and relay agents listen on UDP port 67 and clients listen on UDP port 68, DHCPv6 clients listen on UDP port 546, DHCPv6 servers and relay agents listen on UDP port 547.
- DHCPv6 servers offer randomized interface identifiers (helps limit attacker reconnaissance), DHCP offers the next IPv4 address from the scope/pool.
- DHCPv4 can be configured on a router, stateful DHCPv6 is not typically available on routers.
- DHCP for IPv4 can provide the default gateway IP address to the client, whereas DHCPv6 does not have this option; the IPv6 node learns about its first-hop router from the ICMPv6 RA message (Pending draft on this subject).
- DHCP for IPv4 scopes are susceptible to exhaustion; DHCPv6 scopes are typically /64s with over 18 quintillion addresses so pool exhaustion is impossible.
Just to clarify, in this article, we are discussing stateful DHCPv6. We are not referring to what is called “stateless DHCPv6” (RFC 3736) or “DHCPv6-Lite”. Stateless DHCPv6 is where the IPv6 client uses Stateless Address Auto-Configuration (SLAAC) for its IPv6 address, but acquires DNS information from the first-hop router to help the node obtain functional use of the network.
DHCP High Availability Problem Statement
Imagine a network that has only one DHCP server and it goes offline. In this situation, no systems will be able to acquire a new address and effectively join the network. However, nodes that already have their leases and valid lease times will continue to use the IP addresses that they have been allocated. In other words, if your one and only DHCP server fails, new leases could not be serviced, but those nodes that already had IP addresses would continue to use them until they reached half their renewal period. While the one DHCP server was offline the nodes would be unable to renew their address leases. DHCP for IPv4 and DHCPv6 behave the same in these situations. Organizations don’t want to have to re-assign leases to operational clients just because a DHCP server fails. They want lease stability and they don’t want to impact the operations of working clients. They also want to minimize changes to dynamic DNS if node addresses change. Therefore, we need some solutions to help solve this problem.
Possible Solutions for DHCP Redundancy
Because services like DHCP and DNS are vitally important to IP networking connectivity, it is important to have highly reliable services for these critical functions. We desire lease stability and no impact to operational clients if a DHCP server fails. Most of the solutions to the DHCP availability problem require the use of multiple DHCP servers. We just need a way to operate two DHCP servers without impacting the clients if a server fails. As you can probably guess, one possible solution would involve synchronizing lease information between multiple DHCP servers.
There are both similarities as well as some differences between DHCP for IPv4 and DHCPv6 regarding how they work in a high-availability configuration with redundant DHCP servers. The IETF RFC titled “DHCPv6 Redundancy Deployment Considerations” (BCP 180, RFC 6853) provides an overview of the issues and reviews possible solutions to the problem. One key difference with DHCPv6 is that a node may request a single IPv6 address or a node may also request an entire IPv6 prefix to use downstream. This second request for an IPv6 prefix is called DHCPv6 Prefix Delegation (DHCPv6-PD) (RFC 3633) and there is no equivalent function in DHCP for IPv4.
Split Scopes, Split Prefix Ranges
A possible solution to the problem that may be familiar to IPv4 DHCP administrators is the concept termed “split scopes.” This is where two DHCP servers split up the IP address space: Half the addresses are used in a scope on the first DHCP server and the second half are used in a scope on the second DHCP server. With IPv4 there are far fewer IP addresses to go around. With IPv6 there is an abundance of addresses within a single /64 default prefix size. In the DHCPv6 situation these are called “split prefixes” and the entire /64 is split into two /65 prefixes. For example, the prefix used on the LAN would be 2001:0DB8:1234:5678::/64 and it would be split up into the following two /65 prefixes used by DHCPv6.
2001:0DB8:1234:5678:0000::/65
2001:0DB8:1234:5678:0000:0000:0000:0000 to 2001:db8:1234:5678:7FFF:FFFF:FFFF:FFFF
2001:0DB8:1234:5678:8000::/65
2001:0DB8:1234:5678:8000:0000:0000:0000 to 2001:db8:1234:5678:FFFF:FFFF:FFFF:FFFF
In this split prefix method, both DHCPv6 servers will respond to the Solicit message with an Advertise message. The two DHCPv6 servers use the DHCPv6 server preference option to tell the end-nodes which of the two DHCPv6 servers they should use. End-nodes will always chose the DHCPv6 server with the highest preference. Therefore, any DHCPv6 lease will be given by the preferred server.
This preference value is called the “DHCPv6 Failover Preference Option” and the higher preference is configured on the primary server (while the lower preference on the secondary server). This preference value is sent within the DHCPv6 Advertise message. Typical preference values are “255” for the primary server and “0” for the secondary server.
It is customary to use a preference value of “0” on the secondary server, so if the client receives that response first, it will wait a period of time until it hears another potential response with a higher preference value. This gives the primary server a chance to still be the primary server even if it isn’t the first to respond.
Note that if the preference value is set the same on the two DHCPv6 server Advertise messages, then the client picks one while discarding the other. The two servers would then need to synchronize their lease databases, thus increasing server load.
It should be noted as well that an active/passive design is much simpler to implement. In this configuration, if the primary server fails, then the nodes with IPv6 addresses will continue to function. New nodes joining the network will get their IPv6 addresses from the secondary server. However, when existing nodes need to renew their leases, the rebinding will fail to the secondary server and the node will end up getting a new address on the second /65 from the second DHCPv6 server. This will not meet our goal for lease stability.
Multiple Prefixes
A similar method to the split prefixes concept that we just described is one in which the two DHCPv6 servers each use a completely different /64 prefix. For example, the first DHCPv6 server will use 2001
B8:1:1::/64 with a higher preference and use 2001B8:2:2::/64 with a lower preference. Meanwhile, the second DHCPv6 server will use 2001B8:1:1::/64 with a lower preference and will use 2001B8:2:2::/64 with a higher preference. If one of the server fails, then the rebinding nodes or new nodes may get an addresses from either prefix. The issue here is that the local LAN would need to have both IPv6 prefixes operational on the network at the same time. This technique also suffers from a lack a lease stability.
Load Balancing
Another idea is one that uses hash buckets on both of the DHCPv6 servers. Each DHCPv6 server calculates a hash value between 1 and 256 buckets. One server will service the requests that have a hash value that falls within buckets 1 to 128. The other server will service the requests that have a hash value that falls within buckets 129 to 256. This approach effectively distributes load across the two servers. And while it also solves the problem of load balancing between two or more DHCPv6 servers, it doesn’t solve the high-availability redundancy problem and does not provide lease stability. There is an IETF RFC draft proposing this solution.
Overlapping Prefixes - DHCPv6 Failover
In this solution, two DHCPv6 servers use overlapping ranges and thus identical prefixes. For example, both DHCPv6 servers will respond to a Solicit message with an Advertise from the 2001B8:1:1::/64 prefix. Each DHCPv6 server will use a different preference value such as “255” for the primary DHCPv6 server and “0” for the secondary DHCPv6 server. This might sound like a great option up until the point where two nodes on the same LAN are issued an identical interface identifier. Not only would that be a great day to go buy a lottery ticket, but it would also be the day Duplicate Address Detection (DAD) helps prevent a collision.
To really make this a robust solution there are some other conditions that need to be addressed. For example, in the situation where an organization would like to have multiple DHCP servers provide addresses from a single shared pool, the two servers need to share lease information. If you made a pair of DHCPv6 servers share the same pool and have both servers allocate addresses then they will need some mechanism to share the state of leased IP addresses with each other. In other words, there will need to be some form of synchronization protocol used between the two servers. This protocol will be required to:
- continuously operate as the systems are both operational
- send heartbeat messages like a health check to make sure that the other server is online and operational
- used to re-synchronize status when a server is booted up to check in and synchronize with the other operational server
- synchronize the databases of state information and note which of the servers initially serviced the lease
While this may sound like a great idea, there are several problems with this approach. This surely adds complexity to the design. The other problem is that this is not currently available to implement because it is not a valid IETF RFC yet. There is an IETF RFC titled “DHCPv6 Failover Requirements” (RFC 7031) which covers the considerations of this failover method, but it does not specify the failover protocol. Unfortunately, the IETF draft that specifies the failover protocol titled “DHCPv6 Failover Design” is still in draft status. This DHCPv6 draft is based on the DHCP Failover Protocol for IPv4, which was proposed but never approved. However, that didn’t stop ISC from creating and implementing their own failover protocol method. (ISC is still deciding if they want to implement this similar feature for DHCPv6.)
Summary
We have reviewed many similarities and differences between DHCP for IPv4 and DHCPv6. They share many of the same concepts: The things that we know about DHCP will carry forward into our engineering and operation of DHCPv6 systems. However, there are some subtle differences between the two and we can’t just assume that DHCPv6 is configured identically to the way we have been used to configuring DHCP for IPv4. Namely, the DHCPv6 redundancy strategy we choose will likely be different than the method we may be using for DHCPv4. However, this is acceptable because IPv4 and IPv6 are completely different network protocols and we can’t expect that everything will be identical. If everything with IPv6 is the same as IPv4, then that would be boring and no fun at all. Vive la difference!