A phone holding an unexpired DHCPv4 lease rejoins Wi-Fi after two days away; when does its INIT-REBOOT request get a DHCPACK, a DHCPNAK, or silence?

## Why a returning client rechecks A phone that leaves the Wi-Fi for two days may come back to the same network, a different VLAN, or a network whose server has changed. RFC 2131 §3.7 says a client SHOULD use DHCP to "reacquire or verify its IP address" whenever the local network may have changed, "e.g., at system boot time or after a disconnection." When the client remembers an address whose lease has not expired, it can take the short path of §3.2 and §4.4.2 rather than the full four-message exchange. Take a concrete case: the phone was granted a seven-day lease the morning it left. Two days later it is still before `T1` (three and a half days), so the lease is valid and the address is worth asking for. ## What the INIT-REBOOT request carries The client enters **`INIT-REBOOT`**, sends one message and moves to **`REBOOTING`** to wait. RFC 2131 §4.3.2 and Table 4 fix its contents: | Field | INIT-REBOOT `DHCPREQUEST` | Why | |---|---|---| | Delivery | broadcast | the client is not yet sure its address works here | | `requested IP address` option | MUST carry the remembered address | this is what the server checks | | `ciaddr` | MUST be zero | the client has not yet confirmed the address | | `server identifier` option | MUST NOT be present | any server that knows the client may answer | | `client identifier` option | the same one used to get the lease | the lease is keyed on it | | `xid` | a new random value | to match the reply | Contrast this with a renewal, where the address sits in `ciaddr` and the requested-address option is absent; the two layouts are how a server tells "verify me" from "extend me". ## How a server decides RFC 2131 §4.3.2 gives the server's checks in order: 1. **Is the client on the right network?** The server applies the subnet mask of the interface the request arrived on, or the remote subnet named by `giaddr` if a relay forwarded it, to the requested address. If it does not match, the server SHOULD send **`DHCPNAK`**. No client record is needed for this check. 2. **Is the client's idea of its address right?** On the right network, if the server's record says something else (the address went to another client, or the client is bound to a different one), it SHOULD send **`DHCPNAK`**. 3. **Does the server know the client at all?** If it has **no record**, it "MUST remain silent, and MAY output a warning to the network administrator." The RFC calls this necessary "for peaceful coexistence of non-communicating DHCP servers on the same wire": a server that knows nothing must not contradict one that does. 4. Otherwise the record matches and the server sends **`DHCPACK`**. RFC 2131 §3.2 adds a related rule: a server that sees a request for an expired binding owned by *another* server SHOULD NOT send a `DHCPNAK` unless the servers maintain coherency through an explicit mechanism. ## How the NAK reaches a client with no working address A client being refused may hold an address or mask that is wrong for the link, and "may not be answering ARP requests." So the server never unicasts the NAK to the requested address: - with `giaddr` zero, the server **broadcasts** the `DHCPNAK` to `255.255.255.255`; - with `giaddr` set, it sets the **broadcast bit** so the relay agent broadcasts the NAK onto the client's segment. ## What the client does with each outcome - **`DHCPACK`** — the client records the expiry as the time it sent the request plus the lease in the ACK and moves to `BOUND`. If it then finds the address already in use, it MUST send `DHCPDECLINE` and restart. - **`DHCPNAK`** — it "cannot reuse its remembered network address" and goes to `INIT`, then runs the full exchange for a new one. - **Silence** — it retransmits with the usual randomised doubling back-off; RFC 2131 gives four retransmissions over about 60 seconds as an example. If neither an ACK nor a NAK arrives, it **MAY** keep the remembered address "for the remainder of the unexpired lease" and moves to `BOUND`. ## Reading the symptoms The silence rule explains a familiar complaint: a device that takes about a minute to come up and then appears with its old address. That is a client whose request reached no server holding its record — the server was replaced, its lease database was lost, or the request reached only a server that did not grant the lease. The client is behaving correctly; whether the address is still safe depends on whether anyone else has since been given it. If the phone's lease had already **expired** during its absence, the short path no longer applies: on expiry RFC 2131 sends a client to `INIT`. It may still name the old address as a hint, because the `requested IP address` option MAY appear in a `DHCPDISCOVER` and servers attempt to return the same address to a client.