DHCP

TCP/IP networks in the 1980s remained modest and their configuration was entirely static. Administrators manually assigned an IP address to each machine, which stored this information in its secondary memory. Any modification required direct intervention at the console, typically followed by a system reboot. This hands-on approach suited the infrastructures of the time, but it would soon show its limitations.

Network growth and the arrival of affordable workstations without secondary memory disrupted this organization. It became urgent to centralize the administration of links between IP addresses and computer hardware. The RARP (Reverse Address Resolution Protocol) protocol emerged as the first answer: a machine connected to a network segment could now discover its IP address and initiate TCP/IP communications normally. Meanwhile, BOOTP (Bootstrap Protocol) facilitated the configuration of diskless stations by retrieving all TCP/IP parameters and system data needed for startup. The introduction of BOOTP relay agents made it possible to cross the boundaries of a single network segment. BOOTP already integrated an extension mechanism using the last field of the frame for specific data, an idea that DHCP would adopt.

RFC 1531 defined DHCP as a standard in October 1993. This extension of BOOTP corrected two major weaknesses: the requirement for manual intervention to add configuration information for each client, and the inability to reuse IP addresses. The protocol gained popularity, which led to successive clarifications. In 1997, RFC 2131 became the reference for IPv4 networks, a status it still holds today.

The arrival of IPv6 required the development of DHCPv6, documented in RFC 3315. This was not a simple transposition of DHCPv4 to IPv6 addresses, but a substantially different protocol. The most notable change concerned client identification: DHCPv4 relies on the MAC address, while DHCPv6 introduces the DUID (DHCP Unique Identifier). The design of DHCPv6 abandons the principle of a single address per device, allowing devices to request multiple addresses. RFC 3633 added prefix delegation, a novel functionality with no equivalent in DHCPv4. RFC 3736 extended the protocol’s capabilities to support configuration of clients using stateless address autoconfiguration.

The Internet Systems Consortium (ISC) played a decisive role in the development of DHCP. The organization maintains two major systems: ISC DHCP and Kea. Ted Lemon and Vixie Enterprises wrote the first implementation, ISC DHCP, as a reference for the new protocol. Version 1.0 was released in June 1998, followed a year later by version 2.0. Version 3.0, published in 2001, integrated support for the IETF failover standard and asynchronous DDNS updates. Version 4.0, in 2007, brought IPv6 support.

A dedicated engineering team has been working on ISC DHCP since 2004. Ted Lemon and Shawn Routhier, former ISC employees, contributed to the project for many years. Thomas Markwalder has been the primary maintainer since 2016, while Francis Dupont has been actively involved in maintaining the software since 2007. The community has enriched the project with an LDAP lease storage system and a lease display script.

Kea represents an entirely new implementation, intended to replace the aging ISC DHCP. Initially designed within the BIND 10 application framework to support multiple DNS and DHCP applications, the project refocused on DHCP after DNS development was discontinued in 2014. Tomek Mrugalski and Marcin Siodelski led the initial development of Kea, which stands out for its modern REST management interface and modular architecture. Unlike ISC DHCP, Kea separates the DHCPv4, DHCPv6 and dynamic DNS daemons, and offers optional libraries to extend the core DHCP server functionality.

The DHCP community has organized itself around complementary tools. The perfdhcp software, distributed with Kea, evaluates DHCP server performance by generating heavy traffic from multiple simulated clients. It tests both IPv4 and IPv6 servers, providing statistics on response times and lost requests. The Anterius project, part of ISC’s Google Summer of Code program, demonstrated the possibility of developing a lightweight management dashboard for Kea. More recently, the Stork project, launched in 2020, offers a robust and extensible web interface, integrating with the Prometheus time-series database and the Grafana visualization tool.

DHCP illustrates the adaptability of network protocols to the changing needs of computing. From a simple automatic configuration tool, it has evolved into a sophisticated system managing dynamic address allocation in modern networks. Its continued development, driven by an active community, ensures its lasting relevance in the face of contemporary network infrastructure challenges.