draft-ietf-lisp-introduction-11.txt   draft-ietf-lisp-introduction-12.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: August 13, 2015 INRIA Expires: August 21, 2015 INRIA
February 9, 2015 February 17, 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-11.txt draft-ietf-lisp-introduction-12.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.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 August 13, 2015. This Internet-Draft will expire on August 21, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
4.1. Cache Management . . . . . . . . . . . . . . . . . . . . 16 4.1. Cache Management . . . . . . . . . . . . . . . . . . . . 16
4.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 17 4.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 17
4.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 18 4.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 18
4.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 18 4.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 18
5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 20 7.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 20
7.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 21 7.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 21
7.3. LISP for Virtual Private Networks . . . . . . . . . . . . 21 7.3. LISP for Virtual Private Networks . . . . . . . . . . . . 21
7.4. LISP for Virtual Machine Mobility in Data Centers . . . . 21 7.4. LISP for Virtual Machine Mobility in Data Centers . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. A Brief History of Location/Identity Separation . . 26 Appendix A. A Brief History of Location/Identity Separation . . 26
A.1. Old LISP Models . . . . . . . . . . . . . . . . . . . . . 26 A.1. Old LISP Models . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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 the unpublished Internet semantics. Indeed and as pointed out by the unpublished Internet
Draft by Noel Chiappa [Chiappa], currently IP addresses both identify Draft by Noel Chiappa [Chiappa], currently IP addresses both identify
the topological location of a network attachment point as well as the the topological location of a network attachment point as well as the
skipping to change at page 4, line 5 skipping to change at page 4, line 5
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
semantics to nodes at other LISP sites (i.e., enough locator semantics to nodes at other LISP sites (i.e., enough locator
information to tell that the EID is external to the site) information to tell that the EID is external to the site)
The relationship described above is not unique to LISP but it is The relationship described above is not unique to LISP but it is
common to other overlay technologies. common to other overlay technologies.
The initial motivation in the LISP effort is to be find in the The initial motivation in the LISP effort is to be found in the
routing scalability problem [RFC4984], where, if LISP is completely routing scalability problem [RFC4984], where, if LISP is completely
deployed, the Internet core is populated with RLOCs while Traffic deployed, the Internet core is populated with RLOCs while Traffic
Engineering mechanisms are pushed to the Mapping System. In such Engineering mechanisms are pushed to the Mapping System. In such
scenario RLOCs are quasi-static (i.e., low churn), hence making the scenario RLOCs are quasi-static (i.e., low churn), hence making the
routing system scalable [Quoitin], while EIDs can roam anywhere with routing system scalable [Quoitin], while EIDs can roam anywhere with
no churn to the underlying routing system. [RFC7215] discusses the no churn to the underlying routing system. [RFC7215] discusses the
impact of LISP on the global routing system during the transition impact of LISP on the global routing system during the transition
period. However, the separation between location and identity that period. However, the separation between location and identity that
LISP offers makes it suitable for use in additional scenarios such as LISP offers makes it suitable for use in additional scenarios such as
Traffic Engineering (TE), multihoming, and mobility among others. Traffic Engineering (TE), multihoming, and mobility among others.
skipping to change at page 6, line 16 skipping to change at page 6, line 16
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 because of this, contain inter-domain topological information and because of this,
EIDs are usually routable at the edge (within LISP sites) or in the EIDs are usually routable at the edge (within LISP sites) or in the
non-LISP Internet. non-LISP Internet; see Section 3.5 for discussion of LISP site
internetworking with non-LISP sites and domains in the 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
skipping to change at page 7, line 22 skipping to change at page 7, line 22
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.
Finally, the LISP architecture emphasizes a cost effective Finally, the LISP architecture emphasizes incremental deployment.
incremental deployment. Given that LISP represents an overlay to the Given that LISP represents an overlay to the current Internet
current Internet architecture, endhosts as well as intra and inter- architecture, endhosts as well as intra and inter-domain routers
domain routers remain unchanged, and the only required changes to the remain unchanged, and the only required changes to the existing
existing infrastructure are to routers connecting the EID with the infrastructure are to routers connecting the EID with the RLOC space.
RLOC space. Such LISP capable routers, in most cases, only require a Such LISP capable routers, in most cases, only require a software
software upgrade. Additionally, LISP requires the deployment of an upgrade. Additionally, LISP requires the deployment of an
independent Mapping System, such distributed database is a new independent Mapping System, such distributed database is a new
network entity. network entity.
The following describes a simplified packet flow sequence between two The following describes a simplified packet flow sequence between two
nodes that are attached to LISP sites. Client HostA wants to send a nodes that are attached to LISP sites. Please note that typical
packet to server HostB. LISP-capable routers are xTRs (both ITR and ETR). Client HostA wants
to send a packet to server HostB.
/----------------\ /----------------\
| Mapping | | Mapping |
| System | | System |
.| |- .| |-
` \----------------/ `. ` \----------------/ `.
,` \ ,` \
/ `. / `.
,' _,..-..,, ', ,' _,..-..,, ',
/ -` `-, \ / -` `-, \
skipping to change at page 8, line 29 skipping to change at page 8, line 29
| | RLOC_A1 |-------| | | | RLOC_A1 |-------| |
+-----+ | | RLOC_B2+-----+ +-----+ | | RLOC_B2+-----+
, / , /
\ / \ /
`', ,-` `', ,-`
``''-''`` ``''-''``
Figure 2.- Packet flow sequence in LISP Figure 2.- Packet flow sequence in LISP
1. HostA retrieves the EID_B of HostB, typically querying the DNS 1. HostA retrieves the EID_B of HostB, typically querying the DNS
and obtaining and A or AAAA record. Then it generates an IP and obtaining an A or AAAA record. Then it generates an IP
packet as in the Internet, the packet has source address EID_A packet as in the Internet, the packet has source address EID_A
and destination address EID_B. and destination address EID_B.
2. The packet is routed towards ITR_A in the LISP site using 2. The packet is routed towards ITR_A in the LISP site using
standard intra-domain mechanisms. standard intra-domain mechanisms.
3. ITR_A upon receiving the packet queries the Mapping System to 3. ITR_A upon receiving the packet queries the Mapping System to
retrieve the locator of ETR_B that is servicing HostB's EID_B. retrieve the locator of ETR_B that is servicing HostB's EID_B.
In order to do so it uses a LISP control message called Map- In order to do so it uses a LISP control message called Map-
Request, the message contains EID_B as the lookup key. In turn Request, the message contains EID_B as the lookup key. In turn
skipping to change at page 9, line 26 skipping to change at page 9, line 26
This section provides a high-level description of the LISP data- This section provides a high-level description of the LISP data-
plane, which is specified in detail in [RFC6830]. The LISP data- plane, which is specified in detail in [RFC6830]. The LISP data-
plane is responsible for encapsulating and decapsulating data packets plane is responsible for encapsulating and decapsulating data packets
and caching the appropriate forwarding state. It includes two main and caching the appropriate forwarding state. It includes two main
entities, the ITR and the ETR, both are LISP capable routers that entities, the ITR and the ETR, both are LISP capable routers that
connect the EID with the RLOC space (ITR) and vice versa (ETR). connect the EID with the RLOC space (ITR) and vice versa (ETR).
3.3.1. LISP Encapsulation 3.3.1. LISP Encapsulation
ITRs encapsulate data packets towards ETRs. LISP data packets are ITRs encapsulate data packets towards ETRs. LISP data packets are
encapsulated using UDP (port 4341), the source port is selected by encapsulated using UDP (port 4341), the source port is usually
the ITR and ignored on reception. A particularity of LISP is that selected by the ITR using a 5-tuple hash of the inner header (so to
UDP packets should include a zero checksum [RFC6935] [RFC6936] that be consistent in case of multi-path solutions such as ECMP [RFC2992])
it is not verified in reception, LISP also supports non-zero and ignored on reception. A particularity of LISP is that UDP
checksums that may be verified. This decision was made because the packets should include a zero checksum [RFC6935] [RFC6936] that it is
typical transport protocols used by the applications already include not verified in reception, LISP also supports non-zero checksums that
a checksum, by neglecting the additional UDP encapsulation checksum may be verified. This decision was made because the typical
transport protocols used by the applications already include a
checksum, by neglecting the additional UDP encapsulation checksum
xTRs can forward packets more efficiently. xTRs can forward packets more efficiently.
LISP-encapsulated packets also include a LISP header (after the UDP LISP-encapsulated packets also include a LISP header (after the UDP
header and before the original IP header). The LISP header is header and before the original IP header). The LISP header is
prepended by ITRs and striped by ETRs. It carries reachability prepended by ITRs and striped by ETRs. It carries reachability
information (see more details in Section 4.2) and the Instance ID information (see more details in Section 4.2) and the Instance ID
field. The Instance ID field is used to distinguish traffic to/from field. The Instance ID field is used to distinguish traffic to/from
different tenant address spaces at the LISP site and that may use different tenant address spaces at the LISP site and that may use
overlapped but logically separated EID addressing. overlapped but logically separated EID addressing.
skipping to change at page 10, line 16 skipping to change at page 10, line 16
originated by ITRs and stripped by ETRs. originated by ITRs and stripped by ETRs.
3. LISP header that contains various forwarding-plane features (such 3. LISP header that contains various forwarding-plane features (such
as reachability) and an Instance ID field. This header is as reachability) and an Instance ID field. This header is
originated by ITRs and stripped by ETRs. originated by ITRs and stripped by ETRs.
4. Inner IP header containing EIDs as source and destination 4. Inner IP header containing EIDs as source and destination
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 Re-encapsulating and/or Recursive tunnels
can be used for Traffic Engineering and re-routing. Re-encapsulating are useful to choose a specified path in the underlay network, for
tunnels are consecutive LISP tunnels and occur when a decapsulator instance to avoid congestion or failure. Re-encapsulating tunnels
(an ETR action) removes a LISP header and then acts as an encapsultor are consecutive LISP tunnels and occur when a decapsulator (an ETR
(an ITR action) to prepend another one. On the other hand, Recursive action) removes a LISP header and then acts as an encapsultor (an ITR
tunnels are nested tunnels and are implemented by using multiple LISP action) to prepend another one. On the other hand, Recursive tunnels
encapsulations on a packet. Typically such functions are implemented are nested tunnels and are implemented by using multiple LISP
by Reencapsulating Tunnel Routers (RTRs). An RTR can be thought of encapsulations on a packet. Such functions are implemented by
as a router that first acts as an ETR by decapsulating packets and Reencapsulating Tunnel Routers (RTRs). An RTR can be thought of as a
then as an ITR by encapsulating them towards another locator, more 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]. 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 them. Meaning that, ITRs retrieve from the
LISP Mapping System mappings between EID prefixes and RLOCs that are LISP Mapping System mappings between EID-prefixes (blocks of EIDs)
used to encapsulate packets. Such mappings are stored in a local and RLOCs that are used to encapsulate packets. Such mappings are
cache called the Map-Cache for subsequent packets addressed to the stored in a local cache called the Map-Cache for subsequent packets
same EID prefix. Note that, in case of overlapping EID-prefixes, addressed to the same EID prefix. Note that, in case of overlapping
following a single request, the ITR may receive a set of mappings, EID-prefixes, following a single request, the ITR may receive a set
covering the requested EID-prefix and all more-specifics (cf., of mappings, covering the requested EID-prefix and all more-specifics
Section 6.1.5 [RFC6830]). Mappings include a (Time-to-Live) TTL (set (cf., Section 6.1.5 [RFC6830]). Mappings include a (Time-to-Live)
by the ETR). More details about the Map-Cache management can be TTL (set by the ETR). More details about the Map-Cache management
found in Section 4.1. can be found in Section 4.1.
3.4. Control-Plane 3.4. Control-Plane
The LISP control-plane, specified in [RFC6833], provides a standard The LISP control-plane, specified in [RFC6833], provides a standard
interface to register and request mappings. The LISP Mapping System interface to register and request mappings. The LISP Mapping System
is a database that stores such mappings. The following first is a database that stores such mappings. The following first
describes the mappings, then the standard interface to the Mapping describes the mappings, then the standard interface to the Mapping
System, and finally its architecture. System, and finally its architecture.
3.4.1. LISP Mappings 3.4.1. LISP Mappings
skipping to change at page 16, line 5 skipping to change at page 16, line 5
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 Additionally, LISP also defines mechanisms to operate with private
EIDs [RFC1918] by means of LISP-NAT [RFC6832]. In this case the xTR 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 replaces a private EID source address with a routable one. At the
time of this writing, work is ongoing to define NAT-traversal time of this writing, work is ongoing to define NAT-traversal
capabilities, that is xTRs behind a NAT using non-routable RLOCs. capabilities, that is xTRs behind a NAT using non-routable RLOCs.
PITRs, PETRs and, LISP-NAT enable incremental deployment of LISP, by
providing significant flexibility in the placement of the boundaries
between the LISP and non-LISP portions of the network, and making it
easy to change those boundaries over time.
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
a local cache in ITRs to reduce signaling overhead (Map-Request/Map- a local cache in ITRs to reduce signaling overhead (Map-Request/Map-
Reply) and increase forwarding speed. The local cache available at Reply) and increase forwarding speed. The local cache available at
skipping to change at page 17, line 46 skipping to change at page 17, line 50
probes to specific locators, this effectively probes both the locator probes to specific locators, this effectively probes both the locator
and the path. In particular this is done by sending a Map-Request and the path. In particular this is done by sending a Map-Request
(with certain flags activated) on the data-plane (RLOC space) and (with certain flags activated) on the data-plane (RLOC space) and
waiting in return a Map-Reply, also sent on the data-plane. The waiting in return a Map-Reply, also sent on the data-plane. The
active nature of RLOC-probing provides an effective mechanism to active nature of RLOC-probing provides an effective mechanism to
determine reachability and, in case of failure, switching to a determine reachability and, in case of failure, switching to a
different locator. Furthermore the mechanism also provides useful different locator. Furthermore the mechanism also provides useful
RTT estimates of the delay of the path that can be used by other RTT estimates of the delay of the path that can be used by other
network algorithms. network algorithms.
Additionally, LISP also recommends inferring reachability of locators
by using information provided by the underlay, in particular:
It is worth noting that RLOC probing and Echo-nonce can work It is worth noting that RLOC probing and Echo-nonce can work
together. Specifically if a nonce is not echoed, an ITR could RLOC- together. Specifically if a nonce is not echoed, an ITR could RLOC-
probe to determine if the path is up when it cannot tell the probe to determine if the path is up when it cannot tell the
difference between a failed bidirectional path or the return path is difference between a failed bidirectional path or the return path is
not used (a unidirectional path). not used (a unidirectional path).
Additionally, LISP also recommends inferring reachability of locators
by using information provided by the underlay, in particular:
ICMP signaling: The LISP underlay -the current Internet- uses the ICMP signaling: The LISP underlay -the current Internet- uses the
ICMP protocol to signal unreachability (among other things). LISP ICMP protocol to signal unreachability (among other things). LISP
can take advantage of this and the reception of a ICMP Network can take advantage of this and the reception of a ICMP Network
Unreachable or ICMP Host Unreachable message can be seen as a hint Unreachable or ICMP Host Unreachable message can be seen as a hint
that a locator might be unreachable, this should lead to perform that a locator might be unreachable, this should lead to perform
additional checks. additional checks.
Underlay routing: Both BGP and IBGP carry reachability information, Underlay routing: Both BGP and IBGP carry reachability information,
LISP-capable routers that have access to underlay routing information LISP-capable routers that have access to underlay routing information
can use it to determine if a given locator or path are reachable. can use it to determine if a given locator or path are reachable.
skipping to change at page 18, line 44 skipping to change at page 18, line 47
LISP defines two mechanisms: LISP defines two mechanisms:
Stateless: With this mechanism the effective MTU is assumed from the Stateless: With this mechanism the effective MTU is assumed from the
ITR's perspective. If a payload packet is too big for the ITR's perspective. If a payload packet is too big for the
effective MTU, and can be fragmented, the payload packet is effective MTU, and can be fragmented, the payload packet is
fragmented on the ITR, such that reassembly is performed at the fragmented on the ITR, such that reassembly is performed at the
destination host. destination host.
Stateful: With this mechanism ITRs keep track of the MTU of the Stateful: With this mechanism ITRs keep track of the MTU of the
paths towards the destination locators by parsing the ICMP Too Big paths towards the destination locators by parsing the ICMP Too Big
packets sent by intermediate routers. Additionally ITRs will send packets sent by intermediate routers. ITRs will send ICMP Too Big
ICMP Too Big messages to inform the sources about the effective messages to inform the sources about the effective MTU.
MTU. Additionally ITRs can use mechanisms such as PMTUD [RFC1191] or
PLPMTUD [RFC4821] to keep track of the MTU towards the locators.
In both cases if the packet cannot be fragmented (IPv4 with DF=1 or In both cases if the packet cannot be fragmented (IPv4 with DF=1 or
IPv6) then the ITR drops it and replies with a ICMP Too Big message 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
skipping to change at page 19, line 31 skipping to change at page 19, line 35
when it is visited. This functionality is similar to Mobile IP when it is visited. This functionality is similar to Mobile IP
([RFC5944] and [RFC6275]). ([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, typically with a local mapping and registers it to its Map-Server, typically with a
low TTL value (1min). To avoid the need of a home gateway, the ITR low TTL value (1min). To avoid the need of a home gateway, the ITR
also indicates the RLOC change to all remote devices that have also indicates the RLOC change to all remote devices that have
ongoing communications with the device that moved. The combination ongoing communications with the device that moved. The combination
of both methods ensures the scalability of the system as signaling is of both methods ensures the scalability of the system as signaling is
strictly limited the Map-Server and to hosts with which strictly limited the Map-Server and to hosts with which
communications are ongoing. communications are ongoing. In the mobility case the EID-prefix can
be as small as a full /32 or /128 (IPv4 or IPv6 respectively)
depending on the specific use-case (e.g., subnet mobility vs single
VM/Mobile node mobility).
The decoupled identity and location provided by LISP allows it to The decoupled identity and location provided by LISP allows it to
operate with other layer 2 and layer 3 mobility solutions. 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].
skipping to change at page 20, line 23 skipping to change at page 20, line 31
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 [RFC6831] supports all PIM modes, additionally LISP can also Please note that the inner and outer multicast addresses are in
support non-PIM mechanisms to maintain multicast state. general different, unless in specific cases where the underlay
provider implements a tight control on the overlay. LISP
specifications already support all PIM modes [RFC6831].
Additionally, LISP can support as well non-PIM mechanisms in order to
maintain multicast state.
7. Use Cases 7. Use Cases
7.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 information are propagated along the network and each BGP, routing information 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
skipping to change at page 23, line 16 skipping to change at page 23, line 27
may be needed. may be needed.
As with any other tunneling mechanism, middleboxes on the path As with any other tunneling mechanism, middleboxes on the path
between an ITR (or PITR) and an ETR (or PETR) must implement between an ITR (or PITR) and an ETR (or PETR) must implement
mechanisms to strip the LISP encapsulation to correctly inspect the mechanisms to strip the LISP encapsulation to correctly inspect the
content of LISP encapsulated packets. content of LISP encapsulated packets.
Like other map-and-encap mechanisms, LISP enables triangular routing Like other map-and-encap mechanisms, LISP enables triangular routing
(i.e., packets of a flow cross different border routers depending on (i.e., packets of a flow cross different border routers depending on
their direction). This means that intermediate boxes may have their direction). This means that intermediate boxes may have
incomplete view on the traffic they inspect or manipulate. incomplete view on the traffic they inspect or manipulate. Moreover,
LISP-encapsulated packets are routed based on the outer IP address
(i.e., the RLOC), and can be delivered to an ETR that is not
responsible of the destination EID of the packet or even to a network
element that is not an ETR. The mitigation consists in applying
appropriate filtering techniques on the network elements that can
potentially receive un-expected LISP-encapsulated packets
More details about security implications of LISP are discussed in More details about security implications of LISP are discussed in
[I-D.ietf-lisp-threats]. [I-D.ietf-lisp-threats].
9. IANA Considerations 9. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
10. 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 Barkai, 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,
well as every people acknowledged in [RFC6830]. David Black as well as every people acknowledged in [RFC6830].
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", BCP E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996. 5, RFC 1918, February 1996.
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path
Algorithm", RFC 2992, November 2000.
[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.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005. RFC 3963, January 2005.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007.
[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 [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC
5944, November 2010. 5944, November 2010.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011. in IPv6", RFC 6275, July 2011.
 End of changes. 26 change blocks. 
61 lines changed or deleted 94 lines changed or added

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