draft-ietf-lisp-introduction-09.txt   draft-ietf-lisp-introduction-10.txt 
Network Working Group A. Cabellos Network Working Group A. Cabellos
Internet-Draft UPC-BarcelonaTech Internet-Draft UPC-BarcelonaTech
Intended status: Informational D. Saucez (Ed.) Intended status: Informational D. Saucez (Ed.)
Expires: May 16, 2015 INRIA Expires: July 24, 2015 INRIA
November 12, 2014 January 20, 2015
An Architectural Introduction to the Locator/ID Separation Protocol An Architectural Introduction to the Locator/ID Separation Protocol
(LISP) (LISP)
draft-ietf-lisp-introduction-09.txt draft-ietf-lisp-introduction-10.txt
Abstract Abstract
This document describes the architecture of the Locator/ID Separation This document describes the architecture of the Locator/ID Separation
Protocol (LISP), making it easier to read the rest of the LISP Protocol (LISP), making it easier to read the rest of the LISP
specifications and providing a basis for discussion about the details specifications and providing a basis for discussion about the details
of the LISP protocols. This document is used for introductory of the LISP protocols. This document is used for introductory
purposes, more details can be found in RFC6830, the protocol purposes, more details can be found in RFC6830, the protocol
specification. specification.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 16, 2015. This Internet-Draft will expire on July 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. LISP Architecture . . . . . . . . . . . . . . . . . . . . . . 4 3. LISP Architecture . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 4 3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 4
3.2. Overview of the Architecture . . . . . . . . . . . . . . 5 3.2. Overview of the Architecture . . . . . . . . . . . . . . 5
3.3. Data-Plane . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Data-Plane . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1. LISP Encapsulation . . . . . . . . . . . . . . . . . 8 3.3.1. LISP Encapsulation . . . . . . . . . . . . . . . . . 8
3.3.2. LISP Forwarding State . . . . . . . . . . . . . . . . 9 3.3.2. LISP Forwarding State . . . . . . . . . . . . . . . . 9
3.4. Control-Plane . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Control-Plane . . . . . . . . . . . . . . . . . . . . . . 9
3.4.1. LISP Mappings . . . . . . . . . . . . . . . . . . . . 10 3.4.1. LISP Mappings . . . . . . . . . . . . . . . . . . . . 10
3.4.2. Mapping System Interface . . . . . . . . . . . . . . 10 3.4.2. Mapping System Interface . . . . . . . . . . . . . . 10
3.4.3. Mapping System . . . . . . . . . . . . . . . . . . . 11 3.4.3. Mapping System . . . . . . . . . . . . . . . . . . . 11
3.5. Interworking Mechanisms . . . . . . . . . . . . . . . . . 14 3.5. Internetworking Mechanisms . . . . . . . . . . . . . . . 14
4. LISP Operational Mechanisms . . . . . . . . . . . . . . . . . 14 4. LISP Operational Mechanisms . . . . . . . . . . . . . . . . . 15
4.1. Cache Management . . . . . . . . . . . . . . . . . . . . 15 4.1. Cache Management . . . . . . . . . . . . . . . . . . . . 15
4.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 15 4.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 16
4.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 17 4.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 17
4.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 17 4.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 17
5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 19
8.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 20 7.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 20
8.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 20 7.3. LISP for Virtual Private Networks . . . . . . . . . . . . 20
8.3. LISP for Virtual Private Networks . . . . . . . . . . . . 21 7.4. LISP for Virtual Machine Mobility in Data Centers . . . . 20
8.4. LISP for Virtual Machine Mobility in Data Centers . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. A Brief History of Location/Identity Separation . . 25 Appendix A. A Brief History of Location/Identity Separation . . 25
A.1. Old LISP Models . . . . . . . . . . . . . . . . . . . . . 25 A.1. Old LISP Models . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
This document introduces the Locator/ID Separation Protocol (LISP) This document introduces the Locator/ID Separation Protocol (LISP)
[RFC6830] architecture, its main operational mechanisms and its [RFC6830] architecture, its main operational mechanisms and its
design rationale. Fundamentally, LISP is built following a well- design rationale. Fundamentally, LISP is built following a well-
known architectural idea: decoupling the IP address overloaded known architectural idea: decoupling the IP address overloaded
semantics. Indeed and as pointed out by [Chiappa], currently IP semantics. Indeed and as pointed out by the unpublished Internet
addresses both identify the topological location of a network Draft by Noel Chiappa [Chiappa], currently IP addresses both identify
attachment point as well as the node's identity. However, nodes and the topological location of a network attachment point as well as the
routing have fundamentally different requirements, routing systems node's identity. However, nodes and routing have fundamentally
require that addresses are aggregatable and have topological meaning, different requirements, routing systems require that addresses are
while nodes require to be identified independently of their current aggregatable and have topological meaning, while nodes require to be
location [RFC4984]. identified independently of their current location [RFC4984].
LISP creates two separate namespaces, EIDs (End-host IDentifiers) and LISP creates two separate namespaces, EIDs (End-host IDentifiers) and
RLOCs (Routing LOCators), both are typically syntactically identical RLOCs (Routing LOCators), both are typically syntactically identical
to the current IPv4 and IPv6 addresses. EIDs are used to uniquely to the current IPv4 and IPv6 addresses. EIDs are used to uniquely
identify nodes irrespective of their topological location and are identify nodes irrespective of their topological location and are
typically routed intra-domain. RLOCs are assigned topologically to typically routed intra-domain. RLOCs are assigned topologically to
network attachment points and are typically routed inter-domain. network attachment points and are typically routed inter-domain.
With LISP, the edge of the Internet (where the nodes are connected) With LISP, the edge of the Internet (where the nodes are connected)
and the core (where inter-domain routing occurs) can be logically and the core (where inter-domain routing occurs) can be logically
separated and interconnected by LISP-capable routers. LISP also separated and interconnected by LISP-capable routers. LISP also
introduces a database, called the Mapping System, to store and introduces a database, called the Mapping System, to store and
retrieve mappings between identity and location. LISP-capable retrieve mappings between identity and location. LISP-capable
routers exchange packets over the Internet core by encapsulating them routers exchange packets over the Internet core by encapsulating them
to the appropriate location. to the appropriate location.
In summary: In summary:
o RLOCs have meaning only in the underlay network o RLOCs have meaning only in the underlay network, that is the
underlying core routing system.
o EIDs have meaning only in the overlay network (unless they are o EIDs have meaning only in the overlay network unless they are
leaked into the underlay network) leaked into the underlay network. The overlay is the
encapsulation relationship between LISP-capable routers.
o The LISP edge maps EIDs to RLOCs o The LISP edge maps EIDs to RLOCs
o Within the underlay network, RLOCs have both locator and o Within the underlay network, RLOCs have both locator and
identifier semantics identifier semantics
o An EID within a LISP site carries both identifier and locator o An EID within a LISP site carries both identifier and locator
semantics to other nodes within that site semantics to other nodes within that site
o An EID within a LISP site carries identifier and limited locator o An EID within a LISP site carries identifier and limited locator
skipping to change at page 4, line 40 skipping to change at page 4, line 33
This document describes the LISP architecture and does not define or This document describes the LISP architecture and does not define or
introduce any new term. The reader is referred to [RFC6830], introduce any new term. The reader is referred to [RFC6830],
[RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835], [RFC6836],
[RFC7052], [RFC7215] for the LISP definition of terms. [RFC7052], [RFC7215] for the LISP definition of terms.
3. LISP Architecture 3. LISP Architecture
This section presents the LISP architecture, it first details the This section presents the LISP architecture, it first details the
design principles of LISP and then it proceeds to describe its main design principles of LISP and then it proceeds to describe its main
aspects: data-plane, control-plane, and inetrworking mechanisms. aspects: data-plane, control-plane, and internetworking mechanisms.
3.1. Design Principles 3.1. Design Principles
The LISP architecture is built on top of four basic design The LISP architecture is built on top of four basic design
principles: principles:
o Locator/Identifier split: By decoupling the overloaded semantics o Locator/Identifier split: By decoupling the overloaded semantics
of the current IP addresses the Internet core can be assigned of the current IP addresses the Internet core can be assigned
identity meaningful addresses and hence, can use aggregation to identity meaningful addresses and hence, can use aggregation to
scale. Devices are assigned with relatively opaque identity scale. Devices are assigned with relatively opaque identity
skipping to change at page 5, line 31 skipping to change at page 5, line 26
3.2. Overview of the Architecture 3.2. Overview of the Architecture
LISP splits architecturally the core from the edge of the Internet by LISP splits architecturally the core from the edge of the Internet by
creating two separate namespaces: Endpoint Identifiers (EIDs) and creating two separate namespaces: Endpoint Identifiers (EIDs) and
Routing LOCators (RLOCs). The edge consists of LISP sites (e.g., an Routing LOCators (RLOCs). The edge consists of LISP sites (e.g., an
Autonomous System) that use EID addresses. EIDs are typically -but Autonomous System) that use EID addresses. EIDs are typically -but
not limited to- IPv4 or IPv6 addresses that uniquely identify not limited to- IPv4 or IPv6 addresses that uniquely identify
communication end-hosts and are assigned and configured by the same communication end-hosts and are assigned and configured by the same
mechanisms that exist at the time of this writing. EIDs do not mechanisms that exist at the time of this writing. EIDs do not
contain inter-domain topological information and can be thought as an contain inter-domain topological information and because of this,
analogy to Provider Independent (PI [RFC4116]) addresses. Because of EIDs are usually routable at the edge (within LISP sites) or in the
this, EIDs are usually only routable at the edge with a LISP site. non-LISP Internet.
With LISP, LISP sites (edge) and the core of the Internet are With LISP, LISP sites (edge) and the core of the Internet are
interconnected by means of LISP-capable routers (e.g., border interconnected by means of LISP-capable routers (e.g., border
routers) using tunnels. When packets originated from a LISP site are routers) using tunnels. When packets originated from a LISP site are
flowing towards the core network, they ingress into an encapsulated flowing towards the core network, they ingress into an encapsulated
tunnel via an Ingress Tunnel Router (ITR). When packets flow from tunnel via an Ingress Tunnel Router (ITR). When packets flow from
the core network to a LISP site, they egress from an encapsulated the core network to a LISP site, they egress from an encapsulated
tunnel to an Egress Tunnel Router (ETR). An xTR is a router which tunnel to an Egress Tunnel Router (ETR). An xTR is a router which
can perform both ITR and ETR operations. In this context ITRs can perform both ITR and ETR operations. In this context ITRs
encapsulate packets while ETRs decapsulate them, hence LISP operates encapsulate packets while ETRs decapsulate them, hence LISP operates
as an overlay on top of the current Internet core. as an overlay on top of the current Internet core.
/-----------------\ --- /-----------------\ ---
| Mapping | | | Mapping | |
. System | | Control . System | | Control
-| |`, | Plane -| |`, | Plane
,' \-----------------/ . | ,' \-----------------/ . |
/ \ --- / | ---
,.., - _,..--..,, `, ,.., | ,.., - _,....,, | ,.., |
/ ` ,' ,-` `', . / ` | / ` ,' ,-` `', | / ` |
/ \ +-----+ ,' `, +--'--+ / \ | / \ +-----+ ,' `, +-----+ / \ |
| EID |-| xTR |---/ RLOC ,---| xTR |-| EID | | Data | EID |-| xTR |--/ RLOC ,--| xTR |-| EID | | Data
| Space |-| |---| Space |---| |-| Space | | Plane | Space |-| |--| Space |--| |-| Space | | Plane
\ / +-----+ . / +-----+ \ / | \ / +-----+ . / +-----+ \ / |
`. .' `. ,' `. .' | `. .' `. ,' `. .' |
`'-` `., ,.' `'-` --- `'-` `., ,.' `'-` ---
``''--''`` ``'''``
LISP Site (Edge) Core LISP Site (Edge) LISP Site (Edge) Core LISP Site (Edge)
Figure 1.- A schema of the LISP Architecture Figure 1.- A schema of the LISP Architecture
With LISP, the core uses RLOCs, an RLOC is typically -but not limited With LISP, the core uses RLOCs, an RLOC is typically -but not limited
to- an IPv4 or IPv6 address assigned to an Internet-facing network to- an IPv4 or IPv6 address assigned to an Internet-facing network
interface of an ITR or ETR. Typically RLOCs are numbered from interface of an ITR or ETR. Typically RLOCs are numbered from
topologically aggregatable blocks assigned to a site at each point to topologically aggregatable blocks assigned to a site at each point to
which it attaches to the global Internet. The topology is defined by which it attaches to the global Internet, the topology is defined by
the connectivity of networks, in this context RLOCs can be thought of the connectivity of networks.
Provider Aggregatable addresses [RFC4116].
A typically distributed database, called the Mapping System, stores A typically distributed database, called the Mapping System, stores
mappings between EIDs and RLOCs. Such mappings relate the identity mappings between EIDs and RLOCs. Such mappings relate the identity
of the devices attached to LISP sites (EIDs) to the set of RLOCs of the devices attached to LISP sites (EIDs) to the set of RLOCs
configured at the LISP-capable routers servicing the site. configured at the LISP-capable routers servicing the site.
Furthermore, the mappings also include traffic engineering policies Furthermore, the mappings also include traffic engineering policies
and can be configured to achieve multihoming and load balancing. The and can be configured to achieve multihoming and load balancing. The
LISP Mapping System is conceptually similar to the DNS where it is LISP Mapping System is conceptually similar to the DNS where it is
organized as a distributed multi-organization network database. With organized as a distributed multi-organization network database. With
LISP, ETRs register mappings while ITRs retrieve them. LISP, ETRs register mappings while ITRs retrieve them.
skipping to change at page 8, line 8 skipping to change at page 8, line 5
Request, the message contains EID_B as the lookup key. In turn Request, the message contains EID_B as the lookup key. In turn
it receives another LISP control message called Map-Reply, the it receives another LISP control message called Map-Reply, the
message contains two locators: RLOC_B1 and RLOC_B2 along with message contains two locators: RLOC_B1 and RLOC_B2 along with
traffic engineering policies: priority and weight per locator. traffic engineering policies: priority and weight per locator.
ITR_A also stores the mapping in a local cache to speed-up ITR_A also stores the mapping in a local cache to speed-up
forwarding of subsequent packets. forwarding of subsequent packets.
4. ITR_A encapsulates the packet towards RLOC_B1 (chosen according 4. ITR_A encapsulates the packet towards RLOC_B1 (chosen according
to the priorities/weights specified in the mapping). The packet to the priorities/weights specified in the mapping). The packet
contains two IP headers, the outer header has RLOC_A1 as source contains two IP headers, the outer header has RLOC_A1 as source
and RLOC_B2 as destination, the inner original header has EID_A and RLOC_B1 as destination, the inner original header has EID_A
as source and EID_B as destination. Furthermore ITR_A adds a as source and EID_B as destination. Furthermore ITR_A adds a
LISP header, more details about LISP encapsulation can be found LISP header, more details about LISP encapsulation can be found
in Section 3.3.1. in Section 3.3.1.
5. The encapsulated packet is forwarded by the Internet core as a 5. The encapsulated packet is forwarded by the Internet core as a
normal IP packet, making the EID invisible from the Internet normal IP packet, making the EID invisible from the Internet
core. core.
6. Upon reception of the encapsulated packet by ETR_B, it 6. Upon reception of the encapsulated packet by ETR_B, it
decapsulates the packet and forwards it to HostB. decapsulates the packet and forwards it to HostB.
skipping to change at page 9, line 27 skipping to change at page 9, line 23
addresses. This header is created by the source end-host and is addresses. This header is created by the source end-host and is
left unchanged by LISP data plane processing on the ITR and ETR. left unchanged by LISP data plane processing on the ITR and ETR.
Finally, in some scenarios Recursive and/or Re-encapsulating tunnels Finally, in some scenarios Recursive and/or Re-encapsulating tunnels
can be used for Traffic Engineering and re-routing. Re-encapsulating can be used for Traffic Engineering and re-routing. Re-encapsulating
tunnels are consecutive LISP tunnels and occur when a decapsulator tunnels are consecutive LISP tunnels and occur when a decapsulator
(an ETR action) removes a LISP header and then acts as an encapsultor (an ETR action) removes a LISP header and then acts as an encapsultor
(an ITR action) to prepend another one. On the other hand, Recursive (an ITR action) to prepend another one. On the other hand, Recursive
tunnels are nested tunnels and are implemented by using multiple LISP tunnels are nested tunnels and are implemented by using multiple LISP
encapsulations on a packet. Typically such functions are implemented encapsulations on a packet. Typically such functions are implemented
by Reencapsulating Tunnel Routers (RTRs). by Reencapsulating Tunnel Routers (RTRs). An RTR can be thought as a
router that first acts as an ETR by decapsulating packets and then as
an ITR by encapsulating them towards another locator, more
information can be found at [RFC6830].
3.3.2. LISP Forwarding State 3.3.2. LISP Forwarding State
In the LISP architecture, ITRs keep just enough information to route In the LISP architecture, ITRs keep just enough information to route
traffic flowing through it. Meaning that, ITRs retrieve from the traffic flowing through it. Meaning that, ITRs retrieve from the
LISP Mapping System mappings between EID prefixes and RLOCs that are LISP Mapping System mappings between EID prefixes and RLOCs that are
used to encapsulate packets. Such mappings are stored in a local used to encapsulate packets. Such mappings are stored in a local
cache called the Map-Cache for subsequent packets addressed to the cache called the Map-Cache for subsequent packets addressed to the
same EID prefix. Note that, in case of overlapping EID-prefixes, same EID prefix. Note that, in case of overlapping EID-prefixes,
following a single request, the ITR may receive a set of mappings, following a single request, the ITR may receive a set of mappings,
skipping to change at page 11, line 37 skipping to change at page 11, line 37
the data-plane is optimized to route packets according to the data-plane is optimized to route packets according to
hierarchical IP addresses. However the control-plane may have hierarchical IP addresses. However the control-plane may have
different requirements, for instance and by taking advantage of the different requirements, for instance and by taking advantage of the
LCAFs, the Mapping System may be used to store non-hierarchical keys LCAFs, the Mapping System may be used to store non-hierarchical keys
(such as MAC addresses), requiring different architectural approaches (such as MAC addresses), requiring different architectural approaches
for scalability. Another important difference between the LISP for scalability. Another important difference between the LISP
control and data-planes is that, and as a result of the local mapping control and data-planes is that, and as a result of the local mapping
cache available at ITR, the Mapping System does not need to operate cache available at ITR, the Mapping System does not need to operate
at line-rate. at line-rate.
The LISP WG has explored application of the following distributed Many of the existing mechanisms to create distributed systems have
system techniques to the Mapping System architecture: graph-based been explored and considered for the Mapping System architecture:
databases in the form of LISP+ALT [RFC6836], hierarchical databases graph-based databases in the form of LISP+ALT [RFC6836], hierarchical
in the form of LISP-DDT [I-D.ietf-lisp-ddt], monolithic databases in databases in the form of LISP-DDT [I-D.ietf-lisp-ddt], monolithic
the form of LISP-NERD [RFC6837], flat databases in the form of LISP- databases in the form of LISP-NERD [RFC6837], flat databases in the
DHT [I-D.cheng-lisp-shdht],[I-D.mathy-lisp-dht] and, a multicast- form of LISP-DHT [I-D.cheng-lisp-shdht],[Mathy] and, a multicast-
based database [I-D.curran-lisp-emacs]. Furthermore it is worth based database [I-D.curran-lisp-emacs]. Furthermore it is worth
noting that, in some scenarios such as private deployments, the noting that, in some scenarios such as private deployments, the
Mapping System can operate as logically centralized. In such cases Mapping System can operate as logically centralized. In such cases
it is typically composed of a single Map-Server/Map-Resolver. it is typically composed of a single Map-Server/Map-Resolver.
The following focuses on the two mapping systems that have been The following focuses on the two mapping systems that have been
implemented and deployed (LISP-ALT and LISP+DDT). implemented and deployed (LISP-ALT and LISP+DDT).
3.4.3.1. LISP+ALT 3.4.3.1. LISP+ALT
skipping to change at page 14, line 13 skipping to change at page 14, line 13
to reduce the mapping retrieving latency[Jakab]. to reduce the mapping retrieving latency[Jakab].
The DDT Mapping System relies on manual configuration. That is Map- The DDT Mapping System relies on manual configuration. That is Map-
Resolvers are manually configured with the set of available DDT root Resolvers are manually configured with the set of available DDT root
nodes while DDT nodes are manually configured with the appropriate nodes while DDT nodes are manually configured with the appropriate
XEID delegations. Configuration changes in the DDT nodes are only XEID delegations. Configuration changes in the DDT nodes are only
required when the tree structure changes itself, but it doesn't required when the tree structure changes itself, but it doesn't
depend on EID dynamics (RLOC allocation or traffic engineering policy depend on EID dynamics (RLOC allocation or traffic engineering policy
changes). changes).
3.5. Interworking Mechanisms 3.5. Internetworking Mechanisms
EIDs are typically identical to either IPv4 or IPv6 addresses and EIDs are typically identical to either IPv4 or IPv6 addresses and
they are stored in the LISP Mapping System, however they are usually they are stored in the LISP Mapping System, however they are usually
not announced in the Internet global routing system. As a result not announced in the Internet global routing system. As a result
LISP requires an inetrworking mechanism to allow LISP sites to speak LISP requires an internetworking mechanism to allow LISP sites to
with non-LISP sites and vice versa. LISP inetrworking mechanisms are speak with non-LISP sites and vice versa. LISP internetworking
specified in [RFC6832]. mechanisms are specified in [RFC6832].
LISP defines two entities to provide inetrworking: LISP defines two entities to provide internetworking:
Proxy Ingress Tunnel Router (PITR): PITRs provide connectivity from Proxy Ingress Tunnel Router (PITR): PITRs provide connectivity from
the legacy Internet to LISP sites. PITRs announce in the global the legacy Internet to LISP sites. PITRs announce in the global
routing system blocks of EID prefixes (aggregating when possible) routing system blocks of EID prefixes (aggregating when possible)
to attract traffic. For each incoming packet from a source not in to attract traffic. For each incoming packet from a source not in
a LISP site (a non-EID), the PITR LISP-encapsulates it towards the a LISP site (a non-EID), the PITR LISP-encapsulates it towards the
RLOC(s) of the appropriate LISP site. The impact of PITRs in the RLOC(s) of the appropriate LISP site. The impact of PITRs in the
routing table size of the DFZ is, in the worst-case, similar to routing table size of the Default-Free Zone (DFZ) is, in the
the case in which LISP is not deployed. EID-prefixes will be worst-case, similar to the case in which LISP is not deployed.
aggregated as much as possible both by the PITR and by the global EID-prefixes will be aggregated as much as possible both by the
routing system. PITR and by the global routing system.
Proxy Egress Tunnel Router (PETR): PETRs provide connectivity from Proxy Egress Tunnel Router (PETR): PETRs provide connectivity from
LISP sites to the legacy Internet. In some scenarios, LISP sites LISP sites to the legacy Internet. In some scenarios, LISP sites
may be unable to send encapsulated packets with a local EID may be unable to send encapsulated packets with a local EID
address as a source to the legacy Internet. For instance when address as a source to the legacy Internet. For instance when
Unicast Reverse Path Forwarding (uRPF) is used by Provider Edge Unicast Reverse Path Forwarding (uRPF) is used by Provider Edge
routers, or when an intermediate network between a LISP site and a routers, or when an intermediate network between a LISP site and a
non-LISP site does not support the desired version of IP (IPv4 or non-LISP site does not support the desired version of IP (IPv4 or
IPv6). In both cases the PETR overcomes such limitations by IPv6). In both cases the PETR overcomes such limitations by
encapsulating packets over the network. There is no specified encapsulating packets over the network. There is no specified
provision for the distribution of PETR RLOC addresses to the ITRs. provision for the distribution of PETR RLOC addresses to the ITRs.
Additionally, LISP also defines mechanisms to operate with private
EIDs [RFC1918] by means of LISP-NAT [RFC6832]. In this case the xTR
replaces a private EID source address with a routable one. At the
time of this writing, work is ongoing to define NAT-traversal
capabilities, that is xTRs behind a NAT using non-routable RLOCs.
4. LISP Operational Mechanisms 4. LISP Operational Mechanisms
This section details the main operational mechanisms defined in LISP. This section details the main operational mechanisms defined in LISP.
4.1. Cache Management 4.1. Cache Management
LISP's decoupled control and data-plane, where mappings are stored in LISP's decoupled control and data-plane, where mappings are stored in
the control-plane and used for forwarding in the data plane, requires the control-plane and used for forwarding in the data plane, requires
of a local cache in ITRs to reduce signaling overhead (Map-Request/ a local cache in ITRs to reduce signaling overhead (Map-Request/Map-
Map-Reply) and increase forwarding speed. The local cache available Reply) and increase forwarding speed. The local cache available at
at the ITRs, called Map-Cache, is used by the router to LISP- the ITRs, called Map-Cache, is used by the router to LISP-encapsulate
encapsulate packets. The Map-Cache is indexed by (Instance ID, EID- packets. The Map-Cache is indexed by (Instance ID, EID-prefix) and
prefix) and contains basically the set of RLOCs with the associated contains basically the set of RLOCs with the associated traffic
traffic engineering policies (priorities and weights). engineering policies (priorities and weights).
The Map-Cache, as any other cache, requires cache coherence The Map-Cache, as any other cache, requires cache coherence
mechanisms to maintain up-to-date information. LISP defines three mechanisms to maintain up-to-date information. LISP defines three
main mechanisms for cache coherence: main mechanisms for cache coherence:
Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, upon Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, upon
expiration of the TTL the ITR has to refresh the mapping by expiration of the TTL the ITR has to refresh the mapping by
sending a new Map-Request. Typical values for TTL defined by LISP sending a new Map-Request. Typical values for TTL defined by LISP
are 24 hours. are 24 hours.
Solicit-Map-Request (SMR): SMR is an explicit mechanism to update Solicit-Map-Request (SMR): SMR is an explicit mechanism to update
mapping information. In particular a special type of Map-Request mapping information. In particular a special type of Map-Request
can be sent on demand by ETRs to request refreshing a mapping. can be sent on demand by ETRs to request refreshing a mapping.
Upon reception of a SMR message, the ITR must refresh the bindings Upon reception of a SMR message, the ITR must refresh the bindings
by sending a Map-Request to the Mapping System. by sending a Map-Request to the Mapping System. Further uses of
SMRs are documented in [RFC6830].
Map-Versioning: This optional mechanism piggybacks in the LISP Map-Versioning: This optional mechanism piggybacks in the LISP
header of data-packets the version number of the mappings used by header of data-packets the version number of the mappings used by
an xTR. This way, when an xTR receives a LISP-encapsulated packet an xTR. This way, when an xTR receives a LISP-encapsulated packet
from a remote xTR, it can check whether its own Map-Cache or the from a remote xTR, it can check whether its own Map-Cache or the
one of the remote xTR is outdated. If its Map-Cache is outdated, one of the remote xTR is outdated. If its Map-Cache is outdated,
it sends a Map-Request for the remote EID so to obtain the newest it sends a Map-Request for the remote EID so to obtain the newest
mappings. On the contrary, if it detects that the remote xTR Map- mappings. On the contrary, if it detects that the remote xTR Map-
Cache is outdated, it sends a SMR to notify it that a new mapping Cache is outdated, it sends a SMR to notify it that a new mapping
is available. is available.
skipping to change at page 17, line 50 skipping to change at page 18, line 12
IPv6) then the ITR drops it and replies with a ICMP Too Big message IPv6) then the ITR drops it and replies with a ICMP Too Big message
to the source. to the source.
5. Mobility 5. Mobility
The separation between locators and identifiers in LISP was initially The separation between locators and identifiers in LISP was initially
proposed for traffic engineering purpose where LISP sites can change proposed for traffic engineering purpose where LISP sites can change
their attachment points to the Internet (i.e., RLOCs) without their attachment points to the Internet (i.e., RLOCs) without
impacting endpoints or the Internet core. In this context, the impacting endpoints or the Internet core. In this context, the
border routers operate the xTR functionality and endpoints are not border routers operate the xTR functionality and endpoints are not
aware of the existence of LISP. However, this mode of operation does aware of the existence of LISP. This functionality is similar to
not allow seamless mobility of endpoints between different LISP sites Network Mobility [RFC3963]. However, this mode of operation does not
as the EID address might not be routable in a visited site. allow seamless mobility of endpoints between different LISP sites as
the EID address might not be routable in a visited site.
Nevertheless, LISP can be used to enable seamless IP mobility when Nevertheless, LISP can be used to enable seamless IP mobility when
LISP is directly implemented in the endpoint or when the endpoint LISP is directly implemented in the endpoint or when the endpoint
roams to an attached xTR. Each endpoint is then an xTR and the EID roams to an attached xTR. Each endpoint is then an xTR and the EID
address is the one presented to the network stack used by address is the one presented to the network stack used by
applications while the RLOC is the address gathered from the network applications while the RLOC is the address gathered from the network
when it is visited. when it is visited. This functionality is similar to Mobile IP
([RFC5944] and [RFC6275]).
Whenever the device changes of RLOC, the xTR updates the RLOC of its Whenever the device changes of RLOC, the xTR updates the RLOC of its
local mapping and registers it to its Map-Server. To avoid the need local mapping and registers it to its Map-Server, typically with a
of a home gateway, the ITR also indicates the RLOC change to all low TTL value (1min). To avoid the need of a home gateway, the ITR
remote devices that have ongoing communications with the device that also indicates the RLOC change to all remote devices that have
moved. The combination of both methods ensures the scalability of ongoing communications with the device that moved. The combination
the system as signaling is strictly limited the Map-Server and to of both methods ensures the scalability of the system as signaling is
hosts with which communications are ongoing. strictly limited the Map-Server and to hosts with which
communications are ongoing.
The decoupled identity and location provided by LISP allows it to
operate with other layer 2 and layer 3 mobility solutions.
6. Multicast 6. Multicast
LISP also supports transporting IP multicast packets sent from the LISP also supports transporting IP multicast packets sent from the
EID space, the operational changes required to the multicast EID space, the operational changes required to the multicast
protocols are documented in [RFC6831]. protocols are documented in [RFC6831].
In such scenarios, LISP may create multicast state both at the core In such scenarios, LISP may create multicast state both at the core
and at the sites (both source and receiver). When signaling is used and at the sites (both source and receiver). When signaling is used
to create multicast state at the sites, LISP routers unicast to create multicast state at the sites, LISP routers unicast
skipping to change at page 19, line 7 skipping to change at page 19, line 23
3. Multicast data packets originated by the source (S-EID, G) flow 3. Multicast data packets originated by the source (S-EID, G) flow
from the source to the ITR. The ITR LISP-encapsulates the from the source to the ITR. The ITR LISP-encapsulates the
multicast packets, the outter header includes its own RLOC as the multicast packets, the outter header includes its own RLOC as the
source (S-RLOC) and the original multicast group address (G) as source (S-RLOC) and the original multicast group address (G) as
the destination. Please note that multicast group address are the destination. Please note that multicast group address are
logical and are not resolved by the mapping system. Then the logical and are not resolved by the mapping system. Then the
multicast packet is transmitted through the core towards the multicast packet is transmitted through the core towards the
receiving ETRs that decapsulates the packets and sends them using receiving ETRs that decapsulates the packets and sends them using
the receiver's site multicast state. the receiver's site multicast state.
LISP can also support non-PIM mechanisms to maintain multicast state. LISP [RFC6831] supports all PIM modes, additionally LISP can also
support non-PIM mechanisms to maintain multicast state.
7. Security Considerations
LISP uses a pull architecture to learn mappings. While in a push
system, the state necessary to forward packets is learned
independently of the traffic itself, with a pull architecture, the
system becomes reactive and data-plane events (e.g., the arrival of a
packet for an unknown destination) may trigger control-plane events.
This on-demand learning of mappings provides many advantages as
discussed above but may also affect the way security is enforced.
Usually, the data-plane is implemented in the fast path of routers to
provide high performance forwarding capabilities while the control-
plane features are implemented in the slow path to offer high
flexibility and a performance gap of several order of magnitude can
be observed between the slow and the fast paths. As a consequence,
the way data-plane events are notified to the control-plane must be
thought carefully so to not overload the slow path and rate limiting
should be used as specified in [RFC6830].
Care must also be taken so to not overload the mapping system (i.e.,
the control plane infrastructure) as the operations to be performed
by the mapping system may be more complex than those on the data-
plane, for that reason [RFC6830] recommends to rate limit the sending
of messages to the mapping system.
To improve resiliency and reduce the overall number of messages
exchanged, LISP offers the possibility to leak information, such as
reachabilty of locators, directly into data plane packets. In
environments that are not fully trusted, control informations gleaned
from data-plane packets should be verified before using them.
Mappings are the centrepiece of LISP and all precautions must be
taken to avoid them to be manipulated or misused by malicious
entities. Using trustable Map-Servers that strictly respect
[RFC6833] and the lightweight authentication mechanism proposed by
LISP-Sec [I-D.ietf-lisp-sec] reduces the risk of attacks to the
mapping integrity. In more critical environments, secure measures
may be needed.
As with any other tunneling mechanism, middleboxes on the path
between an ITR (or PITR) and an ETR (or PETR) must implement
mechanisms to strip the LISP encapsulation to correctly inspect the
content of LISP encapsulated packets.
Like other map-and-encap mechanisms, LISP enables triangular routing
(i.e., packets of a flow cross different border routers depending on
their direction). This means that intermediate boxes may have
incomplete view on the traffic they inspect or manipulate.
More details about security implications of LISP are discussed in
[I-D.ietf-lisp-threats].
8. Use Cases 7. Use Cases
8.1. Traffic Engineering 7.1. Traffic Engineering
BGP is the standard protocol to implement inter-domain routing. With BGP is the standard protocol to implement inter-domain routing. With
BGP, routing informations are propagated along the network and each BGP, routing informations are propagated along the network and each
autonomous system can implement its own routing policy that will autonomous system can implement its own routing policy that will
influence the way routing information are propagated. The direct influence the way routing information are propagated. The direct
consequence is that an autonomous system cannot precisely control the consequence is that an autonomous system cannot precisely control the
way the traffic will enter the network. way the traffic will enter the network.
As opposed to BGP, a LISP site can strictly impose via which ETRs the As opposed to BGP, a LISP site can strictly impose via which ETRs the
traffic must enter the the LISP site network even though the path traffic must enter the the LISP site network even though the path
skipping to change at page 20, line 48 skipping to change at page 20, line 13
(the least preferred ones being provided for backup purpose). The (the least preferred ones being provided for backup purpose). The
weight permits to balance the load between the RLOCs with the same weight permits to balance the load between the RLOCs with the same
priority, proportionally to the weight value. priority, proportionally to the weight value.
As mappings are directly issued by the authoritative ETR of the EID As mappings are directly issued by the authoritative ETR of the EID
and are not altered while transmitted to the remote site, it offers and are not altered while transmitted to the remote site, it offers
highly flexible incoming inter-domain traffic engineering with even highly flexible incoming inter-domain traffic engineering with even
the possibility for a site to issue a different mapping for each the possibility for a site to issue a different mapping for each
remote site, implementing so precise routing policies. remote site, implementing so precise routing policies.
8.2. LISP for IPv6 Co-existence 7.2. LISP for IPv6 Co-existence
LISP encapsulations allows to transport packets using EIDs from a LISP encapsulations allows to transport packets using EIDs from a
given address family (e.g., IPv6) with packets from other address given address family (e.g., IPv6) with packets from other address
families (e.g., IPv4). The absence of correlation between the families (e.g., IPv4). The absence of correlation between the
address family of RLOCs and EIDs makes LISP a candidate to allow, address family of RLOCs and EIDs makes LISP a candidate to allow,
e.g., IPv6 to be deployed when all of the core network may not have e.g., IPv6 to be deployed when all of the core network may not have
IPv6 enabled. IPv6 enabled.
For example, two IPv6-only data centers could be interconnected via For example, two IPv6-only data centers could be interconnected via
the legacy IPv4 Internet. If their border routers are LISP capable, the legacy IPv4 Internet. If their border routers are LISP capable,
sending packets between the data center is done without any form of sending packets between the data center is done without any form of
translation as the native IPv6 packets (in the EID space) will be translation as the native IPv6 packets (in the EID space) will be
LISP encapsulated and transmitted over the IPv4 legacy Internet by LISP encapsulated and transmitted over the IPv4 legacy Internet by
the mean of IPv4 RLOCs. the mean of IPv4 RLOCs.
8.3. LISP for Virtual Private Networks 7.3. LISP for Virtual Private Networks
It is common to operate several virtual networks over the same It is common to operate several virtual networks over the same
physical infrastructure. In such virtual private networks, it is physical infrastructure. In such virtual private networks, it is
essential to distinguish which virtual network a packet belongs and essential to distinguish which virtual network a packet belongs and
tags or labels are used for that purpose. When using LISP, the tags or labels are used for that purpose. When using LISP, the
distinction can be made with the Instance ID field. When an ITR distinction can be made with the Instance ID field. When an ITR
encapsulates a packet from a particular virtual network (e.g., known encapsulates a packet from a particular virtual network (e.g., known
via the VRF or VLAN), it tags the encapsulated packet with the via the VRF or VLAN), it tags the encapsulated packet with the
Instance ID corresponding to the virtual network of the packet. When Instance ID corresponding to the virtual network of the packet. When
an ETR receives a packet tagged with an Instance ID it uses the an ETR receives a packet tagged with an Instance ID it uses the
Instance ID to determine how to treat the packet. Instance ID to determine how to treat the packet.
The main usage of LISP for virtual private networks does not The main usage of LISP for virtual private networks does not
introduce additional requirements on the underlying network, as long introduce additional requirements on the underlying network, as long
as it is running IP. as it is running IP.
8.4. LISP for Virtual Machine Mobility in Data Centers 7.4. LISP for Virtual Machine Mobility in Data Centers
A way to enable seamless virtual machine mobility in data center is A way to enable seamless virtual machine mobility in data center is
to conceive the datacenter backbone as the RLOC space and the subnet to conceive the datacenter backbone as the RLOC space and the subnet
where servers are hosted as forming the EID space. A LISP router is where servers are hosted as forming the EID space. A LISP router is
placed at the border between the backbone and each subnet. When a placed at the border between the backbone and each subnet. When a
virtual machine is moved to another subnet, it can keep (temporarily) virtual machine is moved to another subnet, it can keep (temporarily)
the address it had before the move so to continue without a transport the address it had before the move so to continue without a transport
layer connection reset. When an xTR detects a source address layer connection reset. When an xTR detects a source address
received on a subnet to be an address not assigned to the subnet, it received on a subnet to be an address not assigned to the subnet, it
registers the address to the Mapping System. registers the address to the Mapping System.
To inform the other LISP routers that the machine moved and where, To inform the other LISP routers that the machine moved and where,
and then to avoid detours via the initial subnetwork, mechanisms such and then to avoid detours via the initial subnetwork, mechanisms such
as the Solicit-Map-Request messages are used. as the Solicit-Map-Request messages are used.
9. Security Considerations 8. Security Considerations
This document does not specify any protocol or operational practices This section describes the security considerations associated to the
and hence, does not have any security considerations. LISP protocol.
10. IANA Considerations LISP uses a pull architecture to learn mappings. While in a push
system, the state necessary to forward packets is learned
independently of the traffic itself, with a pull architecture, the
system becomes reactive and data-plane events (e.g., the arrival of a
packet for an unknown destination) may trigger control-plane events.
This on-demand learning of mappings provides many advantages as
discussed above but may also affect the way security is enforced.
Usually, the data-plane is implemented in the fast path of routers to
provide high performance forwarding capabilities while the control-
plane features are implemented in the slow path to offer high
flexibility and a performance gap of several order of magnitude can
be observed between the slow and the fast paths. As a consequence,
the way data-plane events are notified to the control-plane must be
thought carefully so to not overload the slow path and rate limiting
should be used as specified in [RFC6830].
Care must also be taken so to not overload the mapping system (i.e.,
the control plane infrastructure) as the operations to be performed
by the mapping system may be more complex than those on the data-
plane, for that reason [RFC6830] recommends to rate limit the sending
of messages to the mapping system.
To improve resiliency and reduce the overall number of messages
exchanged, LISP offers the possibility to leak information, such as
reachabilty of locators, directly into data plane packets. In
environments that are not fully trusted, control informations gleaned
from data-plane packets should be verified before using them.
Mappings are the centrepiece of LISP and all precautions must be
taken to avoid them to be manipulated or misused by malicious
entities. Using trustable Map-Servers that strictly respect
[RFC6833] and the lightweight authentication mechanism proposed by
LISP-Sec [I-D.ietf-lisp-sec] reduces the risk of attacks to the
mapping integrity. In more critical environments, secure measures
may be needed.
As with any other tunneling mechanism, middleboxes on the path
between an ITR (or PITR) and an ETR (or PETR) must implement
mechanisms to strip the LISP encapsulation to correctly inspect the
content of LISP encapsulated packets.
Like other map-and-encap mechanisms, LISP enables triangular routing
(i.e., packets of a flow cross different border routers depending on
their direction). This means that intermediate boxes may have
incomplete view on the traffic they inspect or manipulate.
More details about security implications of LISP are discussed in
[I-D.ietf-lisp-threats].
9. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
11. Acknowledgements 10. Acknowledgements
This document was initiated by Noel Chiappa and much of the core This document was initiated by Noel Chiappa and much of the core
philosophy came from him. The authors acknowledge the important philosophy came from him. The authors acknowledge the important
contributions he has made to this work and thank him for his past contributions he has made to this work and thank him for his past
efforts. efforts.
The authors would also like to thank Dino Farinacci, Fabio Maino, The authors would also like to thank Dino Farinacci, Fabio Maino,
Luigi Iannone, Sharon Barakai, Isidoros Kouvelas, Christian Cassar, Luigi Iannone, Sharon Barakai, Isidoros Kouvelas, Christian Cassar,
Florin Coras, Marc Binderberger, Alberto Rodriguez-Natal, Ronald Florin Coras, Marc Binderberger, Alberto Rodriguez-Natal, Ronald
Bonica, Chad Hintz, Robert Raszuk, Joel M. Halpern, Darrel Lewis, as Bonica, Chad Hintz, Robert Raszuk, Joel M. Halpern, Darrel Lewis, as
well as every people acknowledged in [RFC6830]. well as every people acknowledged in [RFC6830].
12. References 11. References
12.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
Requirement Levels", BCP 14, RFC 2119, March 1997. E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002. an On-line Database", RFC 3232, January 2002.
[RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Gill, "IPv4 Multihoming Practices and Limitations", RFC Thubert, "Network Mobility (NEMO) Basic Support Protocol",
4116, July 2005. RFC 3963, January 2005.
[RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
Workshop on Routing and Addressing", RFC 4984, September Workshop on Routing and Addressing", RFC 4984, September
2007. 2007.
[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC
5944, November 2010.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, January Locator/ID Separation Protocol (LISP)", RFC 6830, January
2013. 2013.
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
Locator/ID Separation Protocol (LISP) for Multicast Locator/ID Separation Protocol (LISP) for Multicast
Environments", RFC 6831, January 2013. Environments", RFC 6831, January 2013.
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol "Interworking between Locator/ID Separation Protocol
skipping to change at page 23, line 42 skipping to change at page 24, line 13
RFC 6936, April 2013. RFC 6936, April 2013.
[RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID [RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID
Separation Protocol (LISP) MIB", RFC 7052, October 2013. Separation Protocol (LISP) MIB", RFC 7052, October 2013.
[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
Pascual, J., and D. Lewis, "Locator/Identifier Separation Pascual, J., and D. Lewis, "Locator/Identifier Separation
Protocol (LISP) Network Element Deployment Protocol (LISP) Network Element Deployment
Considerations", RFC 7215, April 2014. Considerations", RFC 7215, April 2014.
12.2. Informative References 11.2. Informative References
[Chiappa] Chiappa, J., "Endpoints and Endpoint names: A Propose [Chiappa] Chiappa, J., "Endpoints and Endpoint names: A Propose
Enhancement to the Internet Architecture, Enhancement to the Internet Architecture,
http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt", 1999. http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt", 1999.
[DDT-ROOT] [DDT-ROOT]
LISP DDT ROOT, , "http://ddt-root.org/", August 2013. LISP DDT ROOT, , "http://ddt-root.org/", August 2013.
[DFZ] Huston, Geoff., "Growth of the BGP Table - 1994 to Present
http://bgp.potaroo.net/", August 2013.
[I-D.cheng-lisp-shdht] [I-D.cheng-lisp-shdht]
Cheng, L. and J. Wang, "LISP Single-Hop DHT Mapping Cheng, L. and J. Wang, "LISP Single-Hop DHT Mapping
Overlay", draft-cheng-lisp-shdht-04 (work in progress), Overlay", draft-cheng-lisp-shdht-04 (work in progress),
July 2013. July 2013.
[I-D.curran-lisp-emacs] [I-D.curran-lisp-emacs]
Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID
Mappings Multicast Across Cooperating Systems for LISP", Mappings Multicast Across Cooperating Systems for LISP",
draft-curran-lisp-emacs-00 (work in progress), November draft-curran-lisp-emacs-00 (work in progress), November
2007. 2007.
[I-D.ietf-lisp-ddt] [I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Delegated Database Tree", draft-ietf-lisp-ddt-02 (work in Delegated Database Tree", draft-ietf-lisp-ddt-02 (work in
progress), October 2014. progress), October 2014.
[I-D.ietf-lisp-lcaf] [I-D.ietf-lisp-lcaf]
Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", draft-ietf-lisp-lcaf-06 (work in Address Format (LCAF)", draft-ietf-lisp-lcaf-07 (work in
progress), October 2014. progress), December 2014.
[I-D.ietf-lisp-sec] [I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-07 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-07
(work in progress), October 2014. (work in progress), October 2014.
[I-D.ietf-lisp-threats] [I-D.ietf-lisp-threats]
Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
Analysis", draft-ietf-lisp-threats-10 (work in progress), Analysis", draft-ietf-lisp-threats-11 (work in progress),
July 2014. December 2014.
[I-D.mathy-lisp-dht]
Mathy, L., Iannone, L., and O. Bonaventure, ""LISP-DHT:
Towards a DHT to map identifiers onto locators" draft-
mathy-lisp-dht-00 (work in progress)", April 2008.
[Jakab] Jakab, L., Cabellos, A., Saucez, D., and O. Bonaventure, [Jakab] Jakab, L., Cabellos, A., Saucez, D., and O. Bonaventure,
"LISP-TREE: A DNS Hierarchy to Support the LISP Mapping "LISP-TREE: A DNS Hierarchy to Support the LISP Mapping
System, IEEE Journal on Selected Areas in Communications, System, IEEE Journal on Selected Areas in Communications,
vol. 28, no. 8, pp. 1332-1343", October 2010. vol. 28, no. 8, pp. 1332-1343", October 2010.
[Mathy] Mathy, L., Iannone, L., and O. Bonaventure, "LISP-DHT:
Towards a DHT to map identifiers onto locators. The ACM
ReArch, Re-Architecting the Internet. Madrid (Spain)",
December 2008.
[Quoitin] Quoitin, B., Iannone, L., Launois, C., and O. Bonaventure, [Quoitin] Quoitin, B., Iannone, L., Launois, C., and O. Bonaventure,
""Evaluating the Benefits of the Locator/Identifier ""Evaluating the Benefits of the Locator/Identifier
Separation" in Proceedings of 2Nd ACM/IEEE International Separation" in Proceedings of 2Nd ACM/IEEE International
Workshop on Mobility in the Evolving Internet Workshop on Mobility in the Evolving Internet
Architecture", 2007. Architecture", 2007.
Appendix A. A Brief History of Location/Identity Separation Appendix A. A Brief History of Location/Identity Separation
The LISP system for separation of location and identity resulted from The LISP system for separation of location and identity resulted from
the discussions of this topic at the Amsterdam IAB Routing and the discussions of this topic at the Amsterdam IAB Routing and
 End of changes. 51 change blocks. 
180 lines changed or deleted 192 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/