When a DHCP server grants an IP address, it doesn't give it permanently—it leases it. This temporary assignment is the key innovation that enables dynamic addressing to work at scale. But lease management is far more complex than simply setting a timer.

Consider these questions:

• What happens when a client's lease expires while it's actively using the network?
• How does the server track thousands of leases across restarts and crashes?
• What prevents address conflicts when multiple servers share responsibility for a scope?
• How do you prevent address pool exhaustion in high-churn environments?

Lease management encompasses the policies, mechanisms, and databases that answer these questions. It's the operational backbone of DHCP—invisible when working correctly, catastrophic when misconfigured.

This page examines lease management holistically: from the moment a lease is created through renewal, rebinding, expiration, and reclamation. You'll understand how to size lease durations, design for failure scenarios, and maintain healthy address pools.

A DHCP lease is a time-bounded contract between server and client. The server agrees to not assign the IP address to anyone else for the lease duration; the client agrees to either renew the lease or stop using the address when it expires.

Lease Components:

A lease record in the DHCP server database typically contains:

The Lease as Contract:

Understanding leases as contracts clarifies the obligations:

Server Obligations:

• Not assign the leased address to another client during the lease
• Respond to renewal requests from the legitimate client
• Only reclaim the address after lease expiration and reasonable grace period
• Persist lease information across restarts and failures

Client Obligations:

• Attempt to renew the lease before expiration (at T1)
• Release the address if not needed (though optional)
• Cease using the address when the lease expires without renewal
• Not assume the same address will be available in future transactions

Breaking the Contract:

Clients that fail to renew (e.g., powered off, disconnected) technically violate the implicit contract, but DHCP accommodates this gracefully—the address simply becomes available after expiration.

A DHCP lease progresses through several states during its lifetime. Understanding these states, from both client and server perspectives, is essential for troubleshooting and operations.

Server-Side Lease States:

Client-Side States (from RFC 2131):

The client also maintains state that determines its behavior:

State Persistence:

Clients typically persist the assigned address and lease expiration to storage. On reboot, they can attempt INIT-REBOOT to quickly reclaim their previous address without full DORA.

Lease renewal is the routine maintenance that keeps DHCP leases active. Properly functioning renewal ensures clients never lose connectivity due to lease expiration during normal operation.

The T1 Timer (Renewal Time):

T1 is typically set to 50% of the lease duration (or specified by Option 58). When T1 fires:

1. Client enters RENEWING state
2. Client sends REQUEST via unicast to the original leasing server
3. ciaddr contains the client's current IP address
4. No Server Identifier option needed (server known)
5. No Requested IP option needed (ciaddr is the address)

Why Unicast?

• Reduces broadcast traffic on the network
• Allows operation when other network resources are unavailable
• Maintains affinity with the original server
• More efficient for both network and server

Renewal Success:

If the server receives the renewal REQUEST and can honor it:

1. Server verifies the lease record exists and matches
2. Server updates lease expiration time (new lease starts now)
3. Server sends ACK with updated lease time and options
4. Client resets T1 and T2 timers based on new lease
5. Client may receive updated configuration (DNS, etc.)

Renewal Failure Handling:

If the server cannot be reached or responds with NAK:

• Client continues retrying until T2
• Retransmission uses exponential backoff
• If ACK received before T2: success, timers reset
• If T2 expires without ACK: transition to REBINDING
• If NAK received: release address, restart from INIT

Renewal Best Practices:

When renewal fails—because the original server is unreachable—the client has one more chance before losing its address: rebinding. This mechanism provides resilience against server failures.

The T2 Timer (Rebinding Time):

T2 is typically set to 87.5% of the lease duration (or specified by Option 59). When T2 fires:

1. Client enters REBINDING state
2. Client sends REQUEST via broadcast
3. ciaddr contains the client's current IP address
4. Any DHCP server that recognizes the lease can respond
5. This is a "last resort" before lease expiration

Why 50% and 87.5%?

These defaults create a structured failure response:

For a 24-hour lease:

• T1 at 12 hours: 12 hours to reach original server
• T2 at 21 hours: 3 hours to reach any server
• Expiration at 24 hours: Must have completed or restart DORA

Rebinding Server Processing:

When a DHCP server receives a broadcast REQUEST in the REBINDING context:

1. Server checks if it has the lease

   • Same server (recovered): Extend lease normally
   • Different server (failover): Check if address is valid in its scope

2. If address is valid and available:

   • Create new lease record (take over from original server)
   • Send ACK with updated lease time
   • Client continues normally with new server

3. If address is invalid for this network:

   • Send NAK to force client restart
   • Client likely moved to different subnet

4. If address conflicts with another lease:

   • Best practice: Send NAK
   • Client must restart DORA
   • Investigate duplicate lease condition

The Grace Period:

Many DHCP server implementations provide a grace period after lease expiration before returning the address to the pool:

• Typically 1 hour to several hours
• Allows disconnected clients to recover their address upon return
• Reduces IP address churn and DNS update frequency
• Configurable per scope or globally

During the grace period:

• Address is not offered to new clients
• Original client can still reclaim via INIT-REBOOT
• After grace period, address returns to Available

The DHCP server must persist lease information across restarts, crashes, and even hardware failures. Without persistence, a server restart would lose all lease records—potentially causing address conflicts when new addresses are assigned to devices that still hold their previous leases.

Lease Storage Mechanisms:

Configuring the right lease duration is one of the most important—and often overlooked—DHCP decisions. Too short wastes resources; too long exhausts pools and delays configuration updates.

Factors Influencing Lease Duration:

Calculating Optimal Lease Duration:

A practical formula for minimum lease duration:

Minimum Lease = (Address Pool Size / Peak Device Count) × Average Session Duration

Example:

• Pool: 200 addresses
• Peak devices: 150 concurrent
• Average session: 2 hours

Minimum Lease = (200/150) × 2 hours = 2.67 hours

With safety margin: 3-4 hours recommended

Warning Signs of Wrong Lease Duration:

Too Short:

• High renewal traffic (visible in packet captures)
• Excessive server CPU/disk usage
• Clients occasionally failing to renew in time

Too Long:

• Pool approaching exhaustion during peak
• Stale configuration persisting on clients
• Addresses tied up by devices no longer present

A single DHCP server is a single point of failure. When it goes offline, no new devices can join the network, and existing devices risk losing addresses when their leases expire. Enterprise deployments require high availability strategies.

Failover Approaches:

We've comprehensively examined DHCP lease management—the operational backbone that makes dynamic addressing reliable. Let's consolidate the key takeaways:

What's Next:

With lease management understood, the final page examines DHCP relay agents—the mechanism that enables DHCP to work across routed network segments. Relay agents are essential for enterprise deployments where clients and servers reside on different subnets.