Network Working Group                                        A. Cabellos-Aparicio (Ed.) Cabellos
Internet-Draft                         Technical University of Catalonia                                         UPC-BarcelonaTech
Intended status: Informational                           D. Saucez (Ed.)
Expires: January 17, March 26, 2015                                            INRIA
                                                           July 16,
                                                      September 22, 2014

 An Architectural Introduction to the LISP Location-Identity Separation
                                 System
                  draft-ietf-lisp-introduction-04.txt
                  draft-ietf-lisp-introduction-05.txt

Abstract

   This document is an introductory overview of describes the Locator/ID Separation Protocol, it describes the major concepts and functional
   sub-systems of LISP Protocol (LISP)
   architecture, its main operational mechanisms as well as its design
   rationale.

Requirements Language

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

Status of This Memo

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

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 17, March 26, 2015.

Copyright Notice

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

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

Table of Contents

   1.  Prefatory Note  . . . .  Introduction  . . . . . . . . . . . . . . . . . . .   4
   2.  Part I . . . . .   3
   2.  LISP Architecture . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Initial Glossary
     2.1.  Design Principles . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Overview of the Architecture  . .   5
   4.  Background . . . . . . . . . . . .   4
     2.3.  Data-Plane  . . . . . . . . . . . . .   6
   5.  Deployment Philosophy . . . . . . . . . .   7
       2.3.1.  LISP encapsulation  . . . . . . . . . .   7
     5.1.  Economics . . . . . . .   7
       2.3.2.  LISP Forwarding State . . . . . . . . . . . . . . . .   8
     2.4.  Control-Plane .   7
     5.2.  Maximize Re-use of Existing Mechanism . . . . . . . . . .   8
   6.  LISP Overview . . . . . . . . . . .   9
       2.4.1.  LISP Mappings . . . . . . . . . . . . .   8
     6.1.  Basic Approach . . . . . . .   9
       2.4.2.  Mapping System Interface  . . . . . . . . . . . . . .   9
     6.2.  Basic Functionality . . . . . .
       2.4.3.  Mapping System  . . . . . . . . . . . . .   9
     6.3.  Mapping from EIDs to RLOCs . . . . . .  10
     2.5.  Internetworking Mechanisms  . . . . . . . . .  11
     6.4.  Interworking With Non-LISP-Capable Endpoints . . . . . .  11
     6.5.  Security in  13
   3.  LISP Operational Mechanisms . . . . . . . . . . . . . . . . .  13
     3.1.  Cache Management  . . .  12
   7.  Initial Applications  . . . . . . . . . . . . . . . . . . .  14
     3.2.  RLOC Reachability .  13
     7.1.  Provider Independence . . . . . . . . . . . . . . . . . .  13
     7.2.  Multi-Homing .  14
     3.3.  ETR Synchronization . . . . . . . . . . . . . . . . . . .  15
     3.4.  MTU Handling  . .  13
     7.3.  Traffic Engineering . . . . . . . . . . . . . . . . . . .  14
     7.4.  Routing .  16
   4.  Mobility  . . . . . . . . . . . . . . . . . . . . . . . .  15
     7.5.  Mobility . .  16
   5.  Multicast . . . . . . . . . . . . . . . . . . . . . .  15
     7.6.  Traversal Across Alternate IP Versions . . . .  17
   6.  Security  . . . . .  15
     7.7.  Virtual Private Networks . . . . . . . . . . . . . . . .  16
     7.8.  Local Uses . . . . .  17
   7.  Use Cases . . . . . . . . . . . . . . . . . .  16
   8.  Major Functional Subsystems . . . . . . . .  18
     7.1.  Traffic Engineering . . . . . . . . .  17
     8.1.  Data Plane - xTRs Overview . . . . . . . . . .  18
     7.2.  LISP for IPv6 Transition  . . . . .  17
       8.1.1.  Mapping Cache Performance . . . . . . . . . . .  19
     7.3.  LISP for Network Virtualization . . .  18
     8.2.  Control Plane - Mapping System Overview . . . . . . . . .  18
       8.2.1.  Mapping System Organization .  19
     7.4.  LISP for Virtual Machine Mobility in Data Centers . . . .  20
   8.  Security Considerations . . . . . . . .  19
       8.2.2.  Interface to the Mapping System . . . . . . . . . . .  20
       8.2.3.  Indexing Sub-system . .
   9.  IANA Considerations . . . . . . . . . . . . . . .  20
   9.  Examples of operation . . . . . .  20
   10. Acknowledgements  . . . . . . . . . . . . . .  22
     9.1.  An Ordinary Packet's Processing . . . . . . . .  21
   11. References  . . . . .  22
     9.2.  A Mapping Cache Miss . . . . . . . . . . . . . . . . . .  23
   10. Part II . .  21
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  21
     11.2.  Informative References . . . . . . .  24
   11. Design Approach . . . . . . . . . .  22
   Appendix A.  A Brief History of Location/Identity Separation  . .  23
     A.1.  Old LISP Models . . . . . . . . . . .  24
   12. xTRs . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . .  25
     12.1.  When to Encapsulate . . . . . . . . . . . . . . . . . .  25
     12.2.  UDP Encapsulation Details  . . . . . . . . . . . . . . .  26
     12.3.  Header Control Channel . . . . . . . . . . . . . . . . .  26
       12.3.1.  Mapping Versioning . . . . . . . . . . . . . . . . .  26
       12.3.2.  Echo Nonces  . . . . . . . . . . . . . . . . . . . .  27
       12.3.3.  Instances  . . . . . . . . . . . . . . . . . . . . .  27
     12.4.  Probing  . . . . . . . . . . . . . . . . . . . . . . . .  28
     12.5.  Mapping Lifetimes and Timeouts . . . . . . . . . . . . .  28
     12.6.  Mapping Gleaning in ETRs . . . . . . . . . . . . . . . .  29
     12.7.  MTU Issues . . . . . . . . . . . . . . . . . . . . . . .  29
     12.8.  Security of Mapping Lookups  . . . . . . . . . . . . . .  29
     12.9.  ITR Mapping Cache Performance  . . . . . . . . . . . . .  30
   13. The Mapping System  . . . . . . . . . . . . . . . . . . . . .  31
     13.1.  The Mapping System Interface . . . . . . . . . . . . . .  32
       13.1.1.  Map-Request Messages . . . . . . . . . . . . . . . .  32
       13.1.2.  Map-Reply Messages . . . . . . . . . . . . . . . . .  32
       13.1.3.  Map-Register and Map-Notify Messages . . . . . . . .  33
     13.2.  The DDT Indexing Sub-system  . . . . . . . . . . . . . .  34
     13.3.  Reliability via Replication  . . . . . . . . . . . . . .  35
     13.4.  Security of the DDT Indexing Sub-system  . . . . . . . .  35
     13.5.  Extended Capabilities  . . . . . . . . . . . . . . . . .  36
     13.6.  Performance of the Mapping System  . . . . . . . . . . .  36
   14. Multicast Support in LISP . . . . . . . . . . . . . . . . . .  37
     14.1.  Basic Concepts of Multicast Support in LISP  . . . . . .  37
     14.2.  Initial Multicast Support in LISP  . . . . . . . . . . .  38
   15. Deployment Issues and Mechanisms  . . . . . . . . . . . . . .  39
     15.1.  LISP Deployment Needs  . . . . . . . . . . . . . . . . .  39
     15.2.  Interworking Mechanisms  . . . . . . . . . . . . . . . .  40
       15.2.1.  Proxy LISP Routers . . . . . . . . . . . . . . . . .  40
       15.2.2.  LISP-NAT . . . . . . . . . . . . . . . . . . . . . .  42
     15.3.  Use Through NAT Devices  . . . . . . . . . . . . . . . .  42
     15.4.  LISP and Core Internet Routing . . . . . . . . . . . . .  43
   16. Fault Discovery/Handling  . . . . . . . . . . . . . . . . . .  43
     16.1.  Handling Missing Mappings  . . . . . . . . . . . . . . .  44
     16.2.  Outdated Mappings  . . . . . . . . . . . . . . . . . . .  44
       16.2.1.  Outdated Mappings - Updated Mapping  . . . . . . . .  44
       16.2.2.  Outdated Mappings - Wrong ETR  . . . . . . . . . . .  44
       16.2.3.  Outdated Mappings - No Longer an ETR . . . . . . . .  45
     16.3.  Erroneous Mappings . . . . . . . . . . . . . . . . . . .  45
     16.4.  Verifying ETR Liveness . . . . . . . . . . . . . . . . .  45
     16.5.  Verifying ETR Reachability . . . . . . . . . . . . . . .  46
   17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  46
   18. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  47
   19. Security Considerations . . . . . . . . . . . . . . . . . . .  47
   20. References  . . . . . . . . . . . . . . . . . . . . . . . . .  47
     20.1.  Normative References . . . . . . . . . . . . . . . . . .  47
     20.2.  Informative References . . . . . . . . . . . . . . . . .  49
   Appendix A.  Glossary/Definition of Terms . . . . . . . . . . . .  52
   Appendix B.  Other Appendices . . . . . . . . . . . . . . . . . .  55
     B.1.   A Brief History of Location/Identity Separation  . . . .  55
     B.2.  A Brief History of the LISP Project . . . . . . . . . . .  56
     B.3.  Old LISP 'Models' . . . . . . . . . . . . . . . . . . . .  56
     B.4.  The ALT Mapping Indexing Sub-system . . . . . . . . . . .  57
     B.5.  Early NAT Support . . . . . . . . . . . . . . . . . . . .  58
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  59

1.  Prefatory Note

   {{Suggestion by editors: Remove all the sections before "LISP
   Overview" and write a straight-to-the-point introduction}}

   {{Suggestion by editors: The draft should focus on describing the
   LISP architecture and avoid comparing loc/id split architectures with
   other approaches}}

   This document is the first of a pair which, together, form what one
   would think of as the 'architecture document' for LISP (the
   'Location-Identity Separation Protocol').  Much of what would
   normally be in an architecture document (e.g. the architectural
   design principles used in LISP, and the design considerations behind
   various components and aspects of the LISP system) is in the second
   document, the 'Architectural Perspective on LISP' document.
   [I-D.ietf-lisp-perspective]

   This 'Architectural Introduction' document is primarily intended for
   those who are unfamiliar with LISP, and want to start learning about
   it.  It is intended primarily for those working on LISP, but those
   working with LISP, and more generally anyone who wants to know more
   about LISP, may also find this document useful.

   This document is intended to both be easy to follow and it is
   structured as a series of phases, each covering the entire system,
   but with ever-increasing detail.  Reading only the first part of the
   document will give a good high-level view of the system; reading the
   complete document should provide a fairly detailed understanding of
   the entire system.

   People who just want to get an idea of how LISP works might only read
   the first part; they can stop reading either just before, or just
   after Section 9.  People who are going to go on and read the protocol
   specifications (perhaps to implement LISP) should read the entire
   document.

   This document is a descriptive document, not a protocol
   specification.  Should it differ in any detail from any of the LISP
   protocol specification documents, they take precedence for the actual
   operation of the protocol.

2.  Part I
3.  Initial Glossary

   This initial glossary defines a few general terms which will be
   useful to have in hand when commencing reading this document.  A
   complete glossary is available in Appendix A.

   A note about style: initial usage of a term defined in the glossary
   is denoted with double quotation marks (").  Other uses of quotations
   (e.g. for quotations, euphemisms, etc) use single quotation marks
   (').

   o  Name: a name refers to an identifier for an object or entity.
      Names have both semantics (meaning) and syntax (form) [RFC1498].

   o  Namespace: A group of names with matching semantics and syntax;
      they usually, but not always, refer to members of a class of
      identical objects.

   o  Mapping: a binding between two names, one in each of two
      namespaces.

   o  Delegation Hierarchy: an abstract rooted tree (in the graph theory
      sense of the term) which is a virtual representation of the
      delegation of a namespace into smaller and smaller blocks, in a
      recursive process.

   o  Node: The general term used to describe any sort of communicating
      entity; it might be a physical or a virtual host, or a mobile
      device of some sort.  It includes both entities which forward
      packets, and entities which create or consume packets.

   o  Switch, Packet Switch: A packet switch, in the general meaning of
      that term.  A device which takes in packets from its interfaces
      and forwards them on, either to a next-hop switch, or to the final
      destination.  They may operate at either the network layer (e.g.
      ARPANET), or internetwork layer.  [Baran][Heart][RFC1812]

   o  Endpoint, end-end communication entity: The fate-sharing region at
      one end of an end-end communication; the collection of state
      related to both the reliable end-end communication channel, and
      the applications running there.  [Chiappa]

   o  Address: In this document, in current IP (IPv4 or IPv6) and
      similar networking suites, a "name" which has mixed semantics, in
      that it includes both identity ('who') and location ('where')
      semantics.  [Atkinson]

   o  Address Block, Block: A contiguous section of a namespace (e.g.,
      IP addresses that belong to the same prefix).

   o  Identifier: a name which has identity semantics.

   o  Locator: name with only location semantics and not necessarily
      carried in every packet [RFC1992].

   o  Site: A collection of hosts, routers, and networks under a single
      administrative control.

   o  LISP site: a site separated from the rest of the network by LISP
      routers.

   o  LISP node: A network element implementing LISP functionality; this
      means it can process some subset of LISP control and planes
      traffic.

   o  LISP router: A network element implementing LISP data-plane
      functionality, i.e., a LISP node which can forward user traffic.

   o  LISP host: A host which is behind (from the point of view of the
      rest of the network) a LISP router.

4.  Background

   It has gradually been realized in the networking community that
   networks, especially large networks, should deal quite separately
   with the identity and location of an endpoint - basically, who an
   endpoint is, and where it is ([RFC1498] [RFC4984]).

   At the moment of this writing, in both IPv4 and IPv6, IP addresses
   indicate both where the named node is, as well as identify it for
   purposes of end-end communication; i.e. it has both location and
   identity properties.  However, the separation of those two properties
   is a step which has been identified by the IRTF as a necessary
   evolutionary architectural step for the Internet [RFC6115] and the
   on-going LISP project is an attempt to provide a viable path towards
   this separation.

   As an add-on to a large existing system, it has had to make certain
   compromises.  (For a good example, see [I-D.ietf-lisp-perspective],
   Section "Residual Location Functionality in EIDs".  However, if it
   reaches near-ubiquitous deployment, it will have two important
   consequences.

   First, in effectively providing separation of location and identity,
   along with providing a distributed directory of the mappings between
   them, 'Wheeler's Law' ('All problems in computer science can be
   solved by another level of indirection') will come into play, and the
   Internet technical community will have a new, immensely powerful,
   tool at its disposal.  The fact that the namespaces on both sides of
   the mapping are global ones maximizes the power of that tool.  (See
   [I-D.ietf-lisp-perspective], Section "Need for a Mapping System", for
   more on this.)

   Second, because of a combination of the flexible capability built
   into LISP, and the breaking of the unification of location and
   identity names, further architectural evolution of the Internet
   becomes easily available; for example, new namespaces for location or
   identity could be designed and deployed.  In other words, LISP is not
   a point solution to meet a particular need, but hopefully an 'escape
   hatch' which will allow further significant enhancement to the
   Internet's overall architecture.  (See [Future] for more on this.)

5.  Deployment Philosophy

   {{Suggestion by editors: Remove the entire section, it can be
   summarized by the last paragraph.  Furthermore the arguments used in
   this sections are hard to follow since LISP has not been described
   yet.}}

   The deployment philosophy was a major driver for the design of LISP
   (architecture and engineering).

   Experience over the last several decades has shown that having a
   viable deployment model for a new design is a key to the adoption of
   the solution.  In general, it is comparatively easy to conceive of
   new network designs, but much harder to devise approaches which will
   actually get deployed throughout the global network.  A new design
   may be fantastic but if it can not be successfully deployed (for
   whatever factors), it is useless.

   LISP aims to achieve the near-ubiquitous deployment necessary for
   maximum exploitation of an architectural upgrade by i) minimizing the
   amount of change needed (most existing hosts and routers can operate
   unmodified); and ii) by providing significant benefits to early
   adopters.

5.1.  Economics

   {{Suggestion by editors: Remove this section, this has not been
   discussed by the WG}}

   A key factor in successful adoption is economics: does the new design
   have benefits which outweigh its costs?
   More importantly, this balance needs to hold for early adopters -
   because if they do not receive benefits to their adoption, the sphere
   of earliest adopters will not expand, and it will never get to
   widespread deployment.

   This is particularly true of architectural enhancements, which are
   far less likely to be an addition which one can bolt onto the side of
   existing mechanisms, and often offer their greatest benefits only
   when widely (or ubiquitously) deployed.

   Maximizing the cost-benefit ratio obviously has two aspects.  First,
   on the cost side, by making the design as inexpensive as possible,
   which means in part making the deployment as easy as possible.
   Second, on the benefit side, by providing many new capabilities,
   which is best done not by loading the design up with lots of features
   or options (which adds complexity), but by making the addition
   powerful through deeper flexibility.  The LISP community believes
   LISP has met both of these goals.

5.2.  Maximize Re-use of Existing Mechanism

   {{Suggestion by editors: Remove/Summarize the entire section, the
   arguments used in this section are hard to follow since LISP has not
   been described yet.}}

   One key part of reducing the cost of a new design is to minimize the
   amount of change required to existing, deployed, devices: the fewer
   devices need to be changed, and the smaller the change to those that
   do, the greater the likelihood of deployment.

   Designs which absolutely require forklift upgrades to large amounts
   of existing gear are far less likely to succeed - because they have
   to have extremely large benefits to make their very substantial costs
   worthwhile.

   It is for this reason that LISP, in most cases, initially requires no
   changes to almost all existing devices in the Internet (both hosts
   and routers); LISP functionality needs to be added in only a few
   places ( Section 15.1)

6.  LISP Overview

   LISP is an incrementally deployable architectural upgrade to the
   existing Internet infrastructure, one which provides separation of
   location and identity.  It thus starts to separate the names used for
   identity and location of nodes, which are currently unified in IP
   addresses.

6.1.  Basic Approach

   {{Suggestion by editors: Merge this section with the previous one
   (LISP Overview)}}

   In LISP, the first key concept is that nodes have both an identifier
   called an Endpoint IDentifier (EID) and an associated Routing Locator
   (RLOC).  A node may be associated with more than one RLOC, or the
   RLOC may change over time (e.g., if the node is mobile), but it would
   normally always have the same EID.

   The second key concept is that if one wants to be as forward-looking
   as possible, conceptually one should think of the two kinds of names
   (EIDs and RLOCs) as naming different classes of entities.

   On the one hand, EIDs are used to name nodes - or rather, their end-
   end communication entities.  RLOC(s), on the other hand, name
   interfaces, i.e. places to which the system of routers sends packets.

   This distinction, the formal recognition of different kinds of
   entities ("endpoints" and interfaces), and their association with the
   two different classes of names, is also important.  Clearly
   recognizing interfaces and endpoints as distinctly separate classes
   of objects is another improvement to the existing Internet
   architecture.

   An important insight in LISP is that it initially uses existing IP
   addresses for both of these kinds of names, as opposed to some
   similar earlier deployment proposals for separation of location and
   identity (e.g.  [RFC1992]), which proposed using a new namespace for
   locators.  This choice minimizes LISP's deployment cost, as well as
   providing the ability to easily interact with un-modified hosts and
   routers.

   The capability to use namespaces other than IP addresses for both
   kinds of names is already built in LISP, which is expected to greatly
   increase the long-term benefits, flexibility, and power of LISP
   ([AFI], [I-D.ietf-lisp-lcaf]).

6.2.  Basic Functionality

   {{Suggestion by editors: Rewrite this section: It is using non-
   standard terminology to refer to standard LISP concepts ('enhance'
   instead of encapsulate) It is using subjective terms (e.g., 'near'
   the source) It is missing key LISP aspects such as that RLOC packets
   are forwarded in the RLOC space }}
   The basic operation of LISP, as it currently stands, is quite simple.
   LISP augmented packet switches, "LISP routers", near the source and
   destination of packets intercept traffic, and 'enhance' the packets
   for the trip between the LISP switches.

   The LISP router near the original source (the Ingress Tunnel Router,
   or ITR ) looks up additional information about the destination of the
   packet, and then wraps the packet in an outer header, one which
   contains additional information related to LISP operation.

   The LISP router near the destination, the (the Egress Tunnel Router,
   or ETR) removes that header, leaving the original, un-modified,
   packet to be sent on to the original destination node.

   The overall processing is shown below, in Figure 1:

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

                  Figure.- An schema of the LISP Architecture

                     Figure 1: Basic LISP Packet Flow

   To retrieve that additional information, the ITR uses the information
   in the original packet about the identity of its ultimate
   destination, i.e. the destination EID address.  It uses the
   destination EID to look up the current location (the RLOC) of that
   EID.

   The lookup is performed through a mapping system, which is the heart
   of LISP: it is a distributed directory of mappings from EIDs to
   RLOCs.  The destination RLOC(s) is (are) normally the address(es) of
   the ETR(s) near the ultimate destination.

   The ITR then generates a new outer header for the original packet,
   with that header containing the ETR's RLOC as the wrapped packet's
   destination, and the ITR's own address (i.e. the RLOC usually
   associated with the original source) as the wrapped packet's source,
   and sends it off.

   When the packet arrives at the ETR, that outer header is stripped
   off, and the original packet is forwarded to the original ultimate
   destination for normal processing.

   Return traffic is handled similarly, often (depending on the
   network's configuration) with the original ITR and ETR switching
   roles.  The ETR and ITR functionality is usually co-located in a
   single LISP router; these are normally denominated as xTRs.

6.3.  Mapping from EIDs to RLOCs

   The mappings from EIDs to RLOCs are provided by a distributed, and
   potentially replicated, database, the "mapping database", which is
   the heart of LISP.  Here, and in other places in LISP, the
   replication is not a deep architectural concept, simply an
   engineering device to obtain reliability via potential redundancy.

   Entities which need EID-to-RLOC mappings get them from the mapping
   system, which is a collection of sub-systems through which clients
   can find and obtain mappings as discussed in more details in
   Section 8.2 and Section 13.

   Mappings are normally distributed via a pull mechanism (i.e., not
   pre-loaded, but requested on demand).  Once obtained by an ITR, they
   are cached for performance reasons.

6.4.  Interworking With Non-LISP-Capable Endpoints

   It is clearly crucial to provide the capability for easy
   interoperation between "LISP hosts" - i.e. they are behind xTRs, and
   their EIDs are in the mapping database - and existing non-LISP-using
   hosts (often called 'legacy' hosts) or legacy "sites".

   To allow interoperation between devices hosted in a LISP site and
   devices not belonging to a LISP site (non-LISP site), an interworking
   mechanism based on proxies has been designed.  Proxy ITRs (PITR)
   encapsulate packets sent from non-LISP sites to LISP sites while
   Proxy ETRs (PETR) decapsulate packets sent from LISP sites to non-
   LISP sites.  More details are given in Section 15.2.1.

6.5.  Security in LISP

   {{Suggestion by editors: Rewrite this section: (first 3 paragraphs)
   It contains a general discussion as well as strong statements that
   are not supported by any WG document.  (last 3 paragraphs) It
   enumerates the security mechanisms specified in LISP but does not
   describe them.}}

   To provide a brief overview of security in LISP, it is definitely
   understood that LISP needs to be highly _securable_, especially in
   the long term; over time, the attacks mounted by 'bad guys' are
   becoming more and more sophisticated.  So LISP, like DNS, needs to be
   _capable_ of providing 'the very best' security there is.

   At the same time, there is a conflicting goal: it must be deployable
   at a a viable cost.  That means two things: First, as an experiment,
   we cannot expect to create the complete security apparatus which we
   might see in the finished product, including both design and
   implementation.  Second, security needs to be flexible, so that we
   don't overload the users with more security than they need at any
   point.

   To accomplish these divergent goals, the approach taken is to first
   analyze what LISP needs for security.  [I-D.ietf-lisp-threats].
   Then, steps can be taken to ensure that the appropriate 'hooks' (such
   as packet fields) are included at an early stage, when doing so is
   still easy.  Over time, additional mechanisms will be fully
   specified, implemented, and deployed.

   LISP does already include a number of security mechanisms; in
   particular, requesting mappings can be secured (see Section 12.8,
   "Security of Mapping Lookups"), as can registering of xTRs (see
   Section 13.1.3, "Map-Register and Map-Notify Messages"); the key
   database of the mapping system is also secured (see Section 13.4,
   "Security of the DDT Indexing Sub-system").

   The existing security mechanisms, and their configuration (which is
   mostly manual at this point) currently in LISP are felt to be
   adequate for the needs of the on-going early stages of deployment;
   experience will indicate when improvements are required (within the
   constraints of the conflicting goal given above).

   For more on LISP's security philosophy; see
   [I-D.ietf-lisp-perspective], Section 7 "Security", where it is laid
   out in some detail.

7.  Initial Applications

   {{Suggested by editors: Move this section after section 8, the
   applications should not be described before LISP has been fully
   described.

   {{Suggested by Noel: Reorder the whole section in popularity order?}}

   As previously mentioned, it is felt that LISP will provide even the
   earliest adopters with some useful capabilities, and that these
   capabilities will drive early LISP deployment.

   It is very imporant to note that even when used only for
   interoperation with existing un-modified hosts, use of LISP can still
   provide benefits to the site which has deployed it - and, perhaps
   even more importantly, can do so to both sides.  This characteristic
   acts to further enhance the utility for early adopters of LISP.

   Note also that this section only lists some early applications and
   benefits.  See [I-D.ietf-lisp-perspective], in the Section "Goals of
   LISP", for a more extensive discussion of some of what LISP might
   ultimately provide.

7.1.  Provider Independence

   Provider independence (i.e. the ability to easily change one's
   Internet Service Provider) is a good example of the utility of
   separating location and identity.

   To limit global routing table size addresses need to be aggregated.
   To that aim networks can use provider aggregatable addresses
   ([RFC4116]) which means that the IP prefixes of networks are sub-
   prefixes of their provider.  This solutions allows to reduce
   scalability issues of the global routing table but it means that when
   a network switches providers it has to re-number all its devices
   which is known to be complex in current networks [RFC5887].

   Having separate namespaces for location and identity greatly reduces
   the problems involved with re-numbering; an organization which moves
   retains its EIDs (which are how most other parties refer to its
   nodes), but is allocated new RLOCs, and the mapping system can
   quickly provide the updated mapping from the EIDs to the new RLOCs.

7.2.  Multi-Homing

   {{Suggested by editors: This section should be extended, it is
   unclear the benefits that LISP brings to multihoming (.e.g, traffic
   engineering, decoupled multihoming from the data-plane).

   Multi-homing is another place where the value of separation of
   location and identity became apparent.  There are several different
   sub-flavours of the multi-homing problem - e.g. depending on whether
   one wants open TCP connections to keep working, etc - and other axes
   as well (e.g. site multi-homing versus host multi-homing).

   In particular, for the 'keep open connections up' case, without
   separation of location and identity, with most currently deployed
   implementations, the only currently feasible approach is to use
   provider-independent addressses - which moves the problem into the
   global routing system, with attendant costs.  This approach is also
   not really feasible for host multi-homing.

7.3.  Traffic Engineering

   {{Suggestion by editors: Merge this section with the previous one, TE
   is not practical without multihoming}}

   {{Needs a fix - not sure what.}}

   Traffic engineering (TE) [RFC3272], desirable though this capability
   is in a global network, is currently somewhat problematic to provide
   in the Internet.  The problem, fundamentally, is that this capability
   was not forseen when the Internet was designed, so the support for it
   via hacks is neither clean, nor flexible.

   TE is, fundamentally, a routing issue.  However, the current Internet
   routing architecture, which is basically the Baran design of fifty
   years ago [Baran] (a single large, distributed computation), is ill-
   suited to provide TE.  The Internet seems a long way from adopting a
   more-advanced routing architecture, although the basic concepts for
   such have been known for some time.  [RFC1992]

   Although the identity-location mapping layer is thus a poor place,
   architecturally, to provide TE capabilities, it is still an
   improvement over the current routing tools available for this purpose
   (e.g. injection of more-specific routes into the global routing
   table).

   In addition, instead of the entire network incurring the costs
   (through the routing system overhead), when using a mapping layer to
   provide TE, the overhead is limited to those who are actually
   communicating with that particular destination.

   LISP includes a number of features in the mapping system to support
   TE. (described in Section 8.2, "Control Plane - Mapping System
   Overview", below); more details about using LISP for TE can be found
   in [I-D.farinacci-lisp-te].

   Also, a number of academic papers have explored how LISP can be used
   to do TE, and how effective it can be.  See the online LISP
   Bibliography ([Bibliography]) for information about them.

7.4.  Routing

   {{Suggestion by editors: Remove this section, LISP is not a routing
   protocol.}}

   Multi-homing and Traffic Engineering are both, in some sense, uses of
   LISP for routing, but there are many other routing-related uses for
   LISP.

   One of the major original motivations for the separation of location
   and identity in general, and thus LISP, was to reduce the growth of
   the routing tables in the "Internet core", the part where routes to
   _all_ ultimate destinations must be available.  LISP is expected to
   help with this; for more detail, see Section 15.4, "LISP and Core
   Internet Routing", below.

   LISP may also have more local applications in which it can help with
   routing; see, for instance, [CorasBGP].

7.5.  Mobility

   {{Suggestion by editors: Remove this section, mobility is not in
   charter.}}

   Mobility is yet another place where separation of location and
   identity is a key part of a clean, efficient and high-functionality
   solution.  Considerable experimentation has been completed on doing
   mobility with LISP.

   The mobility provided by LISP allows active sessions to survive moves
   (provided of course that there is not a period of inaccessibility
   which exceeds a timeout).  LISP mobility also will typically have
   better packet stretch (i.e. increase in path length) compared to
   traditional mobility schemes, which use a home agent.

7.6.  Traversal Across Alternate IP Versions

   Note that LISP inherently supports intermixing of various IP versions
   for packet carriage; IPv4 packets might well be carried in IPv6, or
   vice versa, depending on the network's configuration.

   This capability allows an island of operation of one type to be
   automatically tunneled over a stretch of infrastucture which only
   supports the other type.

7.7.  Virtual Private Networks

   {{Suggestion by editors: Remove this section, not covered by any WG
   document}}

   L2 and L3 {{Need to add text here - This used to be part of 'Local'
   below, but we decided this was so important it deserved its own
   section.  Maybe move this up further, as it seems to be the most
   important 'early adopter' application?}}

   The mapping-and-encapsulation nature of LISP makes it a perfect
   candidate for VPN solutions.  In this case, private parts of the VPN
   form LISP sites and the IP addresses of devices in the private parts
   are composing EID spaces.  The interconnection between the LISP sites
   is the public network and IP addresses in the interconnection compose
   the RLOC space.  A major advantage of using LISP to construct VPN
   resides in the simplicity of the configurations: each xTR (i.e., VPN
   end) is configured to query the mapping system to retrieve mappings
   making the glue between the public (RLOC space) and the private (EID
   space) of the VPN.

   This includes support of multi-tenancy where several private networks
   can be carried over the same underlayer network.  Thanks to the
   instance-id field, multi-tenant network can even use the exact same
   addresses as the xTR distinguishes the tenant based on the value of
   the instance-id.  The multiple address family support in LISP
   mappings also allows to build private networks using a different
   addressing family than the carrier (e.g., IPv6 over IPv4).

7.8.  Local Uses

   {{Suggestion by editors: Remove this section.  The section contains a
   general discussion about the applicability of LISP in intra-domain
   scenarios, however it does not describe any specific application.}}

   LISP has a number of use cases which are within purely
   organizationally-local contexts, i.e. not in the larger Internet.
   These fall into two categories: uses seen on the Internet (above),
   but here on a private (and usually small scale) setting; and
   applications which do not have a direct analog in the larger
   Internet, and which apply only to local deployments.

   Among the former are multi-homing and IP version traversal. {{This
   was marked to be deleted - why?  The next part doesn't make sense
   without this first?}}

   Among the latter class, non-Internet applications which have no
   analog on the Internet, are the following example applications:

   virtual machine mobility in data centers; non-IP EID types such as L2
   MAC addresses, or application specific data.

   Several of the applications listed in this section are the ones which
   have been most popular for LISP in practise; these include virtual
   networks, and virtual machine mobility.

   These often show a synergistic tendency, in that a site which
   installs LISP to do one, often finds that then becomes a small matter
   to use it for the second.  Given all the things which LISP can do, it
   is hoped that this synergistic effect will continue to expand LISP's
   uses.

   {{Preceeding paragraphs should probably get moved up into VPN
   section?}}

8.  Major Functional Subsystems

   {{Suggestion by editors: This section should appear before since it
   describes key aspects of LISP (e.g., LISP decoupled control and data-
   plane).}}

   LISP has two major functional sub-systems: the xTRs which form the
   data-plane of LISP; and the mapping system which forms the control
   plane that maintains and distributes the mapping database.

   The purpose and operation of each is described at a high level below,
   and then, later on, in a fair amount of detail, in separate sections
   on each (Section 12 and Section 13).

8.1.  Data Plane - xTRs Overview

   {{Suggestion by editors: Extend this section, it misses key LISP
   data-plane aspects, such as the map-cache.}}

   xTRs are routers that have been augmented with extra functionality in
   both the data and control planes.  The data plane functions in ITRs
   include deciding which packets need to be given LISP processing
   (since packets to non-LISP hosts may be sent as they are); i.e.
   looking up the mapping; encapsulating (wrapping) the packet; and
   sending it to the ETR.

   This encapsulation is done using UDP [RFC0768], along with an
   additional outer IP header (to hold the source and destination
   RLOCs).  To the extent that traffic engineering features are in use
   for a particular EID, the ITRs implement them as well.

   In the ETR, the data plane simply decapsulates (unwraps) the packets,
   and forwards the it to the destination.

   Control plane functions in ITRs include: asking for EID-to-RLOC
   mappings via Map-Request packets; handling the returning reply
   control messages (i.e., Map-Reply packets), which contain the EID-to-
   RLOC mapping; managing the local mapping cache and checking for the
   reachability of destination ETR's RLOCs.

   In the ETR, control plane functions include participating in the
   reachability tests (see Section 16.4); interacting with the mapping
   sub-system to let it know what mapping this ETR can provide (see
   Section 8.2.2); and answering Map-Request packets from ITRs for those
   mappings.

8.1.1.  Mapping Cache Performance

   {{Suggestion by editors: Push this section further in the document,
   the cache performance is not a "Major LISP subsystem"}}

   As mentioned, studies have been performed to verify that caching
   mappings in ITRs is viable, in practical engineering terms.  These
   studies not only verified that such caching is feasible, but also
   provided some insight for designing ITR "mapping caches".

   Briefly, they took lengthy traces of all packets leaving a large
   site, over a period of a week or so, and used those to drive
   simulations which showed how many mappings would be required.  It
   also allowed analysis of how much control traffic (for loading needed
   mappings) would result, using various cache sizes and replacement
   algorithms.  These studies provide an insight into how well LISP can
   be expected to perform, and scale, over time.

   A more extended look at the results us given below, in Section 12.9,
   "xTR Mapping Cache Performance".

8.2.  Control Plane - Mapping System Overview

   {{Suggestion by editors: Rewrite: Replace EID block terminology
   (along with its description) with the very common term "prefix".
   Describe Map-Request/Map-Reply LISP signaling messages.}}

   The mapping system's entire purpose is to give ITRs on-demand access
   to the mapping database, which is a distributed, and potentially
   replicated, database which holds mappings between EIDs (identity) and
   RLOCs (location), along with needed ancillary data (e.g. lifetimes).

   To be exact, it contains mappings between EID blocks and RLOCs (the
   block size is given explicitly, as part of the syntax).  Support for
   blocks is both for minimizing the administrative configuration
   overhead, as well as for operational efficiency; e.g. when a group of
   EIDs are behind a single xTR.  In IP blocks are delimited by their IP
   prefix.

   However, the block may be, and sometimes is, as small as a single
   EID.  However, since mappings are only loaded upon demand, if smaller
   blocks become predominant, then the increased size of the overall
   database is far less problematic than if the Internet's routing
   tables came to be dominated by such small entries.

   A particular EID (or EID block) may be associated to than one RLOC,
   and may change the association with time.

   Also, in general, throughout LISP, the address family of EIDs and
   RLOCs is explicitly mentioned in control packet.

   Finally, the mapping from an EID (or EID block) contains not just the
   RLOC(s), but also (for each RLOC for any given EID entry) priority
   and weight fields (to allow allocation of load between several RLOCs
   at a given priority); this allows a certain amount of traffic
   engineering to be accomplished with LISP.

8.2.1.  Mapping System Organization

   {{Suggestion by editors: Rewrite: Describe key Mapping System
   components: Map-Server/Map-Resolver}}

   The mapping system is split into three functional sub-systems.

   The first is the actual mappings themselves, collectively the mapping
   database; they are held by the ETRs, and an ITR which needs a mapping
   gets it (effectively) directly from the ETR.  This co-location of the
   authoritative version of the mappings, and the forwarding
   functionality which it describes, is an instance of fate-sharing.
   [Clark]

   To find the appropriate ETR(s) to query for the mapping, the second
   two sub-systems form an indexing system, itself also based on a
   distributed, potentially replicated database.  It provides
   information on which ETR(s) are authoritative sources for the various
   EID-to-RLOC mappings which are available.  The two sub-systems which
   form it are the client interface sub-system, and indexing sub-system
   (which holds and provides the actual information).

8.2.2.  Interface to the Mapping System

   {{Suggestion by editors: has been rewritten: This section should
   appear earlier since it describes key LISP components (Map-Request/
   Map-Reply/Map-Server/Map-Resolver}}

   The client interface to the indexing system from an ITR's point of
   view is not with the indexing sub-system directly; rather, it is
   through the Map-Resolvers (MRs) and Map-Servers (MSs).

   To obtain the mapping for an EID, the ITRs sends Map-Request packet
   to an MR.  The MR then uses the indexing sub-system to allow it to
   forward the Map-Request to an appropriate Map-Server (MS), which in
   turn sends the Map-Request on to the appropriate ETR.  The latter is
   authoritative for the actual mappings for the EID.

   The ETR then sends the mappings for that EID in the form of aMap-
   Reply packets, which is sent directly to the ITR, without passing
   through the indexing sub-system and MR.  The details of the indexing
   sub-system are thus hidden from the ITRs.

   Note that in proxy mode, the MS replies on behalf of the ETR.  When
   this the case, the map-replies is tagged to indicate that the answer
   is not delivered from the authoritative ETR but from the MS instead.

   The interface to the indexing system from an ETR's point of view is
   made through MSes.  ETRs send Map-Register packets to their
   designated MSes.  The effect of a Map-Register is to inform the MS
   about the mappings maintained by ETRs such that the MS can transmit
   the Map-Requests is receives to the appropriate ETRs.

   The MS optionally replies Map-Register packets with a Map-Notify
   packet to confirm the registration.  The details of the indexing sub-
   system are thus likewise hidden from ETRs.

   The fact that the details of the indexing sub-system are entirely
   hidden from xTRs gives considerably flexibility to this aspect of
   LISP.  As long as any potential indexing sub-system can track where
   mappings are, it could potentially be used; this would allow the
   actual indexing sub-system to be replaced without needing to modify
   the xTRs.

8.2.3.  Indexing Sub-system

   {{suggestion by editor: rename the section to "DDT"}}

   The current indexing sub-system is the Delegated Database Tree (DDT),
   which is conceptually similar to DNS ([I-D.ietf-lisp-ddt],

   [RFC1034]).  DDT replaces the earlier LISP+ALT indexing sub-system
   ([RFC6836]).  The seamless migration to DDT while LISP+ALT was
   previously used validated the concept of having a client-interface
   sub-system between the indexing sub-system, and the clients.

8.2.3.1.  DDT Overview

   Conceptually, DDT is similar to the DNS, in DDT the delegation of the
   EID namespace is instantiated as a delegation hierarchy, a tree of
   DDT nodes, starting with the root DDT node.  Each vertex is
   responsible for a block of the EID namespace.

   The root node is responsible for the entire EID space; any DDT node
   can delegate part(s) of its EID block to child DDT node(s).  The
   child node(s) can in turn further delegate (necessarily smaller)
   blocks of namespace to their children, through as many levels as are
   needed (for operational, administrative, etc, needs).

   Just as with DNS, any particular vertex in the DDT delegation tree
   may be instantiated in one or more DDT servers.  Multiple (redundant)
   servers for a given node would be used for reasons of performance,
   reliability, and robustness.  Obviously, all the servers which
   instantiate a particular nodes in the tree have to have identical
   data about that node.

8.2.3.2.  Use of DDT by MRs

   An MR which wants to find a mapping for a particular EID first
   interacts with the DDT servers which instantiate the nodes of the
   LISP delegation hierarchy tree, discovering (by querying the servers
   for information about DDT nodes) the chain of delegations which cover
   that EID.  Eventually it is directed to an MS, which is servicing an
   ETR which is authoritative for that EID.

   Also, again like DNS, MRs may cache information they receive about
   the delegations in the delegation tree.  This means that once an MR
   has been in operation for a while, it will usually have much of the
   delegation information cached locally (especially the top levels of
   the delegation tree).  This allows them, when passed a request for a
   mapping by an ITR, to usually forward the mapping request to the
   appropriate MS without having to interact with all the DDT servers on
   the path down the delegation tree, in order to find any particular
   mapping.

   Thus, a typical resolution cycle would usually involve looking at
   some locally cached delegation information, perhaps loading some
   missing delegation entries into their delegation cache, and finally
   sending the Map-Request to the appropriate MS.

   It should also be noted that the delegation tree is fairly static,
   since it reflects EID block allocations, which are themselves fairly
   static.  This stability has several important consequences.  First,
   it increases the performance of the mapping system, since the sub-
   system almost never needs to be re-queried for information about
   intermediate vertices.  {{comment from editor: does not understand
   the next sentence...}}Second, it is not necessary to include a
   mechanism to find out-dated delegations.  [LISP-TREE]

   This contrasts with the mappings, which may change at a high rate -
   changes which have no impact on the indexing sub-system.  The
   potentially high dynamics of mappings explains why mappings are
   delivered directly from ETRs (or MSes in proxy mode) to ITRs and
   hence not cached at the MR level.  LISP is designed to make sure that
   changes in the mappings are detected and acted upon fairly quickly;
   this allows LISP to provide a number of capabilities, such as
   mobility.

9.  Examples of operation

   To aid in comprehension, a few examples are given of user packets
   traversing the LISP system.  The first shows the processing of a
   typical user packet which is LISP forwarded, i.e. what the vast
   majority of user packets will see.  The second shows what happens
   when the first packet to a previously-unseen ultimate destination (at
   a particular ITR) is to be processed by LISP.

9.1.  An Ordinary Packet's Processing

   {{Suggestion by editors: This section should be earlier in the
   document structure, examples are important -particularly for
   engineers- to explain how systems work}}

   This case follows the processing of a typical , {{comment from
   editors: text missing}} when the packet has made its way through the
   local site to an ITR, which in this case is a border router for the
   site, the border router looks up the destination address - an EID -
   in its local mapping cache.  For EIDs which are IP addresses, this
   lookup uses the IP longest prefix matching algorithm.

   It finds a mapping, which instructs it to wrap the packet in an outer
   header - an IP packet, containing a UDP packet which contains a LISP
   header - and then the user's original packet (see Section 12.2 for
   the reasons for this particular choice).  The destination address in
   the outer header is set by the ITR to the RLOC of the destination
   ETR.

   The encapsulated packet is then sent off through the RLOC space
   (e.g., Internet), using normal Internet routing.

   On arrival at the destination ETR, the ETR will notice that it is
   listed as the destination in the outer header.  It will examine the
   packet, detect that it is a LISP packet, and unwrap it.  It will then
   examine the header of the user's original packet, and forward it
   internally, through the local site, to the ultimate destination.

   At the ultimate destination, the packet will be processed, and may
   produce a return packet, which follows the exact same process in
   reverse - with the exception that the roles of the ITR and ETR are
   swapped.

9.2.  A Mapping Cache Miss

   {{Suggestion by editors: (same as previous section)}}

   If a host sends a packet, and it gets to the ITR, and the ITR
   determines that it does not yet have a mapping cache entry which
   covers that destination EID, then additional processing ensues; it
   has to look up the mapping in the mapping system (as previously
   described in Section 6.2).

   The overall processing is shown below, in Figure 2:

                  -----            -----
                 |     |    3     |     |
   Map Resolver  |     | -------> |     |  Map Server
                 |     |          |     |
                  -----            -----
                    ^                |
   Key:             |                |
                    |                |
   -- = Control     |                |
   == = Data        |                |
                 2  |       5        |  4
                    |      ---       |
   Host A           |    /     \     |            Host B
                    |  |_       \    V
    -----          -----          \ -----          -----
   |     |   1    |     |    6     |     |   7    |     |
   |     | =====> | ITR | =======> | ETR | =====> |     |
   |     |        |     |          |     |        |     |
    -----          -----            -----          -----

                Figure 2: Packet flow with missing mapping

   1.  Source-EID sends packet (to Dest-EID) to ITR

   2.  ITR sends Map-Request to Map-Resolver

   3.  Map-Resolver delivers Map-Request to Map-Server

   4.  Map-Server delivers Map-Request to ETR

   5.  ETR returns Map-Reply to ITR; ITR caches EID-to-RLOC(s) mapping

   6.  ITR uses mapping to encapsulate to ETR; sends user packet to ETR

   7.  ETR decapsulates packet, delivers to Dest-EID

   The ITR first sends a Map-Request packet, giving the destination EID
   it needs a mapping for, to its MR.  The MR will look in its cache of
   delegation information to find the vertex which is the most specific
   in the delegation tree for that destination EID .  If it does not
   have the address of an appropriate MS, it will query the DDT system,
   recursively if need be, in order to eventually find the address of
   such an MS.

   When it has the MS's address, it will send the Map-Request on to the
   MS, which then usually sends it on to an appropriate ETR.  The ETR
   sends a Map-Reply to the ITR which needs the mapping; from then on,
   processing of user packets through that ITR to that ultimate
   destination proceeds as above.

   To the best of our knowledge, in all LISP implementations, the
   original user packet will have been discarded, and not queued waiting
   for the mapping to be returned.  When the host retransmits such a
   packet, the mapping will be there, and the packet will be forwarded.
   Alternatively, it might have been forwarded using a PITR to avoid
   being dropped (Section 6.4).

10.  Part II

   {{comment from editors: is that the role of an introductory document
   to enter in such level of details and discuss (mostly) all fields of
   the protocol? }}

11.  Design Approach

   {{Suggestion by editors: Remove this section, it does not describe/
   discuss anything relevant, it is only providing a reference to
   another non-WG document.}}
   Before describing LISP's components in more detail below, it it worth
   pointing out that what may seem, in some cases, like odd (or poor)
   design approaches do in fact result from the application of a
   thought-through, and consistent, design philosophy used in creating
   them. {{Subjective: maybe JMH, Dino can help with better words?}}

   This design philosophy is covered in detail in
   [I-D.ietf-lisp-perspective], Section "Design"), and readers who are
   interested in the 'why' of various mechanisms should consult that;
   reading it may make clearer the reasons for some engineering choices
   in the mechanisms given here.

12.  xTRs

   As mentioned above (in Section 8.1), xTRs are the essential LISP data
   plane elements.  This section explores some advanced topics related
   to xTRs.

   {{Suggestion by editors: remove next paragraph, brings nothing)}}

   Careful rules have been specified for both TTL and ECN [RFC3168] to
   ensure that passage through xTRs does not interfere with the
   operation of these mechanisms.  In addition, care has been taken to
   ensure that traceroute works when xTRs are involved.

12.1.  When to Encapsulate

   An ITR knows that an ultimate destination is running LISP (remember
   that the actual destination machine itself probably knows nothing
   about LISP), and thus that it should perform LISP processing on a
   packet (including potential encapsulation) if it has an entry in its
   local mapping cache that covers the destination address (it is then
   called an EID).

   Conversely, if the cache contains a negative entry (indicating that
   the ITR has previously attempted to find a mapping that covers this
   EID, and it has been informed by the mapping system that no such
   mapping exists), it knows the ultimate destination is not running
   LISP, and the packet can be forwarded natively (i.e. not LISP-
   encapsulated).

   Note that the ITR cannot simply depend on the appearance, or non-
   appearance, of the destination in the routing tables in the Internet
   core, as a way to tell if a destination is a LISP node or not.  That
   is because mechanisms to allow interoperation of LISP sites and
   legacy sites necessarily involve advertising LISP sites' EIDs into
   the Internet core; in other words, LISP sites which need to
   interoperate with legacy nodes will appear in the Internet core
   routing tables, along with non-LISP sites.

12.2.  UDP Encapsulation Details

   Use of UDP (instead of, say, a LISP-specific protocol number) was
   driven by the fact that many routers and middle boxes filter out
   unknown protocols, so adopting a non-UDP encapsulation would have
   compromised the initial deployment of LISP.

   The UDP source port used for encapsulating packet is computed with a
   5-way hash of the original source and destination in the inner
   header, along with the ports, and the protocol.  This is because many
   ISPs use multiple parallel paths (so-called Equal Cost Multi-Path),
   and load-share across them.  Using such a hash in the source-port in
   the outer header both allows LISP traffic to be load-shared, and also
   ensures that packets from individual connections are delivered in
   order (since most ISPs try to ensure that packets for a particular
   flow follow a single path, and hence do not become disordered).

   The UDP checksum is zero because the inner packet usually already has
   a end-end checksum, and the outer checksum adds no value ([Saltzer]).
   {{Suggestion by editors: not sure that next statement is correct}} In
   most exising hardware, computing such a checksum (and checking it at
   the other end) would also present a major load, for no benefit.

12.3.  Header Control Channel

   {{Suggestion by editors: Rewrite this section to improve readability,
   use standard terminology (e.g., Cache Coherence/Reachability instead
   of "Header Control Channel").  Split the mechanisms depending on its
   goal (cache coherence/reachability) and describe them under the same
   context.}}

   LISP provides a multiplexed channel in the encapsulation header.  It
   is mostly (but not entirely) used for control purposes.  The general
   concept is that the header starts with a flags field, and it also
   includes two data fields, the contents and meaning of which vary,
   depending on which flags are set.  This allows these fields to be
   multiplexed among a number of different low-duty-cycle functions,
   while minimizing the space overhead of the LISP.

12.3.1.  Mapping Versioning

   One important use of the multiplexed control channel is mapping
   versioning; i.e. the discovery of when the mapping cached in an ITR
   is outdated.  To allow an ITR to discover this, identifying sequence
   numbers are applied to different versions of a mappping [RFC6834].

   This allows an ITR to easily discover when a cached mapping has been
   updated by a more recent variant.

   Version numbers are available in control messages (Map-Replies), but
   the initial concept is that to limit control message overhead, the
   versioning mechanism should primarily use the multiplexed user data
   header control channel.

   Versioning can operate in both directions: an ITR can advise an ETR
   what version of a mapping it is currently using (so the ETR can
   notify it if there is a more recent version), and ETRs can let ITRs
   know what the current mapping version is (so the ITRs can request an
   update, if their copy is outdated).

12.3.2.  Echo Nonces

   Another important use of the header control channel is for a
   mechanism known as the Nonce Echo, which is used as an efficient
   method for ITRs to check the reachability of neighbour ETRs.

   Basically, an ITR which has to determine that an ETR is up, and
   reachable, sends a nonce to that ETR, carried in the encapsulation
   header; when that ETR (also acting as an ITR) sends some other user
   data packet back to the ITR (acting in turn as an ETR), that nonce is
   carried in the header of that packet, allowing the original ITR to
   confirm that its packets are reaching that ETR.

   Note that a lack of a response is not necessarily proof that
   something has gone wrong - but it strongly suggests that something
   has, so other actions (e.g. a switch to an alternative ETR, if one is
   listed; a direct probe; etc) are advised.  (See Section 16.5 for more
   about Echo Nonces.)

12.3.3.  Instances

   {{Suggestion by editors: Move and extend this section: - Instance ID
   is not a cache-coherence/reachability algorithm.  Describe where and
   what is the Instance ID field Explain its applications}}

   The LISP data-plane header is also used to support VPN and multi-
   tenant networks.  Since there is only one destination UDP port used
   for carriage of user data packets, and the source port is used for
   multiplexing, there is no other way to differentiate among different
   destination EID spaces (which are often overlapped in VPNs and multi-
   tenant networks).

12.4.  Probing

   RLOC-Probing is a mechanism method that an ITR can use to determine
   with that an ETR is up and reachable from the ITR.  As a side-
   benefit, it gives RTT estimates.

   To probe the reachability of an RLOC, an ITR sends a specially marked
   Map-Request directly to the ETR it wishes information about; that ETR
   sends back a specially marked Map-Reply.  A Map-Request message and a
   Map-Reply message are used, rather than a special probing control-
   message pair, because as a side-benefit the ITR can discover if the
   mapping has been updated since it cached it.

   {{Suggestion from editors: remove the following sentence as it is not
   motivated by strong arguments}} The probing mechanism is rather
   heavy-weight and expensive (compared to mechanisms like the Echo-
   Nonce), since it costs a control message from each side, so it should
   only be used sparingly.

   If the number of active neighbour ETRs of the ITR is large, use of
   RLOC-Probing to check on their reachability will result in
   considerable control traffic; such control traffic has to be spread
   out to prevent a load peak.

   Obviously, if RLOC-Probing is the only mechanism being used to detect
   unreachable neighbour ETRs, the rate at which RLOC-Probing is done
   will control the timeliness of the detection of loss of reachability.
   There is thus a tradeoff between overhead and responsiveness,
   particular when an ITR has a large fanout of neighbour ETRs.

12.5.  Mapping Lifetimes and Timeouts

   {{Suggestion by editors: Remove this section, TTL is a simple well-
   known concept, we suggest to include a sentence (and hence remove
   this section) in the control-plane section stating that mappings
   include a TTL.

   Mappings come with a Time-To-Live, which indicate how long the
   creator of the mapping expects them to be useful for.

   Mappings might also be discarded before the TTL expires, depending on
   what strategies the ITR is using to maintain its cache; if the
   maximum cache size is fixed, or the ITR needs to reclaim memory,
   mappings which have not been used recently may be discarded.  (After
   all, there is no harm in so doing; a future reference will merely
   cause that mapping to be reloaded.)

   {{Contents may change before TTL expires?}}

12.6.  Mapping Gleaning in ETRs

   {{Suggestion by editors: Remove this section, gleaning is discouraged
   since it rises many security concerns.}}

   As an optimization to the mapping acquisition process, ETRs are
   allowed to glean mappings from incoming user data packets, and also
   from incoming Map-Request control messages.  This is not secure, and
   so any such mapping must be verified by sending a Map-Request to get
   an authoritative mapping.

   The value of gleaning is that most communications are two-way, and so
   if host A is sending packets to host B (therefore needing B's
   EID->RLOC mapping), very likely B will soon be sending packets back
   to A (and thus needing A's EID->RLOC mapping).  Without gleaning,
   this would sometimes result in a delay, and the dropping of the first
   return packet; this is felt to be very undesirable.

12.7.  MTU Issues

   Several mechanisms have been proposed for dealing with packets which
   are too large to transit the path from a particular ITR to a given
   ETR.

   In one, called the stateful approach, the ITR keeps a per-ETR record
   of the maximum size allowed, and sends an ICMP Too Big message to the
   original source host when a packet which is too large is seen.

   In the other, referred to as the stateless approach, for IPv4 packets
   without the DF bit set, too-large packets are fragmented, and then
   the fragments are forwarded; all other packets are discarded, and an
   ICMP Too Big message returned.

12.8.  Security of Mapping Lookups

   {{Suggestion from editors: would remove all what is related to
   security and instead put a small summary in the security section and
   reference the threats document}}

   LISP provides an optional mechanism to secure the obtaining of
   mappings by an ITR.  [I-D.ietf-lisp-sec] It provides protection
   against attackers generating spurious Map-Reply messages (including
   replaying old Map-Replies), and also against over-claiming attacks
   (where a malicious ETR by claims EID-prefixes which are larger than
   what have been actually delegated to it).

   In summary, the ITR provides a One-Time Key with its Map-Request;
   this key is used by both the MS (to sign an affirmation that it has
   delegated that EID block to that ETR), and indirectly by the ETR (to
   sign the mapping that it is returning to the ITR).

   The specification for LISP-SEC suggests that the ITR-MR stage be
   cryptographically protected, and indicates that the existing
   mechanisms for securing the ETR-MS stage are used to protect Map-
   Rquests also.  It does assume that the channel from the MR to the MS
   is secure.

12.9.  ITR Mapping Cache Performance

   As mentioned previously (Section 8.1.1, a substantial amount of
   simulation work has been performed to predict, and understand, the
   performance of the mapping cache in xTRs.

   Briefly, however, the first, [Iannone], was performed in the very
   early stages of the LISP effort, to verify that that caching approach
   was feasible.

   Packet traces of all traffic over the external connection of a large
   university over a week-long period were collected; simulations driven
   by these recording were then performed.  A variety of control
   settings on the cache were used, to study the effects of varying the
   settings.

   First, the simulation gave the cache sizes that would result from
   such a cache design: it showed that the resulting cache sizes ranged
   from 7,500 entries, up to about 100,000 (depending on factors such as
   traffic and entry retention time).  Using some estimations as to how
   much memory mapping entries would use, this indicated cache sizes of
   between roughly 100 Kbytes and a few Mbytes.

   Of more interest, in a way, were the results regarding two important
   measurements of the effectiveness of the cache: i) the hit ratio
   (i.e. the share of references which could be satisfied by the cache),
   and ii) the miss rate (since control traffic overhead is one of the
   chief concerns when using a cache).  These results were also
   encouraging: miss (and hence lookup) rates ranged from 30 per minute,
   up to 3,000 per minute.

   Significantly, this was substantially lower than the amount of
   observed DNS traffic, which ranged from 1,800 packets per minute up
   to 15,000 per minute.  The results overall showed that using a
   demand-loaded cache was an entirely plausible design approach: both
   cache size, and the control plane traffic load, were definitely
   feasible.

   The second, [Kim], was in general terms similar, except that it used
   data from a large ISP, one with about three times as many users as
   the previous study.  It used the same cache design philosophy (the
   cache size was not fixed), but slightly different, lower, retention
   time values.

   The results were similar: cache sizes ranges from 20,000 entries to
   roughly 60,000; the miss rate ranged from very roughly 400 per minute
   to very roughly 7,000 per minute, similar to the previous results.

   Finally, a third study, [CorasCache], examined the effect of using a
   fixed size cache, and a purely Least Recently Used (LRU) cache
   eviction algorithm (i.e. no timeouts).  It also tried to verify that
   models of the performance of such a cache (using previous theoretical
   work on caches) produced results that conformed with actual empirical
   measurements.

   It used yet another set of packet traces; using a cache size of
   around 50,000 entries produced a miss rate of around 1x10-4; again,
   definitely viable, and in line with the results of the other studies.

13.  The Mapping System

   {{Suggestion by editors: This section is somewhat redundant with
   respect to section 8.2, we suggest to move this section to Part I
   since it provides some missing details.}}

   As discussed already in Section 8.2, the LISP mapping system is an
   important part of LISP's control plane: it i) maintains the database
   of mappings between EIDs, and the RLOCs at which they are to be
   found, and ii) provides those mappings to ITRs which request them, so
   that the ITRs can send traffic for a given EID to the correct RLOC(s)
   for that EID.

   [RFC1034] has this to say about the DNS name to IP address database
   and mapping system:

      "The sheer size of the database and frequency of updates suggest
      that it must be maintained in a distributed manner, with local
      caching to improve performance.  Approaches that attempt to
      collect a consistent copy of the entire database will become more
      and more expensive and difficult, and hence should be avoided."

   and this observation applies equally to the LISP mapping database and
   mapping system.

   To briefly recap, the mapping system is split into three parts: i) an
   indexing sub-system, which keeps track of where all the mappings are
   kept; ii) the interface to the indexing system (which remains the
   same, even if the actual indexing system is changed); and iii) the
   mappings themselves (collectively, the mapping database), the
   authoritative copies of which are always held by ETRs.

13.1.  The Mapping System Interface

   As mentioned in Section 8.2.2, both of the interfaces to the mapping
   system (from ITRs, and ETRs) are standardized, so that the more
   numerous xTRs do not have to be modified when the mapping indexing
   sub-system is changed.

   This section describes the interfaces in a little more detail; for
   details, see [RFC6833].

13.1.1.  Map-Request Messages

   {{Suggestion from editors: should come much earlier as it is an
   essential message in LISP}}

   The Map-Request message contains a number of fields, the two most
   important of which are the requested EID block identifier (remember
   that individual mappings may cover a block of EIDs, not just a single
   EID), and the Address Family Identifier (AFI) for that EID block.

   Other important fields are the source EID (and its AFI), and one or
   more RLOCs for the source EID, along with their AFIs.  The source EID
   and RLOCs allow ETRs to customize their answer.

   Finally, the message includes a long nonce, for simple, efficient
   protection against offpath attackers and a variety of other fields
   and control flag bits.

13.1.2.  Map-Reply Messages

   {{Suggestion from editors: should come much earlier as it is an
   essential message in LISP}}

   The Map-Reply message looks similar, except it includes the mapping
   entry for the requested EID(s), which contains one or more RLOCs and
   their associated data.  Note that the reply may cover a larger block
   of the EID namespace than the request; most requests will be for a
   single EID, the one which prompted the query.

   If there are no mappings available at all for the EID(s) requested, a
   Negative Map-Reply message will be returned.  This is a Map-Reply
   message with flag bits set to indicate that fact.

   For each RLOC in the entry, there  24

1.  Introduction

   There is the RLOC, its AFI, priority and
   weight fields (see Section 8.2), and multicast priority and weight
   fields (see Section 14).

13.1.2.1.  Solicit-Map-Request Messages

   Solicit-Map-Request (SMR) messages are actually not another message
   type, but a variant of Map-Request messages.  They include a special
   flag which indicates to the recipient that it should send a new Map-
   Request message, to refresh its mapping, because the ETR has detected rough consensus that the one it is using is out-dated.

   SMR's, like most other control traffic, should be rate-limited.

13.1.3.  Map-Register and Map-Notify Messages

   {{Suggestion by editors: As noted by the author add a paragraph
   describing how a xTR de-registers an EID-to-RLOC mapping.}}

   {{Suggestion by editors: add a small paragraph to explain what Map-
   Registers are used for}}

   The Map-Register message contains one or several mapping records,
   each with an individual Time-To-Live (TTL).  Each of the records
   contains an EID (potentially, a block of EIDs) and its AFI, a version
   number for this mapping (see Section 12.3.1 and a list of RLOCs and
   their AFIs.

   {{Suggestion by editors: do not understand the following paragraph}}
   Each RLOC entry also includes Internet routing and addressing
   system is facing severe scalability issues [RFC4984].  Specifically,
   the same data as growth in the Map-Replies
   (i.e. priority size of the routing tables of the Default-Free Zone
   (DFZ) is accelerating and weight); showing a supra-linear slope [DFZ].  The
   main driving force behind this growth is because in some circumstances it
   is advantageous to allow the MS to proxy reply on de-aggregation of BGP
   prefixes, which results from the ETR's behalf to
   Map-Request messages, existing BGP multihoming and traffic
   engineering mechanisms that are used -at the MS needs time of this information when it does
   so.

   Map-Notify messages have writing- on
   the exact same contents Internet, as Map-Register
   messages; they well as non-aggregatable address allocations.

   This issue has two profound implications, on the one hand Internet
   core routers are purely acknowledgements.

   The entire interaction is authenticated by use exposed to the network dynamics of a shared key,
   configured the edge.  For
   instance this typically leads to an increased amount of BGP UPDATE
   messages (churn), which results in additional processing requirements
   of Internet core routers in order to timely compute the MS and ETR.  Although DFZ RIB.
   Secondly, the protocol does already
   allow for replacement supra-linear growth imposes strong requirements on the
   size of the encryption algorithm, it does not
   support automated key management (although it appears memory storing the DFZ FIB.  Both aspects lead to fall under an
   increase on the development and production cost of high-end routers,
   and it is unclear if the exclusions semiconductor and router manufacturer
   industries will be able to cope, in [RFC4107]).

   LISP does not specify messages for de-registering an association the long-term, with such
   stringent requirements in a MS.  The de-registration cost-effective way[RFC4984].

   Although this important scalability issue is hence ensured relatively new, the
   architectural reasons behind it are well-known many years ago.
   Indeed, and as pointed out by [Chiappa], IP addresses have overloaded
   semantics.  Currently, IP addresses both identify the expiration topological
   location of a
   timer: if a MS does not receive Map-Register messages within given
   timeout, it de-register the association.

13.2.  The DDT Indexing Sub-system

   {{Suggestion from network attachment point as well as the editors: 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.

   The Locator/ID Separation Protocol (LISP), specified in [RFC6830], is
   built on top of this section does basic idea: decoupling the IP address overloaded
   semantics.  LISP creates two separate namespaces, EIDs (End-host
   IDentifiers) and RLOCs (Routing LOCators), both are -typically, but
   not add any
   fundamental value limited to- syntactically identical to the DDT overview section, propose current IPv4 and IPv6
   addresses.  EIDs are used to remove it uniquely identify nodes irrespective of
   their topological location and are typically routed intra-domain.
   RLOCs are assigned topologically to only keep network attachment points and are
   typically routed inter-domain.  With LISP, the overview; too much details that should not appear in
   an intro document}}

   As previously mentioned in Section 8.2.3, DDT is edge of the current indexing
   sub-system in LISP.

   The overall functioning is conceptually fairly simple; an MR which
   needs a mapping starts at a server for Internet
   -where the root DDT node (there will
   normally be more than one such server available, for both performance nodes are connected- and robustness reasons), the core -where inter-domain
   routing occurs- are architecturally separated and through interconnected by
   LISP-capable routers.  LISP also introduces a combination of cached
   delegation information, publicly accessible
   database, called the Mapping System, to store and repetitive querying of a sequence of DDT
   servers, works its way down retrieve mappings
   between identity and location.  LISP-capable routers exchange packets
   over the delegation tree until it arrives at
   an MS which is authoritative for Internet core by encapsulating them to the block appropriate
   location.  By taking advantage of EID which holds the
   destination EID in question.

   The interaction such separation between MRs location
   and DDT servers is as follow.  The MR
   sends to identity, the DDT server a Map-Request control message.  The DDT
   server uses its data (which is configured, and static) to see whether
   it Internet core is directly peered to an MS populated with RLOCs which can answer be
   quasi-static and highly aggregatable, hence scalable [Quoitin].

   This document describes the request, or if it
   has a child (or children, if replicated) which LISP architecture, its main operational
   mechanisms as its design rationale.  It is responsible for important to note that portion of the EID blocks.

   If it has children configured which are responsible, it will reply
   this document does not specify or complement the LISP protocol.  The
   interested reader should refer to the MR with another kind of main LISP control message, a Map-Referral
   message, which provides information about specifications
   [RFC6830] and the delegation of complementary documents [RFC6831],[RFC6832],
   [RFC6833],[RFC6834],[RFC6835], [RFC6836] for the block
   containing protocol
   specifications along with the requested EID. LISP deployment guidelines [RFC7215].

2.  LISP Architecture

   This step is secured via
   authentication.

   The Map-Referral also gives section presents the addresses LISP architecture, we first detail the
   design principles of DDT servers for that
   block LISP and the MR can then send Map-Requests we proceed to any one (or all) describe its main
   aspects: data-plane, control-plane, and internetworking mechanisms.

2.1.  Design Principles

   The LISP architecture is built on top of
   them.  In addition, four basic design
   principles:

   o  Locator/Identifier split: By decoupling the Map-Referral includes keying material for overloaded semantics
      of the
   children, which allows any information provided by them to be
   cryptographically verified.

   Control flags in current IP addresses the Map-Referral indicate Internet core can be assigned with
      topological meaningful address and hence, can use aggregation to
      scale.  Devices are assigned with identity meaningful address that
      are independent of its topological location.

   o  Overlay architecture: Overlays route packets over the querying MR whether
   the referral is current
      Internet, allowing to another DDT server, an MS, or an ETR. {{All three?
   Check}} If deploy new protocols without changing the former,
      current infrastructure hence, resulting from a low deployment
      cost.

   o  Decoupled data and control-plane: Separating the MR then sends data-plane from
      the Map-Request control-plane allows them to the child
   DDT server, repeating the process.

   If the second, the MR then interacts with that MS, scale independently and usually the
   block's ETR(s) as well, to cause a mapping to be sent to use
      different architectural approaches.  This is important given that
      they typically have different requirements.

   o  Incremental deployability: This principle ensures that the ITR
   which queried
      protocol is compatible with the MR for it.  Recall that legacy Internet while providing
      some MS's provide Map-
   Replies on behalf of an associated ETR, in so-called 'proxy mode', so
   in such cases the Map-Reply will come targeted benefits to early adopters.

2.2.  Overview of the Architecture

   LISP splits architecturally the core from the MS, not edge of the ETR.

   Delegations Internet by
   creating two separate namespaces: Endpoint Identifiers (EIDs) and
   Routing LOCators (RLOC).  The edge are cached in the MRs, so that once LISP sites (e.g., an MR has received
   information about a delegation, it usually will
   Autonomous System) that use EID addresses.  EIDs are typically -but
   not need to look limited to- IPv4 or IPv6 addresses that
   up again.  Once it has been in operation for a short while, there
   will usually only uniquely identify
   endhosts and are assigned and configured by the same mechanisms that
   we have at the time of this writing.  EIDs can be a limited amount are typically
   Provider Independent (PI [RFC4116]) addresses and can be thought as
   they don't contain intra-domain topological information.  Because of delegation information which
   is has not yet asked about - probably
   this, EIDs are usually only the last stage routable in a
   delegation to a leaf MS.

13.3.  Reliability via Replication

   {{Suggestion by editors: Remove this section, describes operational
   practices/policies of the DDT infrastructure, this is beyond edge.

   With LISP, LISP sites (edge) and the
   scope core of this document.}}

   Everywhere throughout the mapping system, robustness to operational
   failures is obtained Internet are inter-
   connected by replicating data in multiple instances of any
   particular node (of whatever type).  Map-Resolvers, Map-Servers, DDT
   nodes, ETRs - all means of them can be replicated, and LISP-capable routers (e.g., border routers).
   When they provide egress (from the protocol
   supports this replication.

   There core perspective) to a LISP site
   they are generally no mechanisms specified yet called Egress Tunnel Routers (ETR), Ingress Tunnel Routers
   (ITR) when they provide ingress, and xTR when they provide both.
   ITRs and ETRs exchange packets by encapsulating them, hence LISP
   operates as an overlay to ensure coherence
   between multiple copies the current Internet core.

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

           Figure 1.- A schema of any particular data item (e.g. the copies
   of delegation data for a particular block of namespace, in DDT
   sibling servers) - this is currently a manual responsibility.

   If and when LISP protocol adoption proceeds, an automated layer to
   perform this functionality can easily be layered on top of Architecture

   With LISP, the
   existing mechanisms.

   The deployed DDT system actually core uses anycast [RFC4786], along with
   replicated servers, to improve both performance and robustness.

13.4.  Security of the DDT Indexing Sub-system

   {{Suggestion by editors: Remove this section, provides unnecessary
   details of DDT.}}

   In summary, securing the mapping indexing system RLOCs, an RLOC is divided into two
   parts: the typically -but not limited
   to- an IPv4 or IPv6 address assigned to an Internet-facing network
   interface between the clients of the system (MR's) and the
   mapping indexing system itself, and the interaction between the DDT
   servers which make it up.

   The client interface provides only a single model, using the
   canonical public-private key system (starting an ITR or ETR.  Typically RLOCs are numbered from
   topologically aggregatable blocks assigned to a trust anchor),
   in site at each point to
   which the child's public key is provided by the parent, along with
   the delegation.  When the child returns any data, it can sign the
   data, and the requestor can use that signature attaches to verify the data.
   This requires very little configuration in the clients. global Internet.  The interface between the DDT servers allows for choices between a
   number of different options, allowing the operators to trade off
   among configuration complexity, security level, etc.  This topology is based
   on experience with DNSSEC ([RFC4033]), where configuration complexity
   has been a major stumbling block to deployment.

13.5.  Extended Capabilities

   {{Suggestion defined by editors: Remove this section, not discussed in any WG
   document.}}

   In addition to
   the priority and weight data items in mappings, LISP
   offers other tools to enhance functionality, particularly connectivity of networks, in this context RLOCs can be though as
   Provider Aggregatable addresses [RFC4116].

   A publicly accessible and usually distributed database, called the
   traffic engineering area.

   One is requestor-specific mappings, i.e. the ETR may return different
   Mapping System, stores mappings to the enquiring ITR, depending on between EIDs and RLOCs.  Such
   mappings relate the identity of the ITR.
   This allows very fine-tuned traffic engineering, far more powerful
   than routing-based TE.

13.6.  Performance 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

   Prior to the creation of DDT, a large study of can be thought as the performance
   equivalent of the
   previous mapping system, ALT ([RFC6836]), along with a proposed new
   design called TREE (which used DNS that would be accessed by ETRs to hold delegation information)
   provided considerable insight into the likely performance of the
   mapping systems at larger scale (See [LISP-TREE]).

   The basic structure register
   mappings and concepts of DDT are identical by ITRs to those of
   TREE, so retrieve them.

   Finally, the performance simulation work done for LISP architecture has a strong emphasis in cost
   effective incremental deployment.  Given that design applies
   equally LISP represents an
   overlay to DDT.

   {{Suggestion from editors: next sentence is redundant with previous
   parts of the doucment}} In that study, current Internet architecture, endhosts as with earlier LISP
   performance analyses, extensive large-scale simulations were driven
   by lengthy recordings of actual traffic at several major sites; one
   was the site in the first study ([Iannone]), well as
   intra and the other was an
   even large university, with roughly 35,000 users.

   The results showed that a system like DDT, which caches information
   about delegations, inter-domain routers remain unchanged, and allows the MR only
   required changes to communicate directly with the
   servers for the lower vertices on existing infrastructure are to routers
   connecting the delegation hierarchy based on
   cached delegation information, would have good performance, EID with
   average resolution times on the order of the MR to MS RTT.  This
   verified RLOC space.  Such LISP capable routers
   typically require only a software upgrade.  Additionally, LISP
   requires the effectiveness deployment of an independent Mapping System, this particular type of indexing
   system.

   A more recent study, [Saucez], has measured actual resolution times
   distributed database is a new network entity.

   In what follows we describe a simplified packet flow sequence between
   two nodes that are attached to LISP sites.  Client hostA wants to
   send a packt to server hostB.

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

               Figure 2.- Packet flow sequence in the deployed LISP network; it took measurements from a variety

   1.  HostA retrieves the EID_B of
   locations HostB (typically querying the DNS)
       and generates an IP packet as in the Internet, with respect to a number of different
   target EIDs.  Average measured resolution delays ranged from roughly
   175 msec to 225 msec, depending on the location.

14.  Multicast Support in LISP

   {{Suggestion by editors: Rewrite this section, it provides too many
   details.  Reduce it to a brief description of LISP Multicast}}

   LISP packet has
       source address EID_A and its intrinsic separation of identity from location destination address EID_B.

   2.  The packet is well
   suited for Multicast ([RFC3170], [RFC5110]), and the definition of
   mappings routed towards ITR_A in the current specifications already allows multicast
   capability ([RFC6830]).

   {{Say something about sources.}}

   {{Suggestion by editors: remove LISP site using
       standard intra-domain mechanisms.

   3.  ITR_A upon receiving the paragraph below, motivation for
   multicast is out of packet queries the scope of this document}}

   Multicast is an important requirement, for a number of reasons: doing
   multiple unicast streams is inefficient, as it is easy Mapping System to use up all
   the upstream bandwidth; without multicast a server can also be
   saturated fairly easily in doing
       retrieve the unicast replication; etc.

   Since it locator of ETR_B that is important for LISP servicing hostB.  In order
       to work well with multicast; doing do so
   has been it uses a significant focus in LISP throughout its entire
   development.

   Further very significant improvements to multicast support in LISP
   are in progress; see [Improvements], Section "Multicast" for more on
   them.

14.1.  Basic Concepts of Multicast Support control message called Map-Request, the
       message contains EID_A as the lookup key, in turn it receives
       another LISP

   This section introduces some of control message called Map-Reply, the basic principles of multicast
   support in LISP.

   Since group addresses name distributed collective entities, message
       contains two locators: RLOC_B1 and RLOC_B2 along with traffic
       engineering policies: priority and weight per locator.  ITR_A
       also stores the mapping in
   general they cannot have a single RLOC also.  Since they usually
   refer local cache to collections speed-up forwarding
       of entities subsequent packets.

   4.  ITR_A encapsulates the notion of endpoint identity must
   be

   A multicast 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 at
       and RLOC_B2 as destination, the inner header has EID_A as source
       and EID_B as destination.  Furthermore ITR_A adds a LISP site may not header,
       more details about LISP encapsulation can be able to become the root
   of a distribution tree found in
       Section 2.3.1.

   5.  The encapsulated packet is forwarded by the Internet core if it uses its EID as its identity
   for that distribution tree (i.e. a distribution tree (S-EID, G));
   that is because there may not be a route to its
       normal IP packet, making the EID in invisible from the core
   (assuming that its section Internet
       core.

   6.  Upon reception of the core even supports multicast; not
   all parts of encapsulated packet by ETR_B, it
       decapsulates the core do).

   Therefore, outside packet and forwards it to hostB.

2.3.  Data-Plane

   This section describes the LISP site, multicast state for the
   distribution tree (S-RLOC, G) needs to be built instead, where S-RLOC data-plane, which is the RLOC specified in
   [RFC6830].  The LISP data-plane is responsible of 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 multicast source inside EID with the LISP site
   will be sending its traffic through.

   Multicast LISP requires no packet format changes to existing
   multicast RLOC space (ITR)
   and viceversa (ETR).  We first describe how packets (both control, are LISP-
   encapsulated and user data).  The initial
   multicast support in then we proceed to explain how ITRs cache forwarding
   state.

2.3.1.  LISP uses existing multicast control mechanisms
   exclusively; improvements currently being worked on provide LISP-
   specific control mechanisms (see [Improvements]).

14.2.  Initial Multicast Support encapsulation

   ITRs encapsulate data packets towards ETRs.  LISP data packets are
   encapsulated using UDP (port 4341).  A particularity of LISP is that
   UDP packets should include a zero checksum [RFC6935] [RFC6936] that
   it is not verified in reception, LISP

   {{Suggestion also supports non-zero
   checksums that may be verified.  This decision was made because the
   typical transport protocols used by editors: remove this paragraph}}

   Readers who wish to fully understand multicast support need to
   consult the appropriate specifications: applications already include
   a checksum, by neglecting the additional UDP encapsulation checksum
   xTRs can forward packets more efficiently.

   LISP-encapsulated packets also include a LISP multicast issues are
   discussed in [RFC6830], Section 11; and see [RFC6831] for header (after the full UDP
   header).  The LISP header is prepended by ITRs and striped by ETRs.
   It carries reachability information (see more details of current multicast support in LISP.

   With the multicast operation defined in [RFC6831]), destination group
   addresses are not mapped; only the source address (when Section 3.2)
   and the original
   source Instance ID field.  The Instance ID field is used to
   distinguish traffic that belongs to multiple tenants inside a LISP site) needs
   site, and that may use overlapped but logically separated addressing
   space.

   Overall, LISP encapsulated data packets carry 4 headers [RFC6830]
   ("outer" to be mapped, both during
   distribution tree setup, as well "inner"):

   1.  Outer IP header containing RLOCs as actual traffic delivery.

   In other words, while LISP's mapping capability is used, at this
   stage it is only applied to the source, not the source and destination (as
       addresses.  This header is originated by ITRs and stripped by
       ETRs.

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

   3.  LISP activity).  Thus, in LISP-encapsulated multicast packets in
   this mode, the inner header that may contain reachability information and an
       Instance ID field.  This header is originated by ITRs and
       stripped by ETRs.

   4.  Inner IP header containing EIDs as source and destination
       addresses.  This header is created by the EID, source end-host and
       remains unchanged.

   Finally and in some scenarios Recursive and/or Re-encapsulating
   tunnels can be used for Traffic Engineering and re-routing.  Re-
   encapsulating tunnels are consecutive LISP tunnels and occur when an
   ETR removes a LISP header and then acts as an ITR to prepend another
   one.  On the outer source is the
   ITR's RLOC; both inner other hand, Recursive tunnels are nested tunnels and outer destinations are the group's
   multicast address.

   Note that this does mean that if the group is
   implemented by using separate source-
   specific trees for distribution, there isn't multiple LISP encapsulations on a separate distribution
   tree outside the packet.

2.3.2.  LISP site for each different source of traffic to
   the group Forwarding State

   ITRs retrieve from inside the LISP site; they Mapping System mappings between EID
   prefixes and RLOCs that are all grouped together
   under used to encapsulate packets.  Such
   mappings are stored in a single source, local cache -called the RLOC.

   The issue of encapsulation is complex, because if Map-Cache- to
   increase the rest forwarding speed of the
   group outside the LISP site includes some members which are at other
   LISP sites (i.e. subsequent packets addressed to them have to be encapsulated), and some
   members at legacy sites (i.e. encapsulated packets would not be
   understood), there is no simple answer.  (The situation becomes even
   more complex when one considers that as hosts leave and join the
   group, it may switch back and forth between mixed and homogenous.)
   This issue is too complex to fully cover here; see Section 9.2.,
   "LISP Sites with Mixed Address Families", in [RFC6831], for complete
   coverage of this issue.

   Basically, there are multicast equivalents of some of
   same EID prefix.  Mappings include a (Time-to-Live) TTL (set by the legacy
   interoperability mechanisms used for unicast; mPITRs and mPETRs
   (multicast-capable PITRs
   ETR) and PETRs).  When mixed groups are a
   possibility, two choices are available: i) send two copies (one
   encapsulated, and one not) of all traffic, or ii) employ mPETRs to
   distribute non-encapsulated copies expired according to legacy group members.

15.  Deployment Issues and Mechanisms

   {{Suggestion by editors: Remove this section, provides unnecessary
   details.  Add a reference to the deployment RFC.}}

   This section discusses several deployment issues in value, more detail.
   With LISP's heavy emphasis on practicality, much work has gone into
   making sure it works well in details about the real-world environments most people
   have to deal with.

15.1.  LISP Deployment Needs

   As mentioned earlier (Section 5.2),
   Map-Cache management can be found in Section 3.1.

2.4.  Control-Plane

   The LISP requires no change control-plane, specified in [RFC6833], provides a standard
   interface to almost
   all existing hosts register, query, and routers.  Obviously, however, one must deploy
   something to run LISP.  Exactly what retrieve mappings.  The LISP
   Mapping System, is a publicly accessible database that has to be will depend
   greatly on stores such
   mappings.  In what follows we first describe the details mappings, then the
   standard interface, and finally the Mapping System architecture.

2.4.1.  LISP Mappings

   Each mapping includes the bindings between EID prefix(es) and set of
   RLOCs as well as traffic engineering policies, in the site's existing networking gear, form of
   priorities and
   choices it makes weights for how the RLOCs.  Priorities allow the ETR to achieve
   configure active/backup policies while weights are used to load-
   balance traffic among the RLOCs (on a per-flow basis).

   Typical mappings in LISP deployment.

   The primary requirement is for one or more xTRs.  These may be
   existing routers, just with new software loads, or it may require bind EIDs in the
   deployment form of new devices.

   {{Suggestion by editors: next paragraph is barely understandable}}

   LISP also requires IP prefixes with a certain amount
   set of LISP-specific support
   infrastructure, such as MRs, MSs, RLOCs, also in the DDT hierarchy, etc.  However,
   much form of this will either i) {{for the case where you IPs.  Such addresses are adding a new
   site encoded
   using existing a general syntax called LISP infrastructure}} already be deployed, Canonical Address Format (LCAF),
   specified in [I-D.ietf-lisp-lcaf].  The syntax is general enough to
   support encoding of IPv4 and if
   the new site can make arrangements IPv6 addresses and any other type of
   value.

   With such a general syntax for address encoding in place, LISP aims
   to use it, it need do nothing
   else; or ii) those functions the site must provide may be co-located
   in other flexibility to current and future applications.  For
   instance LCAFs could support MAC addresses, geo-coordinates, ASCII
   names and application specific data.

2.4.2.  Mapping System Interface

   LISP devices (again, either new devices, or new software on
   existing ones).

15.2.  Interworking Mechanisms

   One aspect which has received defines a lot of attention standard interface between data and control planes.
   The interface is specified in [RFC6833] and defines two entities:

   Map-Server:  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 mechanisms
   previously referred ETR.  However they can also
      operate in proxy-mode, where the ETRs delegate replying to (in Section 6.4) queries
      to allow interoperation of
   LISP sites Map-Servers.  This setup is useful when the ETR has low
      resources (i.e., CPU or power).

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

   The interface defines four LISP control messages which are not running LISP
   (yet).

   {{Suggestion by editors: remove next paragraph sent as it talks about
   features (NAT based transition) not covered
   UDP datagrams (port 4342):

   Map-Register:  This message is used by the WG}}

   There are two main approaches ETRs to such interworking: proxy routers
   (PITRs and PETRs), register mappings in
      the Mapping System and an alternative mechanism it is authenticated using a router with
   combined NAT shared key
      between the ETR and LISP functionality; these are described in more
   detail here.

15.2.1.  Proxy LISP Routers

   {{Suggestion the Map-Server.

   Map-Notify:  When requested by editors: Move this section to Part I.  PxTRs are an
   important aspect of LISP and as such, should be described before.
   Furthermore simplify it, it currently contains too many details plus
   an additional discussion on the impact of PITR that ETR, this message is out of sent by the
      Map-Server in response to a Map-Register to acknowledge the
   scope
      correct reception of the document.}}

   PITRs (proxy ITRs) serve as mapping.

   Map-Request:  This message is used by ITRs for traffic from legacy hosts or Map-Resolvers to
   nodes in LISP sites.  PETRs (proxy ETRs) serve as
      resolve the mapping of a given EID.

   Map-Reply:  This message is sent by Map-Servers or ETRs for LISP
   traffic in response
      to legacy host.

   Note a Map-Request and contains the resolved mapping.  Please note
      that return traffic to a legacy host from Map-Reply may contain a LISP-using node does
   not necessarily have to pass through an ITR/PETR pair - the original
   packets can usually just be sent directly to negative reply if the ultimate
   destination.  However, for some kinds of LISP operation (e.g. mobile
   nodes), this queried EID
      is not possible; in these situations, part of the PETR is
   needed.

15.2.1.1.  PITRs

   To serve as ITRs for traffic from legacy hosts to nodes in LISP
   sites, PITRs they have to advertise into EID space.  In such cases the existing legacy backbone
   Internet routing ITR
      typically forwards the availability of whatever ranges of EIDs (i.e. of
   nodes using LISP) they are proxying for, so that legacy hosts will
   know where to send traffic natively (non encapsulated) to those LISP nodes.  PITR implies that
   EID prefixes are advertised in BGP.

   This technique may have an impact on routing table in the Internet
   core, but it is not clear yet exactly what that impact will be; it is
   very dependent on the collected details
      public Internet.

2.4.3.  Mapping System

   LISP architecturally decouples control and data-plane by means of many individual deployment
   decisions.

   A PITR may cover a group
   standard interface.  This interface glues the data-plane, routers
   responsible of EID blocks forwarding data-packets, with a single EID
   advertisement to the core, LISP Mapping System,
   a publicly accessible database responsible of storing mappings.

   With this separation in order to reduce place the number of routing
   table entries added.  In fact, at data and control-plane can use
   different architectures if needed and scale independently.  Typically
   the moment, aggressive aggregation
   of EID announcements data-plane is performed, precisely optimized to route packets according to minimize
   hierarchical IP addresses.  However the
   number of new announced routes added control-plane may have
   different requirements, for instance and by this technique.

   At taking advantage of the same time, if
   LCAFs, the Mapping System may be used 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 site result of the local mapping
   cache available at ITR, the Mapping System does traffic engineering with not need to operate
   at line-rate.

   The LISP
   instead WG has discussed for the Mapping System architecture the
   four main techniques available in distributed systems, namely: graph-
   based databases in the form of fine-grained BGP announcement, that will help keep table
   sizes down (and this is true even LISP+ALT [RFC6836], hierarchical
   databases in the form of LISP-DDT [I-D.ietf-lisp-ddt], monolithic
   databases in the early stages form of LISP
   deployment).  The same is true for multi-homing. {{Maybe mixing two
   concepts?  LISP TE tools will still apply to traffic between PITR LISP-NERD [I-D.lear-lisp-nerd] and
   LISP site.}}

   As mentioned previously (Section 12.1), an ITR at another LISP site
   can avoid using a PITR (i.e. flat
   databases in the form of LISP-DHT
   [I-D.cheng-lisp-shdht],[I-D.mathy-lisp-dht].  Furthermore it is worth
   noting that, in some scenarios such as private deployments, the
   Mapping System can detect that a given ultimate
   destination operate logically centralized.  In such cases it
   is not a legacy host, if typically composed of a PITR is advertising it into single Map-Server/Map-Resolver.

   In what follows we focus on the Internet core) by checking to see if a LISP two mapping exists for systems that ultimate destination.

15.2.1.2.  PETRs

   PETRs (proxy ETRs) serve as ETRs for have been
   implemented and deployed (LISP-ALT and LISP+DDT).

2.4.3.1.  LISP+ALT

   The LISP traffic to legacy hosts,
   for cases where a Alternative Topology (LISP+ALT) [RFC6836] was the first
   Mapping System proposed, developed and deployed on the LISP node cannot send packets to such hosts without
   encapsulation.  That typically happens for one of two reasons.

   First, it will happen in places where some device pilot
   network.  It is implementing
   Unicast Reverse Path Forwarding (uRPF), to prevent based on a variety of
   negative behaviour; originating packets with distributed BGP overlay.  All the original source's
   EID
   participating nodes connect to their peers through static tunnels.
   Every ETR involved in the source address field will result in them being filtered
   out and discarded.

   {{Suggestion by editors: would adding and example be useful?}}

   Second, ALT topology advertises its EID prefixes
   making the EID routable on the overlay.

   When an ITR needs a mapping, it will happen when sends a LISP site wishes to send packets Map-Request to a
   non-LISP site, and nearby ALT
   router.  The ALT routers then forward the path in between does not support Map-Request on the
   particular IP protocol version used overlay
   by inspecting their ALT routing tables.  When the Map-Request reaches
   the ETR responsible for the mapping, a Map-Reply is generated and
   directly sent to the ITR's RLOC, without using the ALT overlay.

2.4.3.2.  LISP-DDT

   LISP-DDT [I-D.ietf-lisp-ddt] is conceptually similar to the DNS, a
   hierarchical directory whose internal structure mirrors the original source along its
   entire length.  Use
   hierarchical nature of the EID address space.  The DDT hierarchy is
   composed of DDT nodes forming a PETR on tree structure, the other side leafs of the gap will allow tree
   are Map-Servers.  On top of the LISP site's packet to 'hop over' structure there is the gap, by utilizing LISP's
   built-in support for mixed protocol encapsulation.

   PETRs are generally used by specific ITRs, DDT root node
   [DDT-ROOT], which have the location is a particular instance of
   their PETRs configured into them.  In other words, unlike normal
   ETRs, PETRs do not have to register themselves a DDT node and that
   matches the entire address space.  As in the mapping
   database, on behalf case of any legacy sites they serve.

   Also, allowing an ITR to always send traffic leaving a site to DNS, DDT
   supports multiple redundant DDT nodes and/or DDT roots.  The
   following figure presents a PETR schematic representation of the DDT
   hierarchy.

                        /---------\
                        |         |
                        | 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|
+------------+     +------------+   +------------+ +------------+

      Figre 3.- An schematic representation of the DDT tree structure,
              please note that the prefixes and the structure depitected
              should be only considered as an example.

   The DDT structure does avoid having to chose whether or not to encapsulate packets; it
   can actually index EID-prefixes but eXtended
   EID-prefixes (XEID).  An XEID-prefix is just always encapsulate packets, sending them the concatenation of the
   following fields (from most significant bit to less significant bit):
   Database-ID, Instance ID, Address Family Identifier and the PETR if it
   has no specific mapping actual
   EID-prefix.  The Database-ID is provided for possible future
   requirements of higher levels in the ultimate destination.

15.2.2.  LISP-NAT

   {{Suggestion by editors: Remove this section, LISP-NAT is not a WG
   document neither an inter-networking mechanisms.}}

   A LISP-NAT router, as previously mentioned, combines LISP hierarchy and to enable the
   creation of multiple and NAT
   functionality, in separate database trees.

   In order to allow resolve a LISP site which is internally
   using addresses which cannot be globally routed to communicate with
   non-LISP sites elsewhere query LISP-DDT operates iteratively and in a
   similar way to the Internet.  (In other words, the
   technique used by DNS.  DDT clients (usually Map-Resolvers) generate
   Map-Requests to the PITR approach simply cannot be used in this
   case.)

   To do this, DDT root node.  In response they receive a newly
   introduced LISP-control message: a LISP-NAT performs Map-Referral.  A Map-Referral
   provides the usual NAT functionality, and
   translates list of RLOCs of the set of DDT nodes matching a host's source address(es)
   configured XEID delegation.  That is, the information contained in packets passing through it
   from an inner value
   the Map-Referral points to an outer value, and storing the child of the queried DDT node that translation
   in a table, which it can use to similarly has
   more specific information about the queried XEID-prefix.  This
   process subsequent packets
   (both outgoing is repeated until the DDT client walks the tree structure
   (downwards) and incoming).  [RFC6832]

   {{Suggestion by editors: remove discovers the following paragraph, does not
   bring anything}}

   There are two main cases where this might apply:

   o  Sites using non-routable global addresses

   o  Sites using private addresses [RFC1918]

15.3.  Use Through NAT Devices

   {{Suggestion by editors: Remove Map-Server servicing the queried XEID.
   At this section, LISP-NAT is not point the client sends a WG
   document neither an inter-networking mechanisms.}}

   NATs are both ubiquitous, Map-Request and here to stay for receives a long time Map-Reply
   containing the mappings.  It is important to come.
   [RFC1631] Thus, in note that DDT clients
   can also cache the actual Internet of today, having any new
   mechanisms function well information contained in Map-Referrals, that is,
   they cache the presence of NATs (i.e. with LISP xTRs
   behind a NAT device) DDT structure.  This is absolutely necessary.

   LISP has produced a variety of mechanisms to do this.  An
   experimental mechanism used to support them had major limitations; it, and
   its limitations, are described in Appendix B.5.

15.4.  LISP and Core Internet Routing

   {{Suggestion by editors: Remove this section, this reduce the mapping
   retrieving latency[Jakab].

   The DDT Mapping System relies on manual configuration.  That is already
   explained in lisp-deployment}}

   One of LISP's original motivations was to control Map-
   Resolvers are manually configured with the growth set of available DDT root
   nodes while DDT nodes are manually configured with the
   size of routing tables appropriate
   XEID delegations.  Configuration changes in the Internet core, DDT nodes are only
   required when the part where routes tree structure changes itself, but it doesn't
   depend on EID dynamics (RLOC allocation or traffic engineering policy
   changes).

2.5.  Internetworking Mechanisms

   EIDs are typically identical to
   all destinations must be available.  As either IPv4 or IPv6 addresses and
   they are announced at the LISP becomes more widely
   deployed, it can help with this issue, Mapping System, however they are
   usually not announced in the Internet global routing system.  As a variety of ways.

   In covering this topic, one must recognize that conditions in various
   stages of
   result LISP deployment (in terms of ubiquity) will have a large
   influence.  [RFC7215] introduced useful terminology for this
   progression, in addition to some coverage of the topic (see
   Section 5, "Migration requires an internetworking mechanism to LISP"):

   The loosely defined terms of early transition phase, late transition
   phase, and allow LISP Internet phase refer sites
   to time periods when LISP speak with non-LISP sites and viceversa.  LISP internetworking
   mechanisms are a minority, a majority, or represent all edge networks
   respectively.

   In the early phases of deployment, two primary effects will allow specified in [RFC6832].

   LISP defines two entities to have a positive impact on the routing table growth:

   o  Using LISP for traffic engineering instead of BGP

   o  Aggregation of smaller PI sites into a single PITR advertisement

   The first is fairly obvious (doing TE with BGP requires injecting
   more-specific routes into provide internetworking:

   Proxy Ingress Tunnel Router (PITR):  PITRs provide connectivity from
      the legacy Internet core routing tables, something
   doing TE with to LISP avoids); sites.  PITRs announce in the second is not guaranteed to happen
   (since it requires coordination among a number of different parties),
   and only time will tell if it does happen.

16.  Fault Discovery/Handling

   {{Suggestion by editors: Remove this section, although this section
   helps understanding how many global
      routing system blocks of EID prefixes (aggregating when possible)
      to attract traffic.  For each incoming data-packet, the LISP mechanisms work
   (particularly the ones described in section 12) PITR LISP-
      encapsulates it provides an
   unnecessary level of (operational) detail.  This level towards the RLOC(s) of
   understanding should be achieved reading the main appropriate LISP spec. }} site.
      The structure of LISP gives rise to a moderate number of impact of failure
   modes.

16.1.  Handling Missing Mappings

   To handling missing mappings, PITRs in the ITR calls for routing table size of the mapping, and DFZ is, in
      the meantime can either discard traffic worst-case, similar to that ultimate destination
   (as many ARP implementations do) [RFC0826], or, if dropping the
   traffic is deemed undesirable, it can forward them via a PITR.

16.2.  Outdated Mappings

   If a mapping changes once an ITR has retrieved it, that may result case in
   traffic to which LISP is not deployed.
      EID-prefixes will be aggregated as much as possible both by the EIDs covered
      PITR and by that mapping failing.  There are three
   cases to consider:

   o  When the ETR global routing system.

   Proxy Engress Tunnel Router (PETR):  PETRs provide connectivity from
      LISP sites to which traffic is being sent is still a valid ETR
      for that EID, but the mapping has been updated (e.g. legacy Internet.  In some scenarios, LISP sites
      may be unable to change the
      priority of various ETRs)

   o  When the ETR traffic is being sent send encapsulated packets to the legacy Internet.
      For instance when Unicast Reverse Path Forwarding (uRPF) is still used
      by Provider Edge routers, or when an ETR, but no
      longer intermediate network between
      a valid ETR for that EID

   o  When LISP site and a non-LISP site does not support the ETR traffic is being sent to is no longer an ETR

16.2.1.  Outdated Mappings - Updated Mapping

   A 'mapping versioning' system, whereby mappings have desired
      version numbers,
   and ITRs are notified when their mapping is out of date, has been
   added to detect this, and the ITR responds by refreshing IP (IPv4 or IPv6).  In both cases the mapping.
   [RFC6834]

16.2.2.  Outdated Mappings - Wrong ETR

   If an ITR is holding an outdated cached mapping, it may send packets PETR allows to an ETR which is no longer an ETR for that EID.

   It might be argued that if
      overcome such limitations by encapsulating packets over the ETR is properly managing
      network.  Finally, the lifetimes
   on its mapping entries, RLOC of PETRs must be statically configured
      in ITRs.

3.  LISP Operational Mechanisms

   In this cannot happen, but it is a wise design
   methodology to assume that cannot happen events will section we detail the main operational mechanisms defined in fact happen
   (as they do, due to software errors, or, on rare occasions, hardware
   faults),
   LISP.

3.1.  Cache Management

   LISP's decoupled control and ensure that the system will handle them properly.

   ETRs can easily detect cases data-plane, where this happens, after they have un-
   wrapped a user data packet; mappings are stored in response, they send
   the control-plane and used for forwarding in the data plane, requires
   of a Solicit-Map-
   Request local cache in ITRs to reduce signaling overhead (Map-Request/
   Map-Reply) and increase forwarding speed.  The local cache available
   at the source ITR to cause it ITRs, called Map-Cache, is used by the router to refresh its mapping.

16.2.3.  Outdated Mappings - No Longer an ETR

   In another case for what can happen if an ITR uses an outdated
   mapping, LISP-
   encapsulate packets.  The Map-Cache is indexed by (Instance ID, EID-
   prefix) and contains basically the destination set of RLOCs with the associated
   traffic from an ITR might no longer be a
   LISP node at all.  In such cases, one might get an ICMP Destination
   Unreachable (Port Unreachble subtype) error message.  However, one
   cannot depend on that - engineering policies (priorities and in weights).

   The Map-Cache, as any event, that would provide an
   attack vector, so it should be used with care.  (See [RFC6830],
   Section 6.3 other cache, requires cache coherence
   mechanisms to maintain up-to-date information.  LISP defines three
   main mechanisms for more about this.)

   The following mechanism will work, though.  Since cache coherence:

   Time-To-Live (TTL):  Each mapping contains a TTL set by the destination is
   not an ETR, upon
      expiration of the echoing reachability detection mechanism (see
   Section 12.3.2, "Echo Nonces") will detect a problem.  At that point, TTL the backstop mechanism, Probing, will kick in.  Since ITR could refresh the destination mapping by sending
      a new Map-Request.  Typical values for TTL defined by LISP are
      24h.

   Solicit-Map-Request (SMR):  SMR is still not an ETR, that will fail, too.

   At that point, traffic will explicit mechanism to update
      mapping information.  In particular a special type of Map-Request
      can be switched sent on demand by ETRs to request refreshing a different ETR, or, if
   none are available, a reload mapping.
      Upon reception of a SMR message, the mapping may be initiated.

16.3.  Erroneous Mappings

   {{Suggestion ITR must refresh the bindings
      by editors: this section brings nothing, remove it}}

   Again, this should not happen, but sending a good system should deal with it.
   However, Map-Request to the Mapping System.

   Map-Versioning:  This optional mechanism piggybacks in practise, should this happen, it will produce one the LISP
      header of data-packets the
   prior two cases (the wrong ETR, or something that is not version number of the mappings used by
      an ETR), and
   will be handled as described there.

16.4.  Verifying ETR Liveness

   The ITR, like all packet switches, needs to detect, and react, xTR.  This way, when
   its neighbour ceases operation.  As LISP traffic is effectively
   always uni-directional (from ITR to ETR), this could be somewhat
   problematic.

   Solving a related problem, "neighbour ETR" "reachability" below)
   subsumes handling this fault mode, however.

   {{Suggestion by editors: remove next paragraph }}

   Note that the two terms - liveness and reachability - are not
   synonymous (although they are often confused).  Liveness is an xTR receives a
   property of LISP-encapsulated packet
      from a node - remote xTR, it is either up and functioning, can check whether its own Map-Cache or it is not.
   Reachability is only a property of a particular pair the
      one of nodes. the remote xTR is outdated.  If packets sent from a first node to its Map-Cache is outdated,
      it sends a second are successfully
   received at Map-Request for the second, it is reachable from remote EID so to obtain the first.  However, newest
      mappings.  On the
   second node may at contrary, if it detects that the very same time not be reachable from some
   other node.  Reachability remote xTR Map-
      Cache is always outdated, it sends it a ordered pairwise property, and
   of SMR to notify it that a specified ordered pair.

16.5.  Verifying ETR new
      mapping is available.

3.2.  RLOC Reachability

   A more significant issue than whether a particular ETR

   The LISP architecture is up or not
   is, as mentioned above, that although the ETR may be up, attached to
   the network, etc, an issue in edge to edge pull architecture, where the network, between a source ITR, and
   network state is stored in the ETR, may prevent traffic from control-plane while the ITR from getting to data-plane
   pulls it on demand.  On the ETR.
   (Perhaps contrary BGP is a routing problem, or perhaps some sort push architecture,
   where the required network state is pushed by means of access control
   setting.)

   The one-way nature BGP UPDATE
   messages to BGP speakers.  In push architectures, reachability
   information is also pushed to the interested routers.  However pull
   architectures require of explicit mechanisms to propagate
   reachability information.  LISP traffic makes this situation hard defines a set of mechanisms to
   detect with simple inform
   ITRs and non-intrusive techniques.  In line with PITRS about the
   LISP design philosophy this problem reachability of the cached RLOCs:

   Locator Status Bits (LSB): LSB is then attacked not with a
   single mechanism (which would passive technique, the LSB field
   is carried by data-packets in the LISP header and can be complex) but with set by a collection of
   simple mechanisms.

   They
   ETRs to specify which RLOCs are reliance 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 underlying routing system (which can status of
   course only reliably provide RLOCs.

   Echo-nonce: This is also a negative reachabilty indication, not passive technique, that can only operate
   effectively when data flows bi-directionally between two
   communicating xTRs.  Basically, an ITR piggybacks a
   positive one), random number
   (called nonce) in LISP data packets, if the echo nonce (which depends on some return traffic
   from path and the destination xTR back to probed
   locator are up, the source xTR), and finally RLOC
   probing, in ETR will piggyback the same random number on the
   next data-packet, if this is not the case where no positive echo the ITR can set the locator
   as unreachable.  When traffic flow is returned.

   {{Suggestion by editors: remove next paragraph }}

   (The last unidirectional or when the ETR
   receiving the traffic is not the first choice, same as due to the large fan-out
   expected of LISP router, reliance on ITR that transmits it as a sole mechanism would
   produce a fair amount of overhead.)

17.  Acknowledgments
   back, additional mechanisms are required.

   RLOC-probing: This document was initiated by Noel Chiappa, and much of the core
   philosophy came from him.  We acknowledge the important contributions
   he has made is an active probing algorithm where ITRs send
   probes to specific locators, this work effectively probes both the locator
   and thank him for his past efforts.

   The author would like to start by thanking all the members of path.  In particular this is done by sending a Map-Request
   (with certain flags activated) on the
   core LISP group for their willingness to allow him to add himself to
   their effort, and for their enthusiasm for whatever assistance he has
   been able to provide.

   He would also like to thank (in alphabetical order) Michiel Blokzijl,
   Peter Chiappa, Vina Ermagan, Dino Farinacci, Vince Fuller and
   Vasileios Lakafosis for their review of, data-plane and helpful suggestions for,
   this document.  (If I have missed anyone waiting in this list, I apologize
   most profusely.)
   A special thank you goes to Joel Halpern, who almost invariably, when
   asked, promptly returned comments on intermediate versions of this
   document.  Grateful thanks go
   return a Map-Reply, also to Darrel Lewis for his help with
   material sent on non-Internet uses the data-plane.  The active nature
   of LISP, and to Dino Farinacci and
   Vince Fuller for answering detailed questions about some obscure LISP
   topics.

   A final thanks is due RLOC-probing provides an effective mechanism to John Wrocklawski for the author's
   organizational affiliation, and determine
   reachability and, in case of failure, switching to Vince Fuller for help with XML.
   This memo was created using a different
   locator.  Furthermore the xml2rfc tool.

   I would like to dedicate this document to mechanism also provides useful RTT
   estimates of the memory delay of my parents,
   who gave me so much, and whom I the path that can no longer thank in person, as I
   would have so much liked to be able to.

18.  IANA Considerations

   This document makes no request used by other network
   algorithms.

   Additionally, LISP also recommends inferring reachability of the IANA.

19.  Security Considerations

   This memo does not define any protocol and therefore creates no new
   security issues.

20.  References

20.1.  Normative References

   [AFI]      IANA, , "Address Family Indicators (AFIs)",
              http://www.iana.org/assignments/address-family-numbers ,
              January 2011.

   [I-D.ermagan-lisp-nat-traversal]
              Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino,
              F., and C. White, "NAT traversal for LISP", draft-ermagan-
              lisp-nat-traversal-05 (work in progress), February 2014.

   [I-D.farinacci-lisp-te]
              Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic
              Engineering Use-Cases", draft-farinacci-lisp-te-06 (work
              in progress), March 2014.

   [I-D.ietf-lisp-ddt]
              Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
              Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in
              progress), March 2013.

   [I-D.ietf-lisp-lcaf]
              Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
              Address Format (LCAF)", draft-ietf-lisp-lcaf-05 (work locators
   by using information provided by the underlay, in
              progress), May 2014.

   [I-D.ietf-lisp-perspective]
              Chiappa, J., "An Architectural Perspective on particular:

   ICMP signaling: The LISP underlay -the current Internet- uses the
   ICMP protocol to signal unreachability (among other things).  LISP
              Location-Identity Separation System", draft-ietf-lisp-
              perspective-00 (work in progress), February 2013.

   [I-D.ietf-lisp-sec]
              Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
              Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-06
              (work in progress), April 2014.

   [I-D.ietf-lisp-threats]
              Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
              Analysis", draft-ietf-lisp-threats-10 (work in progress),
              July 2014.

   [I-D.meyer-lisp-mn]
              Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
              Mobile Node", draft-meyer-lisp-mn-10 (work in progress),
              January 2014.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830, January
              2013.

   [RFC6831]  Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
              Locator/ID Separation Protocol (LISP) for Multicast
              Environments", RFC 6831, January 2013.

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

   [RFC6833]  Fuller, V. and D. Farinacci, "Locator/ID Separation
              Protocol (LISP) Map-Server Interface", RFC 6833, January
              2013.

   [RFC6834]  Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
              Separation Protocol (LISP) Map-Versioning", RFC 6834,
              January 2013.

   [RFC7215]  Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
              Pascual, J.,
   can take advantage of this and D. Lewis, "Locator/Identifier Separation
              Protocol (LISP) the reception of a ICMP Network Element Deployment
              Considerations", RFC 7215, April 2014.

20.2.  Informative References

   [Atkinson]
              R. Atkinson, , "Revised draft proposed definitions", RRG
              list message, Message-Id: 808E6500-97B4-4107- 8A2F-
              36BC913BE196@extremenetworks.com, 11 June 2007,
              http://www.ietf.org/mail-archive/web/ram/current/
              msg01470.html , .

   [Baran]    P. Baran, , "On Distributed Communications Networks", IEEE
              Transactions on Communications Systems Vol.  CS-12 No. 1,
              pp. 1-9 , March 1964.

   [Bibliography]
              J.N. Chiappa, , "LISP (Location/Identity Separation
              Protocol) Bibliography",
              http://www.chiappa.net/~jnc/tech/lisp/LISPbiblio.html ,
              July 2013.

   [Chiappa]  J.N. Chiappa, , "Endpoints
   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.

   Underlay routing: Both BGP and Endpoint Names: A Proposed
              Enhancement 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.

3.3.  ETR Synchronization

   All the ETRs that are authoritative to a particular EID-prefix must
   announce the Internet Architecture", Personal draft
              (work in progress), 1999,
              http://www.chiappa.net/~jnc/tech/endpoints.txt , 1999.

   [Clark]    D. D. Clark, , "The Design Philosophy same mapping to the requesters, this means that ETRs
   must be aware of the DARPA
              Internet Protocols", Proceedings status of the Symposium on
              Communications Architectures and Protocols SIGCOMM '88',
              pp. 106-114 , 1988.

   [CorasBGP]
              F. Coras, D. Saucez, L. Jakab, A. Cabellos-Aparicio, and
              J. Domingo-Pascual, , "Implementing a BGP-free ISP Core
              with LISP", Proceedings RLOCs of the Global Communications
              Conference (GlobeCom), IEEE, pp. 2772-2778 , December
              2012.

   [CorasCache]
              J. Kim, L. Iannone, and A. Feldmann, , "On remaining ETRs.  This
   is known as ETR synchronization.

   At the Cost time of
              Caching Locator/ID Mappings", Proceedings 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

3.4.  MTU Handling

   Since LISP encapsulates packets it requires dealing with packets that
   exceed the MTU of the 10th
              International IFIP TC 6 Conference on Networking - Volume
              Part I (NETWORKING '11)', IFIP, pp. 367-378 , May 2011.

   [Future]   J.N. Chiappa, , "Potential Long-Term Developments With path between the
              LISP System", draft-chiappa-lisp-evolution-00 (work in
              progress) (NOT EXISTING) , October 2012.

   [Heart]    F. E. Heart, R. E. Kahn, S. M. Ornstein, W. R. Crowther, ITR and D. C. Walden, , "The Interface Message Processor for the ARPA Computer Network", Proceedings AFIPS SJCC, Vol.
              36, pp. 551-567 , 1970.

   [I-D.farinacci-lisp]
              Farinacci, D., "Locator/ID Separation Protocol (LISP)",
              draft-farinacci-lisp-00 (work in progress), January 2007.

   [IEN19]    J. F. Shoch, , "Inter-Network Naming, Addressing, and
              Routing", IEN (Internet Experiment Note) 19 , January
              1978.

   [Iannone]  L. Iannone and O. Bonaventure, , "On ETR.  Specifically
   LISP defienes two mechanisms:

   Stateless:  With this mechanism ITRs fragment packets that are too
      big, typically reassembly is performed at the Cost of Caching
              Locator/ID Mappings", Proceedings destination host.

   Stateful:  With this mechanism ITRs keep track of the 3rd International
              Conference on emerging Networking EXperiments and
              Technologies (CoNEXT'07)', ACM, pp. 1-12 , December 2007.

   [Improvements]
              J.N. Chiappa, , "An Overview MTU of On-Going Improvements to the LISP Location-Identity Separation System", draft-
              chiappa-lisp-improvements-00 (work in progress) (NOT
              EXISTING) , September 2013.

   [Kim]      L. Iannone and O. Bonaventure, , "A Deep Dive Into
      paths towards the destination locators by parsing the ICMP Too Big
      packets sent by intermediate routers.

   In both cases if the
              LISP Cache and What ISPs Should Know About It",
              Proceedings of packet cannot be framgneted (IPv4 with DF=1 or
   IPv6) then the 3rd International Conference on
              emerging Networking EXperiments and Technologies
              (CoNEXT'07)', ACM, pp. 1-12 , December 2007.

   [LISP-TREE]
              L. Jakab, A. Cabellos-Aparicio, F. Coras, D. Saucez, ITR drops it and
              O. Bonaventure, , "LISP-TREE: A DNS Hierarchy replies with a ICMP Too Big message
   to Support the source.

4.  Mobility

   LISP Mapping System", IEEE Journal on Selected Areas
              in Communications', Vol. 28, No.  8, pp. 1332-1343 ,
              October 2010.

   [NIC8246]  A. McKenzie and J. Postel, , "Host-to-Host Protocol for
              the ARPANET", NIC 8246, Network Information Center, SRI
              International, Menlo Park, CA , October 1977.

   [NSAP]     International Organization for Standardization, ,
              "Information Processing Systems - Open Systems
              Interconnection - Basic Reference Model", ISO Standard
              7489.1984 , 1984.

   [RFC0826]  Plummer, D., "Ethernet Address Resolution Protocol: Or
              converting network protocol addresses can also be used to 48.bit Ethernet enable mobility of devices not located in
   LISP networks.  The problem with mobility of such devices is that
   their IP address for transmission changes whenever they change location, interrupting
   so flows.

   To enable mobility on Ethernet hardware", STD 37,
              RFC 826, November 1982.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1498]  Saltzer, J., "On such devices, the Naming and Binding of Network
              Destinations", RFC 1498, August 1993.

   [RFC1631]  Egevang, K. and P. Francis, "The IP Network Address
              Translator (NAT)", RFC 1631, May 1994.

   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers", RFC
              1812, June 1995.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets", BCP
              5, RFC 1918, February 1996.

   [RFC1992]  Castineyra, I., Chiappa, N., and M. Steenstrup, "The
              Nimrod Routing Architecture", RFC 1992, August 1996.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP", RFC
              3168, September 2001.

   [RFC3170]  Quinn, B. and K. Almeroth, "IP Multicast Applications:
              Challenges and Solutions", RFC 3170, September 2001.

   [RFC3272]  Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X.
              Xiao, "Overview and Principles of Internet Traffic
              Engineering", RFC 3272, May 2002.

   [RFC4026]  Andersson, L. and T. Madsen, "Provider Provisioned Virtual
              Private Network (VPN) Terminology", RFC 4026, March 2005.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements", RFC
              4033, March 2005.

   [RFC4107]  Bellovin, S. and R. Housley, "Guidelines for Cryptographic
              Key Management", BCP 107, RFC 4107, June 2005.

   [RFC4116]  Abley, J., Lindqvist, K., Davies, E., Black, B., and V.
              Gill, "IPv4 Multihoming Practices and Limitations", RFC
              4116, July 2005.

   [RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast
              Services", BCP 126, RFC 4786, December 2006.

   [RFC4984]  Meyer, D., Zhang, L., and K. Fall, "Report device can implement the xTR
   functionality where the IP address presented to applications is an
   EID that never changes while the IP address obtained from the IAB
              Workshop network
   is used by the xTR as RLOC.  Packets are then transported on Routing and Addressing", RFC 4984, September
              2007.

   [RFC5110]  Savola, P., "Overview of the Internet Multicast Routing
              Architecture", RFC 5110, January 2008.

   [RFC5887]  Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
              Still Needs Work", RFC 5887, May 2010.

   [RFC6115]  Li, T., "Recommendation for a Routing Architecture", RFC
              6115, February 2011.

   [RFC6836]  Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol Alternative Logical
              Topology (LISP+ALT)", RFC 6836, January 2013.

   [Saltzer]  J. H. Saltzer, D. P. Reed, and D. D. Clark, , "End-To-End
              Arguments in System Design", ACM TOCS, Vol 2, No. 4, pp
              277-288 , November 1984.

   [Saucez]   D. Saucez, L. Iannone, and B. Donnet, , "A First
              Measurement Look
   network using the IP address assigned to the device by the visited
   network while at the Deployment and Evolution application level IP addresses remain
   independent of the
              Locator/ID Separation Protocol", ACM SIGCOMM Computer
              Communication Review', Vol. 43 No. 2, pp.  37-43 , April
              2013.

Appendix A.  Glossary/Definition location of Terms

   {{Suggestion by editors: remove the device.

   Whenever the device changes of RLOC, the ITR updates the RLOC of its
   local mapping and use those from RFCs instead }}

   o  EID, Enpoint Identifier: Originally defined as registers it to its Map-Server.  To avoid the need
   of a name for an
      endpoint, one with purely identity semantics, and globally unique,
      and home gateway, the ITR also indicates the RLOC change to all
   remote devices that have ongoing communications with syntax the device that
   moved.  The combination of relatively short fixed length.  It both methods ensures the scalability of
   the system as signalling is used strictly limited the Map-Server and to
   hosts with which communications are ongoing.

5.  Multicast

   LISP also supports multicast environments, the operational changes
   required to the multicast protocols are documented in [RFC6831].

   In such scenarios, LISP creates multicast state both at the core and
   at the sites (both source and receiver).  In order to create
   multicast state at the sites, LISP work 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 mean the identifier RLOC of a node; it is the input to
      an EID->RLOC lookup in ITR
   servicing the mapping system; it source.  An simplified sequence is usually an IP
      address.  The source and destination addresses of the innermost
      header in shown below:

   1.  An end-host that belongs to a LISP packet are usually EIDs.

   o  RLOC, Routing Locator: site transmits a LISP-specific term meaning PIM Join/
       Prune message (S-EID,G) to join a multicast group.

   2.  The join message flows to the locator
      associated with an entity identified by an EID; as such, it is
      often ETR, upon reception the output of an EID->RLOC lookup in ETR builds
       two join messages, the mapping system; it
      is usually an IP address, and first one unicast LISP-encapsulates the
       original join message towards the RLOC of an ETR.  The the ITR servicing the
       source.  This message creates multicast state at the source and site.
       The second join message contains as destination addresses address the RLOC
       of the outermost header in a LISP packet are
      usually RLOCs.

   o  ITR, Ingress Tunnel Router: a LISP router ITR servicing the source (S-RLOC, G) and creates multicast
       state at the border of a LISP
      site which takes user core.

   3.  Multicast data packets sent to it originated by the source (S-EID, G) flow
       from inside the LISP
      site, encapsulates in a LISP header, source to the ITR.  The ITR LISP-encapsulates the
       multicast packets, the outter header includes its own RLOC as the
       source (S-RLOC) and then sends them across the Internet to an ETR; in other words, original multicast group address (G) as
       the start of a tunnel from destination.  Please note that multicast group address are
       logical and are not resolved by the ITR to an ETR.

   o  ETR: Egress Tunnel Router: a LISP router at mapping system.  Then the border of a LISP
      site which
       multicast packet is transmitted through the core towards the
       receiving ETRs that decapsulates user the packets which arrive at it
      encapsulated in a LISP header, and sends them on towards their
      ultimate destination; in other words, the end of using
       the tunnel from
      an ITR receiver's site multicast state.

6.  Security

   LISP uses a pull architecture to learn mappings.  While in a push
   system, the ETR.

   o  Neighbour ETR: Although an ITR and ETR may be separated by many
      actual physical hops, at the LISP level, they are direct
      neighbours; so any ETR which an ITR sends traffic state necessary to forward packets is a
      neighbour ETR learned
   independently of that ITR.

   o  xTR: An xTR refers to the traffic itself, with a LISP router which functions both as an ITR pull architecture, the
   system becomes reactive and an ETR (which is typical), when data-plane events (e.g., the discussion involves arrival of a
   packet
      flows in both directions through the router, which results in it
      alternately functioning as an ITR and then as for an ETR.

   o  Reachable; Reachability; Neighbour ETR Reachability: The ability unknown destination) may trigger control-plane events.
   This on-demand learning of an ITR to mappings provides many advantages as
   discussed above but may also affect the way security must be able to send packets to a neighbour ETR, or
   envisioned.

   Usually, the
      property data-plane is implemented in the fast path of an ITR routers to be able
   provide high performance forwarding capabilities while the control-
   plane features are implemented in the slow path to send such packets.

   o  Liveness: Whether offer high
   flexibility and a LISP node performance gap of any kind is up and operating, or
      not; or the property several order of a LISP node to magnitude can
   be in such a state.

   o  MR, Map Resolver: A LISP node to which ITRs send requests for
      mappings.

   o  MS, Map Server: A LISP node with which ETRs register mappings, to
      indicate their availability to handle incoming traffic to observed between the EIDs
      covered in those mappings.

   o  Mapping System: The entire ensemble of data slow and mechanisms which
      allow clients - usually ITRs - the fast paths.  As a consequence,
   the way data-plane events are notified to find mappings (from EIDs the control-plane must be
   though carefully so to
      RLOCs).  It includes both not overload the mapping database, slow path and also
      everything rate limiting
   should be used as specified in [RFC6830].

   Care must also been taken so to gain access to it - the MRs, not overload the indexing sub-
      system, etc.

   o  Mapping Database: The term mapping database refers system
   (i.e., the control plane infrastructure) as the operations to be
   performed by the entire
      collection of EID-to-RLOC mappings spread throughout mapping system may be more complex than those on the entire
      LISP system.  It is a subset
   data-plane, for that reason [RFC6830] recommends to rate limit the
   sending of messages to the mapping system.

   o  Mapping Cache: A collection of copies of EID-to-RLOC mappings
      retained in an ITR; not

   To improve resiliency and reduce the entire mapping database, but just overall number of messages
   exchanged, LISP offers the
      subset possibility to leak control informations,
   such as reachabilty of it locators, directly into data plane packets.
   In environments that an ITR needs in order to are not fully trusted, control informations
   gleaned from data-plane packets should be able to properly
      handle the user data traffic which is flowing through it.

   o  Indexing Sub-system: verified before using them.

   Mappings are the entire ensemble centrepiece of data LISP and mechanisms
      which allows MRs all precautions must be
   taken to find out which ETR(s) hold the mapping for a
      given EID avoid them to be manipulated or EID block.  It includes both the data on namespace
      delegations, as well as the nodes which hold misused by malicious
   entities.  Using trustable Map-Server that data, strictly respect [RFC6833]
   and the
      protocols used to interact with those nodes.

   o  DDT Vertex; Vertex: a node (in the graph theory sense of the term)
      in the (abstract) LISP namespace delegation hierarchy.

   o  DDT Server: an actual machine, which one can send packets to, in
      the DDT server hierarchy - which is, hopefully, lightweight authentication mechanism proposed by LISP-Sec
   [I-D.ietf-lisp-sec] is a one-to-one
      projection of possibility to reduce the LISP address delegation hierarchy (although of
      course a single DDT vertex risk.  In more
   critical environments, stronger authentication may turn into several sibling servers).
      Some documents refer to these as DDT nodes but this document does
      not use that term, have to prevent confusion be used.

   Packets are transported encapsulated with DDT vertex.

   o  PITR: Proxy ITR; LISP meaning that devices
   on the path between an ITR which is used for interworking between a
      LISP-speaking node or site, (or PITR) and legacy nodes or sites; in general,
      it acts like a normal ITR, but does so on behalf of LISP nodes
      which are receiving packets from a legacy node.

   o  PETR: Proxy ETR; an ETR which is used for interworking between a
      LISP-speaking node or site, and legacy nodes or sites; in general,
      it acts like a normal ETR, but does so on behalf (or PETR) cannot
   correctly inspect the content of LISP nodes
      which are sending packets unless they implement
   methods to a legacy node.

   o  RTR: Re-encapsulating Tunnel Router; a data plane 'anchor point'
      used strip the headers added by LISP.  Similarly, mappings
   enable triangular routing (i.e., packets of a LISP-speaking node to perform functions flow cross different
   border routers depending on their direction) which means that
   intermediate boxes may have incomplete view on the traffic they
   inspect or manipulate.

   More details about security implications of LISP can only be be performed found in
   [I-D.ietf-lisp-threats].

7.  Use Cases

7.1.  Traffic Engineering

   BGP is the core of standard protocol to implement inter-domain routing.  With
   BGP, routing informations are propagated along the network and each
   autonomous system can implement its own routing policy that will
   influence the way routing information are propagated.  The direct
   consequence is that an autonomous system cannot precisely control the
   way the traffic will enter the network.  One use

   As opposed to BGP, a LISP site can strictly impose via which ETRs the
   traffic must enter the network even though the path followed to reach
   the ETR is for LISP-
      speaking node behind not under the control of the LISP site.  This fine control
   is implemented with the mappings.  When a NAT device remote site is willing to
   send and receive traffic
      through the NAT device; see

   o  Internet core: That part of to a LISP site, it retrieves the Internet in which there are no
      'default' entries in routing tables, but where mapping associated to
   the routing tables
      hold entries for every single reachable destination in EID via the
      Internet.  (Sometimes referred to colloquially as mapping system.  The mapping is sent
   directly by the DFZ, or
      'Default Free Zone'.)

Appendix B.  Other Appendices

B.1. owner of EID and is not altered by any intermediate
   network.

   A Brief History mapping associates a list of Location/Identity Separation

   It was only gradually realized RLOCs to an EID prefix.  Each RLOC
   corresponds to an interface of an ETR that is able to correctly
   forward packets to EIDs in the networking community that
   networks (especially large networks) should deal quite separately prefix.  Each RLOC is tagged with the identity a
   priority and location of a node; the distinction between weight in the
   two was more than a little hazy at first. mapping.  The ARPANET had no real acknowledgment of 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 difference load between the
   two.  [Heart][NIC8246] The early Internet also co-mingled RLOCs with the two
   ([RFC0791]), although there was recognition in same priority,
   proportionally to the early Internet
   work that there were two different things going on.  [IEN19]

   This likely resulted not just from lack of insight, but also weight value.

   As mappings are directly issued by the fact
   that extra mechanism is needed to support this separation (and in owner of the
   early days there were no resources EID and not
   altered while transmitted to spare), as well as the lack of
   need for remote site, it in the smaller networks of offers highly
   flexible incoming inter-domain traffic engineering with even the time.  (It is
   possibility for a truism of
   system design that small systems can get away site to issue a different mapping for each remote
   site, implementing so precise routing policies.

7.2.  LISP for IPv6 Transition

   LISP encapsulations permits to transport packets using EIDs from a
   given address family (e.g., IPv6) with doing two things packets with one mechanism, in a way that usually will not work when the
   system gets much larger.)

   The ISO protocol architecture took steps in this direction [NSAP],
   but addresses
   belonging to the Internet community the necessity another address family (e.g., IPv4).  The absence of a clear separation was
   definitively shown by Saltzer.  [RFC1498] Later work expanded on
   Saltzer's, and tied his separation concepts into
   correlation between the fate-sharing
   concepts of Clark.  [Clark], [Chiappa]

   The separation address family of location RLOCs and identity is a step which has recently
   been identified by the IRTF as EIDs makes LISP a critically necessary evolutionary
   architectural step for
   candidate to ease the Internet.  [RFC6115] However, it has taken
   quite some time for this requirement transition to IPv4.

   For example, two IPv6-only data centers could be generally accepted by interconnected via
   the
   Internet engineering community at large, although it seems that this
   may finally be happening.

   Unfortunately, although legacy IPv4 Internet.  If their border routers are LISP capable,
   sending packets between the development data center is done without any form of
   translation as the native IPv6 presented a golden
   opportunity to learn from this particular failing of IPv4, that
   design failed to recognize packets (in the need for separation of location EID space) will be
   LISP encapsulated and
   identity.

B.2.  A Brief History of transmitted over the LISP Project

   {{Suggestion IPv4 legacy Internet by editors: remove that makes no sense in this document
   }}

   The
   the mean of IPv4 RLOCs.

7.3.  LISP system for separation of location and identity resulted from Network Virtualization

   It is nowadays common to operate several virtual networks over the discussions
   same physical infrastructure.  The current approach usually rely on
   BGP/MPLS VPNs, where BGP is used to exchange routing information and
   MPLS to segregate packets of this topic at the Amsterdam IAB Routing different logical networks.  This
   functionality could be achieved with LISP where the mappings and
   Addressing Workshop, which took place in October 2006.  [RFC4984]

   A small group the
   mapping system are used instead of like-minded personnel from various scattered
   locations within Cisco, spontaneously formed immediately after that
   workshop, BGP and the LISP encapsulation is
   used to work on an idea that came out of informal discussions at replace MPLS.

   In virtual networks, it is essential to distinguish to which virtual
   network a packet belongs and tags or labels are used for that
   purpose.  With LISP, the workshop.  The first Internet-Draft on LISP appeared in January,
   2007, along distinction can be made with the Instance ID
   field.  When an ITR encapsulates a LISP mailing list at packet from a particular virtual
   network (e.g., known via the IETF.
   [I-D.farinacci-lisp]

   Trial implementations started at that time, VRF or VLAN), it tags the encapsulated
   packet with initial trial
   deployments underway since June 2007; the results of early experience
   have been fed back into Instance ID corresponding to 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 virtual network of changes and
   updates.

   LISP transitioned from
   the packet.  When an IRTF activity to ETR receives a packet tagged with an IETF WG in March 2009,
   and after numerous revisions, Instance ID
   it uses the basic specifications moved Instance ID to
   becoming RFCs at determine how to threat the start packet.

   Appart from the simplicity of 2013 (although work to expand and
   improve it, and find new uses managing mappings, the advantage of
   using LISP for it, continues, and undoubtly will virtual network is that it does not impose any
   requirement on the underlying network, except running IP.

7.4.  LISP for a long time Virtual Machine Mobility in Data Centers

   A way to come).

B.3.  Old LISP 'Models'

   LISP, enable seamless virtual machine mobility in data center is
   to conceive the datacenter backbone as initilly conceived, had a number of potential operating
   modes, named 'models'.  Although they are now obsolete, one
   occasionally sees mention of them, so they the RLOC space and the
   subnetworks where servers are briefly described
   here.

   o hosted as forming the EID space.  A
   LISP 1: EIDs all appear in router is placed at the normal routing border between the backbone and forwarding
      tables each
   sub-network.  When a virtual machine is moved to another subnetwork,
   it can (temporarily) keep the address of the network (i.e. they are 'routable');this property is
      used sub-network it was
   hosted before the move so to 'bootstrap' operation, by using this allow ongoing communications to load EID->RLOC
      mappings.  Packets were sent subsist.
   When a subnetwork detects the presence of a host with an address that
   does not belong to the EID as subnetwork (e.g., via a message sent by the destination in
   hypervisor), the outer wrapper; when LISP router of the new subnetwork registers the IP
   address of the virtual machine as an ETR saw such a packet, it would send a
      Map-Reply EID to the source ITR, giving Map-Server of the full mapping.

   o
   subnetwork and associates its own address as RLOC.

   To inform the other LISP 1.5: Similar routers that the machine moved and where,
   and then to LISP 1, but avoid detours via the routability of EIDs happens initial subnetwork, every Map-
   Server can listen on a separate network.

   o  LISP 2: EIDs are not routable; EID->RLOC mappings are available
      from predefined multicast address that is used as
   source address for Map-Register.  As a result, the Map-Notify sent
   back by the Map-Server will be received by all the DNS.

   o LISP 3: EIDs are routers that
   hence automatically learn the new location of the virtual machine.

8.  Security Considerations

   This document does not routable; specify any protocol or operational practices
   and hence, does not have any security considerations.

9.  IANA Considerations

   This memo includes no request 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, IANA.

10.  Acknowledgements

   To Do.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in which all mappings were distributed RFCs to all ITRs, Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4116]  Abley, J., Lindqvist, K., Davies, E., Black, B., and a 'pull' system in which ITRs load the mappings they need, as
      needed.

B.4.  The ALT Mapping Indexing Sub-system

   LISP initially used an indexing sub-system called ALT.  [RFC6836]ALT
   re-purposed a number of existing mechanisms to provide an indexing
   system, which allowed an experimental LISP initial deployment to
   become operational without having to write a lot of code, ALT was
   relatively easily constructed V.
              Gill, "IPv4 Multihoming Practices and Limitations", RFC
              4116, July 2005.

   [RFC4984]  Meyer, D., Zhang, L., and K. Fall, "Report from basically unmodified existing
   mechanisms; it used BGP running over virtual tunnels using GRE.

   ALT proved to have a number of issues which made it unsuitable the IAB
              Workshop on Routing and Addressing", RFC 4984, September
              2007.

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830, January
              2013.

   [RFC6831]  Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
              Locator/ID Separation Protocol (LISP) for Multicast
              Environments", RFC 6831, January 2013.

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

   [RFC6833]  Fuller, V. and D. Farinacci, "Locator/ID Separation
              Protocol (LISP) Map-Server Interface", RFC 6833, January
              2013.

   [RFC6834]  Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
              Separation Protocol (LISP) Map-Versioning", RFC 6834,
              January 2013.

   [RFC6835]  Farinacci, D. and D. Meyer, "The Locator/ID Separation
              Protocol Internet Groper (LIG)", RFC 6835, January 2013.

   [RFC6836]  Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol Alternative Logical
              Topology (LISP+ALT)", RFC 6836, January 2013.

   [RFC6935]  Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
              UDP Checksums for
   large-scale use, Tunneled Packets", RFC 6935, April 2013.

   [RFC6936]  Fairhurst, G. and it has now been superseded by DDT.  A complete
   list of these is not possible here, but M. Westerlund, "Applicability Statement
              for the issues mostly were Use of two
   kinds: technical issues which would have arisen at large scale, IPv6 UDP Datagrams with Zero Checksums",
              RFC 6936, April 2013.

   [RFC7215]  Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
              Pascual, J., and
   practical operational issues which appeared even in the experimental
   deployment.

   The biggest operational issues was the effort involved in
   configuring, D. Lewis, "Locator/Identifier Separation
              Protocol (LISP) Network Element Deployment
              Considerations", RFC 7215, April 2014.

11.2.  Informative References

   [Chiappa]  Chiappa, J., "Endpoints and maintain Endpoint names: A Propose
              Enhancement to the configuration, Internet Architecture,
              http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt", 1999.

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

   [DFZ]      Huston, Geoff., "Growth of the virtual tunnels
   over which ALT ran (including assigning the addresses for the ends,
   etc); also, managing the multiple disjoint routing tables required
   was difficult BGP Table - 1994 to Present
              http://bgp.potaroo.net/", August 2013.

   [I-D.cheng-lisp-shdht]
              Cheng, L. and confusing (even for those who were very familiar
   with ALT).  Debugging faults J. Wang, "LISP Single-Hop DHT Mapping
              Overlay", draft-cheng-lisp-shdht-04 (work in ALT was also difficult; progress),
              July 2013.

   [I-D.ermagan-lisp-nat-traversal]
              Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino,
              F., and finally,
   because of ALT's nature, administrative issues (who pays C. White, "NAT traversal for what,
   who controls what, etc) were problematic.

   However, ALT would have had significant technical issues had it been
   used at a larger scale.

   The most severe (and fundamental) issue was that since all traffic on
   the ALT had LISP", draft-ermagan-
              lisp-nat-traversal-03 (work in progress), March 2013.

   [I-D.ietf-lisp-ddt]
              Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
              Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in
              progress), March 2013.

   [I-D.ietf-lisp-lcaf]
              Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
              Address Format (LCAF)", draft-ietf-lisp-lcaf-05 (work in
              progress), May 2014.

   [I-D.ietf-lisp-sec]
              Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
              Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-06
              (work in progress), April 2014.

   [I-D.ietf-lisp-threats]
              Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
              Analysis", draft-ietf-lisp-threats-10 (work in progress),
              July 2014.

   [I-D.lear-lisp-nerd]
              Lear, E., "NERD: A Not-so-novel EID to transit the 'root' of the ALT tree, those locations
   would have become traffic 'hot-spots' RLOC Database",
              draft-lear-lisp-nerd-08 (work in progress), March 2010.

   [I-D.mathy-lisp-dht]
              Mathy, L., Iannone, L., and O. Bonaventure, ""LISP-DHT:
              Towards a large scale deployment.

   In addition, optimal performance would have required that the ALT
   overall topology be restrained DHT to follow the EID namespace
   allocation; however, it was not clear that this was feasible.  In any
   event, even optimal performance was still less than that map identifiers onto locators" draft-
              mathy-lisp-dht-00 (work in
   alternatives.  The ALT was also very vulnerable to misconfiguration.

   See [LISP-TREE] for more about these issues: the basic structure progress)", April 2008.

   [Jakab]    Jakab, L., Cabellos, A., Saucez, D., and
   operation of DDT is identical O. Bonaventure,
              "LISP-TREE: A DNS Hierarchy to that of TREE, so Support the conclusions
   drawn there about TREE's superiority to ALT apply equally to DDT.

   In particular, LISP Mapping
              System, IEEE Journal on Selected Areas in Communications,
              vol. 28, no. 8, pp. 1332-1343", October 2010.

   [Quoitin]  Quoitin, B., Iannone, L., Launois, C., and O. Bonaventure,
              ""Evaluating the big advantage Benefits of DDT over the ALT, Locator/Identifier
              Separation" in performance
   terms, is that it allows MRs to interact _directly_ with distant DDT
   servers (as opposed to the ALT, which _always_ required mediation
   through intermediate servers); caching Proceedings of information about those
   distant servers allows DDT to make extremely effective use 2Nd ACM/IEEE International
              Workshop on Mobility in the Evolving Internet
              Architecture", 2007.

Appendix A.  A Brief History of this
   capability. Location/Identity Separation

   The ALT did have some useful properties which its replacement, DDT,
   did not, e.g. the ability to forward data directly to the
   destination, over the ALT, when no mapping was available yet LISP system for the
   destination.  However, these were minor, separation of location and heavily outweighed by
   its problems.

   A recent study, [Saucez], measured actual resolution times in the
   deployed LISP network during the changeover identity resulted from ALT to DDT, allowing
   direct comparison of
   the performance discussions of this topic at the two systems.  The study Amsterdam IAB Routing and
   Addressing Workshop, which took measurements from a variety of locations place in the Internet, with
   respect to a number October 2006 [RFC4984].

   A small group of different target EIDs.  The results indicate
   that the performance was almost identical; there was more variance
   with DDT (perhaps due like-minded personnel from various scattered
   locations within Cisco, spontaneously formed immediately after that
   workshop, to the effects work on an idea that came out of caching), but informal discussions at
   the greatly
   improved scalability of DDT as compared to ALT made that effect
   acceptable.

B.5.  Early NAT Support workshop.  The first mechanism used by Internet-Draft on LISP to support operation through a NAT
   device, described here, has now been superseded by the more general
   mechanism proposed appeared in [I-D.ermagan-lisp-nat-traversal].  That
   mechanism is, however, based heavily on this mechanism.  The initial
   mechanism had some serious limitations, which is why that particular
   form of it has been dropped.

   First, it only worked January,
   2007, along with some NATs, those which were configurable
   to allow inbound packet traffic to reach a configured host.  The NAT
   had to be configured to know of LISP mailing list at the ETR.

   Second, IETF.

   Trial implementations started at that time, with initial trial
   deployments underway since NATs share addresses by using ports, it was only
   possible to June 2007; the results of early experience
   have been fed back into the design in a single LISP node behind any given NAT device.
   That is because continuous, ongoing process
   over several years.  LISP expects all incoming data traffic to be on at this point represents a
   specific port, so it was not possible to have multiple ETRs behind moderately
   mature system, having undergone a
   single NAT (which normally would have only one global IP address to
   share).  Even looking at the sort host long organic series of changes and port would not necessarily
   help, because some source ITR could be sending packets
   updates.

   LISP transitioned from an IRTF activity to both ETRs,
   so packets an IETF WG in March 2009,
   and after numerous revisions, the basic specifications moved to either ETR could also have
   becoming RFCs at the identical source host/
   port.  In short, there was no way start of 2013 (although work to expand and
   improve it, and find new uses for it, continues, and undoubtly will
   for a NAT with multiple ETRs behind
   it long time to know which ETR the packet was for.

   To support operation behind a NAT, there was come).

A.1.  Old LISP Models

   LISP, as initilly conceived, had a pair number of new LISP
   control messages, potential operating
   modes, named 'models'.  Although they are now obsolete, one
   occasionally sees mention of them, so they are briefly described
   here.

   LISP Echo-Request 1:  EIDs all appear in the normal routing and Echo-Reply, which allowed forwarding tables
      of the
   ETR network (i.e. they are 'routable');this property is used to discover its temporary global address.  The Echo-Request was
   sent
      'bootstrap' operation, by using this to the configured Map-Server, and it replied load EID->RLOC mappings.
      Packets were sent with an Echo-Reply
   which included the source address from which the Echo Request was
   received (i.e. the public global address assigned to EID as the ETR by destination in the
   NAT).  The outer
      wrapper; when an ETR could then insert that address in any Map-Reply
   control messages which saw such a packet, it sent would send a Map-Reply
      to correspondent ITRs.

   Echo-Request and Echo-Reply have been replaced by Info-Request and
   Info-Reply in the replacement, [NAT-Traversal], where they perform
   very similar functions; source ITR, giving the main change is full mapping.

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

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

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

Authors' Addresses

   Albert Cabellos-Aparicio (Ed.)
   Technical University of Cabellos
   UPC-BarcelonaTech
   c/ Jordi Girona 1-3
   Barcelona, Catalonia
   C/Jordi Girona, s/n
   BARCELONA  08034
   Spain

   Email: jacabello@ac.upc.edu acabello@ac.upc.edu

   Damien Saucez (Ed.)
   INRIA
   2004 route des Lucioles BP 93
   06902
   Sophia Antipolis Cedex  06902
   France

   Email: damien.saucez@inria.fr