RFC 9299

An Architectural Introduction to the Locator/ID Separation Protocol (LISP)

📅 published October 2022, from ietf

Internet Engineering Task Force (IETF) 💖

Okay bestie, let's get into it! ✨ This is RFC 9299, and it's an Informational doc (not a Standards Track spec, so it's not telling anyone what to build, it's here to explain things) 🎀. It's written by A. Cabellos from Universitat Politecnica de Catalunya and D. Saucez, Ed. from Inria 🌸. It was published in October 2022 🦋.

The ISSN is 2070-1721 💅. Let me be clear here: this document doesn't obsolete or update any other RFCs, so it's just its own little vibe 🧚.

An Architectural Introduction to the Locator/ID Separation Protocol (LISP) 🌈

Abstract ✨

Okay so this doc describes the architecture of the Locator/ID Separation Protocol (LISP) 💜. It's basically here to make the rest of the LISP specs easier to read and to give everyone a starting point for talking about the details 🫶. It's meant for introductory purposes, so if you want the real nitty-gritty, go check out RFC 9300 and RFC 9301 📚.

Status of This Memo 🌸

Not an Internet Standards Track spec, it's published just for info 💅. It's a product of the IETF and represents the consensus of the IETF community 🔥. It got public review and was approved by the IESG (Internet Engineering Steering Group) ✨. Also, not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 if you're curious about that 🙈.

For the current status, errata, and how to give feedback, head to https://www.rfc-editor.org/info/rfc9299 🦋.

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved 💖.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the date of publication 📜. Please review those docs carefully, bestie, because they explain your rights and restrictions 🫶. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Revised BSD License 💅.

Table of Contents 🌈

1.  Introduction
2.  Definitions of Terms
3.  LISP Architecture
  3.1.  Design Principles
  3.2.  Overview of the Architecture
  3.3.  Data Plane
    3.3.1.  LISP Encapsulation
    3.3.2.  LISP Forwarding State
  3.4.  Control Plane
    3.4.1.  LISP Mappings
    3.4.2.  Mapping System Interface
    3.4.3.  Mapping System
  3.5.  Internetworking Mechanisms
4.  LISP Operational Mechanisms
  4.1.  Cache Management
  4.2.  RLOC Reachability
  4.3.  ETR Synchronization
  4.4.  MTU Handling
5.  Mobility
6.  Multicast
7.  Use Cases
  7.1.  Traffic Engineering
  7.2.  LISP for IPv6 Co-existence
  7.3.  LISP for Virtual Private Networks
  7.4.  LISP for Virtual Machine Mobility in Data Centers
8.  Security Considerations
9.  IANA Considerations
10. References
  10.1.  Normative References
  10.2.  Informative References
Appendix A.  A Brief History of Location/Identity Separation
  A.1.  Old LISP Models
Acknowledgments
Authors' Addresses

1. Introduction 🧚

Okay so this doc introduces the Locator/ID Separation Protocol (LISP) architecture [RFC9300] [RFC9301], its main operational mechanisms, and its design rationale 💖. Basically, LISP is built on a super well-known architectural idea: decoupling the overloaded semantics of IP addresses ✨. As Noel Chiappa pointed out [RFC4984], IP addresses right now identify both the topological location of a network attachment point AND the node's identity 💀. But nodes and routing have totally different needs 🙈. Routing systems need addresses that are aggregatable and have topological meaning, while nodes need to be identified independently of where they currently are [RFC4984] 🫶.

LISP creates two separate namespaces, Endpoint Identifiers (EIDs) and Routing Locators (RLOCs) 🌸. Both look exactly like the current IPv4 and IPv6 addresses, syntactically speaking 💅. The difference is the vibe: EIDs uniquely identify nodes no matter where they are topologically, and they're typically routed intra-domain 🦋. RLOCs are assigned topologically to network attachment points, and they're typically routed inter-domain 🌈. So with LISP, the edge of the Internet (where the nodes are connected) and the core (where inter-domain routing happens) can be logically separated 👑. LISP-capable routers are the ones interconnecting the two logical spaces ✨. LISP also brings in a database called the Mapping System, which stores and retrieves mappings between identity and location 💜. And LISP-capable routers send packets across the Internet core by encapsulating them to the appropriate location 🎀.

In summary, bestie:

  • RLOCs have meaning only in the underlay network, that is, the underlying core routing system. 🌸
  • EIDs have meaning only in the overlay network, which is the encapsulation relationship between LISP-capable routers. 🦋
  • The LISP edge maps EIDs to RLOCs. 💖
  • Within the underlay network, RLOCs have both Locator and identifier semantics. 🧚
  • An EID within a LISP site carries both identifier and Locator semantics to other nodes within that site. ✨
  • An EID within a LISP site carries identifier and limited Locator semantics to nodes at other LISP sites (i.e., enough Locator information to tell that the EID is external to the site). 🫶

The relationship described above is not unique to LISP, and it's super common across other overlay technologies 🌈.

The original motivation behind LISP is the routing scalability problem [RFC4984]. The idea is that if LISP were fully deployed, the Internet core would be populated with RLOCs, while Traffic Engineering (TE) mechanisms get pushed to the Mapping System 👑. In that world, RLOCs are quasi-static (i.e., low churn), which makes the routing system scalable [Quoitin], while EIDs can roam anywhere with no churn to the underlying global routing system 💅. [RFC7215] discusses the impact of LISP on the global routing system during the transition period 🔥. But the separation between location and identity that LISP offers also makes it suitable for other scenarios, like TE, multihoming, and mobility, among others ✨.

This document describes the LISP architecture, its main operational mechanisms, and its design rationale 💜. It's important to note that this document does not specify or complement LISP 🙈. If you want the protocol specs, go to the main LISP specifications ([RFC9300] and [RFC9301]), plus the complementary docs ([RFC6831], [RFC6832], [RFC9302], [RFC6835], [RFC6836], and [RFC7052]) and the LISP deployment guidelines in [RFC7215] 🎀.

2. Definitions of Terms 🌸

Endpoint Identifier (EID): Addresses used to uniquely identify nodes irrespective of their topological location. Typically routed intra-domain. 🦋

Routing Locator (RLOC): Addresses assigned topologically to network attachment points. Typically routed inter-domain. 🌈

Ingress Tunnel Router (ITR): A LISP-capable router that encapsulates packets from a LISP site towards the core network. 👑

Egress Tunnel Router (ETR): A LISP-capable router that decapsulates packets from the core of the network towards a LISP site. ✨

xTR: A router that implements both ITR and ETR functionalities. 💜

Map-Request: A LISP signaling message used to request an EID-to-RLOC mapping. 🎀

Map-Reply: A LISP signaling message sent in response to a Map-Request that contains a resolved EID-to-RLOC mapping. 🌸

Map-Register: A LISP signaling message used to register an EID-to-RLOC mapping. 🦋

Map-Notify: A LISP signaling message sent in response to a Map-Register to acknowledge the correct reception of an EID-to-RLOC mapping. 🫶

This document describes the LISP architecture and does not introduce any new terms 💅. For the full definitions, go read [RFC9300], [RFC9301], [RFC6831], [RFC6832], [RFC9302], [RFC6835], [RFC6836], [RFC7052], and [RFC7215] 📚.

3. LISP Architecture 👑

This section presents the LISP architecture 💖. It starts with the design principles, then covers the main aspects: the data plane, the control plane, and the internetworking mechanisms 🧚.

3.1. Design Principles ✨

The LISP architecture is built on top of four basic design principles 🌈:

Locator/Identifier split: Decoupling the overloaded semantics of current IP addresses lets devices have identity-based addresses that are separate from topologically meaningful addresses 🦋. By exposing only the topologically meaningful addresses to the Internet core, those addresses can be aggregated for substantial scaling 💅. Individual devices get identity-based addresses that are not used for forwarding in the Internet core 🫶.

Overlay architecture: This architecture overlays packet routing on top of the current Internet, so new protocols can be deployed without changing the current infrastructure 🔥. That means a low deployment cost, which is iconic 💜.

Decoupled data plane and control plane: Separating the data plane from the control plane lets them scale independently and use different architectural approaches 🌸. This matters because they usually have different requirements, and it allows other data planes to be added later 🎀. Even though they're decoupled, they're not completely isolated, because the LISP data plane may trigger control plane activity 🙈.

Incremental deployability: This principle makes sure the protocol interoperates with the legacy Internet while still giving early adopters some of the targeted benefits 👑✨.

Part 1 of 6 is done, bestie! 🌈 Say the word and I'll pick up with Section 3.2 next 💖.

3.2. Overview of the Architecture

Okay bestie, so LISP splits the core from the edge by making two separate namespaces 🦋: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). The edge is made of LISP sites (like an Autonomous System) that use EID addresses. EIDs are IPv4 or IPv6 addresses that uniquely identify communication end hosts, and they get assigned and configured by the same mechanisms that exist at the time of this writing ✨. EIDs don't carry inter-domain topological information, so they're usually routable at the edge (inside LISP sites) but not in the core 💅. For how LISP sites hang out with non-LISP sites and domains on the Internet, check out Section 3.5 🧚.

LISP sites (at the edge) connect to the core of the Internet through LISP-capable routers (e.g., border routers) 🌸. The sites talk across the core using tunnels between those LISP-capable routers. When packets from a LISP site head towards the core network, they ingress into an encapsulated tunnel via an Ingress Tunnel Router (ITR) 🚀. When packets flow from the core into a LISP site, they egress from an encapsulated tunnel at an Egress Tunnel Router (ETR) 💖. An xTR is a router that can do both ITR and ETR operations, and ITRs encapsulate packets while ETRs decapsulate them. So basically LISP is an overlay sitting on top of the current Internet core, and it's giving layers 🍓.

                          /-----------------\                 ---
                          |     Mapping     |                  |
                          .     System      |                  | Control
                         -|                 |`,                | Plane
                       ,' \-----------------/  .               |
                      /                         |             ---
      ,..,           -        _,....,,          |      ,..,    |
    /     `        ,'      ,-`        `',       |    /     `   |
   /        \ +-----+   ,'              `,  +-----+ /        \ |
   |  EID   |-| xTR |--/        RLOC     ,--| xTR |-|  EID   | | Data
   | Space  |-|     |--|       Space     |--|     |-| Space  | | Plane
   \        / +-----+  .                 /  +-----+ \        / |
    `.    .'            `.              ,'           `.    .'  |
      `'-`                `.,        ,.'               `'-`   ---
                             ``'''``
     LISP Site (Edge)            Core              LISP Site (Edge)

Figure 1: A Schema of the LISP Architecture 🎀

With LISP, the core uses RLOCs. An RLOC is an IPv4 or IPv6 address assigned to a core-facing network interface of an ITR or ETR 🌈.

Now, the Mapping System is a database that's typically distributed, and it stores mappings between EIDs and RLOCs 🗺️. These mappings connect the identity of devices attached to LISP sites (the EIDs) to the set of RLOCs configured at the LISP-capable routers serving that site. The mappings also include TE policies, and they can be configured to achieve multihoming and load balancing 👑. The LISP Mapping System is conceptually similar to the DNS, since it's organized as a distributed, multi-organization network database. With LISP, ETRs register mappings and ITRs retrieve them 🫶.

Last but not least, the LISP architecture puts a big emphasis on incremental deployment 🦋. Because LISP is an overlay on the current Internet architecture, end hosts, as well as intra-domain and inter-domain routers, stay unchanged 😭. The only required changes to the existing infrastructure are to the routers connecting the EID space with the RLOC space. LISP also requires deploying an independent Mapping System, and that distributed database is a brand-new network entity 💅.

Here's a simplified packet flow between two nodes attached to LISP sites. Heads up that typical LISP-capable routers are xTRs (both ITR and ETR) 🙈. Client HostA wants to send a packet to server HostB 💌.

                            /----------------\
                            |     Mapping    |
                            |     System     |
                           .|                |-
                          ` \----------------/ `.
                        ,`                       \
                       /                          `.
                     ,'         _,..-..,,           ',
                    /         -`         `-,          \
                  .'        ,'              \          `,
                  `        '                 \           '
              +-----+     |                   | RLOC_B1+-----+
       HostA  |     |    |        RLOC         |-------|     |  HostB
       EID_A--|ITR_A|----|        Space        |       |ETR_B|--EID_B
              |     | RLOC_A1                  |-------|     |
              +-----+     |                   | RLOC_B2+-----+
                           ,                 /
                            \               /
                             `',         ,-`
                                ``''-''``

Figure 2: Packet Flow Sequence in LISP ✨

  1. HostA retrieves the EID_B of HostB, typically by querying the DNS and getting back an A or AAAA record 🔍. Then it generates an IP packet just like on the Internet. The packet has source address EID_A and destination address EID_B.
  2. The packet gets forwarded towards ITR_A in the LISP site using standard intra-domain mechanisms 🛣️.
  3. ITR_A, upon receiving the packet, queries the Mapping System to retrieve the Locator of ETR_B that is serving HostB's EID_B 🔎. To do that, it uses a LISP control message called Map-Request, which contains EID_B as the lookup key. In return, it receives another LISP control message called Map-Reply. That message contains two Locators, RLOC_B1 and RLOC_B2, and it also contains TE policies: priority and weight per Locator 🎯. A Map-Reply can contain more Locators if needed 🌟. ITR_A can cache the mapping in local storage to speed up forwarding of subsequent packets ⚡.
  4. ITR_A encapsulates the packet towards RLOC_B1, chosen according to the priorities/weights specified in the mapping 🎁. The packet now has two IP headers. The outer header has RLOC_A1 as source and RLOC_B1 as destination. The inner original header has EID_A as source and EID_B as destination. ITR_A also adds a LISP header 🧁. More details about LISP encapsulation are in Section 3.3.1.
  5. The encapsulated packet gets forwarded over the interconnecting core as a normal IP packet, which makes the EID invisible from the core 🫥.
  6. When ETR_B receives the encapsulated packet, it decapsulates the packet and forwards it to HostB 🥳.

3.3. Data Plane

This section gives a high-level description of the LISP data plane, which is specified in detail in [RFC9300] 📖. The LISP data plane is responsible for encapsulating and decapsulating data packets and caching the right forwarding state 🧠. It has two main entities, the ITR and the ETR. Both are LISP-capable routers, and they connect the EID space with the RLOC space (ITR) and vice versa (ETR) 🔁.

3.3.1. LISP Encapsulation

ITRs encapsulate data packets towards ETRs 📦. LISP data packets are encapsulated using UDP (port 4341) 🦋. The ITR usually picks the source port using a 5-tuple hash of the inner header, so that it stays consistent in case of multipath solutions such as ECMP [RFC2992], and the source port is ignored on reception 🌈. LISP data packets are often encapsulated in UDP packets that include a zero checksum [RFC6935] [RFC6936], which may not be verified when received, because LISP data packets typically include an inner transport protocol header with a non-zero checksum 🤷‍♀️. The use of UDP zero checksums over IPv6 for all tunneling protocols like LISP is subject to the applicability statement in [RFC6936] 📜. If LISP data packets are encapsulated in UDP packets with non-zero checksums, the outer UDP checksums get verified when the UDP packets are received, as part of normal UDP processing ✅.

LISP-encapsulated packets also include a LISP header, placed after the UDP header and before the original IP header 🎀. The LISP header is prepended by ITRs and stripped by ETRs. It carries reachability information (see more details in Section 4.2) and the 'Instance ID' field. The 'Instance ID' field is used to tell apart traffic to and from different tenant address spaces at the LISP site, and this use of the Instance ID may use overlapped but logically separated EID addressing 👯.

Overall, LISP works on 4 headers: the inner header the source constructed, plus the 3 headers a LISP encapsulator prepends, listed from "outer" to "inner" 🧅.

  1. Outer IP header containing RLOCs as source and destination addresses. This header is originated by ITRs and stripped by ETRs.
  2. UDP header (port 4341), usually with a zero checksum. This header is originated by ITRs and stripped by ETRs.
  3. LISP header that contains various forwarding-plane features (such as reachability) and an 'Instance ID' field. This header is originated by ITRs and stripped by ETRs.
  4. Inner IP header containing EIDs as source and destination addresses. This header is created by the source end host and is left unchanged by the LISP data plane processing on the ITR and ETR 💅.

Finally, in some scenarios, re-encapsulating and/or recursive tunnels are useful for choosing a specified path in the underlay network, for instance to avoid congestion or failure 🛤️. Re-encapsulating tunnels are consecutive LISP tunnels, and they happen when a decapsulator (an ETR action) removes a LISP header and then acts as an encapsulator (an ITR action) to prepend another one 🔗. Recursive tunnels, on the other hand, are nested tunnels, and they're implemented by using multiple LISP encapsulations on a packet 🪆. These functions are implemented by Re-encapsulating Tunnel Routers (RTRs). An RTR can be thought of as a router that first acts as an ETR by decapsulating packets, and then acts as an ITR by encapsulating them towards another Locator. More information can be found in [RFC9300] and [RFC9301] 💜.

3.3.2. LISP Forwarding State

In the LISP architecture, ITRs keep just enough information to route the traffic flowing through them 🧘‍♀️. In other words, ITRs only need to retrieve from the LISP Mapping System the mappings between EID-Prefixes (blocks of EIDs) and the RLOCs used to encapsulate packets. Those mappings get stored in a local cache called the LISP Map-Cache, for subsequent packets addressed to the same EID-Prefix 🗃️. Heads up: with overlapping EID-Prefixes, after a request the ITR may receive a set of mappings covering the requested EID-Prefix and all more-specific EID-Prefixes (cf., Section 5.5 of [RFC9301]) 🙈. Mappings include a Time to Live (TTL), which is set by the ETR ⏳. More details about the Map-Cache management can be found in Section 4.1 🌸.

3.4. Control Plane

The LISP control plane, specified in [RFC9301], provides a standard interface to register and request mappings 🎀. The LISP Mapping System is the database that stores those mappings. The following sub-sections first describe the mappings, then the standard interface to the Mapping System, and finally its architecture 🧚.

3.4.1. LISP Mappings

Okay so, a mapping is basically the bestie-list that ties EID-Prefix(es) to a set of RLOCs, and it also carries the TE policies 💅 Those are priorities and weights for the RLOCs. Priorities let the ETR set up active/backup vibes 🎀, and weights load-balance traffic among the RLOCs on a per-flow basis ✨.

Typical mappings bind EIDs in the form of IP prefixes with a set of RLOCs, which are also IP addresses 🦋. IPv4 and IPv6 addresses get encoded using the right Address Family Identifier (AFI) [RFC8060]. BUT LISP can also do more general address encoding through the ongoing effort around the LISP Canonical Address Format (LCAF) [RFC8060] 😭🫶

Because the syntax for address encoding is this general, LISP is giving flexibility for current and future applications 🌈. For example, LCAFs could support Media Access Control (MAC) addresses, geocoordinates, ASCII names, and application-specific data 🍓. Iconic, periodt.

3.4.2. Mapping System Interface

LISP defines a standard interface between the data and control planes 🔥. The interface is specified in [RFC9301] and it defines two entities:

Map-Server: A network infrastructure component that learns mappings from ETRs and publishes them into the LISP Mapping System 💜. Typically, Map-Servers are not authoritative to reply to queries, so they forward them to the ETR 🙈. They can also operate in proxy-mode, where the ETRs delegate replying to queries to Map-Servers 🧚. This setup is useful when the ETR has limited resources (e.g., CPU or power) 🔋.

Map-Resolver: A network infrastructure component that interfaces ITRs with the Mapping System by proxying queries and, in some cases, responses 🌸.

The interface defines four LISP control messages that are sent as UDP datagrams (port 4342) 👑:

Map-Register: This message is used by ETRs to register mappings in the Mapping System, and it is authenticated using a shared key between the ETR and the Map-Server 🔐.

Map-Notify: When requested by the ETR, this message is sent by the Map-Server in response to a Map-Register to acknowledge the correct reception of the mapping and convey the latest Map-Server state on the EID-to-RLOC mapping ✨. In some cases, a Map-Notify can be sent to the previous RLOCs when an EID is registered by a new set of RLOCs 🦋.

Map-Request: This message is used by ITRs or Map-Resolvers to resolve the mapping of a given EID 💖.

Map-Reply: This message is sent by Map-Servers or ETRs in response to a Map-Request and contains the resolved mapping 🎀. Please note that a Map-Reply may contain a negative reply if, for example, the queried EID is not part of the LISP EID space. In such cases, the ITR typically forwards the traffic as is (non-encapsulated) to the public Internet 🌍. This behavior is defined to support incremental deployment of LISP 🌱.

3.4.3. Mapping System

LISP architecturally decouples control and data planes by means of a standard interface 💅. This interface glues the data plane (routers responsible for forwarding data packets) together with the LISP Mapping System (a database responsible for storing mappings) 🫶.

With this separation in place, the data and control planes can use different architectures if needed and scale independently ✨. Typically, the data plane is optimized to route packets according to hierarchical IP addresses. However, the control plane may have different requirements. For instance, by taking advantage of the LCAFs, the Mapping System may be used to store nonhierarchical keys (such as MAC addresses), which requires different architectural approaches for scalability 🧠. Another important difference between the LISP control and data planes is that, as a result of the local mapping cache available at the ITR, the Mapping System does not need to operate at line-rate 🏎️.

Many of the existing mechanisms to create distributed systems have been explored and considered for the Mapping System architecture 🌈: graph-based databases in the form of LISP Alternative Logical Topology (LISP-ALT) [RFC6836], hierarchical databases in the form of the LISP Delegated Database Tree (LISP-DDT) [RFC8111], monolithic databases in the form of the LISP Not-so-novel EID-to-RLOC Database (LISP-NERD) [RFC6837], flat databases in the form of the LISP Distributed Hash Table (LISP-DHT) [LISP-SHDHT] [Mathy], and a multicast-based database [LISP-EMACS]. Furthermore, it is worth noting that, in some scenarios, such as private deployments, the Mapping System can operate as logically centralized. In such cases, it is typically composed of a single Map-Server/Map-Resolver 🧚.

The following sub-sections focus on the two Mapping Systems that have been implemented and deployed (LISP-ALT and LISP-DDT) 👀.

3.4.3.1. LISP-ALT

LISP-ALT [RFC6836] was the first Mapping System proposed, developed, and deployed on the LISP pilot network 🥇. It is based on a distributed BGP overlay in which Map-Servers and Map-Resolvers participate. The nodes connect to their peers through static tunnels. Each Map-Server involved in the ALT topology advertises the EID-Prefixes registered by the serviced ETRs, making the EID routable on the ALT topology 🗺️.

When an ITR needs a mapping, it sends a Map-Request to a Map-Resolver that, using the ALT topology, forwards the Map-Request towards the Map-Server responsible for the mapping. Upon reception, the Map-Server forwards the request to the ETR, which in turn replies directly to the ITR 📬.

3.4.3.2. LISP-DDT

LISP-DDT [RFC8111] is conceptually similar to the DNS, a hierarchical directory whose internal structure mirrors the hierarchical nature of the EID address space 🌳. The DDT hierarchy is composed of DDT nodes forming a tree structure; the leafs of the tree are Map-Servers. On top of the structure, there is the DDT root node, which is a particular instance of a DDT node, that matches the entire address space 👑. As in the case of DNS, DDT supports multiple redundant DDT nodes and/or DDT roots. Finally, Map-Resolvers are the clients of the DDT hierarchy and can query the DDT root and/or other DDT nodes 💁.

                           /---------\
                           |         |
                           | DDT Root|
                           |   /0    |
                         ,.\---------/-,
                     ,-'`       |       `'.,
                  -'`           |           `-
              /-------\     /-------\    /-------\
              |  DDT  |     |  DDT  |    |  DDT  |
              | Node  |     | Node  |    | Node  |  ...
              |  0/8  |     |  1/8  |    |  2/8  |
              \-------/     \-------/    \-------/
            _.                _.            . -..,,,_
          -`                -`              \        ````''--
   +------------+     +------------+   +------------+ +------------+
   | Map-Server |     | Map-Server |   | Map-Server | | Map-Server |
   | EID-Prefix1|     | EID-Prefix2|   | EID-Prefix3| | EID-Prefix4|
   +------------+     +------------+   +------------+ +------------+

Figure 3: A Schematic Representation of the DDT Tree Structure

Please note that the prefixes and the structure depicted in the figure above should only be considered as an example 🙏.

The DDT structure does not actually index EID-Prefixes; rather, it indexes Extended EID-Prefixes (XEID-Prefixes). An XEID-Prefix is just the concatenation of the following fields (from most significant bit to less significant bits): Database-ID, Instance ID, Address Family Identifier, and the actual EID-Prefix 🧩. The Database-ID is provided for possible future requirements of higher levels in the hierarchy and to enable the creation of multiple and separate database trees 🌲.

In order to resolve a query, LISP-DDT operates in a similar way to the DNS but only supports iterative lookups 🔍. DDT clients (usually Map-Resolvers) generate Map-Requests to the DDT root node. In response, they receive a newly introduced LISP control message: a Map-Referral. A Map-Referral provides the list of RLOCs of the set of DDT nodes matching a configured XEID delegation. That is, the information contained in the Map-Referral points to the child of the queried DDT node that has more specific information about the queried XEID-Prefix 👉. This process is repeated until the DDT client walks the tree structure (downwards) and discovers the Map-Server servicing the queried XEID. At this point, the client sends a Map-Request and receives a Map-Reply containing the mappings 🎯. It is important to note that DDT clients can also cache the information contained in Map-Referrals; that is, they cache the DDT structure. This is used to reduce the time required to retrieve mappings [Jakab] 🏃‍♀️.

The DDT Mapping System relies on manual configuration. That is, Map-Resolvers are configured with the set of available DDT root nodes, while DDT nodes are configured with the appropriate XEID delegations. Configuration changes in the DDT nodes are only required when the tree structure changes itself, but it doesn't depend on EID dynamics (RLOC allocation or TE policy changes) 🛠️.

3.5. Internetworking Mechanisms

EIDs are typically identical to either IPv4 or IPv6 addresses, and they are stored in the LISP Mapping System. However, they are usually not announced in the routing system beyond the local LISP domain 🌐. As a result, LISP requires an internetworking mechanism to allow LISP sites to speak with non-LISP sites and vice versa. LISP internetworking mechanisms are specified in [RFC6832] 🤝.

LISP defines two entities to provide internetworking:

Proxy Ingress Tunnel Router (PITR): PITRs provide connectivity from the legacy Internet to LISP sites. PITRs announce in the global routing system blocks of EID-Prefixes (aggregating when possible) to attract traffic. For each incoming packet from a source not in a LISP site (a non-EID), the PITR LISP-encapsulates it towards the RLOC(s) of the appropriate LISP site. The impact of PITRs on the routing table size of the Default-Free Zone (DFZ) is, in the worst case, similar to the case in which LISP is not deployed. EID-Prefixes will be aggregated as much as possible, both by the PITR and by the global routing system 📡.

Proxy Egress Tunnel Router (PETR): PETRs provide connectivity from LISP sites to the legacy Internet. In some scenarios, LISP sites may be unable to send encapsulated packets with a local EID address as a source to the legacy Internet, for instance, when Unicast Reverse Path Forwarding (uRPF) is used by Provider Edge routers or when an intermediate network between a LISP site and a non-LISP site does not support the desired version of IP (IPv4 or IPv6). In both cases, the PETR overcomes such limitations by encapsulating packets over the network. There is no specified provision for the distribution of PETR RLOC addresses to the ITRs 🤷‍♀️.

Additionally, LISP also defines mechanisms to operate with private EIDs [RFC1918] by means of LISP-NAT [RFC6832]. In this case, the xTR replaces a private EID source address with a routable one. At the time of this writing, work is ongoing to define NAT-traversal capabilities, that is, xTRs behind a NAT using non-routable RLOCs 🚧.

PITRs, PETRs, and LISP-NAT enable incremental deployment of LISP by providing significant flexibility in the placement of the boundaries between the LISP and non-LISP portions of the network and making it easy to change those boundaries over time 🦋✨.

4. LISP Operational Mechanisms ✨

okay bestie, this section is the tea on LISP's main operational mechanisms 💅 let's get into it 🫶

4.1. Cache Management 🧠

so LISP keeps the control plane and the data plane separate. mappings live in the control plane and the data plane uses them for forwarding, which is iconic, but it means ITRs need a local cache 💖 that cache cuts down on signaling overhead (Map-Request/Map-Reply) and makes forwarding faster ⚡ the local cache at the ITRs is called the Map-Cache, and the router uses it to LISP-encapsulate packets. the Map-Cache is indexed by (Instance ID, EID-Prefix) and basically holds the set of RLOCs with their TE policies (priorities and weights) 🎀

like any cache, the Map-Cache needs cache coherence so its info stays up to date. LISP defines three main mechanisms for that 👑

  • Record Time To Live (TTL): each mapping record has a TTL set by the ETR. once it expires, the ITR can't use the mapping until it gets refreshed by sending a new Map-Request ⏰
  • Solicit-Map-Request (SMR): SMR is an explicit way to update mapping info 🔔 an ETR can send a special type of Map-Request on demand to ask for a mapping to be refreshed. when an ITR gets an SMR, it must refresh the bindings by sending a Map-Request to the Mapping System. more on SMR uses is documented in [RFC9301] 📖
  • Map-Versioning: this optional mechanism piggybacks the version number of the mappings an xTR used onto the LISP header of data packets 🧳 so when an xTR gets a LISP-encapsulated packet from a remote xTR, it can check whether its own Map-Cache or the remote xTR's Map-Cache is outdated. if its own is outdated, it sends a Map-Request for the remote EID to get the newest mappings. if it finds that the remote xTR's Map-Cache is outdated, it sends an SMR to say a new mapping is available. more details are in [RFC9302] 🦋

finally, it's worth noting that in some cases an entry in the Map-Cache can be proactively refreshed using the mechanisms in the section below ✨

4.2. RLOC Reachability 📡

in most cases LISP works with a pull-based Mapping System (e.g., DDT) 🧚 that makes it an edge-to-edge pull architecture. the network state is stored in the control plane and the data plane pulls it on demand. this matters for how xTRs' reachability/liveness info gets spread around, since pull architectures need explicit mechanisms to propagate it 🥺 so LISP defines a set of mechanisms to tell ITRs and PITRs about the reachability of the cached RLOCs 💜

  • Locator-Status-Bits (LSBs): this one's passive 🤫 the LSB field rides in the LISP header of data packets, and ETRs can set it to show which RLOCs of the ETR site are up or down. ITRs can use that as a hint about reachability and do extra checks. heads up though, LSBs don't give path reachability status, they only hint at the status of RLOCs 🙈 so they must not be used over the public Internet, and they should be paired with Map-Versioning to stop race conditions where LSBs get read as referring to different RLOCs than intended.
  • Echo-Nonce: also passive, and it only works well when data flows both ways between two communicating xTRs 🔁 an ITR piggybacks a random number (called a nonce) in its LISP data packets. if the path and the probed Locator are up, the ETR piggybacks that same random number on the next data packet. if it doesn't, the ITR can mark the Locator as unreachable. when traffic is one-way, or when the ETR receiving the traffic isn't the same ITR that sends it back, extra mechanisms are needed. the Echo-Nonce mechanism must be used in trusted environments only, never over the public Internet 🔒
  • RLOC-Probing: this one's active 💪 ITRs send probes to specific Locators, which checks both the Locator and the path. it does this by sending a Map-Request (with certain flags turned on) over the data plane (RLOC space) and then waiting for a Map-Reply, which also goes over the data plane. because it's active, it's a really effective way to figure out reachability and, if something fails, switch to a different Locator. it also gives useful RTT estimates of the path's delay that other network algorithms can use 📊

RLOC-Probing and the Echo-Nonce can work together, and this is the moment they're a power couple 👯 if a nonce isn't echoed, an ITR can't tell which path direction failed. in that situation, an ITR can use RLOC-Probing.

LISP also recommends inferring the reachability of Locators from info the underlay gives you, specifically 🌐

  • ICMP signaling: the LISP underlay (aka the current Internet) uses ICMP to signal unreachability, among other things 📣 LISP can take advantage of that. getting an ICMP Network Unreachable or ICMP Host Unreachable message can be seen as a hint that a Locator might be unreachable, and that should lead to additional checks 🙃
  • Underlay routing: both BGP and IGP carry reachability info 🗺️ LISP-capable routers with access to underlay routing info can use it to figure out if a given Locator or path is reachable.

4.3. ETR Synchronization 🤝

all the ETRs that are authoritative for a particular EID-Prefix must announce the same mapping to requesters 📣 that means ETRs have to know the status of the RLOCs of the other ETRs. this is called ETR synchronization.

the tea is that, as of this writing, LISP doesn't specify a mechanism for ETR synchronization 😭 lots of well-known techniques could be applied, but it's still under research. so for now, operators have to rely on coherent manual configuration 🛠️

4.4. MTU Handling 📏

since LISP encapsulates packets, it has to deal with packets that exceed the MTU of the path between the ITR and the ETR 💀 LISP defines two mechanisms for this 👀

  • Stateless: with this one, the effective MTU is assumed from the ITR's perspective. if a payload packet is too big for the effective MTU and can be fragmented, it gets fragmented on the ITR, and reassembly happens at the destination host 🧩
  • Stateful: with this one, ITRs keep track of the MTU of the paths toward the destination Locators by parsing the ICMP Too Big packets that intermediate routers send 🕵️ ITRs will send ICMP Too Big messages to tell the sources about the effective MTU. ITRs can also use mechanisms like Path MTU Discovery (PMTUD) [RFC1191] or Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] to keep track of the MTU toward the Locators 📐

in both cases, if the packet can't be fragmented (IPv4 with DF=1 or IPv6), then the ITR drops it and replies to the source with an ICMP Too Big message 🚫

5. Mobility 🦋

the separation between Locators and identifiers in LISP is great for TE, since LISP sites can change their attachment points to the Internet (i.e., RLOCs) without affecting endpoints or the Internet core 🌸 in this setup, the border routers run the xTR functionality, and endpoints have no idea LISP exists 🙈 this works a lot like Network Mobility [RFC3963].

however, this mode doesn't allow seamless mobility of endpoints between different LISP sites, because the EID address might not be routable in a visited site 😬 LISP can still enable seamless IP mobility when it's implemented directly in the endpoint, or when the endpoint roams to an attached xTR. then each endpoint is an xTR, the EID address is the one shown to the network stack that applications use, and the RLOC is the address picked up from the network where it's visiting 🧳 this is similar to Mobile IP ([RFC5944] and [RFC6275]) 💫

whenever a device changes its RLOC, the xTR updates the RLOC in its local mapping and registers it with its Map-Server, usually with a low TTL value (1 min) ⏱️ to avoid needing a home gateway, the ITR also tells every remote device that has ongoing communications with the device that moved about the RLOC change 📨 using both methods keeps the system scalable, because signaling is strictly limited to the Map-Server and to hosts with ongoing communications 📈 in the mobility case, the EID-Prefix can be as small as a full /32 or /128 (IPv4 or IPv6, respectively), depending on the use case (e.g., subnet mobility vs. single VM/mobile node mobility) 🎯

the decoupled identity and location LISP provides also let it work with other Layer 2 and Layer 3 mobility solutions 🤩

6. Multicast 🦋

okay so LISP can also carry IP multicast packets that come from the EID space 💖 The operational changes the multicast protocols need are written up in [RFC6831] ✨

In these setups, LISP may create multicast state at the core and at the sites, both source and receiver sites 🌸 When signaling is used to build that state at the sites, LISP routers encapsulate PIM Join/Prune messages from receiver sites to source sites as unicast packets 💅 At the core, the ETRs build a brand new PIM Join/Prune message addressed to the RLOC of the ITR servicing the source 🫶 Here's the simplified version:

  1. An end host that wants to join a multicast channel sends an IGMP report 🙋‍♀️ Multicast PIM routers at the LISP site pass PIM Join/Prune messages for (S-EID, G) along toward the ETR 📬
  2. The Join message reaches the ETR, and the ETR makes two Join messages 😭 The first one is unicast LISP-encapsulated and carries the original Join toward the RLOC of the ITR servicing the source, which creates (S-EID, G) multicast state at the source site 🌷 The second Join has the RLOC of the ITR servicing the source as its destination address and creates (S-RLOC, G) multicast state at the core 🧚
  3. Multicast data from the source (S-EID, G) flows to the ITR, and the ITR LISP-encapsulates those packets 🍓 The outer header uses its own RLOC as the source (S-RLOC) and the original multicast group address G as the destination 💜 Please note that multicast group addresses are logical and are not resolved by the Mapping System, so that's not a lookup you'll see happen 🙈 The packets then travel through the core to the receiving ETRs, which decapsulate them and forward them using the receiver site's multicast state 🎀
Please note the inner and outer multicast addresses are generally different, unless the underlay provider has tight control over the overlay. That's the exception, not the rule 👀

LISP specifications already support all PIM modes [RFC6831] 💅 On top of that, LISP can also support non-PIM mechanisms to maintain multicast state 🌈

When multicast sources and receivers are active at LISP sites, but the core network between the sites doesn't provide multicast support, a signal-free mechanism can build an overlay so multicast traffic can flow between sites and connect the multicast trees at each site [RFC8378] 🦋 Registrations from the receiver sites get merged in the Mapping System to put together a multicast replication list that includes every RLOC leading to receivers for a given multicast group or multicast channel 🫶 Each specific multicast entry's replication list is kept as a database mapping entry in the LISP Mapping System 📚

7. Use Cases 💅

7.1. Traffic Engineering 🛣️

A LISP site can strictly control which ETRs the traffic must enter the LISP site network through, even though the path to reach the ETR isn't under the site's control 👑 This fine-grained control is done with the mappings 🎯 When a remote site wants to send traffic to a LISP site, it gets the mapping for the destination EID from the Mapping System 💌 The mapping comes straight from an authoritative ETR of the EID and isn't changed by any intermediate network 🔒

A mapping ties a list of RLOCs to an EID-Prefix 💖 Each RLOC corresponds to an interface of an ETR (or a set of ETRs) that can correctly forward packets to EIDs in that prefix 🧠 Every RLOC gets a priority and a weight in the mapping ✨ The priority says which RLOCs should be preferred for sending packets, and the least preferred ones are there for backup 🛟 The weight lets you balance load between RLOCs with the same priority, in proportion to the weight value ⚖️

Since mappings come directly from the authoritative ETR and don't get altered on the way to the remote site, this gives really flexible incoming inter-domain TE 🔥 It even means a site can run a different mapping policy for each remote site 🥹

7.2. LISP for IPv6 Co-existence 🌐

LISP encapsulations let you carry packets using EIDs from one address family (e.g., IPv6) on top of packets from other address families (e.g., IPv4) 🧚 The RLOCs and EIDs don't have to match up in address family, which makes LISP a great candidate for deploying IPv6 even when the core network doesn't have IPv6 enabled everywhere 🌸

For example, two IPv6-only data centers could be connected over the legacy IPv4 Internet 💻 If their border routers are LISP capable, sending packets between the data centers needs no translation at all 🙌 The original IPv6 packets (in the EID space) get LISP encapsulated and carried over the IPv4 legacy Internet via IPv4 RLOCs 🦋

7.3. LISP for Virtual Private Networks 🔐

Lots of teams run several virtual networks over the same physical infrastructure 🏢 In these virtual private networks, figuring out which virtual network a packet belongs to is essential, and tags or labels are used for that 🏷️ With LISP, the distinction is made with the Instance ID field 💜 When an ITR encapsulates a packet from a particular virtual network (e.g., known via Virtual Routing and Forwarding (VRF) or the VLAN), it tags the encapsulated packet with the Instance ID for that virtual network 🎀 When an ETR receives a packet tagged with an Instance ID, it uses that ID to decide how to treat the packet 🧐

The main use of LISP for virtual private networks doesn't add any extra requirements on the underlying network, as long as it runs IP 🫶

7.4. LISP for Virtual Machine Mobility in Data Centers 🖥️

One way to get seamless virtual machine (VM) mobility in a data center is to treat the data center backbone as the RLOC space, and the subnets where servers are hosted as the EID space 🌈 A LISP router sits at the border between the backbone and each subnet 🧱 When a VM moves to another subnet, it can (temporarily) keep the address it had before the move, so it carries on without a transport-layer connection reset 😌 When an xTR detects a source address received on a subnet that isn't assigned to that subnet, it registers the address with the Mapping System 📝

To tell the other LISP routers that the machine moved and where it went, and to avoid detours through the initial subnetwork, mechanisms such as the Solicit-Map-Request messages are used 🏃‍♀️💨

8. Security Considerations 🚨

This section is about the security considerations for LISP, and y'all, these are serious 🥺

In a push Mapping System, the state needed to forward packets is learned independently of the traffic itself 📦 With a pull architecture, though, the system becomes reactive, and data plane events (e.g., the arrival of a packet with an unknown destination address) may trigger control plane events ⚡ This on-demand learning of mappings has lots of advantages, as discussed above, but it may also affect the way security gets enforced 🫣

The data plane is usually implemented in the fast path of routers for high-performance forwarding, while control plane features are implemented in the slow path for high flexibility 🐢 There can be a performance gap of several orders of magnitude between the slow and fast paths 😳 So the way data plane events get sent to the control plane must be considered carefully, so the slow path doesn't get overloaded, and rate limiting should be used as specified in [RFC9300] and [RFC9301] 🚦

Care must also be taken not to overload the Mapping System (i.e., the control plane infrastructure), because the operations it performs may be more complex than what happens on the data plane 🧩 For that reason, [RFC9300] and [RFC9301] recommend rate limiting the sending of messages to the Mapping System 🛑

To improve resiliency and cut down the total number of messages exchanged, LISP makes it possible to leak certain information, such as the reachability of Locators, straight into data plane packets 🫧 In environments that aren't fully trusted, like the open Internet, control information gleaned from data plane packets must not be used, or must be verified before it's used 🕵️‍♀️

Mappings are the centerpiece of LISP, so all precautions must be taken to stop malicious entities from manipulating or misusing them 🚫 Using trustable Map-Servers that strictly respect [RFC9301], along with the authentication mechanism proposed by LISP-SEC [RFC9303], reduces the risk of attacks on mapping integrity 🔐 In more critical environments, extra-secure measures may be needed 🛡️ How security gets implemented for a given Mapping System depends heavily on that Mapping System's architecture and the threat model assumed for the deployment 🧠 So Mapping System security has to be discussed in the relevant documents that propose the Mapping System architecture 📖

As with any other tunneling mechanism, middleboxes on the path between an ITR (or PITR) and an ETR (or PETR) must implement mechanisms to strip the LISP encapsulation, so they can correctly inspect the content of LISP-encapsulated packets 🔍

Like other map-and-encap mechanisms, LISP enables triangular routing, meaning packets of a flow can cross different border routers depending on their direction 🔄 So intermediate boxes may have an incomplete view of the traffic they inspect or manipulate 🫠 On top of that, LISP-encapsulated packets are routed based on the outer IP address (i.e., the RLOC), and they can be delivered to an ETR that isn't responsible for the packet's destination EID, or even to a network element that isn't an ETR at all 😱 The mitigation is to apply appropriate filtering on the network elements that could potentially receive unexpected LISP-encapsulated packets 🧱

More details about the security implications of LISP are discussed in [RFC7835] 📚

9. IANA Considerations 🌷

This document has no IANA actions 🫶

10. References 📑

10.1. Normative References 📚

Okay so these are the must-read ones, bestie. The spec literally leans on every single one of them 🫶

10.2. Informative References 💡

These ones are the extra reading. Totally worth it if you're obsessed like me 🤓

  • [Jakab] Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D., and O. Bonaventure, "LISP-TREE: A DNS Hierarchy to Support the LISP Mapping System", IEEE Journal on Selected Areas in Communications, vol. 28, no. 8, pp. 1332-1343, DOI 10.1109/JSAC.2010.101011, October 2010, <https://ieeexplore.ieee.org/document/5586446>.
  • [LISP-EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID Mappings Multicast Across Cooperating Systems for LISP", Work in Progress, Internet-Draft, draft-curran-lisp-emacs-00, 9 November 2007, <https://www.ietf.org/archive/id/draft-curran-lisp-emacs-00.txt>.
  • [LISP-SHDHT] Cheng, L. and M. Sun, "LISP Single-Hop DHT Mapping Overlay", Work in Progress, Internet-Draft, draft-cheng-lisp-shdht-04, 15 July 2013, <https://www.ietf.org/archive/id/draft-cheng-lisp-shdht-04.txt>.
  • [Mathy] Mathy, L. and L. Iannone, "LISP-DHT: Towards a DHT to map identifiers onto locators", CoNEXT '08: Proceedings of the 2008 ACM CoNEXT Conference, ReArch '08 - Re-Architecting the Internet, DOI 10.1145/1544012.1544073, December 2008, <https://dl.acm.org/doi/10.1145/1544012.1544073>.
  • [Quoitin] Quoitin, B., Iannone, L., de Launois, C., and O. Bonaventure, "Evaluating the Benefits of the Locator/Identifier Separation", Proceedings of 2nd ACM/IEEE International Workshop on Mobility in the Evolving Internet Architecture, DOI 10.1145/1366919.1366926, August 2007, <https://dl.acm.org/doi/10.1145/1366919.1366926>.

Appendix A. A Brief History of Location/Identity Separation 🌈

So here's the tea ☕ The LISP architecture for separating location and identity came out of the discussions on this topic at the Amsterdam IAB Routing and Addressing Workshop, which happened in October 2006 [RFC4984].

Right after that workshop, a small group of like-minded people spontaneously formed to work on an idea that popped up from informal chats at the workshop and on various mailing lists. The first Internet-Draft on LISP showed up in January 2007.

Trial implementations kicked off right then, and initial trial deployments have been running since June 2007. The early experience has been fed back into the design in a continuous, ongoing process across several years. At this point LISP is a moderately mature system, after a long, organic series of changes and updates 🌸

LISP went from an IRTF activity to an IETF WG in March 2009. After lots of revisions, the basic specifications became RFCs at the start of 2013. The work to expand, improve, and find new uses for it keeps going (and it undoubtedly will for a long time to come) 🚀 The LISP WG was rechartered in 2018 to keep working on the LISP base protocol and to produce Standards Track documents.

A.1. Old LISP Models 🕰️

LISP, as it was first imagined, had a bunch of potential operating modes, called "models". They aren't used anymore, but you'll occasionally see them mentioned, so here's a quick rundown 👀

  • LISP 1: EIDs all show up in the normal routing and forwarding tables of the network (so they're "routable"). This property was used to load EID-to-RLOC mappings through bootstrapping operations. Packets were sent with the EID as the destination in the outer wrapper. When an ETR saw such a packet, it sent a Map-Reply to the source ITR, giving the full mapping.
  • LISP 1.5: LISP 1.5 is similar to LISP 1, but the routability of EIDs happens on a separate network.
  • LISP 2: EIDs are not routable, and EID-to-RLOC mappings are available from the DNS.
  • LISP 3: EIDs are not routable and have to be looked up in a new EID-to-RLOC mapping database (in the initial concept, a system using Distributed Hash Tables). Two variants were possible: a "push" system, where all mappings were distributed to all ITRs, and a "pull" system, where ITRs load the mappings when they need them.

Acknowledgments 🫶

This document was started by Noel Chiappa, and a lot of the core philosophy came from him. The authors really appreciate his important contributions to this work and want to thank him for his past efforts 💖

The authors would also like to thank Dino Farinacci, Fabio Maino, Luigi Iannone, Sharon Barkai, Isidoros Kouvelas, Christian Cassar, Florin Coras, Marc Binderberger, Alberto Rodriguez-Natal, Ronald Bonica, Chad Hintz, Robert Raszuk, Joel M. Halpern, Darrel Lewis, and David Black. Thank you all, you're iconic 👑✨

Authors' Addresses 📮

Albert Cabellos
Universitat Politecnica de Catalunya
c/ Jordi Girona s/n
08034 Barcelona
Spain
Email: acabello@ac.upc.edu


Damien Saucez (editor)
Inria
2004 route des Lucioles - BP 93
Sophia Antipolis
France
Email: damien.saucez@inria.fr
📦 where this page comes from