Internet Engineering Task Force (IETF) D. Farinacci
Request for Comments: 6830 Cisco Systems
Category: Experimental V. Fuller
ISSN: 2070-1721
D. MeyerD. 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.
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 ....................................................32. Requirements Notation ...........................................53. Definition of Terms .............................................54. Basic Overview .................................................104.1. Packet Flow Sequence ......................................135. LISP Encapsulation Details .....................................155.1. LISP IPv4-in-IPv4 Header Format ...........................165.2. LISP IPv6-in-IPv6 Header Format ...........................175.3. Tunnel Header Field Descriptions ..........................185.4. Dealing with Large Encapsulated Packets ...................225.4.1. A Stateless Solution to MTU Handling ...............225.4.2. A Stateful Solution to MTU Handling ................235.5. Using Virtualization and Segmentation with LISP ...........246. EID-to-RLOC Mapping ............................................256.1. LISP IPv4 and IPv6 Control-Plane Packet Formats ...........256.1.1. LISP Packet Type Allocations .......................276.1.2. Map-Request Message Format .........................276.1.3. EID-to-RLOC UDP Map-Request Message ................306.1.4. Map-Reply Message Format ...........................316.1.5. EID-to-RLOC UDP Map-Reply Message ..................356.1.6. Map-Register Message Format ........................376.1.7. Map-Notify Message Format ..........................396.1.8. Encapsulated Control Message Format ................416.2. Routing Locator Selection .................................426.3. Routing Locator Reachability ..............................446.3.1. Echo Nonce Algorithm ...............................466.3.2. RLOC-Probing Algorithm .............................486.4. EID Reachability within a LISP Site .......................496.5. Routing Locator Hashing ...................................49
6.6. Changing the Contents of EID-to-RLOC Mappings .............506.6.1. Clock Sweep ........................................516.6.2. Solicit-Map-Request (SMR) ..........................526.6.3. Database Map-Versioning ............................537. Router Performance Considerations ..............................548. Deployment Scenarios ...........................................558.1. First-Hop/Last-Hop Tunnel Routers .........................568.2. Border/Edge Tunnel Routers ................................568.3. ISP Provider Edge (PE) Tunnel Routers .....................578.4. LISP Functionality with Conventional NATs .................588.5. Packets Egressing a LISP Site .............................589. Traceroute Considerations ......................................589.1. IPv6 Traceroute ...........................................599.2. IPv4 Traceroute ...........................................609.3. Traceroute Using Mixed Locators ...........................6010. Mobility Considerations .......................................6110.1. Site Mobility ............................................6110.2. Slow Endpoint Mobility ...................................6110.3. Fast Endpoint Mobility ...................................6110.4. Fast Network Mobility ....................................6310.5. LISP Mobile Node Mobility ................................6411. Multicast Considerations ......................................6412. Security Considerations .......................................6513. Network Management Considerations .............................6714. IANA Considerations ...........................................6714.1. LISP ACT and Flag Fields .................................6714.2. LISP Address Type Codes ..................................6814.3. LISP UDP Port Numbers ....................................6814.4. LISP Key ID Numbers ......................................6815. Known Open Issues and Areas of Future Work ....................6816. References ....................................................7016.1. Normative References .....................................7016.2. Informative References ...................................71Appendix A. Acknowledgments .......................................741. 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.
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.
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.
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].
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.
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
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.
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).
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.
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.
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.
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.
