Summary

  • RFC 10038 defines a DHCPv6 identity association for SRv6 locators, including an IAID, locator structure, preferred and valid lifetimes, T1/T2 renewal points, server bindings and an explicit no-locator status.
  • A valid locator lease is not a route. The RFC separately makes local route installation and routing-protocol advertisement optional actions, while local SID assignment, use of multiple locators and advertisement of those SIDs remain outside its scope.
  • Weiqiang Cheng edited the RFC with Changwang Lin; Ruibo Han, Daniel Voyer and Geng Zhang are fellow authors, and Yuanxiang Qiu is a contributor. Their collective contract is most useful when lease, route, convergence, forwarding and filtering remain separately observable.

Imagine an access-network change review with two screens open. The first is reassuring. A DHCPv6 server accepted a request, created a binding and returned an SRv6 locator. The Reply contains the expected identity association, structure fields and lifetimes. The second screen is the local route table. The locator is absent.

Nothing in the first screen makes the second impossible. The records answer different questions.

RFC 10038, published on the IETF Standards Track in August 2026, defines how DHCPv6 can assign locators to SRv6 segment endpoint nodes. It gives a familiar access-network protocol a new identity association, IA_SRV6_LOCATOR, and an IA Locator option. It also defines a negative result, NoSRv6LocatorAvail, so lack of assignable space does not have to masquerade as a timeout or ambiguous failure.

The authorship record matters because this is shared standards work rather than a personal deployment story. Weiqiang Cheng and Changwang Lin are the editors. Ruibo Han, Daniel Voyer and Geng Zhang are also authors, and Yuanxiang Qiu is listed as a contributor. Cheng's IETF profile, captured on 31 August 2026, identifies him as Chief Architect of IP Networks at China Mobile Research Institute, chair of the SRv6 Operations working group and an author of nine RFCs. Those public roles support a person-centred reading of the mechanism. They do not prove that China Mobile, or any other named operator, deployed it.

The lease has its own identity and clocks

An IA_SRV6_LOCATOR is more than a prefix carried in a convenient message. Its IAID distinguishes that association from the client's other locator associations. T1 tells the client when to contact the server that supplied the locators to extend their lifetimes; T2 tells it when to contact any available server. The encapsulated locator includes preferred and valid lifetimes and the lengths used to describe locator-block, locator-node, function and argument portions, plus an Algorithm value.

These fields make the assignment auditable. An operator can ask which client requested which IAID, through which relay, which server replied, which structure it returned and how much valid time remained. A Renew or Rebind can be associated with the same object. A Release or expiry can end it. The server can reclaim the locator and delete its binding rather than leaving an unbounded allocation in an inventory.

The clocks are not decorative. A locator can remain present but no longer preferred. It can reach T1, then T2, then expiry. A review that records only the prefix loses the conditions under which the prefix remains usable. Conversely, a monitoring system that reports a healthy DHCP exchange but does not follow the route and forwarding consequences has stopped too early.

The client also has a boundary. After a valid Reply, it configures the assigned locator. But RFC 10038 explicitly leaves local SID assignment, the use of multiple assigned locators and advertisement of those SIDs outside its scope. It also prohibits inferring service logic from locator order. A best-effort locator and a low-latency locator may be requested under distinct policies, but their meaning must come from explicit configuration, not their position in a message.

A route is a second decision

Section 5.5 describes what can happen next. A DHCPv6 relay or server receiving the allocation request may assign a locator and install a corresponding local route. The next hop should point to the requesting client. The relay or server may then advertise that route through a traditional routing protocol so other routers can learn it.

The repeated word “may” is operationally important. The assignment transaction does not contain a hidden command that guarantees route installation everywhere. Policy, implementation, topology and protocol state still intervene. For an Algorithm value of zero, the locator can be advertised as normal IP reachability. For a non-zero Algorithm, the RFC requires the locator TLVs defined for IS-IS or OSPFv3 SRv6. The route form therefore depends on an explicit field rather than on a guess about the prefix.

This separates at least six receipts: the server binding; client locator configuration; local RIB entry; local FIB programming; routing advertisement and downstream convergence. A seventh receipt is observed traffic. Each can fail while the previous one remains true.

A server can hold a valid binding while its relay has no route. A relay can install the route while export policy suppresses the advertisement. An advertisement can leave one router and not converge at another. Every router can have reachability while the CPE lacks the local SID or SR policy needed for the intended service. The policy can exist while a filter, next-hop error or data-plane defect prevents delivery.

This is not an argument against automation. It is an argument for preserving state boundaries so automation can locate the failure instead of repainting it as one green result.

Release is where the join becomes visible

Allocation is only half of the contract. When the client releases the locator, the relay or server must release the allocated resource, remove the local locator route and withdraw the previously advertised route. Lease expiry likewise causes the server to reclaim the locator and delete the binding.

Those actions belong to different components. A reliable implementation needs a correlation key and an ordered consequence chain. Which Release ended which IAID? Which local route depended on it? Which advertisement was withdrawn? Which downstream systems acknowledged the change? Which SR policies or cached decisions referred to the locator? An operator does not need every component to become one giant system, but it needs enough joined evidence to show that the old state stopped being usable.

Aggregation makes that test more subtle. RFC 10038 notes that an operator may advertise an aggregate rather than each individual locator to protect RIB performance. Releasing one locator may therefore leave the aggregate visible. The delegating router is expected to discard packets for a specific prefix that is no longer delegated. An aggregate route can be correct at the same moment an individual locator is invalid.

A dashboard that equates aggregate presence with individual delegation would conceal that distinction. A packet test to an expired locator that reaches the aggregate boundary and is dropped can be the intended result, not evidence that the withdrawal failed. The receipt needs both levels: aggregate reachability and the current set of valid specific delegations.

The trust domain is an assumption with controls

The example deployment assumes a single trusted SR domain. The CPE is managed by the service provider or a trusted partner; if it sits at customer premises, the device and its ports remain under the operator's administrative domain. That is a demanding premise, not a label that makes hostile behaviour impossible.

DHCPv6 does not provide end-to-end encryption by default. RFC 10038 carries forward the risks of hijacking, tampering and eavesdropping. It also notes that different locator-allocation mechanisms can accidentally use the same space unless their pools are separated, and that a malicious client can imitate many clients to consume allocations despite per-client limits.

At the border, the DHCPv6 client must filter traffic on both internal and external interfaces as required by the SRH security model. This matters because locator structure and SRv6 behaviours belong inside a bounded domain. A device cannot satisfy the security contract merely by appearing in the correct inventory or receiving a valid lease. Administrative control, address separation and traffic filters are running controls whose state must be checked.

A receipt for the running result

Heng Lu's Running-Code Primacy offers a useful discipline here: a declared state is not the operational result. Minimum Initial Specification sharpens the design. The common layer should specify what interoperability and safety require, while local choices remain local. RFC 10038 follows much of that grammar. It defines option syntax, lifetimes, client and server behaviour, release and route-handling boundaries without attempting to prescribe every SID plan, service policy or routing design.

An operator can preserve that narrowness and still build a strong evidence join. The record should connect client identity, IAID, server and relay, locator and structure, Algorithm, T1/T2, preferred and valid lifetimes, binding state, client configuration, local route, advertisement mode, convergence, SID and policy state, filters and controlled packet observation. It should include time and software context so another operator can reproduce the conclusion.

The final claim can then be exact. “Locator assigned” is a useful fact. “Route installed” is another. “Advertised and converged” is another. “Policy programmed and packet delivered under the intended conditions” is stronger still. The value of RFC 10038 is not that it collapses these statements. It gives the first one enough identity and lifecycle discipline to be joined honestly to the rest.

Sources