A DHCP lease is the time-limited assignment of an IP address, together with related network settings, that a DHCP server grants to a client. In address configuration, the lease is the contract at the heart of dynamic addressing: the client may use the address only for the lease duration, must renew it before it expires and must stop using it if renewal fails.
Leasing allows a limited pool of addresses to serve a changing population of devices. Addresses held by devices that leave the network return to the pool automatically once their leases expire, without any manual cleanup by an administrator.
How a DHCP lease is obtained
A client obtains a DHCP lease through a four-message exchange known as DORA: Discover, Offer, Request and Acknowledge. The client broadcasts a DHCPDISCOVER, one or more servers answer with a DHCPOFFER containing a proposed address, the client broadcasts a DHCPREQUEST naming the chosen server, and that server confirms with a DHCPACK. Only after the acknowledgment may the client configure the address.
The acknowledgment carries the lease time in option 51, plus settings such as the subnet mask, default gateway and DNS servers. Many clients also probe the offered address, for example with ARP, before using it. If another device already answers, the client sends a DHCPDECLINE and starts again, which prevents an IP address conflict.
When clients sit on a different subnet from the server, a DHCP relay agent on the router forwards the broadcasts as unicast packets and inserts the subnet information the server needs to pick the correct pool.
The DHCP lease lifecycle and its timers
A DHCP lease moves through predictable states driven by two timers. At T1, by default 50 percent of the lease time, the client unicasts a renewal request to the server that granted the lease. If that fails, at T2, by default 87.5 percent, it broadcasts a rebinding request to any server. If the lease then expires, the client must stop using the address and restart discovery.
| State | When it occurs | Client action |
|---|---|---|
| Bound | After a DHCPACK | Uses the address normally |
| Renewing | From T1, default 50 percent of lease | Unicast DHCPREQUEST to the original server |
| Rebinding | From T2, default 87.5 percent of lease | Broadcast DHCPREQUEST to any server |
| Expired | Lease time fully elapsed | Releases the address, restarts discovery |
| Init-reboot | After restart with a remembered lease | Requests the same address again |
A client can end a lease early with DHCPRELEASE, for example when shutting down cleanly, and a server can refuse a requested address with DHCPNAK, typically after the client moved to another subnet. Renewal normally keeps the same address, which is why most devices appear to have a stable IP address even on dynamic configuration.
Choosing the DHCP lease duration
Lease duration is a trade-off between address turnover and control traffic. Short leases free addresses quickly when devices come and go, but generate more renewals and make the network more sensitive to server outages. Long leases reduce traffic and tolerate outages, but keep addresses tied to devices that may never return.
| Environment | Typical lease | Reason |
|---|---|---|
| Guest Wi-Fi or public hotspot | 30 minutes to 4 hours | High turnover of visiting devices |
| Office network | 8 hours to 8 days | Stable devices, moderate turnover |
| Home router | Often 24 hours | Few devices, simple management |
| Server or infrastructure subnet | Reservations or static addresses | Addresses must never change |
| Migration window | Shortened to minutes or hours | Settings changes reach clients quickly |
A useful practice before changing DNS servers or the gateway is to shorten the lease a few days in advance. Clients then pick up the new settings at their next renewal instead of waiting for a long lease to reach T1.
DHCP lease compared with related addressing methods
A DHCP lease is one of several ways a host can obtain an address, and its neighbors in address configuration behave quite differently in ownership and expiry. The table separates the concepts that are most often confused.
| Method | Who decides the address | Expires | Typical use |
|---|---|---|---|
| DHCP lease | Server, from a pool | Yes, unless renewed | Clients on IPv4 networks |
| DHCP reservation | Server, fixed per MAC or client ID | Lease still renewed, address constant | Printers, cameras, access points |
| Static IP address | Administrator on the device | No | Servers, routers, critical devices |
| SLAAC | Host, from a router-advertised prefix | Preferred and valid lifetimes | IPv6 clients |
| APIPA | Host, from 169.254.0.0/16 | No | Fallback when no DHCP server answers |
DHCPv6 uses the same leasing idea but expresses it through preferred and valid lifetimes on each address, and it can also delegate whole prefixes to routers.
Common DHCP lease problems
Most lease-related incidents trace back to pool sizing, rogue servers or broken relays. The recurring symptoms and causes are these:
- Pool exhaustion: long leases on a busy guest network leave no free addresses, and new devices fall back to APIPA.
- Rogue DHCP server: a misconfigured consumer router hands out wrong gateways; DHCP snooping on switches blocks it.
- Overlapping scopes: two servers lease the same range without failover coordination, causing address conflicts.
- Relay misconfiguration: clients on remote subnets never receive an offer.
- Stale settings: clients keep old DNS servers until their next renewal.
Monitoring pool utilization against an alert threshold, often around 80 to 90 percent, gives administrators time to shorten leases or enlarge the subnet before users notice failures.
In plain words
A DHCP lease is like borrowing a numbered parking space for a set amount of time. When a phone or laptop joins a network, a server lends it an address and tells it how long it may keep it.
Before the time runs out, the device politely asks to extend the loan, and usually gets the same space again. If the device leaves and never asks, the space goes back into the pool for someone else.
A real-world example
A conference center runs a guest network on a /22 subnet with about 1,000 usable addresses and an eight-day lease inherited from the office template. During a three-day trade fair, several thousand visitors connect, and by the second morning new phones cannot get an address at all.
The network administrator sees that the pool is 100 percent used, mostly by devices that already left. Because existing eight-day leases cannot be shortened from the server side, she adds a second scope with one-hour leases behind the same relay so that new visitors receive addresses at once. New devices connect without errors for the rest of the fair, and for the next event the guest network starts with one-hour leases from day one, keeping utilization well below the alert threshold.