Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6830

The Locator/ID Separation Protocol (LISP)

Pages: 75
Obsoleted by:  93009301
Updated by:  8113
Part 1 of 4 – Pages 1 to 14
None   None   Next

Top   ToC   RFC6830 - Page 1
Internet Engineering Task Force (IETF)                      D. Farinacci
Request for Comments: 6830                                 Cisco Systems
Category: Experimental                                         V. Fuller
ISSN: 2070-1721
                                                                D. Meyer
                                                                D. Lewis
                                                           Cisco Systems
                                                            January 2013


               The Locator/ID Separation Protocol (LISP)

Abstract

This document describes a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. The Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a "flag day", and offers Traffic Engineering, multihoming, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6830.
Top   ToC   RFC6830 - Page 2
Copyright Notice

   Copyright (c) 2013 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) 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 BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

1. Introduction ....................................................3 2. Requirements Notation ...........................................5 3. Definition of Terms .............................................5 4. Basic Overview .................................................10 4.1. Packet Flow Sequence ......................................13 5. LISP Encapsulation Details .....................................15 5.1. LISP IPv4-in-IPv4 Header Format ...........................16 5.2. LISP IPv6-in-IPv6 Header Format ...........................17 5.3. Tunnel Header Field Descriptions ..........................18 5.4. Dealing with Large Encapsulated Packets ...................22 5.4.1. A Stateless Solution to MTU Handling ...............22 5.4.2. A Stateful Solution to MTU Handling ................23 5.5. Using Virtualization and Segmentation with LISP ...........24 6. EID-to-RLOC Mapping ............................................25 6.1. LISP IPv4 and IPv6 Control-Plane Packet Formats ...........25 6.1.1. LISP Packet Type Allocations .......................27 6.1.2. Map-Request Message Format .........................27 6.1.3. EID-to-RLOC UDP Map-Request Message ................30 6.1.4. Map-Reply Message Format ...........................31 6.1.5. EID-to-RLOC UDP Map-Reply Message ..................35 6.1.6. Map-Register Message Format ........................37 6.1.7. Map-Notify Message Format ..........................39 6.1.8. Encapsulated Control Message Format ................41 6.2. Routing Locator Selection .................................42 6.3. Routing Locator Reachability ..............................44 6.3.1. Echo Nonce Algorithm ...............................46 6.3.2. RLOC-Probing Algorithm .............................48 6.4. EID Reachability within a LISP Site .......................49 6.5. Routing Locator Hashing ...................................49
Top   ToC   RFC6830 - Page 3
      6.6. Changing the Contents of EID-to-RLOC Mappings .............50
           6.6.1. Clock Sweep ........................................51
           6.6.2. Solicit-Map-Request (SMR) ..........................52
           6.6.3. Database Map-Versioning ............................53
   7. Router Performance Considerations ..............................54
   8. Deployment Scenarios ...........................................55
      8.1. First-Hop/Last-Hop Tunnel Routers .........................56
      8.2. Border/Edge Tunnel Routers ................................56
      8.3. ISP Provider Edge (PE) Tunnel Routers .....................57
      8.4. LISP Functionality with Conventional NATs .................58
      8.5. Packets Egressing a LISP Site .............................58
   9. Traceroute Considerations ......................................58
      9.1. IPv6 Traceroute ...........................................59
      9.2. IPv4 Traceroute ...........................................60
      9.3. Traceroute Using Mixed Locators ...........................60
   10. Mobility Considerations .......................................61
      10.1. Site Mobility ............................................61
      10.2. Slow Endpoint Mobility ...................................61
      10.3. Fast Endpoint Mobility ...................................61
      10.4. Fast Network Mobility ....................................63
      10.5. LISP Mobile Node Mobility ................................64
   11. Multicast Considerations ......................................64
   12. Security Considerations .......................................65
   13. Network Management Considerations .............................67
   14. IANA Considerations ...........................................67
      14.1. LISP ACT and Flag Fields .................................67
      14.2. LISP Address Type Codes ..................................68
      14.3. LISP UDP Port Numbers ....................................68
      14.4. LISP Key ID Numbers ......................................68
   15. Known Open Issues and Areas of Future Work ....................68
   16. References ....................................................70
      16.1. Normative References .....................................70
      16.2. Informative References ...................................71
   Appendix A. Acknowledgments .......................................74

1. Introduction

This document describes the Locator/Identifier Separation Protocol (LISP), which provides a set of functions for routers to exchange information used to map from Endpoint Identifiers (EIDs) that are not globally routable to routable Routing Locators (RLOCs). It also defines a mechanism for these LISP routers to encapsulate IP packets addressed with EIDs for transmission across a network infrastructure that uses RLOCs for routing and forwarding.
Top   ToC   RFC6830 - Page 4
   Creation of LISP was initially motivated by discussions during the
   IAB-sponsored Routing and Addressing Workshop held in Amsterdam in
   October 2006 (see [RFC4984]).  A key conclusion of the workshop was
   that the Internet routing and addressing system was not scaling well
   in the face of the explosive growth of new sites; one reason for this
   poor scaling is the increasing number of multihomed sites and other
   sites that cannot be addressed as part of topology-based or provider-
   based aggregated prefixes.  Additional work that more completely
   describes the problem statement may be found in [RADIR].

   A basic observation, made many years ago in early networking research
   such as that documented in [CHIAPPA] and [RFC4984], is that using a
   single address field for both identifying a device and for
   determining where it is topologically located in the network requires
   optimization along two conflicting axes: for routing to be efficient,
   the address must be assigned topologically; for collections of
   devices to be easily and effectively managed, without the need for
   renumbering in response to topological change (such as that caused by
   adding or removing attachment points to the network or by mobility
   events), the address must explicitly not be tied to the topology.

   The approach that LISP takes to solving the routing scalability
   problem is to replace IP addresses with two new types of numbers:
   Routing Locators (RLOCs), which are topologically assigned to network
   attachment points (and are therefore amenable to aggregation) and
   used for routing and forwarding of packets through the network; and
   Endpoint Identifiers (EIDs), which are assigned independently from
   the network topology, are used for numbering devices, and are
   aggregated along administrative boundaries.  LISP then defines
   functions for mapping between the two numbering spaces and for
   encapsulating traffic originated by devices using non-routable EIDs
   for transport across a network infrastructure that routes and
   forwards using RLOCs.  Both RLOCs and EIDs are syntactically
   identical to IP addresses; it is the semantics of how they are used
   that differs.

   This document describes the protocol that implements these functions.
   The database that stores the mappings between EIDs and RLOCs is
   explicitly a separate "module" to facilitate experimentation with a
   variety of approaches.  One database design that is being developed
   for experimentation as part of the LISP working group work is
   [RFC6836].  Others that have been described include [CONS], [EMACS],
   and [RFC6837].  Finally, [RFC6833] documents a general-purpose
   service interface for accessing a mapping database; this interface is
   intended to make the mapping database modular so that different
   approaches can be tried without the need to modify installed LISP-
   capable devices in LISP sites.
Top   ToC   RFC6830 - Page 5
   This experimental specification has areas that require additional
   experience and measurement.  It is NOT RECOMMENDED for deployment
   beyond experimental situations.  Results of experimentation may lead
   to modifications and enhancements of protocol mechanisms defined in
   this document.  See Section 15 for specific, known issues that are in
   need of further work during development, implementation, and
   experimentation.

   An examination of the implications of LISP on Internet traffic,
   applications, routers, and security is for future study.  This
   analysis will explain what role LISP can play in scalable routing and
   will also look at scalability and levels of state required for
   encapsulation, decapsulation, liveness, and so on.

2. Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. Definition of Terms

Provider-Independent (PI) Addresses: PI addresses are an address block assigned from a pool where blocks are not associated with any particular location in the network (e.g., from a particular service provider) and are therefore not topologically aggregatable in the routing system. Provider-Assigned (PA) Addresses: PA addresses are an address block assigned to a site by each service provider to which a site connects. Typically, each block is a sub-block of a service provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and is aggregated into the larger block before being advertised into the global Internet. Traditionally, IP multihoming has been implemented by each multihomed site acquiring its own globally visible prefix. LISP uses only topologically assigned and aggregatable address blocks for RLOCs, eliminating this demonstrably non-scalable practice. Routing Locator (RLOC): An RLOC is an IPv4 [RFC0791] or IPv6 [RFC2460] address of an Egress Tunnel Router (ETR). An RLOC is the output of an EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site.
Top   ToC   RFC6830 - Page 6
   Endpoint ID (EID):   An EID is a 32-bit (for IPv4) or 128-bit (for
      IPv6) value used in the source and destination address fields of
      the first (most inner) LISP header of a packet.  The host obtains
      a destination EID the same way it obtains a destination address
      today, for example, through a Domain Name System (DNS) [RFC1034]
      lookup or Session Initiation Protocol (SIP) [RFC3261] exchange.
      The source EID is obtained via existing mechanisms used to set a
      host's "local" IP address.  An EID used on the public Internet
      must have the same properties as any other IP address used in that
      manner; this means, among other things, that it must be globally
      unique.  An EID is allocated to a host from an EID-Prefix block
      associated with the site where the host is located.  An EID can be
      used by a host to refer to other hosts.  EIDs MUST NOT be used as
      LISP RLOCs.  Note that EID blocks MAY be assigned in a
      hierarchical manner, independent of the network topology, to
      facilitate scaling of the mapping database.  In addition, an EID
      block assigned to a site may have site-local structure
      (subnetting) for routing within the site; this structure is not
      visible to the global routing system.  In theory, the bit string
      that represents an EID for one device can represent an RLOC for a
      different device.  As the architecture is realized, if a given bit
      string is both an RLOC and an EID, it must refer to the same
      entity in both cases.  When used in discussions with other
      Locator/ID separation proposals, a LISP EID will be called an
      "LEID".  Throughout this document, any references to "EID" refer
      to an LEID.

   EID-Prefix:   An EID-Prefix is a power-of-two block of EIDs that are
      allocated to a site by an address allocation authority.
      EID-Prefixes are associated with a set of RLOC addresses that make
      up a "database mapping".  EID-Prefix allocations can be broken up
      into smaller blocks when an RLOC set is to be associated with the
      larger EID-Prefix block.  A globally routed address block (whether
      PI or PA) is not inherently an EID-Prefix.  A globally routed
      address block MAY be used by its assignee as an EID block.  The
      converse is not supported.  That is, a site that receives an
      explicitly allocated EID-Prefix may not use that EID-Prefix as a
      globally routed prefix.  This would require coordination and
      cooperation with the entities managing the mapping infrastructure.
      Once this has been done, that block could be removed from the
      globally routed IP system, if other suitable transition and access
      mechanisms are in place.  Discussion of such transition and access
      mechanisms can be found in [RFC6832] and [LISP-DEPLOY].
Top   ToC   RFC6830 - Page 7
   End-system:   An end-system is an IPv4 or IPv6 device that originates
      packets with a single IPv4 or IPv6 header.  The end-system
      supplies an EID value for the destination address field of the IP
      header when communicating globally (i.e., outside of its routing
      domain).  An end-system can be a host computer, a switch or router
      device, or any network appliance.

   Ingress Tunnel Router (ITR):   An ITR is a router that resides in a
      LISP site.  Packets sent by sources inside of the LISP site to
      destinations outside of the site are candidates for encapsulation
      by the ITR.  The ITR treats the IP destination address as an EID
      and performs an EID-to-RLOC mapping lookup.  The router then
      prepends an "outer" IP header with one of its globally routable
      RLOCs in the source address field and the result of the mapping
      lookup in the destination address field.  Note that this
      destination RLOC MAY be an intermediate, proxy device that has
      better knowledge of the EID-to-RLOC mapping closer to the
      destination EID.  In general, an ITR receives IP packets from site
      end-systems on one side and sends LISP-encapsulated IP packets
      toward the Internet on the other side.

      Specifically, when a service provider prepends a LISP header for
      Traffic Engineering purposes, the router that does this is also
      regarded as an ITR.  The outer RLOC the ISP ITR uses can be based
      on the outer destination address (the originating ITR's supplied
      RLOC) or the inner destination address (the originating host's
      supplied EID).

   TE-ITR:   A TE-ITR is an ITR that is deployed in a service provider
      network that prepends an additional LISP header for Traffic
      Engineering purposes.

   Egress Tunnel Router (ETR):   An ETR is a router that accepts an IP
      packet where the destination address in the "outer" IP header is
      one of its own RLOCs.  The router strips the "outer" header and
      forwards the packet based on the next IP header found.  In
      general, an ETR receives LISP-encapsulated IP packets from the
      Internet on one side and sends decapsulated IP packets to site
      end-systems on the other side.  ETR functionality does not have to
      be limited to a router device.  A server host can be the endpoint
      of a LISP tunnel as well.

   TE-ETR:   A TE-ETR is an ETR that is deployed in a service provider
      network that strips an outer LISP header for Traffic Engineering
      purposes.
Top   ToC   RFC6830 - Page 8
   xTR:   An xTR is a reference to an ITR or ETR when direction of data
      flow is not part of the context description. "xTR" refers to the
      router that is the tunnel endpoint and is used synonymously with
      the term "Tunnel Router".  For example, "An xTR can be located at
      the Customer Edge (CE) router" indicates both ITR and ETR
      functionality at the CE router.

   LISP Router:   A LISP router is a router that performs the functions
      of any or all of the following: ITR, ETR, Proxy-ITR (PITR), or
      Proxy-ETR (PETR).

   EID-to-RLOC Cache:   The EID-to-RLOC Cache is a short-lived,
      on-demand table in an ITR that stores, tracks, and is responsible
      for timing out and otherwise validating EID-to-RLOC mappings.
      This cache is distinct from the full "database" of EID-to-RLOC
      mappings; it is dynamic, local to the ITR(s), and relatively
      small, while the database is distributed, relatively static, and
      much more global in scope.

   EID-to-RLOC Database:   The EID-to-RLOC Database is a global
      distributed database that contains all known EID-Prefix-to-RLOC
      mappings.  Each potential ETR typically contains a small piece of
      the database: the EID-to-RLOC mappings for the EID-Prefixes
      "behind" the router.  These map to one of the router's own
      globally visible IP addresses.  The same database mapping entries
      MUST be configured on all ETRs for a given site.  In a steady
      state, the EID-Prefixes for the site and the Locator-Set for each
      EID-Prefix MUST be the same on all ETRs.  Procedures to enforce
      and/or verify this are outside the scope of this document.  Note
      that there MAY be transient conditions when the EID-Prefix for the
      site and Locator-Set for each EID-Prefix may not be the same on
      all ETRs.  This has no negative implications, since a partial set
      of Locators can be used.

   Recursive Tunneling:   Recursive Tunneling occurs when a packet has
      more than one LISP IP header.  Additional layers of tunneling MAY
      be employed to implement Traffic Engineering or other re-routing
      as needed.  When this is done, an additional "outer" LISP header
      is added, and the original RLOCs are preserved in the "inner"
      header.  Any references to tunnels in this specification refer to
      dynamic encapsulating tunnels; they are never statically
      configured.

   Re-encapsulating Tunnels:   Re-encapsulating Tunneling occurs when an
      ETR removes a LISP header, then acts as an ITR to prepend another
      LISP header.  Doing this allows a packet to be re-routed by the
      re-encapsulating router without adding the overhead of additional
      tunnel headers.  Any references to tunnels in this specification
Top   ToC   RFC6830 - Page 9
      refer to dynamic encapsulating tunnels; they are never statically
      configured.  When using multiple mapping database systems, care
      must be taken to not create re-encapsulation loops through
      misconfiguration.

   LISP Header:   LISP header is a term used in this document to refer
      to the outer IPv4 or IPv6 header, a UDP header, and a LISP-
      specific 8-octet header that follow the UDP header and that an ITR
      prepends or an ETR strips.

   Address Family Identifier (AFI):   AFI is a term used to describe an
      address encoding in a packet.  An address family currently
      pertains to an IPv4 or IPv6 address.  See [AFI] and [RFC3232] for
      details.  An AFI value of 0 used in this specification indicates
      an unspecified encoded address where the length of the address is
      0 octets following the 16-bit AFI value of 0.

   Negative Mapping Entry:   A negative mapping entry, also known as a
      negative cache entry, is an EID-to-RLOC entry where an EID-Prefix
      is advertised or stored with no RLOCs.  That is, the Locator-Set
      for the EID-to-RLOC entry is empty or has an encoded Locator count
      of 0.  This type of entry could be used to describe a prefix from
      a non-LISP site, which is explicitly not in the mapping database.
      There are a set of well-defined actions that are encoded in a
      Negative Map-Reply (Section 6.1.5).

   Data-Probe:   A Data-Probe is a LISP-encapsulated data packet where
      the inner-header destination address equals the outer-header
      destination address used to trigger a Map-Reply by a decapsulating
      ETR.  In addition, the original packet is decapsulated and
      delivered to the destination host if the destination EID is in the
      EID-Prefix range configured on the ETR.  Otherwise, the packet is
      discarded.  A Data-Probe is used in some of the mapping database
      designs to "probe" or request a Map-Reply from an ETR; in other
      cases, Map-Requests are used.  See each mapping database design
      for details.  When using Data-Probes, by sending Map-Requests on
      the underlying routing system, EID-Prefixes must be advertised.
      However, this is discouraged if the core is to scale by having
      less EID-Prefixes stored in the core router's routing tables.

   Proxy-ITR (PITR):   A PITR is defined and described in [RFC6832].  A
      PITR acts like an ITR but does so on behalf of non-LISP sites that
      send packets to destinations at LISP sites.

   Proxy-ETR (PETR):   A PETR is defined and described in [RFC6832].  A
      PETR acts like an ETR but does so on behalf of LISP sites that
      send packets to destinations at non-LISP sites.
Top   ToC   RFC6830 - Page 10
   Route-returnability:  Route-returnability is an assumption that the
      underlying routing system will deliver packets to the destination.
      When combined with a nonce that is provided by a sender and
      returned by a receiver, this limits off-path data insertion.  A
      route-returnability check is verified when a message is sent with
      a nonce, another message is returned with the same nonce, and the
      destination of the original message appears as the source of the
      returned message.

   LISP site:  LISP site is a set of routers in an edge network that are
      under a single technical administration.  LISP routers that reside
      in the edge network are the demarcation points to separate the
      edge network from the core network.

   Client-side:  Client-side is a term used in this document to indicate
      a connection initiation attempt by an EID.  The ITR(s) at the LISP
      site are the first to get involved in obtaining database Map-Cache
      entries by sending Map-Request messages.

   Server-side:  Server-side is a term used in this document to indicate
      that a connection initiation attempt is being accepted for a
      destination EID.  The ETR(s) at the destination LISP site are the
      first to send Map-Replies to the source site initiating the
      connection.  The ETR(s) at this destination site can obtain
      mappings by gleaning information from Map-Requests, Data-Probes,
      or encapsulated packets.

   Locator-Status-Bits (LSBs):  Locator-Status-Bits are present in the
      LISP header.  They are used by ITRs to inform ETRs about the up/
      down status of all ETRs at the local site.  These bits are used as
      a hint to convey up/down router status and not path reachability
      status.  The LSBs can be verified by use of one of the Locator
      reachability algorithms described in Section 6.3.

   Anycast Address:  Anycast Address is a term used in this document to
      refer to the same IPv4 or IPv6 address configured and used on
      multiple systems at the same time.  An EID or RLOC can be an
      anycast address in each of their own address spaces.

4. Basic Overview

One key concept of LISP is that end-systems (hosts) operate the same way they do today. The IP addresses that hosts use for tracking sockets and connections, and for sending and receiving packets, do not change. In LISP terminology, these IP addresses are called Endpoint Identifiers (EIDs).
Top   ToC   RFC6830 - Page 11
   Routers continue to forward packets based on IP destination
   addresses.  When a packet is LISP encapsulated, these addresses are
   referred to as Routing Locators (RLOCs).  Most routers along a path
   between two hosts will not change; they continue to perform routing/
   forwarding lookups on the destination addresses.  For routers between
   the source host and the ITR as well as routers from the ETR to the
   destination host, the destination address is an EID.  For the routers
   between the ITR and the ETR, the destination address is an RLOC.

   Another key LISP concept is the "Tunnel Router".  A Tunnel Router
   prepends LISP headers on host-originated packets and strips them
   prior to final delivery to their destination.  The IP addresses in
   this "outer header" are RLOCs.  During end-to-end packet exchange
   between two Internet hosts, an ITR prepends a new LISP header to each
   packet, and an ETR strips the new header.  The ITR performs
   EID-to-RLOC lookups to determine the routing path to the ETR, which
   has the RLOC as one of its IP addresses.

   Some basic rules governing LISP are:

   o  End-systems (hosts) only send to addresses that are EIDs.  They
      don't know that addresses are EIDs versus RLOCs but assume that
      packets get to their intended destinations.  In a system where
      LISP is deployed, LISP routers intercept EID-addressed packets and
      assist in delivering them across the network core where EIDs
      cannot be routed.  The procedure a host uses to send IP packets
      does not change.

   o  EIDs are always IP addresses assigned to hosts.

   o  LISP routers mostly deal with Routing Locator addresses.  See
      details in Section 4.1 to clarify what is meant by "mostly".

   o  RLOCs are always IP addresses assigned to routers, preferably
      topologically oriented addresses from provider CIDR (Classless
      Inter-Domain Routing) blocks.

   o  When a router originates packets, it may use as a source address
      either an EID or RLOC.  When acting as a host (e.g., when
      terminating a transport session such as Secure SHell (SSH),
      TELNET, or the Simple Network Management Protocol (SNMP)), it may
      use an EID that is explicitly assigned for that purpose.  An EID
      that identifies the router as a host MUST NOT be used as an RLOC;
      an EID is only routable within the scope of a site.  A typical BGP
      configuration might demonstrate this "hybrid" EID/RLOC usage where
      a router could use its "host-like" EID to terminate iBGP sessions
      to other routers in a site while at the same time using RLOCs to
      terminate eBGP sessions to routers outside the site.
Top   ToC   RFC6830 - Page 12
   o  Packets with EIDs in them are not expected to be delivered
      end-to-end in the absence of an EID-to-RLOC mapping operation.
      They are expected to be used locally for intra-site communication
      or to be encapsulated for inter-site communication.

   o  EID-Prefixes are likely to be hierarchically assigned in a manner
      that is optimized for administrative convenience and to facilitate
      scaling of the EID-to-RLOC mapping database.  The hierarchy is
      based on an address allocation hierarchy that is independent of
      the network topology.

   o  EIDs may also be structured (subnetted) in a manner suitable for
      local routing within an Autonomous System (AS).

   An additional LISP header MAY be prepended to packets by a TE-ITR
   when re-routing of the path for a packet is desired.  A potential
   use-case for this would be an ISP router that needs to perform
   Traffic Engineering for packets flowing through its network.  In such
   a situation, termed "Recursive Tunneling", an ISP transit acts as an
   additional ITR, and the RLOC it uses for the new prepended header
   would be either a TE-ETR within the ISP (along an intra-ISP traffic
   engineered path) or a TE-ETR within another ISP (an inter-ISP traffic
   engineered path, where an agreement to build such a path exists).

   In order to avoid excessive packet overhead as well as possible
   encapsulation loops, this document mandates that a maximum of two
   LISP headers can be prepended to a packet.  For initial LISP
   deployments, it is assumed that two headers is sufficient, where the
   first prepended header is used at a site for Location/Identity
   separation and the second prepended header is used inside a service
   provider for Traffic Engineering purposes.

   Tunnel Routers can be placed fairly flexibly in a multi-AS topology.
   For example, the ITR for a particular end-to-end packet exchange
   might be the first-hop or default router within a site for the source
   host.  Similarly, the ETR might be the last-hop router directly
   connected to the destination host.  Another example, perhaps for a
   VPN service outsourced to an ISP by a site, the ITR could be the
   site's border router at the service provider attachment point.
   Mixing and matching of site-operated, ISP-operated, and other Tunnel
   Routers is allowed for maximum flexibility.  See Section 8 for more
   details.
Top   ToC   RFC6830 - Page 13

4.1. Packet Flow Sequence

This section provides an example of the unicast packet flow with the following conditions: o Source host "host1.abc.example.com" is sending a packet to "host2.xyz.example.com", exactly what host1 would do if the site was not using LISP. o Each site is multihomed, so each Tunnel Router has an address (RLOC) assigned from the service provider address block for each provider to which that particular Tunnel Router is attached. o The ITR(s) and ETR(s) are directly connected to the source and destination, respectively, but the source and destination can be located anywhere in the LISP site. o Map-Requests can be sent on the underlying routing system topology, to a mapping database system, or directly over an Alternative Logical Topology [RFC6836]. A Map-Request is sent for an external destination when the destination is not found in the forwarding table or matches a default route. o Map-Replies are sent on the underlying routing system topology. Client host1.abc.example.com wants to communicate with server host2.xyz.example.com: 1. host1.abc.example.com wants to open a TCP connection to host2.xyz.example.com. It does a DNS lookup on host2.xyz.example.com. An A/AAAA record is returned. This address is the destination EID. The locally assigned address of host1.abc.example.com is used as the source EID. An IPv4 or IPv6 packet is built and forwarded through the LISP site as a normal IP packet until it reaches a LISP ITR. 2. The LISP ITR must be able to map the destination EID to an RLOC of one of the ETRs at the destination site. The specific method used to do this is not described in this example. See [RFC6836] or [CONS] for possible solutions. 3. The ITR will send a LISP Map-Request. Map-Requests SHOULD be rate-limited.
Top   ToC   RFC6830 - Page 14
   4.  When an alternate mapping system is not in use, the Map-Request
       packet is routed through the underlying routing system.
       Otherwise, the Map-Request packet is routed on an alternate
       logical topology, for example, the [RFC6836] database mapping
       system.  In either case, when the Map-Request arrives at one of
       the ETRs at the destination site, it will process the packet as a
       control message.

   5.  The ETR looks at the destination EID of the Map-Request and
       matches it against the prefixes in the ETR's configured
       EID-to-RLOC mapping database.  This is the list of EID-Prefixes
       the ETR is supporting for the site it resides in.  If there is no
       match, the Map-Request is dropped.  Otherwise, a LISP Map-Reply
       is returned to the ITR.

   6.  The ITR receives the Map-Reply message, parses the message (to
       check for format validity), and stores the mapping information
       from the packet.  This information is stored in the ITR's
       EID-to-RLOC mapping cache.  Note that the map-cache is an
       on-demand cache.  An ITR will manage its map-cache in such a way
       that optimizes for its resource constraints.

   7.  Subsequent packets from host1.abc.example.com to
       host2.xyz.example.com will have a LISP header prepended by the
       ITR using the appropriate RLOC as the LISP header destination
       address learned from the ETR.  Note that the packet MAY be sent
       to a different ETR than the one that returned the Map-Reply due
       to the source site's hashing policy or the destination site's
       Locator-Set policy.

   8.  The ETR receives these packets directly (since the destination
       address is one of its assigned IP addresses), checks the validity
       of the addresses, strips the LISP header, and forwards packets to
       the attached destination host.

   In order to defer the need for a mapping lookup in the reverse
   direction, an ETR MAY create a cache entry that maps the source EID
   (inner-header source IP address) to the source RLOC (outer-header
   source IP address) in a received LISP packet.  Such a cache entry is
   termed a "gleaned" mapping and only contains a single RLOC for the
   EID in question.  More complete information about additional RLOCs
   SHOULD be verified by sending a LISP Map-Request for that EID.  Both
   the ITR and the ETR may also influence the decision the other makes
   in selecting an RLOC.  See Section 6 for more details.


(next page on part 2)

Next Section