skip to content

In DHCPv4, what happens at T1 and at T2, and why does renewing use unicast while rebinding broadcasts?

level: middleimportance: must knowfreq 40%

answer

  1. two deadlines before expiry
  2. half, then seven-eighths
  3. own server first, then anyone
  4. both are DHCPREQUEST
  5. ciaddr filled, no server identifier

basics

~20 s

At T1, by default half the lease, a DHCPv4 client unicasts a DHCPREQUEST to the server that granted it; if no DHCPACK arrives by T2, by default 87.5%, it broadcasts the DHCPREQUEST so any server may extend it.

solid answer

~50 s

RFC 2131 gives a bound client two deadlines before expiry. At `T1` (default 0.5 of the lease) it enters `RENEWING` and **unicasts** a `DHCPREQUEST` to the server that granted the lease. It already has a working address and knows that server's address, and that server holds the binding, so no broadcast is needed. If no `DHCPACK` arrives by `T2` (default 0.875), it enters `REBINDING` and **broadcasts** the same kind of `DHCPREQUEST`, because the original server may be gone and another server with authority over the lease may answer. Both requests carry the current address in `ciaddr` and omit the server identifier and requested-address options; there is no separate renew or rebind message. A `DHCPACK` returns the client to `BOUND` with a fresh expiry; a `DHCPNAK`, or reaching expiry, sends it to `INIT` and it must stop using the address.

code

pseudocode · 19 lines
pseudocode
on DHCPACK sent_at t, lease L, options T1?, T2?:
    expiry = t + L
    t1 = t + (T1 or 0.5 * L)      # plus some random fuzz
    t2 = t + (T2 or 0.875 * L)
    state = BOUND

when now >= t1 and state == BOUND:
    state = RENEWING
    unicast DHCPREQUEST(ciaddr = my_addr) to granting_server

when now >= t2 and state in (BOUND, RENEWING):
    state = REBINDING
    broadcast DHCPREQUEST(ciaddr = my_addr)

retry wait in RENEWING  = max(60 s, (t2 - now) / 2)
retry wait in REBINDING = max(60 s, (expiry - now) / 2)

on DHCPNAK in RENEWING or REBINDING: stop using my_addr; state = INIT
when now >= expiry: stop using my_addr; state = INIT

go deeper

for a junior

Recall that a client extends its lease twice before expiry: first with its own server at half the lease, then with any server near the end.

for a middle

Explain the RENEWING and REBINDING states, why one is unicast and the other broadcast, what ciaddr carries, and the half-the-remaining-time retry rule.

for a senior

Use the timers operationally: how long a server outage stays invisible, what a NAK during renewal does to a host, and why renewals bypass relay agents.

for a principal

Discuss the two-stage design as a tradeoff between cheap targeted renewal and a last-resort broadcast that only helps if servers share lease state.

## The client states involved RFC 2131 §4.4 describes a DHCPv4 client as a state machine. The states that matter once a lease exists are these: | State | What the client is doing | |---|---| | `BOUND` | Using its address normally, waiting for `T1` | | `RENEWING` | Asking the granting server, by unicast, to extend the lease | | `REBINDING` | Asking any server, by broadcast, to extend the lease | | `INIT` | No usable lease; it must start the full exchange from scratch | | `INIT-REBOOT` / `REBOOTING` | Rechecking a remembered address after a restart or reconnection | The client gets from `INIT` to `BOUND` through the initial four-message exchange (via `SELECTING` and `REQUESTING`); that exchange is a separate subject. This explanation starts when the client is bound. ## The two timers RFC 2131 §4.4.5 defines **`T1`** and **`T2`**, both measured from the moment the lease was granted: - `T1` defaults to `0.5 × lease` and `T2` to `0.875 × lease`. - A server may set both explicitly with RFC 2132 options **58** (Renewal T1 Time Value) and **59** (Rebinding T2 Time Value). - `T1` MUST be earlier than `T2`, which MUST be earlier than expiry. - Both SHOULD carry some random "fuzz", so that clients that booted together do not all renew in the same second. A client MAY also renew earlier than `T1`; the timers are the latest points at which it must act. ## T1: renewing with the granting server At `T1` the client enters `RENEWING` and sends a `DHCPREQUEST` **by unicast** to the server that issued the lease. Unicast works because the client is fully configured: it has a valid address, a subnet mask and a route, and it recorded the server's address from the `server identifier` option when it was bound. That server also holds the binding, so it is the right one to ask. RFC 2131 §4.3.2 notes that this message is unicast "so no relay agents will be involved in its transmission" and, with `giaddr` therefore zero, the server trusts `ciaddr` and unicasts its reply there. ## T2: rebinding with any server If no `DHCPACK` has arrived by `T2`, the client enters `REBINDING` and sends the `DHCPREQUEST` **by broadcast** to `255.255.255.255`. The assumption has changed: the granting server may be down or unreachable. Broadcasting reaches every server on the link, and through a relay agent the servers beyond it. RFC 2131 says this rebinding request is "intended to accommodate sites that have multiple DHCP servers and a mechanism for maintaining consistency among leases", and that a server "MAY extend a client's lease only if it has local administrative authority to do so." ## What the request carries There is **no `DHCPRENEW` or `DHCPREBIND` message**: both phases send `DHCPREQUEST` (message type 3). RFC 2131 Table 4 tells them apart: | Field | `RENEWING` | `REBINDING` | |---|---|---| | Delivery | unicast | broadcast | | `server identifier` option | MUST NOT | MUST NOT | | `requested IP address` option | MUST NOT | MUST NOT | | `ciaddr` | client's address | client's address | A filled-in `ciaddr` is what marks this as an extension of an existing lease rather than a new request. ## Retries inside each state RFC 2131 §4.4.5 has its own back-off here, unlike the seconds-scale retransmission of the initial exchange. With no response, the client waits **half the remaining time until `T2`** (in `RENEWING`) or **half the remaining lease** (in `REBINDING`), never less than **60 seconds**, before retransmitting. Retries therefore crowd toward each deadline. ## How each state ends 1. **`DHCPACK`** — the client records the new expiry as the time it *sent* the request plus the lease in the ACK, and returns to `BOUND`. A server that chooses not to extend the lease should still answer with `DHCPACK`, and SHOULD adjust `T1` and `T2` to the time actually remaining. 2. **`DHCPNAK`** — the server refuses the address; the client halts network use and goes to `INIT`. 3. **Expiry with no answer** — the client "MUST immediately stop any other network processing" and goes to `INIT` as if it had never been configured. If it is later given its old address it continues; if it is given a new one, it MUST NOT keep using the old one. ## Why two stages The design spends the first stretch after `T1` asking the one server that certainly knows the lease, at no cost to anyone else on the link, and keeps a final eighth of the lease in reserve for a broadcast plea to any server. A client on the defaults therefore has half its lease to ride out a problem with its own server, and the last eighth to find another, before it must give the address up.

  • How long can the only DHCPv4 server on a network be down before bound clients start losing addresses?
    With default timers and renewals succeeding until then, every bound client was last extended no later than its `T1`, so it holds between half and all of a lease when the outage starts. The first lease can therefore expire no sooner than about half a lease into the outage, give or take the fuzz. On an 8-hour lease that is roughly 4 hours. Clients arriving in `INIT` during the outage get nothing at once.
  • When a DHCPv4 server answers a renewing DHCPREQUEST, is its DHCPACK broadcast?
    No. A renewing request arrives with `giaddr` zero and `ciaddr` filled in, and RFC 2131 §4.1 has the server unicast its `DHCPACK` to the address in `ciaddr`. For such a request only a `DHCPNAK` would be broadcast: with `giaddr` zero RFC 2131 broadcasts every NAK, because the refused client may lack a usable address.
  • Can a DHCPv4 server make a client renew before T1?
    RFC 3203 adds `DHCPFORCERENEW` (message type 9): the server unicasts it and the client moves to renewing as if `T1` had fired. If the server then answers with `DHCPNAK`, the client returns to `INIT` and is re-addressed. RFC 3203 requires the message to be authenticated and has clients silently discard it otherwise, so it suits controlled networks only.

saying these in an interview costs you the question

  • DHCP has separate DHCPRENEW and DHCPREBIND messages for the two phases.
  • At T1 the client broadcasts a DHCPDISCOVER to look for a new server.
  • Rebinding only starts once the lease has already expired.
  • A T1 renewal is relayed through the relay agent just like the initial exchange.
  • T1 and T2 are fixed at 50% and 87.5% and a server cannot change them.