What is DHCP and why do we need it?

DHCP — the Dynamic Host Configuration Protocol — automatically assigns IP addresses, gateways, and DNS server settings to devices when they join a network. Without DHCP, every device would need to be configured by hand with a unique IP, a subnet mask, a default gateway, and DNS servers. DHCP eliminates that manual work and prevents the address collisions that hand-configuration almost always produced.

How long is a DHCP lease?

It depends entirely on the server's configuration. Home routers default to 24 hours. Corporate Wi-Fi networks often use 8-12 hour leases to match a workday. Hotspot networks may use 1-2 hour leases to recycle addresses faster as people come and go. ISP DHCP for residential connections frequently uses 7-day or longer leases. The client requests a renewal halfway through the lease, so the actual rate of network churn is much lower than the lease duration suggests.

What is a 169.254.x.x address?

That is the APIPA (Automatic Private IP Addressing) fallback range, also called the link-local block under RFC 3927. Windows and macOS hand devices a random 169.254.x.x address when DHCP fails entirely. The device can talk to other devices on the same physical segment that also fell back, but cannot reach the internet. If you see 169.254 in your network settings, your DHCP server is unreachable.

Should I use a static IP or a DHCP reservation?

A DHCP reservation is almost always better. With a static IP you configure each device by hand, which means three things will eventually go wrong: someone else's device will collide with the address, the subnet will be renumbered and you'll have to revisit every device, and configuration drift will leave one machine with the wrong gateway after a network change. A DHCP reservation is keyed on MAC address — the router always gives that one machine the same IP, but if you renumber the LAN, you change the reservation in one place.

It depends. IPv6 has two address-assignment paths: SLAAC (Stateless Address Auto-Configuration), where the router advertises a prefix and the host generates its own address, and DHCPv6, the stateful equivalent to IPv4 DHCP. The most common deployment is a hybrid — the host gets its address via SLAAC and pulls DNS servers and other options from DHCPv6. Home routers almost always do SLAAC only; corporate networks frequently run the hybrid.

How DHCP works — the protocol that hands out IP addresses, explained

Why DHCP exists

In the early TCP/IP era, every machine on a network had to be configured by hand with four things: a unique IP address, a subnet mask telling it which addresses were "local," a default gateway IP telling it where to send everything else, and a list of DNS resolvers. Forget any of the four and the device worked partially or not at all. Get any one of them wrong and the troubleshooting was painful — IP collisions in particular look like intermittent failures rather than clear errors.

DHCP, standardized in RFC 2131 (1997) as a successor to the earlier BOOTP protocol, automates all of that. A central server hands out leases from a pool of addresses; the client just asks for one when it joins the network and gets back a full configuration ready to use. Today every consumer router and every enterprise switch fabric runs DHCP by default — you almost never see a hand-configured client outside of servers, printers you want to find at a predictable address, or specialized infrastructure.

The four-step handshake: DORA

Mnemonic: Discover, Offer, Request, Acknowledge. Every DHCP transaction starts with these four packets, in this order, broadcast to the network so any DHCP server on the segment can hear them.

DHCPDISCOVER. A new client (or one with an expired lease) broadcasts a UDP packet to 255.255.255.255 on port 67, from source port 68. "Is there a DHCP server out there? I need an IP. My MAC address is X." Because the client has no IP yet, it uses 0.0.0.0 as the source — the broadcast destination is how it reaches a server.
DHCPOFFER. Any DHCP server with a free address in its pool replies: "Here is an IP, here is the subnet mask, here is the gateway, here are the DNS servers, the lease is valid for N seconds." On a network with a single DHCP server (the home case), there's just one offer. On a network with a primary and a backup server, the client may receive multiple offers and pick the first.
DHCPREQUEST. The client formally accepts one offer by broadcasting it. The broadcast lets any other DHCP servers know which offer was accepted, so they can return the addresses they had reserved back to their pool.
DHCPACK. The chosen server confirms the assignment with a final ACK. The client configures its interface, the lease starts ticking down, and ordinary traffic can flow.

Total round-trip: usually under 100 ms on a quiet LAN. If you have ever watched a phone show "connecting…" for noticeably longer than that, something else (Wi-Fi association, captive portal probing, IPv6 router solicitation) is the bottleneck — not the DHCP handshake itself.

The lease lifecycle

A DHCP lease isn't a one-shot deal. The server hands you an address for a finite period (the lease time), with two checkpoints called T1 and T2.

T1 = 50% of the lease. The client unicasts a DHCPREQUEST directly to the server that originally granted the lease, asking to extend. If the server replies ACK, the lease resets to its full duration.
T2 = 87.5% of the lease. If the original server hasn't replied by now, the client broadcasts DHCPREQUEST to the whole segment, hoping some other DHCP server will pick it up. This is the failover path.
100% — expiry. No reply by the end of the lease and the client must relinquish the address. The interface goes back to "no IP." It tries DISCOVER from scratch.

A client can also voluntarily release a lease with DHCPRELEASE — for example, when you disconnect from Wi-Fi cleanly. Some operating systems do this enthusiastically; others (notably mobile OSes that try to roam fast) skip the release and just let the lease expire on the server side.

DHCP options — the surprising number of things DHCP can configure

The OFFER and ACK packets aren't just "here's an IP." They include a list of TLV-encoded options, identified by a numeric code. There are over 150 defined options; the ones that matter most in practice:

Option 1 — subnet mask.
Option 3 — default router (gateway).
Option 6 — DNS servers.
Option 15 — domain name.
Option 42 — NTP servers (useful so devices set their clocks correctly without leaking traffic to pool.ntp.org).
Option 43 — vendor-specific (used by Cisco for AP-controller discovery, by Microsoft for SCCM, etc.).
Option 51 — lease duration (in seconds).
Option 66 / 67 — TFTP boot server / boot filename (PXE boot relies on this).
Option 121 — classless static routes; lets DHCP push specific routes to a client beyond the default gateway. Increasingly used by VPN-aware home networks.

Most of the friction in enterprise DHCP rollouts is about getting the right combination of options to the right client class — VoIP phones need different options from laptops, PXE-booting workstations need others again, BYOD devices need a sandboxed set.

Reservations vs. static IPs

For devices you want at a predictable address (printers, NAS, the home server hosting Plex), the right tool is a DHCP reservation, not a hand-configured static IP. A reservation tells the DHCP server "when you see MAC address X, always offer the same address." Three benefits over a static IP:

You change subnets once, in the DHCP server's configuration. The device picks up the new range on next renewal without any configuration on the device itself.
The DHCP server keeps the reserved address out of the general pool, so a random laptop never accidentally gets it.
You have a single inventory of all assigned addresses — useful when troubleshooting and useful when handing the network over to someone else.

IPv6's two paths — SLAAC and DHCPv6

IPv6 changes the picture. The protocol design assumed that the address space was big enough that every device could pick its own address without coordination, so the default assignment mechanism is SLAAC (Stateless Address Auto-Configuration):

The router periodically broadcasts a Router Advertisement (RA) containing the network prefix (the first 64 bits) and the gateway.
The host appends an interface identifier — historically derived from the MAC address, now usually a random opaque value (RFC 7217) for privacy.
The host performs Duplicate Address Detection by sending an unsolicited neighbor solicitation; if no one objects, the address is taken.

SLAAC alone doesn't provide DNS or NTP. For that, the host either uses the RDNSS option inside the Router Advertisement (RFC 8106) or runs DHCPv6 in stateless mode to pull configuration from a server. DHCPv6 stateful mode is closer to IPv4 DHCP — the server tracks each address it has handed out and the host requests one explicitly. Enterprise IPv6 deployments almost always run DHCPv6 stateful so they can audit address ownership the same way they did under IPv4.

Common failure modes

Address conflicts

Two devices end up on the same IP. Usually because someone hand-configured a static IP inside the DHCP pool. Symptoms: intermittent disconnects, especially when one of the two devices comes or goes. Fix: either move the static device outside the DHCP pool's range or convert it to a DHCP reservation. Most modern DHCP servers (ISC, Microsoft, MikroTik) ARP-probe before offering an address to catch this preemptively.

Rogue DHCP servers

Anyone on the broadcast domain can run a DHCP server. The fastest reply wins. If a rogue server hands out incorrect gateways or DNS, every device that lands on it routes its traffic through the attacker. This is a classic LAN attack. The mitigation is DHCP snooping on managed switches, which lets you mark specific ports as "trusted" — only DHCP offers from those ports are forwarded.

Pool exhaustion

The DHCP server has handed out every address in its pool. New devices fail to get one. Symptoms: a guest network where the third visitor of the day can't connect even though two have left. Fixes: shorten the lease time so addresses recycle faster, grow the pool, or split visitors onto multiple subnets.

Stuck APIPA (169.254.x.x)

When DHCP fails completely, Windows and macOS fall back to a random address in the 169.254.0.0/16 range. Devices can talk to each other on the same segment but cannot reach the internet. Seeing a 169.254 address is your tell that DHCP is broken — either the server is unreachable or there's a Layer 2 problem stopping the DISCOVER broadcasts from reaching it.

DHCP starvation attacks

A malicious device spams DHCPDISCOVER from random MAC addresses, requesting every IP in the pool. The pool exhausts, new clients fail. Mitigated by port-security on switches (limit the number of MAC addresses per port) and by DHCP snooping rate-limiting.

How to inspect DHCP from a client

macOS: ipconfig getpacket en0 — dumps the most recent DHCP ACK in full, including every option that came back.
Linux: dhcpcd -T eth0 for a dry-run that shows what the server would offer; journalctl -u systemd-networkd-dhcpd for current state.
Windows: ipconfig /all shows the current lease; ipconfig /release + ipconfig /renew forces a fresh handshake.
Across the wire: tcpdump -i any -n port 67 or port 68 captures DHCP traffic. Wireshark decodes every option human-readably.

How DHCP works