Understanding the DHCP lease timer (T1/T2) calculator — concept and principle
A DHCP server lends an IP address to a device for a limited time, the lease. Before the lease runs out, the client tries to extend it using two timers: T1, the renewal time, and T2, the rebinding time. This calculator shows when those timers fire for a given lease length, which helps when tuning lease times, planning server maintenance or troubleshooting clients that lose their addresses.
How it is calculated
- T1 (renewal) = 0.5 × lease time.
- T2 (rebinding) = 0.875 × lease time.
These are the default values in RFC 2131 when the server does not send its own. A server can override them with DHCP option 58 (renewal time) and option 59 (rebinding time); the lease length itself is option 51.
The principle
The two timers give the client two chances to keep its address before it expires. At T1 the client enters the RENEWING state and sends a unicast DHCPREQUEST directly to the server that granted the lease. If that server answers with DHCPACK, the lease restarts from zero. If there is no answer by T2, the client enters the REBINDING state and broadcasts its DHCPREQUEST so that any DHCP server on the network can extend the lease. If the lease finally expires, the client must stop using the address and start over from discovery. Starting at the halfway point leaves plenty of time for retries, while 87.5% reserves a final stretch for the broadcast attempt.
Worked example
- Input: lease time 24 hours.
- T1: 0.5 × 24 = 12 hours after the lease was obtained.
- T2: 0.875 × 24 = 21 hours.
- The lease expires at 24 hours if neither renewal nor rebinding succeeded.
| Lease time (hours) | Renewal T1 (50%) (h) |
|---|---|
| 6 | 3 |
| 12 | 6 |
| 18 | 9 |
| 24 | 12 |
| 30 | 15 |
| 36 | 18 |
| 48 | 24 |
How to read the result
The time between T1 and expiry is how long a DHCP server can be down before clients notice: here, even a client that has just reached T1 keeps its address for 12 more hours. Short leases (minutes to a few hours) suit guest Wi-Fi and busy networks with many transient devices, because addresses are freed quickly. Long leases (days) suit stable wired networks and reduce DHCP traffic.
Common mistakes
- Assuming the device asks for a new address only when the lease ends.
- Making leases so long that a small pool runs out on a busy guest network.
- Forgetting that a server may send its own T1/T2 values, which replace the defaults.
Frequently asked questions
What happens if the DHCP server is offline at T1?
The client keeps the address and retries; at T2 it broadcasts to any server. Only at expiry does it give up the address.
What lease time should I use at home?
Router defaults of about one day are usually fine. Shorter leases help only when many devices come and go.
Does DHCPv6 use the same timers?
DHCPv6 also has T1 and T2, carried per address association, but its rules are defined in its own RFC rather than RFC 2131.
Sources: IETF RFC 2131, Dynamic Host Configuration Protocol (section 4.4.5) · IETF RFC 2132, DHCP Options and BOOTP Vendor Extensions