A host with no address has a problem
Everything so far assumed a host already knows its own address, mask, gateway, and resolver. Somebody has to provide those, and typing them by hand on every laptop, phone, and printer does not scale. DHCP (dynamic host configuration protocol) hands them out automatically.
A newly connected host needs at least five things, and DHCP delivers all of them in one exchange.
| Item | Example | DHCP option number |
|---|---|---|
| IP address and prefix | 192.168.1.42/24 | in the packet, plus option 1 |
| Default gateway | 192.168.1.1 | 3 |
| DNS resolvers | 192.168.1.1, 1.1.1.1 | 6 |
| Search domain | home.example.com | 15 |
| Lease time | 86400 seconds | 51 |
The awkward part is the bootstrap. The host has no address, so it cannot be the destination of a normal unicast reply, and it does not know the server's address either. DHCP solves both with broadcast, which is why it lives at UDP ports 68 on the client and 67 on the server, and why it only works inside one broadcast domain unless a relay helps, as covered below.
DORA, four messages
The exchange is named for its four steps: Discover, Offer, Request, Acknowledge.
| Step | Direction | Source | Destination | Meaning |
|---|---|---|---|---|
| DISCOVER | client to all | 0.0.0.0:68 | 255.255.255.255:67 | is any DHCP server there |
| OFFER | server to client | server:67 | broadcast:68 | here is an address you may have |
| REQUEST | client to all | 0.0.0.0:68 | 255.255.255.255:67 | I accept that offer, formally |
| ACK | server to client | server:67 | broadcast:68 | confirmed, it is yours, with options |
Two questions this raises, both with satisfying answers.
Why is the REQUEST broadcast when the client already knows which server it wants? Because there may be several servers, and each one made a tentative offer. Broadcasting the acceptance, which names the chosen server in option 54, tells the others to release their reserved addresses. Without that step, three servers would each hold an address for a client that took only one.
Why not just take the offered address after step 2? Because the offer is not a commitment. The formal request and acknowledgment make the lease definite and give the server a chance to say DHCPNAK if the address became unavailable in the meantime.
Two further messages exist. DHCPDECLINE is sent by a client that discovers the offered address is already in use, which it checks with a gratuitous ARP from Lesson 3-3. DHCPRELEASE politely gives a lease back early, which is what a laptop sends when you disconnect cleanly.
Leases, renewal, and relays
A DHCP assignment is a lease with an expiry, not a permanent grant, so addresses return to the pool when devices leave. Renewal runs on two timers measured from the start of the lease.
| Timer | When | Client action |
|---|---|---|
| T1 | at 50 percent of the lease | unicast a REQUEST to the same server to renew |
| T2 | at 87.5 percent | broadcast a REQUEST, any server may answer |
| Expiry | at 100 percent | give up the address and start DORA from scratch |
Renewal at T1 is a unicast, which is a small but useful detail: the client knows its own address by then, so no broadcast is needed and the exchange is two messages rather than four.
A DHCP server must be reachable by broadcast, and broadcasts stop at routers from
Lesson 3-2. Large networks do not want a server in every VLAN, so routers run a
DHCP relay agent. The relay receives the broadcast, records its own interface
address in the packet's giaddr field, and forwards it as a unicast to a
central server. The server reads giaddr, sees which subnet the client is on, and
picks an address from the right pool. Replies go back through the relay.
Also worth knowing:
- A reservation, sometimes called a static mapping, ties one MAC address to one fixed IP in the server's configuration. This is the right way to give a printer a stable address, because the network keeps control of the plan. - An exclusion range keeps part of a subnet out of the dynamic pool for manually configured devices such as routers and switches. - Option 82, the relay agent information option, lets the relay add which switch port the request came from, so the server can assign by physical location.
When DHCP fails
The symptom is unmistakable once you know the address ranges from Lesson 4-2.
ip -4 addr show dev eth0inet 169.254.212.9/16 brd 169.254.255.255 scope link eth0
A 169.254.x.x address means the host sent DISCOVER packets, heard nothing, and self assigned a link local address. That address can reach other machines on the same link that also self assigned, and nothing else, because there is no gateway and no resolver. Every symptom the user reports will sound like a DNS or internet problem, and none of them are.
The causes, roughly in order of frequency:
1. The link is down, or the switch port is in the wrong VLAN, so the broadcast reached no server at all. 2. The DHCP server or its service is down. 3. The pool is exhausted, every address leased. Common in guest networks with long lease times and short visits, and the fix is a shorter lease. 4. A relay is missing or misconfigured on a routed subnet. 5. A rogue DHCP server, often somebody's home router plugged in backwards, answering faster than the real one and handing out a useless gateway. Switch features such as DHCP snooping exist to block server messages from ports that should not have any.
sudo dhclient -v eth0
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7 DHCPOFFER of 192.168.1.42 from 192.168.1.1 DHCPREQUEST for 192.168.1.42 on eth0 to 255.255.255.255 port 67 DHCPACK of 192.168.1.42 from 192.168.1.1 bound to 192.168.1.42 -- renewal in 41893 seconds
That output is DORA, one line per message, with the retry interval doubling on each unanswered DISCOVER. When only the first two lines ever appear, the problem is on the list above and not on the client.