DHCP — Dynamic Host Configuration — Computer Networks

What it is#

DHCP (Dynamic Host Configuration Protocol, RFC 2131) is the protocol your laptop uses to acquire an IPv4 address — and a lot more — when it joins a new network. A fresh host knows nothing about the LAN: no IP, no subnet mask, no gateway, no DNS resolver. DHCP gives it all of those in a single four-message exchange and a lease.

DHCP runs on UDP — server port 67, client port 68 — and is descended from BOOTP (RFC 951, 1985). The protocol predates IPv6 by years. Its IPv6 cousin DHCPv6 (RFC 8415) exists but is partially eclipsed by SLAAC; many IPv6 deployments use SLAAC for addressing and DHCPv6 only for DNS resolver discovery.

The four-message exchange — DISCOVER, OFFER, REQUEST, ACK, conventionally called DORA — is the part to memorise. The lease lifecycle (renew at half-life, rebind at seven-eighths, fall back to DISCOVER on expiry) is what determines how robust the protocol is to packet loss and server outage.

When to use it#

DHCP is the default address assignment for almost any client device on almost any network — corporate LANs, home Wi-Fi, hotel networks, mobile hotspots, cloud VPCs (where the hypervisor’s DHCP server hands out the IP your eth0 got). You think about DHCP explicitly when:

Setting up a new network. Pick a DHCP server (ISC dhcpd, Kea, dnsmasq, Windows DHCP, Cisco IOS DHCP), define a pool, set lease times.
Provisioning servers. Static IPs by reservation (MAC-pinned) so the host always gets the same address but configuration is centralised.
Network bootstrapping. PXE boot uses DHCP options to point a diskless machine at a TFTP / HTTP boot image.
Cloud and Kubernetes. AWS/GCP/Azure DHCP options sets define DNS resolvers and search domains for the VPC. Kubernetes CNIs sometimes use DHCP at the node level, IPAM internally for pods.
Debugging IP collisions. Two boxes serving DHCP on the same LAN (rogue server) is a classic failure — clients flip between offers and the broken router’s address.

Static IP assignment still has a role: routers themselves, anything that must be reachable before the DHCP server is up, and some HA setups. Everything else should be DHCP-managed.

How it works#

The DORA exchange#

Client (no IP)                                DHCP Server
0.0.0.0:68                                    192.0.2.1:67
   |                                                |
   | -- DISCOVER (broadcast 255.255.255.255) -----> |
   |    src 0.0.0.0  dst 255.255.255.255            |
   |    options: requested IP (optional), client    |
   |             identifier, parameter list         |
   |                                                |
   | <-- OFFER (broadcast or unicast) ------------- |
   |     yiaddr = 192.0.2.50                        |
   |     options: lease time, subnet mask, gateway, |
   |              DNS, server identifier            |
   |                                                |
   | -- REQUEST (broadcast) ----------------------> |
   |    options: requested IP = 192.0.2.50,         |
   |             server identifier (echoes chosen)  |
   |                                                |
   | <-- ACK (broadcast or unicast) --------------- |
   |     yiaddr = 192.0.2.50, lease confirmed       |
   |                                                |
   | (client configures interface, starts using IP) |

The reason DISCOVER is broadcast is the host has no IP yet — src=0.0.0.0 cannot receive a unicast reply. The reason REQUEST is broadcast is to inform other DHCP servers on the LAN that the client has chosen one offer (they release their reservations).

The four messages, in detail#

DISCOVER (Type 1). “Anyone willing to lease me an IP?” Source 0.0.0.0, dest 255.255.255.255. Carries the client’s MAC in the chaddr (client hardware address) field — this is what the server uses to identify the client.
OFFER (Type 2). Server proposes an IP (in yiaddr — “your address”), the lease duration, the subnet mask, the gateway, DNS resolvers, and a server identifier. Multiple servers may offer; the client picks one (usually the first).
REQUEST (Type 3). Client formally requests the chosen IP from the chosen server. Carries the requested IP and the chosen server identifier in options.
ACK (Type 5). Server confirms the lease. Client configures the interface, sends a Gratuitous ARP to detect duplicates, and starts using the address.

There’s also NAK (Type 6) — server refuses (e.g., the requested IP is no longer available, the client moved subnets) — and DECLINE (Type 4) from the client when ARP detects the IP is already in use.

Lease lifecycle#

Time 0     ACK received, lease starts                          t = 0
Time T/2   Renewal — unicast REQUEST to leasing server         t = T/2
Time 7T/8  Rebinding — broadcast REQUEST to any server         t = 7T/8
Time T     Lease expires — release IP, restart DISCOVER        t = T

T is typically ~24 hours for home Wi-Fi, ~8 hours for corporate, ~1 hour for hotspots, and as short as a few minutes for cloud bootstrap pools. The client tries to renew with the original server first; if that fails, it broadcasts to any server (rebinding). Only if both fail does the client give up the address and start over.

Options — the meat of DHCP#

The message header is short; the real configuration lives in TLV (type-length-value) options at the end. The ones you’ll set in every deployment:

Option  Meaning
 1      Subnet mask
 3      Default gateway
 6      DNS resolvers
12      Hostname
15      Domain name
26      Interface MTU
28      Broadcast address
50      Requested IP address
51      Lease time (seconds)
53      DHCP message type (DISCOVER/OFFER/REQUEST/ACK/NAK/DECLINE/RELEASE)
54      Server identifier
55      Parameter request list (what the client wants to know)
58      Renewal (T1) time
59      Rebinding (T2) time
60      Vendor class identifier (PXE, etc.)
66      TFTP server name (PXE boot)
67      Bootfile name (PXE boot)
121     Classless static routes (RFC 3442) — replaces option 33

DHCP relays#

DHCP DISCOVER is a broadcast — it does not cross routers. To centralise DHCP across many subnets, configure the gateway as a DHCP relay (ip helper-address on Cisco). The relay receives the broadcast, rewrites it as unicast to the upstream DHCP server, and stamps the giaddr (gateway IP) field so the server knows which subnet to lease from.

Variants#

DHCPv4 (RFC 2131). The default; what this writeup describes.
DHCPv6 (RFC 8415). IPv6 equivalent — stateful (server tracks leases) or stateless (server only provides options like DNS, addresses come from SLAAC). Uses multicast ff02::1:2 for “all DHCP relay agents and servers” instead of broadcast.
DHCP reservation / static mapping. Server pins a specific IP to a MAC. The address still comes through DHCP but is deterministic — preferred over fully static configuration for servers.
PXE / iPXE bootstrap. DHCP options 66/67 (or 209/210 for iPXE) point a booting machine at a TFTP / HTTP image. Provisioning workflows for bare-metal datacenters use this.
DHCPv6 prefix delegation (DHCPv6-PD). ISPs hand a customer router a whole /56 or /60 prefix; the router subdivides into /64s for internal networks. Used by every IPv6-enabled home gateway.
dnsmasq. Small DHCP + DNS-cache + TFTP server bundled — popular for home routers and small offices. Kea is the modern ISC replacement for the deprecated dhcpd.

Trade-offs#

DHCP (dynamic) — zero-touch on the client, centralised lease management, MAC-based reservations possible, supports PXE / vendor-specific options. Reliant on the server’s availability, broadcast traffic, vulnerable to rogue servers without snooping.

Static IP — survives DHCP-server outage, deterministic across reboots, no extra protocol. Tedious to manage, error-prone collisions, no central audit trail, doesn’t transfer when the host moves networks.

Other tensions:

Lease length. Long leases reduce DHCP traffic but waste IPs when devices come and go (coffee-shop Wi-Fi with a 24-hour lease and a 2-hour visit ties up an address). Short leases burn server capacity and add jitter to addresses.
DHCP vs SLAAC for IPv6. SLAAC needs no server but cannot push DNS resolvers (without RDNSS option, which Android only recently supported). DHCPv6 needs a server but gives full configurability. Many networks run both.
Centralisation. A single DHCP server is a single point of failure for new connections. Failover protocol (RFC 3074) or split scopes between two servers solves it.
Privacy. Client MAC, hostname, and vendor class are visible in every DHCP message. RFC 7844 (“anonymity profiles”) suggests minimising what the client sends; iOS / macOS / Android randomise per-SSID MACs by default.

Why is DISCOVER a broadcast even after the client knows the gateway?

The client typically does not know the gateway when DISCOVER is sent — that information arrives in the OFFER. Even on rebinding, the client broadcasts because the original server might be down and the goal is to reach any server willing to confirm the lease. The only unicast DHCP messages are RENEW (to the known leasing server) and the unicast variant of OFFER/ACK when the server believes the client can receive on the offered address.

Common pitfalls#

Rogue DHCP servers on a flat LAN. Bring up a home router with DHCP enabled on a corporate network and clients flip between offers. Enable DHCP snooping on managed switches.
Forgotten lease database. Restart dhcpd without preserving /var/lib/dhcp/dhcpd.leases and the server forgets which IPs are in use — duplicate assignments follow.
Ignoring duplicate-address detection (DAD). A client that skips Gratuitous ARP after ACK can collide with a host whose lease the server forgot.
Lease times tuned for the wrong workload. Cloud bootstrap pools want minute-scale leases; office networks want hours; long-lived datacenter servers want days or reservations.
PXE boot loops. Wrong TFTP server option, missing bootfile, or relay mis-stamped giaddr causes the booting host to receive an OFFER but fail to fetch the image — loops forever.
Cross-subnet DHCP without a relay. DISCOVER is broadcast and broadcasts don’t cross routers. Configure ip helper-address (or equivalent) on the gateway, or run a server per subnet.
MAC randomisation breaking reservations. Modern phones randomise MAC per SSID. A MAC-pinned reservation no longer matches; the device gets a dynamic lease instead.
Stale ARP after lease change. The DHCP server reassigns an IP to a different host; the gateway’s ARP cache still maps the old MAC. Either flush ARP on the gateway or wait ~60s.