Network Working Group

Internet Engineering Task Force (IETF)                       A. Cabellos
Internet-Draft                                         UPC-BarcelonaTech
Intended status:
Request for Comments: 9299          Universitat Politecnica de Catalunya
Category: Informational                                   D. Saucez (Ed.)
Expires: Saucez, Ed.
ISSN: 2070-1721                                                    Inria
                                                            October 4, 2015                                           INRIA
                                                          April 02, 2015 2022

  An Architectural Introduction to the Locator/ID Separation Protocol
                                 (LISP)
                  draft-ietf-lisp-introduction-13.txt

Abstract

   This document describes the architecture of the Locator/ID Separation
   Protocol (LISP), making it easier to read the rest of the LISP
   specifications and providing a basis for discussion about the details
   of the LISP protocols.  This document is used for introductory
   purposes,
   purposes; more details can be found in RFC6830, the protocol
   specification. specifications,
   RFCs 9300 and 9301.

Status of This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents valid
   approved by the IESG are candidates for a maximum any level of six months Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 4, 2015.
   https://www.rfc-editor.org/info/rfc9299.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info)
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified Revised BSD License text as described in Section 4.e of the
   Trust Legal Provisions and are provided without warranty as described
   in the Simplified Revised BSD License.

Table of Contents

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

1.  Introduction

   This document introduces the Locator/ID Separation Protocol (LISP)
   [RFC6830] architecture,
   architecture [RFC9300] [RFC9301], its main operational mechanisms mechanisms,
   and its design rationale.  Fundamentally, LISP is built following a well-
   known
   well-known architectural idea: decoupling the IP address overloaded
   semantics.  Indeed and as semantics of
   IP addresses.  As pointed out by Noel Chiappa [RFC4984],
   currently currently,
   IP addresses both identify both the topological location of a network
   attachment point as well as the node's identity.  However, nodes and
   routing have fundamentally different requirements, requirements.  On one hand,
   routing systems require that addresses are be aggregatable and have
   topological
   meaning, while meaning; on the other hand, nodes require to must be identified
   independently of their current location [RFC4984].

   LISP creates two separate namespaces, EIDs (End-host IDentifiers) Endpoint Identifiers (EIDs) and
   RLOCs (Routing LOCators), both
   Routing Locators (RLOCs).  Both are syntactically identical to the
   current IPv4 and IPv6 addresses.  However, EIDs are used to uniquely
   identify nodes irrespective of their topological location and are
   typically routed intra-domain.  RLOCs are assigned topologically to
   network attachment points and are typically routed inter-domain.
   With LISP, the edge of the Internet (where the nodes are connected)
   and the core (where inter-domain routing occurs) can be logically separated and
   interconnected by
   separated.  LISP-capable routers. routers interconnect the two logical spaces.
   LISP also introduces a database, called the Mapping System, to store
   and retrieve mappings between identity and location.  LISP-capable
   routers exchange packets over the Internet core by encapsulating them
   to the appropriate location.

   In summary:

   o

   *  RLOCs have meaning only in the underlay network, that is is, the
      underlying core routing system.

   o

   *  EIDs have meaning only in the overlay network, which is the
      encapsulation relationship between LISP-capable routers.

   o

   *  The LISP edge maps EIDs to RLOCs

   o RLOCs.

   *  Within the underlay network, RLOCs have both locator Locator and
      identifier semantics

   o semantics.

   *  An EID within a LISP site carries both identifier and locator Locator
      semantics to other nodes within that site

   o site.

   *  An EID within a LISP site carries identifier and limited locator Locator
      semantics to nodes at other LISP sites (i.e., enough locator Locator
      information to tell that the EID is external to the site) site).

   The relationship described above is not unique to LISP but LISP, and it is
   common to other overlay technologies.

   The initial motivation in the LISP effort is to be found in the
   routing scalability problem [RFC4984], where, if LISP were to be
   completely deployed, the Internet core is populated with RLOCs while
   Traffic Engineering (TE) mechanisms are pushed to the Mapping System.
   In such scenario a scenario, RLOCs are quasi-static (i.e., low churn), hence
   making the routing system scalable [Quoitin], while EIDs can roam
   anywhere with no churn to the underlying global routing system.
   [RFC7215] discusses the impact of LISP on the global routing system
   during the transition period.  However, the separation between
   location and identity that LISP offers makes it suitable for use in
   additional scenarios scenarios, such as
   Traffic Engineering (TE), TE, multihoming, and mobility among
   others.

   This document describes the LISP architecture and its main
   operational mechanisms as well as its design rationale.  It is
   important to note that this document does not specify or complement
   the LISP protocol.
   LISP.  The interested reader should refer to the main LISP
   specifications [RFC6830] (see [RFC9300] and [RFC9301]), as well as the
   complementary documents (i.e., [RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC9302],
   [RFC6835], [RFC6836],
   [RFC7052] and [RFC7052]) for the protocol specifications
   along with the LISP deployment guidelines [RFC7215].

2.  Definition  Definitions of Terms

   Endpoint IDentifier Identifier (EID):  EIDs are addresses  Addresses used to uniquely identify nodes
      irrespective of their topological location and are
      typically location.  Typically routed
      intra-domain.

   Routing LOcator Locator (RLOC):  RLOCs are addresses  Addresses assigned topologically to network
      attachment points and typically points.  Typically routed inter-domain.

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

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

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

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

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

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

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

   This document describes the LISP architecture and does not introduce
   any new term. terms.  The reader is referred to [RFC6830], [RFC9300], [RFC9301],
   [RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC9302], [RFC6835], [RFC6836], [RFC7052], and
   [RFC7215] for the complete definition of terms.

3.  LISP Architecture

   This section presents the LISP architecture, it architecture.  It first details the
   design principles of LISP LISP, and then it proceeds to describe its main
   aspects: data-plane, control-plane, data plane, control plane, and internetworking mechanisms.

3.1.  Design Principles

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

   o

   Locator/Identifier split: By decoupling  Decoupling the overloaded semantics of the
      current IP addresses allows devices to have identity-based
      addresses that are separate from topologically meaningful
      addresses.  By allowing only the Internet core can topologically meaningful
      addresses to be assigned
      identity exposed to the Internet core, those topologically
      meaningful addresses and hence, can use aggregation be aggregated to
      scale.  Devices support substantial
      scaling.  Individual devices are assigned with relatively opaque topologically
      meaningful identity-based addresses
      that are independent of their topological
      location.

   o not used for forwarding in the Internet core.

   Overlay architecture: Overlays  This architecture overlays route packets over
      the current Internet, allowing deployment of new protocols without
      changing the current infrastructure infrastructure; hence, resulting into this results in a low
      deployment cost.

   o

   Decoupled data plane and control-plane: control plane:  Separating the data-plane data plane
      from the control-plane control plane allows them to scale independently and use
      different architectural approaches.  This is important given that
      they typically have different requirements and allows for other
      data-planes
      data planes to be added.  While decoupled,  Even though the data plane and control-plane the
      control plane are decoupled, they are not completely isolated isolated,
      because the LISP data-plane data plane may trigger control-plane control plane activity.

   o

   Incremental deployability:  This principle ensures that the protocol
      interoperates with the legacy Internet while providing some of the
      targeted benefits to early adopters.

3.2.  Overview of the Architecture

   LISP splits architecturally splits the core from the edge of the Internet by
   creating two separate namespaces: Endpoint Identifiers (EIDs) and
   Routing LOCators Locators (RLOCs).  The edge consists of LISP sites (e.g., an
   Autonomous System) that use EID addresses.  EIDs are IPv4 or IPv6
   addresses that uniquely identify communication end-hosts end hosts and are
   assigned and configured by the same mechanisms that exist at the time
   of this writing.  EIDs do not contain inter-domain topological
   information
   information, and because of this, EIDs are usually routable at the
   edge (within LISP sites) or but not in the non-LISP Internet; core; see Section 3.5 for
   discussion of LISP site internetworking with non-LISP sites and
   domains in the Internet.

   LISP sites (at the edge of the Internet) edge) are connected to the interconnecting core of
   the Internet by means of LISP-capable routers (e.g., border routers).
   LISP sites are connected across the interconnecting core of the
   Internet using tunnels between the LISP-capable routers.  When
   packets originated from a LISP site are flowing towards the core
   network, they ingress into an encapsulated tunnel via an Ingress
   Tunnel Router (ITR).  When packets flow from the core network to a
   LISP site, they egress from an encapsulated tunnel to an Egress
   Tunnel Router (ETR).  An xTR is a router which that can perform both ITR
   and ETR operations.  In this
   context context, ITRs encapsulate packets packets, while
   ETRs decapsulate them, hence them; hence, LISP operates as an overlay on top of
   the current Internet core.

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

                Figure 1.- 1: A schema Schema of the LISP Architecture

   With LISP, the core uses RLOCs, an RLOCs.  An RLOC is an IPv4 or IPv6 address
   assigned to an Internet-facing 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 that is typically distributed, called the Mapping System,
   stores mappings between EIDs and RLOCs.  Such mappings relate the
   identity of the devices attached to LISP sites (EIDs) to the set of
   RLOCs configured at the LISP-capable routers servicing the site.
   Furthermore, the mappings also include traffic engineering TE policies and can be
   configured to achieve multihoming and load balancing.  The LISP
   Mapping System is conceptually similar to the DNS DNS, where it is
   organized as a distributed multi-organization network database.  With
   LISP, ETRs register mappings mappings, while ITRs retrieve them.

   Finally, the LISP architecture emphasizes incremental deployment.
   Given that LISP represents an overlay to the current Internet
   architecture, endhosts end hosts, as well as intra intra-domain and inter-domain routers
   routers, remain unchanged, and the unchanged.  The only required changes to the existing
   infrastructure are to routers connecting the EID space with the RLOC
   space.  Additionally, LISP requires the deployment of an independent
   Mapping
   System, System; such a distributed database is a new network entity.

   The following describes a simplified packet flow sequence between two
   nodes that are attached to LISP sites.  Please note that typical
   LISP-capable routers are xTRs (both ITR and ETR).  Client HostA wants
   to send a packet to server HostB.

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

                   Figure 2.- 2: Packet flow sequence Flow Sequence in LISP

   1.  HostA retrieves the EID_B of HostB, typically querying the DNS
       and obtaining an A or AAAA record.  Then  Then, it generates an IP
       packet as in the Internet, the Internet.  The packet has source address EID_A
       and destination address EID_B.

   2.  The packet is routed forwarded towards ITR_A in the LISP site using
       standard intra-domain mechanisms.

   3.  ITR_A  ITR_A, upon receiving the packet packet, queries the Mapping System to
       retrieve the locator Locator of ETR_B that is servicing HostB's EID_B.
       In order to do so so, it uses a LISP control message called Map-
       Request, the
       Request.  The message contains EID_B as the lookup key.  In turn turn,
       it receives another LISP control message called Map-Reply, the Map-Reply.  The
       message contains two locators: Locators: RLOC_B1 and RLOC_B2 along with
       traffic engineering RLOC_B2.  It also
       contains TE policies: priority and weight per locator. Locator.  Note that
       a Map-Reply can contain more locators Locators if needed.  ITR_A
       also stores can cache
       the mapping in a local cache storage to speed-up speed up forwarding of subsequent
       packets.

   4.  ITR_A encapsulates the packet towards RLOC_B1 (chosen according
       to the priorities/weights specified in the mapping).  The packet
       contains two IP headers, the headers.  The outer header has RLOC_A1 as source
       and RLOC_B1 as destination, the destination.  The inner original header has EID_A
       as source and EID_B as destination.  Furthermore  Furthermore, ITR_A adds a
       LISP header, more header.  More details about LISP encapsulation can be found
       in Section 3.3.1.

   5.  The encapsulated packet is forwarded by over the Internet interconnecting
       core as a normal IP packet, making the EID invisible from the Internet
       core.

   6.  Upon reception of the encapsulated packet by ETR_B, it
       decapsulates the packet and forwards it to HostB.

3.3.  Data-Plane  Data Plane

   This section provides a high-level description of the LISP data- data
   plane, which is specified in detail in [RFC6830]. [RFC9300].  The LISP data- data
   plane is responsible for encapsulating and decapsulating data packets
   and caching the appropriate forwarding state.  It includes two main
   entities, the ITR and the ETR, both ETR.  Both are LISP capable LISP-capable routers that
   connect the EID with the RLOC space (ITR) and vice versa (ETR).

3.3.1.  LISP Encapsulation

   ITRs encapsulate data packets towards ETRs.  LISP data packets are
   encapsulated using UDP (port 4341), the 4341).  The source port is usually
   selected by the ITR using a 5-tuple hash of the inner header (so as
   to be consistent in case of multi-path solutions multipath solutions, such as ECMP
   [RFC2992]) and ignored on reception.  LISP data packets are often
   encapsulated in UDP packets that include a zero checksum [RFC6935]
   [RFC6936] that
   is may not be verified when it is received, because LISP
   data packets typically include an inner transport protocol header
   with a non-zero checksum.  By omitting the additional outer  The use of UDP encapsulation
   checksum, xTRs can forward packets more efficiently. zero checksums over IPv6
   for all tunneling protocols like LISP is subject to the applicability
   statement in [RFC6936].  If LISP data packets are encapsulated in UDP
   packets with non-zero checksums, the outer UDP checksums are verified
   when the UDP packets are received, as part of normal UDP processing.

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

   Overall, LISP works on 4 headers, headers: the inner header the source
   constructed,
   constructed and the 3 headers a LISP encapsulator prepends ("outer"
   to "inner"):

   1.  Outer IP header containing RLOCs as source and destination
       addresses.  This header is originated by ITRs and stripped by
       ETRs.

   2.  UDP header (port 4341) 4341), usually with zero checksum.  This header
       is originated by ITRs and stripped by ETRs.

   3.  LISP header that contains various forwarding-plane features (such
       as reachability) and an Instance ID 'Instance ID' field.  This header is
       originated by ITRs and stripped by ETRs.

   4.  Inner IP header containing EIDs as source and destination
       addresses.  This header is created by the source end-host end host and is
       left unchanged by the LISP data plane processing on the ITR and
       ETR.

   Finally, in some scenarios Re-encapsulating scenarios, re-encapsulating and/or Recursive recursive tunnels
   are useful to choose a specified path in the underlay network, for
   instance
   instance, to avoid congestion or failure.  Re-encapsulating tunnels
   are consecutive LISP tunnels and occur when a decapsulator (an ETR
   action) removes a LISP header and then acts as an encapsultor encapsulator (an
   ITR action) to prepend another one.  On the other hand, Recursive recursive
   tunnels are nested tunnels and are implemented by using multiple LISP
   encapsulations on a packet.  Such functions are implemented by
   Reencapsulating Re-
   encapsulating Tunnel Routers (RTRs).  An RTR can be thought of as a
   router that first acts as an ETR by decapsulating packets and then as
   an ITR by encapsulating them towards another locator, Locator; more
   information can be found at [RFC6830]. in [RFC9300] and [RFC9301].

3.3.2.  LISP Forwarding State

   In the LISP architecture, ITRs keep just enough information to route
   traffic flowing through them.  Meaning that,  In other words, ITRs only need to
   retrieve from the LISP Mapping System mappings between EID-prefixes EID-Prefixes
   (blocks of EIDs) and RLOCs that are used to encapsulate packets.
   Such mappings are stored in a local cache called the LISP Map-Cache
   for subsequent packets addressed to the same EID prefix. EID-Prefix.  Note that, that
   in the case of overlapping
   EID-prefixes, following EID-Prefixes, after a single request, the ITR may
   receive a set of mappings, mappings covering the requested EID-prefix EID-Prefix and all more-specifics
   more-specific EID-Prefixes (cf., Section 6.1.5 [RFC6830]). 5.5 of [RFC9301]).  Mappings
   include a (Time-to-Live)
   TTL Time to Live (TTL) (set by the ETR).  More details about
   the Map-Cache management can be found in Section 4.1.

3.4.  Control-Plane  Control Plane

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

3.4.1.  LISP Mappings

   Each mapping includes the bindings between EID prefix(es) EID-Prefix(es) and a set
   of RLOCs as well as traffic engineering TE policies, in the form of priorities and
   weights for the RLOCs.  Priorities allow the ETR to configure active/backup policies active/
   backup policies, while weights are used to load-
   balance load-balance traffic among
   the RLOCs (on a per-flow basis).

   Typical mappings in LISP bind EIDs in the form of IP prefixes with a
   set of RLOCs, also in the form of IPs. IP addresses.  IPv4 and IPv6
   addresses are encoded using the appropriate Address Family Identifier
   (AFI)
   [RFC3232].  However [RFC8060].  However, LISP can also support more general address
   encoding by means of the ongoing effort around the LISP Canonical
   Address Format (LCAF) [I-D.ietf-lisp-lcaf]. [RFC8060].

   With such a general syntax for address encoding in place, LISP aims
   to provide flexibility to current and future applications.  For
   instance
   instance, LCAFs could support MAC Media Access Control (MAC) addresses, geo-coordinates,
   geocoordinates, ASCII
   names names, and application specific application-specific data.

3.4.2.  Mapping System Interface

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

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

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

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

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

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

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

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

3.4.3.  Mapping System

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

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

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

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

3.4.3.1.  LISP+ALT

   The LISP Alternative Topology (LISP+ALT)  LISP-ALT

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

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

3.4.3.2.  LISP-DDT

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

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

       Figure 3.- 3: A schematic representation Schematic Representation of the DDT tree structure,
                please Tree Structure

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

   The DDT structure does not actually index EID-prefixes but eXtended
   EID-prefixes (XEID). EID-Prefixes; rather, it
   indexes Extended EID-Prefixes (XEID-Prefixes).  An XEID-prefix XEID-Prefix is
   just the concatenation of the following fields (from most significant
   bit to less significant bit): bits): Database-ID, Instance ID, Address
   Family Identifier Identifier, and the actual
   EID-prefix. 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 query, LISP-DDT operates in a similar way to
   the DNS but only supports iterative lookups.  DDT clients (usually Map-
   Resolvers)
   Map-Resolvers) generate Map-Requests to the DDT root node.  In response
   response, they receive a newly introduced LISP-control 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.
   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 point, the client sends a Map-Request and
   receives a Map-Reply containing the mappings.  It is important to
   note that DDT clients can also cache the information contained in
   Map-Referrals,
   Map-Referrals; that is, they cache the DDT structure.  This is used
   to reduce the mapping retrieving latency[Jakab]. time required to retrieve mappings [Jakab].

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

3.5.  Internetworking Mechanisms

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

   LISP defines two entities to provide internetworking:

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

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

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

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

4.  LISP Operational Mechanisms

   This section details the main operational mechanisms defined in LISP.

4.1.  Cache Management

   LISP's decoupled control and data-plane, data planes, where mappings are stored
   in the control-plane control plane and used for forwarding in the data plane, requires
   require a local cache in ITRs to reduce signaling overhead (Map-Request/Map-
   Reply) (Map-
   Request/Map-Reply) and increase forwarding speed.  The local cache
   available at the ITRs, called Map-Cache, is used by the router to
   LISP-encapsulate packets.  The Map-Cache is indexed by (Instance ID, EID-prefix)
   EID-Prefix) and contains basically the set of RLOCs with the
   associated traffic
   engineering TE policies (priorities and weights).

   The Map-Cache, as with any other cache, requires cache coherence
   mechanisms to maintain up-to-date information.  LISP defines three
   main mechanisms for cache coherence:

   Time-To-Live

   Record Time To Live (TTL):  Each mapping record contains a TTL set by
      the ETR, upon ETR.  Upon expiration of the TTL TTL, the ITR can't use the
      mapping until it is refreshed by sending a new Map-Request.  Typical values for TTL
      defined by LISP are 24 hours.

   Solicit-Map-Request (SMR):  SMR is an explicit mechanism to update
      mapping information.  In particular particular, a special type of Map-Request
      can be sent on demand by ETRs to request refreshing a mapping.
      Upon reception of a an SMR message, the ITR must refresh the
      bindings by sending a Map-Request to the Mapping System.  Further
      uses of SMRs are documented in [RFC6830]. [RFC9301].

   Map-Versioning:  This optional mechanism piggybacks piggybacks, in the LISP
      header of data-packets data packets, the version number of the mappings used by
      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
      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
      newest mappings.  On the contrary, if it detects that the remote
      xTR Map-
      Cache Map-Cache is outdated, it sends a an SMR to notify it that a new
      mapping is available.

   Finally  Further details are available in [RFC9302].

   Finally, it is worth noting that that, in some cases cases, an entry in the map-
   cache Map-
   Cache can be proactively refreshed using the mechanisms described in
   the section below.

4.2.  RLOC Reachability

   In most cases cases, LISP operates with a pull-based Mapping System (e.g.,
   DDT), this
   DDT).  This results in an edge to edge edge-to-edge pull architecture.  In such
   scenario a
   scenario, the network state is stored in the control-plane control plane while the
   data-plane
   data plane pulls it on demand.  This has consequences concerning the
   propagation of xTRs xTRs' reachability/liveness information information, since pull
   architectures require explicit mechanisms to propagate this
   information.  As a result result, LISP defines a set of mechanisms to inform
   ITRs and PITRS PITRs about the reachability of the cached RLOCs:

   Locator Status Bits (LSB): LSB

   Locator-Status-Bits (LSBs):  Using LSBs is a passive technique, the LSB technique.  The
      'LSB' field is carried by data-packets data packets in the LISP header and can
      be set by a 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
      reachability to perform additional checks.  Also note that LSB does LSBs do
      not provide path reachability status, status; they only provide hints on
      about the status of RLOCs.

   Echo-nonce:  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, technique that can only operate
      effectively when data flows bi-directionally bidirectionally between two
      communicating xTRs.  Basically, an ITR piggybacks a random number
      (called a nonce) in LISP data packets, if packets.  If the path and the probed
   locator
      Locator are up, the ETR will piggyback the same random number on
      the next data-packet, data packet; if this is not the case case, the ITR can set the locator
      Locator as unreachable.  When traffic flow is unidirectional or
      when the ETR receiving the traffic is not the same as the ITR that
      transmits it back, additional mechanisms are required.

   RLOC-probing:  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
      probes to specific locators, this Locators.  This effectively probes both the locator
      Locator and the path.  In particular particular, this is done by sending a
      Map-Request (with certain flags activated) on the data-plane data plane (RLOC
      space) and then waiting in return for a Map-Reply, also Map-Reply (also sent on the data-plane. data
      plane).  The active nature of RLOC-probing RLOC-Probing provides an effective
      mechanism to
   determine for determining reachability and, in case of failure,
      switching to a different locator.  Furthermore Locator.  Furthermore, the mechanism also
      provides useful RTT estimates of the delay of the path that can be
      used by other network algorithms.

   It is worth noting that RLOC probing RLOC-Probing and Echo-nonce the Echo-Nonce can work
   together.  Specifically  Specifically, if a nonce is not echoed, an ITR could RLOC-
   probe to determine if the path is up when it cannot tell the
   difference between a failed bidirectional path or the return
   determine which path is
   not used (a unidirectional path). direction has failed.  In this scenario, an ITR
   can use RLOC-Probing.

   Additionally, LISP also recommends inferring the reachability of locators
   Locators by using information provided by the underlay, in particular: particularly:

   ICMP signaling:  The LISP underlay -the -- the current Internet- Internet -- uses the
      ICMP protocol to signal unreachability (among other things).  LISP can take
      advantage of this this, and the reception of a an ICMP Network
      Unreachable or ICMP Host Unreachable message can be seen as a hint
      that a locator Locator might be unreachable, this unreachable.  This should lead to perform
      performing additional checks.

   Underlay routing:  Both BGP and IBGP IGP carry reachability information, information.
      LISP-capable routers that have access to underlay routing
      information can use it to determine if a given locator Locator or path are is
      reachable.

4.3.  ETR Synchronization

   All the ETRs that are authoritative to a particular EID-prefix EID-Prefix must
   announce the same mapping to the requesters, this requesters.  This means that ETRs
   must be aware of the status of the RLOCs of the remaining ETRs.  This
   is known as ETR synchronization.

   At the time of this writing writing, LISP does not specify a mechanism to
   achieve ETR synchronization.  Although many well-known techniques
   could be applied to solve this issue issue, it is still under research, as research.  As
   a
   result result, operators must rely on coherent manual configuration configuration.

4.4.  MTU Handling

   Since LISP encapsulates packets packets, it requires dealing with packets
   that exceed the MTU of the path between the ITR and the ETR.  Specifically
   Specifically, LISP defines two mechanisms:

   Stateless:  With this mechanism mechanism, the effective MTU is assumed from
      the ITR's perspective.  If a payload packet is too big for the
      effective MTU, MTU and can be fragmented, the payload packet is
      fragmented on the ITR, such that reassembly is performed at the
      destination host.

   Stateful:  With this mechanism mechanism, ITRs keep track of the MTU of the
      paths towards the destination locators Locators by parsing the ICMP Too Big
      packets sent by intermediate routers.  ITRs will send ICMP Too Big
      messages to inform the sources about the effective MTU.

      Additionally
      Additionally, ITRs can use mechanisms such as PMTUD Path MTU Discovery
      (PMTUD) [RFC1191] or
      PLPMTUD Packetization Layer Path MTU Discovery
      (PLPMTUD) [RFC4821] to keep track of the MTU towards the locators. Locators.

   In both cases cases, if the packet cannot be fragmented (IPv4 with DF=1 or
   IPv6)
   IPv6), then the ITR drops it and replies with a an ICMP Too Big message
   to the source.

5.  Mobility

   The separation between locators Locators and identifiers in LISP is suitable
   for traffic engineering purpose TE purposes where LISP sites can change their attachment points
   to the Internet (i.e., RLOCs) without impacting endpoints or the
   Internet core.  In this context, the border routers operate the xTR functionality
   functionality, and endpoints are not aware of the existence of LISP.
   This functionality is similar to Network Mobility [RFC3963].
   However, this mode of operation does not allow seamless mobility of
   endpoints between different LISP sites sites, as the EID address might not
   be routable in a visited site.  Nevertheless, LISP can be used to
   enable seamless IP mobility when LISP is directly implemented in the
   endpoint or when the endpoint roams to an attached xTR.  Each
   endpoint is then an xTR xTR, and the EID address is the one presented to
   the network stack used by applications while the RLOC is the address
   gathered from the network when it is visited.  This functionality is
   similar to Mobile IP ([RFC5944] and [RFC6275]).

   Whenever the a device changes of its RLOC, the xTR updates the RLOC of its
   local mapping and registers it to its Map-Server, typically with a
   low TTL value (1min). (1 min).  To avoid the need of for a home gateway, the ITR
   also indicates the RLOC change to all remote devices that have
   ongoing communications with the device that moved.  The combination
   of both methods ensures the scalability of the system system, as signaling
   is strictly limited to the Map-Server and to hosts with which
   communications are ongoing.  In the mobility case case, the EID-prefix EID-Prefix can
   be as small as a full /32 or /128 (IPv4 or IPv6 respectively) IPv6, respectively),
   depending on the specific use-case use case (e.g., subnet mobility vs vs. single
   VM/Mobile node mobility).

   The decoupled identity and location provided by LISP allows allow it to
   operate with other layer Layer 2 and layer Layer 3 mobility solutions.

6.  Multicast

   LISP also supports transporting IP multicast packets sent from the
   EID space, the space.  The required operational changes required to the multicast
   protocols are documented in [RFC6831].

   In such scenarios, LISP may create multicast state both at the core
   and at the sites (both source and receiver).  When signaling is used
   to create multicast state at the sites, LISP routers unicast encapsulate PIM
   Join/Prune messages from receiver to source sites. sites as unicast packets.
   At the core, ETRs build a new PIM Join/Prune message addressed to the
   RLOC of the ITR servicing the source.  An  A simplified sequence is shown below
   below.

   1.  An end-host end host willing to join a multicast channel sends an IGMP
       report.  Multicast PIM routers at the LISP site propagate PIM
       Join/Prune messages (S-EID, G) towards the ETR.

   2.  The join Join message flows to the ETR, upon reception ETR.  Upon reception, the ETR
       builds two join messages, the Join messages.  The first one unicast LISP-encapsulates LISP-
       encapsulates the original join Join message towards the RLOC of the
       ITR servicing the source.  This message creates (S-EID, G)
       multicast state at the source site.  The second join Join message contains
       contains, as a destination
       address address, the RLOC of the ITR servicing
       the source (S-RLOC, G) and creates multicast state at the core.

   3.  Multicast data packets originated by the source (S-EID, G) flow
       from the source to the ITR.  The ITR LISP-encapsulates the
       multicast packets, the outter packets.  The outer header includes its own RLOC as the
       source (S-RLOC) and the original multicast group address (G) as
       the destination.  Please note that multicast group address addresses are
       logical and are not resolved by the mapping system.  Then Mapping System.  Then, the
       multicast packet is packets are transmitted through the core towards the
       receiving ETRs that decapsulates ETRs, which decapsulate the packets and sends forward them
       using the receiver's site receiver site's multicast state.

   Please note that the inner and outer multicast addresses are in
   general
   generally different, unless except in specific cases where the underlay
   provider implements a tight control on the overlay.  LISP
   specifications already support all PIM modes [RFC6831].
   Additionally, LISP can also support as well non-PIM mechanisms in order to
   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.1.  Traffic Engineering

   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 ETR
   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
   traffic to a LISP site, it retrieves the mapping associated to with the
   destination EID via the mapping system. Mapping System.  The mapping is sent directly
   by an authoritative ETR of the EID and is not altered by any
   intermediate network.

   A mapping associates a list of RLOCs to with an EID prefix. EID-Prefix.  Each RLOC
   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
   tagged with a priority and a weight in the mapping.  The priority is
   used to indicates indicate which RLOCs should be preferred to send for sending packets
   (the least preferred ones being provided for backup purpose). purposes).  The
   weight permits to balance balancing the load between the RLOCs with the same
   priority, proportionally in proportion to the weight value.

   As mappings are directly issued by the authoritative ETR of the EID
   and are not altered while when transmitted to the remote site, it offers
   highly flexible incoming inter-domain traffic engineering with TE and even
   the possibility makes it possible
   for a site to support a different mapping policy for each remote
   site.  routing policies.

7.2.  LISP for IPv6 Co-existence

   LISP encapsulations allows to transport allow transporting packets using EIDs from a
   given address family (e.g., IPv6) with packets from other address
   families (e.g., IPv4).  The absence of correlation between the
   address family 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
   IPv6 enabled.

   For example, two IPv6-only data centers could be interconnected via
   the legacy IPv4 Internet.  If their border routers are LISP capable,
   sending packets between the data center centers is done without any form of
   translation
   translation, as the native original IPv6 packets (in the EID space) will be
   LISP encapsulated and transmitted over the IPv4 legacy Internet by
   the mean of via
   IPv4 RLOCs.

7.3.  LISP for Virtual Private Networks

   It is common to operate several virtual networks over the same
   physical infrastructure.  In such virtual private networks, it is
   essential
   determining to distinguish which virtual network a packet belongs and is essential;
   tags or labels are used for that purpose.  When using LISP, the
   distinction can be made with the Instance ID 'Instance ID' field.  When an ITR
   encapsulates a packet from a particular virtual network (e.g., known
   via the VRF Virtual Routing and Forwarding (VRF) or the VLAN), it tags the
   encapsulated packet with the Instance ID corresponding to the virtual
   network of the packet.  When an ETR receives a packet tagged with an
   Instance ID ID, it uses the Instance ID to determine how to treat the
   packet.

   The main usage of LISP for virtual private networks does not
   introduce additional requirements on the underlying network, as long
   as it is running runs IP.

7.4.  LISP for Virtual Machine Mobility in Data Centers

   A way to enable seamless virtual machine (VM) mobility in the data
   center is to conceive the datacenter data center backbone as the RLOC space and
   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.
   When a
   virtual machine VM is moved to another subnet, it can keep (temporarily) the
   address it had before the move so as to continue without a transport transport-
   layer connection reset.  When an xTR detects a source address
   received on a subnet to be an address not assigned to the subnet, it
   registers the address to the Mapping System.

   To inform the other LISP routers that the machine moved and where,
   and then to avoid detours via the initial subnetwork, mechanisms such
   as the Solicit-Map-Request messages are used.

8.  Security Considerations

   This section describes the security considerations associated to the
   LISP protocol.

   While in with
   LISP.

   In a push mapping system, Mapping System, the state necessary to forward packets is
   learned independently of the traffic itself, itself.  However, with a pull
   architecture, the system becomes reactive reactive, and data-plane data plane events
   (e.g., the arrival of a packet for with an unknown destination) destination address)
   may trigger control-plane control plane events.  This on-demand learning of
   mappings provides many advantages advantages, as discussed above above, but may also
   affect the way security is enforced.

   Usually, the data-plane data plane is implemented in the fast path of routers to
   provide high performance high-performance forwarding capabilities capabilities, while the control- control
   plane features are implemented in the slow path to offer high
   flexibility
   flexibility, and a performance gap of several order orders of magnitude can
   be observed between the slow and the fast paths.  As a consequence, the
   way data-plane events are notified to notify the control-plane control plane of data plane events must be
   thought
   considered carefully so to as not to overload the slow path path, and rate
   limiting should be used as specified in [RFC6830]. [RFC9300] and [RFC9301].

   Care must also be taken so to not to overload the mapping system Mapping System (i.e., the
   control plane infrastructure) infrastructure), as the operations to be performed by
   the mapping system Mapping System may be more complex than those on the data-
   plane, for data plane.
   For that reason [RFC6830] recommends to reason, [RFC9300] and [RFC9301] recommend rate limit limiting the
   sending of messages to the mapping system. Mapping System.

   To improve resiliency and reduce the overall number of messages
   exchanged, LISP offers the possibility makes it possible to leak certain information, such
   as
   reachabilty the reachability of locators, Locators, directly into data plane packets.
   In environments that are not fully trusted, like the open Internet,
   control information gleaned from data-plane data plane packets should must not be used
   or must be verified before using them. it.

   Mappings are the centrepiece centerpiece of LISP LISP, and all precautions must be
   taken to avoid them to be manipulated or misused by prevent malicious
   entities. entities from manipulating or misusing
   them.  Using trustable Map-Servers that strictly respect
   [RFC6833] [RFC9301]
   and the lightweight authentication mechanism proposed by
   LISP-Sec [I-D.ietf-lisp-sec] LISP-SEC [RFC9303]
   reduces the risk of attacks to the on mapping integrity.  In more critical
   environments, secure measures may be needed.  The way security is
   implemented for a given mapping
   system Mapping System strongly depends on the
   architecture of the mapping system Mapping System itself and the threat model
   assumed for the deployment.  Thus, the
   mapping system Mapping System security has to be
   discussed in the relevant documents proposing the mapping system Mapping System
   architecture.

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

   Like other map-and-encap mechanisms, LISP enables triangular routing
   (i.e., packets of a flow cross different border routers routers, depending on
   their direction).  This means that intermediate boxes may have an
   incomplete view on of the traffic they inspect or manipulate.  Moreover,
   LISP-encapsulated packets are routed based on the outer IP address
   (i.e., the RLOC), RLOC) and can be delivered to an ETR that is not
   responsible of for the destination EID of the packet or even delivered
   to a network element that is not an ETR.  The mitigation  Mitigation consists in of
   applying appropriate filtering techniques on the network elements
   that can potentially receive un-expected unexpected LISP-encapsulated packets packets.

   More details about security implications of LISP are discussed in
   [I-D.ietf-lisp-threats].
   [RFC7835].

9.  IANA Considerations

   This memo includes no request to IANA.

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. no IANA actions.

10.  References

11.1.

10.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]
              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]
              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,
              DOI 10.17487/RFC1191, November 1990. 1990,
              <https://www.rfc-editor.org/info/rfc1191>.

   [RFC1918]  Rekhter, Y., Moskowitz, R., B., Karrenberg, D., de Groot, G., G.
              J., and E. Lear, "Address Allocation for Private
              Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
              February 1996. 1996, <https://www.rfc-editor.org/info/rfc1918>.

   [RFC2992]  Hopps, C., "Analysis of an Equal-Cost Multi-Path
              Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000.

   [RFC3232]  Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
              an On-line Database", RFC 3232, January 2002. 2000,
              <https://www.rfc-editor.org/info/rfc2992>.

   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
              RFC 3963, DOI 10.17487/RFC3963, January 2005. 2005,
              <https://www.rfc-editor.org/info/rfc3963>.

   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
              Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007. 2007,
              <https://www.rfc-editor.org/info/rfc4821>.

   [RFC4984]  Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
              from the IAB Workshop on Routing and Addressing",
              RFC 4984, DOI 10.17487/RFC4984, September
              2007. 2007,
              <https://www.rfc-editor.org/info/rfc4984>.

   [RFC5944]  Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
              RFC 5944, DOI 10.17487/RFC5944, November 2010. 2010,
              <https://www.rfc-editor.org/info/rfc5944>.

   [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
              Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011.

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830, January
              2013.
              2011, <https://www.rfc-editor.org/info/rfc6275>.

   [RFC6831]  Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
              Locator/ID Separation Protocol (LISP) for Multicast
              Environments", RFC 6831, DOI 10.17487/RFC6831, January 2013.
              2013, <https://www.rfc-editor.org/info/rfc6831>.

   [RFC6832]  Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking between Locator/ID Separation Protocol
              (LISP) and Non-LISP Sites", RFC 6832,
              DOI 10.17487/RFC6832, January 2013.

   [RFC6833]  Fuller, V. and D. Farinacci, "Locator/ID Separation
              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. 2013,
              <https://www.rfc-editor.org/info/rfc6832>.

   [RFC6835]  Farinacci, D. and D. Meyer, "The Locator/ID Separation
              Protocol Internet Groper (LIG)", RFC 6835,
              DOI 10.17487/RFC6835, January 2013. 2013,
              <https://www.rfc-editor.org/info/rfc6835>.

   [RFC6836]  Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol Alternative Logical
              Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
              January 2013. 2013, <https://www.rfc-editor.org/info/rfc6836>.

   [RFC6837]  Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
              Routing Locator (RLOC) Database", RFC 6837,
              DOI 10.17487/RFC6837, January 2013. 2013,
              <https://www.rfc-editor.org/info/rfc6837>.

   [RFC6935]  Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
              UDP Checksums for Tunneled Packets", RFC 6935,
              DOI 10.17487/RFC6935, April 2013. 2013,
              <https://www.rfc-editor.org/info/rfc6935>.

   [RFC6936]  Fairhurst, G. and M. Westerlund, "Applicability Statement
              for the Use of IPv6 UDP Datagrams with Zero Checksums",
              RFC 6936, DOI 10.17487/RFC6936, April 2013. 2013,
              <https://www.rfc-editor.org/info/rfc6936>.

   [RFC7052]  Schudel, G., Jain, A., and V. Moreno, "Locator/ID
              Separation Protocol (LISP) MIB", RFC 7052,
              DOI 10.17487/RFC7052, October 2013. 2013,
              <https://www.rfc-editor.org/info/rfc7052>.

   [RFC7215]  Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
              Pascual, J., and D. Lewis, "Locator/Identifier Separation
              Protocol (LISP) Network Element Deployment
              Considerations", RFC 7215, DOI 10.17487/RFC7215, April 2014.

11.2.  Informative References

   [DDT-ROOT]
              LISP DDT ROOT, , "http://ddt-root.org/", August 2013.

   [I-D.cheng-lisp-shdht]
              Cheng, L.
              2014, <https://www.rfc-editor.org/info/rfc7215>.

   [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>.

   [RFC8060]  Farinacci, D., Meyer, D., and J. Wang, Snijders, "LISP Single-Hop DHT Mapping
              Overlay", draft-cheng-lisp-shdht-04 (work in progress),
              July 2013.

   [I-D.curran-lisp-emacs]
              Brim, S., Canonical
              Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
              February 2017, <https://www.rfc-editor.org/info/rfc8060>.

   [RFC8111]  Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
              Smirnov, "Locator/ID Separation Protocol Delegated
              Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
              May 2017, <https://www.rfc-editor.org/info/rfc8111>.

   [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 J. Curran, "EID
              Mappings Multicast Across Cooperating Systems for LISP",
              draft-curran-lisp-emacs-00 (work in progress), November
              2007. 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, Cabellos-Aparicio, A., Coras, F., Saucez, D.,
              and O. Bonaventure, "LISP-TREE: A DNS Hierarchy to Support
              the LISP Mapping
              System, System", IEEE Journal on Selected Areas
              in Communications, vol. 28, no. 8, pp. 1332-1343", 1332-1343,
              DOI 10.1109/JSAC.2010.101011, October 2010. 2010,
              <https://ieeexplore.ieee.org/document/5586446>.

   [LISP-EMACS]
              Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID
              Mappings Multicast Across Cooperating Systems for LISP",
              Work in Progress, Internet-Draft, draft-curran-lisp-emacs-
              00, 9 November 2007, <https://www.ietf.org/archive/id/
              draft-curran-lisp-emacs-00.txt>.

   [LISP-SHDHT]
              Cheng, L. and M. Sun, "LISP Single-Hop DHT Mapping
              Overlay", Work in Progress, Internet-Draft, draft-cheng-
              lisp-shdht-04, 15 July 2013,
              <https://www.ietf.org/archive/id/draft-cheng-lisp-shdht-
              04.txt>.

   [Mathy]    Mathy, L., Iannone, L., L. and O. Bonaventure, L. Iannone, "LISP-DHT: Towards a DHT to map
              identifiers onto locators.  The locators", CoNEXT '08: Proceedings of the
              2008 ACM
              ReArch, CoNEXT Conference, ReArch '08 - Re-Architecting
              the Internet. Madrid (Spain)", Internet, DOI 10.1145/1544012.1544073, December 2008. 2008,
              <https://dl.acm.org/doi/10.1145/1544012.1544073>.

   [Quoitin]  Quoitin, B., Iannone, L., de Launois, C., and O.
              Bonaventure,
              ""Evaluating "Evaluating the Benefits of the Locator/Identifier
              Separation" in Locator/
              Identifier Separation", Proceedings of 2Nd 2nd ACM/IEEE
              International Workshop on Mobility in the Evolving
              Internet
              Architecture", 2007. 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

   The LISP architecture for separation of location and identity
   resulted from the discussions of this topic at the Amsterdam IAB
   Routing and Addressing Workshop, which took place in October 2006
   [RFC4984].

   A small group of like-minded personnel spontaneously formed
   immediately after that workshop, workshop to work on an idea that came out of
   informal discussions at the workshop and on various mailing lists.
   The first Internet-Draft on LISP appeared in January, January 2007.

   Trial implementations started at that time, with initial trial
   deployments underway since June 2007; the results of early experience
   have been fed back into the design in a continuous, ongoing process
   over several years.  LISP at  At this point point, LISP represents a moderately
   mature system, having undergone a long long, organic series of changes and
   updates.

   LISP transitioned from an IRTF activity to an IETF WG in March 2009,
   and after 2009.
   After numerous revisions, the basic specifications moved to becoming
   RFCs at the start of 2013 (although 2013; work to expand and
   improve it, expand, improve, and find new uses
   for it, continues, and undoubtly it continues (and undoubtedly will for a long time to come).  The
   LISP WG was rechartered in 2018 to continue work on the LISP base
   protocol and produce Standards Track documents.

A.1.  Old LISP Models

   LISP, as initially conceived, had a number of potential operating
   modes, named 'models'.  Although they are no not used anymore, one
   occasionally sees mention of them, so they are briefly described
   here.

   LISP 1:  EIDs all appear in the normal routing and forwarding tables
      of the network (i.e. (i.e., they are 'routable');this 'routable').  This property is used
      to
      'bootstrap' operation, by using this to load EID->RLOC mappings. EID-to-RLOC mappings via bootstrapping operations.
      Packets were are sent with the EID as the destination in the outer
      wrapper; when an ETR saw sees such a packet, it would send sends a Map-Reply to
      the source ITR, giving the full mapping.

   LISP 1.5:  Similar  LISP 1.5 is similar to LISP 1, but the routability of EIDs
      happens on a separate network.

   LISP 2:  EIDs are not routable; EID->RLOC EID-to-RLOC mappings are available
      from the DNS.

   LISP 3:  EIDs are not routable; routable and have to be looked up in in a new
      EID->RLOC EID-
      to-RLOC mapping database (in the initial concept, a system using
      Distributed Hash Tables).  Two variants were possible: a 'push'
      system,
      system in which all mappings were distributed to all ITRs, ITRs and a
      'pull' system in which ITRs load the mappings when they need, as
      needed. need them.

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

   Albert Cabellos
   UPC-BarcelonaTech
   Universitat Politecnica de Catalunya
   c/ Jordi Girona 1-3
   Barcelona, Catalonia s/n
   08034 Barcelona
   Spain
   Email: acabello@ac.upc.edu

   Damien Saucez (Ed.)
   INRIA (editor)
   Inria
   2004 route des Lucioles - BP 93
   Sophia Antipolis Cedex  06902
   France
   Email: damien.saucez@inria.fr