On October 22, the Internet Systems Consortium (ISC) posted an end-of-life announcement for ISC DHCP Server, a benchmark product used by major network infrastructure providers around the globe. Originally conceived in 1993 and built in 1995, ISC DHCP was a bleeding-edge product for much of its early history, shaping how DHCP functions. As the DHCP protocol and its application evolved, ISC DHCP changed with it, adjusting to new requirements and use cases.
The EOL announcement is hardly a surprise. Back in 2018, ISC announced the final version of the product. An end-of-maintenance announcement for several components was released in July 2021.
Even with this parade of announcements foreshadowing the demise of ISC DHCP, it remains the de facto standard for DHCP implementations around the globe. All of the major DDI providers still use it as part of their core product lines. Now those providers have to deal with an unsupported application at the center of their business - one that would require a great deal of risk and uncertainty to replace.
Can Kea DHCP fill the gap?
ISC created Kea DHCP in 2014 to fill the space long occupied by ISC DHCP. Kea’s newer codebase and updated feature set are designed to fit a broader set of use cases and operational requirements. It has an API, dashboards, and many other modern features which ISC DHCP never supported.
Yet the fact of ISC DHCP’s continued longevity speaks to significant gaps that Kea DHCP hasn’t filled. Kea DHCP was designed as a bridge - recognizing the ubiquity of ISC DHCP, and the architecture prioritized compatibility with existing deployments as much as possible. The criticism is that it ended up being a “bridge to nowhere,” full of incomplete implementations and half-baked functionality.
Take failover as an example. The failover mechanism in ISC DHCP was always a sore spot, with overly complex workflows that required a lot of care and feeding. Kea DHCP did improve how those workflows came together but failed to address underlying concerns about complexity. While Kea DHCP supports both active/active and active/passive failover in theory, the reality is that two-node, active/active failover synchronization is the only method that’s feasible. Long lease synchronization times, constant rebalancing, and a limit of two nodes make the active/passive option impractical. Multiple fail points aren’t an option at all.
Replication is another area where Kea DHCP’s limitations create operational headaches. Instead of entrusting replication to the backend database, Kea DHCP only supports inter-process communications. In practice, this means that replication nodes need to have extremely low latency. If they aren’t in the same data center or local network area, “flapping” makes replication basically unusable.
Leases are another operational challenge in Kea DHCP. Information about lease status and release times aren’t exposed through a centralized database of leases. This data can be retrieved via API, but only on a per-server basis. If you have more than one DHCP server (which is quite common), all the data correlation from those different API calls has to happen manually. This only adds to the workload of network administrators deploying Kea into larger environments.
The list goes on - lack of WAN connectivity, issues with authentication and cross-network servicing, a complicated interface, and lack of ping checks for clients without protocol integration capabilities - all of these make Kea DHCP a poor substitute for its predecessor of nearly thirty years.
The road ahead
Where do network administrators go from here? The options are increasingly narrow and not exactly promising. There are a few non-ISC options, but many of those are also long in the tooth and have even larger functionality gaps than ISC DHCP and Kea DHCP. In the near term, most admins will probably hunker down with the systems they’ve got, even as they cast about with increasing urgency for a viable alternative.
One potential upside of the EOL announcement for ISC DHCP is that it creates urgency. Reliance on the “good enough” systems of old is no longer a viable long-term strategy. Some alternatives will have to emerge - the only question is where it will come from, how it will be developed, and (most importantly) who will do the work.
Kea DHCP has a clear head start, but a significant amount of reengineering and strategy work would be required for it to live up to its initial mission. Given ISC’s limited resources, it would take more than a proverbial village to bring Kea DHCP to where it needs to be - more like a mid-size town of developers, coders, and testers.
Here’s where things get interesting. Kea DHCP is free but not open source, a situation that effectively prevents it from being the next-generation solution that network administrators and internet service companies truly need.
What is preventing Kea DHCP from moving into the open-source realm? Intellectual property rights. Several companies and developers have expressed interest in helping to develop Kea DHCP further, yet the “hub and spoke” failover model it uses is part of an active patent. All the non-disclosure agreements and other restrictions designed to protect the patent holder’s rights have effectively hemmed in developing this critical software that the world’s networks rely on. Rearchitecting Kea DHCP to work around the patent would be a heavy lift at this point - you might as well start from scratch.
Network admins will probably continue to limp along with ISC DHCP as long as they can. Yet there is a clear requirement for a new benchmark DHCP product that’s free, open source, and has all the functionality network administrators really need. The market need is certainly there, and it won’t be satisfied by either ISC DHCP or Kea DHCP. The use cases are well-defined. The gaps in existing options are clear. An alignment of factors like this is quite rare in any business, let alone in a technology sector that has explored opportunities in the smallest of niches.
The clock is ticking. Who will answer the call?