skip to content

A DHCPv4 laptop with default timers leased an address for 8 hours at 09:00, then slept 12:30 to 14:00; what does it do on waking?

level: middleimportance: should knowfreq 22%

answer

  1. work out the three deadlines first
  2. 13:00, 16:00, 17:00
  3. woke between T1 and T2
  4. retry at half the remaining time
  5. new clock from the send time

basics

~10 s

The laptop's deadlines are T1 13:00, T2 16:00 and expiry 17:00, so at 14:00 it is past T1: it unicasts a renewing DHCPREQUEST to its server, and a DHCPACK restarts the lease from 14:00.

solid answer

~50 s

Start with the clock. An 8-hour lease requested at 09:00 gives `T1` at 13:00 (half the lease), `T2` at 16:00 (seven-eighths) and expiry at 17:00. The laptop slept through `T1`, so on waking at 14:00 it is in `RENEWING` and unicasts a `DHCPREQUEST`, with its address in `ciaddr`, to the server that granted the lease. If a `DHCPACK` for another 8 hours comes back, the new expiry is counted from the 14:00 send time: `T1` 18:00, `T2` 21:00, expiry 22:00. If nothing answers, it retries after half the time left to `T2` (15:00, then 15:30, 15:45, down to a 60-second floor), broadcasts from 16:00 in `REBINDING`, and at 17:00 must stop using the address and start over. The default times also carry a little random fuzz, so real clients act near these marks rather than exactly on them.

go deeper

for a junior

Recall the default timer fractions, half and seven-eighths of the lease, and turn an 8-hour lease into three clock times.

for a middle

Walk the timeline: which state the laptop wakes in, unicast or broadcast, the half-the-remaining-time retries with a 60-second floor, and the fresh deadlines after an ACK.

for a senior

Read wake-up behaviour from the clock alone, note that servers may override T1 and T2 or shorten the extension, and know the RFC's separate advice to recheck after a disconnection.

for a principal

Use the arithmetic to reason about tolerance: how long hosts survive a dead server or a long sleep, and how timer choices shift that margin.

## The three deadlines RFC 2131 §4.4.5 gives a bound DHCPv4 client three moments, all measured from when it **sent** the request that the server acknowledged. With no explicit `T1` and `T2` options (RFC 2132 options 58 and 59) from the server, the defaults apply: | Moment | Rule | 8-hour lease from 09:00 | |---|---|---| | `T1` — enter `RENEWING` | 0.5 × lease = 4 h | **13:00** | | `T2` — enter `REBINDING` | 0.875 × lease = 7 h | **16:00** | | Expiry | 1.0 × lease = 8 h | **17:00** | Check the arithmetic: 8 h is 28,800 s; half is 14,400 s (4 h); 0.875 × 28,800 = 25,200 s (7 h). RFC 2131 says `T1` and `T2` SHOULD include some random fuzz so clients that started together spread out, so a real client acts near these times, not to the second. ## Waking at 14:00 The laptop slept from 12:30, before `T1`, to 14:00, after it. The timers are relative to its own clock, so on waking it is past `T1` and before `T2`: it belongs in **`RENEWING`**. 1. It **unicasts** a `DHCPREQUEST` to the server that granted the lease, the address it recorded from the `server identifier` option. 2. The request carries its current address in `ciaddr` and omits both the `server identifier` and `requested IP address` options. 3. The server, seeing `giaddr` zero and `ciaddr` set, unicasts its `DHCPACK` back to that address. Nothing about the address changed while the laptop slept, because the lease never came near expiry. That is the whole reason a short absence is invisible to the user. A second path is also legitimate. RFC 2131 §3.7 says a client SHOULD reacquire or verify its address after a disconnection, and a sleeping laptop often loses its link. A client that noticed the link go down may therefore recheck its remembered address with a broadcast request first. The timers alone, however, require the renewal above. ## When the DHCPACK arrives The client records the new expiry as the time it **sent** the request plus the lease in the `DHCPACK`, then returns to `BOUND`. If the server grants another 8 hours to the 14:00 request: - `T1` = 14:00 + 4 h = **18:00** - `T2` = 14:00 + 7 h = **21:00** - expiry = 14:00 + 8 h = **22:00** The server is not obliged to grant a full 8 hours. RFC 2131 lets it decline to extend the lease and still answer `DHCPACK`, with `T1` and `T2` adjusted to the time that actually remains. ## When nothing answers In `RENEWING`, RFC 2131 has the client wait **half the remaining time until `T2`**, but never less than **60 seconds**, before each retransmission: | Retransmission | Remaining until T2 | Wait | Sent at | |---|---|---|---| | after the 14:00 request | 2 h | 1 h | 15:00 | | next | 1 h | 30 min | 15:30 | | next | 30 min | 15 min | 15:45 | | next | 15 min | 7.5 min | 15:52:30 | The waits keep halving until the 60-second floor takes over, and at 16:00 `T2` arrives. The client then enters **`REBINDING`** and **broadcasts** its `DHCPREQUEST` so any server with authority over the lease may answer. The same halving now applies to the time left on the lease: retransmissions at 16:30, 16:45, 16:52:30 and so on, again no closer together than 60 seconds. At **17:00** the lease expires. The client MUST immediately stop using the address and goes to `INIT`, starting the full exchange as if it had never been configured. If it is given the same address back it carries on; if it is given a different one it MUST NOT keep using the old one. ## Other wake-up times The same clock decides every variant of the scenario: - **Wake before 13:00** — still `BOUND`; the timers require nothing until `T1`, apart from any recheck after a lost link. - **Wake between 13:00 and 16:00** — `RENEWING`: unicast to the granting server, as above. - **Wake between 16:00 and 17:00** — `REBINDING`: broadcast to any server. - **Wake after 17:00** — the lease is gone; stop using the address and start again from `INIT`. One more reading of the table: right after a grant, an 8-hour lease with default timers needs no protocol activity for four hours, and the address survives as long as some server answers before the eighth hour.

  • If the same DHCPv4 laptop slept from 12:30 to 16:30 instead, what would it send on waking?
    At 16:30 it is past `T2` (16:00) but before expiry (17:00), so it is in `REBINDING` and **broadcasts** a `DHCPREQUEST` with its address in `ciaddr`. Any server with authority over the lease may extend it. With no answer it retries after half the remaining lease, at 16:45, and must stop using the address at 17:00.
  • If the server's DHCPv4 options set T1 to 2 hours and T2 to 3 hours on the same 8-hour lease, when would the laptop act?
    Options 58 and 59 override the defaults, so from a 09:00 grant it would start renewing at 11:00 and, if no server answered, rebinding at 12:00, both before its 12:30 nap. Still unanswered, it wakes at 14:00 in `REBINDING` with three hours of lease left and broadcasts at once; expiry stays at 17:00.

saying these in an interview costs you the question

  • The laptop slept through T1, so it has lost its address and must start over.
  • T2 falls at 15:00, three-quarters of the way through the lease.
  • The new expiry is counted from when the DHCPACK arrives, not when the request was sent.
  • With no reply, the client retries every 4 seconds until T2.
  • After 14:00 the client broadcasts its renewal to every server on the link.