DHCP
Dynamic Host Configuration Protocol · Application layer
A machine that has just joined a network knows nothing — not its own address, not the gateway, not which resolver to ask. DHCP is the four-message exchange that configures it, starting from a broadcast because it has no address to send from.
Understand these first
- Why does this protocol exist?
- A machine joining a network has no address, no mask, no gateway and no resolver. Configuring all four by hand does not scale, and a machine cannot ask for them using IP because it has no IP yet.
- Which problem does it solve?
- Get a full network configuration to a machine that cannot yet be addressed, and reclaim it when the machine leaves.
- Who participates?
- A client with no address, one or more servers, and optionally a relay agent when the server is on another subnet.
- Which layer uses it?
- Application layer over UDP — client port 68, server port 67. Built on the older BOOTP message format.
- What does it depend on?
- UDP broadcast, and therefore the ability to send from 0.0.0.0 to 255.255.255.255 before having an address at all.
- What depends on it?
- Everything the client does afterwards. A wrong or missing gateway or resolver from DHCP produces failures blamed on other protocols for hours.
- What state does each participant maintain?
- The server holds a pool of addresses and a lease per client, with an expiry. The client holds its lease and two timers: T1 at half the lease, when it tries to renew with its own server, and T2 later, when it broadcasts to any server.
- Which fields matter?
- message type (option 53) — All eight: DISCOVER, OFFER, REQUEST, DECLINE, ACK, NAK, RELEASE, INFORM. The packet shape is identical for every one of them; this option is the only thing that says what it means.
- yiaddr — 'Your address' — the address being offered. Not in the IP header, because the client cannot use it yet.
- option 1 / 3 / 6 — Subnet mask, router, DNS servers. An address without these is nearly useless, which is a lesson in its own right.
- xid — Transaction id tying the four messages of one exchange together across broadcasts.
- What does normal behaviour look like?
- DISCOVER broadcast, OFFER, REQUEST broadcast (announcing which offer was accepted, so the other servers can release theirs), ACK. Four messages, then nothing until the lease is half gone.
- What does failure look like?
- DISCOVER repeating with no OFFER (no server reachable, or the pool is exhausted). NAK in response to a REQUEST (the client asked for an address it may not have). Or an ACK that is missing option 3, giving a client that can reach its own subnet and nothing else.
- How can I prove the diagnosis from packets?
- Read the options in the ACK, not just the address. Most 'DHCP worked but the network is broken' cases are a complete exchange with a missing or wrong gateway or resolver option.
- How does it interact with the rest of the stack?
- DHCP runs before IP is usable and configures the parameters every later protocol assumes: the address IP uses, the gateway the routing decision uses, the resolver DNS uses. It is the first thing in a full journey and the reason the rest can start.
DORA — Discover, Offer, Request, Acknowledge — is the initial allocation only. Renewal at T1 is a unicast REQUEST and ACK, with no DISCOVER and no OFFER.
Guided course — 5 lessons
Read in order. Every lesson pauses the capture on the packets it is talking about, and every one reads at three levels — so the time below is an estimate from the number of steps, not a measurement of anybody.
- 1DHCP-01How a Machine Gets an AddressThe bootstrapping problem, and the four messages that solve it≈15 min · 9 steps · 4 questions · guidedNot started
- 2DHCP-02Troubleshooting: An Address Is Not EnoughWhen the lease succeeds and the network still does not work≈10 min · 7 steps · 3 questions · guided · diagnosis lab · after dhcp-getting-an-addressNot started
- 3DHCP-03The Lease LifecycleDORA happens once; renewal is a different exchange entirely≈15 min · 8 steps · 3 questions · guided · after dhcp-getting-an-addressNot started
- 4DHCP-04The Messages You Rarely SeeDECLINE, RELEASE and INFORM — and why none of them is acknowledged≈15 min · 9 steps · 3 questions · guided · diagnosis lab · after dhcp-the-lease-lifecycleNot started
- 5DHCP-05Across a RouterHow a broadcast reaches a server it cannot possibly reach≈15 min · 8 steps · 3 questions · guided · after dhcp-getting-an-addressNot started
Troubleshooting labs — 2
A symptom, a capture, and no answer given. Each one is a lesson from the course above, listed again here because the diagnosis is worth coming back for.
Packet explorer — 11 scenarios, no coaching
A laptop joins the network knowing nothing — not its address, not the gateway, not a resolver. Four broadcast messages later it has all three. Watch the source address on the first two packets.
Two servers, one choiceBoth servers offer an address. The client takes the first and names that server in its REQUEST — which is broadcast precisely so the other server hears it and releases the address it had set aside.
Renewal at T1A short lease, so the renewal happens while you watch. Two things change: the request is unicast rather than broadcast, and it carries the client's own address — because by now it has one.
DHCPNAK — that address is not valid hereThe client asks for an address and the server refuses. A NAK usually means the machine moved to a different subnet while holding an old lease — the classic symptom of a laptop carried between offices.
No DHCP server on the segmentThe DISCOVER goes out and nothing replies. With no address the machine cannot do anything at all — which is why systems fall back to a self-assigned 169.254 address that reaches neighbours and nothing else.
Troubleshooting: address but no gatewayThe lease completes and the machine has an address. But the server omitted the router option, so nothing beyond this subnet is reachable. Local traffic works perfectly — which is what makes this so confusing to diagnose.
The pool is emptyEvery address is already leased, so the server says nothing at all. There is no 'pool full' message in DHCP — the client experiences silence, indistinguishable from a dead server.
DHCPDECLINE — that address is already in useThe server offers 10.0.1.55 in good faith. Before using it the client asks the segment whether anybody already has it — and somebody does, because a printer was configured by hand inside the DHCP range. Watch the client refuse a lease it has already been granted.
DHCPRELEASE — handing the address backA laptop is shut down properly, so it returns its address instead of leaving it stranded until the lease expires. One packet, no reply, and the lease table is shorter afterwards. Watch the client's routing table empty at the same moment.
DHCPINFORM — settings without an addressThis host was configured by hand and needs no lease, but it still does not know which resolver to use. One request, one reply, and nothing is allocated: no yiaddr, no lease time, and no new row in the lease table.
Across a router: the relay agentThe client is on the office LAN and the only DHCP server is on the server LAN. A router does not forward broadcasts, so the DISCOVER cannot reach it — and yet the lease still completes. The field that makes it work is giaddr.
Reference material
The terms this module introduces, and the specifications behind them. Both lists come from the lessons themselves rather than from a list kept beside them.
That you can say what a lease actually delivers, and recognise a configuration fault by its effects further up.
Where DHCP sits in a real request
These captures run DHCP as one stage of a longer chain, and hand its result to whatever comes next.
You plug in a laptop and type a name. Four protocols run before a single byte of the page is requested, and each one exists because the one before it could not do this job. Watch what each stage hands to the next.
Opening a secure websiteThe same four stages, plus one: before any request is sent, the server has to prove it is the server. Note what a capture can still read after encryption starts — and what it cannot.
Diagnosis: nothing works at allThe laptop reports no network connection. One stage in this capture never completes, and every later stage is missing entirely — which is itself the clue.
Diagnosis: local machines work, the internet does notPrinting works. The intranet works. Anything outside this LAN times out. The laptop has an address, so the problem is further along.
Diagnosis: the settings look correctAddress, mask, gateway and resolver all match the documentation. Traffic off the LAN still fails. The configuration is not the problem.
Diagnosis: one site fails, everything else is fineOther sites load normally. This one fails instantly — not slowly, instantly. That timing is a clue in itself.
Diagnosis: the site is reachable but refusesThe name resolves and the server is clearly alive — it answers immediately. It just will not accept the connection.