Difficulty: Intermediate
What is DHCP? Explain the DORA process, lease renewal, and how a DHCP server on another subnet can serve clients.
When you walk into a cafe and your phone connects to Wi-Fi, you do not type an IP address, subnet mask, gateway and DNS server. Something gave you all of that in a second. That something is DHCP, the Dynamic Host Configuration Protocol. It automates IP configuration so administrators do not maintain thousands of static entries and so addresses can be reused as devices come and go.
DHCP runs over UDP, with the server on port 67 and the client on port 68. The exchange is called DORA. Discover: the client has no IP, so it broadcasts a DHCPDISCOVER from source 0.0.0.0 to 255.255.255.255 asking is there a DHCP server. Offer: one or more servers reply with a DHCPOFFER containing a proposed IP, subnet mask, lease time, default gateway and DNS servers. Request: the client picks an offer and broadcasts a DHCPREQUEST naming the server it accepted, which also tells other servers to withdraw their offers. Acknowledge: the chosen server sends a DHCPACK confirming the lease. Only then does the client configure its interface. Discover and Request are broadcast because the client has no address yet and needs everyone to hear the choice.
The address is leased, not owned. Typically at 50 percent of the lease time (T1) the client tries to renew by sending a unicast DHCPREQUEST to the same server. If that fails, at 87.5 percent (T2) it broadcasts a request to any server. If the lease expires without renewal, the client must stop using the address and start again with Discover. Clients can also send DHCPRELEASE when shutting down gracefully. Administrators can set reservations, which pin a specific IP to a device's MAC address, useful for printers and servers.
Broadcasts do not cross routers, so how does one central DHCP server serve fifty subnets? With a DHCP relay agent (configured as ip helper-address on Cisco gear). The router hears the broadcast on a client subnet, converts it into a unicast packet to the DHCP server, and stamps in the giaddr field, the gateway address, so the server knows which subnet the client is on and picks an address from the right pool. The reply travels back through the relay.
Edge cases and troubleshooting are what make this answer strong. If no server answers, Windows falls back to APIPA, an address in 169.254.0.0/16, and Linux clients often do the same with link-local. A rogue DHCP server, say someone plugging in a home router into an office port, can hand out wrong gateways and DNS, enabling traffic hijacking; the fix is DHCP snooping on switches, which only allows DHCP offers from trusted ports. A DHCP starvation attack floods requests with fake MACs to exhaust the pool. Address conflicts are prevented by the server pinging the candidate address, or the client using ARP probes before using it.
DHCPv6 exists for IPv6, but many networks rely on SLAAC for the address and use DHCPv6 only for additional options such as DNS.
$ sudo tcpdump -n -i eth0 port 67 or port 68
IP 0.0.0.0.68 > 255.255.255.255.67: DHCP-Message Discover
IP 192.168.1.1.67 > 255.255.255.255.68: DHCP-Message Offer yiaddr 192.168.1.42
IP 0.0.0.0.68 > 255.255.255.255.67: DHCP-Message Request
IP 192.168.1.1.67 > 255.255.255.255.68: DHCP-Message ACK lease 86400sDiscover and Request come from 0.0.0.0 because the client has no address yet.
DHCP, DORA, Lease, Relay Agent, APIPA