DHCP: The DORA Exchange
Last updated:
Four packets, mostly broadcast, all UDP (client 68 → server 67):
| Step | Packet | From → To | Purpose |
|---|---|---|---|
| D | Discover | client → broadcast | "Any DHCP servers out there?" |
| O | Offer | server → client | "Here's an address you could have" |
| R | Request | client → broadcast | "I'll take that one" (also announces choice to losing servers) |
| A | Ack | server → client | Lease confirmed + options (mask, gw, DNS) |
The client broadcasts the Request too — that's how other offering servers learn they lost and can return their offers to the pool.
Leases and renewal
- At T1 (50% of lease) the client unicasts a renewal Request to its server.
- At T2 (~87.5%), still no answer → it broadcasts, willing to rebind to any server.
- Lease expiry → back to square one: Discover.
DHCP relay
Broadcasts don't cross routers. On the client VLAN's gateway, a relay agent (ip helper-address in Cisco-speak) converts the broadcast to a unicast toward the DHCP server and stamps the client subnet into giaddr so the server picks the right pool. One central server, hundreds of VLANs.
Rogue DHCP servers
A stray "helpful" home router on the office LAN answers Discovers faster than your real server and hands out garbage. The defense is DHCP snooping: switches drop server-messages (Offer/Ack) arriving on untrusted ports.