1<?xml version='1.0' encoding='utf-8'?>
2<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
3<?rfc toc="yes"?>
4<?rfc tocompact="yes"?>
5<?rfc tocdepth="3"?>
6<?rfc tocindent="yes"?>
7<?rfc symrefs="yes"?>
8<?rfc sortrefs="yes"?>
9<?rfc comments="yes"?>
10<?rfc inline="yes"?>
11<?rfc compact="yes"?>
12<?rfc subcompact="no"?>
13<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-ietf-lisp-introduction-13.txt" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3">
14  <!-- xml2rfc v2v3 conversion 2.23.0 -->
15  <front>
16    <title abbrev="LISP Introduction">An Architectural Introduction to the Locator/ID Separation Protocol (LISP)</title>
17    <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-introduction-13.txt"/>
18    <author fullname="Albert Cabellos" initials="A." surname="Cabellos">
19      <organization>UPC-BarcelonaTech</organization>
20      <address>
21        <postal>
22          <street>c/ Jordi Girona 1-3</street>
23          <city>Barcelona</city>
24          <code>08034</code>
25          <region>Catalonia</region>
26          <country>Spain</country>
27        </postal>
28        <email>acabello@ac.upc.edu</email>
29      </address>
30    </author>
31    <author fullname="Damien Saucez (Ed.)" initials="D." surname="Saucez (Ed.)">
32      <organization>INRIA</organization>
33      <address>
34        <postal>
35          <street>2004 route des Lucioles BP 93</street>
36          <city>Sophia Antipolis Cedex</city>
37          <code>06902</code>
38          <country>France</country>
39        </postal>
40        <email>damien.saucez@inria.fr</email>
41      </address>
42    </author>
43    <date day="02" month="April" year="2015"/>
44    <area>Routing Area</area>
45    <keyword>LISP</keyword>
46    <keyword>Architecture</keyword>
47    <abstract>
48      <t>This document describes the architecture of the Locator/ID Separation
49 Protocol (LISP), making it easier to read the rest of the LISP
50 specifications and providing a basis for discussion about the details
51 of the LISP protocols. This document is used for introductory purposes, 
52 more details can be found in RFC6830, the protocol specification.</t>
53    </abstract>
54  </front>
55  <middle>
56    <section numbered="true" toc="default">
57      <name>Introduction</name>
58      <t>This document introduces the Locator/ID Separation Protocol (LISP)
59 <xref target="RFC6830" format="default"/> architecture, its main operational mechanisms and its design
60 rationale. Fundamentally, LISP is built following a well-known
61 architectural idea: decoupling the IP address overloaded semantics.
62 Indeed and as pointed out by Noel Chiappa <xref target="RFC4984" format="default"/>, currently IP addresses both
63 identify the topological location of a network attachment point as
64 well as the node's identity.  However, nodes and routing have
65 fundamentally different requirements, routing systems require that
66 addresses are aggregatable and have topological meaning, while nodes
67 require to be identified independently of their current location <xref target="RFC4984" format="default"/>.</t>
68      <t>LISP creates two separate namespaces, EIDs (End-host IDentifiers) and
69 RLOCs (Routing LOCators), both are 
70 syntactically identical to the current IPv4 and IPv6 addresses.  EIDs
71 are used to uniquely identify nodes irrespective of their topological
72 location and are typically routed intra-domain. RLOCs are assigned
73 topologically to network attachment points and are typically routed
74 inter-domain.  With LISP, the edge of the Internet (where the nodes
75 are connected) and the core (where inter-domain routing occurs) can be
76 logically separated and interconnected by LISP-capable routers.
77 LISP also introduces a database, called the
78 Mapping System, to store and retrieve mappings between identity and
79 location.  LISP-capable routers exchange packets over the Internet
80 core by encapsulating them to the appropriate location.</t>
81      <t>In summary:</t>
82      <ul spacing="normal">
83        <li>RLOCs have meaning only in the underlay network, that is the underlying core routing system.</li>
84        <li>EIDs have meaning only in the overlay network, which is the encapsulation relationship between LISP-capable routers.</li>
85        <li>The LISP edge maps EIDs to RLOCs</li>
86        <li>Within the underlay network, RLOCs have both locator and
87        identifier semantics</li>
88        <li>An EID within a LISP site carries both identifier and locator
89        semantics to other nodes within that site</li>
90        <li>An EID within a LISP site carries identifier and limited locator
91        semantics to nodes at other LISP sites (i.e., enough locator
92        information to tell that the EID is external to the site)</li>
93      </ul>
94      <t>The relationship described above is not unique to LISP but it is
95    common to other overlay technologies.</t>
96      <t>
97The initial motivation in the LISP effort is to be found in the
98    routing scalability problem <xref target="RFC4984" format="default"/>, where, if LISP were to be completely
99    deployed, the Internet core is populated with RLOCs while Traffic
100    Engineering mechanisms are pushed to the Mapping System.  
102          In such scenario RLOCs are quasi-static (i.e., low churn), hence making the routing system
103    scalable <xref target="Quoitin" format="default"/>, while EIDs can roam anywhere with no churn to the
104    underlying routing system. <xref target="RFC7215" format="default"/> discusses the impact of LISP on the global routing 
105          system during the transition period. However, the separation between location and identity
106    that LISP offers makes it suitable for use in additional
107    scenarios such as Traffic Engineering (TE), multihoming, and
108    mobility among others.</t>
109      <t>This document describes the LISP architecture and its main
110   operational mechanisms as well as its design rationale. It is important to note that this
111 document does not specify or complement the LISP protocol. The
112 interested reader should refer to the main LISP specifications <xref target="RFC6830" format="default"/> and the complementary documents <xref target="RFC6831" format="default"/>, <xref target="RFC6832" format="default"/>, <xref target="RFC6833" format="default"/>, <xref target="RFC6834" format="default"/>, <xref target="RFC6835" format="default"/>,
113 <xref target="RFC6836" format="default"/>, <xref target="RFC7052" format="default"/> for the protocol specifications along with the 
114 LISP deployment guidelines <xref target="RFC7215" format="default"/>.</t>
115    </section>
116    <section numbered="true" toc="default">
117      <name>Definition of Terms</name>
118      <dl newline="false" spacing="normal">
119        <dt>Endpoint IDentifier (EID):</dt>
120        <dd> EIDs are addresses used to uniquely identify nodes irrespective of their topological location and are typically routed intra-domain.</dd>
121        <dt>Routing LOcator (RLOC):</dt>
122        <dd>RLOCs are addresses assigned topologically to network attachment points and typically routed inter-domain.</dd>
123        <dt>Ingress Tunnel Router (ITR):</dt>
124        <dd>A LISP-capable router that encapsulates packets from a LISP site towards the core network.</dd>
125        <dt>Egress Tunnel Router (ETR):</dt>
126        <dd>A LISP-capable router that decapsulates packets from the core of the network towards a LISP site.</dd>
127        <dt>xTR:</dt>
128        <dd>A router that implements both ITR and ETR functionalities.</dd>
129        <dt>Map-Request:</dt>
130        <dd>A LISP signaling message used to request an EID-to-RLOC mapping.</dd>
131        <dt>Map-Reply:</dt>
132        <dd>A LISP signaling message sent in response to a Map-Request that contains a resolved EID-to-RLOC mapping.</dd>
133        <dt>Map-Register:</dt>
134        <dd>A LISP signaling message used to register an EID-to-RLOC mapping.</dd>
135        <dt>Map-Notify:</dt>
136        <dd>A LISP signaling message sent in response of a Map-Register to acknowledge the correct reception of an EID-to-RLOC mapping.</dd>
137      </dl>
138      <t>This document describes the LISP architecture and does not  
139 introduce any new term. The reader is referred to <xref target="RFC6830" format="default"/>, <xref target="RFC6831" format="default"/>, <xref target="RFC6832" format="default"/>, <xref target="RFC6833" format="default"/>, <xref target="RFC6834" format="default"/>, <xref target="RFC6835" format="default"/>,
140       <xref target="RFC6836" format="default"/>, <xref target="RFC7052" format="default"/>, <xref target="RFC7215" format="default"/> for the complete definition of terms.</t>
141    </section>
142    <section numbered="true" toc="default">
143      <name>LISP Architecture</name>
144      <t>This section presents the LISP architecture, it first details the
145      design principles of LISP and then it proceeds to describe its main aspects:
146      data-plane, control-plane, and internetworking mechanisms.</t>
147      <section numbered="true" toc="default">
148        <name>Design Principles</name>
149        <t>The LISP architecture is built on top of four basic design
150        principles:</t>
151        <ul spacing="normal">
152          <li>Locator/Identifier split: By decoupling the overloaded semantics of the
153            current IP addresses the Internet core can be assigned identity meaningful addresses and hence, can use aggregation to
154            scale. Devices are assigned with relatively opaque topologically meaningful addresses that
155            are independent of their topological location.</li>
156          <li>Overlay architecture: Overlays route packets over the current
157            Internet, allowing deployment of new protocols without changing the
158            current infrastructure hence, resulting into a low deployment
159            cost.</li>
160          <li>Decoupled data and control-plane: Separating the data-plane
161            from the control-plane allows them to scale independently and use
162            different architectural approaches. This is important given that
163            they typically have different requirements and allows for other data-planes to be added. While decoupled, data and control-plane
164      are not completely isolated because the LISP data-plane may
165      trigger control-plane activity.</li>
166          <li>Incremental deployability: This principle ensures that the protocol interoperates with the legacy Internet while providing some of the targeted benefits to early adopters.</li>
167        </ul>
168      </section>
169      <section numbered="true" toc="default">
170        <name>Overview of the Architecture</name>
171        <t>LISP splits architecturally the core from the edge of the Internet
172        by creating two separate namespaces: Endpoint Identifiers (EIDs) and
173        Routing LOCators (RLOCs). The edge consists of LISP sites (e.g., an Autonomous
174        System) that use EID addresses. EIDs are IPv4 or IPv6
175        addresses that uniquely identify communication end-hosts and are assigned and
176        configured by the same mechanisms that exist at the time of this writing. EIDs do not contain inter-domain topological information and because of this, EIDs are usually routable at the edge (within LISP sites) or in the non-LISP Internet; see Section 3.5 for discussion of LISP site internetworking with non-LISP sites and domains in the Internet.</t>
177        <t>LISP sites (at the edge of the Internet) are connected to the core
178 of the Internet by means of LISP-capable routers (e.g., border
179 routers).  LISP sites are connected across the core of the Internet
180 using tunnels between the LISP-capable routers. 
181When 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).
183 An xTR is a router which can perform both ITR and ETR operations. In this context ITRs
184 encapsulate packets while ETRs decapsulate them, hence LISP operates
185 as an overlay on top of the current Internet core.</t>
186        <artwork name="" type="" align="left" alt=""><![CDATA[
188                       /-----------------\                 ---
189                       |     Mapping     |                  | 
190                       .     System      |                  | Control
191                      -|                 |`,                | Plane  
192                    ,' \-----------------/  .               |
193                   /                         |             ---
194   ,..,           -        _,....,,          |      ,..,    | 
195 /     `        ,'      ,-`        `',       |    /     `   | 
196/        \ +-----+   ,'              `,  +-----+ /        \ |        
197|  EID   |-| xTR |--/        RLOC     ,--| xTR |-|  EID   | | Data  
198| Space  |-|     |--|       Space     |--|     |-| Space  | | Plane 
199\        / +-----+  .                 /  +-----+ \        / |        
200 `.    .'            `.              ,'           `.    .'  |   
201   `'-`                `.,        ,.'               `'-`   ---  
202                          ``'''``                                  
203  LISP Site (Edge)            Core              LISP Site (Edge)        
207           Figure 1.- A schema of the LISP Architecture   
210        <t>With LISP, the core uses RLOCs, an RLOC is an IPv4 or IPv6
211        address assigned to an Internet-facing network interface of an ITR or
212        ETR. Typically RLOCs are numbered from topologically aggregatable
213        blocks assigned to a site at each point to which it attaches to the
214        global Internet, the topology is defined by the connectivity of
215        networks.</t>
216        <t>A database which is typically distributed, called the Mapping System,
217 stores mappings between EIDs and RLOCs. Such mappings relate
218        the identity of the devices attached to LISP sites (EIDs) to the set
219        of RLOCs configured at the LISP-capable routers servicing the site.
220        Furthermore, the mappings also include traffic engineering policies
221        and can be configured to achieve multihoming and load balancing. The
222        LISP Mapping System is conceptually similar to the DNS 
223 where it is organized as a distributed multi-organization network database. 
224 With LISP, ETRs register mappings while ITRs retrieve them.</t>
225        <t>Finally, the LISP architecture emphasizes incremental deployment. Given that LISP represents an
226        overlay to the current Internet architecture, endhosts as well as
227        intra and inter-domain routers remain unchanged, and the only required
228        changes to the existing infrastructure are to routers connecting the
229        EID with the RLOC space. Additionally, LISP requires the deployment of
230        an independent Mapping System, such distributed database is a new
231        network entity.</t>
232        <t>The following describes a simplified packet flow sequence
233        between two nodes that are attached to LISP sites. Please note that typical LISP-capable routers are xTRs (both ITR and ETR). Client HostA
234        wants to send a packet to server HostB.</t>
235        <artwork name="" type="" align="left" alt=""><![CDATA[
237                         /----------------\
238                         |     Mapping    |
239                         |     System     |
240                        .|                |-           
241                       ` \----------------/ `.         
242                     ,`                       \        
243                    /                          `.      
244                  ,'         _,..-..,,           ',                 
245                 /         -`         `-,          \                
246               .'        ,'              \          `,              
247               `        '                 \           '             
248           +-----+     |                   | RLOC_B1+-----+         
249    HostA  |     |    |        RLOC         |-------|     |  HostB  
250    EID_A--|ITR_A|----|        Space        |       |ETR_B|--EID_B  
251           |     | RLOC_A1                  |-------|     |         
252           +-----+     |                   | RLOC_B2+-----+         
253                        ,                 /                         
254                         \               /                          
255                          `',         ,-`                           
256                             ``''-''``                              
258 Figure 2.- Packet flow sequence in LISP
260 ]]></artwork>
261        <ol spacing="normal" type="1">
262          <li>HostA retrieves the EID_B of HostB, typically querying the DNS and obtaining an A or AAAA record.
263            Then it generates an IP packet as in the Internet, the packet
264            has source address EID_A and destination address EID_B.</li>
265          <li>The packet is routed towards ITR_A in the LISP site using
266            standard intra-domain mechanisms.</li>
267          <li>ITR_A upon receiving the packet queries the Mapping System to
268            retrieve the locator of ETR_B that is servicing HostB's EID_B. In order
269            to do so it uses a LISP control message called Map-Request, the
270            message contains EID_B as the lookup key. In turn it receives
271            another LISP control message called Map-Reply, the message
272            contains two locators: RLOC_B1 and RLOC_B2 along with traffic
273            engineering policies: priority and weight per locator. Note that a Map-Reply can contain more locators if needed.
274    ITR_A also stores the mapping in a local cache to speed-up 
275    forwarding of subsequent packets.</li>
276          <li>ITR_A encapsulates the packet towards RLOC_B1 (chosen according
277            to the priorities/weights specified in the mapping). The packet contains two
278            IP headers, the outer header has RLOC_A1 as source and RLOC_B1 as
279            destination, the inner original header has EID_A as source and EID_B as
280            destination. Furthermore ITR_A adds a LISP header, more details
281            about LISP encapsulation can be found in <xref target="encapsulation" format="default"/>.</li>
282          <li>The encapsulated packet is forwarded by the Internet core as a
283            normal IP packet, making the EID invisible from the Internet core.</li>
284          <li>Upon reception of the encapsulated packet by ETR_B, it
285            decapsulates the packet and forwards it to HostB.</li>
286        </ol>
287      </section>
288      <section numbered="true" toc="default">
289        <name>Data-Plane</name>
290        <t>This section provides a high-level description of the LISP data-plane, 
291 which is specified in detail in <xref target="RFC6830" format="default"/>. The LISP data-plane is responsible for 
292        encapsulating and decapsulating data packets and caching the
293        appropriate forwarding state. It includes two main entities, the ITR
294        and the ETR, both are LISP capable routers that connect the EID with
295 the RLOC space (ITR) and vice versa (ETR). </t>
296        <section anchor="encapsulation" numbered="true" toc="default">
297          <name>LISP Encapsulation</name>
298          <t>ITRs encapsulate data packets towards ETRs. LISP data packets are
299          encapsulated using UDP (port 4341), the source port is usually selected by the ITR using a 5-tuple hash of the inner header (so to be consistent in case of multi-path solutions such as ECMP <xref target="RFC2992" format="default"/>) and ignored on reception.  LISP data packets are often encapsulated in UDP packets that
300   include a zero checksum <xref target="RFC6935" format="default"/> <xref target="RFC6936" format="default"/> that is not verified
301   when it is received, because LISP data packets typically include
302   an inner transport protocol header with a non-zero checksum. By
303   omitting the additional outer UDP encapsulation checksum, xTRs
304   can forward packets more efficiently. If LISP data packets are
305   encapsulated in UDP packets with non-zero checksums, the outer
306   UDP checksums are verified when the UDP packets are received, as
307   part of normal UDP processing.</t>
308          <t>LISP-encapsulated packets also include a LISP header (after the
309          UDP header and before the original IP header). The LISP header is prepended by ITRs and striped by
310          ETRs. It carries reachability information (see more details in <xref target="reachability" format="default"/>) and the Instance ID
311   field. 
312   The Instance ID field is used to distinguish traffic to/from
313   different tenant address spaces at the LISP site and that may use
314   overlapped but logically separated EID addressing.</t>
315          <t>Overall, LISP works on 4 headers, the inner header the source constructed, and the 3 headers a LISP encapsulator prepends ("outer" to "inner"):</t>
316          <ol spacing="normal" type="1">
317            <li>Outer IP header containing RLOCs as source and destination
318              addresses. This header is originated by ITRs and stripped by
319              ETRs.</li>
320            <li>UDP header (port 4341) with zero checksum. This header is
321              originated by ITRs and stripped by ETRs.</li>
322            <li>LISP header that contains various forwarding-plane features (such as reachability) and an
323              Instance ID field. This header is originated by ITRs and
324              stripped by ETRs.</li>
325            <li>Inner IP header containing EIDs as source and destination
326              addresses. This header is created by the source end-host and
327              is left unchanged by LISP data plane processing on the ITR and ETR.</li>
328          </ol>
329          <t>Finally, in some scenarios Re-encapsulating and/or Recursive
330 tunnels are useful to choose a specified path in the underlay network, for instance to avoid congestion or failure. 
331 Re-encapsulating tunnels are consecutive LISP tunnels and occur when
332 a decapsulator (an ETR action) removes a LISP header and then acts as an encapsultor (an ITR action) to prepend
333 another one.  On the other hand, Recursive tunnels are nested tunnels
334 and are implemented by using multiple LISP encapsulations on a packet. Such functions are implemented by Reencapsulating Tunnel
335 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, more information can be found at <xref target="RFC6830" format="default"/>.</t>
336        </section>
337        <section numbered="true" toc="default">
338          <name>LISP Forwarding State</name>
339          <t>In the LISP architecture, ITRs keep just enough information to route
340    traffic flowing through them. Meaning that, ITRs retrieve from the LISP
341    Mapping System mappings between EID-prefixes (blocks of EIDs) and RLOCs that are used
342    to encapsulate packets.  Such mappings are stored in a local cache
343  called the Map-Cache for subsequent packets addressed to the same EID
344    prefix.  Note that, in case of overlapping EID-prefixes, following a
345    single request, the ITR may receive a set of mappings, covering the
346    requested EID-prefix and all more-specifics (cf., Section 6.1.5
347    <xref target="RFC6830" format="default"/>). Mappings include a (Time-to-Live) TTL (set by the ETR).
348    More details about the Map-Cache management can be found in <xref target="management" format="default"/>.
349          </t>
350        </section>
351      </section>
352      <section numbered="true" toc="default">
353        <name>Control-Plane</name>
354        <t>
355 The LISP control-plane, specified in <xref target="RFC6833" format="default"/>, provides a standard
356 interface to register and request mappings.  The LISP
357 Mapping System is a database that stores such
358 mappings.  The following first describes the mappings, then the
359 standard interface to the Mapping System, and finally its architecture.</t>
360        <section numbered="true" toc="default">
361          <name>LISP Mappings</name>
362          <t>Each mapping includes the bindings between EID prefix(es) and
363          set of RLOCs as well as traffic engineering policies, in the form of
364          priorities and weights for the RLOCs. Priorities allow the ETR to
365          configure active/backup policies while weights are used to
366          load-balance traffic among the RLOCs (on a per-flow basis).</t>
367          <t>Typical mappings in LISP bind EIDs in the form of IP prefixes with
368 a set of RLOCs, also in the form of IPs.  IPv4 and IPv6 addresses are
369 encoded using the appropriate Address Family Identifier (AFI)
370 <xref target="RFC3232" format="default"/>. However LISP can also support more general address encoding 
371 by means of the ongoing effort around the LISP Canonical Address Format (LCAF)
372 <xref target="I-D.ietf-lisp-lcaf" format="default"/>.</t>
373          <t>With such a general syntax for address encoding in place, LISP
374          aims to provide flexibility to current and future applications. For
375          instance LCAFs could support 
376          MAC addresses, geo-coordinates, ASCII names and application specific
377          data.</t>
378        </section>
379        <section numbered="true" toc="default">
380          <name>Mapping System Interface</name>
381          <t>LISP defines a standard interface between data and control
382          planes. The interface is specified in <xref target="RFC6833" format="default"/> and
383          defines two entities:</t>
384          <dl newline="false" spacing="normal">
385            <dt>Map-Server:</dt>
386            <dd>A network infrastructure component
387              that learns mappings from ETRs and publishes them into the LISP
388              Mapping System. Typically Map-Servers are not authoritative to
389              reply to queries and hence, they forward them to the ETR.
390              However they can also operate in proxy-mode, where the ETRs
391              delegate replying to queries to Map-Servers. This setup is
392              useful when the ETR has limited resources (i.e., CPU or power).</dd>
393            <dt>Map-Resolver:</dt>
394            <dd>A network infrastructure component
395              that interfaces ITRs with the Mapping System by proxying queries
396              and in some cases responses. </dd>
397          </dl>
398          <t> The interface defines four LISP control messages which are
399          sent as UDP datagrams (port 4342):</t>
400          <dl newline="false" spacing="normal">
401            <dt>Map-Register:</dt>
402            <dd>This message is used by ETRs to
403              register mappings in the Mapping System and it is authenticated
404              using a shared key between the ETR and the Map-Server.</dd>
405            <dt>Map-Notify:</dt>
406            <dd>When requested by the ETR, this message is sent by the
407 Map-Server in response to a Map-Register to acknowledge the correct
408 reception of the mapping and convey the latest Map-Server state on the
409 EID to RLOC mapping. In some cases a Map-Notify can be sent to the previous RLOCs when an EID is registered by a new set of RLOCs.</dd>
410            <dt>Map-Request:</dt>
411            <dd>This message is used by ITRs or
412              Map-Resolvers to resolve the mapping of a given EID.</dd>
413            <dt>Map-Reply:</dt>
414            <dd>This message is sent by Map-Servers or ETRs in response to
415 a Map-Request and contains the resolved mapping.  Please note that a
416 Map-Reply may contain a negative reply if, for example, the queried EID is not part
417 of the LISP EID space.  In such cases the ITR typically forwards the
418 traffic natively (non encapsulated) to the public Internet, this
419 behavior is defined to support incremental deployment of LISP.</dd>
420          </dl>
421        </section>
422        <section numbered="true" toc="default">
423          <name>Mapping System</name>
424          <t>LISP architecturally decouples control and data-plane by means of
425          a standard interface. This interface glues the data-plane, routers
426          responsible for forwarding data-packets, with the LISP Mapping
427          System, a database responsible for storing
428          mappings.</t>
429          <t>With this separation in place the data and control-plane can use
430          different architectures if needed and scale independently.
431          Typically the data-plane is optimized to route packets according to
432          hierarchical IP addresses. However the control-plane may have
433          different requirements, for instance and by taking advantage of the
434          LCAFs, the Mapping System may be used to store
435          non-hierarchical keys (such as MAC addresses),
436          requiring different architectural approaches for scalability.
437          Another important difference between the LISP control and
438          data-planes is that, and as a result of the local mapping cache
439          available at ITR, the Mapping System does not need to operate at
440          line-rate.</t>
441          <t>
442       Many of the existing mechanisms to create distributed systems have been explored and considered for the Mapping System architecture:
443           graph-based databases in the form of LISP+ALT <xref target="RFC6836" format="default"/>, hierarchical databases in the form of LISP-DDT
444          <xref target="I-D.ietf-lisp-ddt" format="default"/>, monolithic databases in the form
445          of LISP-NERD <xref target="RFC6837" format="default"/>, flat databases
446          in the form of LISP-DHT <xref target="I-D.cheng-lisp-shdht" format="default"/>,<xref target="Mathy" format="default"/> and, a multicast-based database <xref target="I-D.curran-lisp-emacs" format="default"/>. Furthermore it is worth noting that, in some 
447          scenarios such as private deployments, the Mapping System can operate as logically centralized. 
448          In such cases it is typically composed of a single Map-Server/Map-Resolver.</t>
449          <t>The following focuses on the two mapping systems that have
450          been implemented and deployed (LISP-ALT and LISP+DDT).</t>
451          <section numbered="true" toc="default">
452            <name>LISP+ALT</name>
453            <t>
454   The LISP Alternative Topology (LISP+ALT) <xref target="RFC6836" format="default"/> was the first
455 Mapping System proposed, developed and deployed on the LISP pilot
456 network.  It is based on a distributed BGP overlay participated by
457 Map-Servers and Map-Resolvers. The nodes connect to their peers
458 through static tunnels. Each Map-Server involved in the ALT topology
459 advertises the EID-prefixes registered by the serviced ETRs, making
460 the EID routable on the ALT topology.
461            </t>
462            <t>When an ITR needs a mapping it sends a Map-Request to a Map-Resolver
463 that, using the ALT topology, forwards the Map-Request towards the
464 Map-Server responsible for the mapping. Upon reception the Map-Server
465 forwards the request to the ETR that in turn, replies directly to the
466 ITR using the native Internet core.</t>
467          </section>
468          <section numbered="true" toc="default">
469            <name>LISP-DDT</name>
470            <t>
471   LISP-DDT <xref target="I-D.ietf-lisp-ddt" format="default"/> is conceptually similar to the DNS, a
472 hierarchical directory whose internal structure mirrors the
473 hierarchical nature of the EID address space.  The DDT hierarchy is
474 composed of DDT nodes forming a tree structure, the leafs of the tree
475 are Map-Servers.  On top of the structure there is the DDT root node
476 <xref target="DDT-ROOT" format="default"/>, which is a particular instance of a DDT node and that
477 matches the entire address space.  As in the case of DNS, DDT supports
478 multiple redundant DDT nodes and/or DDT roots. Finally, Map-Resolvers
479 are the clients of the DDT hierarchy and can query either the DDT root
480 and/or other DDT nodes.
481            </t>
482            <artwork name="" type="" align="left" alt=""><![CDATA[
483                        /---------\
484                        |         |
485                        | DDT Root|
486                        |   /0    |
487                      ,.\---------/-,      
488                  ,-'`       |       `'.,  
489               -'`           |           `-      
490           /-------\     /-------\    /-------\  
491           |  DDT  |     |  DDT  |    |  DDT  |  
492           | Node  |     | Node  |    | Note  |  ...
493           |  0/8  |     |  1/8  |    |  2/8  |  
494           \-------/     \-------/    \-------/  
495         _.                _.            . -..,,,_        
496       -`                -`              \        ````''--
497+------------+     +------------+   +------------+ +------------+     
498| Map-Server |     | Map-Server |   | Map-Server | | Map-Server |     
499| EID-prefix1|     | EID-prefix2|   | EID-prefix3| | EID-prefix4|     
500+------------+     +------------+   +------------+ +------------+
502      Figure 3.- A schematic representation of the DDT tree structure,
503              please note that the prefixes and the structure depicted
504              should be only considered as an example.
507            <t>The DDT structure does not actually index EID-prefixes but
508            eXtended EID-prefixes (XEID). An XEID-prefix is just the
509            concatenation of the following fields (from most significant bit
510            to less significant bit): Database-ID, Instance ID, Address Family
511            Identifier and the actual EID-prefix. The Database-ID is provided
512            for possible future requirements of higher levels in the hierarchy
513            and to enable the creation of multiple and separate database
514            trees.</t>
515            <t>In order to resolve a query LISP-DDT operates in a similar way to the
516 DNS but only supports iterative lookups. DDT clients (usually Map-Resolvers)
517            generate Map-Requests to the DDT root node. In response they
518            receive a newly introduced LISP-control message: a Map-Referral. A
519            Map-Referral provides the list of RLOCs of the set of DDT nodes
520            matching a configured XEID delegation. That is, the information
521            contained in the Map-Referral points to the child of the queried
522            DDT node that has more specific information about the queried
523            XEID-prefix. This process is repeated until the DDT client walks
524            the tree structure (downwards) and discovers the Map-Server
525            servicing the queried XEID. At this point the client sends a
526            Map-Request and receives a Map-Reply containing the mappings. It
527            is important to note that DDT clients can also cache the
528            information contained in Map-Referrals, that is, they cache the
529            DDT structure. This is used to reduce the mapping retrieving
530            latency<xref target="Jakab" format="default"/>.</t>
531            <t>The DDT Mapping System relies on manual configuration. That is
532            Map- Resolvers are manually configured with the set of available
533            DDT root nodes while DDT nodes are manually configured with the
534            appropriate XEID delegations. Configuration changes in the DDT
535            nodes are only required when the tree structure changes itself,
536            but it doesn't depend on EID dynamics (RLOC allocation or traffic
537            engineering policy changes).</t>
538          </section>
539        </section>
540      </section>
541      <section numbered="true" toc="default">
542        <name>Internetworking Mechanisms</name>
543        <t>EIDs are typically identical to either IPv4 or IPv6 addresses and
544        they are stored in the LISP Mapping System, however they are usually not
545        announced in the Internet global routing system. As a result LISP
546        requires an internetworking mechanism to allow LISP sites to speak
547        with non-LISP sites and vice versa. LISP internetworking mechanisms are
548        specified in <xref target="RFC6832" format="default"/>.</t>
549        <t>LISP defines two entities to provide internetworking:</t>
550        <dl newline="false" spacing="normal">
551          <dt>Proxy Ingress Tunnel Router (PITR):</dt>
552          <dd>PITRs provide
553            connectivity from the legacy Internet to LISP sites. PITRs
554            announce in the global routing system blocks of EID prefixes
555            (aggregating when possible) to attract traffic. For each incoming packet from a source not in a LISP site (a non-EID), 
556 the PITR LISP-encapsulates it towards the RLOC(s) of
557            the appropriate LISP site. The impact of PITRs in the routing
558            table size of the Default-Free Zone (DFZ) is, in the worst-case, similar to the case
559            in which LISP is not deployed. EID-prefixes will be aggregated 
560            as much as possible both by the PITR and by the global routing system.</dd>
561          <dt>Proxy Egress Tunnel Router (PETR):</dt>
562          <dd>PETRs provide
563            connectivity from LISP sites to the legacy Internet. In some scenarios, LISP sites may be unable to send encapsulated
564 packets with a local EID address as a source to the legacy Internet. For instance when Unicast Reverse Path
565            Forwarding (uRPF) is used by Provider Edge routers, or when an
566            intermediate network between a LISP site and a non-LISP site does
567            not support the desired version of IP (IPv4 or IPv6). In both
568            cases the PETR  overcomes such limitations by
569            encapsulating packets over the network.
570 There is no specified provision for the distribution of PETR RLOC addresses to the ITRs.</dd>
571        </dl>
572        <t>Additionally, LISP also defines mechanisms to operate with private EIDs <xref target="RFC1918" format="default"/> by means of LISP-NAT <xref target="RFC6832" format="default"/>. In this case 
573 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 xTRs behind a NAT using non-routable RLOCs.</t>
574        <t>PITRs, PETRs and, LISP-NAT enable incremental deployment of LISP, 
575 by providing significant flexibility in the placement of the boundaries between the 
576 LISP and non-LISP portions of the network, and making it easy to change those boundaries over time.</t>
577      </section>
578    </section>
579    <section numbered="true" toc="default">
580      <name>LISP Operational Mechanisms</name>
581      <t>This section details the main operational mechanisms defined in
582      LISP.</t>
583      <section anchor="management" numbered="true" toc="default">
584        <name>Cache Management</name>
585        <t>LISP's decoupled control and data-plane, where mappings are
586          stored in the control-plane and used for forwarding in the data
587          plane, requires a local cache in ITRs to reduce signaling
588          overhead (Map-Request/Map-Reply) and increase forwarding speed. The
589          local cache available at the ITRs, called Map-Cache, is used by the
590          router to LISP-encapsulate packets. The Map-Cache is indexed by
591          (Instance ID, EID-prefix) and contains basically the set
592          of RLOCs with the associated traffic engineering policies (priorities and
593          weights).</t>
594        <t>The Map-Cache, as any other cache, requires cache coherence
595          mechanisms to maintain up-to-date information. LISP defines three
596          main mechanisms for cache coherence:</t>
597        <dl newline="false" spacing="normal">
598          <dt>Time-To-Live (TTL):</dt>
599          <dd>Each mapping contains a TTL set by the ETR, upon
600 expiration of the TTL the ITR can't use the mapping until it is refreshed by 
601 sending a new Map-Request.  Typical values for TTL defined by LISP
602 are 24 hours.</dd>
603          <dt>Solicit-Map-Request (SMR):</dt>
604          <dd>SMR is an explicit
605              mechanism to update mapping information. In particular a special
606              type of Map-Request can be sent on demand by ETRs to request refreshing
607             a mapping. Upon reception of a SMR
608              message, the ITR must refresh the bindings by sending a
609              Map-Request to the Mapping System. Further uses of SMRs are documented in <xref target="RFC6830" format="default"/>.</dd>
610          <dt>Map-Versioning:</dt>
611          <dd>This optional mechanism piggybacks in the LISP header of data-packets the
612            version number of the mappings used by an xTR.  This way, when an xTR receives
613            a LISP-encapsulated packet from a remote xTR, it can check whether its own
614            Map-Cache or the one of the remote xTR is outdated.  If its Map-Cache is
615            outdated, it sends a Map-Request for the remote EID so to obtain the newest
616            mappings.  On the contrary, if it detects that the remote xTR Map-Cache is
617            outdated, it sends a SMR to notify it that a new mapping is available.</dd>
618        </dl>
619        <t>Finally it is worth noting that in some cases an entry in the
620 map-cache can be proactively refreshed using the mechanisms described
621 in the section below.</t>
622      </section>
623      <section anchor="reachability" numbered="true" toc="default">
624        <name>RLOC Reachability</name>
625        <t>In most cases LISP operates with a pull-based Mapping System (e.g., DDT), 
626 this results in an edge to edge pull architecture. In such scenario the network 
627 state is stored in the control-plane while the data-plane pulls it on demand.  
628 This has consequences concerning the propagation of xTRs reachability/liveness 
629 information since pull architectures require explicit mechanisms to propagate this information.  
630 As a result LISP defines a set of mechanisms to inform ITRs and PITRS about the reachability of the cached RLOCs:</t>
631        <t>Locator Status Bits (LSB): LSB is a passive technique, the LSB field is carried by data-packets
632 in the LISP header and can be set by a ETRs to specify which RLOCs of the ETR site are
633 up/down. This information
634        can be used by the ITRs as a hint about the reachability to perform
635        additional checks. Also note that LSB does not provide path
636        reachability status, only hints on the status of RLOCs.</t>
637        <t>Echo-nonce: This is also a passive technique, that can only operate
638        effectively when data flows bi-directionally between two communicating xTRs.
639        Basically, an ITR piggybacks a random number (called nonce) in LISP
640        data packets, if the path and the probed locator are up, the ETR will
641        piggyback the same random number on the next data-packet, if this is
642        not the case the ITR can set the locator as unreachable. When traffic
643        flow is unidirectional or when the ETR receiving the traffic is not
644        the same as the ITR that transmits it back, additional mechanisms are
645        required.</t>
646        <t>RLOC-probing: This is an active probing algorithm where ITRs send
647 probes to specific locators, this effectively probes both the locator
648 and the path. In particular this is done by sending a Map-Request
649 (with certain flags activated) on the data-plane (RLOC space) and
650 waiting in return a Map-Reply, also sent on the data-plane. The active
651        nature of RLOC-probing provides an effective mechanism to determine
652        reachability and, in case of failure, switching to a different
653        locator. Furthermore the mechanism also provides useful RTT
654        estimates of the delay of the path that can be used by other network
655        algorithms.</t>
656        <t>It is worth noting that RLOC probing and Echo-nonce can work together.
657 Specifically if a nonce is not echoed, an ITR could RLOC-probe to
658 determine if the path is up when it cannot tell the difference between a 
659 failed bidirectional path or the return path is not used (a unidirectional path).</t>
660        <t>Additionally, LISP also recommends inferring reachability of
661        locators by using information provided by the underlay, in
662        particular:</t>
663        <t>ICMP signaling: The LISP underlay -the current Internet- uses the
664        ICMP protocol to signal unreachability (among other things). LISP can
665        take advantage of this and the reception of a ICMP Network Unreachable
666        or ICMP Host Unreachable message can be seen as a hint that a locator
667        might be unreachable, this should lead to perform additional
668        checks.</t>
669        <t>Underlay routing: Both BGP and IBGP carry reachability information,
670        LISP-capable routers that have access to underlay routing information
671        can use it to determine if a given locator or path are reachable.</t>
672      </section>
673      <section numbered="true" toc="default">
674        <name>ETR Synchronization</name>
675        <t>All the ETRs that are authoritative to a particular EID-prefix must 
676 announce the same mapping to the requesters, this means that ETRs must be 
677 aware of the status of the RLOCs of the remaining ETRs. This is known as
678 ETR synchronization.</t>
679        <t>At the time of this writing LISP does not specify a mechanism to achieve ETR
680   synchronization. Although many well-known techniques could be applied to solve this issue
681   it is still under research, as a result operators must
682   rely on coherent manual configuration</t>
683      </section>
684      <section numbered="true" toc="default">
685        <name>MTU Handling</name>
686        <t>Since LISP encapsulates packets it requires dealing with packets that exceed the MTU of the path between the ITR
687                and the ETR. Specifically LISP defines two mechanisms:</t>
688        <dl newline="false" spacing="normal">
689          <dt>Stateless:</dt>
690          <dd>With this mechanism the effective MTU is assumed from the
691 ITR's perspective. If a payload packet is too big for the effective MTU, and
692 can be fragmented, the payload packet is fragmented on the ITR, such that
693 reassembly is performed at the destination host.</dd>
694          <dt>Stateful:</dt>
695          <dd>With this mechanism ITRs keep track of the MTU of the
696 paths towards the destination locators by parsing the ICMP Too Big
697 packets sent by intermediate routers. ITRs will send ICMP Too Big messages to inform the sources about the effective MTU. 
698 Additionally ITRs can use mechanisms such as PMTUD <xref target="RFC1191" format="default"/> or PLPMTUD <xref target="RFC4821" format="default"/> to keep track of the MTU towards the locators.</dd>
699        </dl>
700        <t>In both cases if the packet cannot be fragmented (IPv4 with DF=1 or IPv6) then the ITR drops
701                it and replies with a ICMP Too Big message to the source.</t>
702      </section>
703    </section>
704    <section numbered="true" toc="default">
705      <name>Mobility</name>
706      <t>The separation between locators and identifiers in LISP is suitable 
707 for traffic engineering purpose where LISP sites can change their attachment
708 points to the Internet (i.e., RLOCs) without impacting endpoints or the
709 Internet core. In this context, the border routers operate the xTR
710 functionality and endpoints are not aware of the existence of LISP. This functionality is similar to Network Mobility <xref target="RFC3963" format="default"/>. However,
711 this mode of operation does not allow seamless mobility of endpoints between
712 different LISP sites as the EID address might not be routable in a visited
713 site.  Nevertheless, LISP can be used to enable seamless IP mobility when LISP
714 is directly implemented in the endpoint or when the endpoint roams to an attached xTR.  
715 Each endpoint is then an xTR and the EID address is the one presented to the network stack used by applications
716 while the RLOC is the address gathered from the network when it is visited. This functionality is similar to Mobile IP (<xref target="RFC5944" format="default"/> and <xref target="RFC6275" format="default"/>).</t>
717      <t>Whenever the device changes of RLOC, the xTR updates the RLOC of its
718          local mapping and registers it to its Map-Server, typically with a low TTL value (1min). To avoid the need of a
719          home gateway, the ITR also indicates the RLOC change to all remote devices
720          that have ongoing communications with the device that moved.  The
721          combination of both methods ensures the scalability of the system as
722          signaling is strictly limited the Map-Server and to hosts with which
723          communications are ongoing. In the mobility case the EID-prefix can be as small as a full /32 or /128 (IPv4 or IPv6 respectively) depending on the specific use-case (e.g., subnet mobility vs single VM/Mobile node mobility).</t>
724      <t>The decoupled identity and location provided by LISP allows it to operate with other layer 2 and layer 3 mobility solutions.</t>
725    </section>
726    <section numbered="true" toc="default">
727      <name>Multicast</name>
728      <t>LISP also supports transporting IP multicast packets sent from the EID
729 space, the operational changes required to the multicast protocols are
730 documented in <xref target="RFC6831" format="default"/>.</t>
731      <t>In such scenarios, LISP may create multicast state both at the core
732 and at the sites (both source and receiver).  When signaling is used
733 to create multicast state at the sites, LISP routers unicast encapsulate
734 PIM Join/Prune messages from receiver to source sites.  At the core,
735 ETRs build a new PIM Join/Prune message addressed to the RLOC of the
736 ITR servicing the source.  An simplified sequence is shown below</t>
737      <ol spacing="normal" type="1">
738        <li>An end-host willing to join a multicast channel sends an IGMP
739 report. Multicast PIM routers at the LISP site propagate PIM
740 Join/Prune messages (S-EID, G) towards the ETR.</li>
741        <li>The join message flows to the ETR, upon reception the ETR builds two join messages, 
742             the first one unicast LISP-encapsulates the original join message towards the RLOC of the 
743             ITR servicing the source. This message creates (S-EID, G) multicast state at the source site.
744             The second join message contains as destination address the RLOC of the ITR 
745             servicing the source (S-RLOC, G) and creates multicast state at the core.</li>
746        <li>Multicast data packets originated by the source (S-EID, G) flow from the source
747         to the ITR. The ITR LISP-encapsulates the multicast packets, the outter header includes its own RLOC
748         as the source (S-RLOC) and the original multicast group address (G) as the destination. Please
749         note that multicast group address are logical and are not resolved by the mapping system. Then
750         the multicast packet is transmitted through the core towards the receiving ETRs that decapsulates
751         the packets and sends them using the receiver's site multicast state.</li>
752      </ol>
753      <t>Please note that the inner and outer multicast addresses are in general different, 
754 unless in specific cases where the underlay provider implements a tight control on the overlay. LISP specifications already support all PIM modes <xref target="RFC6831" format="default"/>. Additionally, 
755 LISP can support as well non-PIM mechanisms in order to maintain multicast state.</t>
756    </section>
757    <section numbered="true" toc="default">
758      <name>Use Cases</name>
759      <section numbered="true" toc="default">
760        <name>Traffic Engineering</name>
761        <t> A LISP site can strictly impose via which ETRs the
762          traffic must enter the the LISP site network even though the path followed to reach the
763          ETR is not under the control of the LISP site.  This fine control is
764          implemented with the mappings.  When a remote site is willing to send
765          traffic to a LISP site, it retrieves the mapping associated to the
766          destination EID via the mapping system.  The mapping is sent directly by an
767          authoritative ETR of the EID and is not altered by any intermediate network.  </t>
768        <t>A mapping associates a list of RLOCs to an EID prefix.  Each RLOC
769          corresponds to an interface of an ETR (or set of ETRs) that is able to correctly forward
770          packets to EIDs in the prefix.  Each RLOC is tagged with a priority and a
771          weight in the mapping.  The priority is used to indicates which RLOCs
772          should be preferred to send packets (the least preferred ones being
773          provided for backup purpose).  The weight permits to balance the load
774          between the RLOCs with the same priority, proportionally to the weight
775          value.</t>
776        <t>As mappings are directly issued by the authoritative ETR of the EID and are not altered
777          while transmitted to the remote site, it offers highly flexible incoming
778          inter-domain traffic engineering with even the possibility for a site to support a different mapping
779 policy for each remote site.
780          routing policies.</t>
781      </section>
782      <section numbered="true" toc="default">
783        <name>LISP for IPv6 Co-existence</name>
784        <t>LISP encapsulations allows to transport packets using EIDs from a given
785          address family (e.g., IPv6) with packets from other address families (e.g., IPv4). The absence of correlation between
786          the address family of RLOCs and EIDs makes LISP a candidate to allow, e.g., IPv6 to be deployed when all of the core
787 network may not have IPv6 enabled.</t>
788        <t>For example, two IPv6-only data centers could be interconnected via the
789          legacy IPv4 Internet. If their border routers are LISP capable, sending
790          packets between the data center is done without any form of translation as
791          the native IPv6 packets (in the EID space) will be LISP encapsulated and
792          transmitted over the IPv4 legacy Internet by the mean of IPv4 RLOCs.</t>
793      </section>
794      <section numbered="true" toc="default">
795        <name>LISP for Virtual Private Networks</name>
796        <t>It is common to operate several virtual networks over the same
797          physical infrastructure. In such virtual private networks, it is essential to distinguish which virtual
798          network a packet belongs and tags or labels are used for that purpose.
799          When using LISP, the distinction can be made with the Instance ID field.  When an
800          ITR encapsulates a packet from a particular virtual network (e.g., known
801          via the VRF or VLAN), it tags the encapsulated packet with the Instance ID
802          corresponding to the virtual network of the packet.  When an ETR receives a
803          packet tagged with an Instance ID it uses the Instance ID to determine how
804          to treat the packet. </t>
805        <t>The main usage of LISP for virtual private networks does not introduce 
806additional requirements on the underlying network, as long as it is  running IP.</t>
807      </section>
808      <section numbered="true" toc="default">
809        <name>LISP for Virtual Machine Mobility in Data Centers</name>
810        <t>A way to enable seamless virtual machine mobility in data center is to
811          conceive the datacenter backbone as the RLOC space and the subnet
812          where servers are hosted as forming the EID space. A LISP router is placed
813          at the border between the backbone and each subnet. When a virtual
814          machine is moved to another subnet, it can keep (temporarily) the address it had before the move so to continue without a 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.</t>
815        <t>To inform the other LISP routers that the machine moved and where, and then
816 to avoid detours via the initial subnetwork, mechanisms such as the
817 Solicit-Map-Request messages are used.</t>
818      </section>
819    </section>
820    <section numbered="true" toc="default">
821      <name>Security Considerations</name>
822      <t>This section describes the security considerations associated to the LISP protocol.</t>
823      <t>While in a push
824   mapping system, the state necessary to forward packets is learned
825   independently of the traffic itself, with a pull architecture, the
826   system becomes reactive and data-plane events (e.g., the arrival of a
827   packet for an unknown destination) may trigger control-plane events.
828   This on-demand learning of mappings provides many advantages as
829   discussed above but may also affect the way security is enforced.</t>
830      <t>Usually, the data-plane is implemented in the fast path of routers to
831        provide high performance forwarding capabilities while the control-plane
832        features are implemented in the slow path to offer high flexibility and a
833        performance gap of several order of magnitude can be observed between the slow
834        and the fast paths.  As a consequence, the way data-plane events are notified
835        to the control-plane must be thought carefully so to not overload the slow path
836        and rate limiting should be used as specified in <xref target="RFC6830" format="default"/>.</t>
837      <t>Care must also be taken so to not overload the mapping system (i.e., the
838        control plane infrastructure) as the operations to be performed by the mapping
839        system may be more complex than those on the data-plane, for that reason
840        <xref target="RFC6830" format="default"/> recommends to rate limit the sending of messages to the
841          mapping system.</t>
842      <t>To improve resiliency and reduce the overall number of messages exchanged,
843        LISP offers the possibility to leak information, such as reachabilty
844        of locators, directly into data plane packets.  In environments that are not
845        fully trusted, control information gleaned from data-plane packets should be
846        verified before using them.</t>
847      <t>
848   Mappings are the centrepiece of LISP and all precautions must be taken to
849   avoid them to be manipulated or misused by malicious entities.  Using
850   trustable Map-Servers that strictly respect [RFC6833] and the lightweight
851   authentication mechanism proposed by LISP-Sec <xref target="I-D.ietf-lisp-sec" format="default"/> reduces
852   the risk of attacks to the mapping integrity.  In more critical
853   environments, secure measures may be needed.  The way security is
854   implemented for a given mapping system strongly depends on the architecture
855   of the mapping system itself and the threat model assumed for the
856   deployment. Thus, the mapping system security has to be discussed in the 
857relevant documents proposing the mapping system architecture.
858      </t>
859      <t>
860 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 
861 inspect the content of LISP encapsulated packets. </t>
862      <t>
863     Like other map-and-encap mechanisms, LISP enables triangular routing (i.e.,
864 packets of a flow cross different border routers depending on their direction).
865 This means that intermediate boxes may have incomplete view on the traffic they
866 inspect or manipulate. Moreover, LISP-encapsulated packets are routed
867 based on the outer IP address (i.e., the RLOC), and can be
868 delivered to an ETR that is not responsible of the destination EID of the
869 packet or even to a network element that is not an ETR. The mitigation
870 consists in applying appropriate filtering techniques on the network elements
871 that can potentially receive un-expected LISP-encapsulated packets</t>
872      <t>More details about security implications of LISP are discussed in
873        <xref target="I-D.ietf-lisp-threats" format="default"/>.
874      </t>
875    </section>
876    <section numbered="true" toc="default">
877      <name>IANA Considerations</name>
878      <t>This memo includes no request to IANA.</t>
879    </section>
880    <section anchor="Acknowledgements" numbered="true" toc="default">
881      <name>Acknowledgements</name>
882      <t>This document was initiated by Noel Chiappa and much of the core
883 philosophy came from him.  The authors acknowledge the important contributions
884 he has made to this work and thank him for his past efforts.</t>
885      <t>The authors would also like to thank Dino Farinacci, Fabio Maino, 
886 Luigi Iannone,  Sharon Barkai, Isidoros Kouvelas, Christian Cassar, 
887 Florin Coras, Marc Binderberger, Alberto Rodriguez-Natal, Ronald Bonica, 
888 Chad Hintz, Robert Raszuk, Joel M. Halpern, Darrel Lewis, David Black as well as every people acknowledged in <xref target="RFC6830" format="default"/>.</t>
889    </section>
890  </middle>
891  <back>
892    <references>
893      <name>References</name>
894      <references>
895        <name>Normative References</name>
896        <reference anchor="RFC1191" target="https://www.rfc-editor.org/info/rfc1191">
897          <front>
898            <title>Path MTU discovery</title>
899            <seriesInfo name="DOI" value="10.17487/RFC1191"/>
900            <seriesInfo name="RFC" value="1191"/>
901            <author initials="J.C." surname="Mogul" fullname="J.C. Mogul">
902              <organization/>
903            </author>
904            <author initials="S.E." surname="Deering" fullname="S.E. Deering">
905              <organization/>
906            </author>
907            <date year="1990" month="November"/>
908            <abstract>
909              <t>This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path.  It specifies a small change to the way routers generate one type of ICMP message.  For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice.  [STANDARDS-TRACK]</t>
910            </abstract>
911          </front>
912        </reference>
913        <reference anchor="RFC1918" target="https://www.rfc-editor.org/info/rfc1918">
914          <front>
915            <title>Address Allocation for Private Internets</title>
916            <seriesInfo name="DOI" value="10.17487/RFC1918"/>
917            <seriesInfo name="RFC" value="1918"/>
918            <seriesInfo name="BCP" value="5"/>
919            <author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
920              <organization/>
921            </author>
922            <author initials="B." surname="Moskowitz" fullname="B. Moskowitz">
923              <organization/>
924            </author>
925            <author initials="D." surname="Karrenberg" fullname="D. Karrenberg">
926              <organization/>
927            </author>
928            <author initials="G. J." surname="de Groot" fullname="G. J. de Groot">
929              <organization/>
930            </author>
931            <author initials="E." surname="Lear" fullname="E. Lear">
932              <organization/>
933            </author>
934            <date year="1996" month="February"/>
935            <abstract>
936              <t>This document describes address allocation for private internets.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
937            </abstract>
938          </front>
939        </reference>
940        <reference anchor="RFC2992" target="https://www.rfc-editor.org/info/rfc2992">
941          <front>
942            <title>Analysis of an Equal-Cost Multi-Path Algorithm</title>
943            <seriesInfo name="DOI" value="10.17487/RFC2992"/>
944            <seriesInfo name="RFC" value="2992"/>
945            <author initials="C." surname="Hopps" fullname="C. Hopps">
946              <organization/>
947            </author>
948            <date year="2000" month="November"/>
949            <abstract>
950              <t>Equal-cost multi-path (ECMP) is a routing technique for routing packets along multiple paths of equal cost.  The forwarding engine identifies paths by next-hop.  When forwarding a packet the router must decide which next-hop (path) to use.  This document gives an analysis of one method for making that decision.  The analysis includes the performance of the algorithm and the disruption caused by changes to the set of next-hops.  This memo provides information for the Internet community.</t>
951            </abstract>
952          </front>
953        </reference>
954        <reference anchor="RFC3232" target="https://www.rfc-editor.org/info/rfc3232">
955          <front>
956            <title>Assigned Numbers: RFC 1700 is Replaced by an On-line Database</title>
957            <seriesInfo name="DOI" value="10.17487/RFC3232"/>
958            <seriesInfo name="RFC" value="3232"/>
959            <author initials="J." surname="Reynolds" fullname="J. Reynolds" role="editor">
960              <organization/>
961            </author>
962            <date year="2002" month="January"/>
963            <abstract>
964              <t>This memo obsoletes RFC 1700 (STD 2) "Assigned Numbers", which contained an October 1994 snapshot of assigned Internet protocol parameters.  This memo provides information for the Internet community.</t>
965            </abstract>
966          </front>
967        </reference>
968        <reference anchor="RFC4821" target="https://www.rfc-editor.org/info/rfc4821">
969          <front>
970            <title>Packetization Layer Path MTU Discovery</title>
971            <seriesInfo name="DOI" value="10.17487/RFC4821"/>
972            <seriesInfo name="RFC" value="4821"/>
973            <author initials="M." surname="Mathis" fullname="M. Mathis">
974              <organization/>
975            </author>
976            <author initials="J." surname="Heffner" fullname="J. Heffner">
977              <organization/>
978            </author>
979            <date year="2007" month="March"/>
980            <abstract>
981              <t>This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets.  This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively.  [STANDARDS-TRACK]</t>
982            </abstract>
983          </front>
984        </reference>
985        <reference anchor="RFC5944" target="https://www.rfc-editor.org/info/rfc5944">
986          <front>
987            <title>IP Mobility Support for IPv4, Revised</title>
988            <seriesInfo name="DOI" value="10.17487/RFC5944"/>
989            <seriesInfo name="RFC" value="5944"/>
990            <author initials="C." surname="Perkins" fullname="C. Perkins" role="editor">
991              <organization/>
992            </author>
993            <date year="2010" month="November"/>
994            <abstract>
995              <t>This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet.  Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet.  While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet.  The protocol provides for registering the care-of address with a home agent.  The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address.  After arriving at the end of the tunnel, each datagram is then delivered to the mobile node.  [STANDARDS-TRACK]</t>
996            </abstract>
997          </front>
998        </reference>
999        <reference anchor="RFC6275" target="https://www.rfc-editor.org/info/rfc6275">
1000          <front>
1001            <title>Mobility Support in IPv6</title>
1002            <seriesInfo name="DOI" value="10.17487/RFC6275"/>
1003            <seriesInfo name="RFC" value="6275"/>
1004            <author initials="C." surname="Perkins" fullname="C. Perkins" role="editor">
1005              <organization/>
1006            </author>
1007            <author initials="D." surname="Johnson" fullname="D. Johnson">
1008              <organization/>
1009            </author>
1010            <author initials="J." surname="Arkko" fullname="J. Arkko">
1011              <organization/>
1012            </author>
1013            <date year="2011" month="July"/>
1014            <abstract>
1015              <t>This document specifies Mobile IPv6, a protocol that allows nodes to remain reachable while moving around in the IPv6 Internet.  Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet.  While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location.  IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address.  The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address.  To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option.  All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes.  This document obsoletes RFC 3775. [STANDARDS-TRACK]</t>
1016            </abstract>
1017          </front>
1018        </reference>
1019        <reference anchor="RFC3963" target="https://www.rfc-editor.org/info/rfc3963">
1020          <front>
1021            <title>Network Mobility (NEMO) Basic Support Protocol</title>
1022            <seriesInfo name="DOI" value="10.17487/RFC3963"/>
1023            <seriesInfo name="RFC" value="3963"/>
1024            <author initials="V." surname="Devarapalli" fullname="V. Devarapalli">
1025              <organization/>
1026            </author>
1027            <author initials="R." surname="Wakikawa" fullname="R. Wakikawa">
1028              <organization/>
1029            </author>
1030            <author initials="A." surname="Petrescu" fullname="A. Petrescu">
1031              <organization/>
1032            </author>
1033            <author initials="P." surname="Thubert" fullname="P. Thubert">
1034              <organization/>
1035            </author>
1036            <date year="2005" month="January"/>
1037            <abstract>
1038              <t>This document describes the Network Mobility (NEMO) Basic Support protocol that enables Mobile Networks to attach to different points in the Internet.  The protocol is an extension of Mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves.  It also allows every node in the Mobile Network to be reachable while moving around.  The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent.  The protocol is designed so that network mobility is transparent to the nodes inside the Mobile Network.  [STANDARDS-TRACK]</t>
1039            </abstract>
1040          </front>
1041        </reference>
1042        <reference anchor="RFC4984" target="https://www.rfc-editor.org/info/rfc4984">
1043          <front>
1044            <title>Report from the IAB Workshop on Routing and Addressing</title>
1045            <seriesInfo name="DOI" value="10.17487/RFC4984"/>
1046            <seriesInfo name="RFC" value="4984"/>
1047            <author initials="D." surname="Meyer" fullname="D. Meyer" role="editor">
1048              <organization/>
1049            </author>
1050            <author initials="L." surname="Zhang" fullname="L. Zhang" role="editor">
1051              <organization/>
1052            </author>
1053            <author initials="K." surname="Fall" fullname="K. Fall" role="editor">
1054              <organization/>
1055            </author>
1056            <date year="2007" month="September"/>
1057            <abstract>
1058              <t>This document reports the outcome of the Routing and Addressing Workshop that was held by the Internet Architecture Board (IAB) on October 18-19, 2006, in Amsterdam, Netherlands.  The primary goal of the workshop was to develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet routing system.  The key workshop findings include an analysis of the major factors that are driving routing table growth, constraints in router technology, and the limitations of today's Internet addressing architecture.  It is hoped that these findings will serve as input to the IETF community and help identify next steps towards effective solutions.</t>
1059              <t>Note that this document is a report on the proceedings of the workshop.  The views and positions documented in this report are those of the workshop participants and not of the IAB.  Furthermore, note that work on issues related to this workshop report is continuing, and this document does not intend to reflect the increased understanding of issues nor to discuss the range of potential solutions that may be the outcome of this ongoing work.  This memo provides information for the Internet community.</t>
1060            </abstract>
1061          </front>
1062        </reference>
1063        <reference anchor="RFC6830" target="https://www.rfc-editor.org/info/rfc6830">
1064          <front>
1065            <title>The Locator/ID Separation Protocol (LISP)</title>
1066            <seriesInfo name="DOI" value="10.17487/RFC6830"/>
1067            <seriesInfo name="RFC" value="6830"/>
1068            <author initials="D." surname="Farinacci" fullname="D. Farinacci">
1069              <organization/>
1070            </author>
1071            <author initials="V." surname="Fuller" fullname="V. Fuller">
1072              <organization/>
1073            </author>
1074            <author initials="D." surname="Meyer" fullname="D. Meyer">
1075              <organization/>
1076            </author>
1077            <author initials="D." surname="Lewis" fullname="D. Lewis">
1078              <organization/>
1079            </author>
1080            <date year="2013" month="January"/>
1081            <abstract>
1082              <t>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.</t>
1083              <t>Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop.  This document defines an Experimental Protocol for the Internet community.</t>
1084            </abstract>
1085          </front>
1086        </reference>
1087        <reference anchor="RFC6831" target="https://www.rfc-editor.org/info/rfc6831">
1088          <front>
1089            <title>The Locator/ID Separation Protocol (LISP) for Multicast Environments</title>
1090            <seriesInfo name="DOI" value="10.17487/RFC6831"/>
1091            <seriesInfo name="RFC" value="6831"/>
1092            <author initials="D." surname="Farinacci" fullname="D. Farinacci">
1093              <organization/>
1094            </author>
1095            <author initials="D." surname="Meyer" fullname="D. Meyer">
1096              <organization/>
1097            </author>
1098            <author initials="J." surname="Zwiebel" fullname="J. Zwiebel">
1099              <organization/>
1100            </author>
1101            <author initials="S." surname="Venaas" fullname="S. Venaas">
1102              <organization/>
1103            </author>
1104            <date year="2013" month="January"/>
1105            <abstract>
1106              <t>This document describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the Locator/ID Separation Protocol (LISP) architecture.   This document defines an Experimental Protocol for the Internet community.</t>
1107            </abstract>
1108          </front>
1109        </reference>
1110        <reference anchor="RFC6832" target="https://www.rfc-editor.org/info/rfc6832">
1111          <front>
1112            <title>Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites</title>
1113            <seriesInfo name="DOI" value="10.17487/RFC6832"/>
1114            <seriesInfo name="RFC" value="6832"/>
1115            <author initials="D." surname="Lewis" fullname="D. Lewis">
1116              <organization/>
1117            </author>
1118            <author initials="D." surname="Meyer" fullname="D. Meyer">
1119              <organization/>
1120            </author>
1121            <author initials="D." surname="Farinacci" fullname="D. Farinacci">
1122              <organization/>
1123            </author>
1124            <author initials="V." surname="Fuller" fullname="V. Fuller">
1125              <organization/>
1126            </author>
1127            <date year="2013" month="January"/>
1128            <abstract>
1129              <t>This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP) to interoperate with Internet sites that may be using either IPv4, IPv6, or both but that are not running LISP.  A fundamental property of LISP-speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive.  While EIDs are syntactically identical to IPv4 or IPv6 addresses, normally routes to them are not carried in the global routing system, so an interoperability mechanism is needed for non- LISP-speaking sites to exchange traffic with LISP-speaking sites. This document introduces three such mechanisms.  The first uses a new network element, the LISP Proxy Ingress Tunnel Router (Proxy-ITR), to act as an intermediate LISP Ingress Tunnel Router (ITR) for non-LISP- speaking hosts.  Second, this document adds Network Address Translation (NAT) functionality to LISP ITRs and LISP Egress Tunnel Routers (ETRs) to substitute routable IP addresses for non-routable EIDs.  Finally, this document introduces the Proxy Egress Tunnel Router (Proxy-ETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation.  This document defines  an Experimental Protocol for the Internet community.</t>
1130            </abstract>
1131          </front>
1132        </reference>
1133        <reference anchor="RFC6833" target="https://www.rfc-editor.org/info/rfc6833">
1134          <front>
1135            <title>Locator/ID Separation Protocol (LISP) Map-Server Interface</title>
1136            <seriesInfo name="DOI" value="10.17487/RFC6833"/>
1137            <seriesInfo name="RFC" value="6833"/>
1138            <author initials="V." surname="Fuller" fullname="V. Fuller">
1139              <organization/>
1140            </author>
1141            <author initials="D." surname="Farinacci" fullname="D. Farinacci">
1142              <organization/>
1143            </author>
1144            <date year="2013" month="January"/>
1145            <abstract>
1146              <t>This document describes the Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two new types of LISP- speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID to Routing Locator mapping databases.</t>
1147              <t>By using this service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers and Egress Tunnel Routers are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs. Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP.  This document defines an Experimental Protocol  for the Internet community.</t>
1148            </abstract>
1149          </front>
1150        </reference>
1151        <reference anchor="RFC6834" target="https://www.rfc-editor.org/info/rfc6834">
1152          <front>
1153            <title>Locator/ID Separation Protocol (LISP) Map-Versioning</title>
1154            <seriesInfo name="DOI" value="10.17487/RFC6834"/>
1155            <seriesInfo name="RFC" value="6834"/>
1156            <author initials="L." surname="Iannone" fullname="L. Iannone">
1157              <organization/>
1158            </author>
1159            <author initials="D." surname="Saucez" fullname="D. Saucez">
1160              <organization/>
1161            </author>
1162            <author initials="O." surname="Bonaventure" fullname="O. Bonaventure">
1163              <organization/>
1164            </author>
1165            <date year="2013" month="January"/>
1166            <abstract>
1167              <t>This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets.  The proposed approach is based on associating a version number to EID-to-RLOC mappings and the transport of such a version number in the LISP-specific header of LISP-encapsulated packets.  LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets.  The mechanism is transparent to implementations not supporting this feature, since in the LISP- specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support the mechanism.  This document defines an Experimental Protocol for the  Internet community.</t>
1168            </abstract>
1169          </front>
1170        </reference>
1171        <reference anchor="RFC6835" target="https://www.rfc-editor.org/info/rfc6835">
1172          <front>
1173            <title>The Locator/ID Separation Protocol Internet Groper (LIG)</title>
1174            <seriesInfo name="DOI" value="10.17487/RFC6835"/>
1175            <seriesInfo name="RFC" value="6835"/>
1176            <author initials="D." surname="Farinacci" fullname="D. Farinacci">
1177              <organization/>
1178            </author>
1179            <author initials="D." surname="Meyer" fullname="D. Meyer">
1180              <organization/>
1181            </author>
1182            <date year="2013" month="January"/>
1183            <abstract>
1184              <t>A simple tool called the Locator/ID Separation Protocol (LISP) Internet Groper or 'lig' can be used to query the LISP mapping database.  This document describes how it works.  This document  is not an Internet Standards Track specification; it is published for informational purposes.</t>
1185            </abstract>
1186          </front>
1187        </reference>
1188        <reference anchor="RFC6836" target="https://www.rfc-editor.org/info/rfc6836">
1189          <front>
1190            <title>Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)</title>
1191            <seriesInfo name="DOI" value="10.17487/RFC6836"/>
1192            <seriesInfo name="RFC" value="6836"/>
1193            <author initials="V." surname="Fuller" fullname="V. Fuller">
1194              <organization/>
1195            </author>
1196            <author initials="D." surname="Farinacci" fullname="D. Farinacci">
1197              <organization/>
1198            </author>
1199            <author initials="D." surname="Meyer" fullname="D. Meyer">
1200              <organization/>
1201            </author>
1202            <author initials="D." surname="Lewis" fullname="D. Lewis">
1203              <organization/>
1204            </author>
1205            <date year="2013" month="January"/>
1206            <abstract>
1207              <t>This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map-Resolver (MR) to find the Egress Tunnel Router (ETR) that holds the mapping information for a particular Endpoint Identifier (EID).  The MR can then query that ETR to obtain the actual mapping information, which consists of a list of Routing Locators (RLOCs) for the EID.  Termed the Alternative Logical Topology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and Generic Routing Encapsulation (GRE).  This document defines an Experimental  Protocol for the Internet community.</t>
1208            </abstract>
1209          </front>
1210        </reference>
1211        <reference anchor="RFC6837" target="https://www.rfc-editor.org/info/rfc6837">
1212          <front>
1213            <title>NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database</title>
1214            <seriesInfo name="DOI" value="10.17487/RFC6837"/>
1215            <seriesInfo name="RFC" value="6837"/>
1216            <author initials="E." surname="Lear" fullname="E. Lear">
1217              <organization/>
1218            </author>
1219            <date year="2013" month="January"/>
1220            <abstract>
1221              <t>The Locator/ID Separation Protocol (LISP) is a protocol to encapsulate IP packets in order to allow end sites to route to one another without injecting routes from one end of the Internet to another.  This memo presents an experimental database and a discussion of methods to transport the mapping of Endpoint IDs (EIDs) to Routing Locators (RLOCs) to routers in a reliable, scalable, and secure manner.  Our analysis concludes that transport of all EID-to- RLOC mappings scales well to at least 10^8 entries.  This document  defines an Experimental Protocol for the Internet community.</t>
1222            </abstract>
1223          </front>
1224        </reference>
1225        <reference anchor="RFC7215" target="https://www.rfc-editor.org/info/rfc7215">
1226          <front>
1227            <title>Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations</title>
1228            <seriesInfo name="DOI" value="10.17487/RFC7215"/>
1229            <seriesInfo name="RFC" value="7215"/>
1230            <author initials="L." surname="Jakab" fullname="L. Jakab">
1231              <organization/>
1232            </author>
1233            <author initials="A." surname="Cabellos-Aparicio" fullname="A. Cabellos-Aparicio">
1234              <organization/>
1235            </author>
1236            <author initials="F." surname="Coras" fullname="F. Coras">
1237              <organization/>
1238            </author>
1239            <author initials="J." surname="Domingo-Pascual" fullname="J. Domingo-Pascual">
1240              <organization/>
1241            </author>
1242            <author initials="D." surname="Lewis" fullname="D. Lewis">
1243              <organization/>
1244            </author>
1245            <date year="2014" month="April"/>
1246            <abstract>
1247              <t>This document is a snapshot of different Locator/Identifier Separation Protocol (LISP) deployment scenarios.  It discusses the placement of new network elements introduced by the protocol, representing the thinking of the LISP working group as of Summer 2013.  LISP deployment scenarios may have evolved since then.  This memo represents one stable point in that evolution of understanding.</t>
1248            </abstract>
1249          </front>
1250        </reference>
1251        <reference anchor="RFC6935" target="https://www.rfc-editor.org/info/rfc6935">
1252          <front>
1253            <title>IPv6 and UDP Checksums for Tunneled Packets</title>
1254            <seriesInfo name="DOI" value="10.17487/RFC6935"/>
1255            <seriesInfo name="RFC" value="6935"/>
1256            <author initials="M." surname="Eubanks" fullname="M. Eubanks">
1257              <organization/>
1258            </author>
1259            <author initials="P." surname="Chimento" fullname="P. Chimento">
1260              <organization/>
1261            </author>
1262            <author initials="M." surname="Westerlund" fullname="M. Westerlund">
1263              <organization/>
1264            </author>
1265            <date year="2013" month="April"/>
1266            <abstract>
1267              <t>This document updates the IPv6 specification (RFC 2460) to improve performance when a tunnel protocol uses UDP with IPv6 to tunnel packets.  The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for tunnel protocols whose header information is protected on the "inner" packet being carried. Relaxing this requirement removes the overhead associated with the computation of UDP checksums on IPv6 packets that carry the tunnel protocol packets.  This specification describes how the IPv6 UDP checksum requirement can be relaxed when the encapsulated packet itself contains a checksum.  It also describes the limitations and risks of this approach and discusses the restrictions on the use of this method.</t>
1268            </abstract>
1269          </front>
1270        </reference>
1271        <reference anchor="RFC6936" target="https://www.rfc-editor.org/info/rfc6936">
1272          <front>
1273            <title>Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums</title>
1274            <seriesInfo name="DOI" value="10.17487/RFC6936"/>
1275            <seriesInfo name="RFC" value="6936"/>
1276            <author initials="G." surname="Fairhurst" fullname="G. Fairhurst">
1277              <organization/>
1278            </author>
1279            <author initials="M." surname="Westerlund" fullname="M. Westerlund">
1280              <organization/>
1281            </author>
1282            <date year="2013" month="April"/>
1283            <abstract>
1284              <t>This document provides an applicability statement for the use of UDP transport checksums with IPv6.  It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum.  It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations, and it examines the role of the IPv6 UDP transport checksum.  The document also identifies issues and constraints for deployment on network paths that include middleboxes.  An appendix presents a summary of the trade-offs that were considered in evaluating the safety of the update to RFC 2460 that changes the use of the UDP checksum with IPv6.</t>
1285            </abstract>
1286          </front>
1287        </reference>
1288        <reference anchor="RFC7052" target="https://www.rfc-editor.org/info/rfc7052">
1289          <front>
1290            <title>Locator/ID Separation Protocol (LISP) MIB</title>
1291            <seriesInfo name="DOI" value="10.17487/RFC7052"/>
1292            <seriesInfo name="RFC" value="7052"/>
1293            <author initials="G." surname="Schudel" fullname="G. Schudel">
1294              <organization/>
1295            </author>
1296            <author initials="A." surname="Jain" fullname="A. Jain">
1297              <organization/>
1298            </author>
1299            <author initials="V." surname="Moreno" fullname="V. Moreno">
1300              <organization/>
1301            </author>
1302            <date year="2013" month="October"/>
1303            <abstract>
1304              <t>This document defines the MIB module that contains managed objects to support the monitoring devices of the Locator/ID Separation Protocol (LISP).  These objects provide information useful for monitoring LISP devices, including determining basic LISP configuration information, LISP functional status, and operational counters and other statistics.</t>
1305            </abstract>
1306          </front>
1307        </reference>
1308        <reference anchor="I-D.ietf-lisp-ddt" target="http://www.ietf.org/internet-drafts/draft-ietf-lisp-ddt-09.txt">
1309          <front>
1310            <title>LISP Delegated Database Tree</title>
1311            <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-ddt-09"/>
1312            <author initials="V" surname="Fuller" fullname="Vince Fuller">
1313              <organization/>
1314            </author>
1315            <author initials="D" surname="Lewis" fullname="Darrel Lewis">
1316              <organization/>
1317            </author>
1318            <author initials="V" surname="Ermagan" fullname="Vina Ermagan">
1319              <organization/>
1320            </author>
1321            <author initials="A" surname="Jain" fullname="Amit Jain">
1322              <organization/>
1323            </author>
1324            <author initials="A" surname="Smirnov" fullname="Anton Smirnov">
1325              <organization/>
1326            </author>
1327            <date month="January" day="18" year="2017"/>
1328            <abstract>
1329              <t>This document describes the LISP Delegated Database Tree (LISP-DDT), a hierarchical, distributed database which embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs).  It is a statically-defined distribution of the EID namespace among a set of LISP-speaking servers, called DDT nodes.  Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated.</t>
1330            </abstract>
1331          </front>
1332        </reference>
1333        <reference anchor="I-D.ietf-lisp-lcaf" target="http://www.ietf.org/internet-drafts/draft-ietf-lisp-lcaf-22.txt">
1334          <front>
1335            <title>LISP Canonical Address Format (LCAF)</title>
1336            <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-lcaf-22"/>
1337            <author initials="D" surname="Farinacci" fullname="Dino Farinacci">
1338              <organization/>
1339            </author>
1340            <author initials="D" surname="Meyer" fullname="David Meyer">
1341              <organization/>
1342            </author>
1343            <author initials="J" surname="Snijders" fullname="Job Snijders">
1344              <organization/>
1345            </author>
1346            <date month="November" day="28" year="2016"/>
1347            <abstract>
1348              <t>This document defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System.</t>
1349            </abstract>
1350          </front>
1351        </reference>
1352        <reference anchor="I-D.ietf-lisp-threats" target="http://www.ietf.org/internet-drafts/draft-ietf-lisp-threats-15.txt">
1353          <front>
1354            <title>LISP Threats Analysis</title>
1355            <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-threats-15"/>
1356            <author initials="D" surname="Saucez" fullname="Damien Saucez">
1357              <organization/>
1358            </author>
1359            <author initials="L" surname="Iannone" fullname="Luigi Iannone">
1360              <organization/>
1361            </author>
1362            <author initials="O" surname="Bonaventure" fullname="Olivier Bonaventure">
1363              <organization/>
1364            </author>
1365            <date month="January" day="29" year="2016"/>
1366            <abstract>
1367              <t>This document provides a threat analysis of the Locator/Identifier Separation Protocol (LISP).</t>
1368            </abstract>
1369          </front>
1370        </reference>
1371        <reference anchor="I-D.ietf-lisp-sec" target="http://www.ietf.org/internet-drafts/draft-ietf-lisp-sec-18.txt">
1372          <front>
1373            <title>LISP-Security (LISP-SEC)</title>
1374            <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-sec-18"/>
1375            <author initials="F" surname="Maino" fullname="Fabio Maino">
1376              <organization/>
1377            </author>
1378            <author initials="V" surname="Ermagan" fullname="Vina Ermagan">
1379              <organization/>
1380            </author>
1381            <author initials="A" surname="Cabellos-Aparicio" fullname="Albert Cabellos-Aparicio">
1382              <organization/>
1383            </author>
1384            <author initials="D" surname="Saucez" fullname="Damien Saucez">
1385              <organization/>
1386            </author>
1387            <date month="June" day="2" year="2019"/>
1388            <abstract>
1389              <t>This memo specifies LISP-SEC, a set of security mechanisms that provides origin authentication, integrity and anti-replay protection to LISP's EID-to-RLOC mapping data conveyed via mapping lookup process.  LISP-SEC also enables verification of authorization on EID- prefix claims in Map-Reply messages.</t>
1390            </abstract>
1391          </front>
1392        </reference>
1393      </references>
1394      <references>
1395        <name>Informative References</name>
1396        <reference anchor="Jakab" target="">
1397          <front>
1398            <title>LISP-TREE: A DNS Hierarchy to Support the LISP Mapping
1399          System, IEEE Journal on Selected Areas in Communications, vol. 28,
1400          no. 8, pp. 1332-1343</title>
1401            <author initials="L." surname="Jakab"/>
1402            <author initials="A." surname="Cabellos"/>
1403            <author initials="D." surname="Saucez"/>
1404            <author initials="O." surname="Bonaventure"/>
1405            <date month="October" year="2010"/>
1406          </front>
1407        </reference>
1408        <reference anchor="Mathy" target="">
1409          <front>
1410            <title>LISP-DHT: Towards a DHT to map identifiers onto locators. 
1411   The ACM ReArch, Re-Architecting the Internet. Madrid (Spain)</title>
1412            <author initials="L." surname="Mathy"/>
1413            <author initials="L." surname="Iannone"/>
1414            <author initials="O." surname="Bonaventure"/>
1415            <date month="December" year="2008"/>
1416          </front>
1417        </reference>
1418        <reference anchor="I-D.cheng-lisp-shdht" target="http://www.ietf.org/internet-drafts/draft-cheng-lisp-shdht-04.txt">
1419          <front>
1420            <title>LISP Single-Hop DHT Mapping Overlay</title>
1421            <seriesInfo name="Internet-Draft" value="draft-cheng-lisp-shdht-04"/>
1422            <author fullname="Li Cheng" initials="L" surname="Cheng">
1423              <organization/>
1424            </author>
1425            <author fullname="Jun Wang" initials="J" surname="Wang">
1426              <organization/>
1427            </author>
1428            <date day="15" month="July" year="2013"/>
1429            <abstract>
1430              <t>This draft specifies the LISP Single-Hop Distributed Hash Table
1431            Mapping Database (LISP-SHDHT), a distributed mapping database
1432            which consists of a set of SHDHT Nodes to provide mappings from
1433            LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). EID
1434            namespace is dynamically distributed among SHDHT Nodes based on
1435            DHT Hash algorithm. Each SHDHT Node is configured with one or more
1436            hash spaces which contain multiple EID-prefixes along with RLOCs
1437            of corresponding Map Servers.</t>
1438            </abstract>
1439          </front>
1440        </reference>
1441        <reference anchor="I-D.curran-lisp-emacs" target="http://tools.ietf.org/html/draft-curran-lisp-emacs-00">
1442          <front>
1443            <title>EID Mappings Multicast Across Cooperating Systems for LISP</title>
1444            <seriesInfo name="Internet-Draft" value="draft-curran-lisp-emacs-00"/>
1445            <author fullname="S. Brim" initials="S" surname="Brim">
1446              <organization/>
1447            </author>
1448            <author fullname="Dino Farinacci" initials="D" surname="Farinacci">
1449              <organization/>
1450            </author>
1451            <author fullname="Dave Meyer" initials="D" surname="Meyer">
1452              <organization/>
1453            </author>
1454            <author fullname="J Curran" initials="J" surname="Curran">
1455              <organization/>
1456            </author>
1457            <date day="9" month="November" year="2007"/>
1458            <abstract>
1459              <t> One of the potential problems with the "map-and-encapsulate"
1460   approaches to routing architecture is that there is a significant
1461   chance of packets being dropped while a mapping is being retrieved.
1462   Some approaches pre-load ingress tunnel routers with at least part of
1463   the mapping database.  Some approaches try to solve this by providing intermediate "default" routers which have a great deal more knowledge
1464   than a typical ingress tunnel router.  This document proposes a
1465   scheme which does not drop packets yet does not require a great deal
1466   of knowledge in any router.  However, there are still some issues
1467   that need to be worked out.</t>
1468            </abstract>
1469          </front>
1470        </reference>
1471        <reference anchor="DDT-ROOT" target="">
1472          <front>
1473            <title>http://ddt-root.org/</title>
1474            <author surname="LISP DDT ROOT"/>
1475            <date month="August" year="2013"/>
1476          </front>
1477        </reference>
1478        <reference anchor="Quoitin" target="">
1479          <front>
1480            <title>"Evaluating the Benefits of the Locator/Identifier Separation" in Proceedings of 2Nd ACM/IEEE International Workshop on Mobility in the Evolving Internet Architecture</title>
1481            <author initials="B." surname="Quoitin"/>
1482            <author initials="L." surname="Iannone"/>
1483            <author initials="C." surname="Launois"/>
1484            <author initials="O." surname="Bonaventure"/>
1485            <date year="2007"/>
1486          </front>
1487        </reference>
1488      </references>
1489    </references>
1490    <section numbered="true" toc="default">
1491      <name>A Brief History of Location/Identity Separation</name>
1492      <t>The LISP architecture for separation of location and identity resulted from
1493      the discussions of this topic at the Amsterdam IAB Routing and
1494      Addressing Workshop, which took place in October 2006 <xref target="RFC4984" format="default"/>.</t>
1495      <t>A small group of like-minded personnel spontaneously formed immediately after that
1496 workshop, to work on an idea that came out of informal discussions at
1497 the workshop and on various mailing lists.  The first
1498 Internet-Draft on LISP appeared in January, 2007.</t>
1499      <t>Trial implementations started at that time, with initial trial
1500      deployments underway since June 2007; the results of early experience
1501      have been fed back into the design in a continuous, ongoing process
1502      over several years.  LISP at this point represents a moderately
1503      mature system, having undergone a long organic series of changes and
1504      updates.</t>
1505      <t>LISP transitioned from an IRTF activity to an IETF WG in March 2009,
1506      and after numerous revisions, the basic specifications moved to
1507      becoming RFCs at the start of 2013 (although work to expand and
1508      improve it, and find new uses for it, continues, and undoubtly will
1509      for a long time to come).</t>
1510      <section numbered="true" toc="default">
1511        <name>Old LISP Models</name>
1512        <t>LISP, as initially conceived, had a number of potential operating
1513      modes, named 'models'.  Although they are no used anymore, one
1514      occasionally sees mention of them, so they are briefly described
1515      here.</t>
1516        <dl newline="false" spacing="normal">
1517          <dt>LISP 1:</dt>
1518          <dd>EIDs all appear in the normal routing and forwarding
1519            tables of the network (i.e. they are 'routable');this property is
1520            used to 'bootstrap' operation, by using this to load EID-&gt;RLOC
1521            mappings.  Packets were sent with the EID as the destination in
1522            the outer wrapper; when an ETR saw such a packet, it would send a
1523            Map-Reply to the source ITR, giving the full mapping.</dd>
1524          <dt>LISP 1.5:</dt>
1525          <dd>Similar to LISP 1, but the routability of EIDs happens
1526            on a separate network.</dd>
1527          <dt>LISP 2:</dt>
1528          <dd>EIDs are not routable; EID-&gt;RLOC mappings are available
1529            from the DNS.</dd>
1530          <dt>LISP 3:</dt>
1531          <dd>EIDs are not routable; and have to be looked up in in a
1532            new EID-&gt;RLOC mapping database (in the initial concept, a system
1533            using Distributed Hash Tables).  Two variants were possible: a
1534            'push' system, in which all mappings were distributed to all ITRs,
1535            and a 'pull' system in which ITRs load the mappings they need, as
1536            needed.</dd>
1537        </dl>
1538      </section>
1539    </section>
1540  </back>
  • <?xml version="1.0" encoding="utf-8"?>
  • <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
  • <?rfc toc="yes"?>
  • <?rfc tocompact="yes"?>
  • <?rfc tocdepth="3"?>
  • <?rfc tocindent="yes"?>
  • <?rfc symrefs="yes"?>
  • <?rfc sortrefs="yes"?>
  • <?rfc comments="yes"?>
  • <?rfc inline="yes"?>
  • <?rfc compact="yes"?>
  • <?rfc subcompact="no"?>
  • <rfc category="info" docName="draft-ietf-lisp-introduction-13.txt" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3" tocInclude="true" symRefs="true" sortRefs="true" number="0000" consensus="true">
    • <-- xml2rfc v2v3 conversion 2.23.0 -->
    • <front>
      • <title abbrev="LISP Introduction">
        • An Architectural Introduction to the Locator/ID Separation Protocol (LISP)
        • </title>
      • <seriesInfo name="Internet-Draft" "RFC" value="draft-ietf-lisp-introduction-13.txt" "0000" />
      • <author fullname="Albert Cabellos" initials="A." surname="Cabellos">
        • <organization>
          • UPC-BarcelonaTech
          • </organization>
        • <address>
          • <postal>
            • <street>
              • c/ Jordi Girona 1-3
              • </street>
            • <city>
              • Barcelona
              • </city>
            • <code>
              • 08034
              • </code>
            • <region>
              • Catalonia
              • </region>
            • <country>
              • Spain
              • </country>
            • </postal>
          • <email>
            • acabello@ac.upc.edu
            • </email>
          • </address>
        • </author>
      • <author fullname="Damien Saucez (Ed.)" initials="D." surname="Saucez (Ed.)">
        • <organization>
          • INRIA
          • </organization>
        • <address>
          • <postal>
            • <street>
              • 2004 route des Lucioles BP 93
              • </street>
            • <city>
              • Sophia Antipolis Cedex
              • </city>
            • <code>
              • 06902
              • </code>
            • <country>
              • France
              • </country>
            • </postal>
          • <email>
            • damien.saucez@inria.fr
            • </email>
          • </address>
        • </author>
      • <date day="02" month="April" "August" year="2015" "2019" />
      • <area>
        • Routing Area
        • </area>
      • <keyword>
        • LISP
        • </keyword>
      • <keyword>
        • Architecture
        • </keyword>
      • <abstract>
        • <t>
          • 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, more details can be found in RFC6830, the protocol specification.
          • </t>
        • </abstract>
      • </front>
    • <middle>
      • <section numbered="true" toc="default">
        • <name>
          • Introduction
          • </name>
        • <t>
          • This document introduces the Locator/ID Separation Protocol (LISP) <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6830" format="default"/> architecture, its main operational mechanisms and its design rationale. Fundamentally, LISP is built following a well-known architectural idea: decoupling the IP address overloaded semantics. Indeed and as pointed out by Noel Chiappa <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC4984" format="default"/>, currently IP addresses both identify the topological location of a network attachment point as well as the node's identity. However, nodes and routing have fundamentally different requirements, routing systems require that addresses are aggregatable and have topological meaning, while nodes require to be identified independently of their current location <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC4984" format="default"/>.
          • </t>
        • <t>
          • LISP creates two separate namespaces, EIDs (End-host IDentifiers) and RLOCs (Routing LOCators), both are syntactically identical to the current IPv4 and IPv6 addresses. 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 LISP-capable routers. 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.
          • </t>
        • <t>
          • In summary:
          • </t>
        • <ul spacing="normal">
          • <li>
            • RLOCs have meaning only in the underlay network, that is the underlying core routing system.
            • </li>
          • <li>
            • EIDs have meaning only in the overlay network, which is the encapsulation relationship between LISP-capable routers.
            • </li>
          • <li>
            • The LISP edge maps EIDs to RLOCs
            • </li>
          • <li>
            • Within the underlay network, RLOCs have both locator and identifier semantics
            • </li>
          • <li>
            • An EID within a LISP site carries both identifier and locator semantics to other nodes within that site
            • </li>
          • <li>
            • An EID within a LISP site carries identifier and limited locator semantics to nodes at other LISP sites (i.e., enough locator information to tell that the EID is external to the site)
            • </li>
          • </ul>
        • <t>
          • The relationship described above is not unique to LISP but it is common to other overlay technologies.
          • </t>
        • <t>
          • The initial motivation in the LISP effort is to be found in the routing scalability problem <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC4984" format="default"/>, where, if LISP were to be completely deployed, the Internet core is populated with RLOCs while Traffic Engineering mechanisms are pushed to the Mapping System. In such scenario RLOCs are quasi-static (i.e., low churn), hence making the routing system scalable <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="Quoitin" format="default"/>, while EIDs can roam anywhere with no churn to the underlying routing system. <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC7215" format="default"/> 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 such as Traffic Engineering (TE), multihoming, and mobility among others.
          • </t>
        • <t>
          • 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. The interested reader should refer to the main LISP specifications <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6830" format="default"/> and the complementary documents <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6831" format="default"/>, <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6832" format="default"/>, <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6833" format="default"/>, <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6834" format="default"/>, <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6835" format="default"/>, <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6836" format="default"/>, <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC7052" format="default"/> for the protocol specifications along with the LISP deployment guidelines <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC7215" format="default"/>.
          • </t>
        • </section>
      • <section numbered="true" toc="default">
        • <name>
          • Definition of Terms
          • </name>
        • <dl newline="false" "true" spacing="normal">
          • <dt>
            • Endpoint IDentifier (EID):
            • </dt>
          • <dd>
            • EIDs are addresses used to uniquely identify nodes irrespective of their topological location and are typically routed intra-domain.
            • </dd>
          • <dt>
            • Routing LOcator (RLOC):
            • </dt>
          • <dd>
            • RLOCs are addresses assigned topologically to network attachment points and typically routed inter-domain.
            • </dd>
          • <dt>
            • Ingress Tunnel Router (ITR):
            • </dt>
          • <dd>
            • A LISP-capable router that encapsulates packets from a LISP site towards the core network.
            • </dd>
          • <dt>
            • Egress Tunnel Router (ETR):
            • </dt>
          • <dd>
            • A LISP-capable router that decapsulates packets from the core of the network towards a LISP site.
            • </dd>
          • <dt>
            • xTR:
            • </dt>
          • <dd>
            • A router that implements both ITR and ETR functionalities.
            • </dd>
          • <dt>
            • Map-Request:
            • </dt>
          • <dd>
            • A LISP signaling message used to request an EID-to-RLOC mapping.
            • </dd>
          • <dt>
            • Map-Reply:
            • </dt>
          • <dd>
            • A LISP signaling message sent in response to a Map-Request that contains a resolved EID-to-RLOC mapping.
            • </dd>
          • <dt>
            • Map-Register:
            • </dt>
          • <dd>
            • A LISP signaling message used to register an EID-to-RLOC mapping.
            • </dd>
          • <dt>
            • Map-Notify:
            • </dt>
          • <dd>
            • A LISP signaling message sent in response of a Map-Register to acknowledge the correct reception of an EID-to-RLOC mapping.
            • </dd>
          • </dl>
        • <t>
          • This document describes the LISP architecture and does not introduce any new term. The reader is referred to <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6830" format="default"/>, <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6831" format="default"/>, <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6832" format="default"/>, <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6833" format="default"/>, <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6834" format="default"/>, <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6835" format="default"/>, <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6836" format="default"/>, <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC7052" format="default"/>, <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC7215" format="default"/> for the complete definition of terms.
          • </t>
        • </section>
      • <section numbered="true" toc="default">
        • <name>
          • LISP Architecture
          • </name>
        • <t>
          • This section presents the LISP architecture, it first details the design principles of LISP and then it proceeds to describe its main aspects: data-plane, control-plane, and internetworking mechanisms.
          • </t>
        • <section numbered="true" toc="default">
          • <name>
            • Design Principles
            • </name>
          • <t>
            • The LISP architecture is built on top of four basic design principles:
            • </t>
          • <ul spacing="normal">
            • <li>
              • Locator/Identifier split: By decoupling the overloaded semantics of the current IP addresses the Internet core can be assigned identity meaningful addresses and hence, can use aggregation to scale. Devices are assigned with relatively opaque topologically meaningful addresses that are independent of their topological location.
              • </li>
            • <li>
              • Overlay architecture: Overlays route packets over the current Internet, allowing deployment of new protocols without changing the current infrastructure hence, resulting into a low deployment cost.
              • </li>
            • <li>
              • Decoupled data and control-plane: Separating the data-plane from the 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 to be added. While decoupled, data and control-plane are not completely isolated because the LISP data-plane may trigger control-plane activity.
              • </li>
            • <li>
              • Incremental deployability: This principle ensures that the protocol interoperates with the legacy Internet while providing some of the targeted benefits to early adopters.
              • </li>
            • </ul>
          • </section>
        • <section numbered="true" toc="default">
          • <name>
            • Overview of the Architecture
            • </name>
          • <t>
            • LISP splits architecturally the core from the edge of the Internet by creating two separate namespaces: Endpoint Identifiers (EIDs) and Routing 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 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 and because of this, EIDs are usually routable at the edge (within LISP sites) or in the non-LISP Internet; see Section 3.5 <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="internetwork"/> for discussion of LISP site internetworking with non-LISP sites and domains in the Internet.
            • </t>
          • <t>
            • LISP sites (at the edge of the Internet) are connected to the core of the Internet by means of LISP-capable routers (e.g., border routers). LISP sites are connected across the 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 can perform both ITR and ETR operations. In this context ITRs encapsulate packets while ETRs decapsulate them, hence LISP operates as an overlay on top of the current Internet core.
            • </t>
          • <figure anchor="fig1" title="A Schema of the LISP Architecture">
            • <artwork name="" type="" align="left" alt="">

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

                                       /-----------------\                 ---
                                       |     Mapping     |                  | 
                                       .     System      |                  | Control
                                      -|                 |`,                | Plane  
                                    ,' \-----------------/  .               |
                                   /                         |             ---
                   ,..,           -        _,....,,          |      ,..,    | 
                 /     `        ,'      ,-`        `',       |    /     `   | 
                /        \ +-----+   ,'              `,  +-----+ /        \ |        
                |  EID   |-| xTR |--/        RLOC     ,--| xTR |-|  EID   | | Data  
                | Space  |-|     |--|       Space     |--|     |-| Space  | | Plane 
                \        / +-----+  .                 /  +-----+ \        / |        
                 `.    .'            `.              ,'           `.    .'  |   
                   `'-`                `.,        ,.'               `'-`   ---  
                  LISP Site (Edge)            Core              LISP Site (Edge)
                           Figure 1.- A schema of the LISP Architecture
              • </artwork>
            • </figure>
          • <t>
            • With LISP, the core uses RLOCs, an RLOC is an IPv4 or IPv6 address assigned to an Internet-facing network interface of an ITR or ETR. 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.
            • </t>
          • <t>
            • A database which 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 policies and can be configured to achieve multihoming and load balancing. The LISP Mapping System is conceptually similar to the DNS where it is organized as a distributed multi-organization network database. With LISP, ETRs register mappings while ITRs retrieve them.
            • </t>
          • <t>
            • Finally, the LISP architecture emphasizes incremental deployment. Given that LISP represents an overlay to the current Internet architecture, endhosts as well as intra and inter-domain routers remain unchanged, and the only required changes to the existing infrastructure are to routers connecting the EID with the RLOC space. Additionally, LISP requires the deployment of an independent Mapping System, such distributed database is a new network entity.
            • </t>
          • <t>
            • 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.
            • </t>
          • <figure anchor="fig2" title="Packet Flow Sequence in LISP">
            • <artwork name="" type="" align="left" alt="">

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

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

                Figure 2.- Packet flow sequence in LISP
              • </artwork>
            • </figure>
          • <ol spacing="normal" type="1">
            • <li>
              • HostA retrieves the EID_B of HostB, typically querying the DNS and obtaining an A or AAAA record. Then it generates an IP packet as in the Internet, the packet has source address EID_A and destination address EID_B.
              • </li>
            • <li>
              • The packet is routed towards ITR_A in the LISP site using standard intra-domain mechanisms.
              • </li>
            • <li>
              • ITR_A upon receiving the packet queries the Mapping System to retrieve the locator of ETR_B that is servicing HostB's EID_B. In order to do so it uses a LISP control message called Map-Request, the message contains EID_B as the lookup key. In turn it receives another LISP control message called Map-Reply, the message contains two locators: RLOC_B1 and RLOC_B2 along with traffic engineering policies: priority and weight per locator. Note that a Map-Reply can contain more locators if needed. ITR_A also stores the mapping in a local cache to speed-up forwarding of subsequent packets.
              • </li>
            • <li>
              • 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 outer header has RLOC_A1 as source and RLOC_B1 as destination, the inner original header has EID_A as source and EID_B as destination. Furthermore ITR_A adds a LISP header, more details about LISP encapsulation can be found in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="encapsulation" format="default"/>.
              • </li>
            • <li>
              • The encapsulated packet is forwarded by the Internet core as a normal IP packet, making the EID invisible from the Internet core.
              • </li>
            • <li>
              • Upon reception of the encapsulated packet by ETR_B, it decapsulates the packet and forwards it to HostB.
              • </li>
            • </ol>
          • </section>
        • <section numbered="true" toc="default">
          • <name>
            • Data-Plane
            • </name>
          • <t>
            • This section provides a high-level description of the LISP data-plane, which is specified in detail in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6830" format="default"/>. The LISP 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 are LISP capable routers that connect the EID with the RLOC space (ITR) and vice versa (ETR).
            • </t>
          • <section anchor="encapsulation" numbered="true" toc="default">
            • <name>
              • LISP Encapsulation
              • </name>
            • <t>
              • ITRs encapsulate data packets towards ETRs. LISP data packets are encapsulated using UDP (port 4341), the source port is usually selected by the ITR using a 5-tuple hash of the inner header (so to be consistent in case of multi-path solutions such as ECMP <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC2992" format="default"/>) and ignored on reception. LISP data packets are often encapsulated in UDP packets that include a zero checksum <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6935" format="default"/> <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6936" format="default"/> that is not 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 UDP encapsulation checksum, xTRs can forward packets more efficiently. 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.
              • </t>
            • <t>
              • 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 by ETRs. It carries reachability information (see more details in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="reachability" format="default"/>) and the Instance ID field. The Instance ID field is used to distinguish traffic to/from different tenant address spaces at the LISP site and that may use overlapped but logically separated EID addressing.
              • </t>
            • <t>
              • Overall, LISP works on 4 headers, the inner header the source constructed, and the 3 headers a LISP encapsulator prepends ("outer" to "inner"):
              • </t>
            • <ol spacing="normal" type="1">
              • <li>
                • Outer IP header containing RLOCs as source and destination addresses. This header is originated by ITRs and stripped by ETRs.
                • </li>
              • <li>
                • UDP header (port 4341) with zero checksum. This header is originated by ITRs and stripped by ETRs.
                • </li>
              • <li>
                • LISP header that contains various forwarding-plane features (such as reachability) and an Instance ID field. This header is originated by ITRs and stripped by ETRs.
                • </li>
              • <li>
                • Inner IP header containing EIDs as source and destination addresses. This header is created by the source end-host and is left unchanged by LISP data plane processing on the ITR and ETR.
                • </li>
              • </ol>
            • <t>
              • Finally, in some scenarios Re-encapsulating and/or Recursive tunnels are useful to choose a specified path in the underlay network, for 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 (an ITR action) to prepend another one. On the other hand, Recursive tunnels are nested tunnels and are implemented by using multiple LISP encapsulations on a packet. Such functions are implemented by Reencapsulating 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, more information can be found at <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6830" format="default"/>.
              • </t>
            • </section>
          • <section numbered="true" toc="default">
            • <name>
              • LISP Forwarding State
              • </name>
            • <t>
              • In the LISP architecture, ITRs keep just enough information to route traffic flowing through them. Meaning that, ITRs retrieve from the LISP Mapping System mappings between EID-prefixes (blocks of EIDs) and RLOCs that are used to encapsulate packets. Such mappings are stored in a local cache called the Map-Cache for subsequent packets addressed to the same EID prefix. Note that, in case of overlapping EID-prefixes, following a single request, the ITR may receive a set of mappings, covering the requested EID-prefix and all more-specifics (cf., Section 6.1.5 (cf. <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6830" format="default"/>). sectionFormat="comma" section="6.1.5"/>). Mappings include a (Time-to-Live) TTL (set by the ETR). More details about the Map-Cache management can be found in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="management" format="default"/>.
              • </t>
            • </section>
          • </section>
        • <section numbered="true" toc="default">
          • <name>
            • Control-Plane
            • </name>
          • <t>
            • The LISP control-plane, specified in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6833" format="default"/>, provides a standard interface to register and request mappings. The LISP Mapping System is a database that stores such mappings. The following first describes the mappings, then the standard interface to the Mapping System, and finally its architecture.
            • </t>
          • <section numbered="true" toc="default">
            • <name>
              • LISP Mappings
              • </name>
            • <t>
              • Each mapping includes the bindings between EID prefix(es) and set of RLOCs as well as traffic engineering policies, in the form of priorities and weights for the RLOCs. Priorities allow the ETR to configure active/backup policies while weights are used to load-balance traffic among the RLOCs (on a per-flow basis).
              • </t>
            • <t>
              • Typical mappings in LISP bind EIDs in the form of IP prefixes with a set of RLOCs, also in the form of IPs. IPv4 and IPv6 addresses are encoded using the appropriate Address Family Identifier (AFI) <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC3232" format="default"/>. However LISP can also support more general address encoding by means of the ongoing effort around the LISP Canonical Address Format (LCAF) <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="I-D.ietf-lisp-lcaf" format="default"/>.
              • </t>
            • <t>
              • With such a general syntax for address encoding in place, LISP aims to provide flexibility to current and future applications. For instance LCAFs could support MAC addresses, geo-coordinates, ASCII names and application specific data.
              • </t>
            • </section>
          • <section numbered="true" toc="default">
            • <name>
              • Mapping System Interface
              • </name>
            • <t>
              • LISP defines a standard interface between data and control planes. The interface is specified in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6833" format="default"/> and defines two entities:
              • </t>
            • <dl newline="false" "true" spacing="normal">
              • <dt>
                • Map-Server:
                • </dt>
              • <dd>
                • A network infrastructure component that learns mappings from ETRs and publishes them into the LISP Mapping System. Typically Map-Servers are not authoritative to reply to queries and hence, they forward them to the ETR. 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., CPU or power).
                • </dd>
              • <dt>
                • Map-Resolver:
                • </dt>
              • <dd>
                • A network infrastructure component that interfaces ITRs with the Mapping System by proxying queries and in some cases responses.
                • </dd>
              • </dl>
            • <t>
              • The interface defines four LISP control messages which are sent as UDP datagrams (port 4342):
              • </t>
            • <dl newline="false" "true" spacing="normal">
              • <dt>
                • Map-Register:
                • </dt>
              • <dd>
                • This message is used by ETRs to register mappings in the Mapping System and it is authenticated using a shared key between the ETR and the Map-Server.
                • </dd>
              • <dt>
                • Map-Notify:
                • </dt>
              • <dd>
                • 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 mapping. In some cases a Map-Notify can be sent to the previous RLOCs when an EID is registered by a new set of RLOCs.
                • </dd>
              • <dt>
                • Map-Request:
                • </dt>
              • <dd>
                • This message is used by ITRs or Map-Resolvers to resolve the mapping of a given EID.
                • </dd>
              • <dt>
                • Map-Reply:
                • </dt>
              • <dd>
                • 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 the ITR typically forwards the traffic natively (non encapsulated) to the public Internet, this behavior is defined to support incremental deployment of LISP.
                • </dd>
              • </dl>
            • </section>
          • <section numbered="true" toc="default">
            • <name>
              • Mapping System
              • </name>
            • <t>
              • LISP architecturally decouples control and data-plane by means of a standard interface. This interface glues the data-plane, routers responsible for forwarding data-packets, with the LISP Mapping System, a database responsible for storing mappings.
              • </t>
            • <t>
              • With this separation in place the data and control-plane can use different architectures if needed and scale independently. Typically the data-plane is optimized to route packets according to hierarchical IP addresses. However the control-plane may have different requirements, for instance and by taking advantage of the LCAFs, the Mapping System may be used to store non-hierarchical keys (such as MAC addresses), requiring different architectural approaches for scalability. Another important difference between the LISP control and data-planes is that, and as a result of the local mapping cache available at ITR, the Mapping System does not need to operate at line-rate.
              • </t>
            • <t>
              • 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 <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6836" format="default"/>, hierarchical databases in the form of LISP-DDT <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="I-D.ietf-lisp-ddt" format="default"/>, monolithic databases in the form of LISP-NERD <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6837" format="default"/>, flat databases in the form of LISP-DHT <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="I-D.cheng-lisp-shdht" format="default"/>,<xref xmlns:xi="http://www.w3.org/2001/XInclude" target="Mathy" format="default"/> and, a multicast-based database <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="I-D.curran-lisp-emacs" format="default"/>. Furthermore it is worth noting that, in some scenarios such as private deployments, the Mapping System can operate as logically centralized. In such cases it is typically composed of a single Map-Server/Map-Resolver.
              • </t>
            • <t>
              • The following focuses on the two mapping systems that have been implemented and deployed (LISP-ALT and LISP+DDT).
              • </t>
            • <section numbered="true" toc="default">
              • <name>
                • LISP+ALT
                • </name>
              • <t>
                • The LISP Alternative Topology (LISP+ALT) <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6836" format="default"/> was the first Mapping System proposed, developed and deployed on the LISP pilot network. It is based on a distributed BGP overlay participated by Map-Servers and Map-Resolvers. The nodes connect to their peers through static tunnels. Each Map-Server involved in the ALT topology advertises the EID-prefixes registered by the serviced ETRs, making the EID routable on the ALT topology.
                • </t>
              • <t>
                • When an ITR needs a mapping it sends a Map-Request to a Map-Resolver that, using the ALT topology, forwards the Map-Request towards the Map-Server responsible for the mapping. Upon reception the Map-Server forwards the request to the ETR that in turn, replies directly to the ITR using the native Internet core.
                • </t>
              • </section>
            • <section numbered="true" toc="default">
              • <name>
                • LISP-DDT
                • </name>
              • <t>
                • LISP-DDT <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="I-D.ietf-lisp-ddt" format="default"/> 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, the leafs of the tree are Map-Servers. On top of the structure there is the DDT root node <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="DDT-ROOT" format="default"/>, which is a particular instance of a DDT node and 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.
                • </t>
              • <figure anchor="fig3" title="A Schematic Representation of the DDT Tree Structure">
                • <artwork name="" type="" align="left" alt="">

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

                          Figure 3.- A schematic representation of the DDT tree structure,
                                  please note that the prefixes and the structure depicted
                                  should be only considered as an example.
                  • </artwork>
                • </figure>
              • <t>
                • Note: In the figure above, the prefixes and the structure depicted should only be considered as an example.
                • </t>
              • <t>
                • The DDT structure does not actually index EID-prefixes but eXtended EID-prefixes (XEID). An XEID-prefix is just the concatenation of the following fields (from most significant bit to less significant bit): Database-ID, Instance ID, Address Family Identifier and the actual EID-prefix. The Database-ID is provided for possible future requirements of higher levels in the hierarchy and to enable the creation of multiple and separate database trees.
                • </t>
              • <t>
                • In order to resolve a query LISP-DDT operates in a similar way to the DNS but only supports iterative lookups. DDT clients (usually Map-Resolvers) generate Map-Requests to the DDT root node. In response they receive a newly introduced LISP-control message: a Map-Referral. A Map-Referral provides the list of RLOCs of the set of DDT nodes matching a configured XEID delegation. That is, the information contained in the Map-Referral points to the child of the queried DDT node that has more specific information about the queried XEID-prefix. This process is repeated until the DDT client walks the tree structure (downwards) and discovers the Map-Server servicing the queried XEID. At this point the client sends a Map-Request and receives a Map-Reply containing the mappings. It is important to note that DDT clients can also cache the information contained in Map-Referrals, that is, they cache the DDT structure. This is used to reduce the mapping retrieving latency<xref latency <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="Jakab" format="default"/>.
                • </t>
              • <t>
                • The DDT Mapping System relies on manual configuration. That is Map- Resolvers are manually configured with the set of available DDT root 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 policy changes).
                • </t>
              • </section>
            • </section>
          • </section>
        • <section numbered="true" toc="default" anchor="internetwork">
          • <name>
            • Internetworking Mechanisms
            • </name>
          • <t>
            • EIDs are typically identical to either IPv4 or IPv6 addresses and they are stored in the LISP Mapping System, however they are usually not announced in the Internet global routing system. As a 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 <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6832" format="default"/>.
            • </t>
          • <t>
            • LISP defines two entities to provide internetworking:
            • </t>
          • <dl newline="false" "true" spacing="normal">
            • <dt>
              • Proxy Ingress Tunnel Router (PITR):
              • </dt>
            • <dd>
              • PITRs provide connectivity from the legacy Internet to LISP sites. PITRs announce in the global routing system blocks of 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 the routing table size of the Default-Free Zone (DFZ) is, in the worst-case, similar to the case in which LISP is not deployed. EID-prefixes will be aggregated as much as possible both by the PITR and by the global routing system.
              • </dd>
            • <dt>
              • Proxy Egress Tunnel Router (PETR):
              • </dt>
            • <dd>
              • 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 when Unicast Reverse Path Forwarding (uRPF) is used by Provider Edge 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 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.
              • </dd>
            • </dl>
          • <t>
            • Additionally, LISP also defines mechanisms to operate with private EIDs <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC1918" format="default"/> by means of LISP-NAT <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6832" format="default"/>. In this 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 xTRs behind a NAT using non-routable RLOCs.
            • </t>
          • <t>
            • PITRs, PETRs and, LISP-NAT enable incremental deployment of LISP, by providing significant flexibility in the placement of the boundaries between the LISP and non-LISP portions of the network, and making it easy to change those boundaries over time.
            • </t>
          • </section>
        • </section>
      • <section numbered="true" toc="default">
        • <name>
          • LISP Operational Mechanisms
          • </name>
        • <t>
          • This section details the main operational mechanisms defined in LISP.
          • </t>
        • <section anchor="management" numbered="true" toc="default">
          • <name>
            • Cache Management
            • </name>
          • <t>
            • LISP's decoupled control and data-plane, where mappings are stored in the control-plane and used for forwarding in the data plane, requires a local cache in ITRs to reduce signaling overhead (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) and contains basically the set of RLOCs with the associated traffic engineering policies (priorities and weights).
            • </t>
          • <t>
            • The Map-Cache, as any other cache, requires cache coherence mechanisms to maintain up-to-date information. LISP defines three main mechanisms for cache coherence:
            • </t>
          • <dl newline="false" "true" spacing="normal">
            • <dt>
              • Time-To-Live (TTL):
              • </dt>
            • <dd>
              • Each mapping contains a TTL set by the ETR, upon expiration of the 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.
              • </dd>
            • <dt>
              • Solicit-Map-Request (SMR):
              • </dt>
            • <dd>
              • SMR is an explicit mechanism to update mapping information. In particular a special type of Map-Request can be sent on demand by ETRs to request refreshing a mapping. Upon reception of a SMR message, the ITR must refresh the bindings by sending a Map-Request to the Mapping System. Further uses of SMRs are documented in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6830" format="default"/>.
              • </dd>
            • <dt>
              • Map-Versioning:
              • </dt>
            • <dd>
              • This optional mechanism piggybacks in the LISP header of 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 to obtain the newest mappings. On the contrary, if it detects that the remote xTR Map-Cache is outdated, it sends a SMR to notify it that a new mapping is available.
              • </dd>
            • </dl>
          • <t>
            • Finally it is worth noting that in some cases an entry in the map-cache can be proactively refreshed using the mechanisms described in the section below.
            • </t>
          • </section>
        • <section anchor="reachability" numbered="true" toc="default">
          • <name>
            • RLOC Reachability
            • </name>
          • <t>
            • In most cases LISP operates with a pull-based Mapping System (e.g., DDT), this results in an edge to edge pull architecture. In such scenario the network state is stored in the control-plane while the data-plane pulls it on demand. This has consequences concerning the propagation of xTRs reachability/liveness information since pull architectures require explicit mechanisms to propagate this information. As a result LISP defines a set of mechanisms to inform ITRs and PITRS about the reachability of the cached RLOCs:
            • </t>
          • <dl newline="true" spacing="normal">
            • <dt>
              • Locator Status Bits (LSB):
              • </dt>
            • <tdd>
              • Locator Status Bits (LSB): LSB is a passive technique, the LSB field is carried by 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 not provide path reachability status, only hints on the status of RLOCs.
              • </t>
            • <dt>
              • Echo-nonce:
              • </dt>
            • <tdd>
              • Echo-nonce: This is also a passive technique, that can only operate effectively when data flows bi-directionally between two communicating xTRs. Basically, an ITR piggybacks a random number (called nonce) in LISP data packets, if the path and the probed locator are up, the ETR will piggyback the same random number on the next data-packet, if this is not the case the ITR can set the 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.
              • </t>
            • <dt>
              • RLOC-probing:
              • </dt>
            • <tdd>
              • RLOC-probing: This is an active probing algorithm where ITRs send probes to specific locators, this effectively probes both the locator and the path. In particular this is done by sending a Map-Request (with certain flags activated) on the data-plane (RLOC space) and waiting in return a Map-Reply, also sent on the data-plane. The active nature of RLOC-probing provides an effective mechanism to determine reachability and, in case of failure, switching to a different locator. Furthermore the mechanism also provides useful RTT estimates of the delay of the path that can be used by other network algorithms.
              • </t>
            • </dl>
          • <t>
            • It is worth noting that RLOC probing and Echo-nonce can work together. 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 path is not used (a unidirectional path).
            • </t>
          • <t>
            • Additionally, LISP also recommends inferring reachability of locators by using information provided by the underlay, in particular:
            • </t>
          • <dl newline="true" spacing="normal">
            • <dt>
              • ICMP signaling:
              • </dt>
            • <tdd>
              • ICMP signaling: The LISP underlay -the current Internet- uses the ICMP protocol to signal unreachability (among other things). LISP can take advantage of this and the reception of a ICMP Network Unreachable or ICMP Host Unreachable message can be seen as a hint that a locator might be unreachable, this should lead to perform additional checks.
              • </t>
            • <dt>
              • Underlay routing:
              • </dt>
            • <tdd>
              • Underlay routing: Both BGP and IBGP carry reachability information, LISP-capable routers that have access to underlay routing information can use it to determine if a given locator or path are reachable.
              • </t>
            • </dl>
          • </section>
        • <section numbered="true" toc="default">
          • <name>
            • ETR Synchronization
            • </name>
          • <t>
            • All the ETRs that are authoritative to a particular EID-prefix must announce the same mapping to the requesters, this means that ETRs must be aware of the status of the RLOCs of the remaining ETRs. This is known as ETR synchronization.
            • </t>
          • <t>
            • At the time of this writing LISP does not specify a mechanism to achieve ETR synchronization. Although many well-known techniques could be applied to solve this issue it is still under research, as a result operators must rely on coherent manual configuration
            • </t>
          • </section>
        • <section numbered="true" toc="default">
          • <name>
            • MTU Handling
            • </name>
          • <t>
            • Since LISP encapsulates packets it requires dealing with packets that exceed the MTU of the path between the ITR and the ETR. Specifically LISP defines two mechanisms:
            • </t>
          • <dl newline="false" "true" spacing="normal">
            • <dt>
              • Stateless:
              • </dt>
            • <dd>
              • With this mechanism the effective MTU is assumed from the ITR's perspective. If a payload packet is too big for the effective MTU, and can be fragmented, the payload packet is fragmented on the ITR, such that reassembly is performed at the destination host.
              • </dd>
            • <dt>
              • Stateful:
              • </dt>
            • <dd>
              • With this mechanism ITRs keep track of the MTU of the paths towards the destination 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 ITRs can use mechanisms such as PMTUD <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC1191" format="default"/> or PLPMTUD <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC4821" format="default"/> to keep track of the MTU towards the locators.
              • </dd>
            • </dl>
          • <t>
            • In both cases if the packet cannot be fragmented (IPv4 with DF=1 or IPv6) then the ITR drops it and replies with a ICMP Too Big message to the source.
            • </t>
          • </section>
        • </section>
      • <section numbered="true" toc="default">
        • <name>
          • Mobility
          • </name>
        • <t>
          • The separation between locators and identifiers in LISP is suitable for traffic engineering purpose 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 and endpoints are not aware of the existence of LISP. This functionality is similar to Network Mobility <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC3963" format="default"/>. However, this mode of operation does not allow seamless mobility of endpoints between different LISP 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 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 (<xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC5944" format="default"/> and <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6275" format="default"/>).
          • </t>
        • <t>
          • Whenever the device changes of RLOC, the xTR updates the RLOC of its local mapping and registers it to its Map-Server, typically with a low TTL value (1min). To avoid the need of a home gateway, the ITR 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 as signaling is strictly limited the Map-Server and to hosts with which communications are ongoing. In the mobility case the EID-prefix can be as small as a full /32 or /128 (IPv4 or IPv6 respectively) depending on the specific use-case (e.g., subnet mobility vs single VM/Mobile node mobility).
          • </t>
        • <t>
          • The decoupled identity and location provided by LISP allows it to operate with other layer 2 and layer 3 mobility solutions.
          • </t>
        • </section>
      • <section numbered="true" toc="default">
        • <name>
          • Multicast
          • </name>
        • <t>
          • LISP also supports transporting IP multicast packets sent from the EID space, the operational changes required to the multicast protocols are documented in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6831" format="default"/>.
          • </t>
        • <t>
          • 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. At the core, ETRs build a new PIM Join/Prune message addressed to the RLOC of the ITR servicing the source. An simplified sequence is shown below
          • </t>
        • <ol spacing="normal" type="1">
          • <li>
            • An 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.
            • </li>
          • <li>
            • The join message flows to the ETR, upon reception the ETR builds two join messages, the first one unicast LISP-encapsulates the original 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 message contains as destination address the RLOC of the ITR servicing the source (S-RLOC, G) and creates multicast state at the core.
            • </li>
          • <li>
            • 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 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 are logical and are not resolved by the mapping system. Then the multicast packet is transmitted through the core towards the receiving ETRs that decapsulates the packets and sends them using the receiver's site multicast state.
            • </li>
          • </ol>
        • <t>
          • Please note that the inner and outer multicast addresses are in general different, unless in specific cases where the underlay provider implements a tight control on the overlay. LISP specifications already support all PIM modes <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6831" format="default"/>. Additionally, LISP can support as well non-PIM mechanisms in order to maintain multicast state.
          • </t>
        • </section>
      • <section numbered="true" toc="default">
        • <name>
          • Use Cases
          • </name>
        • <section numbered="true" toc="default">
          • <name>
            • Traffic Engineering
            • </name>
          • <t>
            • 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 the destination EID via the mapping system. The mapping is sent directly by an authoritative ETR of the EID and is not altered by any intermediate network.
            • </t>
          • <t>
            • A mapping associates a list of RLOCs to an 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 which RLOCs should be preferred to send packets (the least preferred ones being provided for backup purpose). The weight permits to balance the load between the RLOCs with the same priority, proportionally to the weight value.
            • </t>
          • <t>
            • As mappings are directly issued by the authoritative ETR of the EID and are not altered while transmitted to the remote site, it offers highly flexible incoming inter-domain traffic engineering with even the possibility for a site to support a different mapping policy for each remote site. routing policies.
            • </t>
          • </section>
        • <section numbered="true" toc="default">
          • <name>
            • LISP for IPv6 Co-existence
            • </name>
          • <t>
            • LISP encapsulations allows to transport 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 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.
            • </t>
          • <t>
            • 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 is done without any form of translation as the native IPv6 packets (in the EID space) will be LISP encapsulated and transmitted over the IPv4 legacy Internet by the mean of IPv4 RLOCs.
            • </t>
          • </section>
        • <section numbered="true" toc="default">
          • <name>
            • LISP for Virtual Private Networks
            • </name>
          • <t>
            • It is common to operate several virtual networks over the same physical infrastructure. In such virtual private networks, it is essential to distinguish which virtual network a packet belongs and tags or labels are used for that purpose. When using LISP, the distinction can be made with the Instance ID field. When an ITR encapsulates a packet from a particular virtual network (e.g., known via the VRF or 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 it uses the Instance ID to determine how to treat the packet.
            • </t>
          • <t>
            • The main usage of LISP for virtual private networks does not introduce additional requirements on the underlying network, as long as it is running IP.
            • </t>
          • </section>
        • <section numbered="true" toc="default">
          • <name>
            • LISP for Virtual Machine Mobility in Data Centers
            • </name>
          • <t>
            • A way to enable seamless virtual machine mobility in data center is to conceive the datacenter 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 is moved to another subnet, it can keep (temporarily) the address it had before the move so to continue without a 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.
            • </t>
          • <t>
            • 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.
            • </t>
          • </section>
        • </section>
      • <section numbered="true" toc="default">
        • <name>
          • Security Considerations
          • </name>
        • <t>
          • This section describes the security considerations associated to the LISP protocol.
          • </t>
        • <t>
          • While in a push mapping system, the state necessary to forward packets is learned independently of the traffic itself, with a pull architecture, the system becomes reactive and data-plane events (e.g., the arrival of a packet for an unknown destination) may trigger control-plane events. This on-demand learning of mappings provides many advantages as discussed above but may also affect the way security is enforced.
          • </t>
        • <t>
          • Usually, the data-plane is implemented in the fast path of routers to provide high performance forwarding capabilities while the control-plane features are implemented in the slow path to offer high flexibility and a performance gap of several order of magnitude can be observed between the slow and the fast paths. As a consequence, the way data-plane events are notified to the control-plane must be thought carefully so to not overload the slow path and rate limiting should be used as specified in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6830" format="default"/>.
          • </t>
        • <t>
          • Care must also be taken so to not overload the mapping system (i.e., the control plane infrastructure) as the operations to be performed by the mapping system may be more complex than those on the data-plane, for that reason <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6830" format="default"/> recommends to rate limit the sending of messages to the mapping system.
          • </t>
        • <t>
          • To improve resiliency and reduce the overall number of messages exchanged, LISP offers the possibility to leak information, such as reachabilty of locators, directly into data plane packets. In environments that are not fully trusted, control information gleaned from data-plane packets should be verified before using them.
          • </t>
        • <t>
          • Mappings are the centrepiece of LISP and all precautions must be taken to avoid them to be manipulated or misused by malicious entities. Using trustable Map-Servers that strictly respect [RFC6833] <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6833"/> and the lightweight authentication mechanism proposed by LISP-Sec <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="I-D.ietf-lisp-sec" format="default"/> reduces the risk of attacks to the mapping integrity. In more critical environments, secure measures may be needed. The way security is implemented for a given mapping system strongly depends on the architecture of the mapping system itself and the threat model assumed for the deployment. Thus, the mapping system security has to be discussed in the relevant documents proposing the mapping system architecture.
          • </t>
        • <t>
          • 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 packets.
          • </t>
        • <t>
          • Like other map-and-encap mechanisms, LISP enables triangular routing (i.e., packets of a flow cross different border routers depending on their direction). This means that intermediate boxes may have incomplete view on the traffic they inspect or manipulate. Moreover, LISP-encapsulated packets are routed based on the outer IP address (i.e., the RLOC), and can be delivered to an ETR that is not responsible of the destination EID of the packet or even to a network element that is not an ETR. The mitigation consists in applying appropriate filtering techniques on the network elements that can potentially receive un-expected LISP-encapsulated packets
          • </t>
        • <t>
          • More details about security implications of LISP are discussed in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="I-D.ietf-lisp-threats" format="default"/>.
          • </t>
        • </section>
      • <section numbered="true" toc="default">
        • <name>
          • IANA Considerations
          • </name>
        • <t>
          • This memo includes no request to IANA.
          • </t>
        • </section>
      • <section anchor="Acknowledgements" numbered="true" toc="default">
        • <name>
          • Acknowledgements
          • </name>
        • <t>
          • 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.
          • </t>
        • <t>
          • 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 <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6830" format="default"/>.
          • </t>
        • </section>
      • </middle>
    • <back>
      • <references>
        • <name>
          • References
          • </name>
        • <references>
          • <name>
            • Normative References
            • </name>
          • <reference anchor="RFC1191" target="https://www.rfc-editor.org/info/rfc1191" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1191.xml">
            • <front>
              • <title>
                • Path MTU discovery
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC1191"/>
              • <seriesInfo name="RFC" value="1191"/>
              • <author initials="J.C." surname="Mogul" fullname="J.C. Mogul">
                • <organization/>
                • </author>
              • <author initials="S.E." surname="Deering" fullname="S.E. Deering">
                • <organization/>
                • </author>
              • <date year="1990" month="November"/>
              • <abstract>
                • <t>
                  • This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path. It specifies a small change to the way routers generate one type of ICMP message. For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice. [STANDARDS-TRACK]
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="1191"/>
            • <seriesInfo name="DOI" value="10.17487/RFC1191"/>
            • </reference>
          • <reference anchor="RFC1918" target="https://www.rfc-editor.org/info/rfc1918" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1918.xml">
            • <front>
              • <title>
                • Address Allocation for Private Internets
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC1918"/>
              • <seriesInfo name="RFC" value="1918"/>
              • <seriesInfo name="BCP" value="5"/>
              • <author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
                • <organization/>
                • </author>
              • <author initials="B." surname="Moskowitz" fullname="B. Moskowitz">
                • <organization/>
                • </author>
              • <author initials="D." surname="Karrenberg" fullname="D. Karrenberg">
                • <organization/>
                • </author>
              • <author initials="G. J." surname="de Groot" fullname="G. J. de Groot">
                • <organization/>
                • </author>
              • <author initials="E." surname="Lear" fullname="E. Lear">
                • <organization/>
                • </author>
              • <date year="1996" month="February"/>
              • <abstract>
                • <t>
                  • This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="BCP" value="5"/>
            • <seriesInfo name="RFC" value="1918"/>
            • <seriesInfo name="DOI" value="10.17487/RFC1918"/>
            • </reference>
          • <reference anchor="RFC2992" target="https://www.rfc-editor.org/info/rfc2992" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2992.xml">
            • <front>
              • <title>
                • Analysis of an Equal-Cost Multi-Path Algorithm
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC2992"/>
              • <seriesInfo name="RFC" value="2992"/>
              • <author initials="C." surname="Hopps" fullname="C. Hopps">
                • <organization/>
                • </author>
              • <date year="2000" month="November"/>
              • <abstract>
                • <t>
                  • Equal-cost multi-path (ECMP) is a routing technique for routing packets along multiple paths of equal cost. The forwarding engine identifies paths by next-hop. When forwarding a packet the router must decide which next-hop (path) to use. This document gives an analysis of one method for making that decision. The analysis includes the performance of the algorithm and the disruption caused by changes to the set of next-hops. This memo provides information for the Internet community.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="2992"/>
            • <seriesInfo name="DOI" value="10.17487/RFC2992"/>
            • </reference>
          • <reference anchor="RFC3232" target="https://www.rfc-editor.org/info/rfc3232" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3232.xml">
            • <front>
              • <title>
                • Assigned Numbers: RFC 1700 is Replaced by an On-line Database
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC3232"/>
              • <seriesInfo name="RFC" value="3232"/>
              • <author initials="J." surname="Reynolds" fullname="J. Reynolds" role="editor">
                • <organization/>
                • </author>
              • <date year="2002" month="January"/>
              • <abstract>
                • <t>
                  • This memo obsoletes RFC 1700 (STD 2) "Assigned Numbers", which contained an October 1994 snapshot of assigned Internet protocol parameters. This memo provides information for the Internet community.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="3232"/>
            • <seriesInfo name="DOI" value="10.17487/RFC3232"/>
            • </reference>
          • <reference anchor="RFC4821" "RFC3963" target="https://www.rfc-editor.org/info/rfc4821" "https://www.rfc-editor.org/info/rfc3963" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3963.xml">
            • <front>
              • <title>
                • Packetization Layer Path MTU Discovery Network Mobility (NEMO) Basic Support Protocol
                • </title>
              • <author initials="V." surname="Devarapalli" fullname="V. Devarapalli">
                • <organization/>
                • </author>
              • <author initials="R." surname="Wakikawa" fullname="R. Wakikawa">
                • <organization/>
                • </author>
              • <seriesInfo name="DOI" value="10.17487/RFC4821"/>
              • <seriesInfo name="RFC" value="4821"/>
              • <author initials="M." "A." surname="Mathis" "Petrescu" fullname="M. Mathis" "A. Petrescu" >
                • <organization/>
                • </author>
              • <author initials="J." "P." surname="Heffner" "Thubert" fullname="J. Heffner" "P. Thubert" >
                • <organization/>
                • </author>
              • <date year="2007" "2005" month="March" "January" />
              • <abstract>
                • <t>
                  • This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6,*the respectively. Network Mobility (NEMO) Basic Support protocol that enables Mobile Networks to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves. It also allows every node in the Mobile Network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed so that network mobility is transparent to the nodes inside the Mobile Network. [STANDARDS-TRACK]
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="3963"/>
            • <seriesInfo name="DOI" value="10.17487/RFC3963"/>
            • </reference>
          • <reference anchor="RFC5944" "RFC4821" target="https://www.rfc-editor.org/info/rfc5944" "https://www.rfc-editor.org/info/rfc4821" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4821.xml">
            • <front>
              • <title>
                • IP Mobility Support for IPv4, Revised Packetization Layer Path MTU Discovery
                • </title>
              • <author initials="M." surname="Mathis" fullname="M. Mathis">
                • <organization/>
                • </author>
              • <seriesInfo name="DOI" value="10.17487/RFC5944"/>
              • <seriesInfo name="RFC" value="5944"/>
              • <author initials="C." "J." surname="Perkins" "Heffner" fullname="C. Perkins" "J. Heffner" role="editor">
                • <organization/>
                • </author>
              • <date year="2010" "2007" month="November" "March" />
              • <abstract>
                • <t>
                  • This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile*describes node. a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively. [STANDARDS-TRACK]
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="4821"/>
            • <seriesInfo name="DOI" value="10.17487/RFC4821"/>
            • </reference>
          • <reference anchor="RFC6275" "RFC4984" target="https://www.rfc-editor.org/info/rfc6275" "https://www.rfc-editor.org/info/rfc4984" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4984.xml">
            • <front>
              • <title>
                • Mobility Support in IPv6 Report from the IAB Workshop on Routing and Addressing
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC6275"/>
              • <seriesInfo name="RFC" value="6275"/>
              • <author initials="C." "D." surname="Perkins" "Meyer" fullname="C. Perkins" "D. Meyer" role="editor">
                • <organization/>
                • </author>
              • <author initials="D." "L." surname="Johnson" "Zhang" fullname="D. Johnson" "L. Zhang" role="editor">
                • <organization/>
                • </author>
              • <author initials="J." "K." surname="Arkko" "Fall" fullname="J. Arkko" "K. Fall" role="editor">
                • <organization/>
                • </author>
              • <date year="2011" "2007" month="July" "September" />
              • <abstract>
                • <t>
                  • This document specifies Mobile IPv6, a protocol that allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. This document obsoletes RFC 3775.*reports [STANDARDS-TRACK] the outcome of the Routing and Addressing Workshop that was held by the Internet Architecture Board (IAB) on October 18-19, 2006, in Amsterdam, Netherlands. The primary goal of the workshop was to develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet routing system. The key workshop findings include an analysis of the major factors that are driving routing table growth, constraints in router technology, and the limitations of today's Internet addressing architecture. It is hoped that these findings will serve as input to the IETF community and help identify next steps towards effective solutions.
                  • </t>
                • <t>
                  • Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and not of the IAB. Furthermore, note that work on issues related to this workshop report is continuing, and this document does not intend to reflect the increased understanding of issues nor to discuss the range of potential solutions that may be the outcome of this ongoing work. This memo provides information for the Internet community.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="4984"/>
            • <seriesInfo name="DOI" value="10.17487/RFC4984"/>
            • </reference>
          • <reference anchor="RFC3963" "RFC5944" target="https://www.rfc-editor.org/info/rfc3963" "https://www.rfc-editor.org/info/rfc5944" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5944.xml">
            • <front>
              • <title>
                • Network IP Mobility (NEMO) Basic Support Protocol for IPv4, Revised
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC3963"/>
              • <seriesInfo name="RFC" value="3963"/>
              • <author initials="V." surname="Devarapalli" fullname="V. Devarapalli">
                • <organization/>
                • </author>
              • <author initials="R." surname="Wakikawa" fullname="R. Wakikawa">
                • <organization/>
                • </author>
              • <author initials="A." surname="Petrescu" fullname="A. Petrescu">
                • <organization/>
                • </author>
              • <author initials="P." "C." surname="Thubert" "Perkins" fullname="P. Thubert" "C. Perkins" role="editor">
                • <organization/>
                • </author>
              • <date year="2005" "2010" month="January" "November" />
              • <abstract>
                • <t>
                  • This document describes the Network Mobility (NEMO) Basic Support protocol that enables Mobile Networks to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves. It also allows every node in the Mobile Network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed so that network mobility is transparent to the nodes inside the Mobile*specifies Network. protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. [STANDARDS-TRACK]
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="5944"/>
            • <seriesInfo name="DOI" value="10.17487/RFC5944"/>
            • </reference>
          • <reference anchor="RFC4984" "RFC6275" target="https://www.rfc-editor.org/info/rfc4984" "https://www.rfc-editor.org/info/rfc6275" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6275.xml">
            • <front>
              • <title>
                • Report from the IAB Workshop on Routing and Addressing Mobility Support in IPv6
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC4984"/>
              • <seriesInfo name="RFC" value="4984"/>
              • <author initials="D." "C." surname="Meyer" "Perkins" fullname="D. Meyer" "C. Perkins" role="editor">
                • <organization/>
                • </author>
              • <author initials="L." "D." surname="Zhang" "Johnson" fullname="L. Zhang" "D. Johnson" role="editor">
                • <organization/>
                • </author>
              • <author initials="K." "J." surname="Fall" "Arkko" fullname="K. Fall" "J. Arkko" role="editor">
                • <organization/>
                • </author>
              • <date year="2007" "2011" month="September" "July" />
              • <abstract>
                • <t>
                  • This document reports the outcome of the Routing and Addressing Workshop that was held by the Internet Architecture Board (IAB) on October 18-19, 2006, in Amsterdam, Netherlands. The primary goal of the workshop was to develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet routing system. The key workshop findings include an analysis of the major factors that are driving routing table growth, constraints in router technology, and the limitations of today's Internet addressing architecture. It is hoped that these findings will serve as input to the IETF community and help identify next steps towards effective*specifies solutions. Mobile IPv6, a protocol that allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. This document obsoletes RFC 3775. [STANDARDS-TRACK]
                  • </t>
                • <t>
                  • Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and not of the IAB. Furthermore, note that work on issues related to this workshop report is continuing, and this document does not intend to reflect the increased understanding of issues nor to discuss the range of potential solutions that may be the outcome of this ongoing work. This memo provides information for the Internet community.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="6275"/>
            • <seriesInfo name="DOI" value="10.17487/RFC6275"/>
            • </reference>
          • <reference anchor="RFC6830" target="https://www.rfc-editor.org/info/rfc6830" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6830.xml">
            • <front>
              • <title>
                • The Locator/ID Separation Protocol (LISP)
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC6830"/>
              • <seriesInfo name="RFC" value="6830"/>
              • <author initials="D." surname="Farinacci" fullname="D. Farinacci">
                • <organization/>
                • </author>
              • <author initials="V." surname="Fuller" fullname="V. Fuller">
                • <organization/>
                • </author>
              • <author initials="D." surname="Meyer" fullname="D. Meyer">
                • <organization/>
                • </author>
              • <author initials="D." surname="Lewis" fullname="D. Lewis">
                • <organization/>
                • </author>
              • <date year="2013" month="January"/>
              • <abstract>
                • <t>
                  • 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.
                  • </t>
                • <t>
                  • Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. This document defines an Experimental Protocol for the Internet community.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="6830"/>
            • <seriesInfo name="DOI" value="10.17487/RFC6830"/>
            • </reference>
          • <reference anchor="RFC6831" target="https://www.rfc-editor.org/info/rfc6831" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6831.xml">
            • <front>
              • <title>
                • The Locator/ID Separation Protocol (LISP) for Multicast Environments
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC6831"/>
              • <seriesInfo name="RFC" value="6831"/>
              • <author initials="D." surname="Farinacci" fullname="D. Farinacci">
                • <organization/>
                • </author>
              • <author initials="D." surname="Meyer" fullname="D. Meyer">
                • <organization/>
                • </author>
              • <author initials="J." surname="Zwiebel" fullname="J. Zwiebel">
                • <organization/>
                • </author>
              • <author initials="S." surname="Venaas" fullname="S. Venaas">
                • <organization/>
                • </author>
              • <date year="2013" month="January"/>
              • <abstract>
                • <t>
                  • This document describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the Locator/ID Separation Protocol (LISP) architecture. This document defines an Experimental Protocol for the Internet community.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="6831"/>
            • <seriesInfo name="DOI" value="10.17487/RFC6831"/>
            • </reference>
          • <reference anchor="RFC6832" target="https://www.rfc-editor.org/info/rfc6832" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6832.xml">
            • <front>
              • <title>
                • Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC6832"/>
              • <seriesInfo name="RFC" value="6832"/>
              • <author initials="D." surname="Lewis" fullname="D. Lewis">
                • <organization/>
                • </author>
              • <author initials="D." surname="Meyer" fullname="D. Meyer">
                • <organization/>
                • </author>
              • <author initials="D." surname="Farinacci" fullname="D. Farinacci">
                • <organization/>
                • </author>
              • <author initials="V." surname="Fuller" fullname="V. Fuller">
                • <organization/>
                • </author>
              • <date year="2013" month="January"/>
              • <abstract>
                • <t>
                  • This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP) to interoperate with Internet sites that may be using either IPv4, IPv6, or both but that are not running LISP. A fundamental property of LISP-speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 or IPv6 addresses, normally routes to them are not carried in the global routing system, so an interoperability mechanism is needed for non- LISP-speaking sites to exchange traffic with LISP-speaking sites. This document introduces three such mechanisms. The first uses a new network element, the LISP Proxy Ingress Tunnel Router (Proxy-ITR), to act as an intermediate LISP Ingress Tunnel Router (ITR) for non-LISP- speaking hosts. Second, this document adds Network Address Translation (NAT) functionality to LISP ITRs and LISP Egress Tunnel Routers (ETRs) to substitute routable IP addresses for non-routable EIDs. Finally, this document introduces the Proxy Egress Tunnel Router (Proxy-ETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation. This document defines an Experimental Protocol for the Internet community.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="6832"/>
            • <seriesInfo name="DOI" value="10.17487/RFC6832"/>
            • </reference>
          • <reference anchor="RFC6833" target="https://www.rfc-editor.org/info/rfc6833" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6833.xml">
            • <front>
              • <title>
                • Locator/ID Separation Protocol (LISP) Map-Server Interface
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC6833"/>
              • <seriesInfo name="RFC" value="6833"/>
              • <author initials="V." surname="Fuller" fullname="V. Fuller">
                • <organization/>
                • </author>
              • <author initials="D." surname="Farinacci" fullname="D. Farinacci">
                • <organization/>
                • </author>
              • <date year="2013" month="January"/>
              • <abstract>
                • <t>
                  • This document describes the Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two new types of LISP- speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID to Routing Locator mapping databases.
                  • </t>
                • <t>
                  • By using this service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers and Egress Tunnel Routers are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs. Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. This document defines an Experimental Protocol for the Internet community.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="6833"/>
            • <seriesInfo name="DOI" value="10.17487/RFC6833"/>
            • </reference>
          • <reference anchor="RFC6834" target="https://www.rfc-editor.org/info/rfc6834" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6834.xml">
            • <front>
              • <title>
                • Locator/ID Separation Protocol (LISP) Map-Versioning
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC6834"/>
              • <seriesInfo name="RFC" value="6834"/>
              • <author initials="L." surname="Iannone" fullname="L. Iannone">
                • <organization/>
                • </author>
              • <author initials="D." surname="Saucez" fullname="D. Saucez">
                • <organization/>
                • </author>
              • <author initials="O." surname="Bonaventure" fullname="O. Bonaventure">
                • <organization/>
                • </author>
              • <date year="2013" month="January"/>
              • <abstract>
                • <t>
                  • This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and the transport of such a version number in the LISP-specific header of LISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is transparent to implementations not supporting this feature, since in the LISP- specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support the mechanism. This document defines an Experimental Protocol for the Internet community.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="6834"/>
            • <seriesInfo name="DOI" value="10.17487/RFC6834"/>
            • </reference>
          • <reference anchor="RFC6835" target="https://www.rfc-editor.org/info/rfc6835" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6835.xml">
            • <front>
              • <title>
                • The Locator/ID Separation Protocol Internet Groper (LIG)
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC6835"/>
              • <seriesInfo name="RFC" value="6835"/>
              • <author initials="D." surname="Farinacci" fullname="D. Farinacci">
                • <organization/>
                • </author>
              • <author initials="D." surname="Meyer" fullname="D. Meyer">
                • <organization/>
                • </author>
              • <date year="2013" month="January"/>
              • <abstract>
                • <t>
                  • A simple tool called the Locator/ID Separation Protocol (LISP) Internet Groper or 'lig' can be used to query the LISP mapping database. This document describes how it works. This document is not an Internet Standards Track specification; it is published for informational purposes.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="6835"/>
            • <seriesInfo name="DOI" value="10.17487/RFC6835"/>
            • </reference>
          • <reference anchor="RFC6836" target="https://www.rfc-editor.org/info/rfc6836" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6836.xml">
            • <front>
              • <title>
                • Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC6836"/>
              • <seriesInfo name="RFC" value="6836"/>
              • <author initials="V." surname="Fuller" fullname="V. Fuller">
                • <organization/>
                • </author>
              • <author initials="D." surname="Farinacci" fullname="D. Farinacci">
                • <organization/>
                • </author>
              • <author initials="D." surname="Meyer" fullname="D. Meyer">
                • <organization/>
                • </author>
              • <author initials="D." surname="Lewis" fullname="D. Lewis">
                • <organization/>
                • </author>
              • <date year="2013" month="January"/>
              • <abstract>
                • <t>
                  • This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map-Resolver (MR) to find the Egress Tunnel Router (ETR) that holds the mapping information for a particular Endpoint Identifier (EID). The MR can then query that ETR to obtain the actual mapping information, which consists of a list of Routing Locators (RLOCs) for the EID. Termed the Alternative Logical Topology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and Generic Routing Encapsulation (GRE). This document defines an Experimental Protocol for the Internet community.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="6836"/>
            • <seriesInfo name="DOI" value="10.17487/RFC6836"/>
            • </reference>
          • <reference anchor="RFC6837" target="https://www.rfc-editor.org/info/rfc6837" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6837.xml">
            • <front>
              • <title>
                • NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC6837"/>
              • <seriesInfo name="RFC" value="6837"/>
              • <author initials="E." surname="Lear" fullname="E. Lear">
                • <organization/>
                • </author>
              • <date year="2013" month="January"/>
              • <abstract>
                • <t>
                  • The Locator/ID Separation Protocol (LISP) is a protocol to encapsulate IP packets in order to allow end sites to route to one another without injecting routes from one end of the Internet to another. This memo presents an experimental database and a discussion of methods to transport the mapping of Endpoint IDs (EIDs) to Routing Locators (RLOCs) to routers in a reliable, scalable, and secure manner. Our analysis concludes that transport of all EID-to- RLOC mappings scales well to at least 10^8 entries. This document defines an Experimental Protocol for the Internet community.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="6837"/>
            • <seriesInfo name="DOI" value="10.17487/RFC6837"/>
            • </reference>
          • <reference anchor="RFC7215" "RFC6935" target="https://www.rfc-editor.org/info/rfc7215" "https://www.rfc-editor.org/info/rfc6935" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6935.xml">
            • <front>
              • <title>
                • Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations IPv6 and UDP Checksums for Tunneled Packets
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC7215"/>
              • <seriesInfo name="RFC" value="7215"/>
              • <author initials="L." surname="Jakab" fullname="L. Jakab">
                • <organization/>
                • </author>
              • <author initials="A." surname="Cabellos-Aparicio" fullname="A. Cabellos-Aparicio">
                • <organization/>
                • </author>
              • <author initials="F." "M." surname="Coras" "Eubanks" fullname="F. Coras" "M. Eubanks" >
                • <organization/>
                • </author>
              • <author initials="J." "P." surname="Domingo-Pascual" "Chimento" fullname="J. Domingo-Pascual" "P. Chimento" >
                • <organization/>
                • </author>
              • <author initials="D." "M." surname="Lewis" "Westerlund" fullname="D. Lewis" "M. Westerlund" >
                • <organization/>
                • </author>
              • <date year="2014" "2013" month="April"/>
              • <abstract>
                • <t>
                  • This document is a snapshot of different Locator/Identifier Separation Protocol (LISP) deployment scenarios. It discusses the placement of new network elements introduced by the protocol, representing the thinking of the LISP working group as of Summer 2013. LISP deployment scenarios may have evolved since then. This memo represents one stable point*updates in the IPv6 specification (RFC 2460) to improve performance when a tunnel protocol uses UDP with IPv6 to tunnel packets. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for tunnel protocols whose header information is protected on the "inner" packet being carried. Relaxing this requirement removes the overhead associated with the computation of UDP checksums on IPv6 packets that evolution carry the tunnel protocol packets. This specification describes how the IPv6 UDP checksum requirement can be relaxed when the encapsulated packet itself contains a checksum. It also describes the limitations and risks of this approach and discusses the restrictions on the use of understanding. this method.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="6935"/>
            • <seriesInfo name="DOI" value="10.17487/RFC6935"/>
            • </reference>
          • <reference anchor="RFC6935" "RFC6936" target="https://www.rfc-editor.org/info/rfc6935" "https://www.rfc-editor.org/info/rfc6936" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6936.xml">
            • <front>
              • <title>
                • Applicability Statement for the Use of IPv6 and UDP Datagrams with Zero Checksums for Tunneled Packets
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC6935"/>
              • <seriesInfo name="RFC" value="6935"/>
              • <author initials="M." surname="Eubanks" fullname="M. Eubanks">
                • <organization/>
                • </author>
              • <author initials="P." "G." surname="Chimento" "Fairhurst" fullname="P. Chimento" "G. Fairhurst" >
                • <organization/>
                • </author>
              • <author initials="M." surname="Westerlund" fullname="M. Westerlund">
                • <organization/>
                • </author>
              • <date year="2013" month="April"/>
              • <abstract>
                • <t>
                  • This document updates the IPv6 specification (RFC 2460) to improve performance when a tunnel protocol uses UDP with IPv6 to tunnel packets. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for tunnel protocols whose header information is protected on the "inner" packet being carried. Relaxing this requirement removes the overhead associated with the computation of UDP checksums on IPv6 packets that carry the tunnel protocol packets. This specification describes how the IPv6 UDP checksum requirement can be relaxed when the encapsulated packet itself contains a checksum. It also describes the limitations and risks of this*provides approach an applicability statement for the use of UDP transport checksums with IPv6. It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum. It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations, and discusses it examines the role of the restrictions IPv6 UDP transport checksum. The document also identifies issues and constraints for deployment on network paths that include middleboxes. An appendix presents a summary of the trade-offs that were considered in evaluating the safety of the update to RFC 2460 that changes the use of this method. the UDP checksum with IPv6.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="6936"/>
            • <seriesInfo name="DOI" value="10.17487/RFC6936"/>
            • </reference>
          • <reference anchor="RFC6936" "RFC7052" target="https://www.rfc-editor.org/info/rfc6936" "https://www.rfc-editor.org/info/rfc7052" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7052.xml">
            • <front>
              • <title>
                • Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums Locator/ID Separation Protocol (LISP) MIB
                • </title>
              • <author initials="G." surname="Schudel" fullname="G. Schudel">
                • <organization/>
                • </author>
              • <seriesInfo name="DOI" value="10.17487/RFC6936"/>
              • <seriesInfo name="RFC" value="6936"/>
              • <author initials="G." "A." surname="Fairhurst" "Jain" fullname="G. Fairhurst" "A. Jain" >
                • <organization/>
                • </author>
              • <author initials="M." "V." surname="Westerlund" "Moreno" fullname="M. Westerlund" "V. Moreno" >
                • <organization/>
                • </author>
              • <date year="2013" month="April" "October" />
              • <abstract>
                • <t>
                  • This document provides an applicability statement for the use of UDP transport checksums with IPv6. It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum. It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations, and it examines the role of the IPv6 UDP transport checksum. The document also identifies issues and constraints for deployment on network paths that include middleboxes. An appendix presents a summary of the trade-offs that were considered in evaluating the safety of the update to RFC 2460 that changes the use of the UDP checksum with*defines IPv6. the MIB module that contains managed objects to support the monitoring devices of the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including determining basic LISP configuration information, LISP functional status, and operational counters and other statistics.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="7052"/>
            • <seriesInfo name="DOI" value="10.17487/RFC7052"/>
            • </reference>
          • <reference anchor="RFC7052" "RFC7215" target="https://www.rfc-editor.org/info/rfc7052" "https://www.rfc-editor.org/info/rfc7215" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7215.xml">
            • <front>
              • <title>
                • Locator/ID Locator/Identifier Separation Protocol (LISP) MIB Network Element Deployment Considerations
                • </title>
              • <author initials="L." surname="Jakab" fullname="L. Jakab">
                • <organization/>
                • </author>
              • <author initials="A." surname="Cabellos-Aparicio" fullname="A. Cabellos-Aparicio">
                • <organization/>
                • </author>
              • <seriesInfo name="DOI" value="10.17487/RFC7052"/>
              • <seriesInfo name="RFC" value="7052"/>
              • <author initials="G." "F." surname="Schudel" "Coras" fullname="G. Schudel" "F. Coras" >
                • <organization/>
                • </author>
              • <author initials="A." "J." surname="Jain" "Domingo-Pascual" fullname="A. Jain" "J. Domingo-Pascual" >
                • <organization/>
                • </author>
              • <author initials="V." "D." surname="Moreno" "Lewis" fullname="V. Moreno" "D. Lewis" >
                • <organization/>
                • </author>
              • <date year="2013" "2014" month="October" "April" />
              • <abstract>
                • <t>
                  • This document defines the MIB module that contains managed objects to support the monitoring devices of the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including determining basic LISP configuration information, LISP functional status, and operational counters and other*is statistics. a snapshot of different Locator/Identifier Separation Protocol (LISP) deployment scenarios. It discusses the placement of new network elements introduced by the protocol, representing the thinking of the LISP working group as of Summer 2013. LISP deployment scenarios may have evolved since then. This memo represents one stable point in that evolution of understanding.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="7215"/>
            • <seriesInfo name="DOI" value="10.17487/RFC7215"/>
            • </reference>
          • <reference anchor="I-D.ietf-lisp-ddt" target="http://www.ietf.org/internet-drafts/draft-ietf-lisp-ddt-09.txt">
            • <front>
              • <title>
                • LISP Delegated Database Tree
                • </title>
              • <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-ddt-09"/>
              • <author initials="V" surname="Fuller" fullname="Vince Fuller">
                • <organization/>
                • </author>
              • <author initials="D" surname="Lewis" fullname="Darrel Lewis">
                • <organization/>
                • </author>
              • <author initials="V" surname="Ermagan" fullname="Vina Ermagan">
                • <organization/>
                • </author>
              • <author initials="A" surname="Jain" fullname="Amit Jain">
                • <organization/>
                • </author>
              • <author initials="A" surname="Smirnov" fullname="Anton Smirnov">
                • <organization/>
                • </author>
              • <date month="January" day="18" year="2017"/>
              • <abstract>
                • <t>
                  • This document describes the LISP Delegated Database Tree (LISP-DDT), a hierarchical, distributed database which embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically-defined distribution of the EID namespace among a set of LISP-speaking servers, called DDT nodes. Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated.
                  • </t>
                • </abstract>
              • </front>
            • </reference>
          • <reference anchor="I-D.ietf-lisp-lcaf" target="http://www.ietf.org/internet-drafts/draft-ietf-lisp-lcaf-22.txt">
            • <front>
              • <title>
                • LISP Canonical Address Format (LCAF)
                • </title>
              • <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-lcaf-22"/>
              • <author initials="D" surname="Farinacci" fullname="Dino Farinacci">
                • <organization/>
                • </author>
              • <author initials="D" surname="Meyer" fullname="David Meyer">
                • <organization/>
                • </author>
              • <author initials="J" surname="Snijders" fullname="Job Snijders">
                • <organization/>
                • </author>
              • <date month="November" day="28" year="2016"/>
              • <abstract>
                • <t>
                  • This document defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System.
                  • </t>
                • </abstract>
              • </front>
            • </reference>
          • <reference anchor="I-D.ietf-lisp-threats" target="http://www.ietf.org/internet-drafts/draft-ietf-lisp-threats-15.txt">
            • <front>
              • <title>
                • LISP Threats Analysis
                • </title>
              • <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-threats-15"/>
              • <author initials="D" surname="Saucez" fullname="Damien Saucez">
                • <organization/>
                • </author>
              • <author initials="L" surname="Iannone" fullname="Luigi Iannone">
                • <organization/>
                • </author>
              • <author initials="O" surname="Bonaventure" fullname="Olivier Bonaventure">
                • <organization/>
                • </author>
              • <date month="January" day="29" year="2016"/>
              • <abstract>
                • <t>
                  • This document provides a threat analysis of the Locator/Identifier Separation Protocol (LISP).
                  • </t>
                • </abstract>
              • </front>
            • </reference>
          • <reference anchor="I-D.ietf-lisp-sec" target="http://www.ietf.org/internet-drafts/draft-ietf-lisp-sec-18.txt">
            • <front>
              • <title>
                • LISP-Security (LISP-SEC)
                • </title>
              • <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-sec-18"/>
              • <author initials="F" surname="Maino" fullname="Fabio Maino">
                • <organization/>
                • </author>
              • <author initials="V" surname="Ermagan" fullname="Vina Ermagan">
                • <organization/>
                • </author>
              • <author initials="A" surname="Cabellos-Aparicio" fullname="Albert Cabellos-Aparicio">
                • <organization/>
                • </author>
              • <author initials="D" surname="Saucez" fullname="Damien Saucez">
                • <organization/>
                • </author>
              • <date month="June" day="2" year="2019"/>
              • <abstract>
                • <t>
                  • This memo specifies LISP-SEC, a set of security mechanisms that provides origin authentication, integrity and anti-replay protection to LISP's EID-to-RLOC mapping data conveyed via mapping lookup process. LISP-SEC also enables verification of authorization on EID- prefix claims in Map-Reply messages.
                  • </t>
                • </abstract>
              • </front>
            • </reference>
          • </references>
        • <references>
          • <name>
            • Informative References
            • </name>
          • <reference anchor="Jakab" target="">
            • <front>
              • <title>
                • LISP-TREE: A DNS Hierarchy to Support the LISP Mapping System, IEEE Journal on Selected Areas in Communications, vol. 28, no. 8, pp. 1332-1343
                • </title>
              • <author initials="L." surname="Jakab"/>
              • <author initials="A." surname="Cabellos"/>
              • <author initials="D." surname="Saucez"/>
              • <author initials="O." surname="Bonaventure"/>
              • <date month="October" year="2010"/>
              • </front>
            • </reference>
          • <reference anchor="Mathy" target="">
            • <front>
              • <title>
                • LISP-DHT: Towards a DHT to map identifiers onto locators. The ACM ReArch, Re-Architecting the Internet. Madrid (Spain)
                • </title>
              • <author initials="L." surname="Mathy"/>
              • <author initials="L." surname="Iannone"/>
              • <author initials="O." surname="Bonaventure"/>
              • <date month="December" year="2008"/>
              • </front>
            • </reference>
          • <reference anchor="I-D.cheng-lisp-shdht" target="http://www.ietf.org/internet-drafts/draft-cheng-lisp-shdht-04.txt">
            • <front>
              • <title>
                • LISP Single-Hop DHT Mapping Overlay
                • </title>
              • <seriesInfo name="Internet-Draft" value="draft-cheng-lisp-shdht-04"/>
              • <author fullname="Li Cheng" initials="L" surname="Cheng">
                • <organization/>
                • </author>
              • <author fullname="Jun Wang" initials="J" surname="Wang">
                • <organization/>
                • </author>
              • <date day="15" month="July" year="2013"/>
              • <abstract>
                • <t>
                  • This draft specifies the LISP Single-Hop Distributed Hash Table Mapping Database (LISP-SHDHT), a distributed mapping database which consists of a set of SHDHT Nodes to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). EID namespace is dynamically distributed among SHDHT Nodes based on DHT Hash algorithm. Each SHDHT Node is configured with one or more hash spaces which contain multiple EID-prefixes along with RLOCs of corresponding Map Servers.
                  • </t>
                • </abstract>
              • </front>
            • </reference>
          • <reference anchor="I-D.curran-lisp-emacs" target="http://tools.ietf.org/html/draft-curran-lisp-emacs-00">
            • <front>
              • <title>
                • EID Mappings Multicast Across Cooperating Systems for LISP
                • </title>
              • <seriesInfo name="Internet-Draft" value="draft-curran-lisp-emacs-00"/>
              • <author fullname="S. Brim" initials="S" surname="Brim">
                • <organization/>
                • </author>
              • <author fullname="Dino Farinacci" initials="D" surname="Farinacci">
                • <organization/>
                • </author>
              • <author fullname="Dave Meyer" initials="D" surname="Meyer">
                • <organization/>
                • </author>
              • <author fullname="J Curran" initials="J" surname="Curran">
                • <organization/>
                • </author>
              • <date day="9" month="November" year="2007"/>
              • <abstract>
                • <t>
                  • One of the potential problems with the "map-and-encapsulate" approaches to routing architecture is that there is a significant chance of packets being dropped while a mapping is being retrieved. Some approaches pre-load ingress tunnel routers with at least part of the mapping database. Some approaches try to solve this by providing intermediate "default" routers which have a great deal more knowledge than a typical ingress tunnel router. This document proposes a scheme which does not drop packets yet does not require a great deal of knowledge in any router. However, there are still some issues that need to be worked out.
                  • </t>
                • </abstract>
              • </front>
            • </reference>
          • <reference anchor="DDT-ROOT" target="">
            • <front>
              • <title>
                • http://ddt-root.org/
                • </title>
              • <author surname="LISP DDT ROOT"/>
              • <date month="August" year="2013"/>
              • </front>
            • </reference>
          • <reference anchor="Quoitin" target="">
            • <front>
              • <title>
                • "Evaluating the Benefits of the Locator/Identifier Separation" in Proceedings of 2Nd ACM/IEEE International Workshop on Mobility in the Evolving Internet Architecture
                • </title>
              • <author initials="B." surname="Quoitin"/>
              • <author initials="L." surname="Iannone"/>
              • <author initials="C." surname="Launois"/>
              • <author initials="O." surname="Bonaventure"/>
              • <date year="2007"/>
              • </front>
            • </reference>
          • </references>
        • </references>
      • <section numbered="true" toc="default">
        • <name>
          • A Brief History of Location/Identity Separation
          • </name>
        • <t>
          • 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 <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC4984" format="default"/>.
          • </t>
        • <t>
          • A small group of like-minded personnel spontaneously formed immediately after that 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, 2007.
          • </t>
        • <t>
          • 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 this point represents a moderately mature system, having undergone a long organic series of changes and updates.
          • </t>
        • <t>
          • LISP transitioned from an IRTF activity to an IETF WG in March 2009, and after numerous revisions, the basic specifications moved to becoming RFCs at the start of 2013 (although work to expand and improve it, and find new uses for it, continues, and undoubtly will for a long time to come).
          • </t>
        • <section numbered="true" toc="default">
          • <name>
            • Old LISP Models
            • </name>
          • <t>
            • LISP, as initially conceived, had a number of potential operating modes, named 'models'. Although they are no used anymore, one occasionally sees mention of them, so they are briefly described here.
            • </t>
          • <dl newline="false" "true" spacing="normal">
            • <dt>
              • LISP 1:
              • </dt>
            • <dd>
              • EIDs all appear in the normal routing and forwarding tables of the network (i.e. they are 'routable');this property is used to 'bootstrap' operation, by using this to load EID->RLOC mappings. Packets were sent with the EID as the destination in the outer wrapper; when an ETR saw such a packet, it would send a Map-Reply to the source ITR, giving the full mapping.
              • </dd>
            • <dt>
              • LISP 1.5:
              • </dt>
            • <dd>
              • Similar to LISP 1, but the routability of EIDs happens on a separate network.
              • </dd>
            • <dt>
              • LISP 2:
              • </dt>
            • <dd>
              • EIDs are not routable; EID->RLOC mappings are available from the DNS.
              • </dd>
            • <dt>
              • LISP 3:
              • </dt>
            • <dd>
              • EIDs are not routable; and have to be looked up in in a new EID->RLOC mapping database (in the initial concept, a system using Distributed Hash Tables). Two variants were possible: a 'push' system, in which all mappings were distributed to all ITRs, and a 'pull' system in which ITRs load the mappings they need, as needed.
              • </dd>
            • </dl>
          • </section>
        • </section>
      • </back>
    • </rfc>
1<?xml version='1.0' encoding='utf-8'?>
3<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info"
4     ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
5     xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true"
6     version="3" number="0000" consensus="true">
8  <!-- xml2rfc v2v3 conversion 2.23.0 -->
10  <front>
11    <title abbrev="LISP Introduction">An Architectural Introduction to the Locator/ID Separation Protocol (LISP)</title>
12    <seriesInfo name="RFC" value="0000"/>
13    <author fullname="Albert Cabellos" initials="A." surname="Cabellos">
14      <organization>UPC-BarcelonaTech</organization>
15      <address>
16        <postal>
17          <street>c/ Jordi Girona 1-3</street>
18          <city>Barcelona</city>
19          <code>08034</code>
20          <region>Catalonia</region>
21          <country>Spain</country>
22        </postal>
23        <email>acabello@ac.upc.edu</email>
24      </address>
25    </author>
26    <author fullname="Damien Saucez (Ed.)" initials="D." surname="Saucez (Ed.)">
27      <organization>INRIA</organization>
28      <address>
29        <postal>
30          <street>2004 route des Lucioles BP 93</street>
31          <city>Sophia Antipolis Cedex</city>
32          <code>06902</code>
33          <country>France</country>
34        </postal>
35        <email>damien.saucez@inria.fr</email>
36      </address>
37    </author>
38    <date month="August" year="2019"/>
39    <area>Routing Area</area>
40    <keyword>LISP</keyword>
41    <keyword>Architecture</keyword>
42    <abstract>
43      <t>This document describes the architecture of the Locator/ID Separation
44 Protocol (LISP), making it easier to read the rest of the LISP
45 specifications and providing a basis for discussion about the details
46 of the LISP protocols. This document is used for introductory purposes, 
47 more details can be found in RFC6830, the protocol specification.</t>
48    </abstract>
49  </front>
50  <middle>
51    <section numbered="true" toc="default">
52      <name>Introduction</name>
53      <t>This document introduces the Locator/ID Separation Protocol (LISP)
54 <xref target="RFC6830" format="default"/> architecture, its main operational mechanisms and its design
55 rationale. Fundamentally, LISP is built following a well-known
56 architectural idea: decoupling the IP address overloaded semantics.
57 Indeed and as pointed out by Noel Chiappa <xref target="RFC4984" format="default"/>, currently IP addresses both
58 identify the topological location of a network attachment point as
59 well as the node's identity.  However, nodes and routing have
60 fundamentally different requirements, routing systems require that
61 addresses are aggregatable and have topological meaning, while nodes
62 require to be identified independently of their current location <xref target="RFC4984" format="default"/>.</t>
63      <t>LISP creates two separate namespaces, EIDs (End-host IDentifiers) and
64 RLOCs (Routing LOCators), both are 
65 syntactically identical to the current IPv4 and IPv6 addresses.  EIDs
66 are used to uniquely identify nodes irrespective of their topological
67 location and are typically routed intra-domain. RLOCs are assigned
68 topologically to network attachment points and are typically routed
69 inter-domain.  With LISP, the edge of the Internet (where the nodes
70 are connected) and the core (where inter-domain routing occurs) can be
71 logically separated and interconnected by LISP-capable routers.
72 LISP also introduces a database, called the
73 Mapping System, to store and retrieve mappings between identity and
74 location.  LISP-capable routers exchange packets over the Internet
75 core by encapsulating them to the appropriate location.</t>
76      <t>In summary:</t>
77      <ul spacing="normal">
78        <li>RLOCs have meaning only in the underlay network, that is the underlying core routing system.</li>
79        <li>EIDs have meaning only in the overlay network, which is the encapsulation relationship between LISP-capable routers.</li>
80        <li>The LISP edge maps EIDs to RLOCs</li>
81        <li>Within the underlay network, RLOCs have both locator and
82        identifier semantics</li>
83        <li>An EID within a LISP site carries both identifier and locator
84        semantics to other nodes within that site</li>
85        <li>An EID within a LISP site carries identifier and limited locator
86        semantics to nodes at other LISP sites (i.e., enough locator
87        information to tell that the EID is external to the site)</li>
88      </ul>
89      <t>The relationship described above is not unique to LISP but it is
90    common to other overlay technologies.</t>
91      <t>
92The initial motivation in the LISP effort is to be found in the
93    routing scalability problem <xref target="RFC4984" format="default"/>, where, if LISP were to be completely
94    deployed, the Internet core is populated with RLOCs while Traffic
95    Engineering mechanisms are pushed to the Mapping System.  
97          In such scenario RLOCs are quasi-static (i.e., low churn), hence making the routing system
98    scalable <xref target="Quoitin" format="default"/>, while EIDs can roam anywhere with no churn to the
99    underlying routing system. <xref target="RFC7215" format="default"/> discusses the impact of LISP on the global routing 
100          system during the transition period. However, the separation between location and identity
101    that LISP offers makes it suitable for use in additional
102    scenarios such as Traffic Engineering (TE), multihoming, and
103    mobility among others.</t>
104      <t>This document describes the LISP architecture and its main
105   operational mechanisms as well as its design rationale. It is important to note that this
106 document does not specify or complement the LISP protocol. The
107 interested reader should refer to the main LISP specifications <xref target="RFC6830" format="default"/> and the complementary documents <xref target="RFC6831" format="default"/>, <xref target="RFC6832" format="default"/>, <xref target="RFC6833" format="default"/>, <xref target="RFC6834" format="default"/>, <xref target="RFC6835" format="default"/>,
108 <xref target="RFC6836" format="default"/>, <xref target="RFC7052" format="default"/> for the protocol specifications along with the 
109 LISP deployment guidelines <xref target="RFC7215" format="default"/>.</t>
110    </section>
111    <section numbered="true" toc="default">
112      <name>Definition of Terms</name>
113      <dl newline="true" spacing="normal">
114        <dt>Endpoint IDentifier (EID):</dt>
115        <dd> EIDs are addresses used to uniquely identify nodes irrespective of their topological location and are typically routed intra-domain.</dd>
116        <dt>Routing LOcator (RLOC):</dt>
117        <dd>RLOCs are addresses assigned topologically to network attachment points and typically routed inter-domain.</dd>
118        <dt>Ingress Tunnel Router (ITR):</dt>
119        <dd>A LISP-capable router that encapsulates packets from a LISP site towards the core network.</dd>
120        <dt>Egress Tunnel Router (ETR):</dt>
121        <dd>A LISP-capable router that decapsulates packets from the core of the network towards a LISP site.</dd>
122        <dt>xTR:</dt>
123        <dd>A router that implements both ITR and ETR functionalities.</dd>
124        <dt>Map-Request:</dt>
125        <dd>A LISP signaling message used to request an EID-to-RLOC mapping.</dd>
126        <dt>Map-Reply:</dt>
127        <dd>A LISP signaling message sent in response to a Map-Request that contains a resolved EID-to-RLOC mapping.</dd>
128        <dt>Map-Register:</dt>
129        <dd>A LISP signaling message used to register an EID-to-RLOC mapping.</dd>
130        <dt>Map-Notify:</dt>
131        <dd>A LISP signaling message sent in response of a Map-Register to acknowledge the correct reception of an EID-to-RLOC mapping.</dd>
132      </dl>
133      <t>This document describes the LISP architecture and does not  
134 introduce any new term. The reader is referred to <xref target="RFC6830" format="default"/>, <xref target="RFC6831" format="default"/>, <xref target="RFC6832" format="default"/>, <xref target="RFC6833" format="default"/>, <xref target="RFC6834" format="default"/>, <xref target="RFC6835" format="default"/>,
135       <xref target="RFC6836" format="default"/>, <xref target="RFC7052" format="default"/>, <xref target="RFC7215" format="default"/> for the complete definition of terms.</t>
136    </section>
137    <section numbered="true" toc="default">
138      <name>LISP Architecture</name>
139      <t>This section presents the LISP architecture, it first details the
140      design principles of LISP and then it proceeds to describe its main aspects:
141      data-plane, control-plane, and internetworking mechanisms.</t>
142      <section numbered="true" toc="default">
143        <name>Design Principles</name>
144        <t>The LISP architecture is built on top of four basic design
145        principles:</t>
146        <ul spacing="normal">
147          <li>Locator/Identifier split: By decoupling the overloaded semantics of the
148            current IP addresses the Internet core can be assigned identity meaningful addresses and hence, can use aggregation to
149            scale. Devices are assigned with relatively opaque topologically meaningful addresses that
150            are independent of their topological location.</li>
151          <li>Overlay architecture: Overlays route packets over the current
152            Internet, allowing deployment of new protocols without changing the
153            current infrastructure hence, resulting into a low deployment
154            cost.</li>
155          <li>Decoupled data and control-plane: Separating the data-plane
156            from the control-plane allows them to scale independently and use
157            different architectural approaches. This is important given that
158            they typically have different requirements and allows for other data-planes to be added. While decoupled, data and control-plane
159      are not completely isolated because the LISP data-plane may
160      trigger control-plane activity.</li>
161          <li>Incremental deployability: This principle ensures that the protocol interoperates with the legacy Internet while providing some of the targeted benefits to early adopters.</li>
162        </ul>
163      </section>
164      <section numbered="true" toc="default">
165        <name>Overview of the Architecture</name>
166        <t>LISP splits architecturally the core from the edge of the Internet
167        by creating two separate namespaces: Endpoint Identifiers (EIDs) and
168        Routing LOCators (RLOCs). The edge consists of LISP sites (e.g., an Autonomous
169        System) that use EID addresses. EIDs are IPv4 or IPv6
170        addresses that uniquely identify communication end-hosts and are assigned and
171        configured by the same mechanisms that exist at the time of this
172 writing. EIDs do not contain inter-domain topological information and
173 because of this, EIDs are usually routable at the edge (within LISP
174 sites) or in the non-LISP Internet; see <xref target="internetwork"/>
175 for discussion of LISP site internetworking with non-LISP sites and domains in the Internet.</t>
176        <t>LISP sites (at the edge of the Internet) are connected to the core
177 of the Internet by means of LISP-capable routers (e.g., border
178 routers).  LISP sites are connected across the core of the Internet
179 using tunnels between the LISP-capable routers. 
180When 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).
182 An xTR is a router which can perform both ITR and ETR operations. In this context ITRs
183 encapsulate packets while ETRs decapsulate them, hence LISP operates
184 as an overlay on top of the current Internet core.</t>
185 <figure anchor="fig1" title="A Schema of the LISP Architecture">
186        <artwork name="" type="" align="left" alt=""><![CDATA[
188                       /-----------------\                 ---
189                       |     Mapping     |                  | 
190                       .     System      |                  | Control
191                      -|                 |`,                | Plane  
192                    ,' \-----------------/  .               |
193                   /                         |             ---
194   ,..,           -        _,....,,          |      ,..,    | 
195 /     `        ,'      ,-`        `',       |    /     `   | 
196/        \ +-----+   ,'              `,  +-----+ /        \ |        
197|  EID   |-| xTR |--/        RLOC     ,--| xTR |-|  EID   | | Data  
198| Space  |-|     |--|       Space     |--|     |-| Space  | | Plane 
199\        / +-----+  .                 /  +-----+ \        / |        
200 `.    .'            `.              ,'           `.    .'  |   
201   `'-`                `.,        ,.'               `'-`   ---  
202                          ``'''``                                  
203  LISP Site (Edge)            Core              LISP Site (Edge)        
206 </figure>
207        <t>With LISP, the core uses RLOCs, an RLOC is an IPv4 or IPv6
208        address assigned to an Internet-facing network interface of an ITR or
209        ETR. Typically RLOCs are numbered from topologically aggregatable
210        blocks assigned to a site at each point to which it attaches to the
211        global Internet, the topology is defined by the connectivity of
212        networks.</t>
213        <t>A database which is typically distributed, called the Mapping System,
214 stores mappings between EIDs and RLOCs. Such mappings relate
215        the identity of the devices attached to LISP sites (EIDs) to the set
216        of RLOCs configured at the LISP-capable routers servicing the site.
217        Furthermore, the mappings also include traffic engineering policies
218        and can be configured to achieve multihoming and load balancing. The
219        LISP Mapping System is conceptually similar to the DNS 
220 where it is organized as a distributed multi-organization network database. 
221 With LISP, ETRs register mappings while ITRs retrieve them.</t>
222        <t>Finally, the LISP architecture emphasizes incremental deployment. Given that LISP represents an
223        overlay to the current Internet architecture, endhosts as well as
224        intra and inter-domain routers remain unchanged, and the only required
225        changes to the existing infrastructure are to routers connecting the
226        EID with the RLOC space. Additionally, LISP requires the deployment of
227        an independent Mapping System, such distributed database is a new
228        network entity.</t>
229        <t>The following describes a simplified packet flow sequence
230        between two nodes that are attached to LISP sites. Please note that typical LISP-capable routers are xTRs (both ITR and ETR). Client HostA
231        wants to send a packet to server HostB.</t>
232<figure anchor="fig2" title="Packet Flow Sequence in LISP">      
233  <artwork name="" type="" align="left" alt=""><![CDATA[
235                         /----------------\
236                         |     Mapping    |
237                         |     System     |
238                        .|                |-           
239                       ` \----------------/ `.         
240                     ,`                       \        
241                    /                          `.      
242                  ,'         _,..-..,,           ',                 
243                 /         -`         `-,          \                
244               .'        ,'              \          `,              
245               `        '                 \           '             
246           +-----+     |                   | RLOC_B1+-----+         
247    HostA  |     |    |        RLOC         |-------|     |  HostB  
248    EID_A--|ITR_A|----|        Space        |       |ETR_B|--EID_B  
249           |     | RLOC_A1                  |-------|     |         
250           +-----+     |                   | RLOC_B2+-----+         
251                        ,                 /                         
252                         \               /                          
253                          `',         ,-`                           
254                             ``''-''``                              
256 ]]></artwork>
257      </figure>
258        <ol spacing="normal" type="1">
259          <li>HostA retrieves the EID_B of HostB, typically querying the DNS and obtaining an A or AAAA record.
260            Then it generates an IP packet as in the Internet, the packet
261            has source address EID_A and destination address EID_B.</li>
262          <li>The packet is routed towards ITR_A in the LISP site using
263            standard intra-domain mechanisms.</li>
264          <li>ITR_A upon receiving the packet queries the Mapping System to
265            retrieve the locator of ETR_B that is servicing HostB's EID_B. In order
266            to do so it uses a LISP control message called Map-Request, the
267            message contains EID_B as the lookup key. In turn it receives
268            another LISP control message called Map-Reply, the message
269            contains two locators: RLOC_B1 and RLOC_B2 along with traffic
270            engineering policies: priority and weight per locator. Note that a Map-Reply can contain more locators if needed.
271    ITR_A also stores the mapping in a local cache to speed-up 
272    forwarding of subsequent packets.</li>
273          <li>ITR_A encapsulates the packet towards RLOC_B1 (chosen according
274            to the priorities/weights specified in the mapping). The packet contains two
275            IP headers, the outer header has RLOC_A1 as source and RLOC_B1 as
276            destination, the inner original header has EID_A as source and EID_B as
277            destination. Furthermore ITR_A adds a LISP header, more details
278            about LISP encapsulation can be found in <xref target="encapsulation" format="default"/>.</li>
279          <li>The encapsulated packet is forwarded by the Internet core as a
280            normal IP packet, making the EID invisible from the Internet core.</li>
281          <li>Upon reception of the encapsulated packet by ETR_B, it
282            decapsulates the packet and forwards it to HostB.</li>
283        </ol>
284      </section>
285      <section numbered="true" toc="default">
286        <name>Data-Plane</name>
287        <t>This section provides a high-level description of the LISP data-plane, 
288 which is specified in detail in <xref target="RFC6830" format="default"/>. The LISP data-plane is responsible for 
289        encapsulating and decapsulating data packets and caching the
290        appropriate forwarding state. It includes two main entities, the ITR
291        and the ETR, both are LISP capable routers that connect the EID with
292 the RLOC space (ITR) and vice versa (ETR). </t>
293        <section anchor="encapsulation" numbered="true" toc="default">
294          <name>LISP Encapsulation</name>
295          <t>ITRs encapsulate data packets towards ETRs. LISP data packets are
296          encapsulated using UDP (port 4341), the source port is usually selected by the ITR using a 5-tuple hash of the inner header (so to be consistent in case of multi-path solutions such as ECMP <xref target="RFC2992" format="default"/>) and ignored on reception.  LISP data packets are often encapsulated in UDP packets that
297   include a zero checksum <xref target="RFC6935" format="default"/> <xref target="RFC6936" format="default"/> that is not verified
298   when it is received, because LISP data packets typically include
299   an inner transport protocol header with a non-zero checksum. By
300   omitting the additional outer UDP encapsulation checksum, xTRs
301   can forward packets more efficiently. If LISP data packets are
302   encapsulated in UDP packets with non-zero checksums, the outer
303   UDP checksums are verified when the UDP packets are received, as
304   part of normal UDP processing.</t>
305          <t>LISP-encapsulated packets also include a LISP header (after the
306          UDP header and before the original IP header). The LISP header is prepended by ITRs and striped by
307          ETRs. It carries reachability information (see more details in <xref target="reachability" format="default"/>) and the Instance ID
308   field. 
309   The Instance ID field is used to distinguish traffic to/from
310   different tenant address spaces at the LISP site and that may use
311   overlapped but logically separated EID addressing.</t>
312          <t>Overall, LISP works on 4 headers, the inner header the source constructed, and the 3 headers a LISP encapsulator prepends ("outer" to "inner"):</t>
313          <ol spacing="normal" type="1">
314            <li>Outer IP header containing RLOCs as source and destination
315              addresses. This header is originated by ITRs and stripped by
316              ETRs.</li>
317            <li>UDP header (port 4341) with zero checksum. This header is
318              originated by ITRs and stripped by ETRs.</li>
319            <li>LISP header that contains various forwarding-plane features (such as reachability) and an
320              Instance ID field. This header is originated by ITRs and
321              stripped by ETRs.</li>
322            <li>Inner IP header containing EIDs as source and destination
323              addresses. This header is created by the source end-host and
324              is left unchanged by LISP data plane processing on the ITR and ETR.</li>
325          </ol>
326          <t>Finally, in some scenarios Re-encapsulating and/or Recursive
327 tunnels are useful to choose a specified path in the underlay network, for instance to avoid congestion or failure. 
328 Re-encapsulating tunnels are consecutive LISP tunnels and occur when
329 a decapsulator (an ETR action) removes a LISP header and then acts as an encapsultor (an ITR action) to prepend
330 another one.  On the other hand, Recursive tunnels are nested tunnels
331 and are implemented by using multiple LISP encapsulations on a packet. Such functions are implemented by Reencapsulating Tunnel
332 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, more information can be found at <xref target="RFC6830" format="default"/>.</t>
333        </section>
334        <section numbered="true" toc="default">
335          <name>LISP Forwarding State</name>
336          <t>In the LISP architecture, ITRs keep just enough information to route
337    traffic flowing through them. Meaning that, ITRs retrieve from the LISP
338    Mapping System mappings between EID-prefixes (blocks of EIDs) and RLOCs that are used
339    to encapsulate packets.  Such mappings are stored in a local cache
340  called the Map-Cache for subsequent packets addressed to the same EID
341    prefix.  Note that, in case of overlapping EID-prefixes, following a
342    single request, the ITR may receive a set of mappings, covering the
343    requested EID-prefix and all more-specifics (cf. <xref
344 target="RFC6830" sectionFormat="comma" section="6.1.5"/>). Mappings include a (Time-to-Live) TTL (set by the ETR).
345    More details about the Map-Cache management can be found in <xref target="management" format="default"/>.
346          </t>
347        </section>
348      </section>
349      <section numbered="true" toc="default">
350        <name>Control-Plane</name>
351        <t>
352 The LISP control-plane, specified in <xref target="RFC6833" format="default"/>, provides a standard
353 interface to register and request mappings.  The LISP
354 Mapping System is a database that stores such
355 mappings.  The following first describes the mappings, then the
356 standard interface to the Mapping System, and finally its architecture.</t>
357        <section numbered="true" toc="default">
358          <name>LISP Mappings</name>
359          <t>Each mapping includes the bindings between EID prefix(es) and
360          set of RLOCs as well as traffic engineering policies, in the form of
361          priorities and weights for the RLOCs. Priorities allow the ETR to
362          configure active/backup policies while weights are used to
363          load-balance traffic among the RLOCs (on a per-flow basis).</t>
364          <t>Typical mappings in LISP bind EIDs in the form of IP prefixes with
365 a set of RLOCs, also in the form of IPs.  IPv4 and IPv6 addresses are
366 encoded using the appropriate Address Family Identifier (AFI)
367 <xref target="RFC3232" format="default"/>. However LISP can also support more general address encoding 
368 by means of the ongoing effort around the LISP Canonical Address Format (LCAF)
369 <xref target="I-D.ietf-lisp-lcaf" format="default"/>.</t>
370          <t>With such a general syntax for address encoding in place, LISP
371          aims to provide flexibility to current and future applications. For
372          instance LCAFs could support 
373          MAC addresses, geo-coordinates, ASCII names and application specific
374          data.</t>
375        </section>
376        <section numbered="true" toc="default">
377          <name>Mapping System Interface</name>
378          <t>LISP defines a standard interface between data and control
379          planes. The interface is specified in <xref target="RFC6833" format="default"/> and
380          defines two entities:</t>
381          <dl newline="true" spacing="normal">
382            <dt>Map-Server:</dt>
383            <dd>A network infrastructure component
384              that learns mappings from ETRs and publishes them into the LISP
385              Mapping System. Typically Map-Servers are not authoritative to
386              reply to queries and hence, they forward them to the ETR.
387              However they can also operate in proxy-mode, where the ETRs
388              delegate replying to queries to Map-Servers. This setup is
389              useful when the ETR has limited resources (i.e., CPU or power).</dd>
390            <dt>Map-Resolver:</dt>
391            <dd>A network infrastructure component
392              that interfaces ITRs with the Mapping System by proxying queries
393              and in some cases responses. </dd>
394          </dl>
395          <t> The interface defines four LISP control messages which are
396          sent as UDP datagrams (port 4342):</t>
397          <dl newline="true" spacing="normal">
398            <dt>Map-Register:</dt>
399            <dd>This message is used by ETRs to
400              register mappings in the Mapping System and it is authenticated
401              using a shared key between the ETR and the Map-Server.</dd>
402            <dt>Map-Notify:</dt>
403            <dd>When requested by the ETR, this message is sent by the
404 Map-Server in response to a Map-Register to acknowledge the correct
405 reception of the mapping and convey the latest Map-Server state on the
406 EID to RLOC mapping. In some cases a Map-Notify can be sent to the previous RLOCs when an EID is registered by a new set of RLOCs.</dd>
407            <dt>Map-Request:</dt>
408            <dd>This message is used by ITRs or
409              Map-Resolvers to resolve the mapping of a given EID.</dd>
410            <dt>Map-Reply:</dt>
411            <dd>This message is sent by Map-Servers or ETRs in response to
412 a Map-Request and contains the resolved mapping.  Please note that a
413 Map-Reply may contain a negative reply if, for example, the queried EID is not part
414 of the LISP EID space.  In such cases the ITR typically forwards the
415 traffic natively (non encapsulated) to the public Internet, this
416 behavior is defined to support incremental deployment of LISP.</dd>
417          </dl>
418        </section>
419        <section numbered="true" toc="default">
420          <name>Mapping System</name>
421          <t>LISP architecturally decouples control and data-plane by means of
422          a standard interface. This interface glues the data-plane, routers
423          responsible for forwarding data-packets, with the LISP Mapping
424          System, a database responsible for storing
425          mappings.</t>
426          <t>With this separation in place the data and control-plane can use
427          different architectures if needed and scale independently.
428          Typically the data-plane is optimized to route packets according to
429          hierarchical IP addresses. However the control-plane may have
430          different requirements, for instance and by taking advantage of the
431          LCAFs, the Mapping System may be used to store
432          non-hierarchical keys (such as MAC addresses),
433          requiring different architectural approaches for scalability.
434          Another important difference between the LISP control and
435          data-planes is that, and as a result of the local mapping cache
436          available at ITR, the Mapping System does not need to operate at
437          line-rate.</t>
438          <t>
439       Many of the existing mechanisms to create distributed systems have been explored and considered for the Mapping System architecture:
440           graph-based databases in the form of LISP+ALT <xref target="RFC6836" format="default"/>, hierarchical databases in the form of LISP-DDT
441          <xref target="I-D.ietf-lisp-ddt" format="default"/>, monolithic databases in the form
442          of LISP-NERD <xref target="RFC6837" format="default"/>, flat databases
443          in the form of LISP-DHT <xref target="I-D.cheng-lisp-shdht" format="default"/>,<xref target="Mathy" format="default"/> and, a multicast-based database <xref target="I-D.curran-lisp-emacs" format="default"/>. Furthermore it is worth noting that, in some 
444          scenarios such as private deployments, the Mapping System can operate as logically centralized. 
445          In such cases it is typically composed of a single Map-Server/Map-Resolver.</t>
446          <t>The following focuses on the two mapping systems that have
447          been implemented and deployed (LISP-ALT and LISP+DDT).</t>
448          <section numbered="true" toc="default">
449            <name>LISP+ALT</name>
450            <t>
451   The LISP Alternative Topology (LISP+ALT) <xref target="RFC6836" format="default"/> was the first
452 Mapping System proposed, developed and deployed on the LISP pilot
453 network.  It is based on a distributed BGP overlay participated by
454 Map-Servers and Map-Resolvers. The nodes connect to their peers
455 through static tunnels. Each Map-Server involved in the ALT topology
456 advertises the EID-prefixes registered by the serviced ETRs, making
457 the EID routable on the ALT topology.
458            </t>
459            <t>When an ITR needs a mapping it sends a Map-Request to a Map-Resolver
460 that, using the ALT topology, forwards the Map-Request towards the
461 Map-Server responsible for the mapping. Upon reception the Map-Server
462 forwards the request to the ETR that in turn, replies directly to the
463 ITR using the native Internet core.</t>
464          </section>
465          <section numbered="true" toc="default">
466            <name>LISP-DDT</name>
467            <t>
468   LISP-DDT <xref target="I-D.ietf-lisp-ddt" format="default"/> is conceptually similar to the DNS, a
469 hierarchical directory whose internal structure mirrors the
470 hierarchical nature of the EID address space.  The DDT hierarchy is
471 composed of DDT nodes forming a tree structure, the leafs of the tree
472 are Map-Servers.  On top of the structure there is the DDT root node
473 <xref target="DDT-ROOT" format="default"/>, which is a particular instance of a DDT node and that
474 matches the entire address space.  As in the case of DNS, DDT supports
475 multiple redundant DDT nodes and/or DDT roots. Finally, Map-Resolvers
476 are the clients of the DDT hierarchy and can query either the DDT root
477 and/or other DDT nodes.
478            </t>
479<figure anchor="fig3" title="A Schematic Representation of the DDT Tree Structure">
480            <artwork name="" type="" align="left" alt=""><![CDATA[
481                        /---------\
482                        |         |
483                        | DDT Root|
484                        |   /0    |
485                      ,.\---------/-,      
486                  ,-'`       |       `'.,  
487               -'`           |           `-      
488           /-------\     /-------\    /-------\  
489           |  DDT  |     |  DDT  |    |  DDT  |  
490           | Node  |     | Node  |    | Note  |  ...
491           |  0/8  |     |  1/8  |    |  2/8  |  
492           \-------/     \-------/    \-------/  
493         _.                _.            . -..,,,_        
494       -`                -`              \        ````''--
495+------------+     +------------+   +------------+ +------------+     
496| Map-Server |     | Map-Server |   | Map-Server | | Map-Server |     
497| EID-prefix1|     | EID-prefix2|   | EID-prefix3| | EID-prefix4|     
498+------------+     +------------+   +------------+ +------------+
503Note: In the figure above, the prefixes and the structure depicted should only
504be considered as an example.</t>
505            <t>The DDT structure does not actually index EID-prefixes but
506            eXtended EID-prefixes (XEID). An XEID-prefix is just the
507            concatenation of the following fields (from most significant bit
508            to less significant bit): Database-ID, Instance ID, Address Family
509            Identifier and the actual EID-prefix. The Database-ID is provided
510            for possible future requirements of higher levels in the hierarchy
511            and to enable the creation of multiple and separate database
512            trees.</t>
513            <t>In order to resolve a query LISP-DDT operates in a similar way to the
514 DNS but only supports iterative lookups. DDT clients (usually Map-Resolvers)
515            generate Map-Requests to the DDT root node. In response they
516            receive a newly introduced LISP-control message: a Map-Referral. A
517            Map-Referral provides the list of RLOCs of the set of DDT nodes
518            matching a configured XEID delegation. That is, the information
519            contained in the Map-Referral points to the child of the queried
520            DDT node that has more specific information about the queried
521            XEID-prefix. This process is repeated until the DDT client walks
522            the tree structure (downwards) and discovers the Map-Server
523            servicing the queried XEID. At this point the client sends a
524            Map-Request and receives a Map-Reply containing the mappings. It
525            is important to note that DDT clients can also cache the
526            information contained in Map-Referrals, that is, they cache the
527            DDT structure. This is used to reduce the mapping retrieving
528            latency <xref target="Jakab" format="default"/>.</t>
529            <t>The DDT Mapping System relies on manual configuration. That is
530            Map- Resolvers are manually configured with the set of available
531            DDT root nodes while DDT nodes are manually configured with the
532            appropriate XEID delegations. Configuration changes in the DDT
533            nodes are only required when the tree structure changes itself,
534            but it doesn't depend on EID dynamics (RLOC allocation or traffic
535            engineering policy changes).</t>
536          </section>
537        </section>
538      </section>
539      <section numbered="true" toc="default" anchor="internetwork">
540        <name>Internetworking Mechanisms</name>
541        <t>EIDs are typically identical to either IPv4 or IPv6 addresses and
542        they are stored in the LISP Mapping System, however they are usually not
543        announced in the Internet global routing system. As a result LISP
544        requires an internetworking mechanism to allow LISP sites to speak
545        with non-LISP sites and vice versa. LISP internetworking mechanisms are
546        specified in <xref target="RFC6832" format="default"/>.</t>
547        <t>LISP defines two entities to provide internetworking:</t>
548        <dl newline="true" spacing="normal">
549          <dt>Proxy Ingress Tunnel Router (PITR):</dt>
550          <dd>PITRs provide
551            connectivity from the legacy Internet to LISP sites. PITRs
552            announce in the global routing system blocks of EID prefixes
553            (aggregating when possible) to attract traffic. For each incoming packet from a source not in a LISP site (a non-EID), 
554 the PITR LISP-encapsulates it towards the RLOC(s) of
555            the appropriate LISP site. The impact of PITRs in the routing
556            table size of the Default-Free Zone (DFZ) is, in the worst-case, similar to the case
557            in which LISP is not deployed. EID-prefixes will be aggregated 
558            as much as possible both by the PITR and by the global routing system.</dd>
559          <dt>Proxy Egress Tunnel Router (PETR):</dt>
560          <dd>PETRs provide
561            connectivity from LISP sites to the legacy Internet. In some scenarios, LISP sites may be unable to send encapsulated
562 packets with a local EID address as a source to the legacy Internet. For instance when Unicast Reverse Path
563            Forwarding (uRPF) is used by Provider Edge routers, or when an
564            intermediate network between a LISP site and a non-LISP site does
565            not support the desired version of IP (IPv4 or IPv6). In both
566            cases the PETR  overcomes such limitations by
567            encapsulating packets over the network.
568 There is no specified provision for the distribution of PETR RLOC addresses to the ITRs.</dd>
569        </dl>
570        <t>Additionally, LISP also defines mechanisms to operate with private EIDs <xref target="RFC1918" format="default"/> by means of LISP-NAT <xref target="RFC6832" format="default"/>. In this case 
571 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 xTRs behind a NAT using non-routable RLOCs.</t>
572        <t>PITRs, PETRs and, LISP-NAT enable incremental deployment of LISP, 
573 by providing significant flexibility in the placement of the boundaries between the 
574 LISP and non-LISP portions of the network, and making it easy to change those boundaries over time.</t>
575      </section>
576    </section>
577    <section numbered="true" toc="default">
578      <name>LISP Operational Mechanisms</name>
579      <t>This section details the main operational mechanisms defined in
580      LISP.</t>
581      <section anchor="management" numbered="true" toc="default">
582        <name>Cache Management</name>
583        <t>LISP's decoupled control and data-plane, where mappings are
584          stored in the control-plane and used for forwarding in the data
585          plane, requires a local cache in ITRs to reduce signaling
586          overhead (Map-Request/Map-Reply) and increase forwarding speed. The
587          local cache available at the ITRs, called Map-Cache, is used by the
588          router to LISP-encapsulate packets. The Map-Cache is indexed by
589          (Instance ID, EID-prefix) and contains basically the set
590          of RLOCs with the associated traffic engineering policies (priorities and
591          weights).</t>
592        <t>The Map-Cache, as any other cache, requires cache coherence
593          mechanisms to maintain up-to-date information. LISP defines three
594          main mechanisms for cache coherence:</t>
595        <dl newline="true" spacing="normal">
596          <dt>Time-To-Live (TTL):</dt>
597          <dd>Each mapping contains a TTL set by the ETR, upon
598 expiration of the TTL the ITR can't use the mapping until it is refreshed by 
599 sending a new Map-Request.  Typical values for TTL defined by LISP
600 are 24 hours.</dd>
601          <dt>Solicit-Map-Request (SMR):</dt>
602          <dd>SMR is an explicit
603              mechanism to update mapping information. In particular a special
604              type of Map-Request can be sent on demand by ETRs to request refreshing
605             a mapping. Upon reception of a SMR
606              message, the ITR must refresh the bindings by sending a
607              Map-Request to the Mapping System. Further uses of SMRs are documented in <xref target="RFC6830" format="default"/>.</dd>
608          <dt>Map-Versioning:</dt>
609          <dd>This optional mechanism piggybacks in the LISP header of data-packets the
610            version number of the mappings used by an xTR.  This way, when an xTR receives
611            a LISP-encapsulated packet from a remote xTR, it can check whether its own
612            Map-Cache or the one of the remote xTR is outdated.  If its Map-Cache is
613            outdated, it sends a Map-Request for the remote EID so to obtain the newest
614            mappings.  On the contrary, if it detects that the remote xTR Map-Cache is
615            outdated, it sends a SMR to notify it that a new mapping is available.</dd>
616        </dl>
617        <t>Finally it is worth noting that in some cases an entry in the
618 map-cache can be proactively refreshed using the mechanisms described
619 in the section below.</t>
620      </section>
621      <section anchor="reachability" numbered="true" toc="default">
622        <name>RLOC Reachability</name>
623        <t>In most cases LISP operates with a pull-based Mapping System (e.g., DDT), 
624 this results in an edge to edge pull architecture. In such scenario the network 
625 state is stored in the control-plane while the data-plane pulls it on demand.  
626 This has consequences concerning the propagation of xTRs reachability/liveness 
627 information since pull architectures require explicit mechanisms to propagate this information.  
628 As a result LISP defines a set of mechanisms to inform ITRs and PITRS about the reachability of the cached RLOCs:</t>
629<dl newline="true" spacing="normal">
630<dt>Locator Status Bits (LSB):</dt><dd>LSB is a passive technique, the LSB field is carried by data-packets
631 in the LISP header and can be set by a ETRs to specify which RLOCs of the ETR site are
632 up/down. This information
633        can be used by the ITRs as a hint about the reachability to perform
634        additional checks. Also note that LSB does not provide path
635        reachability status, only hints on the status of RLOCs.</dd>
636        <dt>Echo-nonce:</dt><dd>This is also a passive technique, that can only operate
637        effectively when data flows bi-directionally between two communicating xTRs.
638        Basically, an ITR piggybacks a random number (called nonce) in LISP
639        data packets, if the path and the probed locator are up, the ETR will
640        piggyback the same random number on the next data-packet, if this is
641        not the case the ITR can set the locator as unreachable. When traffic
642        flow is unidirectional or when the ETR receiving the traffic is not
643        the same as the ITR that transmits it back, additional mechanisms are
644        required.</dd>
645        <dt>RLOC-probing:</dt><dd>This is an active probing algorithm where ITRs send
646 probes to specific locators, this effectively probes both the locator
647 and the path. In particular this is done by sending a Map-Request
648 (with certain flags activated) on the data-plane (RLOC space) and
649 waiting in return a Map-Reply, also sent on the data-plane. The active
650        nature of RLOC-probing provides an effective mechanism to determine
651        reachability and, in case of failure, switching to a different
652        locator. Furthermore the mechanism also provides useful RTT
653        estimates of the delay of the path that can be used by other network
654        algorithms.</dd>
655      </dl>
656        <t>It is worth noting that RLOC probing and Echo-nonce can work together.
657 Specifically if a nonce is not echoed, an ITR could RLOC-probe to
658 determine if the path is up when it cannot tell the difference between a 
659 failed bidirectional path or the return path is not used (a
660 unidirectional path).</t>
662        <t>Additionally, LISP also recommends inferring reachability of
663        locators by using information provided by the underlay, in
664        particular:</t>
665 <dl newline="true" spacing="normal">
666        <dt>ICMP signaling:</dt><dd>The LISP underlay -the current Internet- uses the
667        ICMP protocol to signal unreachability (among other things). LISP can
668        take advantage of this and the reception of a ICMP Network Unreachable
669        or ICMP Host Unreachable message can be seen as a hint that a locator
670        might be unreachable, this should lead to perform additional
671        checks.</dd>
672        <dt>Underlay routing:</dt><dd>Both BGP and IBGP carry reachability information,
673        LISP-capable routers that have access to underlay routing information
674        can use it to determine if a given locator or path are reachable.</dd>
675 </dl>
676      </section>
677      <section numbered="true" toc="default">
678        <name>ETR Synchronization</name>
679        <t>All the ETRs that are authoritative to a particular EID-prefix must 
680 announce the same mapping to the requesters, this means that ETRs must be 
681 aware of the status of the RLOCs of the remaining ETRs. This is known as
682 ETR synchronization.</t>
683        <t>At the time of this writing LISP does not specify a mechanism to achieve ETR
684   synchronization. Although many well-known techniques could be applied to solve this issue
685   it is still under research, as a result operators must
686   rely on coherent manual configuration</t>
687      </section>
688      <section numbered="true" toc="default">
689        <name>MTU Handling</name>
690        <t>Since LISP encapsulates packets it requires dealing with packets that exceed the MTU of the path between the ITR
691                and the ETR. Specifically LISP defines two mechanisms:</t>
692        <dl newline="true" spacing="normal">
693          <dt>Stateless:</dt>
694          <dd>With this mechanism the effective MTU is assumed from the
695 ITR's perspective. If a payload packet is too big for the effective MTU, and
696 can be fragmented, the payload packet is fragmented on the ITR, such that
697 reassembly is performed at the destination host.</dd>
698          <dt>Stateful:</dt>
699          <dd>With this mechanism ITRs keep track of the MTU of the
700 paths towards the destination locators by parsing the ICMP Too Big
701 packets sent by intermediate routers. ITRs will send ICMP Too Big messages to inform the sources about the effective MTU. 
702 Additionally ITRs can use mechanisms such as PMTUD <xref target="RFC1191" format="default"/> or PLPMTUD <xref target="RFC4821" format="default"/> to keep track of the MTU towards the locators.</dd>
703        </dl>
704        <t>In both cases if the packet cannot be fragmented (IPv4 with DF=1 or IPv6) then the ITR drops
705                it and replies with a ICMP Too Big message to the source.</t>
706      </section>
707    </section>
708    <section numbered="true" toc="default">
709      <name>Mobility</name>
710      <t>The separation between locators and identifiers in LISP is suitable 
711 for traffic engineering purpose where LISP sites can change their attachment
712 points to the Internet (i.e., RLOCs) without impacting endpoints or the
713 Internet core. In this context, the border routers operate the xTR
714 functionality and endpoints are not aware of the existence of LISP. This functionality is similar to Network Mobility <xref target="RFC3963" format="default"/>. However,
715 this mode of operation does not allow seamless mobility of endpoints between
716 different LISP sites as the EID address might not be routable in a visited
717 site.  Nevertheless, LISP can be used to enable seamless IP mobility when LISP
718 is directly implemented in the endpoint or when the endpoint roams to an attached xTR.  
719 Each endpoint is then an xTR and the EID address is the one presented to the network stack used by applications
720 while the RLOC is the address gathered from the network when it is visited. This functionality is similar to Mobile IP (<xref target="RFC5944" format="default"/> and <xref target="RFC6275" format="default"/>).</t>
721      <t>Whenever the device changes of RLOC, the xTR updates the RLOC of its
722          local mapping and registers it to its Map-Server, typically with a low TTL value (1min). To avoid the need of a
723          home gateway, the ITR also indicates the RLOC change to all remote devices
724          that have ongoing communications with the device that moved.  The
725          combination of both methods ensures the scalability of the system as
726          signaling is strictly limited the Map-Server and to hosts with which
727          communications are ongoing. In the mobility case the EID-prefix can be as small as a full /32 or /128 (IPv4 or IPv6 respectively) depending on the specific use-case (e.g., subnet mobility vs single VM/Mobile node mobility).</t>
728      <t>The decoupled identity and location provided by LISP allows it to operate with other layer 2 and layer 3 mobility solutions.</t>
729    </section>
730    <section numbered="true" toc="default">
731      <name>Multicast</name>
732      <t>LISP also supports transporting IP multicast packets sent from the EID
733 space, the operational changes required to the multicast protocols are
734 documented in <xref target="RFC6831" format="default"/>.</t>
735      <t>In such scenarios, LISP may create multicast state both at the core
736 and at the sites (both source and receiver).  When signaling is used
737 to create multicast state at the sites, LISP routers unicast encapsulate
738 PIM Join/Prune messages from receiver to source sites.  At the core,
739 ETRs build a new PIM Join/Prune message addressed to the RLOC of the
740 ITR servicing the source.  An simplified sequence is shown below</t>
741      <ol spacing="normal" type="1">
742        <li>An end-host willing to join a multicast channel sends an IGMP
743 report. Multicast PIM routers at the LISP site propagate PIM
744 Join/Prune messages (S-EID, G) towards the ETR.</li>
745        <li>The join message flows to the ETR, upon reception the ETR builds two join messages, 
746             the first one unicast LISP-encapsulates the original join message towards the RLOC of the 
747             ITR servicing the source. This message creates (S-EID, G) multicast state at the source site.
748             The second join message contains as destination address the RLOC of the ITR 
749             servicing the source (S-RLOC, G) and creates multicast state at the core.</li>
750        <li>Multicast data packets originated by the source (S-EID, G) flow from the source
751         to the ITR. The ITR LISP-encapsulates the multicast packets, the outter header includes its own RLOC
752         as the source (S-RLOC) and the original multicast group address (G) as the destination. Please
753         note that multicast group address are logical and are not resolved by the mapping system. Then
754         the multicast packet is transmitted through the core towards the receiving ETRs that decapsulates
755         the packets and sends them using the receiver's site multicast state.</li>
756      </ol>
757      <t>Please note that the inner and outer multicast addresses are in general different, 
758 unless in specific cases where the underlay provider implements a tight control on the overlay. LISP specifications already support all PIM modes <xref target="RFC6831" format="default"/>. Additionally, 
759 LISP can support as well non-PIM mechanisms in order to maintain multicast state.</t>
760    </section>
761    <section numbered="true" toc="default">
762      <name>Use Cases</name>
763      <section numbered="true" toc="default">
764        <name>Traffic Engineering</name>
765        <t> A LISP site can strictly impose via which ETRs the
766          traffic must enter the the LISP site network even though the path followed to reach the
767          ETR is not under the control of the LISP site.  This fine control is
768          implemented with the mappings.  When a remote site is willing to send
769          traffic to a LISP site, it retrieves the mapping associated to the
770          destination EID via the mapping system.  The mapping is sent directly by an
771          authoritative ETR of the EID and is not altered by any intermediate network.  </t>
772        <t>A mapping associates a list of RLOCs to an EID prefix.  Each RLOC
773          corresponds to an interface of an ETR (or set of ETRs) that is able to correctly forward
774          packets to EIDs in the prefix.  Each RLOC is tagged with a priority and a
775          weight in the mapping.  The priority is used to indicates which RLOCs
776          should be preferred to send packets (the least preferred ones being
777          provided for backup purpose).  The weight permits to balance the load
778          between the RLOCs with the same priority, proportionally to the weight
779          value.</t>
780        <t>As mappings are directly issued by the authoritative ETR of the EID and are not altered
781          while transmitted to the remote site, it offers highly flexible incoming
782          inter-domain traffic engineering with even the possibility for a site to support a different mapping
783 policy for each remote site.
784          routing policies.</t>
785      </section>
786      <section numbered="true" toc="default">
787        <name>LISP for IPv6 Co-existence</name>
788        <t>LISP encapsulations allows to transport packets using EIDs from a given
789          address family (e.g., IPv6) with packets from other address families (e.g., IPv4). The absence of correlation between
790          the address family of RLOCs and EIDs makes LISP a candidate to allow, e.g., IPv6 to be deployed when all of the core
791 network may not have IPv6 enabled.</t>
792        <t>For example, two IPv6-only data centers could be interconnected via the
793          legacy IPv4 Internet. If their border routers are LISP capable, sending
794          packets between the data center is done without any form of translation as
795          the native IPv6 packets (in the EID space) will be LISP encapsulated and
796          transmitted over the IPv4 legacy Internet by the mean of IPv4 RLOCs.</t>
797      </section>
798      <section numbered="true" toc="default">
799        <name>LISP for Virtual Private Networks</name>
800        <t>It is common to operate several virtual networks over the same
801          physical infrastructure. In such virtual private networks, it is essential to distinguish which virtual
802          network a packet belongs and tags or labels are used for that purpose.
803          When using LISP, the distinction can be made with the Instance ID field.  When an
804          ITR encapsulates a packet from a particular virtual network (e.g., known
805          via the VRF or VLAN), it tags the encapsulated packet with the Instance ID
806          corresponding to the virtual network of the packet.  When an ETR receives a
807          packet tagged with an Instance ID it uses the Instance ID to determine how
808          to treat the packet. </t>
809        <t>The main usage of LISP for virtual private networks does not introduce 
810additional requirements on the underlying network, as long as it is  running IP.</t>
811      </section>
812      <section numbered="true" toc="default">
813        <name>LISP for Virtual Machine Mobility in Data Centers</name>
814        <t>A way to enable seamless virtual machine mobility in data center is to
815          conceive the datacenter backbone as the RLOC space and the subnet
816          where servers are hosted as forming the EID space. A LISP router is placed
817          at the border between the backbone and each subnet. When a virtual
818          machine is moved to another subnet, it can keep (temporarily) the address it had before the move so to continue without a 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.</t>
819        <t>To inform the other LISP routers that the machine moved and where, and then
820 to avoid detours via the initial subnetwork, mechanisms such as the
821 Solicit-Map-Request messages are used.</t>
822      </section>
823    </section>
824    <section numbered="true" toc="default">
825      <name>Security Considerations</name>
826      <t>This section describes the security considerations associated to the LISP protocol.</t>
827      <t>While in a push
828   mapping system, the state necessary to forward packets is learned
829   independently of the traffic itself, with a pull architecture, the
830   system becomes reactive and data-plane events (e.g., the arrival of a
831   packet for an unknown destination) may trigger control-plane events.
832   This on-demand learning of mappings provides many advantages as
833   discussed above but may also affect the way security is enforced.</t>
834      <t>Usually, the data-plane is implemented in the fast path of routers to
835        provide high performance forwarding capabilities while the control-plane
836        features are implemented in the slow path to offer high flexibility and a
837        performance gap of several order of magnitude can be observed between the slow
838        and the fast paths.  As a consequence, the way data-plane events are notified
839        to the control-plane must be thought carefully so to not overload the slow path
840        and rate limiting should be used as specified in <xref target="RFC6830" format="default"/>.</t>
841      <t>Care must also be taken so to not overload the mapping system (i.e., the
842        control plane infrastructure) as the operations to be performed by the mapping
843        system may be more complex than those on the data-plane, for that reason
844        <xref target="RFC6830" format="default"/> recommends to rate limit the sending of messages to the
845          mapping system.</t>
846      <t>To improve resiliency and reduce the overall number of messages exchanged,
847        LISP offers the possibility to leak information, such as reachabilty
848        of locators, directly into data plane packets.  In environments that are not
849        fully trusted, control information gleaned from data-plane packets should be
850        verified before using them.</t>
851      <t>
852   Mappings are the centrepiece of LISP and all precautions must be taken to
853   avoid them to be manipulated or misused by malicious entities.  Using
854   trustable Map-Servers that strictly respect <xref target="RFC6833"/> and the lightweight
855   authentication mechanism proposed by LISP-Sec <xref target="I-D.ietf-lisp-sec" format="default"/> reduces
856   the risk of attacks to the mapping integrity.  In more critical
857   environments, secure measures may be needed.  The way security is
858   implemented for a given mapping system strongly depends on the architecture
859   of the mapping system itself and the threat model assumed for the
860   deployment. Thus, the mapping system security has to be discussed in the 
861relevant documents proposing the mapping system architecture.
862      </t>
863      <t>
864 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 
865 inspect the content of LISP encapsulated packets. </t>
866      <t>
867     Like other map-and-encap mechanisms, LISP enables triangular routing (i.e.,
868 packets of a flow cross different border routers depending on their direction).
869 This means that intermediate boxes may have incomplete view on the traffic they
870 inspect or manipulate. Moreover, LISP-encapsulated packets are routed
871 based on the outer IP address (i.e., the RLOC), and can be
872 delivered to an ETR that is not responsible of the destination EID of the
873 packet or even to a network element that is not an ETR. The mitigation
874 consists in applying appropriate filtering techniques on the network elements
875 that can potentially receive un-expected LISP-encapsulated packets</t>
876      <t>More details about security implications of LISP are discussed in
877        <xref target="I-D.ietf-lisp-threats" format="default"/>.
878      </t>
879    </section>
880    <section numbered="true" toc="default">
881      <name>IANA Considerations</name>
882      <t>This memo includes no request to IANA.</t>
883    </section>
884    <section anchor="Acknowledgements" numbered="true" toc="default">
885      <name>Acknowledgements</name>
886      <t>This document was initiated by Noel Chiappa and much of the core
887 philosophy came from him.  The authors acknowledge the important contributions
888 he has made to this work and thank him for his past efforts.</t>
889      <t>The authors would also like to thank Dino Farinacci, Fabio Maino, 
890 Luigi Iannone,  Sharon Barkai, Isidoros Kouvelas, Christian Cassar, 
891 Florin Coras, Marc Binderberger, Alberto Rodriguez-Natal, Ronald Bonica, 
892 Chad Hintz, Robert Raszuk, Joel M. Halpern, Darrel Lewis, David Black as well as every people acknowledged in <xref target="RFC6830" format="default"/>.</t>
893    </section>
894  </middle>
895  <back>
896    <references>
897      <name>References</name>
898      <references>
899        <name>Normative References</name>
902    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1191.xml"/>
904    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1918.xml"/>
906    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2992.xml"/>
908    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3232.xml"/>
910    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3963.xml"/>
912    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4821.xml"/>
914    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4984.xml"/>
916    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5944.xml"/>
918    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6275.xml"/>
920    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6830.xml"/>
922    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6831.xml"/>
924    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6832.xml"/>
926    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6833.xml"/>
928    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6834.xml"/>
930    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6835.xml"/>
932    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6836.xml"/>
934    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6837.xml"/>
936    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6935.xml"/>
938    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6936.xml"/>
940    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7052.xml"/>
942    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7215.xml"/> 
945        <reference anchor="I-D.ietf-lisp-ddt" target="http://www.ietf.org/internet-drafts/draft-ietf-lisp-ddt-09.txt">
946          <front>
947            <title>LISP Delegated Database Tree</title>
948            <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-ddt-09"/>
949            <author initials="V" surname="Fuller" fullname="Vince Fuller">
950              <organization/>
951            </author>
952            <author initials="D" surname="Lewis" fullname="Darrel Lewis">
953              <organization/>
954            </author>
955            <author initials="V" surname="Ermagan" fullname="Vina Ermagan">
956              <organization/>
957            </author>
958            <author initials="A" surname="Jain" fullname="Amit Jain">
959              <organization/>
960            </author>
961            <author initials="A" surname="Smirnov" fullname="Anton Smirnov">
962              <organization/>
963            </author>
964            <date month="January" day="18" year="2017"/>
965            <abstract>
966              <t>This document describes the LISP Delegated Database Tree (LISP-DDT), a hierarchical, distributed database which embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs).  It is a statically-defined distribution of the EID namespace among a set of LISP-speaking servers, called DDT nodes.  Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated.</t>
967            </abstract>
968          </front>
969        </reference>
971        <reference anchor="I-D.ietf-lisp-lcaf" target="http://www.ietf.org/internet-drafts/draft-ietf-lisp-lcaf-22.txt">
972          <front>
973            <title>LISP Canonical Address Format (LCAF)</title>
974            <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-lcaf-22"/>
975            <author initials="D" surname="Farinacci" fullname="Dino Farinacci">
976              <organization/>
977            </author>
978            <author initials="D" surname="Meyer" fullname="David Meyer">
979              <organization/>
980            </author>
981            <author initials="J" surname="Snijders" fullname="Job Snijders">
982              <organization/>
983            </author>
984            <date month="November" day="28" year="2016"/>
985            <abstract>
986              <t>This document defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System.</t>
987            </abstract>
988          </front>
989        </reference>
991        <reference anchor="I-D.ietf-lisp-threats" target="http://www.ietf.org/internet-drafts/draft-ietf-lisp-threats-15.txt">
992          <front>
993            <title>LISP Threats Analysis</title>
994            <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-threats-15"/>
995            <author initials="D" surname="Saucez" fullname="Damien Saucez">
996              <organization/>
997            </author>
998            <author initials="L" surname="Iannone" fullname="Luigi Iannone">
999              <organization/>
1000            </author>
1001            <author initials="O" surname="Bonaventure" fullname="Olivier Bonaventure">