Why is ISC skeptical of the value of Ping-Check?
  • 27 Nov 2023
  • 4 Minutes to read
  • Contributors
  • Dark
    Light
  • PDF

Why is ISC skeptical of the value of Ping-Check?

  • Dark
    Light
  • 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, and has just recently been implemented in the Kea 2.5 development branch. It will be available as an optional Premium hook with the 2.6 stable branch.

Here's why we were so reluctant to add ping-check to Kea, and why we are skeptical of it's value to Kea users.

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 can be quite 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.

DHCP DECLINE

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.

Interestingly, there appears to be widespread and fundamental dissatisfaction with ping check in ISC DHCP and other implementations. 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.

Implementing ping-check has been a multi-step process, beginning with this design document. 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).

Given all these reasons, ISC decided to implement ping-check as an optional, premium hook. The solution will be complicated, challenging to maintain, and inherently unreliable, but we are implementing it because we have heard, over and over again, that some users, primarily enterprise users, still feel it has a useful role. We are hoping to hear that it works better, and is more useful, than we anticipated!