Summary

  • A DHCPv4 lease has three relevant moments: T1 begins renewal with the leasing server, T2 begins broadcast rebinding, and expiry ends the client's permission to use the address unless a DHCPACK has created a new lease.
  • Rebinding improves availability but does not make every reachable server authoritative. RFC 2131 allows an alternate server to extend the lease only when it has local administrative authority; observed packet delivery never overrides the deadline.

The address still worked when its permission began to narrow

Imagine a laptop with open connections and a working route. Its IPv4 address still answers. The DHCP server that supplied the address no longer responds.

Nothing visible on the wire tells the user that a change of authority has begun. The client knows because it recorded three intervals when it accepted the lease. At the first, T1, it asks the leasing server for continuity. At the second, T2, it broadcasts the request so another authorised server can answer. At the third—the lease's expiry—the address must be abandoned if no acknowledgement has arrived.

This sequence is easily flattened into “automatic renewal.” That phrase hides the design. DHCP does not keep one responder set for the entire lease. It starts with affinity, relaxes that affinity to protect availability, and finally makes time stronger than local observation.

Reusable addresses required revocable bindings

BOOTP could deliver configuration to a booting host, but it did not make a limited pool of addresses reusable through timed custody. RFC 1541, issued in October 1993, described DHCP's dynamic allocation as an address assignment for a limited period or until explicit release.

The RFC called the resulting state a binding: configuration parameters, including at least an IP address, associated with a client and managed by DHCP servers. Dynamic allocation made serial reuse possible. One address could serve different clients at different times without pretending that any client owned it permanently.

That distinction remains more important than the familiar four-message discovery sequence. The address is not a fact handed over once. It is one part of a time-bounded configuration decision maintained by a service under local policy.

RFC 2131, published in March 1997, retained three allocation models. Automatic allocation may be permanent. Manual allocation conveys an administrator's choice. Dynamic allocation is the model that depends on the lease clock and the staged reacquisition states discussed here.

One lease carried three clocks

The lease duration and its two reacquisition times are separate values. RFC 2132 assigns option 51 to the address lease time, option 58 to Renewal Time Value T1, and option 59 to Rebinding Time Value T2. Each is an interval in seconds from address assignment, not a wall-clock date.

When a server does not supply valid T1 and T2 values, RFC 2131 gives defaults: T1 at one half of the lease and T2 at seven eighths. It recommends some random variation so a fleet does not attempt reacquisition in lockstep. These fractions are fallback protocol values, not universal operating advice; a server can provide different valid intervals.

The order conveys policy. T1 must leave time for a conversation with the original authority. T2 must leave time for a wider recovery attempt. Expiry is not another retry threshold. It is the end of the current binding.

T1 gave the leasing server the first answer

When T1 arrives, a BOUND client enters RENEWING. It sends DHCPREQUEST to the server that granted the lease when it knows that server's address. The client's current address appears in ciaddr; the message is not selecting among fresh offers.

This preference preserves state ownership. The leasing server knows the binding it created, the local policy behind it, and any configuration changes that should accompany an extension. It may grant a longer lease, return modified parameters or decline to extend according to administrative policy.

The absence of an immediate reply does not invalidate the address. The existing lease remains the client's authority. The client retransmits while measuring the time left before T2. A server outage and a lease revocation are different events.

That difference keeps a brief control-plane failure from becoming an instant data-plane outage. It also prevents the client from treating server silence as unlimited permission.

T2 widened discovery, not authority

If no DHCPACK arrives before T2, the client enters REBINDING. It broadcasts DHCPREQUEST, fills ciaddr with the address it is using, and omits the server identifier. The change lets other servers hear a request that the original server may never receive.

Broadcast alone does not decide who may extend the lease. RFC 2131 states that a server may do so only if it has local administrative authority. The mechanism was intended for sites with multiple servers and a way to keep their lease state consistent.

This is the architectural centre of rebinding. DHCP expands the responder set because availability matters, but it does not turn network reachability into delegation. An alternate server needs the operational authority and state needed to speak for the binding.

If servers disagree, rebinding can expose the inconsistency at the worst possible moment. One server may believe an address is still bound while another believes it is available. The protocol cannot manufacture shared custody from a broadcast; the network has to maintain it.

ACK, NAK and silence were three different verdicts

A DHCPACK during RENEWING or REBINDING creates continuity. The client records the returned lease and starts new T1 and T2 timers. The acknowledgement may also carry changed configuration, so renewal is not merely a ceremonial extension of one number.

A DHCPNAK is the opposite. It tells the client that its current network configuration is not acceptable. The client halts its use and returns to initialization. Continuing to emit traffic after a NAK would turn remembered state into a competing address claim.

Silence is neither ACK nor NAK. While time remains, it leaves the current lease intact and causes bounded retransmission. If the lease expires before ACK, however, RFC 2131 requires the client to move to INIT, stop other network processing, and request configuration as though uninitialized.

The client may still see replies to cached neighbours. Its switch port may remain up. A router may continue forwarding. None of those observations extends the lease. The deadline is the boundary between a failed attempt to retain authority and unauthorized continued use.

A remembered address had to be submitted for judgment

Reboot adds another temptation toward false continuity. A client may remember its former address and believe it has returned to the same network. DHCP's INIT-REBOOT path lets it ask for that address, but the memory is a proposal, not a right.

The request is broadcast because the client may not know whether the old server or even the old network remains relevant. A server can confirm with DHCPACK or reject with DHCPNAK. If the client cannot contact a server, RFC 2131 permits use of the previous configuration only for the still-unexpired portion of its lease.

This makes “same address after restart” a checked outcome. The protocol values continuity, yet it refuses to derive present authority from a value stored on the client.

A later server message could pull renewal forward

The original state machine made renewal primarily timer-driven. RFC 3203 later introduced unicast FORCERENEW so a server could cause a client to enter the normal RENEW state before T1—for example when configuration needed to change.

FORCERENEW does not install new configuration by itself. It prompts an ordinary DHCPREQUEST. A server that wants the client to abandon its address can answer that request with DHCPNAK, sending the client back to discovery.

That power can interrupt active sessions, and a forged trigger could repeatedly disrupt a client. RFC 3203 therefore requires FORCERENEW authentication through the procedures in RFC 3118. The extension demonstrates the same boundary from the other direction: a server may ask the client to revisit the lease early, but must still use a controlled state transition rather than silently rewriting local state.

A lease was permission, not proof that the wire was clear

Even a genuine DHCPACK cannot prove that no other host is using the address on the local link. Configuration authority and observed link state are separate.

RFC 5227 requires an IPv4 host to probe before beginning to use a newly configured address. A DHCP client that detects a conflict sends DHCPDECLINE. The server's plan has met contradictory local evidence and must be reconsidered.

This qualification keeps the lease claim bounded. DHCP can say that the managed service assigned an address to a client for an interval. It does not authenticate the person using the client, prove legal ownership, guarantee end-to-end reachability or make a duplicate address impossible.

Sources and evidence limits

The historical and protocol claims come from RFC 1541, RFC 2131, RFC 2132, RFC 3118, RFC 3203 and RFC 5227:

They define a DHCPv4 contract. They do not establish the current defaults, failover design, client correctness or deployment share of any named product or network. DHCPv6 uses a different protocol. The default T1 and T2 fractions are not proof that every server sends or every client uses those values.