rfc9299v2.txt   rfc9299.txt 
Internet Engineering Task Force (IETF) A. Cabellos Internet Engineering Task Force (IETF) A. Cabellos
Request for Comments: 9299 UPC-BarcelonaTech Request for Comments: 9299 Universitat Politecnica de Catalunya
Category: Informational D. Saucez, Ed. Category: Informational D. Saucez, Ed.
ISSN: 2070-1721 Inria ISSN: 2070-1721 Inria
September 2022 October 2022
An Architectural Introduction to the Locator/ID Separation Protocol An Architectural Introduction to the Locator/ID Separation Protocol
(LISP) (LISP)
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
skipping to change at line 111 skipping to change at line 111
LISP creates two separate namespaces, Endpoint Identifiers (EIDs) and LISP creates two separate namespaces, Endpoint Identifiers (EIDs) and
Routing Locators (RLOCs). Both are syntactically identical to the Routing Locators (RLOCs). Both are syntactically identical to the
current IPv4 and IPv6 addresses. However, EIDs are used to uniquely current IPv4 and IPv6 addresses. However, EIDs are used to uniquely
identify nodes irrespective of their topological location and are identify nodes irrespective of their topological location and are
typically routed intra-domain. RLOCs are assigned topologically to typically routed intra-domain. RLOCs are assigned topologically to
network attachment points and are typically routed inter-domain. network attachment points and are typically routed inter-domain.
With LISP, the edge of the Internet (where the nodes are connected) With LISP, the edge of the Internet (where the nodes are connected)
and the core (where inter-domain routing occurs) can be logically and the core (where inter-domain routing occurs) can be logically
separated. LISP-capable routers interconnect the two logical spaces. separated. LISP-capable routers interconnect the two logical spaces.
LISP also introduces a database, called the mapping system, to store LISP also introduces a database, called the Mapping System, to store
and retrieve mappings between identity and location. LISP-capable and retrieve mappings between identity and location. LISP-capable
routers exchange packets over the Internet core by encapsulating them routers exchange packets over the Internet core by encapsulating them
to the appropriate location. to the appropriate location.
In summary: In summary:
* 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.
* 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.
* The LISP edge maps EIDs to RLOCs. * The LISP edge maps EIDs to RLOCs.
* Within the underlay network, RLOCs have both locator and * Within the underlay network, RLOCs have both Locator and
identifier semantics. identifier semantics.
* 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.
* 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, and 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 (TE) mechanisms are pushed to the mapping system. Traffic Engineering (TE) mechanisms are pushed to the Mapping System.
In such a scenario, RLOCs are quasi-static (i.e., low churn), hence In such a scenario, RLOCs are quasi-static (i.e., low churn), hence
making the routing system scalable [Quoitin], while EIDs can roam making the routing system scalable [Quoitin], while EIDs can roam
anywhere with no churn to the underlying global routing system. anywhere with no churn to the underlying global routing system.
[RFC7215] discusses the impact of LISP on the global routing system [RFC7215] discusses the impact of LISP on the global routing system
during the transition period. However, the separation between during the transition period. However, the separation between
location and identity that LISP offers makes it suitable for use in location and identity that LISP offers makes it suitable for use in
additional scenarios, such as TE, multihoming, and mobility among additional scenarios, such as TE, multihoming, and mobility among
others. others.
This document describes the LISP architecture and its main This document describes the LISP architecture and its main
skipping to change at line 282 skipping to change at line 282
`. .' `. ,' `. .' | `. .' `. ,' `. .' |
`'-` `., ,.' `'-` --- `'-` `., ,.' `'-` ---
``'''`` ``'''``
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 a core-facing network interface of an ITR or ETR. assigned to a core-facing network interface of an ITR or ETR.
A database that 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 TE policies and can be Furthermore, the mappings also include TE policies and can be
configured to achieve multihoming and load balancing. The LISP configured to achieve multihoming and load balancing. The 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, end hosts, as well as intra-domain and inter-domain architecture, end hosts, as well as intra-domain and inter-domain
routers, remain unchanged. The only required changes to the existing routers, remain unchanged. The only required changes to the existing
infrastructure are to routers connecting the EID space with the RLOC infrastructure are to routers connecting the EID space with the RLOC
space. Additionally, LISP requires the deployment of an independent space. Additionally, LISP requires the deployment of an independent
mapping system; such a 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 line 336 skipping to change at line 336
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 forwarded 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. It also message contains two Locators: RLOC_B1 and RLOC_B2. It also
contains TE policies: priority and weight per locator. Note that contains TE policies: priority and weight per Locator. Note that
a Map-Reply can contain more locators if needed. ITR_A can cache a Map-Reply can contain more Locators if needed. ITR_A can cache
the mapping in local storage to speed up forwarding of subsequent the mapping in local storage to speed up forwarding 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.
skipping to change at line 426 skipping to change at line 426
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 encapsulator (an action) removes a LISP header and then acts as an encapsulator (an
ITR action) to prepend another one. On the other hand, recursive ITR action) to prepend another one. On the other hand, recursive
tunnels 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 Re- encapsulations on a packet. Such functions are implemented by Re-
encapsulating 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 in [RFC9300] and [RFC9301]. 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. In other words, ITRs only need to traffic flowing through them. In other words, ITRs only need to
retrieve from the LISP mapping system mappings between EID-prefixes retrieve from the LISP Mapping System mappings between EID-Prefixes
(blocks of EIDs) and RLOCs that are used to encapsulate packets. (blocks of EIDs) and RLOCs that are used to encapsulate packets.
Such mappings are stored in a local cache called the LISP Map-Cache Such mappings are stored in a local cache called the LISP Map-Cache
for subsequent packets addressed to the same EID prefix. Note that for subsequent packets addressed to the same EID-Prefix. Note that
in the case of overlapping EID-prefixes, after a request, the ITR may in the case of overlapping EID-Prefixes, after a request, the ITR may
receive a set of mappings covering the requested EID-prefix and all receive a set of mappings covering the requested EID-Prefix and all
more-specific EID-prefixes (cf., Section 5.5 of [RFC9301]). Mappings more-specific EID-Prefixes (cf., Section 5.5 of [RFC9301]). Mappings
include a Time to Live (TTL) (set by the ETR). More details about include a Time to Live (TTL) (set by the ETR). More details about
the Map-Cache management 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 [RFC9301], 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 sub-sections is a database that stores such mappings. The following sub-sections
first describe the mappings, then the standard interface to the first describe the mappings, then the standard interface to the
mapping 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 a set Each mapping includes the bindings between EID-Prefix(es) and a set
of RLOCs as well as TE policies, in the form of priorities and of RLOCs as well as TE policies, in the form of priorities and
weights for the RLOCs. Priorities allow the ETR to configure active/ weights for the RLOCs. Priorities allow the ETR to configure active/
backup policies, while weights are used to load-balance traffic among backup policies, while weights are used to load-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 IP addresses. IPv4 and IPv6 set of RLOCs, also in the form of IP addresses. IPv4 and IPv6
addresses are encoded using the appropriate Address Family Identifier addresses are encoded using the appropriate Address Family Identifier
(AFI) [RFC8060]. 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
skipping to change at line 477 skipping to change at line 477
to provide flexibility to current and future applications. For to provide flexibility to current and future applications. For
instance, LCAFs could support Media Access Control (MAC) addresses, instance, LCAFs could support Media Access Control (MAC) addresses,
geocoordinates, ASCII 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 [RFC9301] 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;
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 (e.g., 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 ITRs with the Mapping System by proxying queries and, in some
cases, responses. cases, responses.
The interface defines four LISP control messages that are sent as UDP The interface defines four LISP control messages that are sent as 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
skipping to change at line 517 skipping to change at line 517
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 as is (non-encapsulated) to the ITR typically forwards the traffic as is (non-encapsulated) to the
public Internet. This behavior is defined to support incremental public Internet. This behavior is defined to support incremental
deployment of LISP. deployment of LISP.
3.4.3. Mapping System 3.4.3. Mapping System
LISP architecturally decouples control and data planes 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 planes can use With this separation in place, the data and control planes can use
different architectures if needed and scale independently. different architectures if needed and scale independently.
Typically, 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 nonhierarchical 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 the ITR, the mapping system does not need to cache available at the ITR, the Mapping System does not need to
operate 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 Alternative Logical graph-based databases in the form of LISP Alternative Logical
Topology (LISP-ALT) [RFC6836], hierarchical databases in the form of Topology (LISP-ALT) [RFC6836], hierarchical databases in the form of
the LISP Delegated Database Tree (LISP-DDT) [RFC8111], monolithic the LISP Delegated Database Tree (LISP-DDT) [RFC8111], monolithic
databases in the form of the LISP Not-so-novel EID-to-RLOC Database databases in the form of the LISP Not-so-novel EID-to-RLOC Database
(LISP-NERD) [RFC6837], flat databases in the form of the LISP (LISP-NERD) [RFC6837], flat databases in the form of the LISP
Distributed Hash Table (LISP-DHT) [LISP-SHDHT] [Mathy], and a Distributed Hash Table (LISP-DHT) [LISP-SHDHT] [Mathy], and a
multicast-based database [LISP-EMACS]. Furthermore, it is worth multicast-based database [LISP-EMACS]. Furthermore, it is worth
noting that, in some scenarios, such as private deployments, the noting that, in some scenarios, such as private deployments, the
mapping system can operate as logically centralized. In such cases, 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 sub-sections focus on the two mapping systems that have The following sub-sections focus on the two Mapping Systems that have
been 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
LISP-ALT [RFC6836] was the first mapping system proposed, developed, LISP-ALT [RFC6836] was the first Mapping System proposed, developed,
and deployed on the LISP pilot network. It is based on a distributed and deployed on the LISP pilot network. It is based on a distributed
BGP overlay in which Map-Servers and Map-Resolvers participate. The BGP overlay in which Map-Servers and Map-Resolvers participate. The
nodes connect to their peers through static tunnels. Each Map-Server nodes connect to their peers through static tunnels. Each Map-Server
involved in the ALT topology advertises the EID-prefixes registered involved in the ALT topology advertises the EID-Prefixes registered
by the serviced ETRs, making the EID routable on the ALT topology. by the serviced ETRs, making the EID routable on the ALT topology.
When an ITR needs a mapping, it sends a Map-Request to a Map-Resolver 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, which in turn replies Server forwards the request to the ETR, which in turn replies
directly to the ITR. directly to the ITR.
3.4.3.2. LISP-DDT 3.4.3.2. LISP-DDT
skipping to change at line 591 skipping to change at line 591
-'` | `- -'` | `-
/-------\ /-------\ /-------\ /-------\ /-------\ /-------\
| DDT | | DDT | | DDT | | DDT | | DDT | | DDT |
| Node | | Node | | Node | ... | 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 in the Please note that the prefixes and the structure depicted in the
figure above should only be considered as an example. figure above should only be considered as an example.
The DDT structure does not actually index EID-prefixes; rather, it The DDT structure does not actually index EID-Prefixes; rather, it
indexes Extended EID-prefixes (XEID-prefixes). An XEID-prefix is indexes Extended EID-Prefixes (XEID-Prefixes). An XEID-Prefix is
just the concatenation of the following fields (from most significant just the concatenation of the following fields (from most significant
bit to less significant bits): Database-ID, Instance ID, Address bit to less significant bits): Database-ID, Instance ID, Address
Family Identifier, and the actual EID-prefix. The Database-ID is Family Identifier, and the actual EID-Prefix. The Database-ID is
provided for possible future requirements of higher levels in the provided for possible future requirements of higher levels in the
hierarchy and to enable the creation of multiple and separate hierarchy and to enable the creation of multiple and separate
database trees. database trees.
In order to resolve a query, LISP-DDT operates in a similar way to In order to resolve a query, LISP-DDT operates in a similar way to
the DNS but only supports iterative lookups. DDT clients (usually the DNS but only supports iterative lookups. DDT clients (usually
Map-Resolvers) generate Map-Requests to the DDT root node. In Map-Resolvers) generate Map-Requests to the DDT root node. In
response, they receive a newly introduced LISP control message: a response, they receive a newly introduced LISP control message: a
Map-Referral. A Map-Referral provides the list of RLOCs of the set Map-Referral. A Map-Referral provides the list of RLOCs of the set
of DDT nodes matching a configured XEID delegation. That is, the of DDT nodes matching a configured XEID delegation. That is, the
information contained in the Map-Referral points to the child of the information contained in the Map-Referral points to the child of the
queried DDT node that has more specific information about the queried queried DDT node that has more specific information about the queried
XEID-prefix. This process is repeated until the DDT client walks the XEID-Prefix. This process is repeated until the DDT client walks the
tree structure (downwards) and discovers the Map-Server servicing the tree structure (downwards) and discovers the Map-Server servicing the
queried XEID. At this point, the client sends a Map-Request and 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 time required to retrieve mappings [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 configured with the set of available DDT root nodes, Resolvers are configured with the set of available DDT root nodes,
while DDT nodes are configured with the appropriate XEID delegations. while DDT nodes are configured with the appropriate XEID delegations.
Configuration changes in the DDT nodes are only required when the Configuration changes in the DDT nodes are only required when the
tree structure changes itself, but it doesn't depend on EID dynamics tree structure changes itself, but it doesn't depend on EID dynamics
(RLOC allocation or TE policy changes). (RLOC allocation or TE policy 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 they are stored in the LISP Mapping System. However, they are
usually not announced in the routing system beyond the local LISP usually not announced in the routing system beyond the local LISP
domain. As a result, LISP requires an internetworking mechanism to domain. As a result, LISP requires an internetworking mechanism to
allow LISP sites to speak with non-LISP sites and vice versa. LISP allow LISP sites to speak with non-LISP sites and vice versa. LISP
internetworking 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 on the RLOC(s) of the appropriate LISP site. The impact of PITRs on the
routing table size of the Default-Free Zone (DFZ) is, in the worst routing table size of the Default-Free Zone (DFZ) is, in the worst
case, similar to the case in which LISP is not deployed. EID- case, similar to the case in which LISP is not deployed. EID-
prefixes will be aggregated as much as possible, both by the PITR Prefixes will be aggregated as much as possible, both by the 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
skipping to change at line 687 skipping to change at line 687
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 planes, where mappings are stored LISP's decoupled control and data planes, where mappings are stored
in the control plane and used for forwarding in the data plane, in the control plane and used for forwarding in the data plane,
require a local cache in ITRs to reduce signaling overhead (Map- require a local cache in ITRs to reduce signaling overhead (Map-
Request/Map-Reply) and increase forwarding speed. The local cache Request/Map-Reply) and increase forwarding speed. The local cache
available at the ITRs, called Map-Cache, is used by the router to available at the ITRs, called Map-Cache, is used by the router to
LISP-encapsulate packets. The Map-Cache is indexed by (Instance ID, LISP-encapsulate packets. The Map-Cache is indexed by (Instance ID,
EID-prefix) and contains basically the set of RLOCs with the EID-Prefix) and contains basically the set of RLOCs with the
associated TE policies (priorities and weights). associated TE policies (priorities and weights).
The Map-Cache, as with 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:
Record Time To Live (TTL): Each mapping record contains a TTL set by Record Time To Live (TTL): Each mapping record contains a TTL set by
the ETR. Upon expiration of the TTL, the ITR can't use the the ETR. Upon expiration of the TTL, the ITR can't use the
mapping until it is refreshed by sending a new Map-Request. mapping until it is refreshed by sending a new Map-Request.
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 an SMR message, the ITR must refresh the Upon reception of an SMR message, the ITR must refresh the
bindings by sending a Map-Request to the mapping system. Further bindings by sending a Map-Request to the Mapping System. Further
uses of SMRs are documented in [RFC9301]. 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 as to obtain the it sends a Map-Request for the remote EID so as to obtain the
newest mappings. On the contrary, if it detects that the remote newest mappings. On the contrary, if it detects that the remote
xTR Map-Cache is outdated, it sends an SMR to notify it that a new xTR Map-Cache is outdated, it sends an SMR to notify it that a new
mapping is available. Further details are available in [RFC9302]. 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 a 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 (LSBs): Using LSBs is a passive technique. The Locator-Status-Bits (LSBs): Using LSBs is a passive technique. The
'LSB' field is carried by data packets in the LISP header and can 'LSB' field is carried by data packets in the LISP header and can
be set by ETRs to specify which RLOCs of the ETR site are up/down. be set by ETRs to specify which RLOCs of the ETR site are up/down.
This information can be used by the ITRs as a hint about the This information can be used by the ITRs as a hint about the
reachability to perform additional checks. Also note that LSBs do reachability to perform additional checks. Also note that LSBs do
not provide path reachability status; they only provide hints not provide path reachability status; they only provide hints
about the status of RLOCs. As such, they must not be used over about the status of RLOCs. As such, they must not be used over
the public Internet and should be coupled with Map-Versioning to the public Internet and should be coupled with Map-Versioning to
prevent race conditions where LSBs are interpreted as referring to prevent race conditions where LSBs are interpreted as referring to
different RLOCs than intended. 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 bidirectionally 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 a 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 Locator are up, the ETR will piggyback the same random number on
the next data packet; if this is not the case, the ITR can set the the next data packet; if this is not the case, the ITR can set the
locator as unreachable. When traffic flow is unidirectional or Locator as unreachable. When traffic flow is unidirectional or
when the ETR receiving the traffic is not the same as the ITR that when the ETR receiving the traffic is not the same as the ITR that
transmits it back, additional mechanisms are required. The echo- transmits it back, additional mechanisms are required. The Echo-
nonce mechanism must be used in trusted environments only, not Nonce mechanism must be used in trusted environments only, not
over the public Internet. 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 probes to specific Locators. This effectively probes both the
locator and the path. In particular, this is done by sending a Locator and the path. In particular, this is done by sending a
Map-Request (with certain flags activated) on the data plane (RLOC Map-Request (with certain flags activated) on the data plane (RLOC
space) and then waiting for a Map-Reply (also sent on the data space) and then waiting for a Map-Reply (also sent on the data
plane). The active nature of RLOC-Probing provides an effective plane). The active nature of RLOC-Probing provides an effective
mechanism for determining reachability and, in case of failure, mechanism for determining reachability and, in case of failure,
switching to a different locator. Furthermore, the mechanism also switching to a different Locator. Furthermore, the mechanism also
provides useful RTT estimates of the delay of the path that can be provides useful RTT estimates of the delay of the path that can be
used by other network algorithms. used by other network algorithms.
It is worth noting that RLOC-Probing and the 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 cannot together. Specifically, if a nonce is not echoed, an ITR cannot
determine which path direction has failed. In this scenario, an ITR determine which path direction has failed. In this scenario, an ITR
can use RLOC-probing. can use RLOC-Probing.
Additionally, LISP also recommends inferring the reachability of Additionally, LISP also recommends inferring the reachability of
locators by using information provided by the underlay, particularly: Locators by using information provided by the underlay, particularly:
ICMP signaling: The LISP underlay -- the current Internet -- uses ICMP signaling: The LISP underlay -- the current Internet -- uses
ICMP to signal unreachability (among other things). LISP can take ICMP to signal unreachability (among other things). LISP can take
advantage of this, and the reception of an 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 that a Locator might be unreachable. This should lead to
performing additional checks. performing additional checks.
Underlay routing: Both BGP and IGP carry reachability information. Underlay routing: Both BGP and IGP carry reachability information.
LISP-capable routers that have access to underlay routing LISP-capable routers that have access to underlay routing
information can use it to determine if a given locator or path is information can use it to determine if a given Locator or path is
reachable. 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 could be applied to solve this issue, it is still under research. As
a 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
skipping to change at line 809 skipping to change at line 809
that exceed the MTU of the path between the ITR and the ETR. that exceed the MTU of the path between the ITR and the ETR.
Specifically, LISP defines two mechanisms: Specifically, LISP defines two mechanisms:
Stateless: With this mechanism, the effective MTU is assumed from Stateless: With this mechanism, the effective MTU is assumed from
the 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 Additionally, ITRs can use mechanisms such as Path MTU Discovery
(PMTUD) [RFC1191] or Packetization Layer Path MTU Discovery (PMTUD) [RFC1191] or Packetization Layer Path MTU Discovery
(PLPMTUD) [RFC4821] to keep track of the MTU towards the locators. (PLPMTUD) [RFC4821] to keep track of the MTU towards the Locators.
In both cases, if the packet cannot be fragmented (IPv4 with DF=1 or In both cases, if the packet cannot be fragmented (IPv4 with DF=1 or
IPv6), then the ITR drops it and replies with an ICMP Too Big message IPv6), then the ITR drops it and replies with an 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 TE purposes where LISP sites can change their attachment points for TE purposes where LISP sites can change their attachment points
to the Internet (i.e., RLOCs) without impacting endpoints or the to the Internet (i.e., RLOCs) without impacting endpoints or the
Internet core. In this context, the border routers operate the xTR Internet core. In this context, the border routers operate the xTR
functionality, and endpoints are not aware of the existence of LISP. functionality, and endpoints are not aware of the existence of LISP.
This functionality is similar to Network Mobility [RFC3963]. This functionality is similar to Network Mobility [RFC3963].
However, this mode of operation does not allow seamless mobility of However, this mode of operation does not allow seamless mobility of
endpoints between different LISP sites, as the EID address might not endpoints between different LISP sites, as the EID address might not
be routable in a visited site. Nevertheless, LISP can be used to be routable in a visited site. Nevertheless, LISP can be used to
enable seamless IP mobility when LISP is directly implemented in the enable seamless IP mobility when LISP is directly implemented in the
endpoint or when the endpoint roams to an attached xTR. Each endpoint or when the endpoint roams to an attached xTR. Each
skipping to change at line 845 skipping to change at line 845
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 a device changes its 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 (1 min). To avoid the need for 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 of both methods ensures the scalability of the system, as signaling
is strictly limited to 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 allow 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
skipping to change at line 884 skipping to change at line 884
ITR servicing the source. This message creates (S-EID, G) ITR servicing the source. This message creates (S-EID, G)
multicast state at the source site. The second Join message multicast state at the source site. The second Join message
contains, as a destination address, the RLOC of the ITR servicing contains, as a destination address, the RLOC of the ITR servicing
the source (S-RLOC, G) and 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 outer 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 addresses 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 packets are transmitted through the core towards the multicast packets are transmitted through the core towards the
receiving ETRs, which decapsulate the packets and forward them receiving ETRs, which decapsulate the packets and forward them
using the receiver site's multicast state. using the receiver site's multicast state.
Please note that the inner and outer multicast addresses are Please note that the inner and outer multicast addresses are
generally different, except in specific cases where the underlay generally different, except in specific cases where the underlay
provider implements 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 also support 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 When multicast sources and receivers are active at LISP sites and the
core network between the sites does not provide multicast support, a core network between the sites does not provide multicast support, a
signal-free mechanism can be used to create an overlay that will signal-free mechanism can be used to create an overlay that will
allow multicast traffic to flow between sites and connect the allow multicast traffic to flow between sites and connect the
multicast trees at the different sites [RFC8378]. Registrations from multicast trees at the different sites [RFC8378]. Registrations from
the different receiver sites will be merged in the mapping system to the different receiver sites will be merged in the Mapping System to
assemble a multicast replication list inclusive of all RLOCs that assemble a multicast replication list inclusive of all RLOCs that
lead to receivers for a particular multicast group or multicast lead to receivers for a particular multicast group or multicast
channel. The replication list for each specific multicast entry is channel. The replication list for each specific multicast entry is
maintained as a database mapping entry in the LISP mapping system. 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 LISP site network even though the path followed to reach the ETR the LISP site network even though the path followed to reach the 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 with 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 with 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 indicate which RLOCs should be preferred for sending packets used to indicate which RLOCs should be preferred for sending packets
(the least preferred ones being provided for backup purposes). The (the least preferred ones being provided for backup purposes). The
weight permits balancing the load between the RLOCs with the same weight permits balancing the load between the RLOCs with the same
priority, in proportion 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 when transmitted to the remote site, it offers and are not altered when transmitted to the remote site, it offers
skipping to change at line 979 skipping to change at line 979
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 (VM) mobility in the data A way to enable seamless virtual machine (VM) mobility in the data
center is to conceive the data center backbone as the RLOC space and center is to conceive the data center backbone as the RLOC space and
the subnet where servers are hosted as forming the EID space. A LISP the subnet where servers are hosted as forming the EID space. A LISP
router is placed at the border between the backbone and each subnet. router is placed at the border between the backbone and each subnet.
When a VM is moved to another subnet, it can keep (temporarily) the When a VM is moved to another subnet, it can keep (temporarily) the
address it had before the move so as 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 with This section describes the security considerations associated with
LISP. LISP.
In a push mapping system, the state necessary to forward packets is In a push Mapping System, the state necessary to forward packets is
learned independently of the traffic itself. However, 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 with an unknown destination address) (e.g., the arrival of a packet with an unknown destination address)
may trigger control plane events. This on-demand learning of may trigger control plane events. This on-demand learning of
mappings provides many advantages, as discussed above, but may also mappings provides many advantages, as discussed above, but may also
affect the 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 orders of magnitude can flexibility, and a performance gap of several orders of magnitude can
be observed between the slow and fast paths. As a consequence, the be observed between the slow and fast paths. As a consequence, the
way to notify the control plane of data plane events must be way to notify the control plane of data plane events must be
considered carefully so as not to overload the slow path, and rate considered carefully so as not to overload the slow path, and rate
limiting should be used as specified in [RFC9300] and [RFC9301]. limiting should be used as specified in [RFC9300] and [RFC9301].
Care must also be taken not to overload the mapping system (i.e., the Care must also be taken not to overload the Mapping System (i.e., the
control plane infrastructure), as the operations to be performed by control plane infrastructure), as the operations to be performed by
the mapping system may be more complex than those on the data plane. the Mapping System may be more complex than those on the data plane.
For that reason, [RFC9300] and [RFC9301] recommend rate limiting the For that reason, [RFC9300] and [RFC9301] recommend rate limiting the
sending 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 makes it possible to leak certain information, such exchanged, LISP makes it possible to leak certain information, such
as the reachability of locators, directly into data plane packets. as the reachability of Locators, directly into data plane packets.
In environments that are not fully trusted, like the open Internet, In environments that are not fully trusted, like the open Internet,
control information gleaned from data plane packets must not be used control information gleaned from data plane packets must not be used
or must be verified before using it. or must be verified before using it.
Mappings are the centerpiece of LISP, and all precautions must be Mappings are the centerpiece of LISP, and all precautions must be
taken to prevent malicious entities from manipulating or misusing taken to prevent malicious entities from manipulating or misusing
them. Using trustable Map-Servers that strictly respect [RFC9301] them. Using trustable Map-Servers that strictly respect [RFC9301]
and the authentication mechanism proposed by LISP-SEC [RFC9303] and the authentication mechanism proposed by LISP-SEC [RFC9303]
reduces the risk of attacks on mapping integrity. In more critical reduces the risk of attacks on mapping integrity. In more critical
environments, secure measures may be needed. The way security is environments, secure measures may be needed. The way security is
implemented for a given mapping system strongly depends on the implemented for a given Mapping System strongly depends on the
architecture of the mapping system itself and the threat model architecture of the Mapping System itself and the threat model
assumed for the deployment. Thus, mapping system security has to be assumed for the deployment. Thus, Mapping System security has to be
discussed in the relevant documents proposing the mapping system discussed in the relevant documents 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 an their direction). This means that intermediate boxes may have an
skipping to change at line 1162 skipping to change at line 1162
Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
May 2017, <https://www.rfc-editor.org/info/rfc8111>. May 2017, <https://www.rfc-editor.org/info/rfc8111>.
[RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID
Separation Protocol (LISP) Multicast", RFC 8378, Separation Protocol (LISP) Multicast", RFC 8378,
DOI 10.17487/RFC8378, May 2018, DOI 10.17487/RFC8378, May 2018,
<https://www.rfc-editor.org/info/rfc8378>. <https://www.rfc-editor.org/info/rfc8378>.
[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. [RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos, Ed., "The Locator/ID Separation Protocol Cabellos, Ed., "The Locator/ID Separation Protocol
(LISP)", RFC 9300, DOI 10.17487/RFC9300, September 2022, (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
<https://www.rfc-editor.org/info/rfc9300>. <https://www.rfc-editor.org/info/rfc9300>.
[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, [RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
Ed., "Locator/ID Separation Protocol (LISP) Control Ed., "Locator/ID Separation Protocol (LISP) Control
Plane", RFC 9301, DOI 10.17487/RFC9301, September 2022, Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022,
<https://www.rfc-editor.org/info/rfc9301>. <https://www.rfc-editor.org/info/rfc9301>.
[RFC9302] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID [RFC9302] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", RFC 9302, Separation Protocol (LISP) Map-Versioning", RFC 9302,
DOI 10.17487/RFC9302, September 2022, DOI 10.17487/RFC9302, October 2022,
<https://www.rfc-editor.org/info/rfc9302>. <https://www.rfc-editor.org/info/rfc9302>.
[RFC9303] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, [RFC9303] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez,
"Locator/ID Separation Protocol Security (LISP-SEC)", "Locator/ID Separation Protocol Security (LISP-SEC)",
RFC 9303, DOI 10.17487/RFC9303, September 2022, RFC 9303, DOI 10.17487/RFC9303, October 2022,
<https://www.rfc-editor.org/info/rfc9303>. <https://www.rfc-editor.org/info/rfc9303>.
10.2. Informative References 10.2. Informative References
[Jakab] Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D., [Jakab] Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D.,
and O. Bonaventure, "LISP-TREE: A DNS Hierarchy to Support and O. Bonaventure, "LISP-TREE: A DNS Hierarchy to Support
the LISP Mapping System", IEEE Journal on Selected Areas the LISP Mapping System", IEEE Journal on Selected Areas
in Communications, vol. 28, no. 8, pp. 1332-1343, in Communications, vol. 28, no. 8, pp. 1332-1343,
DOI 10.1109/JSAC.2010.101011, October 2010, DOI 10.1109/JSAC.2010.101011, October 2010,
<https://ieeexplore.ieee.org/document/5586446>. <https://ieeexplore.ieee.org/document/5586446>.
skipping to change at line 1284 skipping to change at line 1284
The authors would also like to thank Dino Farinacci, Fabio Maino, The authors would also like to thank Dino Farinacci, Fabio Maino,
Luigi Iannone, Sharon Barkai, Isidoros Kouvelas, Christian Cassar, Luigi Iannone, Sharon Barkai, Isidoros Kouvelas, Christian Cassar,
Florin Coras, Marc Binderberger, Alberto Rodriguez-Natal, Ronald Florin Coras, Marc Binderberger, Alberto Rodriguez-Natal, Ronald
Bonica, Chad Hintz, Robert Raszuk, Joel M. Halpern, Darrel Lewis, and Bonica, Chad Hintz, Robert Raszuk, Joel M. Halpern, Darrel Lewis, and
David Black. 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
08034 Barcelona Catalonia 08034 Barcelona
Spain Spain
Email: acabello@ac.upc.edu Email: acabello@ac.upc.edu
Damien Saucez (editor) Damien Saucez (editor)
Inria Inria
2004 route des Lucioles BP 93 2004 route des Lucioles - BP 93
06902 Sophia Antipolis Cedex Sophia Antipolis
France France
Email: damien.saucez@inria.fr Email: damien.saucez@inria.fr
 End of changes. 74 change blocks. 
91 lines changed or deleted 91 lines changed or added

This html diff was produced by rfcdiff 1.48.