LISP Working Group                                         J. N. Chiappa
Internet-Draft                              Yorktown Museum of Asian Art
Intended status: Informational                          October                             July 15, 2012
Expires: April 18, 2013
Expires: January 16, 2014

                An Architecural Introduction to the LISP
                  Location-Identity Separation System
                    draft-ietf-lisp-introduction-00
                    draft-ietf-lisp-introduction-01

Abstract

   LISP is an upgrade to the architecture of the IPvN internetworking
   system, one which separates location and identity (currently
   intermingled in IPvN addresses).  This is a change which has been
   identified by the IRTF as a critically necessary evolutionary
   architectural step for the Internet.  In LISP, nodes have both a
   'locator' (a name which says _where_ in the network's connectivity
   structure the node is) and an 'identifier' (a name which serves only
   to provide a persistent handle for the node).  A node may have more
   than one locator, or its locator may change over time (e.g. if the
   node is mobile), but it keeps the same identifier.

   One of the chief novelties of LISP, compared to other proposals for
   the separation of location and identity, is its approach to deploying
   this upgrade.  (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.)  LISP aims to
   achieve the near-ubiquitous deployment necessary for maximum
   exploitation of an architectural upgrade by i) minimizing the amount
   of change needed (existing hosts and routers can operate unmodified);
   and ii) by providing significant benefits to early adopters.

   This document is an introduction to the entire LISP system, for those
   who are unfamiliar with it.  It is intended to be both easy to
   follow, and also give a fairly detailed understanding of the entire
   system.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may not be modified,
   and derivative works of it may not be created, except to format it
   for publication as an RFC or to translate it into languages other
   than English.

   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 April 18, 2013. January 16, 2014.

Copyright Notice

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

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

Table of Contents

   1.  Background  Prefaratory Note
   2.  Background
   3.  Deployment Philosophy
     2.1.
     3.1.  Economics
     2.2.
     3.2.  Maximize Re-use of Existing Mechanism
     2.3.  Self-Deployment
   3.
     3.3.  'Self-Deployment'
   4.  LISP Overview
     3.1.
     4.1.  Basic Approach
     3.2.
     4.2.  Basic Functionality
     3.3.
     4.3.  Mapping from EIDs to RLOCs
     3.4.
     4.4.  Interworking With Non-LISP-Capable Endpoints
   4.
     4.5.  Security in LISP
   5.  Initial Applications
     4.1.
     5.1.  Provider Independence
     4.2.
     5.2.  Multi-Homing
     4.3.
     5.3.  Traffic Engineering
     4.4.
     5.4.  Routing
     5.5.  Mobility
     4.5.
     5.6.  IP Version Reciprocal Traversal
     4.6.
     5.7.  Local Uses
   5.
   6.  Major Functional Subsystems
     5.1.
     6.1.  xTRs
     5.2.
       6.1.1.  Mapping Cache Performance
     6.2.  Mapping System
       5.2.1.
       6.2.1.  Mapping System Organization
       5.2.2.
       6.2.2.  Interface to the Mapping System
       5.2.3.
       6.2.3.  Indexing Subsystem
   6. Sub-system
   7.  Examples of Operation
     6.1.
     7.1.  An Ordinary Packet's Processing
     6.2.
     7.2.  A Mapping Cache Miss
   7.
   8.  Design Approach
     7.1.  Quick Implement-Test Loop
       7.1.1.  No Desk Fixes
       7.1.2.  Code Before Documentation
     7.2.  Only Fix Real Problems
     7.3.  No Theoretical Perfection
       7.3.1.  No Ocean Boiling
     7.4.  Just Enough Security
   8.
   9.  xTRs
     8.1.
     9.1.  When to Encapsulate
     8.2.
     9.2.  UDP Encapsulation Details
     8.3.
     9.3.  Header Control Channel
       8.3.1.
       9.3.1.  Mapping Versioning
       9.3.2.  Echo Nonces
       8.3.2.
       9.3.3.  Instances
     8.4.  Fragmentation
     8.5.
     9.4.  Probing
     9.5.  Mapping Lifetimes and Timeouts
     9.6.  Security of Mapping Lookups
     9.7.  Mapping Gleaning in ETRs
   9.
     9.8.  Fragmentation
   10. The Mapping System
     9.1.  The Indexing Subsystem
     9.2.
     10.1. The Mapping System Interface
       9.2.1.
       10.1.1. Map-Request Messages
       9.2.2.
       10.1.2. Map-Reply Maessages
       9.2.3. Messages
       10.1.3. Map-Register and Map-Notify Messages
       9.2.4.
     10.2. The DDT Indexing Sub-system
       10.2.1. Map-Referral Messages
     9.3.
     10.3. Reliability via Replication
     9.4.
     10.4. Security of the DDT Indexing Sub-system
     10.5. Extended Tools
     9.5.  Expected
     10.6. Performance
   10. of the Mapping System
   11. Deployment Mechanisms
     10.1.
     11.1. LISP Deployment Needs
     11.2. Internetworking Mechanism
     10.2.
     11.3. Proxy Devices
       10.2.1.
       11.3.1. PITRs
       10.2.2.
       11.3.2. PETRs
     10.3.
     11.4. LISP-NAT
     10.4. LISP and DFZ Routing
     10.5.
     11.5. Use Through NAT Devices
       10.5.1.
       11.5.1. First-Phase NAT Support
       10.5.2.
       11.5.2. Second-Phase NAT Support
   11. Current Improvements
     11.1. Mapping Versioning
     11.2. Replacement of ALT with DDT
       11.2.1. Why Not Use DNS
     11.3. Mobile Device Support
     11.4. Multicast Support
     11.5. {{Any others?}}
     11.6. LISP and DFZ Routing
       11.6.1. Long-term Possibilities
   12. Fault Discovery/Handling
     12.1. Handling Missing Mappings
     12.2. Outdated Mappings
       12.2.1. Outdated Mappings - Updated Mapping
       12.2.2. Outdated Mappings - Wrong ETR
       12.2.3. Outdated Mappings - No Longer an ETR
     12.3. Erroneous mappings Mappings
     12.4. Neighbour Liveness
     12.5. Neighbour Reachability
   13. Acknowledgments Current Improvements
     13.1. Improved NAT Support
     13.2. Mobile Device Support
     13.3. Multicast Support
     13.4. {{Any others?}}
   14. Acknowledgments
   15. IANA Considerations
   15.
   16. Security Considerations
   16.
   17. References
     16.1.
     17.1. Normative References
     16.2.
     17.2. Informative References
   Appendix A.  Glossary/Definition of Terms
   Appendix B.  Other Appendices
     B.1.  Old LISP 'Models'
     B.2.  Possible Other Appendices

1.  Background

   It has gradually been realized in the networking community that
   networks (especially large networks) should deal quite separately
   with  Prefaratory Note

   This document is the identity and location first of a node (basically, 'who' a node is,
   and 'where' it is).  At pair which, together, form what one
   would think of as the moment, in both IPv4 and IPv6, addresses
   indicate both where the named device is, as well as identify it 'architecture document' for
   purposes LISP (the
   'Location-Identity Separation Protocol').  Much of end-end communication.

   The distinction was more than a little hazy at first: the early
   Internet [RFC791], like the ARPANET before it [Heart] [NIC8246], co-
   mingled what would
   normally be in an architecture document (e.g. the two, although there was recognition architectural
   design principles used in LISP, and the early Internet
   work that there were two different things going on.  [IEN19]

   This likely resulted not just from lack design considerations behind
   various components and aspects of insight, but also the fact
   that extra mechanism LISP system) is needed to support this separation (and in the
   early days there were no resources second
   document, the 'Architectural Perspective on LISP' document.

   This 'Architectural Introduction' document is primarily intended for
   those who don't know anything about LISP, and want to spare), as well start learning
   about it.  It is intended to both be easy to follow, and also to give
   the reader a choice as to how much they wish to know about LISP.
   Reading only the lack first part(s) of
   need for it in the smaller networks document will give a good high-
   level view of the time.  (It is system; reading the complete document should
   provide a truism fairly detailed understanding of
   system design that small systems can get away with doing two things
   with one mechanism, in the entire system.

   This goal explains why the document has a way that usually will somewhat unusual structure.
   It is not work when a reference document, where all the
   system gets much larger.)

   The ISO protocol architecture took steps content on a particular
   topic is grouped in this direction [NSAP],
   but to the Internet community one place.  (That role is filled by the necessity of various
   protocol specifications.)  It starts with a clear separation was
   definitively shown by Saltzer.  [RFC1498] Later work expanded on
   Saltzer's, and tied his separation concepts into the fate-sharing
   concepts of Clark.  [Clark], [Chiappa]

   The separation very high-level view of location and identity is a step which has recently
   been identified by
   the IRTF as entire system, to provide readers with a critically necessary evolutionary
   architectural step for the Internet.  However, it has taken some time
   for this requirement mental framework to be generally accepted by help
   understand the Internet
   engineering community at large, although it seems that this may
   finally be happening.

   The LISP more detailed material which follows.  A second pass
   over the whole system for separation of location and identity resulted from then goes into more detail; finally, individual
   sub-systems are covered in still deeper detail.

   The intent is two-fold: first, the discussions of this topic at multiple passes over the Amsterdam IAB Routing and
   Addressing Workshop, which took place in October 2006.  [RFC4984]

   A small group of like-minded personnel from various scattered
   locations within Cisco, spontaneously formed immediately after that
   workshop, entire
   system, each one going into more detail, are intended to work on ease
   understanding; second, people can simply stop reading when they have
   a detailed-enough understanding for their purposes.  People who just
   want to get an idea that came out of informal discussions at how LISP works might only read the workshop.  The first Internet-Draft
   part(s), whereas people who are going to go on LISP appeared in January,
   2007, along with a LISP mailing list at and read all the IETF.  [LISP]

   Trial implementations started at that time, with initial trial
   deployments underway since June 2007;
   protocol specifications (perhaps to implement LISP) would need/want
   to read the results entire document.

   Note: This document is a descriptive document, not a protocol
   specification.  Should it differ in any detail from any of early experience
   have been fed back into the design in a continuous, ongoing process
   over several years. LISP at this point represents a moderately
   mature system, having undergone a long organic series
   protocol specification documents, they take precedence for the actual
   operation of changes and
   updates.

   LISP transitioned from an IRTF activity to an IETF WG the protocol.

2.  Background

   It has gradually been realized in March 2009, the networking community that
   networks (especially large networks) should deal quite separately
   with the identity and after numerous revisions, location of a node (basically, 'who' a node is,
   and 'where' it is).  At the basic specifications moved to
   becoming RFCs moment, in 2012 (although work to expand both IPv4 and improve IPv6, addresses
   indicate both where the named device is, as well as identify it
   continues, and undoubtly will for
   purposes of end-end communication.

   The distinction was more than a long time to come).

2.  Deployment Philosophy

   It may seem odd to cover 'deployment philosophy' little hazy at this point in
   such a document.  However first: the deployment philosophy was a major
   driver for much of early
   Internet [RFC791], like the design (to some degree ARPANET before it [Heart] [NIC8246], co-
   mingled the architecture, and
   to a very large measure, two, although there was recognition in the engineering).  So, as such an important
   motivator, it early Internet
   work that there were two different things going on.  [IEN19]

   This likely resulted not just from lack of insight, but also the fact
   that extra mechanism is very desirable for readers needed to have support this material separation (and in
   hand the
   early days there were no resources to spare), as well as they examine the design, so that design choices that may seem
   questionable at first glance can be better understood.

   Experience over the last several decades has shown that having a
   viable 'deployment model' lack of
   need for a new design is absolutely key to it in the
   success smaller networks of that design.  A new the time.  (It is a truism of
   system design may be fantastic - but if it that small systems can not or get away with doing two things
   with one mechanism, in a way that usually will not be successfully deployed (for whatever factors),
   it is useless.  This absolute primacy of a viable deployment model is
   what has lead to some painful compromises in work when the design.
   system gets much larger.)

   The extreme focus on a viable deployment scheme is one of ISO protocol architecture took steps in this direction [NSAP],
   but to the
   novelties Internet community the necessity of LISP.

2.1.  Economics

   The key factor in successful adoption, as a clear separation was
   definitively shown by recent experience
   in Saltzer.  [RFC1498] Later work expanded on
   Saltzer's, and tied his separation concepts into the Internet - fate-sharing
   concepts of Clark.  [Clark], [Chiappa]

   The separation of location and little appreciated to begin with, some decades
   back - identity is economics: does the new design have benefits a step which outweigh
   its costs.

   More importantly, this balance needs to hold has recently
   been identified by the IRTF as a critically necessary evolutionary
   architectural step for early adopters -
   because if they do not receive benefits to their adoption, the sphere
   of earliest adopters will not expand, and Internet.  However, it will never get to
   widespread deployment.  One might have the world's best clean-slate
   design, but if it does not have a deployment plan which is
   economically feasible, it's just a mildly interesting piece of paper.

   This is particularly true of architectural enhancements, which are
   far less likely has taken some time
   for this requirement to be an addition which one can 'bolt onto generally accepted by the side' Internet
   engineering community at large, although it seems that this may
   finally be happening.  [RFC6115]

   The LISP system for separation of existing mechanisms, location and often offer their greatest benefits only
   when widely (or ubiquitously) deployed.

   Maximizing the cost-benefit ratio obviously has two aspects.  First,
   on identity resulted from
   the cost side, by making discussions of this topic at the design as inexpensive as possible, Amsterdam IAB Routing and
   Addressing Workshop, which means took place in part making the deployment as easy as possible.
   Second, October 2006.  [RFC4984]

   A small group of like-minded personnel from various scattered
   locations within Cisco, spontaneously formed immediately after that
   workshop, to work on an idea that came out of informal discussions at
   the benefit side, by providing many new capabilities,
   which is best done not by loading workshop.  The first Internet-Draft on LISP appeared in January,
   2007, along with a LISP mailing list at the design up IETF.  [LISP0]

   Trial implementations started at that time, with lots of features
   or options (which adds complexity), but by making initial trial
   deployments underway since June 2007; the addition
   powerful through deeper flexibility.  We believe LISP has met both of
   these goals.

2.2.  Maximize Re-use of Existing Mechanism

   One key part results of reducing early experience
   have been fed back into the cost of a new design is to absolutely
   minimize the amount in a continuous, ongoing process
   over several years.  LISP at this point represents a moderately
   mature system, having undergone a long organic series of change _required_ changes and
   updates.

   LISP transitioned from an IRTF activity to existing, deployed,
   devices: an IETF WG in March 2009,
   and after numerous revisions, the fewer devices need basic specifications moved to be changed,
   becoming RFCs in 2012 (although work to expand and the smaller the
   change improve it
   continues, and undoubtly will for a long time to those that do, the lower come).

3.  Deployment Philosophy

   It may seem odd to cover 'deployment philosophy' at this point in
   such a document.  However the pain (and thus deployment philosophy was a major
   driver for much of the greater design (to some degree 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 architecture, and
   to make their a very substantial costs
   worthwhile.

   It large measure, the engineering).  So, as such an important
   motivator, it is very desirable for this reason that LISP, in most cases, initially requires no
   changes readers to devices have this material in
   hand as they examine the Internet (both hosts and routers), and also
   initially reuses, whereever possible, existing protocols (IPv4
   [RFC791] and IPv6 [RFC2460]).  The 'initially' must design, so that design choices that may seem
   questionable at first glance can be stressed -
   careful attention has also long been paid to better understood.

   Experience over the long-term future
   (see [Future]), and larger changes become feasible as deployment
   succeeds.

2.3.  Self-Deployment

   LISP has deliberately employed last several decades has shown that having a rather different deployment model,
   which we might call 'self-deployment'; it does not require
   viable 'deployment model' for a huge
   push to get it deployed, rather, it new design is hoped absolutely key to the
   success of that once people see design.  A new design may be fantastic - but if it
   and realize they
   can easily make good use of it _on their own_ (i.e.
   without requiring adoption by others), it not or will 'deploy itself' (hence
   the name of the approach).

   One can liken the problem not be successfully deployed (for whatever factors),
   it is useless.  This absolute primacy of deploying new systems in this way to
   rolling a snowball down a hill: unless one starts with a big enough
   initial snowball, and finds a hill of the right steepness (i.e. the
   right path for it to travel, once it starts moving), one's snowball viable deployment model is not going to go anywhere on its own.  However, if one
   what has picked
   one's spot correctly, little additional work is needed - just stand
   back and watch it go.

3.  LISP Overview

   LISP is an incrementally deployable architectural upgrade lead to some painful compromises in the
   existing Internet infrastructure, design.

   The extreme focus on a viable deployment scheme is one which provides separation of
   location and identity. the
   novelties of LISP.

3.1.  Economics

   The separation is usually not perfect, for
   reasons which are driven key factor in successful adoption, as shown by the deployment philosophy (above), and
   explored recent experience
   in a little more detail elsewhere (in [Architecture],
   Section "Namespaces-EIDs-Residual").

   LISP separates the functions of location Internet - and identity, current
   intermingled in IPvN addresses.  (This document uses little appreciated to begin with, some decades
   back - is economics: does the meaning for
   'address' proposed in [Atkinson], i.e. a name with mixed location and
   identity semantics.)

3.1.  Basic Approach

   In LISP, nodes new design have both a 'locator' (a name benefits which says _where_ in
   the network's connectivity structure outweigh
   its costs.

   More importantly, this balance needs to hold for early adopters -
   because if they do not receive benefits to their adoption, the node is), called an 'RLOC', sphere
   of earliest adopters will not expand, and an 'identifier' (a name which serves only it will never get to provide
   widespread deployment.  One might have the world's best 'clean-slate'
   design, but if it does not have a persistent
   handle deployment plan which is
   economically feasible, it's not good for the node), called much.

   This is particularly true of architectural enhancements, which are
   far less likely to be an 'EID'.  A node may have more than addition which one
   RLOC, or its RLOC may change over time (e.g. if can 'bolt onto the node is mobile),
   but it keeps side'
   of existing mechanisms, and often offer their greatest benefits only
   when widely (or ubiquitously) deployed.

   Maximizing the same EID.

   Technically, one should probably say that ideally, cost-benefit ratio obviously has two aspects.  First,
   on the EID names cost side, by making the
   node (or rather, its end-end communication stack, if one wants to be design as forward-looking inexpensive as possible), and the RLOC(s) name interface(s).
   (At the moment, possible,
   which means in reality, part making the situation is somewhat more complex, deployment as will be explained elsewhere (in [Architecture], Section
   "Namespaces-EIDs-Residual").

   This second distinction, of _what_ easy as possible.
   Second, on the benefit side, by providing many new capabilities,
   which is named best done not by loading the two classes of
   name, is necessary both to enable some design up with lots of features
   or options (which adds complexity), but by making the capabilities that addition
   powerful through deeper flexibility.  We believe LISP
   provides (e.g the ability to seamlessly support multiple interfaces,
   to different networks), and is also a further enhancement to the
   architecture.  Faailing to clearly recognize has met both interfaces and
   communication stacks as distinctly separate classes of things is
   another failing
   these goals.

3.2.  Maximize Re-use of Existing Mechanism

   One key part of reducing the existing Internet architecture (again, one
   inherited from the previous generation cost of networking).

   A novelty in LISP a new design is that it uses existing IPvN addresses (initially,
   at least) for both of these kinds of names, thereby minimizing to absolutely
   minimize the
   deployment cost, as well as providing amount of change _required_ to existing, deployed,
   devices: the ability fewer devices need to easily interact
   with unmodified hosts be changed, and routers.

3.2.  Basic Functionality

   The basic operation of LISP, as it currently stands, is that LISP
   augmented packet switches near the source and destination of packets
   intercept traffic, and 'enhance' smaller the packets.

   The LISP device near
   change to those that do, the source looks up additional information about lower the destination, and then wraps pain (and thus the packet in an outer header, one greater the
   likelihood) of deployment.

   Designs which contains some absolutely require 'forklift upgrades' to large amounts
   of that additional information.  The LISP device
   near the destination removes that header, leaving the original,
   unmodified, packet existing gear are far less likely to be processed by 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 destination node.

   The Internet (both hosts
   and routers); LISP device near the source (the Ingress Tunnel Router, or 'ITR')
   uses the information originally functionality is needed in the packet about the identity of
   its ultimate destination, i.e. the destination address, which one can
   view as the EID of the ultimate destination.  It uses the destination
   EID only a few places (see
   Section 11.1 for more).

   LISP also initially reuses, where-ever possible, existing protocols
   (IPv4 [RFC791] and IPv6 [RFC2460]).  The 'initially' must be stressed
   - careful attention has also long been paid to look up the current location (the RLOC) of that EID.

   The lookup is performed through long-term future
   (see [Future]), and larger changes become feasible as deployment
   increases.

3.3.  'Self-Deployment'

   LISP has deliberately employed a 'mapping system', rather different deployment model,
   which is the
   heart we might call 'self-deployment' (for want of LISP: a better term); it is
   does not require a distributed directory of bindings from EIDs huge push to
   RLOCS.  The destination RLOC get it deployed, rather, it is hoped
   that once people see it and realize they can easily make good use of
   it _on their own_ (i.e. without requiring adoption by others), it
   will be (initially at least) 'deploy itself' (hence the address name of the LISP device near approach).

   One can liken the destination (the Egress Tunnel Router, or
   'ETR').

   The ITR then generates a problem of deploying new outer header for the original packet, systems in this way to
   rolling a snowball down a hill: unless one starts with that header containing the destination's RLOC as the wrapped
   packet's destination, a big enough
   snowball, and the ITR's own address (i.e. the RLOC finds a hill of the
   original source) as right steepness (i.e. the wrapped packet's source, and sends right
   path for it off.

   When the packet gets to the ETR, that outer header is stripped off,
   and the original packet travel), one's snowball is forwarded not going to the original ultimate
   destination for normal processing.

   Return traffic is handled similarly, often (depending go anywhere on the
   network's configuration) with the original ITR and ETR switching
   roles.  The ETR and ITR functionality
   its own.  However, if one has picked one's spot correctly, once
   started, little additional work is usually co-located in a
   single device; these are normally denominated as 'xTRs'.

3.3.  Mapping from EIDs to RLOCs

   The mappings from EIDs needed.

4.  LISP Overview

   LISP is an incrementally deployable architectural upgrade to RLOCs are provided by a distributed (and
   potentially replicated) database, the mapping database,
   existing Internet infrastructure, one which is the
   heart provides separation of LISP.

   Mappings are requested on need,
   location and identity.  The separation is usually not (generally) pre-loaded; in other
   words, mapping perfect, for
   reasons which are distributed via a 'pull' mechanism.  Once obtained driven by an ITR, they are cached, to limit the amount of control traffic to
   a practicable level.  (The mapping system will be discussed deployment philosophy (above), and
   explored in a little more detail below, in elsewhere (in [Perspective], Section 5.2
   "Namespaces-EIDs-Residual").

   LISP separates the functions of location and Section 9)

   Extensive studies, including large-scale simulations driven by
   lengthy recordings identity of actual traffic at several major sites, have
   been performed to verify that nodes (a
   nebulous term, deliberately chosen for use in this 'pull and cache' approach document precisely
   because its definition is
   viable, in practical engineering terms.  [Iannone] (This subject not fixed - you will
   be discussed in more detail in Section 9.5, below.)

3.4.  Interworking With Non-LISP-Capable Endpoints

   The capability for 'easy' interoperation between nodes using LISP,
   and existing non-LISP-using hosts or sites (often called 'legacy'
   hosts), is clearly crucial.

   To allow such interoperation, a number not go far wrong if
   you think of mechanisms have been
   designed.  This multiplicity is a node as being something like a host), which are
   currently intermingled in part because different mechanisms
   have different advantages and disadvantages (so that no single
   mechanism is optimal IPvN addresses.  (This document uses the
   meaning for all cases), but also because 'address' proposed in [Atkinson], i.e. a name with limited
   field experience, it is not clear mixed
   location and identity semantics.)

4.1.  Basic Approach

   In LISP, nodes have both a 'locator' (a name which (if any) approach will be
   preferable.

   One approach uses proxy LISP devices, says _where_ in
   the network's connectivity structure the node is), called PITRs (proxy ITRs) an 'RLOC'
   (short for 'routing locator'), and
   PETRs (proxy ETRs), an 'identifier' (a name which
   serves only to provide LISP functionality during interaction
   with legacy sites.  Another approach uses a device with combined LISP
   and NAT ([RFC1631]) functionality, named a LISP-NAT.

4.  Initial Applications

   As previously mentioned, it is felt that LISP will provide even persistent handle for the
   earliest adopters with some useful capabilities, and that these
   capabilities node), called an
   'EID' (short for 'endpoint identifier').

   A node may have more than one RLOC, or its RLOC may change over time
   (e.g. if the node is mobile), but it would normally always keep the
   same EID.

   Technically, one should probably say that ideally, the EID names the
   node (or rather, its end-end communication stack, if one wants to be
   as forward-looking as possible), and the RLOC(s) name interface(s).
   (At the moment, in reality, the situation is somewhat more complex,
   as will drive early LISP deployment.

   It be explained elsewhere (in [Perspective], Section
   "Namespaces-EIDs-Residual".)

   This second distinction, of _what_ is very imporant named by the two classes of
   name, is necessary both to note that even when used only for
   interoperation with existing unmodified hosts, use enable some of the capabilities that LISP can still
   provide benefits for communications with
   provides (e.g the site which has deployed
   it - and, perhaps even more importantly, can do so _to both sides_.
   This characteristic acts ability to seamlessly support multiple interfaces,
   to different networks), and is also a further enhance enhancement to the utility
   architecture.  Faailing to clearly recognize both interfaces and
   communication stacks as distinctly separate classes of things is
   another failing of the existing Internet architecture (again, one
   inherited from the previous generation of networking).

   A novelty in LISP is that it uses existing IPvN addresses (initially,
   at least) for early
   adopters both of deploying LISP, these kinds of names, thereby increasing minimizing the cost/benefit ratio
   needed
   deployment cost, as well as providing the ability to drive deployment, easily interact
   with unmodified hosts and increasing the 'self-deployment'
   aspect routers.

4.2.  Basic Functionality

   The basic operation of LISP. LISP, as it currently stands, is that LISP
   augmented packet switches near the source and destination of packets
   intercept traffic, and 'enhance' the packets.

   The LISP device near the source looks up additional information about
   the destination, and then wraps the packet in an outer header, one
   which contains some of that additional information.  The LISP device
   near the destination removes that header, leaving the original,
   unmodified, packet to be processed by the destination node.

   The LISP device near the original source (the Ingress Tunnel Router,
   or 'ITR') uses the information originally in the packet about the
   identity of its ultimate destination, i.e. the destination address,
   which in LISP is the EID of the ultimate destination.  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 will be (initially at least) the address
   of the LISP device near the ultimate destination (the Egress Tunnel
   Router, or 'ETR').

   {{Is it worth distinguishing between 'mapping' and 'binding'?  Should
   the document pick one term, and stick with it?}}

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

   When the packet gets to 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 device; these are normally denominated as 'xTRs'.

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

   Mappings are requested on need, not (generally) pre-loaded; in other
   words, mapping are distributed via a 'pull' mechanism.  Once obtained
   by an ITR, they are cached by the ITR, to limit the amount of control
   traffic to a practicable level.  (The mapping system will be
   discussed in more detail below, in Section 6.2 and Section 10)

   Extensive studies, including large-scale simulations driven by
   lengthy recordings of actual traffic at several major sites, have
   been performed to verify that this 'pull and cache' approach is
   viable, in practical engineering terms.  (This subject will be
   discussed in more detail in Section 6.1.1, below.)

4.4.  Interworking With Non-LISP-Capable Endpoints

   The capability for 'easy' interoperation between nodes using LISP,
   and existing non-LISP-using hosts (often called 'legacy' hosts) or
   sites (where 'site' is usually taken to mean a collection of hosts,
   routers and networks under a single administrative control), is
   clearly crucial.

   To allow such interoperation, a number of mechanisms have been
   designed.  This multiplicity is in part because different mechanisms
   have different advantages and disadvantages (so that no single
   mechanism is optimal for all cases), but also because with limited
   field experience, it is not clear which (if any) approach will be
   preferable.

   One approach uses proxy LISP devices, called PITRs (proxy ITRs) and
   PETRs (proxy ETRs), to provide LISP functionality during interaction
   with legacy hosts.  Another approach uses a device with combined LISP
   and NAT ([RFC1631]) functionality, named a LISP-NAT.

4.5.  Security in LISP

   LISP has a subtle security philosophy; see [Perspective], Section
   "Security", where it is laid out in some detail.

   To provide a brief overview, 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.
   That means two things: First, with the limited manpower currently
   available, we cannot expect to create the complete security apparatus
   that we might see in the long term (which requires not just design,
   but also implementation, etc).  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
   thorougly analyze what LISP needs for security, and then design, in
   detail, a scheme for providing that security.  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.  Later
   on, the design can be fully specified, implemented, and deployed.

5.  Initial Applications

   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 unmodified hosts, use of LISP can still
   provide benefits for communications with 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 deploying LISP, thereby increasing the cost/benefit ratio
   needed to drive deployment, and increasing the 'self-deployment'
   aspect of LISP.

   Note also that this section this section only lists likely _early_ applications
   and benefits - if and once deployment becomes more widespread, other
   aspects will come into play (as described in [Perspective], in the
   "Goals of LISP" section).

5.1.  Provider Independence

   Provider independence (i.e. the ability to easily change one's
   Internet Service Provider) was probably the first place where the
   Internet engineering community finally really felt the utility of
   separating location and identity.

   The problem is simple: for the global routing to scale, addresses
   need to be aggregated (i.e. things which are close in the overall
   network's connectivity need to have closely related addresses), the
   so-called "provider aggregated" addresses.  [RFC4116] However, if
   this principle is followed, it means that when an entity switches
   providers (i.e. it moves to a different 'place' in the network), it
   has to renumber, a painful undertaking.  [RFC5887]

   In theory, it ought to be possible to update the DNS entries, and
   have everyone switch to the new addresses, but in practise, addresses
   are embedded in many places, such as firewall configurations at other
   sites.

   Having separate namespaces for location and identity greatly reduces
   the problems involved with renumbering; 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.

5.2.  Multi-Homing

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

   Multi-homing was once somewhat esoteric, but a number of trends are
   driving an increased desirability, e.g. the wish to have multiple ISP
   links to a site for robustness; the desire to have mobile handsets
   connect up to multiple wireless systems; etc.

   Again, separation of location and identity, and the existince of a
   binding layer which can be updated fairly quickly, as provided by
   LISP, is a very useful tool for all variants of this issue.

5.3.  Traffic Engineering

   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 computationa), 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 binding 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 binding
   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 6.2 below.)

   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.

5.4.  Routing

   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 so-called 'Default-Free-Zone' (DFZ) - the
   core of the Internet, the part where routes to _all_ ultimate
   destinations must be available.  LISP is expected to help with this;
   for more detail, see Section 11.6, below.

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

5.5.  Mobility

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

5.6.  IP Version Reciprocal Traversal

   Note that LISP 'automagically' allows 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
   would allow an 'island' of operation of one type to be
   'automatically' tunneled over a stretch of infrastucture which only lists likely _early_ applications
   and benefits - if and once
   supports the other type.

   While the machinery of LISP may seem too heavyweight to be good for
   such a mundane use, this is not intended as a 'sole use' case for
   deployment becomes more widespread, of LISP.  Rather, it is something which, if LISP is being
   deployed anyway (for its other
   aspects will come advantages), is an added benefit that
   one gets 'for free'.

5.7.  Local Uses

   LISP has a number of use cases which are within purely local
   contexts, i.e. not in the larger Internet.  These fall into play (as described 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 [Architecture], the larger Internet, and which apply only to local
   deployments.

   Among the former are multi-homing, IP version traversal, and support
   of VPN's for segmentation and multi-tenancy (i.e. a spatially
   separated private VPN whose components are joined together using the
   public Internet as a backbone).

   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; other non-IP EID types such
   as local network MAC addresses, or application specific data.

6.  Major Functional Subsystems

   LISP has only two major functional sub-systems - the
   "Goals collection of LISP" section).

4.1.  Provider Independence

   Provider independence (i.e. the ability to easily change one's
   Internet Service Provider) was probably the first place where
   LISP packet switches (the xTRs), and the
   Internet engineering community finally really felt mapping system, which
   manages the utility of
   separating location and identity. mapping database.  The problem purpose and operation of each is simple: for
   described at a high level below, and then, later on, in a fair amount
   of detail, in separate sections on each (Sections Section 9 and
   Section 10, respectively).

6.1.  xTRs

   xTRs are fairly normal packet switches, enhanced with a little extra
   functionality in both the global routing data and control planes, to scale, addresses perform LISP
   data and control functionality.

   The data plane functions in ITRs include deciding which packets need
   to be aggregated (i.e. things which are close in given LISP processing (since packets to non-LISP hosts may be
   sent 'vanilla'); i.e. looking up the overall
   network's connectivity need mapping; encapsulating the
   packet; and sending it to have closely related addresses), the
   so-called "provider aggregated" addresses.  [RFC4116] However, if
   this principle ETR.  This encapsulation is followed, it means that when an entity switches
   providers (i.e. it moves done using
   UDP [RFC768] (for reasons to a different 'place' be explained below, in Section 9.2),
   along with an additional IPvN header (to hold the network), it
   has to renumber, source and
   destination RLOCs).  To the extent that traffic engineering features
   are in use for a painful undertaking.  [RFC5887] particular EID, the ITRs implement them as well.

   In theory, it ought to be possible to update the DNS entries, ETR, the data plane simply unwraps the packets, and
   have everyone switch forwards
   the now-normal packets to the new addresses, but in practise, addresses
   are embedded ultimate destination.

   Control plane functions in many places, such as firewall configurations at other
   sites.

   Having separate namespaces ITRs include: asking for location and identity greatly reduces {EID->RLOC}
   mappings via Map-Request control messages; handling the problems involved with renumbering; an organization returning
   Map-Replies which moves
   retains its EIDs (which are how most other parties refer to its
   nodes), but is allocated new RLOCs, and contain the mapping system can
   quickly provide requested information; managing the updated binding from
   local cache of mappings; checking for the EIDs to reachability and liveness
   of their neighbour ETRs; and checking for outdated mappings and
   requesting updates.

   In the new RLOCs.

4.2.  Multi-Homing

   Multi-homing is another place where ETR, control plane functions include participating in the value of separation of
   location
   neighbour reachability and identity became apparent.  There are several different
   sub-flavours of liveness function (see Section 12.4);
   interacting with the multi-homing problem - e.g. depending on whether
   one wants open connections mapping sub-system (next section); and answering
   requests for mappings (ditto).

6.1.1.  Mapping Cache Performance

   As mentioned, studies have been performed to keep working, etc - 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.

   Obviously, these studies are all snapshots of a particular point in
   time, and other axes as the Internet continues its life-cycle they will
   increasingly become out-dated.  However, they are useful because they
   provide an insight into how well (e.g. site multi-homing versus host multi-homing).

   In particular, for LISP can be expected to perform, and
   scale, over time.

   The first, [Iannone], was performed in the 'keep open connections up' case, without
   separation very early stages of location and identity, the only currently feasible
   LISP effort, to verify that that approach is was feasible.  First,
   packet traces of all traffic over the external connection of a large
   university (around 10,000 users) 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 use provider-independent addressses - which moves
   study the
   problem into effects of varying the global routing system, with attendant costs.  This
   approach is also not really feasible for host multi-homing.

   Multi-homing was once somewhat esoteric, settings.  The simulations set no
   limit on the total cache size, but used a number range of trends are
   driving cache retention
   times (i.e. an increased desirability, e.g. the wish to have multiple ISP
   links entry that remained unused longer than a fixed
   retention time was discarded), from 3 minutes, up to 300 minutes.

   First, the simulation gave the cache sizes that would result from
   such a site for robustness; cache design.  It showed that the desire resulting cache sizes ranged
   from 7,500 entries (at night, with the shortest retention time) up to
   about 100,000.  Using some estimations as to i) how many RLOCs the
   average mapping would have mobile handsets
   connect up (since this will affect its size), and ii)
   how much memory it would take to multiple wireless systems; etc.

   Again, separation store a mapping, this indicated
   cache sizes of location and identity, between roughly 100 Kbytes and a few Mbytes.

   Of more interest, in a way, were the existince results regarding two important
   measurements of a
   binding layer the effectiveness of the cache: i) the hit ratio
   (i.e. the share of references which can could be updated fairly quickly, as provided satisified by
   LISP, is a very useful tool for all variants of this issue.

4.3.  Traffic Engineering

   Traffic engineering (TE) [RFC3272], desirable though this capability
   is in a global network, the
   cache), and ii) the miss _rate_ (since control traffic overhead is currently somewhat problematic
   one of the chief concerns when using a cache).  These results were
   also encouraging: miss (and hence lookup) rates ranged (again,
   depending on the time of day, cache settings, etc) from 30 per
   minute, up to provide
   in 3,000 per minute (i.e. 150 per second; with the Internet.  The problem, fundamentally, is that
   shortest timeout, and thus the smallest cache).  Significantly, this capability
   was not visualized when substantially lower than the Internet amount of observed DNS traffic,
   which ranged from 1,800 packets per minute up to 15,000 per minute.

   The second, [Kim], was designed, so support for it
   is somewhat in the 'when the only tool you have is a hammer,
   everything looks like nail' category.

   TE is, fundamentally, general terms similar, except that it used
   data from a routing issue.  However, large ISP (taken over two days, at different times of the current Internet
   routing architecture, which is basically
   year), one with about three times as many users as the Baran previous
   study.  It used the same cache design of fifty
   years ago [Baran] (a single large, distributed computationa), is ill-
   suited to provide TE.  The Internet seems a philosophy (the cache size was
   not fixed), but slightly different, lower, retention time values: 60
   seconds, 180 seconds, and 1,800 seconds (30 minutes), since the
   previous study had indicated that extremely long way times (hours) had
   little additional benefit.

   The results were similar: cache sizes ranges from adopting a
   more-advanced routing architecture, although the basic concepts for
   such have been known for some time.  [RFC1992]

   Although 20,000 entries with
   the identity-location binding layer is thus a poor place,
   architecturally, shortest timeout, to provide TE capabilities, it is still an
   improvement over roughly 60,000 with the current routing tools available for this purpose
   (e.g. injection of more-specific routes into longest; the global routing
   table).  In addition, instead of miss
   rate ranged from very roughly 400 per minute (with the entire network incurring longest
   timeout) to very roughly 7,000 per minute (with the
   costs (through shortest),
   similar to the routing system overhead), when using previous results.

   Finally, a binding
   layer to provide TE, third study, [CorasCache], examined the overhead is limited 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 those who are
   actually communicating with verify that particular destination.

   LISP includes a number
   models of features in the mapping system to support
   TE.  (Described in Section 5.2 below.)

4.4.  Mobility

   Mobility is performance of such a cache (using previous theoretical
   work on caches) produced results that conformed with actual empirical
   measurements.

   It used yet another place where separation set of location and
   identity is obviously packet traces (some from an earlier study,
   [Jakab]).  Using a key part cache size of around 50,000 entries produced a clean, efficient
   miss rate of around 1x10-4; again, definitely viable, and high-
   functionality solution.  Considerable experimentation has been
   completed on doing mobility in line
   with LISP.

4.5.  IP Version Reciprocal Traversal

   Note that LISP 'automagically' allows intermixing the results 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
   would allow an 'island' other studies.

6.2.  Mapping System

   The mapping database is a distributed, and potentially replicated,
   database which holds mappings between EIDs (identity) and RLOCs
   (location).  To be exact, it contains mappings between EID blocks and
   RLOCs (the block size is given explicitly, as part of operation 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 one type to EIDs are behind a single xTR.

   However, the block may be
   'automatically' tunneled over (and often is) as small as a stretch of infrastucture which single EID.
   Since mappings are only
   supports the other type.

   While loaded upon demand, if smaller blocks become
   predominant, then the machinery increased size of LISP may seem too heavyweight the overall database is far
   less problematic than if the routing table came to be good for dominated by
   such small entries.

   A particular node may have more than one RLOC, or may change its
   RLOC(s), while keeping its singlar identity.

   The mapping contains not just the RLOC(s), but also (for each RLOC
   for any given EID) priority and weight (to allow allocation of load
   between several RLOCs at a mundane use, given priority); this is not intended as allows a 'sole use' case for
   deployment certain
   amount of traffic engineering to be accomplished with LISP.  Rather, it is something which, if LISP is being
   deployed anyway (for its other advantages),

6.2.1.  Mapping System Organization

   The mapping system is an added benefit that
   one gets 'for free'.

4.6.  Local Uses

   LISP has a number of use cases which actually split into what are within purely local
   contexts, i.e. not in effectively three
   major functional sub-systems (although the larger Internet.  These fall into latter two
   categories: uses seen on are closely
   integrated, and appear to most entities in the Internet (above), but here on LISP system as a private
   (and usually small scale) setting;
   single sub-system).

   The first covers the actual mappings themselves; they are held by the
   ETRs, and applications an ITR which do not have needs a direct analog in mapping gets it (effectively) directly
   from the larger Internet, and which apply only to local
   deployments.

   Among ETR.  This co-location of the former are multi-homing, IP authoritative version traversal, of the
   mappings, and support the forwarding functionality which it describes, is an
   instance of VPN's fate-sharing.  [Clark]

   To find the appropriate ETR(s) to query for segmentation and multi-tenancy (i.e. a spatially
   separated private VPN whose components are joined together using the
   public Internet as mapping, the second
   two sub-systems form an 'indexing system', itself also a backbone).

   Among the latter class, non-Internet applications which have no
   analog distributed,
   potentally replicated database.  It provides information on the Internet, which
   ETR(s) are authoritative sources for the following example applications:
   virtual machine mobility in data centers; other non-IP EID types such
   as local network MAC addresses, or application specific data.

5.  Major Functional Subsystems

   LISP has only various {EID -> RLOC}
   mappings which are available.  The two major functional subsystems - sub-systems which form it are
   the collection of
   LISP packet switches (the xTRs), user interface sub-system, and indexing sub-system (which holds
   and provides the mapping system, which
   manages actual information).

6.2.2.  Interface to the mapping database. Mapping System

   The purpose and operation client interface to the indexing system from an ITR's point of each
   view is
   described at a high level below, and then, later on, in a fair amount
   of detail, in separate sections on each (Sections Section 8 and
   Section 9, respectively).

5.1.  xTRs

   xTRs are fairly normal packet switches, enhanced not with a little extra
   functionality in both the data and indexing sub-system directly; rather, it is
   through the client-interface sub-system, which is provied by devices
   called Map Resolvers (MRs).

   ITRs send request control planes, messages (Map-Request packets) to perform LISP
   data and control functionality.

   The data plane functions an MR.
   (This interface is probably the most important standardized interface
   in ITRs include deciding which packets need
   to be given LISP processing (since packets - it is the key to non-LISP sites may be
   sent 'vanilla'); looking up the mapping; encapsulating entire system.)

   The MR then uses the packet;
   and sending it indexing sub-system to the ETR.  This encapsulation is done using UDP
   [RFC768] (for reasons allow it to be explained below, in Section 8.2), along
   with an additional IPvN header (to hold forward the asource and destination
   RLOCs).  To
   Map-Request to the extent that traffic engineering features appropriate ETR.  The ETR formulates reply control
   messages (Map-Reply packets), which are in use
   for a particular EID, the ITRs implement them as well.

   In sent to the ETR, ITR.  The details
   of the data plane simply unwraps indexing system are thus hidden from the packets, and forwards ITRs.

   Similarly, the 'vanilla' packets client interface to the ultimate destination.

   Control plane functions in ITRs include: asking for {EID->RLOC}
   mappings via Map-Request indexing system from an ETR's
   point of view is through devices called Map Servers (MSs - admittedly
   a poorly chosen term, since their primary function is not to respond
   to queries, but it's too late to change it now).

   ETRs send registration control messages; handling the returning
   Map-Replies messages (Map-Register packets) to an
   MS, which contain makes the requested information; managing information about the
   local cache of mappings; checking for mappings which the reachability and liveness
   of their neighbour ETRs; and checking ETR
   indicates it is authoritative for outdated mappings and
   requesting updates.

   In available to the ETR, indexing system.
   The MS formulates a reply control plane functions include participating in message (the Map-Notify packet),
   which confirms the
   neighbour reachability registration, and liveness function (see Section 12.4);
   interacting with is returned to the ETR.  The
   details of the indexing system are thus likewise hidden from the
   'ordinary' ETRs.

6.2.3.  Indexing Sub-system

   The current indexing sub-system is the Delegated Database Tree (DDT),
   which is very similar to DNS.  [DDT], [RFC1034] However, unlike DNS,
   the actual mappings are not handled by DDT; DDT (as part of the mapping
   indexing system (next section); and
   answering requests for mappings (ditto).

5.2.  Mapping System

   The mapping database is system) merely identifies the ETRs which hold the actual
   mappings.

   DDT replaced an earlier indexing sub-system, ALT ([Perspective],
   section "Appendices-ALT"); this swap validated the concept of having
   a distributed, and potentially replicated,
   database separate client-interface sub-system, which holds bindings between EIDs (identity) and RLOCs
   (location).  To would allow the actual
   indexing sub-system to be exact, it contains bindings between replaced without needing to modify the
   clients.

6.2.3.1.  DDT Overview

   Conceptually, DDT is fairly simple: like DNS, in DDT the delegation
   of the EID blocks and
   RLOCs (the block size namespace ([Perspective], Section "Namespaces-XEIDs") is given explicitly,
   instantiated as part a tree of DDT 'nodes', starting with the syntax).

   Support 'root' DDT
   node.  Each node is responsible (authoritative?) for one or more
   blocks of the EID namespace.

   The 'root' node is both reponsible for minimizing the administrative
   configuration overhead, entire namespace; any DDT node
   can 'delegate' part(s) of its block(s) of the namespace to child DDT
   node(s).  The child node(s) can in turn further delgate (necessarily
   smaller) blocks of namespace to their children, through as well many
   levels as are needed (for operational, administrative, etc, needs).

   Just as with DNS, for operational efficiency; e.g.
   when a group reasons of EIDs are behind a single xTR.

   However, performance, reliability and
   robustness, any particular node in the block DDT delegation tree may be (and often is) as small as
   instantiated in more than one redundant physical server machines.
   Obviously, all the servers which instantiate a single EID.
   Since mappings are only loaded upon demand, if smaller blocks become
   predominant, then particular node in the increased size of
   tree have to have identical data about that node.

   Also, although the overall database delegation hierarchy is far
   less problematic than if a strict tree {{check - do
   all servers for the routing table came to be dominated by
   such small entries.

   A particular node may delegation of block X have to return the same
   list of servers for that block?}}, a single DDT server could be
   responsible (authoritative?) for more than one RLOC, or may change its
   RLOC(s), while keeping its singlar identity.

   The binding contains not just the RLOC(s), but also (for each RLOC
   for any given EID) priority and weight (to allow allocation block of load
   between several RLOCs at a given priority); this allows the EID
   namespace.

   Eventually, leaf nodes in the DDT tree assign ({{delegate? - it's all
   static configured, nothing is dynamic}}) EID namespace blocks to
   MS's, which are DDT terminal nodes; i.e. a certain
   amount leaf of traffic engineering the tree is
   reached when the delegation points to be accomplished with LISP.

5.2.1.  Mapping System Organization an MS instead of to another DDT
   node.

   The mapping system MS is actually split into two major functional sub-
   systems.  The actual bindings themselves in direct communication with the ETR(s) which both i) are held by
   authoritative for the ETRs, mappings for that block, and an
   ITR ii) handle traffic
   to that block of EID namespace.

6.2.3.2.  Use of DDT by MRs

   An MR which needs wants to find a binding effectively gets it from the ETR.

   This co-location of mapping for a particular EID first
   interacts with the authoritative version nodes of the mappings, and DDT tree, discovering (by querying
   DDT nodes) the forwarding functionality chain of delegations which cover that EID.  Eventually
   it describes, is directed to an instance MS, and then to an ETR which is responsible
   {{authoritative?}} for that EID.

   Also, again like DNS, MRs cache information about the delegations in
   the DDT tree.  This means that once an MR has been in operation for
   while, it will usually have much of
   fate-sharing.  [Clark]

   To find the appropriate ETR(s) 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 query for
   usually forward the mapping, mapping request to the second
   subsystem, an 'indexing system', itself also appropriate MS without
   having to do a distributed,
   potentally replicated database, provides information on which ETR(s)
   are authoritative sources complete tree-walk of information about the bindings which are
   available.

5.2.2.  Interface DDT tree to find any
   particular mappping.

   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 Mapping System

   The client interface Map-Request to the mapping system from an ITR's point appropriate MS.

   The big advantage of
   view DDT over the ALT, in performance terms, is not that
   it allows MRs to interact _directly_ with distant DDT nodes (as
   opposed to the indexing system directly; rather, it is ALT, which _always_ required mediation through
   devices called Map Resolvers (MRs).

   ITRs send request control messages (Map-Request packets)
   intermediate nodes); caching of information about those distant nodes
   allows DDT to an MR.
   (This interface is probably the most important standardized interface make extremely effective use of this capability.

7.  Examples of Operation

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

7.1.  An Ordinary Packet's Processing

   This case follows the processing of a typical user packet (for
   instance, a normal TCP data or acknowledgment packet associated with
   an already-open TCP connection) as it makes its way from the
   appropriate ETR.  The ETR formulates reply control messages (Map-
   Reply packets), which is conveyed original
   source host to the ITR.  The details of the
   indexing system, etc, are thus hidden from ultimate destination.

   When the 'ordinary' ITRs.

   Similarly, packet has made its way through the client interface local site to the indexing system from an ETR's
   point of view ITR
   (which is through devices called Map Servers (MSs - admittedly also a poorly chosen term, but it's too late to change it now).

   ETRs send registration control messages (Map-Register packets) to an
   MS, which makes border router for the information about site), the mappings which border router looks
   up the ETR
   indicates desination address (an EID) in its local mapping cache.  It
   finds a mapping, which instructs it is authoritative for available to wrap the indexing system.
   The MS formulates packet in an outer
   header (an IP packet, containing a reply control message (the Map-Notify packet), UDP packet which confirms the registration, contains a LISP
   header, and is returned to then the ETR. user's original packet).  The
   details of the indexing system are thus likewise hidden from destination
   address in the
   'ordinary' ETRs.

5.2.3.  Indexing Subsystem

   The current indexing system outer header is called set by the Delegated Database Tree
   (DDT), which is very similar in operation ITR to DNS.  [DDT], [RFC1034]
   However, unlike DNS, the actual mappings are not handled by DDT; DDT
   merely identifies RLOC of the ETRs which hold
   destination ETR.

   The packet is then sent off through the mappings.

   Again, extensive large-scale simulations driven by lengthy recordings
   of actual traffic Internet, using normal
   Internet routing tables, etc.

   On arrival at several major sites, have been performed to
   verify the effectiveness of this particular indexing system.  [Jakab]

6.  Examples of Operation

   To aid destination ETR, the ETR will notice that it is
   listed as the destination in comprehension, a few examples are given of user packets
   traversing the LISP system.  The first shows outer header.  It will examine the processing of
   packet, detect that it is a
   typical user LISP packet, i.e. what and unwrap it.  It will then
   examine the vast majority header of user packets will
   see.  The second shows what happens when the first packet to a
   previously-unseen destination (at a particular ITR) is user's original packet, and forward it
   internally, through the local site, to be
   processed by LISP.

6.1.  An Ordinary Packet's Processing

   This case follows the processing of a typical user ultimate destination.

   At the ultimate destination, the packet (for
   instance, will be processed, and may
   produce a normal TCP data or acknowledgment packet associated return packet, which follows the exact same process in
   reverse - with
   an open HTTP connection) as it makes its way from the source host to exception that the destination.

   {{Rest to be written.}}

6.2. roles of the ITR and ETR are
   swapped.

7.2.  A Mapping Cache Miss

   If a host sends a packet, and it gets to the ITR, and the ITR both i)
   determines that it needs to perform LISP processing on the user data
   packet, but ii) does not yet have a mapping cache entry which covers
   that destination EID, then more complex processing ensues.

   {{Rest

   It 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 see if it has the RLOC for the ETR for that
   destination EID.  If not, it will query the DDT system to find the
   RLOC of the ETR.  When it has the RLOC, it will send the Map-Request
   on to the 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.  (Typically, like many ARP
   implementations, the original user packet will have been discarded,
   not cached waiting for the mapping to be written.}}

7. found.  When the host
   retransmits the packet, the mapping will be there, and the packet
   will be forwarded.)

8.  Design Approach

   Before describing LISP's components in more detail below, it may be it worth saying a few words about
   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 - this
   them.

   This design philosophy is covered in detail in in [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 there.

7.1.  Quick Implement-Test Loop

   LISP uses a philosophy similar
   here.

9.  xTRs

   As mentioned above (in Section 6.1), xTRs are the basic data-handling
   devices in LISP.  This section explores some advanced topics related
   to xTRs.

   Careful rules have been specified for both TTL and ECN [RFC3168] to
   ensure that used in passage through xTRs does not interfere with the early days
   operation of the
   Internet, which is these mechanisms.  In addition, care has been taken to just build it, then try it and see what
   happens,
   ensure that 'traceroute' works when xTRs are involved.

9.1.  When to Encapsulate

   An ITR knows that an ultimate destination is 'running' LISP (remember
   that the destination machine itself probably knows nothing about
   LISP), and move forward from there based thus that it should perform LISP processing on what actually happens.
   The concept a packet
   (including potential encapsulation) if it has been an entry in its local
   mapping cache that covers the destination EID.

   Conversely, if the cache contains a 'negative' entry (indicating that
   the ITR has previously attempted to get something up and running, find a mapping that covers this
   EID, and then modify it based on testing and experience.

7.1.1.  No Desk Fixes

   Don't try and forsee all issues from desk analysis.  (Which has been informed by the mapping system that no such
   mapping exists), it knows the ultimate destination is not to
   say that one should not spend _some_ time on trying to forsee
   problems, but running
   LISP, and the packet can be aware forwarded normally.

   Note that it is a 'diminishing returns' process.)
   The performance the ITR cannot simply depend on the appearance, or non-
   appearance, of very large, complex, physically distributed
   systems is hard the destination in the routing tables in the DFZ, as a
   way to predict, so rather than try (which would
   necessarily be tell if an incomplete exercise anyway, testing would
   inevitably be required eventually), at ultimate destination is a certain point it's better
   just LISP node or not, because
   mechanisms to get on with it - and you will learn a host allow interoperation of other lessons
   in LISP sites and 'legacy' sites
   necessarily involve advertising LISP sites' EIDs into the process, too.

7.1.2.  Code Before Documentation

   This is often a corollary DFZ.

9.2.  UDP Encapsulation Details

   The UDP encapsulation used by LISP for carrying traffic from ITR to
   ETR, and many of the kind details of style described above.
   While how it probably works, were all chosen for
   very practical reasons.

   Use of UDP (instead of, say, a LISP-specific protocol number) was
   driven by the fact that many devices filter out 'unknown' protocols,
   so adopting a non-UDP encapsulation would not have been possible made the initial
   deployment of LISP harder - and our goal (see Section 3.1) was to
   make the deployment as easy as possible.

   The UDP source port in a large,
   inhomogenous group, the small, close nature encapsulated packet is a hash of the LISP
   implementation group did allow
   original source and ultimate destination; this approach.

7.2.  Only Fix Real Problems

   Don't worry about anything unless experience show it's is because many ISPs
   use multiple parallel paths (so-called 'Equal Cost Multi-Path'), and
   load-share across them.  Using such a real
   problem.  For instance, hash in the early stages, much was made out of the
   problem of 'what does an ITR do if it gets a packet, but does not
   (yet) have a mapping for source-port in the destination?'

   In practise, simply dropping such packets has just not proved
   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
   problem; the higher level protocol will retransmit them after particular
   {source, source port, destination, destination port} tuple flow along
   a
   timeout, single path, and the mapping do not become disordered)..

   The UDP checksum is zero because the inner packet usually in place by then.  So spending already has
   a
   lot of time (and its companion, energy) end-end checksum, and mechanism (and _its_
   extremely undesirable companion, complexity) on solving this
   'problem' would not have been the outer checksum adds no value.  [Saltzer]
   In most efficient approach, overall.

7.3.  No Theoretical Perfection

   Attack hard problems with exising hardware, computing such a number of cheap and simple mechanisms
   that co-operate and overlap.  Trying to find checksum (and checking it
   at the other end) would also present an intolerable load, for no
   benefit.

9.3.  Header Control Channel

   LISP provides a single mechanism that
   is all of:

   - Robust
   - Efficient
   - Fast multiplexed channel in the encapsulation header.  It
   is often (usually?) mostly (but not entirely) used for control purposes.  (See
   [Perspective], Section "Architecture-Piggyback" for a fool's errand.  (The analogy to longer
   discussion of the aphorism
   'Fast, Cheap, Good - Pick Any Two' should be obvious.)  However, a
   collection architectural implications of simple performing control
   functions with data traffic.)

   The general concept is that the header starts with an 8-bit 'flags'
   field, and cheap mechanisms may effectively be able to
   meet all it also includes two data fields (one 24 bits, one 32),
   the contents and meaning of which vary, depending on which flags are
   set.  This allows these goals (see, for example, ETR Liveness/Reachability,
   Section 12.4).

   Yes, this results in fields to be 'multiplexed' among a system which is not provably correct in all
   circumstances.  The world, however, is full number of such systems - and in
   different low-duty-cycle functions, while minimizing the real world, effective robustness is more likely to result from
   having multiple, overlapping mechanisms than one single high-powered
   (and inevitably complex) one.  In space
   overhead of the world LISP encapsulation header.

9.3.1.  Mapping Versioning

   One important use of civil engineering,
   redundancy the multiplexed control channel is now accepted as a key design principle; mapping
   versioning; i.e. the same should
   be true discovery of information systems.  [Salvadori]

7.3.1.  No Ocean Boiling

   Don't boil when the ocean to kill a single fish.  This mapping cached in an ITR
   is a combination outdated.  To allow an ITR to discover this, identifying sequence
   numbers are applied to different versions of
   7.2 (Only Fix Real Problems) and 7.3 (No Theoretical Perfection); it
   just means that spending a lot of complexity and/or overhead mappping.
   [Versioning] This allows an ITR to deal
   with easily discover when a problem that's not really cached
   mapping has been updated by a problem more recent variant.

   Version numbers are available in control messages (Map-Replies), but
   the initial concept is not good engineering.

7.4.  Just Enough Security

   How much security that to have limit control message overhead, the
   versioning mechanism should primarily use the multiplex 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 complex issue.  It's relatively easy
   for designers to add good security, but much harder to get more recent version), and ETRs can let ITRs
   know what the users
   to jump over all current mapping version is (so the ITRs can request an
   update, if their copy is outdated).

   At the hoops necessary to use it.  LISP has therefore
   adopted moment version numbers are manually assigned, and ordered.
   Some felt that this was non-optimal, and that a position where we add 'just enough' security.

   The overall better approach would
   have been to security in LISP have 'fingerprints' which were computed from the current
   mapping data (i.e. a hash).  It is fairly subtle, though, not clear that the ordering buys
   much (if anything), and the potential for mishaps with manually
   configured version numbers is covered in more detail elsewhere (in [Architecture], Section
   "Security").

8.  xTRs

   As mentioned above (in Section 5.1), xTRs are self-evident.

9.3.2.  Echo Nonces

   Another important use of the basic data-handling
   devices in LISP.  This section explores some advanced topics related
   to xTRs.

   Careful rules have been specified header control channel is for both TTL and ECN [RFC3168] a
   mechanism known as the Nonce Echo, which is used as an efficient
   method for ITRs to
   ensure that passage through xTRs does not interfere with check the
   operation reachability of these mechanisms.  In addition, care has been taken correspondent ETRs.

   Basically, an ITR which wishes to ensure that 'traceroute' works when xTRs are involved.

8.1.  When to Encapsulate

   An ITR knows that a destination an ETR is running LISP, up, and thus that it
   should perform LISP processing on
   reachable, sends a packet (including potential
   encapsulation) if it has an entry in its local mapping cache nonce to that
   covers ETR, carried in the destination EID.

   Conversely, if encapsulation
   header; when that ETR (acting as an ITR) sends some other user data
   packet back to the cache contains a 'negative' entry (indicating ITR (acting in turn as an ETR), that nonce is
   carried in the header of that packet, allowing the original ITR has previously attempted to find a mapping
   confirm that covers this
   EID, and it has been informed by the mapping system its packets are reaching that no such
   mapping exists), it knows the destination ETR.

   Note that lack of a response is not running LISP, and
   the packet can be forwarded normally.

   (The ITR cannot simply depend on the appearance, or non-appearance,
   of the destination in the DFZ routing tables, as necessarily _proof_ that
   something has gone wrong - but it stronly suggests that something
   has, so other actions (e.g. a way switch to tell an alternative ETR, if a
   destination one is
   listed; a LISP site or not, because mechanisms to allow
   interoperation direct probe; etc) are advised.

   (See Section 12.5 for more about Echo Nonces.)

9.3.3.  Instances

   Another use of LISP sites and 'legacy' sites necessarily involve
   advertising LISP sites' EIDs into the DFZ.)

8.2.  UDP Encapsulation Details

   The these header fields is for 'Instances' - basically,
   support for VPN's across backbones.  [RFC4026] Since there is only
   one destination UDP encapsulation port used by LISP for carrying traffic from ITR to
   ETR, and many of the details carriage of how user data packets, and
   the it works, were all chosen source port is used for
   very practical reasons.

   Use of UDP (instead of, say, a LISP-specific protocol number) was
   driven by the fact that many devices filter out 'unknown' protocols,
   so adopting a non-UDP encapsulation would have made the initial
   deployment of LISP harder - and our goal multiplexing (above), there is no other
   way to differentiate among different destination address namespaces
   (which are often overlapped in VPNs).

9.4.  Probing

   RLOC-Probing (see [LISP], Section 2.1) was to
   make the deployment as easy as possible.

   The UDP source port in the encapsulated packet 6.3.2.  "RLOC-Probing Algorithm"
   for details) is a hash of the
   original source and destination; this is because many ISPs mechanism method that an ITR can 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 determine
   with certainty that packets an ETR is up and reachable from individual connections are delivered in
   order (since most ISPs try the ITR.  As a
   side-benfit, it gives a rough RTT estimates.

   It is quite a simple mechanism - an ITR simply sends a specially
   marked Map-Request directly to ensure the ETR it wishes information about;
   that packets for a particular
   {source, source port, destination, destination port} tuple flow along ETR sends back a single path, specially marked Map-Reply.  A Map-Request and do not become disordered)..

   The UDP checksum is zero
   Map-Reply are used, rather than a special probing control-message
   pair, because as a side-benefit the inner packet usually already ITR can discover if the mapping
   has
   a end-end checksum, been updated since it cached it.

   The probing mechanism is rather heavy-weight and expensive (compared
   to mechanisms like the outer checksum adds no value.  [Saltzer]
   In most exising hardware, computing such a checksum (and checking Echo-Nonce), since it
   at the other end) would also present an intolerable load, for no
   benefit.

8.3.  Header Control Channel

   LISP provides costs a multiplexed channel in the encapsulation header.  It
   is mostly (but not entirely) used for control purposes.  (See
   [Architecture], Section "Architecture-Piggyback" for message
   from each side, so it should only be used sparingly.  However, it has
   the advantages of providing information quickly (a single RTT), and
   being a longer
   discussion simple, direct robust way of doing so.

9.5.  Mapping Lifetimes and Timeouts

   Mappings come with a Time-To-Live, which indicate how long the architectural implications
   creator of this.) the mapping expects them to be useful for.  The general concept is TTL may
   also indicate that the header starts with an 8-bit 'flags'
   field, and mapping should not be cached at all, or it can
   indicate that it has no particular lifetime, and the recipient can
   chose how long to store it.

   Mappings might also includes two data fields (one 24 bits, one 32), be discarded before the contents and meaning of which vary, TTL expires, depending on which flags are
   set.  This allows these fields to be 'multiplexed' among a number of
   different low-duty-cycle functions, while minimizing
   what strategies the space
   overhead of ITR is using to maintain its cache; if the LISP encapsulation header.

8.3.1.  Echo Nonces

   One important use
   maximum cache size is for a mechanism known as fixed, or the Nonce Echo, ITR needs to reclaim memory,
   mappings which
   is have not been used as 'recently' may be discarded.
   (After all, there is no harm in so doing; a future reference will
   merely cause that mapping to be reloaded.)

9.6.  Security of Mapping Lookups

   LISP provides an efficient method for ITRs optional mechanism to check secure the reachability obtaining of
   correspondent ETRs.

   Basically,
   mappings by an ITR ITR.  [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 wishes are larger what what have
   been actually delegated to ensure it).

   Very briefly, the ITR provided a One-Time Key with its query; this
   key is used by both the MS (to verify the EID block that an it has
   delegated to the ETR), and indirectly by the ETR (to verify the
   mapping that it is up, and
   reachable, sends a nonce returning to the ITR).

   The specification for LISP-SEC suggests that the ITR-MR stage be
   cryptographically protected, and indicates that ETR, carried in the encapsulation
   header; when existing
   mechanisms for securing the ETR-MS stage are used to protect Map-
   Rquests also.  It does assume that ETR (acting as an ITR) sends some other user data
   packet back the channel from the MR to the ITR (acting in turn as an ETR), that nonce MS
   is
   carried in secure (otherwise an attacker could obtain the header of that packet, allowing OTK from the original ITR Map-
   Request and use it to
   confirm that its packets forge a reply).

9.7.  Mapping Gleaning in ETRs

   As an optimization to the mapping acquisition process, ETRs are reaching that ETR.

   Note that lack
   allowed to 'glean' mappings from incoming user data packets, and also
   from incoming Map-Request control messages. {{Is this still there?
   Check the latest version of a response the spec.}} This is not necessarily _proof_ that
   something has gone wrong - but it stronly suggests that something
   has, secure, and so other actions (e.g.
   any such mapping must be 'verified' by sending a switch Map-Request to get
   an alternative ETR, if one is
   listed; a direct probe; etc) are advised. authoritative mapping.  (See further discussion of the security
   implications of this in [Perspective], Section 12.5 for more about Echo Nonces.)

8.3.2.  Instances

   Another use "Security-xTRs".)

   The value of these header fields gleaning is for 'Instances' - basically,
   support for VPN's across backbones.  [RFC4026] Since there that most communications are two-way, and so
   if host A is only
   one destination UDP port used for carriage of user data packets, 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 source port is used for multiplexing (above), there dropping of the first
   return packet; this is no other
   way felt to differentiate among different destination address namespaces
   (which are often overlapped in VPNs).

8.4. be very undesirable.

9.8.  Fragmentation

   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.

   One, called the 'stateful' approach, 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.

   It is not clear at this point which approach is preferable.

8.5.

10.  The Mapping Gleaning in ETRs

   As an optimization System

   RFC 1034 ("DNS Concepts and Facilities") has this to say about the mapping acquisition process, ETRs are
   allowed
   DNS name to 'glean' mappings from incoming user data packets, and also
   from incoming Map-Request control messages.  This is not secure, and
   so any such IP address mapping system:

     "The sheer size of the database and frequency of updates suggest
     that it must be 'verified' by sending maintained in a Map-Request distributed manner, with local
     caching to
   get 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 system.

   To recap, the mapping system is split into an authoritative mapping.  (See further discussion indexing sub-system,
   which keeps track of where all the
   security implications mappings are kept, and the
   mappings themselves, the authoritative copies of this which are always
   held by ETRs.

10.1.  The Mapping System Interface

   As mentioned in [Architecture], Section "Security-
   xTRs".)

   The value 6.2.2, both of gleaning is that most communications are two-way, the inferfaces to the mapping
   system (from ITRs, and ETRs) are standardized, so
   if host A is sending packets that the more
   numerous xTRs do not have 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 modified when the mapping indexing
   sub-system is changed.

   (This precaution has already allowed the mapping system to be
   upgraded during LISP's evolution, when ALT was replaced by DDT.)

   This section describes the interfaces in a delay, and little more detail; for
   the dropping details, see [MapInterface].

10.1.1.  Map-Request Messages

   The Map-Request message contains a number of fields, the first
   return packet; this is felt to be very undesirable.

9.  The Mapping System

   RFC 1034 ("DNS Concepts 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 Facilities") has this to say about the
   DNS name to IP address Address Family Identifier (AFI) for that EID block.
   [AFI] The inclusion of the AFI allows the mapping system:

     "The sheer size system interface
   (as embodied in these control packets) a great deal of flexibility.
   (See [Perspective], Section "Namespaces" for more on this.)

   Other important fields are the database source EID (and its AFI), and frequency of updates suggest one or
   more RLOCs for the source EID, along with their AFIs.  Multiple RLOCs
   are included to ensure that it must be maintained at least one is in a distributed manner, with local
     caching form which will
   allow the reply to improve performance. Approaches that attempt be returned to
     collect the requesting ITR, and the source
   EID is used for a consistent copy variety of functions, including 'gleaning' (see
   Section 9.7).

   Finally, the entire database will become more
     and more expensive and difficult, message includes a long nonce, for simple, efficient
   protection against offpath attackers (see [Perspective], Section
   "Security-xTRs" for more), and hence should be avoided." a variety of other fields and this observation applies equally to control
   flag bits.

10.1.2.  Map-Reply Messages

   The Map-Reply message looks similar, except it includes the LISP mapping system.

   As previously mentioned,
   entry for the mapping system is split into an indexing
   subsystem, requested EID(s), which keeps track contains one or more RLOCs and
   their associated data.  (Note that the reply may cover a larger block
   of where all the mappings are kept, and EID namespace than the mappings themsleves, request; most requests will be for a
   single EID, the authoritative copies of one which are always
   held by ETRs.

9.1.  The Indexing Subsystem

   The indexing system prompted the query.)

   For each RLOC in LISP the entry, there is currently implemented by the DDT
   system.  LISP initially used (for ease of getting something
   operational without having to write RLOC, its AFI (of course),
   priority and weight fields (see Section 6.2), and multicast priority
   and weight fields.

10.1.2.1.  Solicit-Map-Request Messages

   "Solicit-Map-Request" (SMR) messages are actually not another message
   type, but a lot sub-type of code) an indexing system
   called ALT, Map-Reply messages.  They include a special
   flag which used BGP running over virtual tunnels.  [ALT] This
   proved indicates to have the recipient that it _should_ send a number of issues, and new
   Map-Request message, to refresh its mapping, because the ETR has now been superseded by
   DDT.

   In DDT,
   detected that the EID namespace(s) are instantiated as one it is using is out-dated.

   SMR's, like most other control traffic, is rate-limited. {{Need to
   say more about rate limiting, probably in security section?  Ref to
   that from here.}}

10.1.3.  Map-Register and Map-Notify Messages

   The Map-Register message contains authentication information, and a tree
   number of DDT nodes.
   Starting mapping records, each with an individual Time-To-Live
   (TTL).  Each of the root node(s), which have 'reponsibility' records contains an EID (potentially, a block of
   EIDs) and its AFI, a version number for the
   entire namespace, portions this mapping (see
   Section 9.3.1), and a number of RLOCs and their AFIs.

   Each RLOC entry also includes the namespace are delegated to child
   nodes, in a recursive process extending through as many levels same data as are
   needed.  Eventually, leaf nodes in the DDT tree delegate namespace
   blocks to ETRs.

   MRs obtain information about delegations by interrogating DDT nodes, Map-Replies
   (i.e. priority and caching weight); this is because in some circumstances it
   is advantageous to allow the results. aThis allows them, when passed a request for
   a mapping by an ITR, MS to forward proxy reply on the mapping request ETR's behalf to
   Map-Request messages.  [Mobility]

   Map-Notify messages have the
   appropriate ETR (perhaps after loading some missing delegation
   entries into their delegation cache).

9.2. exact same contents as Map-Register
   messages; they are purely acknowledgements.

10.2.  The Mapping System Interface DDT Indexing Sub-system

   As previously mentioned in Section 5.2.2, both of the inferfaces to the mapping
   system (from ITRs, and ETRs) are standardized, so that the more
   numerous xTRs do not have to be modified when 6.2.3, the mapping indexing
   system sub-system in
   LISP is changed.  This precaution has already allowed currently the DDT system.

   The overall operation is fairly simple; an MR which needs a mapping
   system to be upgraded during LISP's evolution, when ALT was replaced
   by DDT.

   This section describes the interfaces in
   starts at a little server for the root DDT node (there will normally be more detail.

9.2.1.  Map-Request Messages

   The Map-Request message contains
   than one such server available, for both performance and robustness
   reasons), and through a number combination of fields, the two most
   important cached delegation information,
   and repetitive querying of which are the requested EID block identifier (remember
   that individual mappings may cover a block sequence of EIDs, not just a single
   EID), and DDT servers, works its way
   down the Address Family Identifier (AFI) delegation tree until it arrives at an MS which is
   authoritative (responsible?) for that the block of EID block.
   [AFI] namespace which
   holds the destination EID in question.

   The inclusion of interaction between MRs and DDT servers is not complex; the AFI allows MR
   sends the mapping system interface
   (as embodied in these control packets) DDT server a great deal of flexibility.
   (See [Architecture], Section "Namespaces" for more on this.)

   Other important fields are Map-Request control message (which looks
   almost exactly like the source EID (and Map-Request which an ITR sends to an MR).
   The DDT server uses its AFI), data (which is configured, and one static) to see
   whether it is directly peered to an MS which can answer the request,
   or
   more RLOCs if it has a child (or children, if replicated) which is
   responsible for that portion of the source EID, along with their AFIs.  Multiple RLOCs EID namespace.

   If it has children which are included responsible, it will reply to ensure that at least one is in the MR
   with another kind of LISP control message, a form Map-Referral message,
   which will
   allow provides information about the reply to be returned to delegation of the requesting ITR, and block
   containing the source
   EID is used for a variety requested EID.  The Map-Referral also gives the RLOCs
   of functions, including 'gleaning' (see
   Section 8.5).

   Finally, all the message includes a long nonce, for simple, efficient
   protection against offpath attackers (see [Architecture], Section
   "Security-xTRs" machines which are DDT servers for more), that block. and a variety the MR
   can then send Map-Requests to any one (or all) of other fields and control
   flag bits.

9.2.2.  Map-Reply Maessages

   The Map-Reply message looks similar, except it includes them.

   Control flags in the mapping
   entry for Map-Referral indicate to the requested EID(s), which contains one querying MR whether
   the referral is to another DDT node, an MS, or more RLOCs and
   their associated data.  (Note that an ETR.  If the reply may cover a larger block
   of
   former, the EID namespace than MR then sends the request; most requests will be for a
   single EID, Map-Request to the one which prompted child DDT node,
   repeating the query.)

   For each RLOC in process.

   If the entry, there is latter, the RLOC, its AFI (of course),
   priority and weight fields (see Section 5.2), and multicast priority
   and weight fields.

9.2.3.  Map-Register and Map-Notify Messages

   The Map-Register message contains authentication information, MR then interacts with that MS, and usually the
   block's ETR(s) as well, to cause a
   number of mapping records, each with an individual Time-To-Live
   (TTL).  Each of to be sent to the records contains an EID (potentially, a block of
   EIDs) and its AFI, a version number ITR
   which queried the MR for this mapping (see
   Section 11.1), and a number it.  (Recall that some MS's provide Map-
   Replies on behalf of RLOCs and their AFIs.

   Each RLOC entry also includes the same data as an associated ETR, so in such cases the Map-Replies
   (i.e. priority and weight); Map-
   Reply will come from the MS, not the ETR. {{I think this is because case has
   been mentioned already; check.}})

   Delegations are cached in some circumstances the MRs, so that once an MR has received
   information about a delegation, it
   is advantageous will not need to allow the MS look that up
   again.  Once it has been in operation for a short while, it will only
   need to proxy reply on ask for delegation information which is has not yet asked
   about - probably only the ETR's behalf last stage in a delegation to
   Map-Request messages.  [Mobility]

   Map-Notify messages have the exact same contents as Map-Register
   messages; they are purely acknowledgements.

9.2.4. a 'leaf' MS.

   As describe below (Section 10.6), significant amounts of modeling and
   performance measurement have been performed, to verify that DDT has
   (and will continue to have) acceptable performance.

10.2.1.  Map-Referral Messages

   Map-Referral messages look almost identical to Map-Reply messages
   (which is felt to be an advantage by some people, although having a
   more generic record-based format would probably be better in the long
   run, as ample long
   run, as ample experience with DNS has shown), except that the RLOCs
   potentially name either i) other DDT nodes (children in the
   delegation tree), or ii) terminal MSs.

10.3.  Reliability via Replication

   Everywhere throughout the mapping system, robustness to operational
   failures is obtained by replicating data in multiple instances of any
   particular node (of whatever type).  Map-Resolvers, Map-Servers, DDT
   nodes, ETRs - all of them can be replicated, and the protocol
   supports this replication.

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

   There are generally no mechanisms specified yet to ensure coherence
   between multiple copies of any particular data item, etc - 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 the existing mechanisms.

10.4.  Security of the DDT Indexing Sub-system

   LISP provides an advanced model for securing the mapping indexing
   system, in line with the overall LISP security philosophy.

   Briefly, securing the mapping indexing system is broken into two
   parts: the interface between the clients of the system (MR's) and the
   mapping indexing system itself, and the interaction between the DDT
   nodes/servers which make it up.

   The client interface provides only a single model, using the
   'canonical' public-private key system (starting from a trust anchor),
   in which the child's public key is provided by the parent, along with
   the delegation.  This requires very little configuration in the
   clients, and is fairly secure.

   The interface between the DDT nodes/servers allows for choices
   between a number of different options, allowing the operators to
   trade off among configuration complexity, security level, etc.  This
   is based on experience with DNS has shown), except that the RLOCs
   potentially name either i) other DDT nodes (children DNS-SEC ([RFC4033]), where configuration
   complexity in the
   delegation tree), or ii) terminal MSs.

   There are also optional authentication fields; see [Architecture], servers has been a major stumbling block to
   deployment.

   See [Perspective], Section "Security-Mappings" for more.

9.3.  Reliability via Replication

   Everywhere throughout the mapping system, robustness

10.5.  Extended Tools

   In addition to operational
   failures is obtained by replicating the priority and weight data items in multiple instances mappings, LISP
   offers other tools to enhance functionality, particularly in the
   traffic engineering area.

   One is 'source-specific mappings', i.e. the ETR may return different
   mappings to the enquiring ITR, depending on the identity of any
   particular node (of whatever type).  Map-Resolvers, Map-Servers, DDT
   nodes, ETRs - all the ITR.
   This allows very fine-tuned traffic engineering, far more powerful
   than routing-based TE.

10.6.  Performance of them can be replicated, and the protocol
   supports this replication.

   There are generally no mechanisms specified yet Mapping System

   Prior to ensure coherence
   between multiple copies the creation of any particular data item, etc - this is
   currently DDT, a manual responsibility.  If large study of the performance of the
   previous mapping system, ALT ([ALT]), along with a proposed new
   design called TREE (which used DNS to hold delegation information)
   provided considerable insight into the likely performance of the
   mapping systems at larger scale.  [Jakab] The basic structure and
   concepts of DDT are identical to those of TREE, so the performance
   simulation work done for that design applies aequally to DDT.

   In that study, 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]), and when LISP protocol
   adoption proceeds, the other was an automated layer even large university, with roughly
   35,000 users.

   The results showed that a system like DDT, which caches information
   about delegations, and allows the MR to perform this functionality
   can 'easily' be layered communicate directly with the
   lower nodes on top the delegation hierarchy based on cached delegation
   information, would have good performance, with average resolution
   times on the order of the existing mechanisms.

9.4.  Extended Tools

   In addition MR to MS RTT.  This verified the priority and weight data items
   effectiveness of this particular type of indexing system.

   A more recent study, [Saucez], has measured actual resolution times
   in mappings, the deployed LISP
   offers other tools to enhance functionality, particularly network; it took measurements from a variety of
   locations in the
   traffic engineering area.  One are 'source-specific mappings', i.e.
   the ETR may return Internet, with respect to a number of different mappings
   target EIDs.  Average measured resolution delays ranged from roughly
   175 msec to the enquiring ITR, 225 msec, depending on the identity of the ITR.  This allows very fine-tuned traffic
   engineering, far more powerful than routing-based TE.

9.5.  Expected Performance

   {{To be written.}}

10. location.

11.  Deployment Mechanisms

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

11.1.  LISP Deployment Needs

   As mentioned earlier (Section 3.2), LISP requires no change to almost
   all existing hosts and routers.  Obviously, however, one must deploy
   _something_ to run LISP!  Exactly what that has to be will depend
   greatly on the details of the site's existing networking gear.

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

   LISP also requires a small amount of LISP-specific support
   infrastructure, such as MRs, MSs, the DDT hierarchy, etc but much of
   this will either i) already be deployed, and if the new site can make
   arrangements to deal with.

10.1. use it, it need do nothing else, or ii) those
   functions it must provide may be co-located in other LISP devices
   (again, either new devices, or new software on existing ones).

11.2.  Internetworking Mechanism

   One aspect which has received a lot of attention are the mechanisms
   previously referred to (in Section 3.4) 4.4) to allow interoperation of
   LISP sites with so-called 'legacy' sites which are not running LISP
   (yet).

   To briefly refresh what was said there, there are two main approaches
   to such interworking: proxy nodes (PITRs and PETRs), and an
   alternative mechanism using device with combined NAT and LISP
   functionality; these are described in more detail here.

10.2.

11.3.  Proxy Devices

   PITRs (proxy ITRs) serve as ITRs for traffic _from_ legacy hosts to
   nodes using LISP.  PETRs (proxy ETRs) serve as ETRs for LISP traffic
   _to_ legacy hosts (for cases where a LISP device cannot send packets
   directly to such sites, hosts, without encapsulation).

   Note that return traffic _to_ a legacy site host from 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 the ultimate
   destination.  However, for some kinds of LISP operation (e.g. mobile
   nodes), this is not possible; in these situations, the PETR is
   needed.

10.2.1.

11.3.1.  PITRs

   PITRs (proxy ITRs) serve as ITRs for traffic _from_ legacy hosts to
   nodes using LISP.  To do that, they have to advertise into the
   existing legacy backbone Internet routing 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 to those
   LISP nodes.

   As mentioned previously (Section 8.1), 9.1), an ITR at another LISP site
   can avoid using a PITR (i.e. it can detect that a given ultimate
   destination is not a legacy site, host, if a PITR is advertising it into
   the DFZ) by checking to see if a LISP mapping exists for that
   ultimate destination.

   This technique obviously has an impact on routing table in the DFZ,
   but it is not clear yet exactly what that impact will be; it is very
   dependent on the collected details of many individual deployment
   decisions.

   A PITR may cover a group of EID blocks with a single EID
   advertisement, in order to reduce the number of routing table entries
   added.  (In fact, at the moment, aggressive aggregation of EID
   announcements is performed, precisely to to minimize the number of
   new announced routes added by this technique.)

   At the same time, it if a site does traffic engineering with LISP
   instead of fine-grained BGP announcement, that will help keep table
   sizes down (and this is true even in the early stages of LISP
   deployment).  The same is true for multi-homing.

10.2.2.

11.3.2.  PETRs

   PETRs (proxy ETRs) serve as ETRs for LISP traffic _to_ legacy hosts,
   for cases where a LISP device cannot send packets to sites such hosts
   without encapsulation.  That typically happens for one of two
   reasons.

   First, it will happen in places where some device is implementing
   Unicast Reverse Path Forwarding (uRPF), to prevent a variety of
   negative behaviour; originating packets with the original source's
   EID in the source address field will result in them being filtered
   out and discarded.

   Second, it will happen when a LISP site wishes to send packets to a
   non-LISP site, and the path in between does not support the
   particular IP protocol version used by the original source along its entir
   entire length.  Use of a PETR on the other side of the 'gap' will
   allow the LISP site's packet to 'hop over' the gap, by utilizing
   LISP's built-in support for mixed protocol encapsulation.

   PETRs are generally paired with specific ITRs, which have the
   location of their PETRs configured into them.  In other words, unlike
   normal ETRS, PETRs do not have to register themselves in the mapping
   database, on behalf of any legacy sites they serve.

   Also, allowing an ITR to always send traffic leaving a site to a PETR
   does avoid having to chose whether or not to encapsulate packets; it
   can just always encapsulate packets, sending them to the PETR if it
   has no specific mapping for the ultimate destination.  However, this
   is not advised: as mentioned, it is easy to tell if something is a
   legacy destination.

10.3.

11.4.  LISP-NAT

   A LISP-NAT device, as previously mentioned, combines LISP and NAT
   functionality, in order to allow a LISP site which is internally
   using addresses which cannot be globally routed to communicate with
   non-LISP sites elsewhere in the Internet.  (In other words, the
   technique used by the PITR approach simply cannot be used in this
   case.)

   To do this, a LISP-NAT performs the usual NAT functionality, and
   translates a host's source address(es) in packets passing through it
   from an 'inner' value to an 'outer' value, and storing that
   translation in a table, which it can use to similarly process
   subsequent packets (both outgoing and incoming).  [Interworking]

   There are two main cases where this might apply:
   -  Sites using non-routable global addresses
   -  Sites using private addresses [RFC1918]

10.4.  LISP and DFZ Routing

   {{To be written.}}

10.5.

11.5.  Use Through NAT Devices

   Like them or not (and NAT devices have many egregious issues - some
   inherent in the nature of the process of mapping addresses; others,
   such as the brittleness due to non-replicated critical state, caused
   by the way NATs were introduced, as stand-alone 'invisible' boxes),
   NATs are both ubiquitous, and here to stay for a long time to come.

   Thus, in the actual Internet of today, having any new mechanisms
   function well in the presence of NATs (i.e. with LISP xTRs behind a
   NAT device) is absolutely necessary.  LISP has produced a variety of
   mechanisms to do this.

10.5.1.

11.5.1.  First-Phase NAT Support

   The first mechanism used by LISP to operate through a NAT device only
   worked with some NATs, those which were configurable to allow inbound
   packet traffic to reach a configured host.

   A pair of new LISP control messages, LISP Echo-Request and Echo-
   Reply, allowed the ETR to discover its temporary global address; the
   Echo-Request was sent to the configured Map-Server, and it replied
   with an Echo-Reply which included the source address from which the
   Echo Request was received (i.e. the public global address assigned to
   the ETR by the NAT).  The ETR could then insert that address in any
   Map-Reply control messages which it sent to correspondent ITRs.

   The fact that this mechanism did not support all NATs, and also
   required manual configuration of the NAT, meant that this was not a
   good solution; in addition, since LISP expects all incoming data
   traffic to be on a specific port, it was not possible to have
   multiple ETRs behind a single NAT (which normally would have only one
   global address to share, meaning port mapping would have to be used,
   except that... )

10.5.2.

11.5.2.  Second-Phase NAT Support

   For a more comprehensive approach to support of LISP xTR deployment
   behind NAT devices, a fairly extensive supplement to LISP, LISP NAT
   Traversal, has been designed.  [NAT]  [LISP-NAT]

   A new class of LISP device, the LISP Re-encapsulating Tunnel Router
   (RTR), passes traffic through the NAT, both to and from the xTR.
   (Inbound traffic has to go through the RTR as well, since otherwise
   multiple xTRs could not operate behind a single NAT, for the
   'specified port' reason in the section above.)

   (Had the Map-Reply included a port number, this could have been
   avoided - although of course it would be possible to define a new
   RLOC type which included protocol and port, to allow other
   encapsulation techniques.)

   Two new LISP control messages (Info-Request and Info-Reply) allow an
   xTR to detect if it is behind a NAT device, and also discover the
   global IP address and UDP port assigned by the NAT to the xTR.  A
   modification to LISP Map-Register control messages allows the xTR to
   initialize mapping state in the NAT, in order to use the RTR.

   This mechanism addresses cases where the xTR is behind a NAT, but the
   xTR's associated MS is on the public side of the NAT; this
   limitation, that MS's must be in the 'public' part of the Internet,
   seems reasonable.

11.  Current Improvements

   In line with the philosophies laid out in Section 7, LISP is
   something of a moving target.  This section discusses some of the
   contemporaneous improvements being made to LISP.

11.1.  Mapping Versioning

   As mentioned, LISP has been under development NAT, for a considerable
   time.  One early addition to LISP (it is already part of the base
   specification) is mapping versioning; i.e.
   'specified port' reason in the application section above.)

   (Had the Map-Reply included a port number, this could have been
   avoided - although of
   identifying sequence numbers course it would be possible to different versions of define a mappping.
   [Versioning] This allows an ITR new
   RLOC type which included protocol and port, to easily discover when a cached
   mapping has been updated by a more recent variant.

   Version numbers are available in allow other
   encapsulation techniques.)

   Two new LISP control messages (Map-Replies), but
   the initial concept is that to limit control message overhead, the
   versioning mechanism should primarily use the multiplex user data
   header control channel (see Section 8.3).

   Versioning can operate in both directions: an ITR can advise (Info-Request and Info-Reply) allow an ETR
   what version of a mapping it is currently using (so the ETR can
   notify it
   xTR to detect if there it is behind a more recent version), NAT device, and ETRs can let ITRs
   know what also discover the current mapping version is (so
   global IP address and UDP port assigned by the ITRs can request an
   update, if their copy is outdated).

   At NAT to the moment version numbers are manually assigned, and ordered.
   Some felt that this was non-optimal, and that a better approach would
   have been xTR.  A
   modification to have 'fingerprints' which were computed from LISP Map-Register control messages allows the current xTR to
   initialize mapping data (i.e. a hash).  It is not clear that state in the NAT, in order to use the RTR.

   This mechanism addresses cases where the ordering buys
   much (if anything), and xTR is behind a NAT, but the potential for mishaps with manually
   configured version numbers
   xTR's associated MS is self-evident.

11.2.  Replacement on the public side of ALT with DDT

   As mentioned the NAT; this
   limitation, that MS's must be in Section 9.2, an interface is provided to allow
   replacement the 'public' part of the indexing subsystem. Internet,
   seems reasonable.

11.6.  LISP initially used an
   indexing system called ALT.  [ALT] ALT and DFZ Routing

   One of LISP's original motivations was relatively easy to
   construct from existing tools (GRE, BGP, etc), but it had a number of
   issues that made it unsuitable for large-scale use.  ALT is now being
   superseded by DDT.

   As indicated previously (Section 9.5), the basic structure try and
   operation control the growth
   of DDT is identical to that the size of TREE, so the extensive
   simulation work done for TREE applies equally to DDT, as do so-called 'Default-Free-Zone' (DFZ), the
   conclusions drawn about TREE's superiority to ALT.  [Jakab]

   {{Briefly synopsize results}}

11.2.1.  Why Not Use DNS

   One obvious question is 'Since DDT is so similar to DNS, why not
   simply use DNS?'  In particular, people are familiar with core of
   the DNS,
   how Internet, the part where routes to configure it, etc - would it not thus _all_ destinations must be preferable to use it?
   To completely answer this would take
   available.  As LISP becomes more space that available here,
   but, briefly, there were two main reasons, and one lesser one.

   First, the syntax of DNS names did not lend itself to looking up
   names widely deployed, it can help with
   this issue, in other syntaxes (e.g. bit fields).  This is a problem which
   has been previously encountered, e.g. variety of ways.

   In covering this topic, one must recognize that conditions in reverse address lookups.
   [RFC5855]

   Second, as an existing system, the interfaces between DNS (should it
   have been used as an indexing subsystem for LISP) would not be
   'tuneable' to be optimal various
   stages of LISP deployment (in terms of ubiquity) will have a large
   influence.  [Deployment] introduced useful terminology for LISP.  For instance, if it were desired this
   progression, in addition to have some coverage of the leaf node in an indexing lookup directly contact topic (see Section
   5, "Migration to LISP"):

     The loosely defined terms of "early transition phase", "late
     transition phase", and "LISP Internet phase" refer to time periods
     when LISP sites are a minority, a majority, or represent all edge
     networks respectively.

   In the ETR early phases of deployment, two primary effects will allow
   LISP to have a positive impact on behalf the routing table growth:
   -  Using LISP for traffic engineering instead of BGP
   -  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 the node DFZ routing tables, something doing TE
   with LISP avoids); the lookup (thereby avoiding a round-trip
   delay), that would second is not be easy without modifications guaranteed to the DNS code.
   Obviously, with happen (since it
   requires coordination among a 'custom' system, this issue number of different parties), and only
   time will tell if it does not arise.

   Finally, DNS security, while robust, is fairly complex.  Doing DDT
   offered an opportunity to provide happen.

11.6.1.  Long-term Possibilities

   At a later stage of the deployment, a more nuanced security model.
   (See [Architecture], Section "Security" aggressive approach
   becomes available: taking part of the DFZ, one for more about this.)

11.3.  Mobile Device Support

   Mobility is an obvious capability which all 'stub'
   sites connected to provide it have deployed LISP, and removing all 'EID
   routes' (used for backwards compatability with LISP.  Doing so is
   relatively simple, if 'legacy' sites); only
   RLOC routes would remain in the mobile host is prepared to act as its own
   ETR.  It obtains routing table in that part of the
   Internet backbone.

   Obviously there would be a local 'temporary use' address, boundary between the two parts of the DFZ,
   and registers that
   address as its RLOC.  Packets to the mobile host are sent to its
   temporary address, whereever that may be, routers on the border would have to (effectively) become
   PITRs, and inject routes to all of the mobile host first
   unwraps LISP sites 'behind' them (acting as an ETR), and into
   the processes them normally
   (acting as 'legacy' DFZ (to coin a host).

   (Doing mobility without having name for the mobile host act as its ETR is
   difficult, even if ETRs are quite common.  The reason is that if part of the
   ETR and mobile host are DFZ which, for
   reasons of interoperability with legacy sites, still carries EID
   routes).

   Note that it is likely not integrated, during feasible to have the step from 'RLOC only' part of
   the ETR DFZ in the 'middle' of the DFZ; that would require (effectively)
   EID routes to be removed from BGP on crossing the mobile host, boundary _into_ the packets must contain
   RLOC DFZ, but re-created on crossing the mobile host's EID,
   and this may not be workable.  If there boundary _out_ of the RLOC
   DFZ.  This is likely to be impractical, leading to the suggestion of
   a local router simpler boundary between the
   ETR RLOC-only part of the DFZ, and mobile host, the
   'legacy' DFZ.

   The mechanism for instance, it is unlikely detecting which routes are 'EID routes' and which
   are 'RLOC routes' (required for the boundary routers to know how be able to get
   filter out the packets 'EID routes') would also need to be worked out; the mobile host.)

   If the mobile host migrates
   most likely appears to a site which is itself a be something involving BGP attributes.

12.  Fault Discovery/Handling

   LISP site,
   things get is, in terms of its functionality, a little more complicated.  The 'temporary address' it
   gets fairly simple system: the
   list of failure modes is itself an EID, requiring thus not extensive.

12.1.  Handling Missing Mappings

   Handling of missing mappings is fairly simple: the ITR calls for the
   mapping, and wrapping for transit
   across in the rest of meantime can either discard traffic to that
   ultimate destination (as many ARP implementations do) [RFC826], or,
   if dropping the Internet.  A 'double encapsulation' traffic is thus
   required at deemed undesirable, it can forward them
   via a 'default PITR'.

   A number of PITRs advertise all EID blocks into the other end; backbone routing,
   so that any ITRs which are temporarily missing a mapping can forward
   the packets traffic to these default PITRs via normal transmission methods,
   where they are first encapsulated with
   the mobile node's temporary address as their RLOC, and then this has
   to be looked up in passed on.

12.2.  Outdated Mappings

   If a second lookup cycle (see Section 8.1), and then
   wrapped again, with the site's RLOC as their destination.

   This results in slight loss mapping changes once an ITR has retrieved it, that may result in maximum packet size, due
   traffic to the
   duplicated headers, but on EIDs covered by that mapping failing.  There are three
   cases to consider:

   -  When the whole it ETR traffic is considerably simpler than
   the alternative, which would be being sent to re-wrap the packet at the site's
   ETR, when it is discovered still a valid ETR for
      that EID, but the destination's EID was not
   'native' mapping has been updated (e.g. to change the site.  This would require that
      priority of various ETRs)
   -  When the mobile node's ETR traffic is being sent to is still an ETR, but no
      longer a valid ETR for that EID
   effectively have two different mappings, depending on whether
   -  When the
   lookup was ETR traffic is being performed outside the LISP site, or inside.

   {{Also probably need sent to mention briefly how the other end is notified
   when no longer an ETR

12.2.1.  Outdated Mappings - Updated Mapping

   A 'mapping versioning' system, whereby mappings have version numbers,
   and ITRs are updated, notified when their mapping is out of date, has been
   added to detect this, and about proxy-Map-Replies.}} [Mobility]

11.4.  Multicast Support

   Multicast may seem the ITR responds by refreshing the mapping.
   [Versioning]

12.2.2.  Outdated Mappings - Wrong ETR

   If an odd thing to support with LISP, since LISP ITR is
   all about separating identity from location, but although holding a multicast
   group in some sense has an identity, seriously outdated cached mapping, it certainly does not have _a_
   location.

   However, multicast is important may send
   packets to some users of the network, an ETR which is no longer an ETR for a
   number of reasons: doing multiple unicast streams that EID.

   It might be argued that if the ETR is inefficient; properly managing the lifetimes
   on its mapping entries, this 'cannot happen', but it is easy a wise design
   methodology to use up all the upstream bandwidth, assume that 'cannot happen' events will in fact happen
   (as they do, due to software errors, or, on rare occasions, hardware
   faults), and without multicast a
   server can also be saturated fairly easily ensure that the system will handle them properly (if,
   perhaps not in doing the unicast
   replication.  So it is important for LISP most expeditious, or 'clean' way - they are, after
   all, very unlikely to 'play nicely' with
   multicast; work on multicast support happen).

   ETRs can easily detect cases where this happpens, after they have un-
   wrapped a user data packet; in LISP is fairly advanced,
   although not far-ranging.

   Briefly, destination group addresses are not mapped; only response, they send a Solicit-Map-
   Request to the source
   address (when ITR to cause it to refresh its mapping.

12.2.3.  Outdated Mappings - No Longer an ETR

   In another case for what can happen if an ITR uses an outdated
   mapping, the source is inside destination of traffic from an ITR might no longer be a
   LISP site) needs to be mapped,
   both during distribution tree setup, as well as actual traffic
   delivery. device at all.  In other words, LISP's mapping capability isa used: such cases, one might get an ICMP Destination
   Unreachable error message.  However, one cannot depend on that - and
   in any event, that would provide an attack vector, so it is
   just applied to the source, not the destination (as should be
   used with most LISP
   activity); care.  (See [LISP], Section 6.3, "Routing Locator
   Reachability" for more about this.)

   The following mechanism will work, though.  Since the inner source destination is
   not an ETR, the EID, and echoing reachability detection mechanism (see
   Section 9.3.2) will detect a problem.  At that point, the outer source is backstop
   mechanism, Probing, will kick in.  Since the
   EID's RLOC.

   Note destination is still not
   an ETR, that this does mean will fail, too.

   At that if the group is using separate source-
   specific trees for distribution, there isn't point, traffic will be switched to a separate distribution
   tree outside the LISP site for each different source ETR, or, if
   none are available, a reload of traffic to
   the group from inside the LISP site; they are all lumped together
   under mapping may be initiated.

12.3.  Erroneous Mappings

   Again, this 'should not happen', but a single source, good system should deal with
   it.  However, in practise, should this happen, it will produce one of
   the RLOC.

   The approach currently used by LISP requires no prior two cases (the wrong ETR, or something that is not an ETR),
   and will be handled as described there.

12.4.  Neighbour Liveness

   The ITR, like all packet format changes switches, needs to existing multicast protocols.  See [Multicast] for more;
   additional LISP multicast issues are discussed in [LISP], Section 12.

11.5.  {{Any others?}}

12.  Fault Discovery/Handling

   LISP is, in terms of detect, and react, when
   its functionality, next-hop neighbour ceases operation.  As LISP traffic is
   effectively always unidirectional (from ITR to ETR), this could be
   somewhat problematic.

   Solving a fairly simple system: related problem, neighbour reachability (below) subsumes
   handling this fault mode, however.

   Note that the
   list two terms (liveness and reachability) are _not_
   synonmous (although a lot of failure modes LISP documentation confuses them).
   Liveness is thus not extensive.

12.1.  Handling Missing Mappings

   Handling a property of missing mappings a node - it is fairly simple: the ITR calls for the
   mapping, and in the meantime can either discard traffic to the
   destination (as many ARP implementations do) [RFC826], or, if
   dropping the traffic is deemed undesirable, up and functioning,
   or it can forward them via is not.  Reachability is only a
   'default PITR'.

   A number property of PITRs advertise all EID blocks into the backbone routing,
   so that any ITRs which are temporarily missing a mapping can forward
   the traffic to these default PITRs via normal transmission methods,
   where they are encapsulated and passed on.

12.2.  Outdated Mappings particular _pair_
   of nodes.

   If packets sent from a mapping changes once an ITR has retrieved it, that may result in
   traffic first node to the EIDs covered by that mapping failing.  There a second are three
   cases to consider:

   -  When successfully
   received at the second, it is 'reachable' from the first.  However,
   the second node may at the ETR traffic is being sent to very same time _not_ be reachable from
   some other node.  Reachability is still _always_ a valid ordered pairwise
   property, and of a specified ordered pair.

12.5.  Neighbour Reachability

   A more significant issue than whether a particular ETR for E is up or not
   is, as mentioned above, that EID, but the mapping has been updated (e.g. although ETR E may be up, attached to change
   the
      priority of various ETRs)
   -  When network, etc, an issue in the ETR network between a source ITR I and
   E may prevent traffic is being sent from I from getting to is still an ETR, but no
      longer E. (Perhaps a valid ETR for that EID
   -  When the ETR routing
   problem, or perhaps some sort of access control setting.)

   The one-way nature of LISP traffic is being sent makes this situation hard to
   detect in a way which is no longer an ETR

12.2.1.  Outdated Mappings - Updated Mapping

   A 'mapping versioning' system, whereby mappings have version numbers, economic, robust and ITRs are notified when their mapping is fast.  Two out of date, has been
   added to detect this, and the ITR responds by refreshing
   three are usually not to hard, but all three at the mapping.
   [Versioning]

12.2.2.  Outdated Mappings same time - Wrong ETR

   {{To be written.}}

12.2.3.  Outdated Mappings as is
   highly desirable for this particular issue - No Longer an ETR

   If are harder.

   In line with the LISP design philosophy ([Perspective], Section
   "Design-Theoretical"), this problem is attacked not with a single
   mechanism (which would have a hard time meeting all those three goals
   simultaneously), but with a collection of simpler, cheaper
   mechanisms, which collectively will usually meet all three.

   They are reliance on the destination underlying routing system (which can of
   course only reliably provide a negative reachabilty indication, not a
   positive one), the echo nonce (which depends on some return traffic
   from an ITR is no longer an ETR, one
   might get an ICMP Destination Unreachable error message.  However,
   one cannot depend on that.  The following mechanism will work,
   though.

   Since the destination xTR back to the source xTR), and finally direct
   'pinging', in the case where no positive echo is returned.

   (The last is not an ETR, the echoing reachability
   detection first choice, as due to the large fan-out
   expected of LISP devices, reliance on it as a sole mechanism (see Section 8.3.1) will detect would
   produce a problem.  At
   that point, fair amount of overhead.)

13.  Current Improvements

   In line with the backstop mechanism, Probing, will kick in.  Since philosophies laid out in Section 8, LISP is
   something of a moving target.  This section discusses some of the
   destination
   contemporaneous improvements being made to LISP.

13.1.  Improved NAT Support

13.2.  Mobile Device Support

   Mobility is still not an ETR, that will fail, too.

   At obvious capability to provide with LISP.  Doing so is
   relatively simple, if the mobile host is prepared to act as its own
   ETR.  It obtains a local 'temporary use' address, and registers that point, traffic will be switched
   address as its RLOC.  Packets to the mobile host are sent to its
   temporary address, wherever that may be, and the mobile host first
   unwraps them (acting as an ETR), and the processes them normally
   (acting as a different ETR, or, host).

   (Doing mobility without having the mobile host act as its ETR is
   difficult, even if
   none ETRs are available, a re-map may be requested.

12.3.  Erroneous mappings

   {{To be written.}}

12.4.  Neighbour Liveness quite common.  The ITR, like all packet switches, needs to detect, and react, when
   its next-hop neighbour ceases operation.  As LISP traffic reason is
   effectively always unidirectional (from ITR that if the
   ETR and mobile host are not integrated, during the step from the ETR
   to ETR), the mobile host, the packets must contain the mobile host's EID,
   and this could may not be
   somewhat problematic.

   Solving workable.  If there is a related problem, neighbour reachability (below) subsumes
   handling this fault mode, however.

   Note that local router between the two terms (liveness
   ETR and reachability) are _not_
   synonmous (although mobile host, for instance, it is unlikely to know how to get
   the packets to the mobile host.)

   If the mobile host migrates to a lot of LISP documentation confuses them).
   Liveness site which is itself a property of LISP site,
   things get a node - little more complicated.  The 'temporary address' it
   gets is either up itself an EID, requiring mapping, and functioning,
   or it is not.  Reachability is only a property of a particular _pair_ wrapping for transit
   across the rest of nodes.

   If the Internet.  A 'double encapsulation' is thus
   required at the other end; the packets sent from a are first node encapsulated with
   the mobile node's temporary address as their RLOC, and then this has
   to be looked up in a second are successfully
   received at lookup cycle (see Section 9.1), and then
   wrapped again, with the site's RLOC as their destination.

   This results in slight loss in maximum packet size, due to the second,
   duplicated headers, but on the whole it is 'reachable' from considerably simpler than
   the first.  However, alternative, which would be to re-wrap the second node may packet at the very same time _not_ be reachable from
   some other node.  Reachability is _always_ a ordered pairwise
   property, and of a specified ordered pair.

12.5.  Neighbour Reachability

   A more significant issue than whether a particular ETR E site's
   ETR, when it is up or not
   is, as mentioned above, discovered that although ETR E may be up, attached the ultimate destination's EID was
   not 'native' to the network, etc, an issue in site.  This would require that the network between a source ITR I mobile node's
   EID effectively have two different mappings, depending on whether the
   lookup was being performed outside the LISP site, or inside.

   {{Also probably need to mention briefly how the other end is notified
   when mappings are updated, and
   E about proxy-Map-Replies.}} [Mobility]

13.3.  Multicast Support

   Multicast may prevent traffic from I from getting seem an odd thing to E. (Perhaps support with LISP, since LISP is
   all about separating identity from location, but although a routing
   problem, or perhaps multicast
   group in some sort sense has an identity, it certainly does not have _a_
   location.

   However, multicast is important to some users of access control setting.)

   The one-way nature the network, for a
   number of reasons: doing multiple unicast streams is inefficient; it
   is easy to use up all the upstream bandwidth, and without multicast a
   server can also be saturated fairly easily in doing the unicast
   replication.  So it is important for LISP traffic makes this situation hard to
   detect 'play nicely' with
   multicast; work on multicast support in a way which LISP is economic, robust and fast.  Two out of the
   three fairly advanced,
   although not far-ranging.

   Briefly, destination group addresses are usually not to hard, but all three at mapped; only the same time - as source
   address (when the original source is
   highly desirable for this particular issue - are harder. inside a LISP site) needs to be
   mapped, both during distribution tree setup, as well as actual
   traffic delivery.  In line with other words, LISP's mapping capability is used:
   it is just applied to the source, not the destination (as with most
   LISP design philosophy (Section 7.3), activity); the inner source is the EID, and the outer source is
   the EID's RLOC.

   Note that this problem does mean that if the group is attacked not with a single mechanism (which would have a hard time
   meeting all those three goals simultaneously), but with using separate source-
   specific trees for distribution, there isn't a collection
   of simpler, cheaper mechanisms, which collectively will usually meet
   all three.

   They are reliance on separate distribution
   tree outside the underlying routing system (which can LISP site for each different source of
   course only reliably provide a negative reachabilty indication, not a
   positive one), the echo nonce (which depends on some return traffic
   from the destination xTR back to
   the source), and finally direct
   'pinging', in group from inside the case where no positive echo is returned.

   (The last is not LISP site; they are all lumped together
   under a single source, the first choice, as due RLOC.

   The approach currently used by LISP requires no packet format changes
   to the large fan-out
   expected of existing multicast protocols.  See [Multicast] for more;
   additional LISP devices, reliance on it as a sole mechanism would
   produce a fair amount of overhead.)

13. multicast issues are discussed in [LISP], Section 12.

13.4.  {{Any others?}}

14.  Acknowledgments

   The author would like thank to start by thanking all the members of 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) Vina Ermagan,
   Vince Fuller, Fuller and especially Joel Halpern Vasileios Lakafosis for their careful review of, and
   helpful suggestions for, this document.  (If I have missed anyone in
   this list, I apologize most profusely.)  A very special thank you
   goes to Joel Halpern, who, when asked, promptly returned comments on
   intermediate versions of this document.  Grateful thanks go also to
   Darrel Lewis for his help with material on non-
   Internet non-Internet uses of LISP,
   and to Vince Fuller and Dino Farinacci for help with XML. answering detailed
   questions about some obscure LISP topics.

   A final thanks is due to John Wrocklawski for the author's
   organizational affiliation. affiliation, and to Vince Fuller for help with XML.
   This memo was created using the xml2rfc
   tool

14. tool.

   I would like to dedicate this document to the memory of my parents,
   who gave me so much, and whom I can no longer thank in person, as I
   would have so much liked to be able to.

15.  IANA Considerations

   This document makes no request of the IANA.

15.

16.  Security Considerations

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

16.

17.  References

16.1.

17.1.  Normative References

   [RFC768]        J. Postel, "User Datagram Protocol", RFC 768,
                   August 1980.

   [RFC791]        J. Postel, "Internet Protocol", RFC 791,
                   September 1981.

   [RFC1498]       J. H. Saltzer, "On the Naming and Binding of Network
                   Destinations", RFC 1498, (Originally published in:
                   "Local Computer Networks", edited by P. Ravasio et
                   al., North-Holland Publishing Company, Amsterdam,
                   1982, pp. 311-317.), August 1993.

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

   [Architecture]  J. N. Chiappa, "An Architectural Perspective on the
                   LISP Location-Identity

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

   [LISP]          D. Farinacci, V. Fuller, D. Meyer, and D. Lewis, "The
                   Locator/ID Separation System",
                   draft-ietf-lisp-architecture-00 (work in progress),
                   October 2012. Protocol (LISP)", RFC 6830,
                   January 2013.

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

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

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

   [DDT]           V. Fuller, D. Lewis, and D. Farinacci, "LISP
                   Delegated Database Tree", draft-fuller-lisp-ddt-01 draft-ietf-lisp-ddt-00
                   (work in progress), March October 2012.

   [Perspective]   J. N. Chiappa, "An Architectural Perspective on the
                   LISP Location-Identity Separation System",
                   draft-ietf-lisp-perspective-00 (work in progress),
                   February 2013.

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

   [Interworking]  D. Lewis, D. Meyer, D. Farinacci, and

   [LISP-SEC]      F. Maino, V. Fuller,
                   "Interworking LISP with IPv4 Ermagan, A. Cabellos-Aparicio,
                   D. Saucez, and IPv6",
                   draft-ietf-lisp-interworking-06 O. Bonaventure, "LISP-Security (LISP-
                   SEC)", draft-ietf-lisp-sec-04 (work in progress),
                   March
                   October 2012.

   [LISP]          D. Farinacci,

   [LISP-NAT]      V. Fuller, Ermagan, D. Meyer, and Farinacci, D. Lewis,
                   "Locator/ID Separation Protocol (LISP)",
                   draft-ietf-lisp-23 J. Skriver,
                   F. Maino, and C. White, "NAT traversal for LISP",
                   draft-ermagan-lisp-nat-traversal-03 (work in
                   progress), May 2012. March 2013.

   [Mobility]      D. Farinacci, V. Fuller, D. Lewis, and D. Meyer,
                   "LISP Mobility Architecture", draft-meyer-lisp-mn-07
                   (work in progress), April 2012.

   [Multicast]     D. Farinacci, D. Meyer, J. Zwiebel, and S. Venaas,
                   "LISP
                   "The Locator/ID Separation Protocol (LISP) for
                   Multicast Environments",
                   draft-ietf-lisp-multicast-14 (work in progress),
                   February 2012.

   [NAT]           V. Ermagan, D. Farinacci, D. Lewis, J. Skriver, RFC 6831, January 2013.

   [Deployment]    L. Jakab, A. Cabellos-Aparicio, F. Maino, Coras, J. Domingo-
                   Pascual, and C. White, "NAT traversal for LISP",
                   draft-ermagan-lisp-nat-traversal-01 (work in
                   progress), March 2012.

   [Versioning]    L. Iannone, D. Saucez, and O. Bonaventure, Lewis, "LISP
                   Mapping Versioning",
                   draft-ietf-lisp-map-versioning-09 Network Element
                   Deployment Considerations",
                   draft-ietf-lisp-deployment-08 (work in progress),
                   March 2012.

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

16.2.
                   June 2013.

17.2.  Informative References

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

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

   [RFC826]        D. Plummer, "Ethernet Address Resolution Protocol",
                   RFC 826, November 1982.

   [RFC1034]       P. V. Mockapetris, "Domain Names - Concepts and
                   Facilities", RFC 1034, November 1987.

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

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

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

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

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

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

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

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

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

   [RFC4984]       D. Meyer, L. Zhang, and K. Fall, "Report from the IAB
                   Workshop on Routing and Addressing", RFC 4984,
                   September 2007.

   [RFC5855]       J. Abley and T. Manderson, "Nameservers for IPv4 and
                   IPv6 Reverse Zones", RFC 5855, May 2010.

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

   [ALT]

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

                   Perhaps the most ill-named RFC of all time; it
                   contains nothing that could truly be called a
                   'routing architecture'.

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

   [ALT]           V. Fuller, D. Farinacci, D. Meyer, and D. Lewis,
                   "LISP
                   "Locator/ID Separation Protocol Alternative Logical
                   Topology (LISP-ALT)",
                   draft-ietf-lisp-alt-10 (work in progress),
                   December 2011. (LISP+ALT)", RFC 6836, January 2013.

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

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

   [Chiappa]       J. N. Chiappa, "Endpoints and Endpoint Names: A
                   Proposed Enhancement to the Internet Architecture",
                   Personal draft (work in progress), 1999,
                   <http://www.chiappa.net/~jnc/tech/endpoints.txt>.

   [Clark]         D. D. Clark, "The Design Philosophy of the DARPA
                   Internet Protocols", in 'Proceedings of the Symposium
                   on Communications Architectures and Protocols SIGCOMM
                   '88', pp. 106-114, 1988.

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

   [Bibliography]  J. N. Chiappa (editor), "LISP (Location/Identity
                   Separation Protocol) Bibliography", Personal
                   site (work in progress), July 2013, <http://
                   www.chiappa.net/~jnc/tech/lisp/LISPbiblio.html>.

   [Iannone]       L. Iannone and O. Bonaventure, "On the Cost of
                   Caching Locator/ID Mappings", in 'Proceedings of the
                   3rd International Conference on emerging Networking
                   EXperiments and Technologies (CoNEXT'07)', ACM, pp.
                   1-12, December 2007.

   [Kim]           J. Kim, L. Iannone, and A. Feldmann, "A Deep Dive
                   Into the LISP Cache and What ISPs Should Know About
                   It", in 'Proceedings of the 10th International IFIP
                   TC 6 Conference on Networking - Volume Part I
                   (NETWORKING '11)', IFIP, pp. 367-378, May 2011.

   [CorasCache]    F. Coras, A. Cabellos-Aparicio, and J. Domingo-
                   Pascual, "An Analytical Model for the LISP Cache
                   Size", in 'Proceedings of the 11th International IFIP
                   TC 6 Networking Conference: Part I', IFIP, pp. 551-567. 409-
                   420, May 2012.

   [Jakab]         L. Jakab, A. Cabellos-Aparicio, F. Coras, D. Saucez,
                   and O. Bonaventure, "LISP-TREE: A DNS Hierarchy to
                   Support the LISP Mapping System", in 'IEEE Journal on
                   Selected Areas in Communications', Vol. 28, No. 8,
                   pp. 1332-1343, October 2010.

   [Iannone]

   [Saucez]        D. Saucez, L. Iannone Iannone, and O. Bonaventure, "On B. Donnet, "A First
                   Measurement Look at the Cost Deployment and Evolution of
                   Caching
                   the Locator/ID Mappings", Separation Protocol", in 'ACM SIGCOMM
                   Computer Communication Review', Vol. 43 No. 2, pp.
                   37-43, April 2013.

   [CorasBGP]      F. Coras, D. Saucez, L. Jakab, A. Cabellos-Aparicio,
                   and J. Domingo-Pascual, "Implementing a BGP-free ISP
                   Core with LISP", in 'Proceedings of the
                   3rd International Global
                   Communications Conference on emerging Networking
                   EXperiments and Technologies (CoNEXT'07)', ACM, (GlobeCom)', IEEE, pp.
                   1-12,
                   2772-2778, December 2007. 2012.

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

   [Salvadori]     M. Salvadori and M. Levy, "Why Buildings Fall Down",
                   W. W. Norton, New York, pg. 81, 1992.

Appendix A.  Glossary/Definition of Terms

   -  Address
   -  Locator
   -  EID
   -  RLOC
   -  ITR
   -  ETR
   -  xTR
   -  PITR
   -  PETR
   -  MR
   -  MS
   -  DFZ

Appendix B.  Other Appendices

B.1.  Old LISP 'Models'

   LISP, 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 are briefly described
   here.

   -  LISP 1: EIDs all appear in the normal routing and forwarding
      tables of the network (i.e. they are 'routable');this property is
      used to 'bootstrap' operation, by using this to load EID->RLOC
      mappings.  Packets were sent with the EID as the destination in
      the outer wrapper; when an ETR saw such a packet, it would send a
      Map-Reply to the source ITR, giving the full mapping.
   -  LISP 1.5: Similar to LISP 1, but the routability of EIDs happens
      on a separate network.
   -  LISP 2: EIDs are not routable; EID->RLOC mappings are available
      from the DNS.
   -  LISP 3: EIDs are not routable; and have to be looked up in in a
      new EID->RLOC mapping database (in the initial concept, a system
      using Distributed Hash Tables).  Two variants were possible: a
      'push' system, in which all mappings were distributed to all ITRs,
      and a 'pull' system in which ITRs load the mappings they need, as
      needed.

B.2.  Possible appendices: Other Appendices

   -- Location/Identity Separation Brief History
   -- LISP History
   -- Old models (LISP 1, LISP 1.5, etc)

Author's Address

   J. Noel Chiappa
   Yorktown Museum of Asian Art
   Yorktown, Virginia
   USA

   EMail: jnc@mit.edu