DHCP
Every device on a network needs an IP address before it can do anything covered so far in this module — no address, no TCP handshake, no DNS query, nothing. Early networks solved this the only way available: someone typed a static address into every single machine by hand, kept a spreadsheet of what was assigned to what, and updated it manually whenever a device moved, was replaced, or left the network. That worked when a network had a dozen machines. It falls apart at the scale of a modern office, a university campus, or a home with fifteen phones, laptops, and smart-home devices joining and leaving constantly.
DHCP — Dynamic Host Configuration Protocol, specified in RFC 2131 — exists to automate exactly that assignment. A device joins a network, asks, and gets back an IP address plus everything else it needs to actually use that network, without a human touching a single configuration file.
The chicken-and-egg problem DHCP has to solve
A device requesting an IP address doesn't have one yet — that's the entire point of asking. Every protocol covered earlier in this course assumed both endpoints already had addresses; DHCP has to work before that assumption holds. It solves this with broadcast: the requesting device sends from 0.0.0.0, since it has no address of its own to use as a source, to the limited broadcast address 255.255.255.255, which every device on the local segment receives regardless of what address it currently holds.
DHCP runs over UDP, using two well-known ports: 67 on the server, 68 on the client. Both ends are fixed, unlike most UDP or TCP exchanges where only the server's port is well-known and the client picks an arbitrary ephemeral one — DHCP can't rely on that, because a client with no address yet also has no established session for an ephemeral port to belong to.
DORA: the four-message exchange
A device requesting an address for the first time goes through four messages, each one named for what it does:
- Discover — the client broadcasts, asking whether any DHCP server is listening at all.
- Offer — one or more servers respond, each proposing an address and lease terms.
- Request — the client broadcasts back which offer it's accepting (still a broadcast, so any other servers that made offers know theirs wasn't chosen and can release the address they'd tentatively reserved).
- Acknowledge — the chosen server confirms the assignment, and the client can now actually use the address.
12:00:01.102340 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:00:27:4e:66:a1, length 300
12:00:01.104881 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
12:00:01.312205 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:00:27:4e:66:a1, length 300
12:00:01.314552 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
Four packets, matching the four steps above — tcpdump's summary line doesn't distinguish Discover from Request by name, both show as BOOTP/DHCP, Request, and both server replies show as BOOTP/DHCP, Reply regardless of whether they're an Offer or an Acknowledge; telling them apart precisely means decoding the DHCP message-type option inside each packet, which a tool like Wireshark does automatically. This article covers the message format and the fields involved; walking the full state machine hop by hop, including what happens when a step fails or times out, gets its own dedicated, hands-on treatment later in the course.
DHCP's protocol format is inherited directly from BOOTP, its 1985 predecessor — which is why tcpdump still labels every DHCP packet BOOTP/DHCP — but BOOTP required a static, pre-configured mapping of hardware address to IP address on the server, no more automatic than manual assignment was. DHCP kept BOOTP's packet layout for compatibility and added the option fields, leases, and dynamic pool allocation that made real automation possible.
What actually gets handed out
An Offer and an Acknowledge don't just carry an IP address — DHCP options attach everything else a device needs to actually use the network, each option identified by a number defined in RFC 2132:
| Option | Name | Purpose |
|---|---|---|
| 1 | Subnet Mask | Which portion of the address identifies the network |
| 3 | Router | The default gateway to send off-network traffic to |
| 6 | Domain Name Server | Which DNS resolvers to query |
| 51 | IP Address Lease Time | How long, in seconds, this assignment is valid |
| 53 | DHCP Message Type | Marks the packet as Discover, Offer, Request, or Ack |
Handing all of this out in one exchange is the actual point of DHCP existing at all — a device doesn't just get an address, it gets a fully usable network configuration in four packets, with no per-field manual setup anywhere.
Leases expire, and renewal happens quietly
An assigned address isn't permanent. It's a lease, valid for the duration set by option 51, and the client is responsible for renewing it before it runs out — not the server pushing anything unprompted. Two internal timers drive this, both computed from the lease length:
- T1, at 50% of the lease, the client sends a unicast Request directly to the server that granted the lease, asking to renew.
- T2, at 87.5% of the lease, if T1's renewal attempt got no answer, the client broadcasts instead, willing to accept renewal from any server, not just the original one.
Under normal conditions, T1 succeeds quietly in the background and a device's user never notices a lease existed at all. A device woken from sleep after its lease has fully expired has to run the whole DORA process again from scratch, since a fully expired lease leaves nothing left to renew.
DHCP across routed networks: relay agents
Broadcast doesn't cross a router by default — that's precisely the boundary a broadcast domain is defined by. A DHCP server sitting on a different subnet than the client would never see the client's broadcast Discover at all, which is a real problem for any network with more than one subnet and only one central DHCP server.
A DHCP relay agent, usually running directly on the router or Layer 3 switch at the client's subnet boundary, solves this: it listens for DHCP broadcasts on its local segment, then forwards them as a unicast packet directly to the DHCP server's address, tagging the packet with the client's originating subnet so the server knows which address pool to offer from. The server's reply comes back through the same relay, which broadcasts it back out onto the client's original segment. From the client's point of view nothing about the DORA exchange looks any different — the relay is invisible to it, doing all of the routing that plain broadcast alone couldn't.
Practical scenario: new devices stop getting an address
A department's DHCP server has worked fine for months, but starting one afternoon, new devices joining the Wi-Fi fail to get an address at all, while devices already connected keep working normally. The server logs show Discover messages arriving and being answered — but with a specific message type, not a normal Offer:
DHCPNAK here means the server has no address left to give out — the pool defined for this subnet is fully allocated, every lease currently checked out to some device. This isn't a protocol failure; DHCP is behaving exactly as designed when a pool runs dry. The actual cause is almost always either genuine growth (more devices than the pool was originally sized for) or a lease time set too long relative to how often devices actually turn over — a lease of several days on a guest network where phones connect for an hour and never come back holds addresses reserved long after the devices that used them are gone. The fix is either enlarging the address pool (a larger subnet, or an additional scope) or shortening the lease time so abandoned addresses free up faster — not restarting the DHCP service, which does nothing to reclaim addresses that are still validly, if uselessly, leased out.
Where this goes wrong in practice
- Confusing a DHCP reservation with a static IP configuration. A reservation still runs through the full DORA exchange and still depends on the DHCP server being reachable; a genuinely static address, typed directly into the device, needs no DHCP server at all and keeps working even if the server is down.
- Forgetting that DHCP relay requires configuration on the router, not just the server. A DHCP server can be perfectly configured with the right pool and options and still never see a single request from a remote subnet if no relay agent is forwarding for it.
Practice exercises
- Run
sudo tcpdump -i any -n port 67 or port 68while reconnecting a device to Wi-Fi or renewing a lease withsudo dhclient -r && sudo dhclient(on a Linux test machine — not one you rely on for connectivity), and match each packet to a DORA step. - Using the scenario above, explain why shortening the lease time helps a pool-exhaustion problem while restarting the DHCP service does not.
- Explain, in terms of broadcast domains, exactly why a DHCP relay agent is needed on a network with client devices and the DHCP server on different subnets.
DHCP hands a device its IP address. But an IP address alone still isn't enough to put a single frame on the wire — something has to translate that freshly assigned address into the MAC address of whichever device is next in line, and that's precisely the gap ARP fills.