no-nonsense, objective, experienced, honest


The Blog of an honest Consultant.

2019-06-19

DHCPv6 Resilience

The services DNS and DHCP are called Core Network Services for a reason. Neither a medium-site family business nor a major corporation is able to run its corporate network without these mandatory services. Their significance is even increasing with topic like computer-controlled manufacturing plants, smart metering or IP-based facility management. In addition the number of IP-enabled devices – specially mobile devices – is also increasing.

DHCPv4 Failover

The proven remedy for DHCP resilience in an IPv4 environment is the setup of a so-called “Failover Association”. The protocol-based geographical redundancy between two active DHCP servers was defined in Internet Engineering Task Force (IETF) document „draft-ietf-dhc-failover-12“. In that case geographical redundancy belongs to the third layer of the OSI model. DHCPv4 failover offers resilience across network boundaries.
From a more technical point of view this concept is based on two DHCP servers located in different IP networks responsible for the same dynamic address range.  A permanent communication between both machines keeps them in sync and ensures the capability that one server is able to handle DHCP leases, which were assigned by its peer. (cf. figure 1).

figure01.png

DHCPv6 Failover

Like in IPv4 the DHCPv6 failover mechanism is based on an IETF draft (draft-ietf-dhc-dhcpv6-failover-design-04), which expired in March 2014. At the time when this article was written, none of the most dominate systems Microsoft DHCP (https://technet.microsoft.com/de-de/windowsserver/dd448608.aspx) and ISC DHCP (https://www.isc.org/downloads/dhcp/) offered an implementation of IETF’s DHCPv6 failover draft. After my presentation about this lack of resilience for DHCPv6 there was a discussion about homegrown solutions to close that gap. Unfortunately this kind of solution isn’t available for the community.
But this doesn’t there’s no resilience for DHCPv6 at all. The “Request for Comments” (RFC) number 6853 deals with potential approaches, that are reachable with today’s technologies.

Currently available Redundancy of DHCPv6

IETF’s RFC 6853 “DHCPv6 Redundancy Deployment Considerations” describes three semi-redundant models in order to realize the reliability of a DHCPv6 service with today’s capabilities.

# Requirements of these Models #
First, various conditions relating to the systems involved and their communications have to be clarified (cf. figure 2):
1. Two or more servers provide DHCPv6 services for the same group of clients.
2. The implementation of all involved DHCP server follows RFC 3315 “Dynamic Host Configuration Protocol for IPv6”.
3. The implementation of all involved DHCP relays (coll. IP helper) also follows RFC 3315.
4. There is no direct communication between the participating DHCP servers.
5. DHCP clients are using “stateful DHCPv6”.
6. DHCP clients have to implement the so-called “Preference Option”, which is included in every DHCPv6 packet.

figure02.png

# Separated DHCP Ranges #
In the model of “Split Scopes” unique, non-overlapping DHCPv6 ranges are defined for the same network. The DHCP pools are active in parallel, but send different values in their “preference option”. This is a kind of prioritization of the server to the client (cf. figure 3).

figure03.png

# Several unique DHCP Networks #
The distribution of multiple IPv6 prefixes is the principle of “Multiple Unique Prefix” model. The available DHCP addresses are not split between multiple DHCP servers. Each system uses its own address space. As with the model of “Split Scopes”, the DHCPv6 servers are configured with different prioritization (cf. figure 4).

figure04.png

# Identical DHCP Ranges #
The model of the “Identical Prefixes” is based on the principle of probability. All participating DHCP servers provide dynamic addresses from identical DHCP pools of the same network segment. Since the address space in IPv6 compared to IPv4 is much more extensive, the probability of address conflicts is relatively low and acceptable (cf. figure 5).

figure05.png

# Review of the three Models #
All three models described above seem to be able to solve the problem of the lack of reliability of DHCPv6 servers. There arise, by the different approaches, various advantages and disadvantages.

The separation of the available DHCP addresses on two (or more) systems is a well known principle in IPv4 networks. A considerable disadvantage of this method arises from the loss of a system. This the number of available addresses is drastically reduced. In IPv4 networks, it may result in failure of the service if the DHCP range of the remaining system does not provide sufficient addresses for all clients. This risk can be greatly reduced in IPv6 networks by splitting address ranges in sufficiently large dimensions. It’s a waste of addresses as it is known as IPv4 in this scenario. The generally recommended size of 64bit in the host portion of the network address allows a very generous handling of DHCP ranges. The real problem with the “Split Scopes” model is the manageability - especially with multiple DHCPv6 server pairs. Without an appropriate management tool, this model can quickly run into misconfigurations, which can result in loss of service under certain circumstances.

The “Multiple Unique Prefix” model assigns a unique network with a unique, dynamic pool to any DHCPv6 server. Similar to the approach described above, the DHCP selected areas within the 64bit networks have to be sufficiently large to not face the problem of address shortage. The complexity of administration is significantly less than with the “Split Scopes” method. Management can be done easily with templates. But multiple IPv6 prefixes are distributed in the same network segment. This process is known as “Superscoping” in IPv4. This in turn affects the definition of “Access Control Lists” (ACL) and their management.

The manageability of the “Identical Prefixes” method is simple because each DHCP server receives the identical configuration. A lack of availability of dynamic addresses can not occur in case of failure of the systems. Assuming that DHCP addresses are randomly offered as a lease to clients, the probability of double occupancy at the address allocation is very low. In practice current DHCPv6 implementations fill a dynamic pool often on the same principle, e.g. starting with the last address available. This leads to address conflicts.

In summary it can be said that all three models are more of a temporary solution as an actual approach for the reliability of a DHCPv6 environment. None of the models considered the event that a failed system becomes active again and provides addresses. Some models offer the possibility of duplication of address assignment - even if the probability is low.

Furthermore the dynamic update of DNS records from the DHCP server was not considered. This principle is common in IPv4 and adopted in IPv6. There may be discrepancies in dynamic DNS (DDNS), if multiple DHCP servers are configured identically. This problem also occurs when DHCPv4 and DHCPv6 servers update the same DNS zone simultaneously. Especially with ISC DHCP the “update-conflict-detection” statement helps at this point.

Why there’s (still) no DHCPv6 Failover

After two servers have built a failover association, the addresses of the pool will be split among both servers. RFC 3074 describes the “DHC Load Balancing Algorithm”, which is implemented by the ISC DHCP daemon. By default a DHCP pool between two “peers” will be divided 50/50 (active-active mode).

This construct leads to problems in practice. Especially the so-called “Rebalancing” can lead to unexpected behavior in DHCP. This balance of available IP addresses is carried out regularly for each DHCP pool with failover in place.

Sep 1 10:31:04 b0ad00ac5n dhcpd:    DHCPDISCOVER from aa:bb:cc:dd:ee:ff via
                                    192.168.0.1: peer holds all free leases
Sep 1 10:31:07 b0ad00ac5n dhcpd:    balancing pool b3f5ed0 192.168.0.0/19
                                    total 8189 free 8143 backup 0 lts -4071
                                    max-own (+/-)814 (requesting peer
                                    rebalance!)

But not the delta is transferred, but a list of all free and all used addresses. Details are stored in the so-called “Leases File” (dhcpd.leases).

[...]
lease 192.168.0.240 {
  binding state free;
}
[...]

In environments with many failover pools and especially with large networks, the rebalancing affect the DHCP service significantly. Usually DHCP failover archives geographical redundancy, so that the combination of rebalancing and latency has to be considered. From the project of an international financial services company has been announced that two geographically not(!) separated DHCP servers in failover mode configured for 500,000 clients need around 3 minutes for the synchronization of their leases. Here it can be assumed from a latency of zero. If the systems were distributed on campus, a latency of 55ms is assumed. In this case a synchronization with a period of up to 45min. is expected. This can affect the allocation of IP addresses by the DHCP service seriously.

With regards at the immense mass of IP addresses of an IPv6 network and the pool contained therein, it is clear that the previously used rebalancing algorithm can bring the DHCP service to a halt quickly. 

References

DHCPv6 Redundancy Considerations (http://www.slideshare.net/ataudte/dhcpv6-redundancy-considerations-20140405)
DHC Load Balancing Algorithm (RFC 3074)
Dynamic Host Configuration Protocol for IPv6 (RFC 3315)
IPv6 Prefix Options for Dynamic Host Configuration Protocol version 6 (RFC 3633)
A DNS Resource Record for Encoding Dynamic Host Configuration Protocol Information (RFC 4701)
Resolution of Fully Qualified Domain Name Conflicts among Dynamic Host Configuration Protocol Clients (RFC 4703)
The Dynamic Host Configuration Protocol for IPv6 Client Fully Qualified Domain Name Option (RFC 4704)
DHCPv6 Leasequery (RFC 5007)
DHCPv6 Bulk Leasequery (RFC 5460)
DHCPv6 Options for Network Boot (RFC 5970)
DHCPv6 Redundancy Considerations (RFC 6853)

Admin - 12:39 @ general, dhcp, ipv6