Summary

  • RFC 10038, published on the IETF Standards Track in August 2026, defines DHCPv6 option 149 for an SRv6 locator identity association, option 150 for each locator and status code 23 when no locator is available. It standardizes allocation inside one trusted SR domain, not end-to-end reachability.
  • A successful Reply proves that a server made a binding under its policy. Client configuration, the relay or server route, IGP propagation, downstream RIB and FIB state, local SID behavior, filters, packet outcome, withdrawal and reuse remain separately owned and separately evidenced.

Consider a managed edge node that requests an SRv6 locator during commissioning. The server returns a prefix, the layout lengths, preferred and valid lifetimes, T1 and T2. The provisioning dashboard turns green. A remote router, however, has not learned a route. The edge has not instantiated the expected SID behavior. The customer-facing filter still admits traffic for a locator released the previous hour.

Nothing in the DHCP transaction proves those later conditions. The allocation may be correct while the network is not ready.

RFC 10038, published in August 2026, defines a way to distribute an SRv6 Locator to an SRv6 Segment Endpoint Node using DHCPv6. It assumes the participants sit inside a single trusted SR domain, including a managed CPE that may be physically located on customer premises. The document adds two options and one status code to the IANA DHCPv6 Parameters registry.

OPTION_IA_SRV6_LOCATOR, option code 149, is the container. It carries an IAID, T1, T2 and nested options. Multiple containers may appear in one message, with unique IAIDs in a number space separate from other DHCPv6 identity associations. OPTION_IALOCATOR, option code 150, sits inside that container. It carries preferred and valid lifetimes, Algorithm, LB-Len, LN-Len, Fun-Len, Arg-Len, the minimally encoded locator and further options.

The lengths describe structure, not a completed service. LB-Len plus LN-Len is the locator length. All four length fields may not sum above 128, and the locator length may not be zero. A malformed locator option can be rejected without turning every other part of the DHCPv6 message into a claim about routing.

The client asks; the server allocates

The client normally sends T1, T2 and the preferred and valid lifetimes as zero. The server ignores client-supplied values in those fields and chooses the lease state. A client may offer nonzero LB-Len and LN-Len with an all-zero address as a sizing hint, but the hint is not an entitlement to that layout or to any particular prefix. Policy and pool ownership remain with the server.

The server may return more than one locator if its policy permits. It may decline with NoSRv6LocatorAvail, status code 23. The client must discard a locator whose preferred lifetime is greater than its valid lifetime. It must also avoid assigning service meaning to the order in which locators arrive.

These details matter because automation often converts a negotiated result into a broader assertion. “Locator assigned” is a defensible statement about the binding ledger. “Node reachable” is not. RFC 9915, the base DHCPv6 specification, provides transaction, identity-association, renewal and release machinery. It does not turn address configuration into a routing-protocol acknowledgement.

Nor is the locator an ordinary host address or a complete SID. RFC 8402 establishes Segment Routing architecture, while RFC 8986 describes SRv6 endpoint behaviors and SID structure. Local SID allocation, the use of multiple locators and the advertisement of individual SIDs are deliberately outside RFC 10038. The receiving node retains authority over what functions, if any, it instantiates under the delegated locator.

Route authority begins after the binding

RFC 10038 allows a DHCPv6 relay or server to install a local route for the allocated locator, with a next hop toward the requesting node. It may then advertise that route through a traditional routing protocol. Both are operational actions, not automatic consequences encoded in the Reply.

The distinction continues through the network. A routing process can originate an advertisement; neighbors still apply authentication, import policy and topology rules. Their RIBs can select or reject it. Their FIBs can lag, fail to program or point somewhere unexpected. A route in one control plane is not proof of a packet in every data plane.

Algorithm zero uses normal IPv6 prefix reachability. A nonzero Algorithm must use the SRv6 locator TLVs called out by RFC 10038 so that the algorithm identity is not erased. RFC 9350 explains how constrained-path computation uses flexible algorithms. Collapsing a nonzero locator into an ordinary prefix advertisement can therefore preserve the bits while losing the intended topology semantics.

At the endpoint, RFC 8754 governs the IPv6 Segment Routing Header and RFC 8986 governs behaviors. Even a correctly forwarded packet can arrive at a node that lacks the intended SID, applies a different local function or filters the traffic. Allocation, route reachability and service authorization are three different propositions.

Release is a distributed withdrawal, not a database verb

The reverse path exposes the same boundary more sharply. When a valid Release is processed, the allocating relay or server must release the binding, remove its local route and withdraw the route it previously advertised. Those acts occur across systems with different clocks. A freed pool record does not prove that every IGP listener has removed the route, every FIB has converged or every endpoint has stopped recognizing a SID from that locator.

The IA has no independent lifetime after all of its locator entries expire. T1 directs renewal back toward the original server; T2 permits a broader search for an available server. Preferred and valid lifetimes count down in seconds, and 0xffffffff means infinity. These timers determine binding eligibility. They do not measure the last packet or the last remote forwarding entry.

Aggregation makes the proof more subtle. If the backbone continues to advertise a covering prefix, withdrawing a more-specific locator need not remove reachability to the delegating edge. The edge must discard packets on the customer-facing interface for prefixes no longer delegated. Otherwise the aggregate can deliver stale traffic to a resource that the lease ledger already calls free.

Before reuse, operators therefore need a quarantine boundary: binding closed; local route removed; advertisement withdrawn; diverse downstream RIB and FIB observations cleared; expected traffic stopped; forbidden traffic rejected; endpoint SID state removed. The locator can then return to the pool with evidence that the old authority no longer survives in the path.

“Trusted domain” narrows deployment; it does not erase security

RFC 10038's trust assumption is not universal authentication or encryption. DHCPv6 does not provide universal end-to-end confidentiality. In an unprotected environment, hijacking, tampering and observation remain possible. Border CPEs need filters on internal and external interfaces, and infrastructure locator space should remain distinguishable from ordinary end-user addressing.

Pool governance also matters. DHCPv6 and another allocator can assign the same locator twice unless their pools are partitioned or reconciled. A per-client quota can be bypassed by an attacker presenting many client identities. The unique IAID namespace helps distinguish associations within the protocol; it does not prove the real-world identity or authorization of the device behind a message.

RFC 7227 and RFC 8168 explain why protocol identifiers and address semantics need disciplined assignment. RFC 8987 places additional operational attention on SRv6 network programming. An IANA registration creates a common wire vocabulary. It does not certify a deployment, pool partition, filter or route.

One ledger must reconcile several owners

A defensible record ties the DHCP transaction to the executed network. Retain the client DUID, IAID, relay or access-port context, authorization and policy version; the hint and granted locator layout; transaction times, lifetimes, T1 and T2; binding and pool state; locally instantiated SIDs; the relay or server RIB and FIB entry; the IGP origin, algorithm and version; downstream RIB and FIB observations; filter results; permitted and forbidden packet canaries; release or expiry, withdrawal propagation, last packet, quarantine and reuse.

Heng Lu's running-code primacy puts authority in this executed sequence rather than in a clean request record. His account of technical and practical data sovereignty explains why a server can own a binding database yet not control copies of the route in independent forwarding systems. His model of a minimum initial specification with localized future decisions fits the protocol boundary: common fields enable interoperation; local operators retain admission, routing, filtering and consequences.

RFC 10038 gives allocation a precise language. Its operational discipline lies in refusing to use that language as a synonym for reachability.