Summary
- RFC 9962 lets xTRs participate in a decentralized LISP Mapping System, distributing EID-to-RLOC state through push multicast or pull DNS discovery instead of depending entirely on a separately managed Mapping System Provider.
- A Map-Register, Map-Notify, authenticated peer relationship, replicated map cache or discovered RLOC is bounded mapping evidence. RFC 9301 expressly distinguishes RLOC status reachability from path reachability as seen by a requester.
The architectural attraction is real. LISP separates an Endpoint Identifier, or EID, from a Routing Locator, or RLOC. A mapping system bridges those two spaces. In the conventional picture, a Mapping System Provider operates the Map-Resolvers and Map-Servers while data-plane tunnel routers register and retrieve mappings. RFC 9962 changes the participation pattern. Its Decentralized Mapping System makes the xTRs that depend on mappings part of the machinery that maintains them.
They can hold distributed state, act as Map-Servers, and establish their own peer relationships instead of treating an outside control-plane service as the only keeper of the record.
That is a change in dependency, not an erasure of judgment. A mapping record answers a deliberately narrow question: which RLOC set has been registered for a particular EID prefix within a particular mapping system. RFC 9301 defines the Map-Register as the ETR's publication of EID prefixes and associated RLOCs to a Map-Server. When requested, a Map-Notify confirms that the Map-Register has been received and processed. Those verbs matter. Registration is not delivery; processing is not an end-to-end test; an acknowledgement is not a warranty that every future packet will reach a useful service.
RFC 9301 states the limit in operational language: an RLOC's status conveys reachability, but does not convey path reachability from a requester's perspective. Separate testing of the path is needed. This is not a minor caveat at the edge of the protocol. It is the boundary that keeps a control-plane record from being mistaken for an operational verdict. A router may know a locator is live in the mapping system while a requester still faces filtering, encapsulation failure, asymmetric routing, congestion, policy rejection, a changed endpoint, or a service that is reachable yet unsuitable for the action at hand.
RFC 9962 supplies two ways to distribute the limited record. In the push design, xTRs join a multicast group; a registration can be sent to the group and the members keep the same registered mapping state. This buys redundancy but requires multicast capability beneath the participants. In the pull design, an agreed transformation of the EID determines a DNS name and hence a Map-Server set. It reduces replicated state, but it depends on all parties using the same algorithm and on the operator's chosen scale-out shape. Neither design is a general federation promise.
RFC 9962 says push and pull cannot be mixed, and that systems using them together remain completely discrete mapping systems.
Authentication is equally bounded. RFC 9962 points to RFC 9301 and ECDSA-AUTH procedures for trust relationships among xTRs. RFC 9301 protects Map-Register origin and integrity, carries replay protections, and permits a Map-Server to reject a registration that fails authentication or policy. Those controls make a particular registration exchange more accountable. They do not turn a cryptographic acceptance into proof that the advertised RLOC is the right business endpoint, that the sender is entitled to a downstream service, or that a different operator must honor the mapping.
The protected claim and the local decision remain separate speakers.
Heng Lu's insistence on a minimum shared mechanism with localized future decisions is useful here as editorial discipline, not as an IETF claim. A shared map can reduce coordination cost. It should not silently acquire power over the party that must route traffic, expose a customer, manage a failure, or fund a recovery. The valuable question is not whether decentralization sounds emancipatory. It is: which dependency did it remove, which record did it make inspectable, and which decision still has to remain with the operator who bears its cost?
Sources
- RFC 9962, A Decentralized Locator/ID Separation Protocol Mapping System (LISP-Decent).
- RFC 9300 and RFC 9301, LISP architecture and control plane.
- RFC 9303, LISP security; RFC 6831 and RFC 6836, multicast and ALT context.
- Heng Lu, Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption and Running-Code Primacy.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
