Summary

  • RFC 9915 treats a valid Renew, Rebind or Information-Request Reply's omission of a newly requested, previously supplied configuration option as a withdrawal instruction.
  • The omission proves the content of one correlated exchange. It does not prove that the client removed the value, reloaded every consumer, stopped traffic to the old endpoint or achieved the intended service result.
  • Identity Association options follow a different state machine, while equivalent configuration can legitimately survive from another source; an audit must establish scope and provenance before declaring non-compliance.

Absence becomes meaningful only inside an exchange

An empty place in a packet is not automatically an instruction. Section 18.2.10.5 of RFC 9915 requires a chain: the client previously received a configuration option in a Reply; it later requested that option again in a Renew, Rebind or Information-Request; and a valid Reply to that exchange omitted it. Only then does the absence acquire withdrawal semantics.

That chain matters operationally. A capture of the final Reply alone cannot show that the option was requested. A dashboard that compares two server configurations cannot show which client received which response. A decoded packet without transaction, direction and validation context cannot establish that the client was entitled to apply it. The minimum evidence set preserves the earlier grant, the later request and the correlated omission.

RFC 9915 then says the client SHOULD stop using the old information, behave as though it had never received the option and return to the relevant default state. This is a clear protocol obligation. It is still not a receipt from the client's configuration manager. The server can prove what it sent; it cannot, from that fact alone, prove what a process on the client is now using.

The standard deliberately refuses one universal removal rule

The text contains a narrow persistence exception. A value MAY remain when there is no viable way to stop using it, no other source supplies the data and keeping it has no external impact. RFC 9915 illustrates the case with a hostname set through the Client FQDN option: if a node cannot reasonably unset the hostname and retention affects nobody else, persistence can be acceptable. RFC 4704 supplies the surrounding FQDN and DNS-update semantics.

The counterexample is intentionally sharper. If the client previously received an NTP server address and the later qualifying Reply omits it, the client MUST stop using that configured address. RFC 5908 defines the DHCPv6 option as server-location information for the time client. A process list or packet trace showing continued contact with that endpoint would therefore deserve investigation.

Even that observation is not the whole verdict. RFC 9915 also says the client should remain open to other sources of the same information. DNS makes the provenance problem concrete: RFC 3646 can supply recursive-server addresses through DHCPv6, while RFC 8106 can supply RDNSS addresses through Router Advertisements, each with its own authority and lifetime. The same address can survive a DHCP withdrawal because a separate mechanism still authorizes it. Equality of value is not identity of source.

Do not apply this rule to address and prefix bindings

Section 18.2.10.5 expressly excludes Identity Association options. IA_NA addresses and IA_PD prefixes are processed under the separate rules in Section 18.2.10.1. An auditor who treats a missing IA as an ordinary omitted configuration option collapses two state machines and may infer a withdrawal that the cited subsection does not define.

Reconfigure is another boundary. A valid Reconfigure message triggers a Renew, Rebind or Information-Request exchange; it is not the resulting configuration. RFC 9915 notes that reconfiguration can affect applications, recommends logging the event and permits implementation-specific notification. Those are useful observation points. They do not allow a trigger receipt to stand in for the completed exchange, local application of the result or service recovery.

Build the retirement record from both sides

A defensible change record begins with the server exchange but ends on the client. Preserve the original Reply that supplied the option. Preserve the later request proving it was asked for again. Preserve the valid Reply that omitted it. Then capture the client configuration transition, the process reload or replacement, the provenance of any surviving equivalent value and traffic showing whether the old endpoint remains in use.

Only the last stages can answer the question leadership usually means by “removed”. The RFC establishes control semantics. Running state establishes execution. Traffic and application measurements establish effect. Reporting the first as though it were the last converts a precise standard into an overbroad assurance claim.

RFC 8415 already contained substantively the same withdrawal rule; RFC 9915 gives it a dedicated subsection while replacing the earlier base specification. This is therefore not a newly invented 2026 power. The improvement is that operators now have a clearer citation for a boundary they still must observe in running systems.

Sources