Introduction
Every device that joins a network needs an IP address, a subnet mask, a default gateway, and usually a DNS server address before it can communicate. Configuring all of this by hand on every device would not scale. DHCP (Dynamic Host Configuration Protocol) automates this process, letting a device request configuration from a DHCP server the moment it connects to the network.
Cricket analogy: A franchise can't hand-fit every new overseas signing with kit, visa paperwork, and a hotel room manually each season; the team's operations desk automates issuing that starter pack the moment the player lands, the way DHCP automates handing a device its IP, mask, gateway, and DNS.
Explanation
DHCP runs over UDP, with servers listening on port 67 and clients on port 68. A device obtaining an address for the first time on a network follows a four-step exchange commonly remembered by the acronym DORA: Discover, Offer, Request, Acknowledge. First, the client broadcasts a DHCPDISCOVER message, because it does not yet have an IP address and does not know if a DHCP server even exists on the network; this message goes to the broadcast address so any listening DHCP server can see it. Any DHCP server that receives the discover and has an address available responds with a DHCPOFFER, also sent as a broadcast (since the client still has no address to be reached at directly), proposing an IP address and lease terms. The client then broadcasts a DHCPREQUEST, formally asking to accept one particular offer — broadcasting here matters because it also tells any other DHCP servers that made offers that their offers were not chosen, so they can free up those reserved addresses. Finally, the chosen server responds with a DHCPACK, confirming the lease and finalizing the configuration, at which point the client can begin using the assigned address.
Cricket analogy: Like a new player broadcasting to the whole dressing room 'does any coach have kit for me' (Discover), any available coach shouting back an offer (Offer), the player publicly accepting one coach's offer so others know to withdraw theirs (Request), and that coach confirming the assignment (Ack) — mirroring DHCP's broadcast DORA exchange on UDP ports 67/68.
After the initial DORA exchange, when a client later needs to renew its lease before it expires, it typically sends a unicast DHCPREQUEST directly to the server it originally leased from, since by that point it already has a working IP address and does not need to broadcast.
Cricket analogy: Once a player has already settled into a franchise's squad list, renewing next season's contract is a direct call between player and that one franchise, not a broadcast to every team in the league — just as DHCP lease renewal is a unicast DHCPREQUEST to the original server.
Example
# View DHCP-obtained IP configuration on a Linux client
ip addr show eth0
# Release the current DHCP lease
sudo dhclient -r eth0
# Trigger a fresh DORA exchange to obtain a new lease
sudo dhclient eth0
# Watch DHCP traffic (DISCOVER, OFFER, REQUEST, ACK) live
sudo tcpdump -i eth0 -n port 67 or port 68Analysis
Running the tcpdump command while a device joins the network makes DORA directly observable: you would see a broadcast DHCPDISCOVER from the client's placeholder address (0.0.0.0), one or more broadcast DHCPOFFER replies from available servers, a broadcast DHCPREQUEST from the client naming the accepted offer, and a final DHCPACK from the chosen server. The consistent use of broadcast during the initial exchange is a direct consequence of the client not yet having a usable IP address — unicast simply is not possible until the client has been assigned one, which is exactly what this exchange is negotiating.
Cricket analogy: Watching the dressing-room walkie-talkie chatter during a new signing's arrival shows the same pattern: an open call to any coach (0.0.0.0), several coaches offering kit, the player's public acceptance, and the final confirmation — all broadcast because the player has no team ID yet, just like tcpdump reveals DORA's broadcasts.
Key Takeaways
- DHCP automates IP configuration (address, subnet mask, gateway, DNS) so devices do not need manual setup.
- DHCP uses UDP, with servers on port 67 and clients on port 68.
- DORA = Discover, Offer, Request, Acknowledge, the four steps of initial lease negotiation.
- DISCOVER, OFFER, and REQUEST are broadcast because the client has no usable IP address yet; ACK finalizes the lease.
- Lease renewal later on typically uses a unicast DHCPREQUEST directly to the known server, since the client already has an address by then.
Practice what you learned
1. What does the acronym DORA represent in DHCP?
2. Why is the initial DHCPDISCOVER message sent as a broadcast?
3. Which DHCP message finalizes and confirms the lease?
4. What port does a DHCP server listen on?
5. When a client later renews an existing lease, how does it typically communicate with the DHCP server?
Was this page helpful?
You May Also Like
Application Layer Protocols Overview
A survey of the protocols that let applications talk to each other over a network, and how they fit above the transport layer.
IP Addressing and Subnetting
Master IPv4 addressing and CIDR subnetting with a fully worked, hand-verified example.
TCP vs UDP
Compare TCP and UDP across reliability, ordering, connection state, overhead, and typical use cases.
Network Troubleshooting Tools
Learn how ping, traceroute, netstat/ss, and nslookup/dig work under the hood to diagnose connectivity, routing, and DNS issues.
Hubs, Switches, and Routers
Learn how hubs, switches, and routers operate at different OSI layers and how they shape collision and broadcast domains.