Summary

  • LISP gives Endpoint Identifiers and Routing Locators different jobs, but packets move only when an ETR has registered an authorised mapping, an ITR has resolved and cached it, a permissible RLOC has been selected, the underlay reaches that RLOC and the destination site completes delivery.
  • David Meyer's useful place in this history is not that he made location irrelevant. As a co-author across the original and current LISP data-plane specifications, he helps expose how an architectural split becomes a time-bounded custody system whose records, trust and operational state must not be confused.

The useful inconvenience of asking again

An ordinary IP address appears to answer two questions at once: which endpoint is this, and where should the network send the packet? That compression is convenient until the answers need to change at different speeds. A site may want a durable way to name an endpoint while its upstream connection, attachment point or preferred path changes. Yet the global routing system pays when edge changes are expressed as more and more specific routes.

The 2006 IAB Routing and Addressing Workshop put this tension in unusually direct terms. Its report, RFC 4984, said that overloading one number with identifier and locator semantics contributed to the scaling problem. Participants thought a split appeared necessary, but did not pretend that naming the split supplied an architecture. The report was a record of workshop views, not an IAB decree and not a deployment result.

LISP became one concrete answer. RFC 9299 describes two namespaces that look exactly like IPv4 or IPv6 addresses but perform different work. An Endpoint Identifier, or EID, names a node without carrying inter-domain topological location. A Routing Locator, or RLOC, names a network attachment point in the underlay. A Mapping System relates the first to one or more of the second, and tunnel routers encapsulate the inner packet toward a selected RLOC.

This creates a memorable slogan—separate identity from location—but the slogan hides the operating system underneath. The EID cannot route itself across the underlay. It has to ask a maintained set of institutions and machines where it currently lives.

A stable number, six changing assertions

RFC 9300, the current Proposed Standard for the LISP data plane, is careful about the first assertion. An EID used on the public Internet must be unique like another public IP address and comes from an EID prefix associated with a site. Uniqueness is necessary. It is not an ownership title, a human authentication result, a promise of portability, or evidence that any mapping has been published.

Delivery requires a longer chain:

Claim Operational custodian and evidence
The EID has a current location set An authorised ETR configuration and accepted Map-Register name one or more RLOCs.
The mapping can be found The Mapping System and a Map-Resolver return the applicable EID-to-RLOC record.
This sender has usable state The ITR holds an unexpired, validated Map-Cache entry after a longest-prefix lookup.
One locator is permitted Priority excludes inferior choices; Weight distributes traffic among equally preferred RLOCs.
The locator is reachable The underlay has a working path to the selected RLOC.
The endpoint receives the packet The ETR decapsulates and forwards the inner packet inside the destination site.

The conjunction matters. A valid EID can coexist with a missing registration. An accepted registration can coexist with a stale remote cache. A fresh mapping can contain an RLOC that the underlay cannot reach. A packet can arrive at the ETR and still fail on the last internal segment. “The identifier is correct” proves none of those later claims.

RFC 9300 makes the sender's uncertainty visible. An ITR performs a longest-prefix lookup in its local, on-demand Map-Cache. On a hit, it obtains a Locator-Set. On a miss, it asks the control plane described by RFC 9301. While resolution is pending, a deployment may drop or buffer the packet. The standard deliberately leaves that availability choice to the operator. Once a reply arrives, the ITR stores the mapping for subsequent traffic.

The stored answer is leased, not eternal. Map-Cache entries expire according to an associated Time to Live and can be updated with newer information. A Map-Reply can set the TTL to zero and require immediate removal; a special all-ones value lets the receiver decide how long to keep it. The cache also holds reachability state. The system therefore distinguishes an answer that once existed from an answer that remains current at this ITR.

Location has policy as well as coordinates

A mapping can list several RLOCs. It also carries Priority and Weight. The lowest Priority wins; a value of 255 means that locator must not forward traffic. When several RLOCs share the best Priority, Weight apportions load. The endpoint identifier remains visually stable while operating policy changes the path beneath it.

That distinction helps explain why location has not vanished. It has been externalised into a record that someone is authorised to publish, someone else resolves, many ingress routers cache, and the underlay must honour. The record can express multihoming and traffic engineering, but it also acquires expiry, convergence, security and rollback problems.

RFC 9301 supplies the control-plane roles. An ETR periodically sends a Map-Register containing its EID prefixes and RLOCs to a Map-Server. A Map-Resolver accepts a Map-Request from an ITR and finds the applicable mapping. Registration is not merely a packet format. The ETR and Map-Server must have a pre-shared secret for authentication, and the server should know which prefixes that ETR may register. Without the prefix check, the RFC warns, trivial hijacking becomes possible.

The ordinary cadence exposes another boundary. Registrations are refreshed periodically and may be removed when valid refreshes stop. A negative reply can mean no registered locator, a policy denial or an authentication failure, and it can direct the ITR to forward natively, retry, do nothing or drop. A single dashboard label such as “mapping failed” throws away information the protocol deliberately preserves.

When an ETR changes a mapping, a Solicit-Map-Request can prompt remote ITRs that have cached it to ask for fresh state. The mechanism is selective and rate-limited. An ITR with no relevant cache entry should not fetch an update merely because it received the prompt. Change is propagated to consumers with active state; it is not a magic invalidation of every possible cache at once.

RFC 9302 makes this problem more concrete in closed, trusted environments. Its optional twelve-bit Map-Version can change when an RLOC is added or removed, when Priority or Weight changes, or when local reachability changes. Because the number space wraps, an operator must prevent a very old value from looking new, including by waiting at least the previous TTL or until active traffic uses the latest state. On the public Internet, RFC 9300 forbids using Map-Versioning, gleaning, Locator-Status-Bits or Echo-Nonce as shortcuts for mapping updates or locator reachability. Public deployments must rely on the control plane.

A clever data-plane hint is not automatically safe evidence.

Trust is part of the map

Separating the namespaces also increases the value of a mapping. A forged EID-to-RLOC answer can redirect traffic, impersonate the requested EID or overclaim a larger prefix. RFC 9301's security analysis begins with strong assumptions: the Mapping System is trusted; ETRs have a preconfigured trust relationship with it; and the system knows which EIDs an ETR may advertise. How those keys and entitlements are established is outside that specification.

For the public-Internet use cases covered by the current documents, LISP-SEC is required. RFC 9303 protects lookup data with origin authentication, integrity and anti-replay mechanisms and lets a receiver verify authorisation of EID-prefix claims. Yet its own threat model retains boundaries. It assumes that the Mapping System delivers a request to the intended ETR and that a Map-Server can verify entitlement at registration. Security moves into the custody chain too; it does not become an intrinsic property of the EID.

The privacy consequence runs in the opposite direction. RFC 9301 notes that a long-lived EID bound to changing RLOCs can expose a topological history when mappings are visible. A stable identifier may reduce renumbering while making movement easier to correlate. Architectural continuity and observational privacy are not the same benefit.

David Meyer without the inventor myth

Dave Meyer appears with Dino Farinacci, Vince Fuller, Darrel Lewis and editor Albert Cabellos on RFC 9300. He also co-authored the original RFC 6830. That continuity makes him a useful figure through which to read LISP: not because one person owned the idea, but because the specification matured from a proposed architectural separation into explicit rules for cache expiry, public-Internet restrictions and control-plane security.

ONUG's historical member page records Meyer's work across Cisco, Brocade, the IAB, NANOG and the University of Oregon's RouteViews project. Those are dated biographical markers, not current-employment claims. They also explain a recurring concern in his technical record: the boundary between a control-plane abstraction and the evidence an operator can actually inspect.

The article already published about Meyer focuses on public routing visibility, RPSL, RouteViews and OpenDaylight. LISP exposes a different mechanism. Public visibility asks who can inspect shared control state. LISP asks who is entitled to write an identity-to-location relation, how long a reader may trust it, and what remains to be proved after the lookup succeeds.

Meyer should not receive sole credit for the result. The RFCs have several authors; the IETF approves shared documents; implementers decide what runs; Mapping System operators maintain trust; site operators configure locators; and underlay networks carry the packet. The architecture's intellectual move is separation. Its operational truth is distributed custody.

The checklist that punctures the slogan

RFC 7215, an Experimental deployment guide from 2014, contains an informative migration checklist. It asks operators to verify platform support, current configuration, MTU handling, prefix allocation, RLOC reachability, registration, authentication keys, EID prefixes, proxy cache contents, BGP policies, external visibility and real traffic. Some transition mechanisms in that document belong to a particular period of LISP's development. The evidentiary lesson survives.

A standards document cannot establish that a site registered the intended locator. A successful Map-Register cannot establish that remote caches refreshed. A Map-Reply cannot establish that the chosen RLOC is reachable. A ping to a familiar destination may even succeed through a native or proxy fallback while the expected LISP path is broken.

The strongest implementation report is consequently a dated chain, not a capability badge: registration accepted by the correct server; lookup authenticated; cache entry unexpired; selected Priority and Weight recorded; RLOC reachable through the underlay; decapsulation observed; inner destination reached; fallback classified. The EID is the stable handle around which that evidence can be assembled. It is not a substitute for the evidence.

Sources