rfc9299.original   rfc9299.txt 
Network Working Group A. Cabellos Internet Engineering Task Force (IETF) A. Cabellos
Internet-Draft UPC-BarcelonaTech Request for Comments: 9299 Universitat Politecnica de Catalunya
Intended status: Informational D. Saucez (Ed.) Category: Informational D. Saucez, Ed.
Expires: October 4, 2015 INRIA ISSN: 2070-1721 Inria
April 02, 2015 October 2022
An Architectural Introduction to the Locator/ID Separation Protocol An Architectural Introduction to the Locator/ID Separation Protocol
(LISP) (LISP)
draft-ietf-lisp-introduction-13.txt
Abstract Abstract
This document describes the architecture of the Locator/ID Separation This document describes the architecture of the Locator/ID Separation
Protocol (LISP), making it easier to read the rest of the LISP Protocol (LISP), making it easier to read the rest of the LISP
specifications and providing a basis for discussion about the details specifications and providing a basis for discussion about the details
of the LISP protocols. This document is used for introductory of the LISP protocols. This document is used for introductory
purposes, more details can be found in RFC6830, the protocol purposes; more details can be found in the protocol specifications,
specification. RFCs 9300 and 9301.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on October 4, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9299.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Revised BSD License text as described in Section 4.e of the
the Trust Legal Provisions and are provided without warranty as Trust Legal Provisions and are provided without warranty as described
described in the Simplified BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions of Terms
3. LISP Architecture . . . . . . . . . . . . . . . . . . . . . . 5 3. LISP Architecture
3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 5 3.1. Design Principles
3.2. Overview of the Architecture . . . . . . . . . . . . . . 5 3.2. Overview of the Architecture
3.3. Data-Plane . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Data Plane
3.3.1. LISP Encapsulation . . . . . . . . . . . . . . . . . 8 3.3.1. LISP Encapsulation
3.3.2. LISP Forwarding State . . . . . . . . . . . . . . . . 10 3.3.2. LISP Forwarding State
3.4. Control-Plane . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Control Plane
3.4.1. LISP Mappings . . . . . . . . . . . . . . . . . . . . 10 3.4.1. LISP Mappings
3.4.2. Mapping System Interface . . . . . . . . . . . . . . 11 3.4.2. Mapping System Interface
3.4.3. Mapping System . . . . . . . . . . . . . . . . . . . 11 3.4.3. Mapping System
3.5. Internetworking Mechanisms . . . . . . . . . . . . . . . 14 3.5. Internetworking Mechanisms
4. LISP Operational Mechanisms . . . . . . . . . . . . . . . . . 15 4. LISP Operational Mechanisms
4.1. Cache Management . . . . . . . . . . . . . . . . . . . . 15 4.1. Cache Management
4.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 16 4.2. RLOC Reachability
4.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 17 4.3. ETR Synchronization
4.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 17 4.4. MTU Handling
5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. Mobility
6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Multicast
7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. Use Cases
7.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 19 7.1. Traffic Engineering
7.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 20 7.2. LISP for IPv6 Co-existence
7.3. LISP for Virtual Private Networks . . . . . . . . . . . . 20 7.3. LISP for Virtual Private Networks
7.4. LISP for Virtual Machine Mobility in Data Centers . . . . 21 7.4. LISP for Virtual Machine Mobility in Data Centers
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 10. References
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References
11.1. Normative References . . . . . . . . . . . . . . . . . . 23 10.2. Informative References
11.2. Informative References . . . . . . . . . . . . . . . . . 25 Appendix A. A Brief History of Location/Identity Separation
Appendix A. A Brief History of Location/Identity Separation . . 25 A.1. Old LISP Models
A.1. Old LISP Models . . . . . . . . . . . . . . . . . . . . . 26 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses
1. Introduction 1. Introduction
This document introduces the Locator/ID Separation Protocol (LISP) This document introduces the Locator/ID Separation Protocol (LISP)
[RFC6830] architecture, its main operational mechanisms and its architecture [RFC9300] [RFC9301], its main operational mechanisms,
design rationale. Fundamentally, LISP is built following a well- and its design rationale. Fundamentally, LISP is built following a
known architectural idea: decoupling the IP address overloaded well-known architectural idea: decoupling the overloaded semantics of
semantics. Indeed and as pointed out by Noel Chiappa [RFC4984], IP addresses. As pointed out by Noel Chiappa [RFC4984], currently,
currently IP addresses both identify the topological location of a IP addresses identify both the topological location of a network
network attachment point as well as the node's identity. However, attachment point as well as the node's identity. However, nodes and
nodes and routing have fundamentally different requirements, routing routing have fundamentally different requirements. On one hand,
systems require that addresses are aggregatable and have topological routing systems require that addresses be aggregatable and have
meaning, while nodes require to be identified independently of their topological meaning; on the other hand, nodes must be identified
current location [RFC4984]. independently of their current location [RFC4984].
LISP creates two separate namespaces, EIDs (End-host IDentifiers) and LISP creates two separate namespaces, Endpoint Identifiers (EIDs) and
RLOCs (Routing LOCators), both are syntactically identical to the Routing Locators (RLOCs). Both are syntactically identical to the
current IPv4 and IPv6 addresses. EIDs are used to uniquely identify current IPv4 and IPv6 addresses. However, EIDs are used to uniquely
nodes irrespective of their topological location and are typically identify nodes irrespective of their topological location and are
routed intra-domain. RLOCs are assigned topologically to network typically routed intra-domain. RLOCs are assigned topologically to
attachment points and are typically routed inter-domain. With LISP, network attachment points and are typically routed inter-domain.
the edge of the Internet (where the nodes are connected) and the core With LISP, the edge of the Internet (where the nodes are connected)
(where inter-domain routing occurs) can be logically separated and and the core (where inter-domain routing occurs) can be logically
interconnected by LISP-capable routers. LISP also introduces a separated. LISP-capable routers interconnect the two logical spaces.
database, called the Mapping System, to store and retrieve mappings LISP also introduces a database, called the Mapping System, to store
between identity and location. LISP-capable routers exchange packets and retrieve mappings between identity and location. LISP-capable
over the Internet core by encapsulating them to the appropriate routers exchange packets over the Internet core by encapsulating them
location. to the appropriate location.
In summary: In summary:
o RLOCs have meaning only in the underlay network, that is the * RLOCs have meaning only in the underlay network, that is, the
underlying core routing system. underlying core routing system.
o EIDs have meaning only in the overlay network, which is the * EIDs have meaning only in the overlay network, which is the
encapsulation relationship between LISP-capable routers. encapsulation relationship between LISP-capable routers.
o The LISP edge maps EIDs to RLOCs * The LISP edge maps EIDs to RLOCs.
o Within the underlay network, RLOCs have both locator and * Within the underlay network, RLOCs have both Locator and
identifier semantics identifier semantics.
o An EID within a LISP site carries both identifier and locator * An EID within a LISP site carries both identifier and Locator
semantics to other nodes within that site semantics to other nodes within that site.
o An EID within a LISP site carries identifier and limited locator * An EID within a LISP site carries identifier and limited Locator
semantics to nodes at other LISP sites (i.e., enough locator semantics to nodes at other LISP sites (i.e., enough Locator
information to tell that the EID is external to the site) information to tell that the EID is external to the site).
The relationship described above is not unique to LISP but it is The relationship described above is not unique to LISP, and it is
common to other overlay technologies. common to other overlay technologies.
The initial motivation in the LISP effort is to be found in the The initial motivation in the LISP effort is to be found in the
routing scalability problem [RFC4984], where, if LISP were to be routing scalability problem [RFC4984], where, if LISP were to be
completely deployed, the Internet core is populated with RLOCs while completely deployed, the Internet core is populated with RLOCs while
Traffic Engineering mechanisms are pushed to the Mapping System. In Traffic Engineering (TE) mechanisms are pushed to the Mapping System.
such scenario RLOCs are quasi-static (i.e., low churn), hence making In such a scenario, RLOCs are quasi-static (i.e., low churn), hence
the routing system scalable [Quoitin], while EIDs can roam anywhere making the routing system scalable [Quoitin], while EIDs can roam
with no churn to the underlying routing system. [RFC7215] discusses anywhere with no churn to the underlying global routing system.
the impact of LISP on the global routing system during the transition [RFC7215] discusses the impact of LISP on the global routing system
period. However, the separation between location and identity that during the transition period. However, the separation between
LISP offers makes it suitable for use in additional scenarios such as location and identity that LISP offers makes it suitable for use in
Traffic Engineering (TE), multihoming, and mobility among others. additional scenarios, such as TE, multihoming, and mobility among
others.
This document describes the LISP architecture and its main This document describes the LISP architecture and its main
operational mechanisms as well as its design rationale. It is operational mechanisms as well as its design rationale. It is
important to note that this document does not specify or complement important to note that this document does not specify or complement
the LISP protocol. The interested reader should refer to the main LISP. The interested reader should refer to the main LISP
LISP specifications [RFC6830] and the complementary documents specifications (see [RFC9300] and [RFC9301]), as well as the
[RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835], [RFC6836], complementary documents (i.e., [RFC6831], [RFC6832], [RFC9302],
[RFC7052] for the protocol specifications along with the LISP [RFC6835], [RFC6836], and [RFC7052]) for the protocol specifications
deployment guidelines [RFC7215]. along with the LISP deployment guidelines [RFC7215].
2. Definition of Terms 2. Definitions of Terms
Endpoint IDentifier (EID): EIDs are addresses used to uniquely Endpoint Identifier (EID): Addresses used to uniquely identify nodes
identify nodes irrespective of their topological location and are irrespective of their topological location. Typically routed
typically routed intra-domain. intra-domain.
Routing LOcator (RLOC): RLOCs are addresses assigned topologically Routing Locator (RLOC): Addresses assigned topologically to network
to network attachment points and typically routed inter-domain. attachment points. Typically routed inter-domain.
Ingress Tunnel Router (ITR): A LISP-capable router that encapsulates Ingress Tunnel Router (ITR): A LISP-capable router that encapsulates
packets from a LISP site towards the core network. packets from a LISP site towards the core network.
Egress Tunnel Router (ETR): A LISP-capable router that decapsulates Egress Tunnel Router (ETR): A LISP-capable router that decapsulates
packets from the core of the network towards a LISP site. packets from the core of the network towards a LISP site.
xTR: A router that implements both ITR and ETR functionalities. xTR: A router that implements both ITR and ETR functionalities.
Map-Request: A LISP signaling message used to request an EID-to-RLOC Map-Request: A LISP signaling message used to request an EID-to-RLOC
skipping to change at page 5, line 6 skipping to change at line 192
Request that contains a resolved EID-to-RLOC mapping. Request that contains a resolved EID-to-RLOC mapping.
Map-Register: A LISP signaling message used to register an EID-to- Map-Register: A LISP signaling message used to register an EID-to-
RLOC mapping. RLOC mapping.
Map-Notify: A LISP signaling message sent in response of a Map- Map-Notify: A LISP signaling message sent in response of a Map-
Register to acknowledge the correct reception of an EID-to-RLOC Register to acknowledge the correct reception of an EID-to-RLOC
mapping. mapping.
This document describes the LISP architecture and does not introduce This document describes the LISP architecture and does not introduce
any new term. The reader is referred to [RFC6830], [RFC6831], any new terms. The reader is referred to [RFC9300], [RFC9301],
[RFC6832], [RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC7052], [RFC6831], [RFC6832], [RFC9302], [RFC6835], [RFC6836], [RFC7052], and
[RFC7215] for the complete definition of terms. [RFC7215] for the complete definition of terms.
3. LISP Architecture 3. LISP Architecture
This section presents the LISP architecture, it first details the This section presents the LISP architecture. It first details the
design principles of LISP and then it proceeds to describe its main design principles of LISP, and then it proceeds to describe its main
aspects: data-plane, control-plane, and internetworking mechanisms. aspects: data plane, control plane, and internetworking mechanisms.
3.1. Design Principles 3.1. Design Principles
The LISP architecture is built on top of four basic design The LISP architecture is built on top of four basic design
principles: principles:
o Locator/Identifier split: By decoupling the overloaded semantics Locator/Identifier split: Decoupling the overloaded semantics of
of the current IP addresses the Internet core can be assigned current IP addresses allows devices to have identity-based
identity meaningful addresses and hence, can use aggregation to addresses that are separate from topologically meaningful
scale. Devices are assigned with relatively opaque topologically addresses. By allowing only the topologically meaningful
meaningful addresses that are independent of their topological addresses to be exposed to the Internet core, those topologically
location. meaningful addresses can be aggregated to support substantial
scaling. Individual devices are assigned identity-based addresses
that are not used for forwarding in the Internet core.
o Overlay architecture: Overlays route packets over the current Overlay architecture: This architecture overlays route packets over
Internet, allowing deployment of new protocols without changing the current Internet, allowing deployment of new protocols without
the current infrastructure hence, resulting into a low deployment changing the current infrastructure; hence, this results in a low
cost. deployment cost.
o Decoupled data and control-plane: Separating the data-plane from Decoupled data plane and control plane: Separating the data plane
the control-plane allows them to scale independently and use from the control plane allows them to scale independently and use
different architectural approaches. This is important given that different architectural approaches. This is important given that
they typically have different requirements and allows for other they typically have different requirements and allows for other
data-planes to be added. While decoupled, data and control-plane data planes to be added. Even though the data plane and the
are not completely isolated because the LISP data-plane may control plane are decoupled, they are not completely isolated,
trigger control-plane activity. because the LISP data plane may trigger control plane activity.
o Incremental deployability: This principle ensures that the Incremental deployability: This principle ensures that the protocol
protocol interoperates with the legacy Internet while providing interoperates with the legacy Internet while providing some of the
some of the targeted benefits to early adopters. targeted benefits to early adopters.
3.2. Overview of the Architecture 3.2. Overview of the Architecture
LISP splits architecturally the core from the edge of the Internet by LISP architecturally splits the core from the edge of the Internet by
creating two separate namespaces: Endpoint Identifiers (EIDs) and creating two separate namespaces: Endpoint Identifiers (EIDs) and
Routing LOCators (RLOCs). The edge consists of LISP sites (e.g., an Routing Locators (RLOCs). The edge consists of LISP sites (e.g., an
Autonomous System) that use EID addresses. EIDs are IPv4 or IPv6 Autonomous System) that use EID addresses. EIDs are IPv4 or IPv6
addresses that uniquely identify communication end-hosts and are addresses that uniquely identify communication end hosts and are
assigned and configured by the same mechanisms that exist at the time assigned and configured by the same mechanisms that exist at the time
of this writing. EIDs do not contain inter-domain topological of this writing. EIDs do not contain inter-domain topological
information and because of this, EIDs are usually routable at the information, and because of this, EIDs are usually routable at the
edge (within LISP sites) or in the non-LISP Internet; see Section 3.5 edge (within LISP sites) but not in the core; see Section 3.5 for
for discussion of LISP site internetworking with non-LISP sites and discussion of LISP site internetworking with non-LISP sites and
domains in the Internet. domains in the Internet.
LISP sites (at the edge of the Internet) are connected to the core of LISP sites (at the edge) are connected to the interconnecting core of
the Internet by means of LISP-capable routers (e.g., border routers). the Internet by means of LISP-capable routers (e.g., border routers).
LISP sites are connected across the core of the Internet using LISP sites are connected across the interconnecting core of the
tunnels between the LISP-capable routers. When packets originated Internet using tunnels between the LISP-capable routers. When
from a LISP site are flowing towards the core network, they ingress packets originated from a LISP site are flowing towards the core
into an encapsulated tunnel via an Ingress Tunnel Router (ITR). When network, they ingress into an encapsulated tunnel via an Ingress
packets flow from the core network to a LISP site, they egress from Tunnel Router (ITR). When packets flow from the core network to a
an encapsulated tunnel to an Egress Tunnel Router (ETR). An xTR is a LISP site, they egress from an encapsulated tunnel to an Egress
router which can perform both ITR and ETR operations. In this Tunnel Router (ETR). An xTR is a router that can perform both ITR
context ITRs encapsulate packets while ETRs decapsulate them, hence and ETR operations. In this context, ITRs encapsulate packets, while
LISP operates as an overlay on top of the current Internet core. ETRs decapsulate them; hence, LISP operates as an overlay on top of
the current Internet core.
/-----------------\ --- /-----------------\ ---
| Mapping | | | Mapping | |
. System | | Control . System | | Control
-| |`, | Plane -| |`, | Plane
,' \-----------------/ . | ,' \-----------------/ . |
/ | --- / | ---
,.., - _,....,, | ,.., | ,.., - _,....,, | ,.., |
/ ` ,' ,-` `', | / ` | / ` ,' ,-` `', | / ` |
/ \ +-----+ ,' `, +-----+ / \ | / \ +-----+ ,' `, +-----+ / \ |
| EID |-| xTR |--/ RLOC ,--| xTR |-| EID | | Data | EID |-| xTR |--/ RLOC ,--| xTR |-| EID | | Data
| Space |-| |--| Space |--| |-| Space | | Plane | Space |-| |--| Space |--| |-| Space | | Plane
\ / +-----+ . / +-----+ \ / | \ / +-----+ . / +-----+ \ / |
`. .' `. ,' `. .' | `. .' `. ,' `. .' |
`'-` `., ,.' `'-` --- `'-` `., ,.' `'-` ---
``'''`` ``'''``
LISP Site (Edge) Core LISP Site (Edge) LISP Site (Edge) Core LISP Site (Edge)
Figure 1.- A schema of the LISP Architecture Figure 1: A Schema of the LISP Architecture
With LISP, the core uses RLOCs, an RLOC is an IPv4 or IPv6 address With LISP, the core uses RLOCs. An RLOC is an IPv4 or IPv6 address
assigned to an Internet-facing network interface of an ITR or ETR. assigned to a core-facing network interface of an ITR or ETR.
Typically RLOCs are numbered from topologically aggregatable blocks
assigned to a site at each point to which it attaches to the global
Internet, the topology is defined by the connectivity of networks.
A database which is typically distributed, called the Mapping System, A database that is typically distributed, called the Mapping System,
stores mappings between EIDs and RLOCs. Such mappings relate the stores mappings between EIDs and RLOCs. Such mappings relate the
identity of the devices attached to LISP sites (EIDs) to the set of identity of the devices attached to LISP sites (EIDs) to the set of
RLOCs configured at the LISP-capable routers servicing the site. RLOCs configured at the LISP-capable routers servicing the site.
Furthermore, the mappings also include traffic engineering policies Furthermore, the mappings also include TE policies and can be
and can be configured to achieve multihoming and load balancing. The configured to achieve multihoming and load balancing. The LISP
LISP Mapping System is conceptually similar to the DNS where it is Mapping System is conceptually similar to the DNS, where it is
organized as a distributed multi-organization network database. With organized as a distributed multi-organization network database. With
LISP, ETRs register mappings while ITRs retrieve them. LISP, ETRs register mappings, while ITRs retrieve them.
Finally, the LISP architecture emphasizes incremental deployment. Finally, the LISP architecture emphasizes incremental deployment.
Given that LISP represents an overlay to the current Internet Given that LISP represents an overlay to the current Internet
architecture, endhosts as well as intra and inter-domain routers architecture, end hosts, as well as intra-domain and inter-domain
remain unchanged, and the only required changes to the existing routers, remain unchanged. The only required changes to the existing
infrastructure are to routers connecting the EID with the RLOC space. infrastructure are to routers connecting the EID space with the RLOC
Additionally, LISP requires the deployment of an independent Mapping space. Additionally, LISP requires the deployment of an independent
System, such distributed database is a new network entity. Mapping System; such a distributed database is a new network entity.
The following describes a simplified packet flow sequence between two The following describes a simplified packet flow sequence between two
nodes that are attached to LISP sites. Please note that typical nodes that are attached to LISP sites. Please note that typical
LISP-capable routers are xTRs (both ITR and ETR). Client HostA wants LISP-capable routers are xTRs (both ITR and ETR). Client HostA wants
to send a packet to server HostB. to send a packet to server HostB.
/----------------\ /----------------\
| Mapping | | Mapping |
| System | | System |
.| |- .| |-
skipping to change at page 7, line 49 skipping to change at line 326
+-----+ | | RLOC_B1+-----+ +-----+ | | RLOC_B1+-----+
HostA | | | RLOC |-------| | HostB HostA | | | RLOC |-------| | HostB
EID_A--|ITR_A|----| Space | |ETR_B|--EID_B EID_A--|ITR_A|----| Space | |ETR_B|--EID_B
| | RLOC_A1 |-------| | | | RLOC_A1 |-------| |
+-----+ | | RLOC_B2+-----+ +-----+ | | RLOC_B2+-----+
, / , /
\ / \ /
`', ,-` `', ,-`
``''-''`` ``''-''``
Figure 2.- Packet flow sequence in LISP Figure 2: Packet Flow Sequence in LISP
1. HostA retrieves the EID_B of HostB, typically querying the DNS 1. HostA retrieves the EID_B of HostB, typically querying the DNS
and obtaining an A or AAAA record. Then it generates an IP and obtaining an A or AAAA record. Then, it generates an IP
packet as in the Internet, the packet has source address EID_A packet as in the Internet. The packet has source address EID_A
and destination address EID_B. and destination address EID_B.
2. The packet is routed towards ITR_A in the LISP site using 2. The packet is forwarded towards ITR_A in the LISP site using
standard intra-domain mechanisms. standard intra-domain mechanisms.
3. ITR_A upon receiving the packet queries the Mapping System to 3. ITR_A, upon receiving the packet, queries the Mapping System to
retrieve the locator of ETR_B that is servicing HostB's EID_B. retrieve the Locator of ETR_B that is servicing HostB's EID_B.
In order to do so it uses a LISP control message called Map- In order to do so, it uses a LISP control message called Map-
Request, the message contains EID_B as the lookup key. In turn Request. The message contains EID_B as the lookup key. In turn,
it receives another LISP control message called Map-Reply, the it receives another LISP control message called Map-Reply. The
message contains two locators: RLOC_B1 and RLOC_B2 along with message contains two Locators: RLOC_B1 and RLOC_B2. It also
traffic engineering policies: priority and weight per locator. contains TE policies: priority and weight per Locator. Note that
Note that a Map-Reply can contain more locators if needed. ITR_A a Map-Reply can contain more Locators if needed. ITR_A can cache
also stores the mapping in a local cache to speed-up forwarding the mapping in local storage to speed up forwarding of subsequent
of subsequent packets. packets.
4. ITR_A encapsulates the packet towards RLOC_B1 (chosen according 4. ITR_A encapsulates the packet towards RLOC_B1 (chosen according
to the priorities/weights specified in the mapping). The packet to the priorities/weights specified in the mapping). The packet
contains two IP headers, the outer header has RLOC_A1 as source contains two IP headers. The outer header has RLOC_A1 as source
and RLOC_B1 as destination, the inner original header has EID_A and RLOC_B1 as destination. The inner original header has EID_A
as source and EID_B as destination. Furthermore ITR_A adds a as source and EID_B as destination. Furthermore, ITR_A adds a
LISP header, more details about LISP encapsulation can be found LISP header. More details about LISP encapsulation can be found
in Section 3.3.1. in Section 3.3.1.
5. The encapsulated packet is forwarded by the Internet core as a 5. The encapsulated packet is forwarded over the interconnecting
normal IP packet, making the EID invisible from the Internet core as a normal IP packet, making the EID invisible from the
core. core.
6. Upon reception of the encapsulated packet by ETR_B, it 6. Upon reception of the encapsulated packet by ETR_B, it
decapsulates the packet and forwards it to HostB. decapsulates the packet and forwards it to HostB.
3.3. Data-Plane 3.3. Data Plane
This section provides a high-level description of the LISP data- This section provides a high-level description of the LISP data
plane, which is specified in detail in [RFC6830]. The LISP data- plane, which is specified in detail in [RFC9300]. The LISP data
plane is responsible for encapsulating and decapsulating data packets plane is responsible for encapsulating and decapsulating data packets
and caching the appropriate forwarding state. It includes two main and caching the appropriate forwarding state. It includes two main
entities, the ITR and the ETR, both are LISP capable routers that entities, the ITR and the ETR. Both are LISP-capable routers that
connect the EID with the RLOC space (ITR) and vice versa (ETR). connect the EID with the RLOC space (ITR) and vice versa (ETR).
3.3.1. LISP Encapsulation 3.3.1. LISP Encapsulation
ITRs encapsulate data packets towards ETRs. LISP data packets are ITRs encapsulate data packets towards ETRs. LISP data packets are
encapsulated using UDP (port 4341), the source port is usually encapsulated using UDP (port 4341). The source port is usually
selected by the ITR using a 5-tuple hash of the inner header (so to selected by the ITR using a 5-tuple hash of the inner header (so as
be consistent in case of multi-path solutions such as ECMP [RFC2992]) to be consistent in case of multipath solutions, such as ECMP
and ignored on reception. LISP data packets are often encapsulated [RFC2992]) and ignored on reception. LISP data packets are often
in UDP packets that include a zero checksum [RFC6935] [RFC6936] that encapsulated in UDP packets that include a zero checksum [RFC6935]
is not verified when it is received, because LISP data packets [RFC6936] that may not be verified when it is received, because LISP
typically include an inner transport protocol header with a non-zero data packets typically include an inner transport protocol header
checksum. By omitting the additional outer UDP encapsulation with a non-zero checksum. The use of UDP zero checksums over IPv6
checksum, xTRs can forward packets more efficiently. If LISP data for all tunneling protocols like LISP is subject to the applicability
packets are encapsulated in UDP packets with non-zero checksums, the statement in [RFC6936]. If LISP data packets are encapsulated in UDP
outer UDP checksums are verified when the UDP packets are received, packets with non-zero checksums, the outer UDP checksums are verified
as part of normal UDP processing. when the UDP packets are received, as part of normal UDP processing.
LISP-encapsulated packets also include a LISP header (after the UDP LISP-encapsulated packets also include a LISP header (after the UDP
header and before the original IP header). The LISP header is header and before the original IP header). The LISP header is
prepended by ITRs and striped by ETRs. It carries reachability prepended by ITRs and stripped by ETRs. It carries reachability
information (see more details in Section 4.2) and the Instance ID information (see more details in Section 4.2) and the 'Instance ID'
field. The Instance ID field is used to distinguish traffic to/from field. The 'Instance ID' field is used to distinguish traffic to/
different tenant address spaces at the LISP site and that may use from different tenant address spaces at the LISP site, and this use
overlapped but logically separated EID addressing. of the Instance ID may use overlapped but logically separated EID
addressing.
Overall, LISP works on 4 headers, the inner header the source Overall, LISP works on 4 headers: the inner header the source
constructed, and the 3 headers a LISP encapsulator prepends ("outer" constructed and the 3 headers a LISP encapsulator prepends ("outer"
to "inner"): to "inner"):
1. Outer IP header containing RLOCs as source and destination 1. Outer IP header containing RLOCs as source and destination
addresses. This header is originated by ITRs and stripped by addresses. This header is originated by ITRs and stripped by
ETRs. ETRs.
2. UDP header (port 4341) with zero checksum. This header is 2. UDP header (port 4341), usually with zero checksum. This header
originated by ITRs and stripped by ETRs. is originated by ITRs and stripped by ETRs.
3. LISP header that contains various forwarding-plane features (such 3. LISP header that contains various forwarding-plane features (such
as reachability) and an Instance ID field. This header is as reachability) and an 'Instance ID' field. This header is
originated by ITRs and stripped by ETRs. originated by ITRs and stripped by ETRs.
4. Inner IP header containing EIDs as source and destination 4. Inner IP header containing EIDs as source and destination
addresses. This header is created by the source end-host and is addresses. This header is created by the source end host and is
left unchanged by LISP data plane processing on the ITR and ETR. left unchanged by the LISP data plane processing on the ITR and
ETR.
Finally, in some scenarios Re-encapsulating and/or Recursive tunnels Finally, in some scenarios, re-encapsulating and/or recursive tunnels
are useful to choose a specified path in the underlay network, for are useful to choose a specified path in the underlay network, for
instance to avoid congestion or failure. Re-encapsulating tunnels instance, to avoid congestion or failure. Re-encapsulating tunnels
are consecutive LISP tunnels and occur when a decapsulator (an ETR are consecutive LISP tunnels and occur when a decapsulator (an ETR
action) removes a LISP header and then acts as an encapsultor (an ITR action) removes a LISP header and then acts as an encapsulator (an
action) to prepend another one. On the other hand, Recursive tunnels ITR action) to prepend another one. On the other hand, recursive
are nested tunnels and are implemented by using multiple LISP tunnels are nested tunnels and are implemented by using multiple LISP
encapsulations on a packet. Such functions are implemented by encapsulations on a packet. Such functions are implemented by Re-
Reencapsulating Tunnel Routers (RTRs). An RTR can be thought of as a encapsulating Tunnel Routers (RTRs). An RTR can be thought of as a
router that first acts as an ETR by decapsulating packets and then as router that first acts as an ETR by decapsulating packets and then as
an ITR by encapsulating them towards another locator, more an ITR by encapsulating them towards another Locator; more
information can be found at [RFC6830]. information can be found in [RFC9300] and [RFC9301].
3.3.2. LISP Forwarding State 3.3.2. LISP Forwarding State
In the LISP architecture, ITRs keep just enough information to route In the LISP architecture, ITRs keep just enough information to route
traffic flowing through them. Meaning that, ITRs retrieve from the traffic flowing through them. In other words, ITRs only need to
LISP Mapping System mappings between EID-prefixes (blocks of EIDs) retrieve from the LISP Mapping System mappings between EID-Prefixes
and RLOCs that are used to encapsulate packets. Such mappings are (blocks of EIDs) and RLOCs that are used to encapsulate packets.
stored in a local cache called the Map-Cache for subsequent packets Such mappings are stored in a local cache called the LISP Map-Cache
addressed to the same EID prefix. Note that, in case of overlapping for subsequent packets addressed to the same EID-Prefix. Note that
EID-prefixes, following a single request, the ITR may receive a set in the case of overlapping EID-Prefixes, after a request, the ITR may
of mappings, covering the requested EID-prefix and all more-specifics receive a set of mappings covering the requested EID-Prefix and all
(cf., Section 6.1.5 [RFC6830]). Mappings include a (Time-to-Live) more-specific EID-Prefixes (cf., Section 5.5 of [RFC9301]). Mappings
TTL (set by the ETR). More details about the Map-Cache management include a Time to Live (TTL) (set by the ETR). More details about
can be found in Section 4.1. the Map-Cache management can be found in Section 4.1.
3.4. Control-Plane 3.4. Control Plane
The LISP control-plane, specified in [RFC6833], provides a standard The LISP control plane, specified in [RFC9301], provides a standard
interface to register and request mappings. The LISP Mapping System interface to register and request mappings. The LISP Mapping System
is a database that stores such mappings. The following first is a database that stores such mappings. The following sub-sections
describes the mappings, then the standard interface to the Mapping first describe the mappings, then the standard interface to the
System, and finally its architecture. Mapping System, and finally its architecture.
3.4.1. LISP Mappings 3.4.1. LISP Mappings
Each mapping includes the bindings between EID prefix(es) and set of Each mapping includes the bindings between EID-Prefix(es) and a set
RLOCs as well as traffic engineering policies, in the form of of RLOCs as well as TE policies, in the form of priorities and
priorities and weights for the RLOCs. Priorities allow the ETR to weights for the RLOCs. Priorities allow the ETR to configure active/
configure active/backup policies while weights are used to load- backup policies, while weights are used to load-balance traffic among
balance traffic among the RLOCs (on a per-flow basis). the RLOCs (on a per-flow basis).
Typical mappings in LISP bind EIDs in the form of IP prefixes with a Typical mappings in LISP bind EIDs in the form of IP prefixes with a
set of RLOCs, also in the form of IPs. IPv4 and IPv6 addresses are set of RLOCs, also in the form of IP addresses. IPv4 and IPv6
encoded using the appropriate Address Family Identifier (AFI) addresses are encoded using the appropriate Address Family Identifier
[RFC3232]. However LISP can also support more general address (AFI) [RFC8060]. However, LISP can also support more general address
encoding by means of the ongoing effort around the LISP Canonical encoding by means of the ongoing effort around the LISP Canonical
Address Format (LCAF) [I-D.ietf-lisp-lcaf]. Address Format (LCAF) [RFC8060].
With such a general syntax for address encoding in place, LISP aims With such a general syntax for address encoding in place, LISP aims
to provide flexibility to current and future applications. For to provide flexibility to current and future applications. For
instance LCAFs could support MAC addresses, geo-coordinates, ASCII instance, LCAFs could support Media Access Control (MAC) addresses,
names and application specific data. geocoordinates, ASCII names, and application-specific data.
3.4.2. Mapping System Interface 3.4.2. Mapping System Interface
LISP defines a standard interface between data and control planes. LISP defines a standard interface between data and control planes.
The interface is specified in [RFC6833] and defines two entities: The interface is specified in [RFC9301] and defines two entities:
Map-Server: A network infrastructure component that learns mappings Map-Server: A network infrastructure component that learns mappings
from ETRs and publishes them into the LISP Mapping System. from ETRs and publishes them into the LISP Mapping System.
Typically Map-Servers are not authoritative to reply to queries Typically, Map-Servers are not authoritative to reply to queries;
and hence, they forward them to the ETR. However they can also hence, they forward them to the ETR. However, they can also
operate in proxy-mode, where the ETRs delegate replying to queries operate in proxy-mode, where the ETRs delegate replying to queries
to Map-Servers. This setup is useful when the ETR has limited to Map-Servers. This setup is useful when the ETR has limited
resources (i.e., CPU or power). resources (e.g., CPU or power).
Map-Resolver: A network infrastructure component that interfaces Map-Resolver: A network infrastructure component that interfaces
ITRs with the Mapping System by proxying queries and in some cases ITRs with the Mapping System by proxying queries and, in some
responses. cases, responses.
The interface defines four LISP control messages which are sent as The interface defines four LISP control messages that are sent as UDP
UDP datagrams (port 4342): datagrams (port 4342):
Map-Register: This message is used by ETRs to register mappings in Map-Register: This message is used by ETRs to register mappings in
the Mapping System and it is authenticated using a shared key the Mapping System, and it is authenticated using a shared key
between the ETR and the Map-Server. between the ETR and the Map-Server.
Map-Notify: When requested by the ETR, this message is sent by the Map-Notify: When requested by the ETR, this message is sent by the
Map-Server in response to a Map-Register to acknowledge the Map-Server in response to a Map-Register to acknowledge the
correct reception of the mapping and convey the latest Map-Server 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 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 be sent to the previous RLOCs when an EID is registered by a new
set of RLOCs. set of RLOCs.
Map-Request: This message is used by ITRs or Map-Resolvers to Map-Request: This message is used by ITRs or Map-Resolvers to
resolve the mapping of a given EID. resolve the mapping of a given EID.
Map-Reply: This message is sent by Map-Servers or ETRs in response Map-Reply: This message is sent by Map-Servers or ETRs in response
to a Map-Request and contains the resolved mapping. Please note to a Map-Request and contains the resolved mapping. Please note
that a Map-Reply may contain a negative reply if, for example, the 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 queried EID is not part of the LISP EID space. In such cases, the
ITR typically forwards the traffic natively (non encapsulated) to ITR typically forwards the traffic as is (non-encapsulated) to the
the public Internet, this behavior is defined to support public Internet. This behavior is defined to support incremental
incremental deployment of LISP. deployment of LISP.
3.4.3. Mapping System 3.4.3. Mapping System
LISP architecturally decouples control and data-plane by means of a LISP architecturally decouples control and data planes by means of a
standard interface. This interface glues the data-plane, routers standard interface. This interface glues the data plane -- routers
responsible for forwarding data-packets, with the LISP Mapping responsible for forwarding data packets -- with the LISP Mapping
System, a database responsible for storing mappings. System -- a database responsible for storing mappings.
With this separation in place the data and control-plane can use With this separation in place, the data and control planes can use
different architectures if needed and scale independently. Typically different architectures if needed and scale independently.
the data-plane is optimized to route packets according to Typically, the data plane is optimized to route packets according to
hierarchical IP addresses. However the control-plane may have hierarchical IP addresses. However, the control plane may have
different requirements, for instance and by taking advantage of the different requirements, for instance, and by taking advantage of the
LCAFs, the Mapping System may be used to store non-hierarchical keys LCAFs, the Mapping System may be used to store nonhierarchical keys
(such as MAC addresses), requiring different architectural approaches (such as MAC addresses), requiring different architectural approaches
for scalability. Another important difference between the LISP for scalability. Another important difference between the LISP
control and data-planes is that, and as a result of the local mapping control and data planes is that, and as a result of the local mapping
cache available at ITR, the Mapping System does not need to operate cache available at the ITR, the Mapping System does not need to
at line-rate. operate at line-rate.
Many of the existing mechanisms to create distributed systems have Many of the existing mechanisms to create distributed systems have
been explored and considered for the Mapping System architecture: been explored and considered for the Mapping System architecture:
graph-based databases in the form of LISP+ALT [RFC6836], hierarchical graph-based databases in the form of LISP Alternative Logical
databases in the form of LISP-DDT [I-D.ietf-lisp-ddt], monolithic Topology (LISP-ALT) [RFC6836], hierarchical databases in the form of
databases in the form of LISP-NERD [RFC6837], flat databases in the the LISP Delegated Database Tree (LISP-DDT) [RFC8111], monolithic
form of LISP-DHT [I-D.cheng-lisp-shdht],[Mathy] and, a multicast- databases in the form of the LISP Not-so-novel EID-to-RLOC Database
based database [I-D.curran-lisp-emacs]. Furthermore it is worth (LISP-NERD) [RFC6837], flat databases in the form of the LISP
noting that, in some scenarios such as private deployments, the Distributed Hash Table (LISP-DHT) [LISP-SHDHT] [Mathy], and a
Mapping System can operate as logically centralized. In such cases 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. it is typically composed of a single Map-Server/Map-Resolver.
The following focuses on the two mapping systems that have been The following sub-sections focus on the two Mapping Systems that have
implemented and deployed (LISP-ALT and LISP+DDT). been implemented and deployed (LISP-ALT and LISP-DDT).
3.4.3.1. LISP+ALT 3.4.3.1. LISP-ALT
The LISP Alternative Topology (LISP+ALT) [RFC6836] was the first LISP-ALT [RFC6836] was the first Mapping System proposed, developed,
Mapping System proposed, developed and deployed on the LISP pilot and deployed on the LISP pilot network. It is based on a distributed
network. It is based on a distributed BGP overlay participated by BGP overlay in which Map-Servers and Map-Resolvers participate. The
Map-Servers and Map-Resolvers. The nodes connect to their peers nodes connect to their peers through static tunnels. Each Map-Server
through static tunnels. Each Map-Server involved in the ALT topology involved in the ALT topology advertises the EID-Prefixes registered
advertises the EID-prefixes registered by the serviced ETRs, making by the serviced ETRs, making the EID routable on the ALT topology.
the EID routable on the ALT topology.
When an ITR needs a mapping it sends a Map-Request to a Map-Resolver 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 that, using the ALT topology, forwards the Map-Request towards the
Map-Server responsible for the mapping. Upon reception the Map- Map-Server responsible for the mapping. Upon reception, the Map-
Server forwards the request to the ETR that in turn, replies directly Server forwards the request to the ETR, which in turn replies
to the ITR using the native Internet core. directly to the ITR.
3.4.3.2. LISP-DDT 3.4.3.2. LISP-DDT
LISP-DDT [I-D.ietf-lisp-ddt] is conceptually similar to the DNS, a LISP-DDT [RFC8111] is conceptually similar to the DNS, a hierarchical
hierarchical directory whose internal structure mirrors the directory whose internal structure mirrors the hierarchical nature of
hierarchical nature of the EID address space. The DDT hierarchy is the EID address space. The DDT hierarchy is composed of DDT nodes
composed of DDT nodes forming a tree structure, the leafs of the tree forming a tree structure; the leafs of the tree are Map-Servers. On
are Map-Servers. On top of the structure there is the DDT root node top of the structure, there is the DDT root node, which is a
[DDT-ROOT], which is a particular instance of a DDT node and that particular instance of a DDT node, that matches the entire address
matches the entire address space. As in the case of DNS, DDT space. As in the case of DNS, DDT supports multiple redundant DDT
supports multiple redundant DDT nodes and/or DDT roots. Finally, nodes and/or DDT roots. Finally, Map-Resolvers are the clients of
Map-Resolvers are the clients of the DDT hierarchy and can query the DDT hierarchy and can query the DDT root and/or other DDT nodes.
either the DDT root and/or other DDT nodes.
/---------\ /---------\
| | | |
| DDT Root| | DDT Root|
| /0 | | /0 |
,.\---------/-, ,.\---------/-,
,-'` | `'., ,-'` | `'.,
-'` | `- -'` | `-
/-------\ /-------\ /-------\ /-------\ /-------\ /-------\
| DDT | | DDT | | DDT | | DDT | | DDT | | DDT |
| Node | | Node | | Note | ... | Node | | Node | | Node | ...
| 0/8 | | 1/8 | | 2/8 | | 0/8 | | 1/8 | | 2/8 |
\-------/ \-------/ \-------/ \-------/ \-------/ \-------/
_. _. . -..,,,_ _. _. . -..,,,_
-` -` \ ````''-- -` -` \ ````''--
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+ +------------+ +------------+
| Map-Server | | Map-Server | | Map-Server | | Map-Server | | Map-Server | | Map-Server | | Map-Server | | Map-Server |
| EID-prefix1| | EID-prefix2| | EID-prefix3| | EID-prefix4| | EID-Prefix1| | EID-Prefix2| | EID-Prefix3| | EID-Prefix4|
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+ +------------+ +------------+
Figure 3.- A schematic representation of the DDT tree structure, Figure 3: A Schematic Representation of the DDT Tree Structure
please note that the prefixes and the structure depicted
should be only considered as an example.
The DDT structure does not actually index EID-prefixes but eXtended Please note that the prefixes and the structure depicted in the
EID-prefixes (XEID). An XEID-prefix is just the concatenation of the figure above should only be considered as an example.
following fields (from most significant bit to less significant bit):
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 The DDT structure does not actually index EID-Prefixes; rather, it
DNS but only supports iterative lookups. DDT clients (usually Map- indexes Extended EID-Prefixes (XEID-Prefixes). An XEID-Prefix is
Resolvers) generate Map-Requests to the DDT root node. In response just the concatenation of the following fields (from most significant
they receive a newly introduced LISP-control message: a Map-Referral. bit to less significant bits): Database-ID, Instance ID, Address
A Map-Referral provides the list of RLOCs of the set of DDT nodes Family Identifier, and the actual EID-Prefix. The Database-ID is
matching a configured XEID delegation. That is, the information provided for possible future requirements of higher levels in the
contained in the Map-Referral points to the child of the queried DDT hierarchy and to enable the creation of multiple and separate
node that has more specific information about the queried XEID- database trees.
prefix. This process is repeated until the DDT client walks the tree
structure (downwards) and discovers the Map-Server servicing the In order to resolve a query, LISP-DDT operates in a similar way to
queried XEID. At this point the client sends a Map-Request and 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 receives a Map-Reply containing the mappings. It is important to
note that DDT clients can also cache the information contained in note that DDT clients can also cache the information contained in
Map-Referrals, that is, they cache the DDT structure. This is used Map-Referrals; that is, they cache the DDT structure. This is used
to reduce the mapping retrieving latency[Jakab]. to reduce the time required to retrieve mappings [Jakab].
The DDT Mapping System relies on manual configuration. That is Map- The DDT Mapping System relies on manual configuration. That is, Map-
Resolvers are manually configured with the set of available DDT root Resolvers are configured with the set of available DDT root nodes,
nodes while DDT nodes are manually configured with the appropriate while DDT nodes are configured with the appropriate XEID delegations.
XEID delegations. Configuration changes in the DDT nodes are only Configuration changes in the DDT nodes are only required when the
required when the tree structure changes itself, but it doesn't tree structure changes itself, but it doesn't depend on EID dynamics
depend on EID dynamics (RLOC allocation or traffic engineering policy (RLOC allocation or TE policy changes).
changes).
3.5. Internetworking Mechanisms 3.5. Internetworking Mechanisms
EIDs are typically identical to either IPv4 or IPv6 addresses and EIDs are typically identical to either IPv4 or IPv6 addresses, and
they are stored in the LISP Mapping System, however they are usually they are stored in the LISP Mapping System. However, they are
not announced in the Internet global routing system. As a result usually not announced in the routing system beyond the local LISP
LISP requires an internetworking mechanism to allow LISP sites to domain. As a result, LISP requires an internetworking mechanism to
speak with non-LISP sites and vice versa. LISP internetworking allow LISP sites to speak with non-LISP sites and vice versa. LISP
mechanisms are specified in [RFC6832]. internetworking mechanisms are specified in [RFC6832].
LISP defines two entities to provide internetworking: LISP defines two entities to provide internetworking:
Proxy Ingress Tunnel Router (PITR): PITRs provide connectivity from Proxy Ingress Tunnel Router (PITR): PITRs provide connectivity from
the legacy Internet to LISP sites. PITRs announce in the global the legacy Internet to LISP sites. PITRs announce in the global
routing system blocks of EID prefixes (aggregating when possible) routing system blocks of EID-Prefixes (aggregating when possible)
to attract traffic. For each incoming packet from a source not in 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 a LISP site (a non-EID), the PITR LISP-encapsulates it towards the
RLOC(s) of the appropriate LISP site. The impact of PITRs in 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 routing table size of the Default-Free Zone (DFZ) is, in the worst
worst-case, similar to the case in which LISP is not deployed. case, similar to the case in which LISP is not deployed. EID-
EID-prefixes will be aggregated as much as possible both by the Prefixes will be aggregated as much as possible, both by the PITR
PITR and by the global routing system. and by the global routing system.
Proxy Egress Tunnel Router (PETR): PETRs provide connectivity from Proxy Egress Tunnel Router (PETR): PETRs provide connectivity from
LISP sites to the legacy Internet. In some scenarios, LISP sites LISP sites to the legacy Internet. In some scenarios, LISP sites
may be unable to send encapsulated packets with a local EID may be unable to send encapsulated packets with a local EID
address as a source to the legacy Internet. For instance when address as a source to the legacy Internet, for instance, when
Unicast Reverse Path Forwarding (uRPF) is used by Provider Edge Unicast Reverse Path Forwarding (uRPF) is used by Provider Edge
routers, or when an intermediate network between a LISP site and a 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 non-LISP site does not support the desired version of IP (IPv4 or
IPv6). In both cases the PETR overcomes such limitations by IPv6). In both cases, the PETR overcomes such limitations by
encapsulating packets over the network. There is no specified encapsulating packets over the network. There is no specified
provision for the distribution of PETR RLOC addresses to the ITRs. provision for the distribution of PETR RLOC addresses to the ITRs.
Additionally, LISP also defines mechanisms to operate with private Additionally, LISP also defines mechanisms to operate with private
EIDs [RFC1918] by means of LISP-NAT [RFC6832]. In this case the xTR 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 replaces a private EID source address with a routable one. At the
time of this writing, work is ongoing to define NAT-traversal time of this writing, work is ongoing to define NAT-traversal
capabilities, that is xTRs behind a NAT using non-routable RLOCs. capabilities, that is, xTRs behind a NAT using non-routable RLOCs.
PITRs, PETRs and, LISP-NAT enable incremental deployment of LISP, by PITRs, PETRs, and LISP-NAT enable incremental deployment of LISP by
providing significant flexibility in the placement of the boundaries providing significant flexibility in the placement of the boundaries
between the LISP and non-LISP portions of the network, and making it between the LISP and non-LISP portions of the network and making it
easy to change those boundaries over time. easy to change those boundaries over time.
4. LISP Operational Mechanisms 4. LISP Operational Mechanisms
This section details the main operational mechanisms defined in LISP. This section details the main operational mechanisms defined in LISP.
4.1. Cache Management 4.1. Cache Management
LISP's decoupled control and data-plane, where mappings are stored in LISP's decoupled control and data planes, where mappings are stored
the control-plane and used for forwarding in the data plane, requires in the control plane and used for forwarding in the data plane,
a local cache in ITRs to reduce signaling overhead (Map-Request/Map- require a local cache in ITRs to reduce signaling overhead (Map-
Reply) and increase forwarding speed. The local cache available at Request/Map-Reply) and increase forwarding speed. The local cache
the ITRs, called Map-Cache, is used by the router to LISP-encapsulate available at the ITRs, called Map-Cache, is used by the router to
packets. The Map-Cache is indexed by (Instance ID, EID-prefix) and LISP-encapsulate packets. The Map-Cache is indexed by (Instance ID,
contains basically the set of RLOCs with the associated traffic EID-Prefix) and contains basically the set of RLOCs with the
engineering policies (priorities and weights). associated TE policies (priorities and weights).
The Map-Cache, as any other cache, requires cache coherence The Map-Cache, as with any other cache, requires cache coherence
mechanisms to maintain up-to-date information. LISP defines three mechanisms to maintain up-to-date information. LISP defines three
main mechanisms for cache coherence: main mechanisms for cache coherence:
Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, upon Record Time To Live (TTL): Each mapping record contains a TTL set by
expiration of the TTL the ITR can't use the mapping until it is the ETR. Upon expiration of the TTL, the ITR can't use the
refreshed by sending a new Map-Request. Typical values for TTL mapping until it is refreshed by sending a new Map-Request.
defined by LISP are 24 hours.
Solicit-Map-Request (SMR): SMR is an explicit mechanism to update Solicit-Map-Request (SMR): SMR is an explicit mechanism to update
mapping information. In particular a special type of Map-Request mapping information. In particular, a special type of Map-Request
can be sent on demand by ETRs to request refreshing a mapping. can be sent on demand by ETRs to request refreshing a mapping.
Upon reception of a SMR message, the ITR must refresh the bindings Upon reception of an SMR message, the ITR must refresh the
by sending a Map-Request to the Mapping System. Further uses of bindings by sending a Map-Request to the Mapping System. Further
SMRs are documented in [RFC6830]. uses of SMRs are documented in [RFC9301].
Map-Versioning: This optional mechanism piggybacks in the LISP Map-Versioning: This optional mechanism piggybacks, in the LISP
header of data-packets the version number of the mappings used by header of data packets, the version number of the mappings used by
an xTR. This way, when an xTR receives a LISP-encapsulated packet an xTR. This way, when an xTR receives a LISP-encapsulated packet
from a remote xTR, it can check whether its own Map-Cache or the from a remote xTR, it can check whether its own Map-Cache or the
one of the remote xTR is outdated. If its Map-Cache is outdated, one of the remote xTR is outdated. If its Map-Cache is outdated,
it sends a Map-Request for the remote EID so to obtain the newest it sends a Map-Request for the remote EID so as to obtain the
mappings. On the contrary, if it detects that the remote xTR Map- newest mappings. On the contrary, if it detects that the remote
Cache is outdated, it sends a SMR to notify it that a new mapping xTR Map-Cache is outdated, it sends an SMR to notify it that a new
is available. mapping is available. Further details are available in [RFC9302].
Finally it is worth noting that in some cases an entry in the map- Finally, it is worth noting that, in some cases, an entry in the Map-
cache can be proactively refreshed using the mechanisms described in Cache can be proactively refreshed using the mechanisms described in
the section below. the section below.
4.2. RLOC Reachability 4.2. RLOC Reachability
In most cases LISP operates with a pull-based Mapping System (e.g., In most cases, LISP operates with a pull-based Mapping System (e.g.,
DDT), this results in an edge to edge pull architecture. In such DDT). This results in an edge-to-edge pull architecture. In such a
scenario the network state is stored in the control-plane while the scenario, the network state is stored in the control plane while the
data-plane pulls it on demand. This has consequences concerning the data plane pulls it on demand. This has consequences concerning the
propagation of xTRs reachability/liveness information since pull propagation of xTRs' reachability/liveness information, since pull
architectures require explicit mechanisms to propagate this architectures require explicit mechanisms to propagate this
information. As a result LISP defines a set of mechanisms to inform information. As a result, LISP defines a set of mechanisms to inform
ITRs and PITRS about the reachability of the cached RLOCs: ITRs and PITRs about the reachability of the cached RLOCs:
Locator Status Bits (LSB): LSB is a passive technique, the LSB field Locator-Status-Bits (LSBs): Using LSBs is a passive technique. The
is carried by data-packets in the LISP header and can be set by a 'LSB' field is carried by data packets in the LISP header and can
ETRs to specify which RLOCs of the ETR site are up/down. This be set by ETRs to specify which RLOCs of the ETR site are up/down.
information can be used by the ITRs as a hint about the reachability This information can be used by the ITRs as a hint about the
to perform additional checks. Also note that LSB does not provide reachability to perform additional checks. Also note that LSBs do
path reachability status, only hints on the status of RLOCs. not provide path reachability status; they only provide hints
about the status of RLOCs. As such, they must not be used over
the public Internet and should be coupled with Map-Versioning to
prevent race conditions where LSBs are interpreted as referring to
different RLOCs than intended.
Echo-nonce: This is also a passive technique, that can only operate Echo-Nonce: This is also a passive technique that can only operate
effectively when data flows bi-directionally between two effectively when data flows bidirectionally between two
communicating xTRs. Basically, an ITR piggybacks a random number communicating xTRs. Basically, an ITR piggybacks a random number
(called nonce) in LISP data packets, if the path and the probed (called a nonce) in LISP data packets. If the path and the probed
locator are up, the ETR will piggyback the same random number on the Locator are up, the ETR will piggyback the same random number on
next data-packet, if this is not the case the ITR can set the locator the next data packet; if this is not the case, the ITR can set the
as unreachable. When traffic flow is unidirectional or when the ETR Locator as unreachable. When traffic flow is unidirectional or
receiving the traffic is not the same as the ITR that transmits it when the ETR receiving the traffic is not the same as the ITR that
back, additional mechanisms are required. transmits it back, additional mechanisms are required. The Echo-
Nonce mechanism must be used in trusted environments only, not
over the public Internet.
RLOC-probing: This is an active probing algorithm where ITRs send RLOC-Probing: This is an active probing algorithm where ITRs send
probes to specific locators, this effectively probes both the locator probes to specific Locators. This effectively probes both the
and the path. In particular this is done by sending a Map-Request Locator and the path. In particular, this is done by sending a
(with certain flags activated) on the data-plane (RLOC space) and Map-Request (with certain flags activated) on the data plane (RLOC
waiting in return a Map-Reply, also sent on the data-plane. The space) and then waiting for a Map-Reply (also sent on the data
active nature of RLOC-probing provides an effective mechanism to plane). The active nature of RLOC-Probing provides an effective
determine reachability and, in case of failure, switching to a mechanism for determining reachability and, in case of failure,
different locator. Furthermore the mechanism also provides useful switching to a different Locator. Furthermore, the mechanism also
RTT estimates of the delay of the path that can be used by other provides useful RTT estimates of the delay of the path that can be
network algorithms. used by other network algorithms.
It is worth noting that RLOC probing and Echo-nonce can work It is worth noting that RLOC-Probing and the Echo-Nonce can work
together. Specifically if a nonce is not echoed, an ITR could RLOC- together. Specifically, if a nonce is not echoed, an ITR cannot
probe to determine if the path is up when it cannot tell the determine which path direction has failed. In this scenario, an ITR
difference between a failed bidirectional path or the return path is can use RLOC-Probing.
not used (a unidirectional path).
Additionally, LISP also recommends inferring reachability of locators Additionally, LISP also recommends inferring the reachability of
by using information provided by the underlay, in particular: Locators by using information provided by the underlay, particularly:
ICMP signaling: The LISP underlay -the current Internet- uses the ICMP signaling: The LISP underlay -- the current Internet -- uses
ICMP protocol to signal unreachability (among other things). LISP ICMP to signal unreachability (among other things). LISP can take
can take advantage of this and the reception of a ICMP Network advantage of this, and the reception of an ICMP Network
Unreachable or ICMP Host Unreachable message can be seen as a hint Unreachable or ICMP Host Unreachable message can be seen as a hint
that a locator might be unreachable, this should lead to perform that a Locator might be unreachable. This should lead to
additional checks. performing additional checks.
Underlay routing: Both BGP and IBGP carry reachability information, Underlay routing: Both BGP and IGP carry reachability information.
LISP-capable routers that have access to underlay routing information LISP-capable routers that have access to underlay routing
can use it to determine if a given locator or path are reachable. information can use it to determine if a given Locator or path is
reachable.
4.3. ETR Synchronization 4.3. ETR Synchronization
All the ETRs that are authoritative to a particular EID-prefix must All the ETRs that are authoritative to a particular EID-Prefix must
announce the same mapping to the requesters, this means that ETRs announce the same mapping to the requesters. This means that ETRs
must be aware of the status of the RLOCs of the remaining ETRs. This must be aware of the status of the RLOCs of the remaining ETRs. This
is known as ETR synchronization. is known as ETR synchronization.
At the time of this writing LISP does not specify a mechanism to At the time of this writing, LISP does not specify a mechanism to
achieve ETR synchronization. Although many well-known techniques achieve ETR synchronization. Although many well-known techniques
could be applied to solve this issue it is still under research, as a could be applied to solve this issue, it is still under research. As
result operators must rely on coherent manual configuration a result, operators must rely on coherent manual configuration.
4.4. MTU Handling 4.4. MTU Handling
Since LISP encapsulates packets it requires dealing with packets that Since LISP encapsulates packets, it requires dealing with packets
exceed the MTU of the path between the ITR and the ETR. Specifically that exceed the MTU of the path between the ITR and the ETR.
LISP defines two mechanisms: Specifically, LISP defines two mechanisms:
Stateless: With this mechanism the effective MTU is assumed from the Stateless: With this mechanism, the effective MTU is assumed from
ITR's perspective. If a payload packet is too big for the the ITR's perspective. If a payload packet is too big for the
effective MTU, and can be fragmented, the payload packet is effective MTU and can be fragmented, the payload packet is
fragmented on the ITR, such that reassembly is performed at the fragmented on the ITR, such that reassembly is performed at the
destination host. destination host.
Stateful: With this mechanism ITRs keep track of the MTU of the Stateful: With this mechanism, ITRs keep track of the MTU of the
paths towards the destination locators by parsing the ICMP Too Big paths towards the destination Locators by parsing the ICMP Too Big
packets sent by intermediate routers. ITRs will send ICMP Too Big packets sent by intermediate routers. ITRs will send ICMP Too Big
messages to inform the sources about the effective MTU. messages to inform the sources about the effective MTU.
Additionally, ITRs can use mechanisms such as Path MTU Discovery
(PMTUD) [RFC1191] or Packetization Layer Path MTU Discovery
(PLPMTUD) [RFC4821] to keep track of the MTU towards the Locators.
Additionally ITRs can use mechanisms such as PMTUD [RFC1191] or In both cases, if the packet cannot be fragmented (IPv4 with DF=1 or
PLPMTUD [RFC4821] to keep track of the MTU towards the locators. IPv6), then the ITR drops it and replies with an ICMP Too Big message
In both cases if the packet cannot be fragmented (IPv4 with DF=1 or
IPv6) then the ITR drops it and replies with a ICMP Too Big message
to the source. to the source.
5. Mobility 5. Mobility
The separation between locators and identifiers in LISP is suitable The separation between Locators and identifiers in LISP is suitable
for traffic engineering purpose where LISP sites can change their for TE purposes where LISP sites can change their attachment points
attachment points to the Internet (i.e., RLOCs) without impacting to the Internet (i.e., RLOCs) without impacting endpoints or the
endpoints or the Internet core. In this context, the border routers Internet core. In this context, the border routers operate the xTR
operate the xTR functionality and endpoints are not aware of the functionality, and endpoints are not aware of the existence of LISP.
existence of LISP. This functionality is similar to Network Mobility This functionality is similar to Network Mobility [RFC3963].
[RFC3963]. However, this mode of operation does not allow seamless However, this mode of operation does not allow seamless mobility of
mobility of endpoints between different LISP sites as the EID address endpoints between different LISP sites, as the EID address might not
might not be routable in a visited site. Nevertheless, LISP can be be routable in a visited site. Nevertheless, LISP can be used to
used to enable seamless IP mobility when LISP is directly implemented enable seamless IP mobility when LISP is directly implemented in the
in the endpoint or when the endpoint roams to an attached xTR. Each endpoint or when the endpoint roams to an attached xTR. Each
endpoint is then an xTR and the EID address is the one presented to endpoint is then an xTR, and the EID address is the one presented to
the network stack used by applications while the RLOC is the address the network stack used by applications while the RLOC is the address
gathered from the network when it is visited. This functionality is gathered from the network when it is visited. This functionality is
similar to Mobile IP ([RFC5944] and [RFC6275]). similar to Mobile IP ([RFC5944] and [RFC6275]).
Whenever the device changes of RLOC, the xTR updates the RLOC of its Whenever a device changes its RLOC, the xTR updates the RLOC of its
local mapping and registers it to its Map-Server, typically with a local mapping and registers it to its Map-Server, typically with a
low TTL value (1min). To avoid the need of a home gateway, the ITR low TTL value (1 min). To avoid the need for a home gateway, the ITR
also indicates the RLOC change to all remote devices that have also indicates the RLOC change to all remote devices that have
ongoing communications with the device that moved. The combination ongoing communications with the device that moved. The combination
of both methods ensures the scalability of the system as signaling is of both methods ensures the scalability of the system, as signaling
strictly limited the Map-Server and to hosts with which is strictly limited to the Map-Server and to hosts with which
communications are ongoing. In the mobility case the EID-prefix can communications are ongoing. In the mobility case, the EID-Prefix can
be as small as a full /32 or /128 (IPv4 or IPv6 respectively) be as small as a full /32 or /128 (IPv4 or IPv6, respectively),
depending on the specific use-case (e.g., subnet mobility vs single depending on the specific use case (e.g., subnet mobility vs. single
VM/Mobile node mobility). VM/Mobile node mobility).
The decoupled identity and location provided by LISP allows it to The decoupled identity and location provided by LISP allow it to
operate with other layer 2 and layer 3 mobility solutions. operate with other Layer 2 and Layer 3 mobility solutions.
6. Multicast 6. Multicast
LISP also supports transporting IP multicast packets sent from the LISP also supports transporting IP multicast packets sent from the
EID space, the operational changes required to the multicast EID space. The required operational changes to the multicast
protocols are documented in [RFC6831]. protocols are documented in [RFC6831].
In such scenarios, LISP may create multicast state both at the core In such scenarios, LISP may create multicast state both at the core
and at the sites (both source and receiver). When signaling is used and at the sites (both source and receiver). When signaling is used
to create multicast state at the sites, LISP routers unicast to create multicast state at the sites, LISP routers encapsulate PIM
encapsulate PIM Join/Prune messages from receiver to source sites. Join/Prune messages from receiver to source sites as unicast packets.
At the core, ETRs build a new PIM Join/Prune message addressed to the At the core, ETRs build a new PIM Join/Prune message addressed to the
RLOC of the ITR servicing the source. An simplified sequence is RLOC of the ITR servicing the source. A simplified sequence is shown
shown below below.
1. An end-host willing to join a multicast channel sends an IGMP 1. An end host willing to join a multicast channel sends an IGMP
report. Multicast PIM routers at the LISP site propagate PIM report. Multicast PIM routers at the LISP site propagate PIM
Join/Prune messages (S-EID, G) towards the ETR. Join/Prune messages (S-EID, G) towards the ETR.
2. The join message flows to the ETR, upon reception the ETR builds 2. The Join message flows to the ETR. Upon reception, the ETR
two join messages, the first one unicast LISP-encapsulates the builds two Join messages. The first one unicast LISP-
original join message towards the RLOC of the ITR servicing the encapsulates the original Join message towards the RLOC of the
source. This message creates (S-EID, G) multicast state at the ITR servicing the source. This message creates (S-EID, G)
source site. The second join message contains as destination multicast state at the source site. The second Join message
address the RLOC of the ITR servicing the source (S-RLOC, G) and contains, as a destination address, the RLOC of the ITR servicing
creates multicast state at the core. the source (S-RLOC, G) and creates multicast state at the core.
3. Multicast data packets originated by the source (S-EID, G) flow 3. Multicast data packets originated by the source (S-EID, G) flow
from the source to the ITR. The ITR LISP-encapsulates the from the source to the ITR. The ITR LISP-encapsulates the
multicast packets, the outter header includes its own RLOC as the multicast packets. The outer header includes its own RLOC as the
source (S-RLOC) and the original multicast group address (G) as source (S-RLOC) and the original multicast group address (G) as
the destination. Please note that multicast group address are the destination. Please note that multicast group addresses are
logical and are not resolved by the mapping system. Then the logical and are not resolved by the Mapping System. Then, the
multicast packet is transmitted through the core towards the multicast packets are transmitted through the core towards the
receiving ETRs that decapsulates the packets and sends them using receiving ETRs, which decapsulate the packets and forward them
the receiver's site multicast state. using the receiver site's multicast state.
Please note that the inner and outer multicast addresses are in Please note that the inner and outer multicast addresses are
general different, unless in specific cases where the underlay generally different, except in specific cases where the underlay
provider implements a tight control on the overlay. LISP provider implements tight control on the overlay. LISP
specifications already support all PIM modes [RFC6831]. specifications already support all PIM modes [RFC6831].
Additionally, LISP can support as well non-PIM mechanisms in order to Additionally, LISP can also support non-PIM mechanisms in order to
maintain multicast state. maintain multicast state.
When multicast sources and receivers are active at LISP sites and the
core network between the sites does not provide multicast support, a
signal-free mechanism can be used to create an overlay that will
allow multicast traffic to flow between sites and connect the
multicast trees at the different sites [RFC8378]. Registrations from
the different receiver sites will be merged in the Mapping System to
assemble a multicast replication list inclusive of all RLOCs that
lead to receivers for a particular multicast group or multicast
channel. The replication list for each specific multicast entry is
maintained as a database mapping entry in the LISP Mapping System.
7. Use Cases 7. Use Cases
7.1. Traffic Engineering 7.1. Traffic Engineering
A LISP site can strictly impose via which ETRs the traffic must enter A LISP site can strictly impose via which ETRs the traffic must enter
the the LISP site network even though the path followed to reach the the LISP site network even though the path followed to reach the ETR
ETR is not under the control of the LISP site. This fine control is is not under the control of the LISP site. This fine control is
implemented with the mappings. When a remote site is willing to send implemented with the mappings. When a remote site is willing to send
traffic to a LISP site, it retrieves the mapping associated to the traffic to a LISP site, it retrieves the mapping associated with the
destination EID via the mapping system. The mapping is sent directly destination EID via the Mapping System. The mapping is sent directly
by an authoritative ETR of the EID and is not altered by any by an authoritative ETR of the EID and is not altered by any
intermediate network. intermediate network.
A mapping associates a list of RLOCs to an EID prefix. Each RLOC A mapping associates a list of RLOCs with an EID-Prefix. Each RLOC
corresponds to an interface of an ETR (or set of ETRs) that is able corresponds to an interface of an ETR (or set of ETRs) that is able
to correctly forward packets to EIDs in the prefix. Each RLOC is to correctly forward packets to EIDs in the prefix. Each RLOC is
tagged with a priority and a weight in the mapping. The priority is tagged with a priority and a weight in the mapping. The priority is
used to indicates which RLOCs should be preferred to send packets used to indicate which RLOCs should be preferred for sending packets
(the least preferred ones being provided for backup purpose). The (the least preferred ones being provided for backup purposes). The
weight permits to balance the load between the RLOCs with the same weight permits balancing the load between the RLOCs with the same
priority, proportionally to the weight value. priority, in proportion to the weight value.
As mappings are directly issued by the authoritative ETR of the EID As mappings are directly issued by the authoritative ETR of the EID
and are not altered while transmitted to the remote site, it offers and are not altered when transmitted to the remote site, it offers
highly flexible incoming inter-domain traffic engineering with even highly flexible incoming inter-domain TE and even makes it possible
the possibility for a site to support a different mapping policy for for a site to support a different mapping policy for each remote
each remote site. routing policies. site.
7.2. LISP for IPv6 Co-existence 7.2. LISP for IPv6 Co-existence
LISP encapsulations allows to transport packets using EIDs from a LISP encapsulations allow transporting packets using EIDs from a
given address family (e.g., IPv6) with packets from other address given address family (e.g., IPv6) with packets from other address
families (e.g., IPv4). The absence of correlation between the families (e.g., IPv4). The absence of correlation between the
address family of RLOCs and EIDs makes LISP a candidate to allow, address families of RLOCs and EIDs makes LISP a candidate to allow,
e.g., IPv6 to be deployed when all of the core network may not have e.g., IPv6 to be deployed when all of the core network may not have
IPv6 enabled. IPv6 enabled.
For example, two IPv6-only data centers could be interconnected via For example, two IPv6-only data centers could be interconnected via
the legacy IPv4 Internet. If their border routers are LISP capable, the legacy IPv4 Internet. If their border routers are LISP capable,
sending packets between the data center is done without any form of sending packets between the data centers is done without any form of
translation as the native IPv6 packets (in the EID space) will be translation, as the original IPv6 packets (in the EID space) will be
LISP encapsulated and transmitted over the IPv4 legacy Internet by LISP encapsulated and transmitted over the IPv4 legacy Internet via
the mean of IPv4 RLOCs. IPv4 RLOCs.
7.3. LISP for Virtual Private Networks 7.3. LISP for Virtual Private Networks
It is common to operate several virtual networks over the same It is common to operate several virtual networks over the same
physical infrastructure. In such virtual private networks, it is physical infrastructure. In such virtual private networks,
essential to distinguish which virtual network a packet belongs and determining to which virtual network a packet belongs is essential;
tags or labels are used for that purpose. When using LISP, the tags or labels are used for that purpose. When using LISP, the
distinction can be made with the Instance ID field. When an ITR distinction can be made with the 'Instance ID' field. When an ITR
encapsulates a packet from a particular virtual network (e.g., known encapsulates a packet from a particular virtual network (e.g., known
via the VRF or VLAN), it tags the encapsulated packet with the via Virtual Routing and Forwarding (VRF) or the VLAN), it tags the
Instance ID corresponding to the virtual network of the packet. When encapsulated packet with the Instance ID corresponding to the virtual
an ETR receives a packet tagged with an Instance ID it uses the network of the packet. When an ETR receives a packet tagged with an
Instance ID to determine how to treat the packet. Instance ID, it uses the Instance ID to determine how to treat the
packet.
The main usage of LISP for virtual private networks does not The main usage of LISP for virtual private networks does not
introduce additional requirements on the underlying network, as long introduce additional requirements on the underlying network, as long
as it is running IP. as it runs IP.
7.4. LISP for Virtual Machine Mobility in Data Centers 7.4. LISP for Virtual Machine Mobility in Data Centers
A way to enable seamless virtual machine mobility in data center is A way to enable seamless virtual machine (VM) mobility in the data
to conceive the datacenter backbone as the RLOC space and the subnet center is to conceive the data center backbone as the RLOC space and
where servers are hosted as forming the EID space. A LISP router is the subnet where servers are hosted as forming the EID space. A LISP
placed at the border between the backbone and each subnet. When a router is placed at the border between the backbone and each subnet.
virtual machine is moved to another subnet, it can keep (temporarily) When a VM is moved to another subnet, it can keep (temporarily) the
the address it had before the move so to continue without a transport address it had before the move so as to continue without a transport-
layer connection reset. When an xTR detects a source address layer connection reset. When an xTR detects a source address
received on a subnet to be an address not assigned to the subnet, it received on a subnet to be an address not assigned to the subnet, it
registers the address to the Mapping System. registers the address to the Mapping System.
To inform the other LISP routers that the machine moved and where, To inform the other LISP routers that the machine moved and where,
and then to avoid detours via the initial subnetwork, mechanisms such and then to avoid detours via the initial subnetwork, mechanisms such
as the Solicit-Map-Request messages are used. as the Solicit-Map-Request messages are used.
8. Security Considerations 8. Security Considerations
This section describes the security considerations associated to the This section describes the security considerations associated with
LISP protocol. LISP.
While in a push mapping system, the state necessary to forward In a push Mapping System, the state necessary to forward packets is
packets is learned independently of the traffic itself, with a pull learned independently of the traffic itself. However, with a pull
architecture, the system becomes reactive and data-plane events architecture, the system becomes reactive, and data plane events
(e.g., the arrival of a packet for an unknown destination) may (e.g., the arrival of a packet with an unknown destination address)
trigger control-plane events. This on-demand learning of mappings may trigger control plane events. This on-demand learning of
provides many advantages as discussed above but may also affect the mappings provides many advantages, as discussed above, but may also
way security is enforced. affect the way security is enforced.
Usually, the data-plane is implemented in the fast path of routers to Usually, the data plane is implemented in the fast path of routers to
provide high performance forwarding capabilities while the control- provide high-performance forwarding capabilities, while the control
plane features are implemented in the slow path to offer high plane features are implemented in the slow path to offer high
flexibility and a performance gap of several order of magnitude can flexibility, and a performance gap of several orders of magnitude can
be observed between the slow and the fast paths. As a consequence, be observed between the slow and fast paths. As a consequence, the
the way data-plane events are notified to the control-plane must be way to notify the control plane of data plane events must be
thought carefully so to not overload the slow path and rate limiting considered carefully so as not to overload the slow path, and rate
should be used as specified in [RFC6830]. limiting should be used as specified in [RFC9300] and [RFC9301].
Care must also be taken so to not overload the mapping system (i.e., Care must also be taken not to overload the Mapping System (i.e., the
the control plane infrastructure) as the operations to be performed control plane infrastructure), as the operations to be performed by
by the mapping system may be more complex than those on the data- the Mapping System may be more complex than those on the data plane.
plane, for that reason [RFC6830] recommends to rate limit the sending For that reason, [RFC9300] and [RFC9301] recommend rate limiting the
of messages to the mapping system. sending of messages to the Mapping System.
To improve resiliency and reduce the overall number of messages To improve resiliency and reduce the overall number of messages
exchanged, LISP offers the possibility to leak information, such as exchanged, LISP makes it possible to leak certain information, such
reachabilty of locators, directly into data plane packets. In as the reachability of Locators, directly into data plane packets.
environments that are not fully trusted, control information gleaned In environments that are not fully trusted, like the open Internet,
from data-plane packets should be verified before using them. control information gleaned from data plane packets must not be used
or must be verified before using it.
Mappings are the centrepiece of LISP and all precautions must be Mappings are the centerpiece of LISP, and all precautions must be
taken to avoid them to be manipulated or misused by malicious taken to prevent malicious entities from manipulating or misusing
entities. Using trustable Map-Servers that strictly respect them. Using trustable Map-Servers that strictly respect [RFC9301]
[RFC6833] and the lightweight authentication mechanism proposed by and the authentication mechanism proposed by LISP-SEC [RFC9303]
LISP-Sec [I-D.ietf-lisp-sec] reduces the risk of attacks to the reduces the risk of attacks on mapping integrity. In more critical
mapping integrity. In more critical environments, secure measures environments, secure measures may be needed. The way security is
may be needed. The way security is implemented for a given mapping implemented for a given Mapping System strongly depends on the
system strongly depends on the architecture of the mapping system architecture of the Mapping System itself and the threat model
itself and the threat model assumed for the deployment. Thus, the assumed for the deployment. Thus, Mapping System security has to be
mapping system security has to be discussed in the relevant documents discussed in the relevant documents proposing the Mapping System
proposing the mapping system architecture. architecture.
As with any other tunneling mechanism, middleboxes on the path As with any other tunneling mechanism, middleboxes on the path
between an ITR (or PITR) and an ETR (or PETR) must implement between an ITR (or PITR) and an ETR (or PETR) must implement
mechanisms to strip the LISP encapsulation to correctly inspect the mechanisms to strip the LISP encapsulation to correctly inspect the
content of LISP encapsulated packets. content of LISP-encapsulated packets.
Like other map-and-encap mechanisms, LISP enables triangular routing Like other map-and-encap mechanisms, LISP enables triangular routing
(i.e., packets of a flow cross different border routers depending on (i.e., packets of a flow cross different border routers, depending on
their direction). This means that intermediate boxes may have their direction). This means that intermediate boxes may have an
incomplete view on the traffic they inspect or manipulate. Moreover, incomplete view of the traffic they inspect or manipulate. Moreover,
LISP-encapsulated packets are routed based on the outer IP address LISP-encapsulated packets are routed based on the outer IP address
(i.e., the RLOC), and can be delivered to an ETR that is not (i.e., the RLOC) and can be delivered to an ETR that is not
responsible of the destination EID of the packet or even to a network responsible for the destination EID of the packet or even delivered
element that is not an ETR. The mitigation consists in applying to a network element that is not an ETR. Mitigation consists of
appropriate filtering techniques on the network elements that can applying appropriate filtering techniques on the network elements
potentially receive un-expected LISP-encapsulated packets that can potentially receive unexpected LISP-encapsulated packets.
More details about security implications of LISP are discussed in More details about security implications of LISP are discussed in
[I-D.ietf-lisp-threats]. [RFC7835].
9. IANA Considerations 9. IANA Considerations
This memo includes no request to IANA. This document has no IANA actions.
10. Acknowledgements
This document was initiated by Noel Chiappa and much of the core
philosophy came from him. The authors acknowledge the important
contributions he has made to this work and 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,
David Black as well as every people acknowledged in [RFC6830].
11. References
11.1. Normative References
[I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Delegated Database Tree", draft-ietf-lisp-ddt-02 (work in
progress), October 2014.
[I-D.ietf-lisp-lcaf]
Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", draft-ietf-lisp-lcaf-07 (work in
progress), December 2014.
[I-D.ietf-lisp-sec] 10. References
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-07
(work in progress), October 2014.
[I-D.ietf-lisp-threats] 10.1. Normative References
Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
Analysis", draft-ietf-lisp-threats-12 (work in progress),
March 2015.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
E. Lear, "Address Allocation for Private Internets", BCP J., and E. Lear, "Address Allocation for Private
5, RFC 1918, February 1996. Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path
Algorithm", RFC 2992, November 2000. Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000,
<https://www.rfc-editor.org/info/rfc2992>.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005. RFC 3963, DOI 10.17487/RFC3963, January 2005,
<https://www.rfc-editor.org/info/rfc3963>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007. Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>.
[RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
Workshop on Routing and Addressing", RFC 4984, September
2007.
[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
5944, November 2010. from the IAB Workshop on Routing and Addressing",
RFC 4984, DOI 10.17487/RFC4984, September 2007,
<https://www.rfc-editor.org/info/rfc4984>.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
in IPv6", RFC 6275, July 2011. RFC 5944, DOI 10.17487/RFC5944, November 2010,
<https://www.rfc-editor.org/info/rfc5944>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Locator/ID Separation Protocol (LISP)", RFC 6830, January Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2013. 2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
Locator/ID Separation Protocol (LISP) for Multicast Locator/ID Separation Protocol (LISP) for Multicast
Environments", RFC 6831, January 2013. Environments", RFC 6831, DOI 10.17487/RFC6831, January
2013, <https://www.rfc-editor.org/info/rfc6831>.
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol "Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832, January 2013. (LISP) and Non-LISP Sites", RFC 6832,
DOI 10.17487/RFC6832, January 2013,
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation <https://www.rfc-editor.org/info/rfc6832>.
Protocol (LISP) Map-Server Interface", RFC 6833, January
2013.
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", RFC 6834,
January 2013.
[RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation
Protocol Internet Groper (LIG)", RFC 6835, January 2013. Protocol Internet Groper (LIG)", RFC 6835,
DOI 10.17487/RFC6835, January 2013,
<https://www.rfc-editor.org/info/rfc6835>.
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical "Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", RFC 6836, January 2013. Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
January 2013, <https://www.rfc-editor.org/info/rfc6836>.
[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
Routing Locator (RLOC) Database", RFC 6837, January 2013. Routing Locator (RLOC) Database", RFC 6837,
DOI 10.17487/RFC6837, January 2013,
<https://www.rfc-editor.org/info/rfc6837>.
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
UDP Checksums for Tunneled Packets", RFC 6935, April 2013. UDP Checksums for Tunneled Packets", RFC 6935,
DOI 10.17487/RFC6935, April 2013,
<https://www.rfc-editor.org/info/rfc6935>.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums", for the Use of IPv6 UDP Datagrams with Zero Checksums",
RFC 6936, April 2013. RFC 6936, DOI 10.17487/RFC6936, April 2013,
<https://www.rfc-editor.org/info/rfc6936>.
[RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID [RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID
Separation Protocol (LISP) MIB", RFC 7052, October 2013. Separation Protocol (LISP) MIB", RFC 7052,
DOI 10.17487/RFC7052, October 2013,
<https://www.rfc-editor.org/info/rfc7052>.
[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
Pascual, J., and D. Lewis, "Locator/Identifier Separation Pascual, J., and D. Lewis, "Locator/Identifier Separation
Protocol (LISP) Network Element Deployment Protocol (LISP) Network Element Deployment
Considerations", RFC 7215, April 2014. Considerations", RFC 7215, DOI 10.17487/RFC7215, April
2014, <https://www.rfc-editor.org/info/rfc7215>.
11.2. Informative References [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Threat Analysis", RFC 7835,
DOI 10.17487/RFC7835, April 2016,
<https://www.rfc-editor.org/info/rfc7835>.
[DDT-ROOT] [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
LISP DDT ROOT, , "http://ddt-root.org/", August 2013. Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
February 2017, <https://www.rfc-editor.org/info/rfc8060>.
[I-D.cheng-lisp-shdht] [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
Cheng, L. and J. Wang, "LISP Single-Hop DHT Mapping Smirnov, "Locator/ID Separation Protocol Delegated
Overlay", draft-cheng-lisp-shdht-04 (work in progress), Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
July 2013. May 2017, <https://www.rfc-editor.org/info/rfc8111>.
[I-D.curran-lisp-emacs] [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID
Separation Protocol (LISP) Multicast", RFC 8378,
DOI 10.17487/RFC8378, May 2018,
<https://www.rfc-editor.org/info/rfc8378>.
[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos, Ed., "The Locator/ID Separation Protocol
(LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
<https://www.rfc-editor.org/info/rfc9300>.
[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
Ed., "Locator/ID Separation Protocol (LISP) Control
Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022,
<https://www.rfc-editor.org/info/rfc9301>.
[RFC9302] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", RFC 9302,
DOI 10.17487/RFC9302, October 2022,
<https://www.rfc-editor.org/info/rfc9302>.
[RFC9303] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez,
"Locator/ID Separation Protocol Security (LISP-SEC)",
RFC 9303, DOI 10.17487/RFC9303, October 2022,
<https://www.rfc-editor.org/info/rfc9303>.
10.2. Informative References
[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 Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID
Mappings Multicast Across Cooperating Systems for LISP", Mappings Multicast Across Cooperating Systems for LISP",
draft-curran-lisp-emacs-00 (work in progress), November Work in Progress, Internet-Draft, draft-curran-lisp-emacs-
2007. 00, 9 November 2007, <https://www.ietf.org/archive/id/
draft-curran-lisp-emacs-00.txt>.
[Jakab] Jakab, L., Cabellos, A., Saucez, D., and O. Bonaventure, [LISP-SHDHT]
"LISP-TREE: A DNS Hierarchy to Support the LISP Mapping Cheng, L. and M. Sun, "LISP Single-Hop DHT Mapping
System, IEEE Journal on Selected Areas in Communications, Overlay", Work in Progress, Internet-Draft, draft-cheng-
vol. 28, no. 8, pp. 1332-1343", October 2010. lisp-shdht-04, 15 July 2013,
<https://www.ietf.org/archive/id/draft-cheng-lisp-shdht-
04.txt>.
[Mathy] Mathy, L., Iannone, L., and O. Bonaventure, "LISP-DHT: [Mathy] Mathy, L. and L. Iannone, "LISP-DHT: Towards a DHT to map
Towards a DHT to map identifiers onto locators. The ACM identifiers onto locators", CoNEXT '08: Proceedings of the
ReArch, Re-Architecting the Internet. Madrid (Spain)", 2008 ACM CoNEXT Conference, ReArch '08 - Re-Architecting
December 2008. the Internet, DOI 10.1145/1544012.1544073, December 2008,
<https://dl.acm.org/doi/10.1145/1544012.1544073>.
[Quoitin] Quoitin, B., Iannone, L., Launois, C., and O. Bonaventure, [Quoitin] Quoitin, B., Iannone, L., de Launois, C., and O.
""Evaluating the Benefits of the Locator/Identifier Bonaventure, "Evaluating the Benefits of the Locator/
Separation" in Proceedings of 2Nd ACM/IEEE International Identifier Separation", Proceedings of 2nd ACM/IEEE
Workshop on Mobility in the Evolving Internet International Workshop on Mobility in the Evolving
Architecture", 2007. 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 Appendix A. A Brief History of Location/Identity Separation
The LISP architecture for separation of location and identity The LISP architecture for separation of location and identity
resulted from the discussions of this topic at the Amsterdam IAB resulted from the discussions of this topic at the Amsterdam IAB
Routing and Addressing Workshop, which took place in October 2006 Routing and Addressing Workshop, which took place in October 2006
[RFC4984]. [RFC4984].
A small group of like-minded personnel spontaneously formed A small group of like-minded personnel spontaneously formed
immediately after that workshop, to work on an idea that came out of immediately after that workshop to work on an idea that came out of
informal discussions at the workshop and on various mailing lists. informal discussions at the workshop and on various mailing lists.
The first Internet-Draft on LISP appeared in January, 2007. The first Internet-Draft on LISP appeared in January 2007.
Trial implementations started at that time, with initial trial Trial implementations started at that time, with initial trial
deployments underway since June 2007; the results of early experience deployments underway since June 2007; the results of early experience
have been fed back into the design in a continuous, ongoing process have been fed back into the design in a continuous, ongoing process
over several years. LISP at this point represents a moderately over several years. At this point, LISP represents a moderately
mature system, having undergone a long organic series of changes and mature system, having undergone a long, organic series of changes and
updates. updates.
LISP transitioned from an IRTF activity to an IETF WG in March 2009, LISP transitioned from an IRTF activity to an IETF WG in March 2009.
and after numerous revisions, the basic specifications moved to After numerous revisions, the basic specifications moved to becoming
becoming RFCs at the start of 2013 (although work to expand and RFCs at the start of 2013; work to expand, improve, and find new uses
improve it, and find new uses for it, continues, and undoubtly will for it continues (and undoubtedly will for a long time to come). The
for a long time to come). LISP WG was rechartered in 2018 to continue work on the LISP base
protocol and produce Standards Track documents.
A.1. Old LISP Models A.1. Old LISP Models
LISP, as initially conceived, had a number of potential operating LISP, as initially conceived, had a number of potential operating
modes, named 'models'. Although they are no used anymore, one modes, named 'models'. Although they are not used anymore, one
occasionally sees mention of them, so they are briefly described occasionally sees mention of them, so they are briefly described
here. here.
LISP 1: EIDs all appear in the normal routing and forwarding tables LISP 1: EIDs all appear in the normal routing and forwarding tables
of the network (i.e. they are 'routable');this property is used to of the network (i.e., they are 'routable'). This property is used
'bootstrap' operation, by using this to load EID->RLOC mappings. to load EID-to-RLOC mappings via bootstrapping operations.
Packets were sent with the EID as the destination in the outer Packets are sent with the EID as the destination in the outer
wrapper; when an ETR saw such a packet, it would send a Map-Reply wrapper; when an ETR sees such a packet, it sends a Map-Reply to
to the source ITR, giving the full mapping. the source ITR, giving the full mapping.
LISP 1.5: Similar to LISP 1, but the routability of EIDs happens on LISP 1.5: LISP 1.5 is similar to LISP 1, but the routability of EIDs
a separate network. happens on a separate network.
LISP 2: EIDs are not routable; EID->RLOC mappings are available from LISP 2: EIDs are not routable; EID-to-RLOC mappings are available
the DNS. from the DNS.
LISP 3: EIDs are not routable; and have to be looked up in in a new LISP 3: EIDs are not routable and have to be looked up in a new EID-
EID->RLOC mapping database (in the initial concept, a system using to-RLOC mapping database (in the initial concept, a system using
Distributed Hash Tables). Two variants were possible: a 'push' Distributed Hash Tables). Two variants were possible: a 'push'
system, in which all mappings were distributed to all ITRs, and a system in which all mappings were distributed to all ITRs and a
'pull' system in which ITRs load the mappings they need, as 'pull' system in which ITRs load the mappings when they need them.
needed.
Acknowledgments
This document was initiated by Noel Chiappa, and much of the core
philosophy came from him. The authors acknowledge the important
contributions he has made to this work and 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.
Authors' Addresses Authors' Addresses
Albert Cabellos Albert Cabellos
UPC-BarcelonaTech Universitat Politecnica de Catalunya
c/ Jordi Girona 1-3 c/ Jordi Girona s/n
Barcelona, Catalonia 08034 08034 Barcelona
Spain Spain
Email: acabello@ac.upc.edu Email: acabello@ac.upc.edu
Damien Saucez (Ed.) Damien Saucez (editor)
INRIA Inria
2004 route des Lucioles BP 93 2004 route des Lucioles - BP 93
Sophia Antipolis Cedex 06902 Sophia Antipolis
France France
Email: damien.saucez@inria.fr Email: damien.saucez@inria.fr
 End of changes. 210 change blocks. 
719 lines changed or deleted 767 lines changed or added

This html diff was produced by rfcdiff 1.48.