summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7215.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7215.txt')
-rw-r--r--doc/rfc/rfc7215.txt1683
1 files changed, 1683 insertions, 0 deletions
diff --git a/doc/rfc/rfc7215.txt b/doc/rfc/rfc7215.txt
new file mode 100644
index 0000000..d26b350
--- /dev/null
+++ b/doc/rfc/rfc7215.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) L. Jakab
+Request for Comments: 7215 Cisco Systems
+Category: Experimental A. Cabellos-Aparicio
+ISSN: 2070-1721 F. Coras
+ J. Domingo-Pascual
+ Technical University of Catalonia
+ D. Lewis
+ Cisco Systems
+ April 2014
+
+
+ Locator/Identifier Separation Protocol (LISP)
+ Network Element Deployment Considerations
+
+Abstract
+
+ This document is a snapshot of different Locator/Identifier
+ Separation Protocol (LISP) deployment scenarios. It discusses the
+ placement of new network elements introduced by the protocol,
+ representing the thinking of the LISP working group as of Summer
+ 2013. LISP deployment scenarios may have evolved since then. This
+ memo represents one stable point in that evolution of understanding.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for examination, experimental implementation, and
+ evaluation.
+
+ This document defines an Experimental Protocol for the Internet
+ community. This document is a product of the Internet Engineering
+ Task Force (IETF). It represents the consensus of the IETF
+ community. It has received public review and has been approved for
+ publication by the Internet Engineering Steering Group (IESG). Not
+ all documents approved by the IESG are a candidate for any level of
+ Internet Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7215.
+
+
+
+
+
+
+
+
+
+
+
+Jakab, et al. Experimental [Page 1]
+
+RFC 7215 LISP Deployment April 2014
+
+
+Copyright Notice
+
+ Copyright (c) 2014 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jakab, et al. Experimental [Page 2]
+
+RFC 7215 LISP Deployment April 2014
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Tunnel Routers ..................................................5
+ 2.1. Deployment Scenarios .......................................5
+ 2.1.1. Customer Edge (CE) ..................................5
+ 2.1.2. Provider Edge (PE) ..................................6
+ 2.1.3. Tunnel Routers behind NAT ...........................8
+ 2.1.3.1. ITR ........................................8
+ 2.1.3.2. ETR ........................................9
+ 2.1.3.3. Additional Notes ...........................9
+ 2.2. Functional Models with Tunnel Routers ......................9
+ 2.2.1. Split ITR/ETR .......................................9
+ 2.2.2. Inter-Service-Provider Traffic Engineering .........11
+ 2.3. Summary and Feature Matrix ................................13
+ 3. Map-Servers and Map-Resolvers ..................................14
+ 3.1. Map-Servers ...............................................14
+ 3.2. Map-Resolvers .............................................16
+ 4. Proxy Tunnel Routers ...........................................17
+ 4.1. PITRs .....................................................17
+ 4.2. PETRs .....................................................18
+ 5. Migration to LISP ..............................................19
+ 5.1. LISP+BGP ..................................................19
+ 5.2. Mapping Service Provider (MSP) PITR Service ...............20
+ 5.3. Proxy-ITR Route Distribution (PITR-RD) ....................20
+ 5.4. Migration Summary .........................................23
+ 6. Security Considerations ........................................24
+ 7. Acknowledgements ...............................................24
+ 8. References .....................................................24
+ 8.1. Normative References ......................................24
+ 8.2. Informative References ....................................24
+ Appendix A. Step-by-Step Example BGP-to-LISP Migration Procedure ..26
+ A.1. Customer Pre-Install and Pre-Turn-Up Checklist .............26
+ A.2. Customer Activating LISP Service ...........................28
+ A.3. Cut-Over Provider Preparation and Changes ..................29
+
+1. Introduction
+
+ The Locator/Identifier Separation Protocol (LISP) is designed to
+ address the scaling issues of the global Internet routing system
+ identified in [RFC4984] by separating the current addressing scheme
+ into Endpoint IDentifiers (EIDs) and Routing LOCators (RLOCs). The
+ main protocol specification [RFC6830] describes how the separation is
+ achieved and which new network elements are introduced, and it
+ details the packet formats for the data and control planes.
+
+
+
+
+
+
+Jakab, et al. Experimental [Page 3]
+
+RFC 7215 LISP Deployment April 2014
+
+
+ LISP assumes that such separation is between the edge and core and
+ uses mapping and encapsulation for forwarding. While the boundary
+ between both is not strictly defined, one widely accepted definition
+ places it at the border routers of stub autonomous systems, which may
+ carry a partial or complete default-free zone (DFZ) routing table.
+ The initial design of LISP took this location as a baseline for
+ protocol development. However, the applications of LISP go beyond
+ just decreasing the size of the DFZ routing table and include
+ improved multihoming and ingress traffic engineering (TE) support for
+ edge networks, and even individual hosts. Throughout this document,
+ we will use the term "LISP site" to refer to these networks/hosts
+ behind a LISP Tunnel Router. We formally define the following
+ two terms:
+
+ Network element: Facility or equipment used in the provision of a
+ communications service over the Internet [TELCO96].
+
+ LISP site: A single host or a set of network elements in an edge
+ network under the administrative control of a single organization,
+ delimited from other networks by LISP Tunnel Router(s).
+
+ Since LISP is a protocol that can be used for different purposes, it
+ is important to identify possible deployment scenarios and the
+ additional requirements they may impose on the protocol specification
+ and other protocols. Additionally, this document is intended as a
+ guide for the operational community for LISP deployments in their
+ networks. It is expected to evolve as LISP deployment progresses,
+ and the described scenarios are better understood or new scenarios
+ are discovered.
+
+ Each subsection considers an element type and discusses the impact of
+ deployment scenarios on the protocol specification. For definitions
+ of terms, please refer to the appropriate documents (as cited in the
+ respective sections).
+
+ This experimental document describes deployment considerations.
+ These considerations and the LISP specifications have areas that
+ require additional experience and measurement. LISP is not
+ recommended for deployment beyond experimental situations. Results
+ of experimentation may lead to modifications and enhancements of LISP
+ mechanisms. Additionally, at the time of this writing there is no
+ standardized security to implement. Beware that there are no
+ countermeasures for any of the threats identified in [LISP-THREATS].
+ See Section 15 of [RFC6830] for specific known issues that are in
+ need of further work during development, implementation, and
+ experimentation, and see [LISP-THREATS] for recommendations to
+ ameliorate the above-mentioned security threats.
+
+
+
+
+Jakab, et al. Experimental [Page 4]
+
+RFC 7215 LISP Deployment April 2014
+
+
+2. Tunnel Routers
+
+ The device that is the gateway between the edge and the core is
+ called a Tunnel Router (xTR); it performs one or both of two separate
+ functions:
+
+ 1. Encapsulating packets originating from an end host to be
+ transported over intermediary (transit) networks towards the
+ other endpoint of the communication.
+
+ 2. Decapsulating packets entering from intermediary (transit)
+ networks, originated at a remote end host.
+
+ The first function is performed by an Ingress Tunnel Router (ITR) and
+ the second by an Egress Tunnel Router (ETR).
+
+ Section 8 of the main LISP specification [RFC6830] has a short
+ discussion of where Tunnel Routers can be deployed and some of the
+ associated advantages and disadvantages. This section adds more
+ detail to the scenarios presented there and provides additional
+ scenarios as well. Furthermore, this section discusses functional
+ models, that is, network functions that can be achieved by deploying
+ Tunnel Routers in specific ways.
+
+2.1. Deployment Scenarios
+
+2.1.1. Customer Edge (CE)
+
+ The first scenario we discuss is the customer edge, when xTR
+ functionality is placed on the router(s) that connects the LISP site
+ to its upstream(s) but is under its control. As such, this is the
+ most common expected scenario for xTRs, and this document considers
+ it the reference location, comparing the other scenarios to this one.
+
+ ISP1 ISP2
+ | |
+ | |
+ +----+ +----+
+ +--|xTR1|--|xTR2|--+
+ | +----+ +----+ |
+ | |
+ | LISP site |
+ +------------------+
+
+ Figure 1: xTRs at the Customer Edge
+
+
+
+
+
+
+Jakab, et al. Experimental [Page 5]
+
+RFC 7215 LISP Deployment April 2014
+
+
+ From the LISP site's perspective, the main advantage of this type of
+ deployment (compared to the one described in the next section) is
+ having direct control over its ingress traffic engineering. This
+ makes it easy to set up and maintain active/active, active/backup, or
+ more complex TE policies, adding ISPs and additional xTRs at will,
+ without involving third parties.
+
+ Being under the same administrative control, reachability information
+ of all ETRs is easier to synchronize, because the necessary control
+ traffic can be allowed between the locators of the ETRs. A correct
+ synchronous global view of the reachability status is thus available,
+ and the Locator-Status-Bits can be set correctly in the LISP data
+ header of outgoing packets.
+
+ By placing the Tunnel Router at the edge of the site, existing
+ internal network configuration does not need to be modified.
+ Firewall rules, router configurations, and address assignments inside
+ the LISP site remain unchanged. This helps with incremental
+ deployment and allows a quick upgrade path to LISP. For larger sites
+ distributed in geographically diverse points of presence (PoPs) and
+ having many external connections and complex internal topology, it
+ may, however, make more sense to both encapsulate and decapsulate as
+ soon as possible, to benefit from the information in the IGP to
+ choose the best path. See Section 2.2.1 for a discussion of this
+ scenario.
+
+ Another thing to consider when placing Tunnel Routers is MTU issues.
+ Encapsulation increases the amount of overhead associated with each
+ packet. This added overhead decreases the effective end-to-end path
+ MTU (unless fragmentation and reassembly are used). Some transit
+ networks are known to provide larger MTU values than the typical
+ value of 1500 bytes for popular access technologies used at end hosts
+ (e.g., IEEE 802.3 and 802.11). However, placing the LISP router
+ connecting to such a network at the customer edge could possibly
+ bring up MTU issues, depending on the link type to the provider as
+ opposed to the following scenario. See [RFC4459] for MTU
+ considerations of tunneling protocols and how to mitigate potential
+ issues. Still, even with these mitigations, path MTU issues are
+ still possible.
+
+2.1.2. Provider Edge (PE)
+
+ The other location at the core-edge boundary for deploying LISP
+ routers is at the Internet service provider edge. The main incentive
+ for this case is that the customer does not have to upgrade the CE
+ router(s) or change the configuration of any equipment.
+ Encapsulation/decapsulation happens in the provider's network, which
+ may be able to serve several customers with a single device. For
+
+
+
+Jakab, et al. Experimental [Page 6]
+
+RFC 7215 LISP Deployment April 2014
+
+
+ large ISPs with many residential/business customers asking for LISP,
+ this can lead to important savings, since there is no need to upgrade
+ the software (or hardware, if that's the case) at each client's
+ location. Instead, they can upgrade the software (or hardware) on a
+ few PE routers serving the customers. This scenario is depicted in
+ Figure 2.
+
+ +----------+ +------------------+
+ | ISP1 | | ISP2 |
+ | | | |
+ | +----+ | | +----+ +----+ |
+ +--|xTR1|--+ +--|xTR2|--|xTR3|--+
+ +----+ +----+ +----+
+ | | |
+ | | |
+ +--<[LISP site]>---+-------+
+
+ Figure 2: xTRs at the Provider Edge
+
+ While this approach can make transition easy for customers and may be
+ cheaper for providers, the LISP site loses one of the main benefits
+ of LISP: ingress traffic engineering. Since the provider controls
+ the ETRs, additional complexity would be needed to allow customers to
+ modify their mapping entries.
+
+ The problem is aggravated when the LISP site is multihomed. Consider
+ the scenario in Figure 2: whenever a change to TE policies is
+ required, the customer contacts both ISP1 and ISP2 to make the
+ necessary changes on the routers (if they provide this possibility).
+ It is, however, unlikely that both ISPs will apply changes
+ simultaneously, which may lead to inconsistent state for the mappings
+ of the LISP site. Since the different upstream ISPs are usually
+ competing business entities, the ETRs may even be configured to
+ compete, to either attract all the traffic or get no traffic. The
+ former will happen if the customer pays per volume, the latter if the
+ connectivity has a fixed price. A solution could be to configure the
+ Map-Server(s) to do proxy-replying and have the Mapping Service
+ Provider (MSP) apply policies.
+
+ Additionally, since xTR1, xTR2, and xTR3 are in different
+ administrative domains, locator reachability information is unlikely
+ to be exchanged among them, making it difficult to set the
+ Locator-Status-Bits (LSBs) correctly on encapsulated packets.
+ Because of this, and due to the security concerns about LSBs as
+ described in [LISP-THREATS], their use is discouraged (set the L-bit
+ to 0). Map-Versioning is another alternative [RFC6834].
+
+
+
+
+
+Jakab, et al. Experimental [Page 7]
+
+RFC 7215 LISP Deployment April 2014
+
+
+ Compared to the customer edge scenario, deploying LISP at the
+ provider edge might have the advantage of diminishing potential MTU
+ issues, because the Tunnel Router is closer to the core, where links
+ typically have higher MTUs than edge network links.
+
+2.1.3. Tunnel Routers behind NAT
+
+ "NAT" in this section refers to IPv4 network address and port
+ translation.
+
+2.1.3.1. ITR
+
+ _.--. _.--.
+ ,-'' `--. +-------+ ,-'' `--.
+ ' EID ` (Private) | NAT | (Public) ,' RLOC `.
+ ( )---[ITR]---| |---------( )
+ . space ,' (Address) | Box |(Address) . space ,'
+ `--. _.-' +-------+ `--. _.-'
+ `--'' `--''
+
+ Figure 3: ITR behind NAT
+
+ Packets encapsulated by an ITR are just UDP packets from a NAT
+ device's point of view, and they are handled like any UDP packet;
+ there are no additional requirements for LISP data packets.
+
+ Map-Requests sent by an ITR, which create the state in the NAT table,
+ have a different 5-tuple in the IP header than the Map-Reply
+ generated by the authoritative ETR. Since the source address of this
+ packet is different from the destination address of the request
+ packet, no state will be matched in the NAT table and the packet will
+ be dropped. To avoid this, the NAT device has to do the following:
+
+ o Send all UDP packets with source port 4342, regardless of the
+ destination port, to the RLOC of the ITR. The simplest way to
+ achieve this is configuring 1:1 NAT mode from the external RLOC of
+ the NAT device to the ITR's RLOC (called "DMZ" mode in consumer
+ broadband routers).
+
+ o Rewrite the ITR-AFI and "Originating ITR RLOC Address" fields in
+ the payload.
+
+ This setup supports only a single ITR behind the NAT device.
+
+
+
+
+
+
+
+
+Jakab, et al. Experimental [Page 8]
+
+RFC 7215 LISP Deployment April 2014
+
+
+2.1.3.2. ETR
+
+ An ETR placed behind NAT is reachable from the outside by the
+ Internet-facing locator of the NAT device. It needs to know this
+ locator (and configure a loopback interface with it), so that it can
+ use it in Map-Reply and Map-Register messages. Thus, support for
+ dynamic locators for the mapping database is needed in LISP
+ equipment.
+
+ Again, only one ETR behind the NAT device is supported.
+
+ _.--. _.--.
+ ,-'' `--. +-------+ ,-'' `--.
+ ' EID ` (Private) | NAT | (Public) ,' RLOC `.
+ ( )---[ETR]---| |---------( )
+ . space ,' (Address) | Box |(Address) . space ,'
+ `--. _.-' +-------+ `--. _.-'
+ `--'' `--''
+
+ Figure 4: ETR behind NAT
+
+2.1.3.3. Additional Notes
+
+ An implication of the issues described above is that LISP sites with
+ xTRs cannot be behind carrier-based NATs, since two different sites
+ would collide on the same forwarded UDP port. An alternative to
+ static hole-punching to explore is the use of the Port Control
+ Protocol (PCP) [RFC6887].
+
+ We only include this scenario due to completeness, to show that a
+ LISP site can be deployed behind NAT should it become necessary.
+ However, LISP deployments behind NAT should be avoided, if possible.
+
+2.2. Functional Models with Tunnel Routers
+
+ This section describes how certain LISP deployments can provide
+ network functions.
+
+2.2.1. Split ITR/ETR
+
+ In a simple LISP deployment, xTRs are located at the border of the
+ LISP site (see Section 2.1.1). In this scenario, packets are routed
+ inside the domain according to the EID. However, more complex
+ networks may want to route packets according to the destination RLOC.
+ This would enable them to choose the best egress point.
+
+
+
+
+
+
+Jakab, et al. Experimental [Page 9]
+
+RFC 7215 LISP Deployment April 2014
+
+
+ The LISP specification separates the ITR and ETR functionality and
+ allows both entities to be deployed in separated network equipment.
+ ITRs can be deployed closer to the host (i.e., access routers). This
+ way, packets are encapsulated as soon as possible, and egress point
+ selection is driven by operational policy. In turn, ETRs can be
+ deployed at the border routers of the network, and packets are
+ decapsulated as soon as possible. Once decapsulated, packets are
+ routed based on the destination EID according to internal routing
+ policy.
+
+ We can see an example in Figure 5. The Source (S) transmits packets
+ using its EID, and in this particular case packets are encapsulated
+ at ITR_1. The encapsulated packets are routed inside the domain
+ according to the destination RLOC and can egress the network through
+ the best point (i.e., closer to the RLOC's Autonomous System (AS)).
+ On the other hand, inbound packets are received by ETR_1, which
+ decapsulates them. Then, packets are routed towards S according to
+ the EID, again following the best path.
+
+ +---------------------------------------+
+ | |
+ | +-------+ +-------+ +-------+
+ | | ITR_1 |---------+ | ETR_1 |-RLOC_A--| ISP_A |
+ | +-------+ | +-------+ +-------+
+ | +-+ | | |
+ | |S| | IGP | |
+ | +-+ | | |
+ | +-------+ | +-------+ +-------+
+ | | ITR_2 |---------+ | ETR_2 |-RLOC_B--| ISP_B |
+ | +-------+ +-------+ +-------+
+ | |
+ +---------------------------------------+
+
+ Figure 5: Split ITR/ETR Scenario
+
+ This scenario has a set of implications:
+
+ o The site must carry more-specific routes in order to choose the
+ best egress point, and typically BGP is used for this, increasing
+ the complexity of the network. However, this is usually already
+ the case for LISP sites that would benefit from this scenario.
+
+ o If the site is multihomed to different ISPs and any of the
+ upstream ISPs are doing unicast reverse path forwarding (uRPF)
+ filtering, this scenario may become impractical. To set the
+ correct source RLOC in the encapsulation header, ITRs need to
+ first determine which ETR will be used by the outgoing packet.
+ This adds complexity and reliability concerns.
+
+
+
+Jakab, et al. Experimental [Page 10]
+
+RFC 7215 LISP Deployment April 2014
+
+
+ o In LISP, ITRs set the reachability bits when encapsulating data
+ packets. Hence, ITRs need a mechanism to be aware of the liveness
+ of all ETRs serving their site.
+
+ o The MTU within the site network must be large enough to
+ accommodate encapsulated packets.
+
+ o In this scenario, each ITR is serving fewer hosts than in the case
+ when it is deployed at the border of the network. It has been
+ shown that the cache hit rate grows logarithmically with the
+ amount of users [CACHE]. Taking this into account, when ITRs are
+ deployed closer to the host the effectiveness of the mapping cache
+ may be lower (i.e., the miss rate is higher). Another consequence
+ of this is that the site may transmit a higher amount of
+ Map-Requests, increasing the load on the distributed mapping
+ database.
+
+ o By placing the ITRs inside the site, they will still need global
+ RLOCs. This may add complexity to intra-site routing
+ configurations and more intra-site issues when there is a change
+ of providers.
+
+2.2.2. Inter-Service-Provider Traffic Engineering
+
+ At the time of this writing, if two ISPs want to control their
+ ingress TE policies for transit traffic between them, they need to
+ rely on existing BGP mechanisms. This typically means deaggregating
+ prefixes to choose on which upstream link packets should enter. This
+ either is not feasible (if fine-grained per-customer control is
+ required, the very-specific prefixes may not be propagated) or
+ increases DFZ table size.
+
+ Typically, LISP is seen as applicable only to stub networks; however,
+ LISP can also be applied in a recursive manner, providing service
+ provider ingress/egress TE capabilities without impacting the DFZ
+ table size.
+
+ In order to implement this functionality with LISP, consider the
+ scenario depicted in Figure 6. The two ISPs willing to achieve
+ ingress/egress TE are labeled as ISP_A and ISP_B. They are servicing
+ Stub1 and Stub2, respectively. Both are required to be LISP sites
+ with their own xTRs. In this scenario, we assume that Stub1 and
+ Stub2 are communicating with each other; thus, ISP_A and ISP_B offer
+ transit for such communications. ISP_A has RLOC_A1 and RLOC_A2 as
+ upstream IP addresses, while ISP_B has RLOC_B1 and RLOC_B2. The
+ shared goal among ISP_A and ISP_B is to control the transit traffic
+ flow between RLOC_A1/A2 and RLOC_B1/B2.
+
+
+
+
+Jakab, et al. Experimental [Page 11]
+
+RFC 7215 LISP Deployment April 2014
+
+
+ _.--.
+ Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub2
+ \ | R_A1|----,' `. ---|R_B1 | /
+ --| | ( Transit ) | |--
+ ... .../ | R_A2|-----. ,' ---|R_B2 | \... ...
+ +-------+ `--. _.-' +-------+
+ ... ... ISP_A `--'' ISP_B ... ...
+
+ Figure 6: Inter-Service-Provider TE Scenario
+
+ Both ISPs deploy xTRs on RLOC_A1/A2 and RLOC_B1/B2, respectively and
+ reach a bilateral agreement to deploy their own private mapping
+ system. This mapping system contains bindings between the RLOCs of
+ Stub1 and Stub2 (owned by ISP_A and ISP_B, respectively) and RLOC_A1/
+ A2 and RLOC_B1/B2. Such bindings are in fact the TE policies between
+ both ISPs, and the convergence time is expected to be fast, since
+ ISPs only have to update/query a mapping to/from the database.
+
+ The packet flow is as follows. First, a packet originated at Stub1
+ towards Stub2 is LISP encapsulated by Stub1's xTR. The xTR of ISP_A
+ recursively encapsulates it, and according to the TE policies stored
+ in the private mapping system the ISP_A xTR chooses RLOC_B1 or
+ RLOC_B2 as the outer encapsulation destination. Note that the packet
+ transits between ISP_A and ISP_B double-encapsulated. Upon reception
+ at the xTR of ISP_B, the packet is decapsulated and sent towards
+ Stub2, which performs the last decapsulation.
+
+ This deployment scenario, which uses recursive LISP, includes three
+ important caveats. First, it is intended to be deployed between only
+ two ISPs. If more than two ISPs use this approach, then either the
+ xTRs deployed at the participating ISPs must query multiple mapping
+ systems, or the ISPs must agree on a common shared mapping system.
+ Furthermore, keeping this deployment scenario restricted to only two
+ ISPs maintains a scalable solution, given that only two entities need
+ to agree on using recursive LISP and only one private mapping system
+ is involved.
+
+ Second, the scenario is only recommended for ISPs providing
+ connectivity to LISP sites, such that source RLOCs of packets to be
+ recursively encapsulated belong to said ISP. Otherwise, the
+ participating ISPs must register prefixes they do not own in the
+ above-mentioned private mapping system. This results in either
+ requiring complex authentication mechanisms or enabling simple
+ traffic redirection attacks. Failure to follow these recommendations
+ may lead to operational security issues when deploying this scenario.
+
+ And third, recursive encapsulation models are typically complex to
+ troubleshoot and debug.
+
+
+
+Jakab, et al. Experimental [Page 12]
+
+RFC 7215 LISP Deployment April 2014
+
+
+ Besides these recommendations, the main disadvantages of this
+ deployment case are:
+
+ o An extra LISP header is needed. This increases the packet size
+ and requires that the MTU between both ISPs accommodate double-
+ encapsulated packets.
+
+ o The ISP ITR must encapsulate packets and therefore must know the
+ RLOC-to-RLOC bindings. These bindings are stored in a mapping
+ database and may be cached in the ITR's mapping cache. Cache
+ misses lead to an additional lookup latency, unless a push-based
+ mapping system is used for the private mapping system.
+
+ o Maintaining the shared mapping database involves operational
+ overhead.
+
+2.3. Summary and Feature Matrix
+
+ When looking at the deployment scenarios and functional models above,
+ there are several things to consider when choosing an appropriate
+ model, depending on the type of the organization doing the
+ deployment.
+
+ For home users and small sites that wish to multihome and have
+ control over their ISP options, the "CE" scenario offers the most
+ advantages: it's simple to deploy, and in some cases it only requires
+ a software upgrade of the Customer Premises Equipment (CPE), getting
+ mapping service, and configuring the router. It retains control of
+ TE and choosing upstreams by the user. It doesn't provide too many
+ advantages to ISPs, due to the lessened dependence on their services
+ in cases of multihomed clients. It is also unlikely that ISPs
+ wishing to offer LISP to their customers will choose the "CE" model,
+ as they would need to send a technician to each customer and,
+ potentially, a new CPE device. Even if they have remote control over
+ the router and a software upgrade could add LISP support, the
+ operation is too risky.
+
+ For a network operator, a good option to deploy is the "PE" scenario,
+ unless a hardware upgrade is required for its edge routers to support
+ LISP (in which case upgrading CPEs may be simpler). It retains
+ control of TE as well as the choice of Proxy Egress Tunnel Router
+ (PETR) and Map-Server/Map-Resolver. It also lowers potential MTU
+ issues, as discussed above. Network operators should also explore
+ the "inter-service-provider TE" (recursive) functional model for
+ their TE needs.
+
+ To optimize their traffic flow, large organizations can benefit the
+ most from the "split ITR/ETR" functional model.
+
+
+
+Jakab, et al. Experimental [Page 13]
+
+RFC 7215 LISP Deployment April 2014
+
+
+ The following table gives a quick overview of the features supported
+ by each of the deployment scenarios discussed above (marked with an
+ "x" in the appropriate column): "CE" for customer edge, "PE" for
+ provider edge, "Split" for split ITR/ETR, and "Recursive" for
+ inter-service-provider traffic engineering. The discussed features
+ include:
+
+ Control of ingress TE: This scenario allows the LISP site to easily
+ control LISP ingress traffic engineering policies.
+
+ No modifications to existing int. network infrastructure: This
+ scenario doesn't require the LISP site to modify internal network
+ configurations.
+
+ Locator-Status-Bits sync: This scenario allows easy synchronization
+ of the Locator Status Bits.
+
+ MTU/PMTUD issues minimized: The scenario minimizes potential MTU and
+ Path MTU Discovery (PMTUD) issues.
+
+ Feature CE PE Split Recursive NAT
+ --------------------------------------------------------------------
+ Control of ingress TE x - x x x
+ No modifications to existing
+ int. network infrastructure x x - - x
+ Locator-Status-Bits sync x - x x -
+ MTU/PMTUD issues minimized - x - - -
+
+3. Map-Servers and Map-Resolvers
+
+ Map-Servers and Map-Resolvers make up the LISP mapping system and
+ provide a means to find authoritative EID-to-RLOC mapping
+ information, conforming to [RFC6833]. They are meant to be deployed
+ in RLOC space, and their operation behind NAT is not supported.
+
+3.1. Map-Servers
+
+ The Map-Server learns EID-to-RLOC mapping entries from an
+ authoritative source and publishes them in the distributed mapping
+ database. These entries are learned through authenticated
+ Map-Register messages sent by authoritative ETRs. Also, upon
+ reception of a Map-Request, the Map-Server verifies that the
+ destination EID matches an EID-Prefix for which it is authoritative
+ and then re-encapsulates and forwards it to a matching ETR.
+ Map-Server functionality is described in detail in [RFC6833].
+
+
+
+
+
+
+Jakab, et al. Experimental [Page 14]
+
+RFC 7215 LISP Deployment April 2014
+
+
+ The Map-Server is provided by a Mapping Service Provider (MSP). The
+ MSP participates in the global distributed mapping database
+ infrastructure by setting up connections to other participants
+ according to the specific mapping system that is employed (e.g.,
+ Alternative Logical Topology (ALT) [RFC6836], Delegated Database Tree
+ (DDT) [LISP-DDT]). Participation in the mapping database and the
+ storing of EID-to-RLOC mapping data are subject to the policies of
+ the "root" operators, who should check ownership rights for the
+ EID-Prefixes stored in the database by participants. These policies
+ are out of scope for this document.
+
+ The LISP DDT protocol is used by LISP MSPs to provide reachability
+ between those providers' Map-Resolvers and Map-Servers. The DDT root
+ is currently operated by a collection of organizations on an open
+ basis. See [DDT-ROOT] for more details. Similarly to the DNS root,
+ it has several different server instances using names of the letters
+ of the Greek alphabet (alpha, delta, etc.), operated by independent
+ organizations. When this document was published, there were 6 such
+ instances, with one of them being anycasted. [DDT-ROOT] provides the
+ list of server instances on its web site and configuration files for
+ several Map-Server implementations. The DDT root and LISP Mapping
+ Providers both rely on and abide by existing allocation policies as
+ defined by Regional Internet Registries (RIRs) to determine prefix
+ ownership for use as EIDs.
+
+ It is expected that the DDT root organizations will continue to
+ evolve in response to experimentation with LISP deployments for
+ Internet edge multihoming and VPN use cases.
+
+ In all cases, the MSP configures its Map-Server(s) to publish the
+ prefixes of its clients in the distributed mapping database and start
+ encapsulating and forwarding Map-Requests to the ETRs of the AS.
+ These ETRs register their prefix(es) with the Map-Server(s) through
+ periodic authenticated Map-Register messages. In this context, for
+ some LISP sites, there is a need for mechanisms to:
+
+ o Automatically distribute EID-Prefix(es) shared keys between the
+ ETRs and the EID-registrar Map-Server.
+
+ o Dynamically obtain the address of the Map-Server in the ETR of
+ the AS.
+
+ The Map-Server plays a key role in the reachability of the
+ EID-Prefixes it is serving. On one hand, it is publishing these
+ prefixes into the distributed mapping database, and on the other
+ hand, it is encapsulating and forwarding Map-Requests to the
+ authoritative ETRs of these prefixes. ITRs encapsulating towards
+ EIDs for which a failed Map-Server is responsible will be unable to
+
+
+
+Jakab, et al. Experimental [Page 15]
+
+RFC 7215 LISP Deployment April 2014
+
+
+ look up any of their covering prefixes. The only exceptions are the
+ ITRs that already contain the mappings in their local caches. In
+ this case, ITRs can reach ETRs until the entry expires (typically
+ 24 hours). For this reason, redundant Map-Server deployments are
+ desirable. A set of Map-Servers providing high-availability service
+ to the same set of prefixes is called a redundancy group. ETRs are
+ configured to send Map-Register messages to all Map-Servers in the
+ redundancy group. The configuration for fail-over (or
+ load-balancing, if desired) among the members of the group depends on
+ the technology behind the mapping system being deployed. Since ALT
+ is based on BGP and DDT takes its inspiration from the Domain Name
+ System (DNS), deployments can leverage current industry best
+ practices for redundancy in BGP and DNS. These best practices are
+ out of scope for this document.
+
+ Additionally, if a Map-Server has no reachability for any ETR serving
+ a given EID block, it should not originate that block into the
+ mapping system.
+
+3.2. Map-Resolvers
+
+ A Map-Resolver is a network infrastructure component that accepts
+ LISP-encapsulated Map-Requests, typically from an ITR, and finds the
+ appropriate EID-to-RLOC mapping by consulting the distributed mapping
+ database. Map-Resolver functionality is described in detail in
+ [RFC6833].
+
+ Anyone with access to the distributed mapping database can set up a
+ Map-Resolver and provide EID-to-RLOC mapping lookup service.
+ Database access setup is mapping system specific.
+
+ For performance reasons, it is recommended that LISP sites use
+ Map-Resolvers that are topologically close to their ITRs. ISPs
+ supporting LISP will provide this service to their customers,
+ possibly restricting access to their user base. LISP sites not in
+ this position can use open access Map-Resolvers, if available.
+ However, regardless of the availability of open access resolvers, the
+ MSP providing the Map-Server(s) for a LISP site should also make
+ available Map-Resolver(s) for the use of that site.
+
+ In medium- to large-size ASes, ITRs must be configured with the RLOC
+ of a Map-Resolver; this type of operation can be done manually.
+ However, in Small Office/Home Office (SOHO) scenarios, a mechanism
+ for autoconfiguration should be provided.
+
+ One solution to avoid manual configuration in LISP sites of any size
+ is the use of anycast [RFC4786] RLOCs for Map-Resolvers, similar to
+ the DNS root server infrastructure. Since LISP uses UDP
+
+
+
+Jakab, et al. Experimental [Page 16]
+
+RFC 7215 LISP Deployment April 2014
+
+
+ encapsulation, the use of anycast would not affect reliability. LISP
+ routers are then shipped with a preconfigured list of well-known
+ Map-Resolver RLOCs, which can be edited by the network administrator,
+ if needed.
+
+ The use of anycast also helps improve mapping lookup performance.
+ Large MSPs can increase the number and geographical diversity of
+ their Map-Resolver infrastructure, using a single anycasted RLOC.
+ Once LISP deployment is advanced enough, very large content providers
+ may also be interested in running this kind of setup, to ensure
+ minimal connection setup latency for those connecting to their
+ network from LISP sites.
+
+ While Map-Servers and Map-Resolvers implement different
+ functionalities within the LISP mapping system, they can coexist on
+ the same device. For example, MSPs offering both services can deploy
+ a single Map-Resolver/Map-Server in each PoP where they have a
+ presence.
+
+4. Proxy Tunnel Routers
+
+4.1. PITRs
+
+ Proxy Ingress Tunnel Routers (PITRs) are part of the non-LISP/LISP
+ transition mechanism, allowing non-LISP sites to reach LISP sites.
+ They announce via BGP certain EID-Prefixes (aggregated, whenever
+ possible) to attract traffic from non-LISP sites towards EIDs in the
+ covered range. They do the mapping system lookup and encapsulate
+ received packets towards the appropriate ETR. Note that for the
+ reverse path, LISP sites can reach non-LISP sites by simply not
+ encapsulating traffic. See [RFC6832] for a detailed description of
+ PITR functionality.
+
+ The success of new protocols depends greatly on their ability to
+ maintain backwards compatibility and interoperate with the
+ protocol(s) they intend to enhance or replace, and on the incentives
+ to deploy the necessary new software or equipment. A LISP site needs
+ an interworking mechanism to be reachable from non-LISP sites. A
+ PITR can fulfill this role, enabling early adopters to see the
+ benefits of LISP, similar to tunnel brokers helping the transition
+ from IPv4 to IPv6. A site benefits from new LISP functionality
+ (proportionally with existing global LISP deployment) when migrating
+ to LISP, so it has the incentives to deploy the necessary Tunnel
+ Routers. In order to be reachable from non-LISP sites, it has two
+ options: keep announcing its prefix(es) with BGP, or have a PITR
+ announce prefix(es) covering them.
+
+
+
+
+
+Jakab, et al. Experimental [Page 17]
+
+RFC 7215 LISP Deployment April 2014
+
+
+ If the goal of reducing the DFZ routing table size is to be reached,
+ the second option is preferred. Moreover, the second option allows
+ LISP-based ingress traffic engineering from all sites. However, the
+ placement of PITRs significantly influences performance and
+ deployment incentives. Section 5 is dedicated to the migration to a
+ LISP-enabled Internet and includes deployment scenarios for PITRs.
+
+4.2. PETRs
+
+ In contrast to PITRs, PETRs are not required for the correct
+ functioning of all LISP sites. There are two cases where they can be
+ of great help:
+
+ o LISP sites with unicast reverse path forwarding (uRPF)
+ restrictions, and
+
+ o Communication between sites using different address family RLOCs.
+
+ In the first case, uRPF filtering is applied at the LISP site's
+ upstream provider's PE router. When forwarding traffic to non-LISP
+ sites, an ITR does not encapsulate packets, leaving the original IP
+ headers intact. As a result, packets will have EIDs in their source
+ address. Since we are discussing the transition period, we can
+ assume that a prefix covering the EIDs belonging to the LISP site is
+ advertised to the global routing tables by a PITR, and the PE router
+ has a route towards it. However, the next hop will not be on the
+ interface towards the CE router, so non-encapsulated packets will
+ fail uRPF checks.
+
+ To avoid this filtering, the affected ITR encapsulates packets
+ towards the locator of the PETR for non-LISP destinations. Now the
+ source address of the packets, as seen by the PE router, is the ITR's
+ locator, which will not fail the uRPF check. The PETR then
+ decapsulates and forwards the packets.
+
+ The second use case is IPv4-to-IPv6 transition. Service providers
+ using older access network hardware that only supports IPv4 can still
+ offer IPv6 to their clients by providing a CPE device running LISP,
+ and PETR(s) for accessing IPv6-only non-LISP sites and LISP sites,
+ with IPv6-only locators. Packets originating from the client LISP
+ site for these destinations would be encapsulated towards the PETR's
+ IPv4 locator. The PETR is in a native IPv6 network, decapsulating
+ and forwarding packets. For non-LISP destinations, the packet
+ travels natively from the PETR. For LISP destinations with IPv6-only
+ locators, the packet will go through a PITR in order to reach its
+ destination.
+
+ For more details on PETRs, see [RFC6832].
+
+
+
+Jakab, et al. Experimental [Page 18]
+
+RFC 7215 LISP Deployment April 2014
+
+
+ PETRs can be deployed by ISPs wishing to offer value-added services
+ to their customers. As is the case with PITRs, PETRs too may
+ introduce path stretch (the ratio between the cost of the selected
+ path and that of the optimal path). Because of this, the ISP needs
+ to consider the tradeoff of using several devices close to the
+ customers to minimize it, or fewer devices farther away from the
+ customers to minimize cost instead.
+
+ Since the deployment incentives for PITRs and PETRs are different, it
+ is likely that they will be deployed in separate devices, except for
+ the Content Delivery Network (CDN) case, which may deploy both in a
+ single device.
+
+ In all cases, the existence of a PETR involves another step in the
+ configuration of a LISP router. CPE routers, which are typically
+ configured by DHCP, stand to benefit most from PETRs.
+ Autoconfiguration of the PETR locator could be achieved by a DHCP
+ option or by adding a PETR field to either Map-Notify or Map-Reply
+ messages.
+
+5. Migration to LISP
+
+ This section discusses a deployment architecture to support the
+ migration to a LISP-enabled Internet. The loosely defined terms
+ "early transition phase", "late transition phase", and "LISP Internet
+ phase" refer to time periods when LISP sites are a minority, a
+ majority, or represent all edge networks, respectively.
+
+5.1. LISP+BGP
+
+ For sites wishing to migrate to LISP with their Provider-Independent
+ (PI) prefix, the least disruptive way is to upgrade their border
+ routers to support LISP and register the prefix into the LISP mapping
+ system, but to keep announcing it with BGP as well. This way, LISP
+ sites will reach them over LISP, while legacy sites will be
+ unaffected by the change. The main disadvantage of this approach is
+ that no decrease in the DFZ routing table size is achieved. Still,
+ just increasing the number of LISP sites is an important gain, as an
+ increasing LISP/non-LISP site ratio may decrease the need for
+ BGP-based traffic engineering that leads to prefix deaggregation.
+ That, in turn, may lead to a decrease in the DFZ size and churn in
+ the late transition phase.
+
+
+
+
+
+
+
+
+
+Jakab, et al. Experimental [Page 19]
+
+RFC 7215 LISP Deployment April 2014
+
+
+ This scenario is not limited to sites that already have their
+ prefixes announced with BGP. Newly allocated EID blocks could follow
+ this strategy as well during the early LISP deployment phase,
+ depending on the cost/benefit analysis of the individual networks.
+ Since this leads to an increase in the DFZ size, the following
+ architecture should be preferred for new allocations.
+
+5.2. Mapping Service Provider (MSP) PITR Service
+
+ In addition to publishing their clients' registered prefixes in the
+ mapping system, MSPs with enough transit capacity can offer PITR
+ service to them as a separate service. This service is especially
+ useful for new PI allocations to sites without existing BGP
+ infrastructure wishing to avoid BGP altogether. The MSP announces
+ the prefix into the DFZ, and the client benefits from ingress traffic
+ engineering without prefix deaggregation. The downside of this
+ scenario is added path stretch.
+
+ Routing all non-LISP ingress traffic through a third party that is
+ not one of its ISPs is only feasible for sites with modest amounts of
+ traffic (like those using the IPv6 tunnel broker services today),
+ especially in the first stage of the transition to LISP, with a
+ significant number of legacy sites. This is because the handling of
+ said traffic is likely to result in additional costs, which would be
+ passed down to the client. When the LISP/non-LISP site ratio becomes
+ high enough, this approach can prove increasingly attractive.
+
+ Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix
+ deaggregation for traffic engineering purposes, resulting in slower
+ routing table increase in the case of new allocations and potential
+ decrease for existing ones. Moreover, MSPs serving different clients
+ with adjacent aggregatable prefixes may lead to additional decrease,
+ but quantifying this decrease is subject to future research study.
+
+5.3. Proxy-ITR Route Distribution (PITR-RD)
+
+ Instead of a LISP site or the MSP announcing its EIDs with BGP to the
+ DFZ, this function can be outsourced to a third party, a PITR Service
+ Provider (PSP). This will result in a decrease in operational
+ complexity at both the site and the MSP.
+
+ The PSP manages a set of distributed PITR(s) that will advertise the
+ corresponding EID-Prefixes through BGP to the DFZ. These PITRs will
+ then encapsulate the traffic they receive for those EIDs towards the
+ RLOCs of the LISP site, ensuring their reachability from non-LISP
+ sites.
+
+
+
+
+
+Jakab, et al. Experimental [Page 20]
+
+RFC 7215 LISP Deployment April 2014
+
+
+ While it is possible for a PSP to manually configure each client's
+ EID-Routes to be announced, this approach offers little flexibility
+ and is not scalable. This section presents a scalable architecture
+ that offers automatic distribution of EID-Routes to LISP sites and
+ service providers.
+
+ The architecture requires no modification to existing LISP network
+ elements, but it introduces a new (conceptual) network element, the
+ EID-Route Server, which is defined as a router that either propagates
+ routes learned from other EID-Route Servers or originates EID-Routes.
+ The EID-Routes that it originates are those for which it is
+ authoritative. It propagates these routes to Proxy-ITRs within the
+ AS of the EID-Route Server. It is worth noting that a BGP-capable
+ router can also be considered an EID-Route Server.
+
+ Further, an EID-Route is defined as a prefix originated via the Route
+ Server of the MSP, which should be aggregated if the MSP has multiple
+ customers inside a single large continuous prefix. This prefix is
+ propagated to other PITRs both within the MSP and to other PITR
+ operators with which it peers. EID-Route Servers are operated by
+ either the LISP site, MSPs, or PSPs and may be collocated with a
+ Map-Server or PITR, but they are functionally discrete entities.
+ They distribute EID-Routes, using BGP, to other domains according to
+ policies set by participants.
+
+ MSP (AS64500)
+ RS ---> PITR
+ | /
+ | _.--./
+ ,-'' /`--.
+ LISP site ---,' | v `.
+ ( | DFZ )----- Mapping system
+ non-LISP site ----. | ^ ,'
+ `--. / _.-'
+ | `--''
+ v /
+ PITR
+ PSP (AS64501)
+
+ Figure 7: PITR-RD Architecture
+
+ The architecture described above decouples EID origination from route
+ propagation, with the following benefits:
+
+ o Can accurately represent business relationships between PITR
+ operators
+
+ o Is more mapping system agnostic
+
+
+
+Jakab, et al. Experimental [Page 21]
+
+RFC 7215 LISP Deployment April 2014
+
+
+ o Makes minor changes to PITR implementation; no changes to other
+ components
+
+ In the example in Figure 7, we have a MSP providing services to the
+ LISP site. The LISP site does not run BGP and gets an EID allocation
+ directly from a RIR, or from the MSP, which may be a Local Internet
+ Registry (LIR). Existing PI allocations can be migrated as well.
+ The MSP ensures the presence of the prefix in the mapping system and
+ runs an EID-Route Server to distribute it to PSPs. Since the LISP
+ site does not run BGP, the prefix will be originated with the AS
+ number of the MSP.
+
+ In the simple case depicted in Figure 7, the EID-Route of a LISP site
+ will be originated by the Route Server and announced to the DFZ by
+ the PSP's PITRs with AS path 64501 64500. From that point on, the
+ usual BGP dynamics apply. This way, routes announced by the PITR are
+ still originated by the authoritative Route Server. Note that the
+ peering relationships between MSPs/PSPs and those in the underlying
+ forwarding plane may not be congruent, making the AS path to a PITR
+ shorter than it is in reality.
+
+ The non-LISP site will select the best path towards the EID-Prefix
+ according to its local BGP policies. Since AS-path length is usually
+ an important metric for selecting paths, careful placement of PITRs
+ could significantly reduce path stretch between LISP and non-LISP
+ sites.
+
+ The architecture allows for flexible policies between MSPs/PSPs.
+ Consider the EID-Route Server networks as control plane overlays,
+ facilitating the implementation of policies necessary to reflect the
+ business relationships between participants. The results are then
+ injected into the common underlying forwarding plane. For example,
+ some MSPs/PSPs may agree to exchange EID-Prefixes and only announce
+ them to each of their forwarding plane customers. Global
+ reachability of an EID-Prefix depends on the MSP from which the LISP
+ site buys service and is also subject to agreement between the above-
+ mentioned parties.
+
+ In terms of impact on the DFZ, this architecture results in a slower
+ routing table increase for new allocations, since traffic engineering
+ will be done at the LISP level. For existing allocations migrating
+ to LISP, the DFZ may decrease, since MSPs may be able to aggregate
+ the prefixes announced.
+
+
+
+
+
+
+
+
+Jakab, et al. Experimental [Page 22]
+
+RFC 7215 LISP Deployment April 2014
+
+
+ Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix
+ deaggregation for traffic engineering purposes, resulting in slower
+ routing table increase in the case of new allocations and potential
+ decrease for existing ones. Moreover, MSPs serving different clients
+ with adjacent aggregatable prefixes may lead to additional decrease,
+ but quantifying this decrease is subject to future research study.
+
+ The flexibility and scalability of this architecture do not come
+ without a cost, however: A PSP operator has to establish either
+ transit or peering relationships to improve its connectivity.
+
+5.4. Migration Summary
+
+ Registering a domain name typically entails an annual fee that should
+ cover the operating expenses for publishing the domain in the global
+ DNS. This situation is similar for several other registration
+ services. A LISP MSP client publishing an EID-Prefix in the LISP
+ mapping system has the option of signing up for PITR services as
+ well, for an extra fee. These services may be offered by the MSP
+ itself, but it is expected that specialized PSPs will do it. Clients
+ that do not sign up will be responsible for getting non-LISP traffic
+ to their EIDs (using the LISP+BGP scenario).
+
+ Additionally, Tier 1 ISPs have incentives to offer PITR services to
+ non-subscribers in strategic places just to attract more traffic from
+ competitors and thus more revenue.
+
+ The following table presents the expected effects that the transition
+ scenarios at various phases will have on the DFZ routing table size:
+
+ Phase | LISP+BGP | MSP PITR | PITR-RD
+ -----------------+--------------+-----------------+----------------
+ Early transition | no change | slower increase | slower increase
+ Late transition | may decrease | slower increase | slower increase
+ LISP Internet | considerable decrease
+
+ It is expected that PITR-RD will coexist with LISP+BGP during the
+ migration, with the latter being more popular in the early transition
+ phase. As the transition progresses and the MSP PITR and PITR-RD
+ ecosystem gets more ubiquitous, LISP+BGP should become less
+ attractive, slowing down the increase of the number of routes in
+ the DFZ.
+
+ Note that throughout Section 5 we focused on the effects of LISP
+ deployment on the DFZ routing table size. Other metrics may be
+ impacted as well but to the best of our knowledge have not been
+ measured as yet.
+
+
+
+
+Jakab, et al. Experimental [Page 23]
+
+RFC 7215 LISP Deployment April 2014
+
+
+6. Security Considerations
+
+ All security implications of LISP deployments are to be discussed in
+ separate documents. [LISP-THREATS] gives an overview of LISP threat
+ models, including ETR operators attracting traffic by overclaiming an
+ EID-Prefix (Section 4.4.3 of [LISP-THREATS]). Securing mapping
+ lookups is discussed in [LISP-SEC].
+
+7. Acknowledgements
+
+ Many thanks to Margaret Wasserman for her contribution to the IETF 76
+ presentation that kickstarted this work. The authors would also like
+ to thank Damien Saucez, Luigi Iannone, Joel Halpern, Vince Fuller,
+ Dino Farinacci, Terry Manderson, Noel Chiappa, Hannu Flinck, Paul
+ Vinciguerra, Fred Templin, Brian Haberman, and everyone else who
+ provided input.
+
+8. References
+
+8.1. Normative References
+
+ [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
+ Locator/ID Separation Protocol (LISP)", RFC 6830,
+ January 2013.
+
+ [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
+ "Interworking between Locator/ID Separation Protocol
+ (LISP) and Non-LISP Sites", RFC 6832, January 2013.
+
+ [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
+ Protocol (LISP) Map-Server Interface", RFC 6833,
+ January 2013.
+
+8.2. Informative References
+
+ [CACHE] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS
+ performance and the effectiveness of caching", IEEE/ACM
+ Transactions on Networking (TON), Volume 10, Issue 5,
+ pages 589-603, October 2002.
+
+ [DDT-ROOT] "Introduction to LISP DDT: DDT Root", March 2014,
+ <http://ddt-root.org/>.
+
+ [LISP-DDT] Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
+ Delegated Database Tree", Work in Progress, March 2013.
+
+
+
+
+
+
+Jakab, et al. Experimental [Page 24]
+
+RFC 7215 LISP Deployment April 2014
+
+
+ [LISP-SEC] Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
+ and O. Bonaventure, "LISP-Security (LISP-SEC)", Work in
+ Progress, October 2013.
+
+ [LISP-THREATS]
+ Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
+ Analysis", Work in Progress, April 2014.
+
+ [RFC4459] Savola, P., "MTU and Fragmentation Issues with
+ In-the-Network Tunneling", RFC 4459, April 2006.
+
+ [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
+ Services", BCP 126, RFC 4786, December 2006.
+
+ [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
+ Workshop on Routing and Addressing", RFC 4984,
+ September 2007.
+
+ [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
+ Separation Protocol (LISP) Map-Versioning", RFC 6834,
+ January 2013.
+
+ [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation
+ Protocol Internet Groper (LIG)", RFC 6835, January 2013.
+
+ [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
+ "Locator/ID Separation Protocol Alternative Logical
+ Topology (LISP+ALT)", RFC 6836, January 2013.
+
+ [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
+ Selkirk, "Port Control Protocol (PCP)", RFC 6887,
+ April 2013.
+
+ [TELCO96] Federal Communications Commission, "Telecommunications Act
+ of 1996", 1996, <http://transition.fcc.gov/telecom.html>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jakab, et al. Experimental [Page 25]
+
+RFC 7215 LISP Deployment April 2014
+
+
+Appendix A. Step-by-Step Example BGP-to-LISP Migration Procedure
+
+ To help the operational community deploy LISP, this informative
+ section offers a step-by-step guide for migrating a BGP-based
+ Internet presence to a LISP site. It includes a pre-install/
+ pre-turn-up checklist, and customer and provider activation
+ procedures.
+
+A.1. Customer Pre-Install and Pre-Turn-Up Checklist
+
+ 1. Determine how many current physical service provider connections
+ the customer has, and their existing bandwidth and traffic
+ engineering requirements.
+
+ This information will determine the number of routing locators,
+ and the priorities and weights that should be configured on
+ the xTRs.
+
+ 2. Make sure the customer router has LISP capabilities.
+
+ * Check the OS version of the CE router. If LISP is an add-on,
+ check to see if it is installed.
+
+ This information can be used to determine if the platform is
+ appropriate to support LISP, in order to determine if a
+ software and/or hardware upgrade is required.
+
+ * Have the customer upgrade (if necessary, software and/or
+ hardware) to be LISP capable.
+
+ 3. Obtain the current running configuration of the CE router. A
+ suggested LISP router configuration example can be customized to
+ the customer's existing environment.
+
+ 4. Verify MTU handling.
+
+ * Request an increase in MTU to 1556 or more on service provider
+ connections. Prior to the MTU change, verify the transmission
+ of a 1500-byte packet from the PxTR to the RLOC with the Don't
+ Fragment (DF) bit set.
+
+ * Ensure that the customer is not filtering ICMP Unreachable or
+ Time Exceeded messages on their firewall or router.
+
+
+
+
+
+
+
+
+Jakab, et al. Experimental [Page 26]
+
+RFC 7215 LISP Deployment April 2014
+
+
+ LISP, like any tunneling protocol, will increase the size of
+ packets when the LISP header is appended. If increasing the MTU
+ of the access links is not possible, care must be taken that ICMP
+ is not being filtered in order to allow Path MTU Discovery to
+ take place.
+
+ 5. Validate member prefix allocation.
+
+ This step checks to see whether the prefix used by the customer
+ is a direct (Provider-Independent) prefix or a prefix assigned by
+ a physical service provider (Provider Aggregatable). If the
+ prefixes are assigned by other service providers, then a Letter
+ of Agreement is required to announce prefixes through the Proxy
+ Service Provider.
+
+ 6. Verify the member RLOCs and their reachability.
+
+ This step ensures that the RLOCs configured on the CE router are
+ in fact reachable and working.
+
+ 7. Prepare for cut-over.
+
+ * If possible, have a host outside of all security and filtering
+ policies connected to the console port of the edge router or
+ switch.
+
+ * Make sure the customer has access to the router in order to
+ configure it.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jakab, et al. Experimental [Page 27]
+
+RFC 7215 LISP Deployment April 2014
+
+
+A.2. Customer Activating LISP Service
+
+ 1. The customer configures LISP on CE router(s) according to the
+ configuration recommended by the service provider.
+
+ The LISP configuration consists of the EID-Prefix, the locators,
+ and the weights and priorities of the mapping between the two
+ values. In addition, the xTR must be configured with
+ Map-Resolver(s), Map-Server(s), and the shared key for
+ registering to Map-Server(s). If required, Proxy-ETR(s) may be
+ configured as well.
+
+ In addition to the LISP configuration:
+
+ * Ensure that the default routes(s) to next-hop external
+ neighbors is included and RLOCs are present in the
+ configuration.
+
+ * If two or more routers are used, ensure that all RLOCs are
+ included in the LISP configuration on all routers.
+
+ * It will be necessary to redistribute the default route via IGP
+ between the external routers.
+
+ 2. When transition is ready, perform a soft shutdown on existing
+ eBGP peer session(s).
+
+ * From the CE router, use the LISP Internet Groper (LIG)
+ [RFC6835] to ensure that registration is successful.
+
+ * To verify LISP connectivity, find and ping LISP connected
+ sites. If possible, find ping destinations that are not
+ covered by a prefix in the global BGP routing system, because
+ PITRs may deliver the packets even if LISP connectivity is not
+ working. Traceroutes may help determine if this is the case.
+
+ * To verify connectivity to non-LISP sites, try accessing a
+ landmark (e.g., a major Internet site) via a web browser.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jakab, et al. Experimental [Page 28]
+
+RFC 7215 LISP Deployment April 2014
+
+
+A.3. Cut-Over Provider Preparation and Changes
+
+ 1. Verify site configuration, and then verify active registration on
+ Map-Server(s).
+
+ * Authentication key.
+
+ * EID-Prefix.
+
+ 2. Add EID space to map-cache on proxies.
+
+ 3. Add networks to BGP advertisement on proxies.
+
+ * Modify route-maps/policies on PxTRs.
+
+ * Modify route policies on core routers (if non-connected
+ member).
+
+ * Modify ingress policies on core routers.
+
+ * Ensure route announcement in looking glass servers,
+ RouteViews.
+
+ 4. Perform traffic verification test.
+
+ * Ensure that MTU handling is as expected (PMTUD working).
+
+ * Ensure Proxy-ITR map-cache population.
+
+ * Ensure access from traceroute/ping servers around Internet.
+
+ * Use a looking glass to check for external visibility of
+ registration via several Map-Resolvers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jakab, et al. Experimental [Page 29]
+
+RFC 7215 LISP Deployment April 2014
+
+
+Authors' Addresses
+
+ Lorand Jakab
+ Cisco Systems
+ 170 Tasman Drive
+ San Jose, CA 95134
+ USA
+
+ EMail: lojakab@cisco.com
+
+
+ Albert Cabellos-Aparicio
+ Technical University of Catalonia
+ C/Jordi Girona, s/n
+ BARCELONA 08034
+ Spain
+
+ EMail: acabello@ac.upc.edu
+
+
+ Florin Coras
+ Technical University of Catalonia
+ C/Jordi Girona, s/n
+ BARCELONA 08034
+ Spain
+
+ EMail: fcoras@ac.upc.edu
+
+
+ Jordi Domingo-Pascual
+ Technical University of Catalonia
+ C/Jordi Girona, s/n
+ BARCELONA 08034
+ Spain
+
+ EMail: jordi.domingo@ac.upc.edu
+
+
+ Darrel Lewis
+ Cisco Systems
+ 170 Tasman Drive
+ San Jose, CA 95134
+ USA
+
+ EMail: darlewis@cisco.com
+
+
+
+
+
+
+Jakab, et al. Experimental [Page 30]
+