DHCP & IPAM — Trivia & Interesting Facts¶
Surprising, historical, and little-known facts about DHCP, IP address management, and dynamic addressing.
DHCP replaced three protocols before getting it right¶
Before DHCP (RFC 2131, 1997), the Internet tried RARP (1984), BOOTP (1985), and various ad-hoc schemes for dynamic address assignment. RARP required a server on every network segment because it worked at Layer 2. BOOTP was better but used static mappings. DHCP added dynamic allocation and lease times, finally solving the "give me any available address" problem after 13 years of iteration.
The DORA handshake is deliberately chatty for a reason¶
DHCP uses four messages — Discover, Offer, Request, Acknowledge — even though two would theoretically suffice. The four-step process exists because multiple DHCP servers may respond to a Discover, and the client needs to explicitly Request from one server while implicitly rejecting the others. The Request is broadcast (not unicast) specifically so the losing servers know to release their offered addresses.
DHCP relay agents are the reason DHCP works on modern networks¶
Without relay agents (RFC 3046), you would need a DHCP server on every broadcast domain. The relay agent — usually built into the router — intercepts DHCP broadcasts and forwards them as unicast to a central server, inserting the "giaddr" (gateway IP address) field so the server knows which subnet the request came from. This simple forwarding mechanism is what allows a single DHCP server to serve thousands of subnets.
Option 82 lets you track exactly which switch port a device is on¶
DHCP Option 82 (Relay Agent Information), defined in RFC 3046, allows the relay agent to insert the circuit ID (switch port) and remote ID (switch hostname) into the DHCP request. This means the DHCP server can assign addresses based on physical location — port 3 on switch-floor2 always gets a specific address — and is the foundation of 802.1X + DHCP integration for network access control.
DHCP leases were designed around 1990s IP address scarcity¶
The concept of "leasing" an IP address for a limited time was driven by the genuine fear of IPv4 address exhaustion in the early 1990s. If a laptop left the network, its address would eventually be reclaimed. The typical default lease time of 24 hours was a compromise — short enough to reclaim addresses, long enough to avoid constant renewal traffic. Many networks today still use this default even though their address space is not scarce.
DHCP starvation attacks can down an entire network¶
An attacker can request every available address in a DHCP pool by spoofing different MAC addresses in rapid succession. Once the pool is exhausted, no legitimate device can obtain an address. This attack — called DHCP starvation — is trivially easy with tools like Yersinia or gobbler, and it is why DHCP snooping and port security are critical on access switches.
Rogue DHCP servers are one of the most common accidental outages¶
When someone plugs a home router into a corporate network with its DHCP server enabled, it can start handing out addresses from a 192.168.1.0/24 pool on a network that uses 10.0.0.0/8. Devices that accept these rogue offers get wrong addresses, wrong gateways, and wrong DNS servers — effectively falling off the network. DHCP snooping was invented specifically for this problem, designating only certain switch ports as trusted DHCP sources.
IPAM spreadsheets were the industry standard until embarrassingly recently¶
Before dedicated IPAM tools, most organizations tracked IP address assignments in Excel spreadsheets. As late as 2015, surveys showed that over 40% of enterprises still used spreadsheets as their primary IPAM tool. The inevitable result was duplicate assignments, stale entries, and the new engineer who sorted the spreadsheet and destroyed the formatting.
DHCPv6 exists but is losing to SLAAC¶
IPv6 offers two auto-configuration methods: DHCPv6 (RFC 8415) and SLAAC (Stateless Address Autoconfiguration, RFC 4862). SLAAC lets hosts generate their own addresses from the router-advertised prefix without any server. Android famously refused to implement DHCPv6 for years (until Android 11), forcing network designs to support SLAAC. The DHCPv6 vs. SLAAC debate is one of the longest-running arguments in IPv6 deployment.
DHCP failover was not standardized until 2004 — and it's still messy¶
RFC 3074 proposed a DHCP failover protocol in 2001, but the actual ISC DHCP failover implementation has been notoriously fragile. The two servers must agree on lease state, which requires careful synchronization. Many organizations gave up on native DHCP failover and instead use split-scope (each server owns half the range) or rely on load balancers, neither of which is elegant.