DHCP

When you join a network - plug in an Ethernet cable, connect to Wi-Fi - your host does not come pre-configured with an IP address for that network. DHCP (Dynamic Host Configuration Protocol) hands one out automatically, along with everything else the host needs to start talking to the internet.

The DORA exchange

A new client and the DHCP server negotiate in four messages, remembered by the acronym DORA:

Message	Direction	Purpose
Discover	Client -> broadcast	New client shouts: is there a DHCP server out there?
Offer	Server -> client (broadcast)	Server proposes an available IP address and lease terms.
Request	Client -> broadcast	Client formally requests the offered address (and declines others).
Ack	Server -> client	Server confirms; the address is now leased to the client.

After the Ack, the client owns that address and can send and receive normally.

tip

At the start of DORA the client has no IP address yet, so it cannot be addressed directly and does not know the server's address. It sends Discover to the broadcast address 255.255.255.255, and the server's Offer is typically broadcast too, because the client still has no address to unicast a reply to.

Lease time

A DHCP address is not permanent - it is a lease with an expiry (hours to days). Before the lease expires the client tries to renew it (a short Request/Ack, skipping Discover/Offer since it already has an address). Leases let a network recycle addresses: a device that leaves and never renews eventually frees its address for someone else.

Worked example: an 8-hour lease timeline

Say the DHCP server offers a lease time of 28,800 seconds (8 hours), and the client completes DORA at exactly 09:00:00 for address 192.168.1.50, offered by server 192.168.1.1. The client does not wait until the lease is about to expire before trying to renew - it uses two internal timers, defined as fractions of the total lease time:

Timer	Fraction of lease	Elapsed time	Clock time	Action
Lease granted	0%	0s	09:00:00	Client starts using 192.168.1.50
T1 (renew)	50%	14,400s (4h)	13:00:00	Unicast Request straight to 192.168.1.1 asking to extend the lease
T2 (rebind)	87.5%	25,200s (7h)	16:00:00	If T1's server never answered, broadcast Request to any DHCP server
Lease expiry	100%	28,800s (8h)	17:00:00	If nothing answered T2 either, the client must drop the address

In the normal case the server answers the T1 renewal at 13:00:00 with a fresh Ack, the lease clock resets to a new 8-hour window starting there, and the client never even reaches T2. T2 only matters as a fallback if the original server is unreachable (rebooted, replaced, network split) - broadcasting at that point gives any surviving DHCP server a chance to confirm the same address before it is lost.

⚠DHCP pool exhaustion

A /24 subnet has 254 usable host addresses. If the DHCP pool is sized for, say, 200 of those and a conference room or open office fills up with laptops, phones, and IoT devices that all hold their leases for the full lease time without releasing them (laptops going to sleep instead of disconnecting cleanly is a common cause), the pool can run dry with client 201 onward. Those clients broadcast Discover and simply get no Offer back - visible on the client as "no DHCP server found" or "limited connectivity," and on the server as a spike in Discover messages with nothing available to lease. The usual fixes are shortening the lease time so stale entries expire faster, or sizing the pool for peak concurrent device count rather than expected headcount (one person now often carries two or three DHCP clients: laptop, phone, watch).

What else DHCP hands out

DHCP does far more than assign an address. In the same exchange the server typically also configures:

• Subnet mask - so the host knows which addresses are local vs remote.
• Default gateway - the router IP to send off-network traffic to.
• DNS server(s) - so the host can resolve names to addresses.

This is why a single successful DHCP lease is enough to make a freshly connected device fully ready to browse the internet.