Summary

  • RFC 10038 lets an SRv6 segment endpoint obtain a structured locator through DHCPv6, including lifetimes, algorithm and locator-layout fields.
  • Because assignment can create and advertise a locator route, renewal, release and expiry become routing-state events rather than ordinary address housekeeping.

The lease behind the SID

SRv6 gives a locator a structural role. It identifies the address space from which a node allocates Segment Identifiers, so the locator determines more than where one interface can be reached. RFC 10038 carries that structure in two new DHCPv6 options. The IA Locator contains preferred and valid lifetimes, an IGP Algorithm value, the lengths of the locator block and node portions, function and argument lengths, and the locator bytes themselves.

Those fields place a decision at the allocation boundary. The client can express a preference, but the server searches its configured locator pool and creates the binding according to server policy. The sum of the structural lengths cannot exceed 128 bits, and the locator block plus node length cannot be zero. A client must discard a locator whose preferred lifetime exceeds its valid lifetime. These are protocol facts, not evidence that any particular product validates them correctly.

IANA assigned option codes 149 and 150 and the NoSRv6LocatorAvail status code 23. A negative response is therefore a defined outcome, not an invitation to invent a locator locally. The specification does not prescribe the operator’s pool design or decide which organization may approve an allocation.

A lease transition can become a route transition

The lifecycle follows DHCPv6: Solicit, Advertise, Request and Reply establish a binding; Renew and Rebind try to preserve it; Release relinquishes it. If renewal fails through the relevant timer and no reply arrives, the client treats the lease as expired and starts again. On valid release or expiry, the server reclaims the locator.

RFC 10038 then crosses into routing. A server or relay may install a local route for the assigned locator, with the requesting client as next hop, and may advertise that route through an IGP. A release requires removal of the local route and withdrawal of the earlier advertisement. Algorithm zero locators may use ordinary IP reachability; non-zero Algorithm locators must use the locator TLVs defined for IS-IS or OSPFv3.

This coupling is the article’s operational inference: the lease ledger, RIB entry and IGP advertisement are representations of one authority decision. They can still diverge in implementation. A successful DHCP reply does not prove that the route was installed, propagated, programmed in forwarding or usable end to end. Conversely, a route left behind after the binding expires would preserve reachability evidence after the allocation authority had ended. No claim is made that either failure has occurred in a named network.

Aggregation changes the failure shape

RFC 10038 notes a stability trade-off. Advertising aggregates can reduce RIB churn when individual leases change. Yet a withdrawn specific locator can remain covered by an aggregate; traffic for a prefix no longer delegated on the customer-facing interface may then be discarded there. The aggregate preserves coarse reachability while the specific authority has disappeared.

That distinction matters to monitoring. Counting an aggregate as proof that every locator below it remains valid would confuse a routing summary with the underlying lease state. Operators need both views: the aggregate policy that protects the RIB and the binding-level state that explains whether a particular locator should still terminate at a particular endpoint.

Security starts with who may allocate

RFC 10038 inherits DHCP security considerations and explicitly notes the absence of end-to-end encryption between DHCP clients and servers, leaving hijacking, tampering and eavesdropping possible where other protections are absent. It also warns that mixed allocation mechanisms can assign the same locator to more than one device. Partitioning pools between mechanisms is one mitigation.

The standard does not turn a DHCP exchange into proof of organizational authorization. That proof remains local: which server and relay were trusted, which client identity was admitted, which pool and algorithm were approved, and which change record explains the binding. Protocol validity and business authority are separate evidence.

Sources