Summary

  • RFC 9915 is IETF Internet Standard STD 102, published in January 2026, and obsoletes RFC 8415.
  • Its meaningful operational change is a tighter lifecycle around client/server exchanges, DUIDs, Server Identifiers, Identity Associations, lifetimes, renewal, rebinding, relays, Reconfigure and Prefix Delegation—not a new address message.
  • RFC 9915 removes IA_TA temporary-address assignment and the Server Unicast capability, including the Server Unicast option and the UseMulticast status code.
  • This does not eliminate IPv6 privacy addresses. SLAAC and its temporary-address mechanism remain bounded by RFC 4862 and RFC 8981.

What changes in the model

RFC 9915 specifies DHCPv6 for stateless configuration and stateful assignment of IPv6 addresses and prefixes, either in place of or alongside SLAAC. A client and server exchange messages across a direct link or through relays. The client’s DUID identifies the client; the server’s identifier lets the client recognize the authority whose replies belong to the current transaction. Identity Associations (IAs) group the resources and state being managed, including address associations and delegated prefixes.

That structure makes a lease more than an allocated address. Preferred and valid lifetimes define how long an address or prefix may be used and when it should be renewed or retired. A client normally Renewes with its selected server before expiry. If that server cannot be reached, Rebind broadens the search to available servers. A successful initial Reply therefore proves only that one exchange worked. It does not prove that a later Renew, Rebind, relay path or downstream delegated-prefix use will work.

Relays are part of this state boundary. They carry client/server traffic across a topology where multicast reachability, relay selection, interface identity and server continuity can differ from the initial path. Reconfigure can ask a client to revisit configuration, but operators must verify that clients accept and process that signal through the actual relay and policy path. A server replacement or failover event must preserve the identifiers, IA interpretation and timing assumptions that clients use to continue the lease; the standard does not make every mixed implementation safe automatically.

Prefix Delegation extends the same reasoning to a customer-edge router. The delegated prefix has lifetimes and an IA context, and the router must continue using it for downstream networks consistently with those lifetimes. RFC 7084 supplies customer-edge requirements and deployment context, but it is not evidence that a particular implementation or topology will preserve delegation through failover. Test the server boundary, relay boundary and downstream renumbering behavior separately.

Retired capabilities and privacy boundaries

RFC 9915 removes IA_TA, the DHCPv6 temporary-address assignment mechanism. It also removes Server Unicast, its option, and the UseMulticast status code. These are protocol-surface changes that narrow what a conforming current state machine should expect. They do not mean that privacy addressing disappeared. RFC 4862 defines SLAAC, and RFC 8981 defines temporary addresses for SLAAC; a deployment can still use those mechanisms where its policy and host behavior call for them. Nor does RFC 9915 imply that DHCPv6 always replaces SLAAC.

Multiple stateful options and multiple IAs deserve their own test matrix. RFC 7550 identifies operational issues around multiple stateful DHCPv6 options; one successful IA or option exchange cannot stand in for the behavior of every IA. Observe address and prefix lifetimes independently, correlate DUID, Server Identifier and IA identity, and record which server and relay handled each transition.

Operator acceptance decision path

  1. Inventory. Identify DHCPv6 servers, relay paths, multicast dependencies, client DUID behavior, Server Identifiers, every IA, downstream delegated-prefix consumer and any legacy IA_TA or Server Unicast expectation.
  2. Baseline. Capture initial allocation, preferred/valid lifetime values, Renew timing, Rebind timing, Reply ownership, relay metadata and the client’s resulting routing and address state.
  3. Exercise transitions. Test server loss, server replacement, relay loss, relay re-selection, multicast-unreachable segments, Reconfigure, multiple IAs, and mixed RFC 8415/RFC 9915 behavior. Treat mixed-version behavior as an unknown until measured; do not infer it from the standard alone.
  4. Test delegation. Let a customer-edge router renew and rebind a delegated prefix, then verify downstream prefix use, expiry handling and recovery after server or relay change.
  5. Check privacy and coexistence. Confirm that SLAAC and RFC 8981 temporary addresses behave according to policy. Do not accept removal of IA_TA as proof that privacy addresses are gone, or as proof that DHCPv6 has replaced SLAAC.
  6. Observe and roll back. Require logs and metrics for DUID, Server Identifier, IA, lifetime, Renew, Rebind, Reconfigure, relay path and prefix continuity. Roll back if any critical transition loses authority, strands a downstream prefix or creates an unbounded address state.

The acceptance decision is go only when lifecycle evidence passes, not when initial allocation passes. Otherwise keep the change in a bounded pilot, preserve the previous configuration, and define a rollback trigger for failed renewal, rebinding, relay reachability, delegation or privacy behavior. This is Theo March analysis: the standard supplies the state machine; the operator must prove that the surrounding system carries its state.

Sources

Claim-to-RFC evidence ledger

Claim Evidence
Current DHCPv6 state, exchanges, identifiers, IAs, lifetimes, Renew, Rebind, Reconfigure, removed capabilities and delegation RFC 9915
Previous DHCPv6 baseline and revision boundary RFC 8415
SLAAC coexistence and address autoconfiguration RFC 4862
Customer-edge and delegated-prefix context RFC 7084
Multiple stateful options and multiple-IA operational boundary RFC 7550
SLAAC temporary-address privacy behavior RFC 8981

This briefing does not claim vendor support, universal deployment or completed migration. It also does not claim that RFC 9915 replaces RFC 9914’s RPL projected-route state, RFC 9913’s radio capability normalization, or RFC 9912’s RAW recovery graph. Those are distinct subjects; this article is about DHCPv6 lease, identity, lifetime and delegated-prefix continuity.