Why doesn't Kea support ping-check?
  • 10 Feb 2021
  • 4 Minutes to read
  • Contributors
  • Dark
  • PDF

Why doesn't Kea support ping-check?

  • Dark
  • PDF

Article Summary

Ping-check is a popular feature in ISC DHCP. The basic idea is that the server attempts to sends an ICMP echo request to the address about to be assigned to verify that it isn't currently in use. It only assigns the address after a timeout. This mechanism was intended to safeguard against several situations: badly-behaved devices (either due to bugs or skewed clocks) deciding to reuse an old address when they can't get a new one; users who hard-code an IP address on their device instead of letting it use DHCP; someone starting up an unofficial DHCP server, etc. This functionality has been requested in Kea, but it has not been implemented. Here's why.

Performance impact of ping-check

First, for single-threaded applications such as ISC DHCP, or Kea running in single-threaded mode, the ping-check mechanism can impose a severe performance penalty, as the server has to wait for a response and can't proceed forward until the timeout expires or an ICMP Reply comes back. This impact can be mitigated to some degree - in ISC DHCP, for example, this particular packet's processing is put on hold while the server does other work - but doing so complicates the packet-processing pipeline and does affect throughput and performance. Adding complexity can introduce extra bugs and occasional weird behavior in corner-case scenarios. The risk of unexpected side effects is increased when High Availability (HA) is also involved; instead of the usual response being sent immediately, a server would have to deploy a more complex processing cycle: allocate a lease, send a ping, park the packet, wait for a timeout, unpark the packet, send an update to its HA partner, park the packet, wait for the HA response, unpark the packet, and then finally send a reply to the client. This type of operation is certainly possible to add to Kea DHCP, but doing so is far from trivial and would incur substantial capital expenses (for the initial effort to implement) and operations expenses (for the ongoing maintenance of a complicated code-processing path).

Ping-check is unreliable

The second reason behind our reluctance to add this feature to Kea DHCP is a much more practical and realistic one. Simply put, the ICMP protocol is unreliable. In modern times, devices often don't respond to pings due to firewalls and routing policies, and occasionally this feature is disabled in the device itself. This problem can be minimized in some circumstances, such as when the operator fully controls the network infrastructure and their clients. But in others, such as public wifi or other BYOD scenarios, using ICMP echo as a means to detect in-use IP addresses is inherently unreliable.


Third, the DHCP protocol itself provides another, more reliable mechanism for this: the DECLINE message. Modern DHCP clients scan their local subnet (for example, using the ARP protocol) to detect whether the suggested address is already active on another device. If a client detects that the address assigned is in use by another device, it reports this to the server, which then marks the address as declined. Kea supports this mechanism well, and it is enabled by default. The lease is put in a probation period of 24 hours by default, but the length is configurable using the decline-probation-period parameter.

The remaining reasons are based purely on engineering constraints. The code changes required include:

  • The need to implement ICMP protocol support, with a new socket type.
  • Packet parsing, with recognition of processing of the various ICMP response codes.
  • The extension of Kea's ability to park packets to include more stages of packet processing (both in the core code and in the HA hook).
  • Additional documentation.
    This feature would also require substantial initial and ongoing testing effort.

Interestingly, there appears to be widespread and fundamental dissatisfaction with this feature. Note that it was mentioned in the DHCPv4 standard (see RFC2131, Section 2.2, published in 1997). However, there was no such suggestion in either the original DHCPv6 standard (RFC3315, published in 2003) or its recent update RFC8415, published in 2018. That is a sign that the IETF community no longer believes that using ICMP echo to prevent IP-address collisions is the right practice. ISC believes that this also reflects reality. Ping-check was a great feature when DHCP traffic rates were much lower and counted in single packets per second. Back then, it was fine to wait an extra second before a device could obtain an address. In modern networks, more and more deployment enviroments demand thousands of leases assigned per second, and ping-check simply does not scale to those levels.

Given all these reasons, ISC has decided not to implement ping-check, at least not yet. The solution would be complicated, challenging to maintain, and inherently unreliable, and other mechanisms can and do now mitigate the problem in most situations. Many other more-popular and -requested features - would give more widespread and tangible benefits.

Does this mean that Kea will never have ping-check? At this stage, we don't know; it depends on how many users and customers request this feature. We may decide to implement it one day, but for the time being, we're simply too busy with work on features that will solve other, more significant problems.