Internet Engineering Task Force (IETF)                         D. Saucez
Request for Comments: 7834                                         INRIA
Category: Informational                                       L. Iannone
ISSN: 2070-1721                                        Telecom ParisTech
                                                             A. Cabellos
                                                                F. Coras
                                       Technical University of Catalonia
                                                              April 2016
Internet Engineering Task Force (IETF)                         D. Saucez
Request for Comments: 7834                                         INRIA
Category: Informational                                       L. Iannone
ISSN: 2070-1721                                        Telecom ParisTech
                                                             A. Cabellos
                                                                F. Coras
                                       Technical University of Catalonia
                                                              April 2016

Locator/ID Separation Protocol (LISP) Impact




The Locator/ID Separation Protocol (LISP) aims to improve the Internet routing scalability properties by leveraging three principles: address role separation, encapsulation, and mapping. In this document, based on implementation work, deployment experiences, and theoretical studies, we discuss the impact that the deployment of LISP can have on both the routing infrastructure and the end user.


Status of This Memo


This document is not an Internet Standards Track specification; it is published for informational purposes.


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.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准;见RFC 5741第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at


Copyright Notice


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

版权所有(c)2016 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( 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.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

Table of Contents


   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  LISP in a Nutshell  . . . . . . . . . . . . . . . . . . . . .   4
   3.  LISP for Scaling the Internet Routing Architecture  . . . . .   5
   4.  Beyond Scaling the Internet Routing Architecture  . . . . . .   6
     4.1.  Traffic Engineering . . . . . . . . . . . . . . . . . . .   8
     4.2.  LISP for IPv6 Co-existence  . . . . . . . . . . . . . . .   8
     4.3.  Inter-domain Multicast  . . . . . . . . . . . . . . . . .   9
   5.  Impact of LISP on Operations and Business Models  . . . . . .  10
     5.1.  Impact on Non-LISP Traffic and Sites  . . . . . . . . . .  10
     5.2.  Impact on LISP Traffic and Sites  . . . . . . . . . . . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  LISP in a Nutshell  . . . . . . . . . . . . . . . . . . . . .   4
   3.  LISP for Scaling the Internet Routing Architecture  . . . . .   5
   4.  Beyond Scaling the Internet Routing Architecture  . . . . . .   6
     4.1.  Traffic Engineering . . . . . . . . . . . . . . . . . . .   8
     4.2.  LISP for IPv6 Co-existence  . . . . . . . . . . . . . . .   8
     4.3.  Inter-domain Multicast  . . . . . . . . . . . . . . . . .   9
   5.  Impact of LISP on Operations and Business Models  . . . . . .  10
     5.1.  Impact on Non-LISP Traffic and Sites  . . . . . . . . . .  10
     5.2.  Impact on LISP Traffic and Sites  . . . . . . . . . . . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18
1. Introduction
1. 介绍

The Locator/ID Separation Protocol (LISP) relies on three principles to improve the scalability properties of Internet routing: address role separation, encapsulation, and mapping. When invented, LISP was targeted at solving the Internet routing scaling problem [RFC4984]. There have now been years of implementations and experiments examining the impact and open questions of using LISP to improve inter-domain routing scalability. Experience has shown that because LISP utilizes mapping and encapsulation technologies, it can be deployed and used for purposes that go beyond routing scalability. For example, LISP provides a mean for a LISP site to precisely control its inter-domain outgoing and incoming traffic, with the possibility to apply different policies to different domains exchanging traffic with it. LISP can also be used to ease the transition from IPv4 to IPv6 as it allows the transport of IPv4 over IPv6 or IPv6 over IPv4. Furthermore, LISP also supports inter-domain multicast.


Leveraging implementation and deployment experience, as well as research work, this document describes, at a high level, the impacts and open questions still seen in LISP. This information is particularly useful for considering future approaches and to support further experimentation to clarify some large open questions (e.g., around the operations). LISP utilizes a tunnel-based data plane and a distributed control plane. LISP requires some new functionalities, such as reachability mechanisms. Because LISP is more than a simple encapsulation technology and is a new technology, until even more deployment experience is gained, some open questions related to LISP deployment and operations remain. As an encapsulation technology, there may be concerns on reduced Maximum Transmission Unit (MTU) size in some deployments. An important impact of LISP is on network operations related to resiliency and troubleshooting. As LISP relies on cached mappings and on encapsulation, resiliency during failures and troubleshooting may be more difficult. Also, the use of encapsulation may make failure detection and recovery slower, and it will require more coordination than with a single, non-encapsulated, routing domain solution.


2. LISP in a Nutshell
2. 口齿不清

LISP relies on three principles: address role separation, encapsulation, and mapping.


The address space is divided into two sets that have different semantic meanings: the Routing Locators (RLOCs) and the Endpoint Identifiers (EIDs). RLOCs are addresses typically assigned from the Provider Aggregatable (PA) address space. The EIDs are attributed to the nodes in the edge networks, by a block of contiguous addresses, which are typically Provider Independent (PI). To limit the scalability problem, LISP only requires the PA routes towards the RLOCs to be announced in the provider infrastructure. Whereas for non-LISP deployments, the EIDs need to be propagated as well.


LISP routers are used at the boundary between the EID and the RLOC spaces. Routers used to exit the EID space (towards the provider domain) are called Ingress Tunnel Routers (ITRs), and those used to enter the EID space (from the provider domain) are called the Egress Tunnel Routers (ETRs). When a host sends a packet to a remote destination, it sends it as in the non-LISP Internet. The packet arrives at the border of its site at an ITR. Because EIDs are not routable on the Internet, the packet is encapsulated with the source address set to the ITR RLOC and the destination address set to the ETR RLOC. The encapsulated packet is then forwarded in the provider domain until it reaches the selected ETR. The ETR de-encapsulates the packet and forwards it to its final destination. The acronym xTR stands for Ingress/Egress Tunnel Router and is used for a router playing these two roles.

LISP路由器用于EID和RLOC空间之间的边界。用于退出EID空间(通向提供商域)的路由器称为入口隧道路由器(ITR),用于进入EID空间(来自提供商域)的路由器称为出口隧道路由器(ETR)。当主机向远程目的地发送数据包时,它会像在非LISP Internet中一样发送数据包。数据包到达ITR的站点边界。由于EID不能在Internet上路由,因此数据包被封装为源地址设置为ITR RLOC,目标地址设置为ETR RLOC。然后在提供者域中转发封装的数据包,直到它到达选定的ETR。ETR反封装数据包并将其转发到最终目的地。缩写词xTR代表入口/出口隧道路由器,用于扮演这两个角色的路由器。

The correspondence between EIDs and RLOCs is given by the mappings. When an ITR needs to find ETR RLOCs that serve an EID, it queries a mapping system. With the LISP Canonical Address Format (LCAF) [LISP-LCAF], LISP is not restricted to the Internet protocol for the EID addresses. With LCAF, any address type can be used as EID (the address is only the key for the mapping lookup). LISP can transport, for example, Ethernet frames over the Internet.

EID和RLOCs之间的对应关系由映射给出。当ITR需要查找为EID提供服务的ETR RLOC时,它会查询映射系统。使用LISP标准地址格式(LCAF)[LISP-LCAF],LISP不限于EID地址的Internet协议。使用LCAF,任何地址类型都可以用作EID(地址只是映射查找的键)。例如,LISP可以通过Internet传输以太网帧。

An introduction to LISP can be found in [RFC7215]. The LISP specifications are given in [RFC6830], [RFC6833], [LISP-DDT], [RFC6836], [RFC6832], and [RFC6834].


3. LISP for Scaling the Internet Routing Architecture
3. 用于扩展Internet路由体系结构的LISP

The original goal of LISP was to improve the scalability properties of the Internet routing architecture. LISP utilizes traffic engineering and stub Autonomous System (AS) prefixes (not announced anymore in the Default-Free Zone (DFZ)), so that routing tables are smaller and more stable (i.e., they experience less churn). Furthermore, at the edge of the network, information necessary to forward packets (i.e., the mappings) is obtained on demand using a pull model (whereas the current Internet BGP model uses a push model). Therefore, the scalability of edge networks is less dependent on the Internet's size and more related to its traffic matrix. This scaling improvement has been proven by several studies (see below). The research studies cited hereafter are based on the following assumptions:


o EID-to-RLOC mappings follow the same prefix size as the current BGP routing infrastructure (current PI addresses only);

o EID到RLOC的映射遵循与当前BGP路由基础设施相同的前缀大小(仅限当前PI地址);

o EIDs are used only at the stub ASes, not in the transit ASes; and

o EID仅用于存根ASE,而不用于传输ASE;和

o the RLOCs of an EID prefix are deployed at the edge between the stubs owning the EID prefix and the providers, allocating the RLOCs in a PA mode.

o EID前缀的RLOC部署在拥有EID前缀的存根和提供者之间的边缘,以PA模式分配RLOC。

The above assumptions are inline with [RFC7215] and current LISP deployments. It is recognized these assumptions may change in the longer term. [KIF13] and [CDLC] explore different EID prefix space sizes and still show results that are consistent and equivalent to the above assumptions.


Quoitin et al. [QIdLB07] show that the separation between locator and identifier roles at the network level improves the routing scalability by reducing the Routing Information Base (RIB) size (up to one order of magnitude) and increases path diversity and thus the traffic engineering capabilities. [IB07] and [KIF13] show, based on real Internet traffic traces, that the number of mapping entries that must be handled by an ITR of a network with up to 20,000 users is limited to few tens of thousands; the signaling traffic (i.e., Map-Request/Map-Reply packets) is in the same order of magnitude similar to DNS request/reply traffic; and the encapsulation overhead, while not negligible, is very limited (in the order of few percentage points of the total traffic volume).


Previous studies consider the case of a timer-based cache eviction policy (i.e., mappings are deleted from the cache upon timeout), while [CDLC] has a more general approach based on the Least Recently Used (LRU) eviction policy, proposing an analytic model for the EID-


to-RLOC cache size when prefix-level traffic has a stationary generating process. The model shows that miss rate can be accurately predicted from the EID-to-RLOC cache size and a small set of easily measurable traffic parameters. The model was validated using four one-day-long packet traces collected at egress points of a campus network and an academic exchange point considering EID prefixes as being of the same size as BGP prefixes. Consequently, operators can provision the EID-to-RLOC cache of their ITRs according to the miss rate they want to achieve for their given traffic.


Results in [CDLC] indicate that for a given target miss ratio, the size of the cache depends only on the parameters of the popularity distribution; the size of the cache is independent of the number of users (the size of the LISP site) and the number of destinations (the size of the EID prefix space). Assuming that the popularity distribution remains constant, this means that as the number of users and the number of destinations grow, the cache size needed to obtain a given miss rate remains constant O(1).


LISP usually populates its EID-to-RLOC cache in a pull mode, which means that mappings are retrieved on demand by the ITR. The main advantage of this mode is that the EID-to-RLOC cache size only depends on the traffic characteristics at the ITR and is independent of the size of the provider domain. This benefit comes at the cost of some delay to transmit the packets that do not hit an entry in the cache (for which a mapping has to be learned). This delay is bound by the time necessary to retrieve the mapping from the mapping system. Moreover, similarly to a push model (e.g., BGP), the pull model induces signaling messages that correspond to the retrieval of mappings upon cache miss. The difference being that the signaling load only depends on the traffic at the ITR and is not triggered by external events such as in BGP. [CDLC] shows that the miss rate is a function of the EID-to-RLOC cache size and traffic generation process, and [CDLC], [SDIB08], and [SDIB08] show from traffic traces that, in practice, the cache miss rate, and thus the signaling rate, remain low.


4. Beyond Scaling the Internet Routing Architecture
4. 除了扩展Internet路由架构之外

LISP is more than just a scalability solution; it is also a tool to provide both incoming and outgoing traffic engineering [S11] [LISP-TE], it can be used as an IPv6 transition at the routing level, and it can be used for inter-domain multicast [RFC6831] [LISP-RE]. Also, LISP has been identified for use to support devices' Internet mobility [LISP-MN] and to support virtual machines' mobility in data centers and multi-tenant VPNs. These last two uses are not discussed further as they are out of the scope of the current LISP Working Group charter.


A key advantage of the LISP architecture is that it facilitates routing in environments where there is little to no correlation between network endpoints and topological location. In service-provider environments, this application is needed in a range of consumer use cases that require an inline anchor to deliver a service to subscribers. Inline anchors provide one of three types of capabilities:


o enable mobility of subscriber endpoints

o 启用订户端点的移动性

o enable chaining of middlebox functions and services

o 启用中间盒功能和服务的链接

o enable functions to be scaled out seamlessly

o 使功能能够无缝扩展

Without LISP, the approach commonly used by operators is to aggregate service anchors in custom-built boxes. This limits deployments as endpoints can only move on the same mobile gateway, functions can be chained only if traffic traverses the same wire or the same Deep Packet Inspection (DPI) box, and capacity can be scaled out only if traffic fans out to/from a specific load balancer.


With LISP, service providers are able to distribute, virtualize, and instantiate subscriber-service anchors anywhere in the network. Typical use cases for virtualized inline anchors and network functions include Distributed Mobility and Virtualized Evolved Packet Core (vEPC), Virtualized Customer Premise Equipment (vCPE), where functionality previously anchored at a customer premise is now dynamically allocated in the network, Virtualized SGi LAN, Virtual IP Multimedia Subsystems (IMSs), Virtual Session Border Controller (SBC), etc.

使用LISP,服务提供商可以在网络中的任何位置分发、虚拟化和实例化订户服务锚。虚拟化内联锚和网络功能的典型用例包括分布式移动和虚拟化演进包核心(vEPC)、虚拟化客户场所设备(vCPE),其中先前锚定在客户场所的功能现在在网络、虚拟化SGi LAN中动态分配,虚拟IP多媒体子系统(IMS)、虚拟会话边界控制器(SBC)等。

ConteXtream [ConteXtream] has been deploying map-assisted overlay networks since 2006, first with a proprietary solution, then evolving to standard LISP. The solution has been deployed in production in three tier-1 operators spanning hundreds of millions of subscribers. Map-assisted overlays had been primarily used to map subscriber flows to services resources dynamically based on profiles and conditions. Specifically, it has been used to map mobile subscribers to value-added/optimization services, broadband subscribers to telephony services, and fixed-mobile subscribers to Broadband Network Gateway (BNG) functions and Internet access services. The LISP map-assisted overlay architecture is used to optimally resolve subscriber to services, functions, instances, and IP overlay aggregation locations on a per-flow basis and just in time.

ConteXtream[ConteXtream]自2006年以来一直在部署地图辅助覆盖网络,首先使用专有解决方案,然后发展到标准LISP。该解决方案已在三家一级运营商的生产中部署,覆盖数亿用户。地图辅助覆盖主要用于根据配置文件和条件动态地将订户流映射到服务资源。具体而言,它已被用于将移动用户映射到增值/优化服务、宽带用户映射到电话服务、固定移动用户映射到宽带网络网关(BNG)功能和互联网接入服务。LISP map辅助覆盖体系结构用于在每个流的基础上及时优化解决订户到服务、功能、实例和IP覆盖聚合位置的问题。

4.1. Traffic Engineering
4.1. 交通工程

In the current (non-LISP) routing infrastructure, addresses used by stub networks are globally routable, and the routing system distributes the routes to reach these stubs. With LISP, the EID prefixes of a LISP site are not routable in the DFZ; mappings are needed in order to determine the list of LISP routers to contact to forward packets. This difference is significant for two reasons. First, packets are not forwarded to a site but to a specific router. Second, a site can control the entry points for its traffic by controlling its mappings.


For traffic engineering purposes, a mapping associates an EID prefix to a list of RLOCs. Each RLOC is annotated with a priority and a weight. When there are several RLOCs, the ITR selects the one with the highest priority and sends the encapsulated packet to this RLOC. If several RLOCs with the highest priority exist, then the traffic is balanced proportionally to their weight among such RLOCs. Traffic engineering in LISP thus allows the mapping owner to have a fine-grained control on the primary and backup path for its incoming and outgoing packet use. In addition, it can share the load among its links. An example of the use of such a feature is described by Saucez et al. [SDIB08], which shows how to use LISP to direct different types of traffic on different links having different capacity.


Traffic engineering in LISP goes one step further, as every Map-Request contains the source EID address of the packet that caused a cache miss and triggered the Map-Request. It is thus possible for a mapping owner to differentiate the answer (Map-Reply) it gives to Map-Requests based on the requester. This functionality is not available today with BGP because a domain cannot control exactly the routes that will be received by domains that are not in the direct neighborhood.


4.2. LISP for IPv6 Co-existence
4.2. IPv6共存的LISP

The LISP encapsulation mechanism is designed to support any combination of address families for locators and identifiers. It is then possible to bind IPv6 EIDs with IPv4 RLOCs and vice versa. This allows transporting IPv6 packets over an IPv4 network (or IPv4 packets over an IPv6 network), making LISP a valuable mechanism to ease the transition to IPv6.

LISP封装机制旨在支持定位器和标识符的地址族的任意组合。然后可以将IPv6 EID与IPv4 RLOC绑定,反之亦然。这允许通过IPv4网络传输IPv6数据包(或通过IPv6网络传输IPv4数据包),使LISP成为一种有价值的机制,可以简化向IPv6的过渡。

An example is the case of the network infrastructure of a data center being IPv4 only while dual-stack front-end load balancers are used. In this scenario, LISP can be used to provide IPv6 access to servers even though the network and the servers only support IPv4. Assuming


that the data center's ISP offers IPv6 connectivity, the data center only needs to deploy one (or more) xTR(s) at its border with the ISP and one (or more) xTR(s) directly connected to the load balancers. The xTR(s) at the ISP's border tunnels IPv6 packets over IPv4 to the xTR(s) directly attached to the load balancer. The load balancer's xTR de-encapsulates the packets and forwards them to the load balancer, which act as a proxy, translating each IPv6 packet into an IPv4 packet. IPv4 packets are then sent to the appropriate servers. Similarly, when the server's response arrives at the load balancer, the packet is translated back into an IPv6 packet and forwarded to its xTR(s), which in turn will tunnel it back, over the IPv4-only infrastructure, to an xTR connected to the ISP. The packet is then de-encapsulated and forwarded to the ISP natively in IPv6.


4.3. Inter-domain Multicast
4.3. 域间多播

LISP has native support for multicast [RFC6831]. From the data-plane perspective, at a multicast-enabled xTR, an EID-sourced multicast packet is encapsulated in another multicast packet and subsequently forwarded in an RLOC-level distribution tree. Therefore, xTRs must participate in both EID and RLOC-level distribution trees. Control-plane wise, since group addresses have no topological significance, they need not be mapped. It is worth noting that, to properly function, LISP-Multicast requires that inter-domain multicast be available.


LISP Replication Engineering (LISP-RE) [LISP-RE] [CDM12] leverages LISP messages [LISP-MULTI-SIGNALING] for multicast state distribution to construct xTR-based inter-domain multicast distribution trees when inter-domain multicast support is not available. Simulations of three different management strategies for low-latency content delivery show that such overlays can support thousands of member xTRs, support hundreds of thousands of end hosts, and deliver content at latencies close to unicast ones [CDM12]. It was also observed that high client churn has a limited impact on performance and management overhead.


Similar to LISP-RE, "Signal-Free LISP Multicast" [LISP-SFM] can be used when the core network does not provide multicast support. But instead of using signaling to build inter-domain multicast trees, signal-free exclusively leverages the map server for multicast state storage and distribution. As a result, the source ITR generally performs head-end replication, but it might also be used to emulate LISP-RE distribution trees.

与LISP-RE类似,当核心网络不提供多播支持时,可以使用“无信号LISP多播”[LISP-SFM]。但是,与使用信令构建域间多播树不同,signal free专门利用map服务器进行多播状态存储和分发。因此,源ITR通常执行前端复制,但也可用于模拟LISP-RE分发树。

5. Impact of LISP on Operations and Business Models
5. LISP对运营和商业模式的影响

Numerous implementation efforts ([IOSNXOS], [OpenLISP], [LISPmob], [LISPClick], [LISPcp], and [LISPfritz]) have been made to assess the specifications, and additionally, interoperability tests [Was09] have been successful. A worldwide large deployment in the international testbed, which is currently composed of nodes running at least three different implementations, will allow us to learn further operational aspects related to LISP.


The following sections distinguish the impact of LISP on LISP sites from the impact on non-LISP sites.


5.1. Impact on Non-LISP Traffic and Sites
5.1. 对非LISP流量和站点的影响

LISP has no impact on traffic that has neither LISP origin nor LISP destination. However, LISP can have a significant impact on traffic between a LISP site and a non-LISP site. Traffic between a non-LISP site and a LISP site is subject to the same issues as those observed for LISP-to-LISP traffic but also has issues specific to the transition mechanism that allow the LISP site to exchange packets with a non-LISP site [RFC6832] [RFC7215].


The transition requires setup of proxy tunnel routers (PxTRs). Proxies cause what is referred to as path stretch (i.e., a lengthening of the path compared to the topological shortest path) and make troubleshooting harder. There are still questions related to PxTRs that need to be answered:


o Where to deploy PxTRs? The placement in the topology has an important impact on the path stretch.

o 在哪里部署PXTR?拓扑中的放置对路径拉伸有重要影响。

o How many PxTRs? The number of PxTRs has a direct impact on the load and the impact of the failure of a PxTR on the traffic.

o 有多少个PXTR?PxTR的数量直接影响负载以及PxTR故障对流量的影响。

o What part of the EID space? Will all the PxTRs be proxies for the whole EID space, or will it be segmented between different PxTRs?

o EID空间的哪一部分?所有PXTR是整个EID空间的代理,还是在不同的PXTR之间进行分段?

o Who operates PxTRs? An important question to answer is related to the entities that will deploy PxTRs: how will they manage their additional Capital Expenditure (CAPEX) / Operating Expenses (OPEX) associated with PxTRs? How will the traffic be carried with respect to security and privacy?

o 谁操作PXTR?需要回答的一个重要问题与将部署PXTR的实体有关:它们将如何管理与PXTR相关的额外资本支出(CAPEX)/运营支出(OPEX)?在安全和隐私方面,交通将如何进行?

A PxTR will also normally advertise in BGP the EID prefix for which they are proxies. However, if proxies are managed by different entities, they will belong to different ASes. In this case, we need to be sure that this will not cause Multi-Origin AS (MOAS) issues


that could negatively influence routing. Moreover, it is important to ensure that the way EID prefixes will be de-aggregated by the proxies will remain reasonable so as not to contribute to BGP scalability issues.


5.2. Impact on LISP Traffic and Sites
5.2. 对LISP流量和站点的影响

LISP is a protocol based on the map-and-encap paradigm, which has the positive impacts that we have summarized in the above sections. However, LISP also has impacts on operations:


MTU issue: As LISP uses encapsulation, the MTU is reduced; this has implications on potentially all of the traffic. However, in practice, on the network, no major issue due to the MTU has been observed. This is probably due to the fact that current end-host stacks are well designed to deal with the problem of MTU.


Resiliency issue: The advantage of flexibility and control offered by the Locator/ID separation comes at the cost of increasing the complexity of the reachability detection. Indeed, identifiers are not directly routable and have to be mapped to locators, but a locator may be unreachable while others are still reachable. This is an important problem for any tunnel-based solution. In the current Internet, packets are forwarded independently of the border router of the network meaning that, in case of the failure of a border router, another one can be used. With LISP, the destination RLOC specifically designates one particular ETR; hence, if this ETR fails, the traffic is dropped, even though other ETRs are available for the destination site. Another resiliency issue is linked to the fact that mappings are learned on demand. When an ITR fails, all its traffic is redirected to other ITRs that might not have the mappings requested by the redirected traffic. Existing studies [SKI12] [SD12] show, based on measurements and traffic traces, that failure of ITRs and RLOC are infrequent but that when such failure happens, a critical number of packets can be dropped. Unfortunately, the current techniques for LISP resiliency, based on monitoring or probing, are not rapid enough (failure recovery on the order of a few seconds). To tackle this issue, [LISP-PRESERVE] and [LISP-ITR-GRACEFUL] propose techniques based on local failure detection and recovery.


Middleboxes/filters: Because of the increasingly common use of encryption as a response to pervasive monitoring [RFC7258] with LISP providing the option to encrypt traffic between xTRs [LISP-CRYPTO], middleboxes are increasingly likely to be unable to understand encapsulated traffic, which can cause them to drop legitimate packets. In addition, LISP allows triangular or even


rectangular routing, so it is difficult to maintain a correct state even if the middlebox understands LISP. Finally, filtering may also have problems because they may think only one host is generating the traffic (the ITR), as long as it is not de-encapsulated. To deal with LISP encapsulation, LISP-aware firewalls that inspect inner LISP packets are proposed [lispfirewall].


Troubleshooting/debugging: The major issue that LISP experimentation has shown is the difficulty of troubleshooting. When there is a problem in the network, it is hard to pinpoint the reason as the operator only has a partial view of the network. The operator can see what is in its EID-to-RLOC cache/database and can try to obtain what is potentially elsewhere by querying the Map Resolvers, but the knowledge remains partial. On top of that, ICMP packets only carry the first few tens of bytes of the original packet, which means that when an ICMP arrives at the ITR, it might not contain enough information to allow correct troubleshooting. Deployment in the beta network has shown that LISP+ALT [RFC6836] was not easy to maintain and control [CCR13], which explains the migration to LISP-DDT [LISP-DDT], based on a massively distributed and hierarchical approach [CCR13].


Business/operational related: Iannone et al. [IL10] have shown that there are economical incentives to migrate to LISP; however, some questions remain. For example, how will the EIDs be allocated to allow aggregation and hence scalability of the mapping system? Who will operate the mapping system infrastructure and for what benefits? What if several operators run different mapping systems? How will they interoperate or share mapping information?


Reachability: The overhead related to RLOC reachability mechanisms is not known.


6. Security Considerations
6. 安全考虑

A thorough security and threat analysis of LISP is carried out in detail in [RFC7835]. For LISP and other Internet technologies, most of the threats can be mitigated using Best Current Practices, meaning with careful deployment and configuration (e.g., filter), by activating only features that are really necessary in the deployment, and by verifying all the information obtained from third parties. Unless gleaning (Section 6 of [RFC6830] and Section 3.1 of [RFC7835]) features are used, the LISP data plane shows the same level of security as other IP-over-IP technologies. From a security perspective, the control plane remains the critical part of the LISP architecture. To mitigate the threats on the mapping system, authentication should be used for all control-plane messages. The

[RFC7835]对LISP进行了全面的安全和威胁分析。对于LISP和其他互联网技术,大多数威胁都可以使用当前最佳实践来缓解,这意味着通过谨慎的部署和配置(如过滤器),只激活部署中真正需要的功能,并验证从第三方获得的所有信息。除非使用了收集(RFC6830第6节和RFC7835第3.1节)功能,否则LISP数据平面显示的安全级别与其他IP over IP技术相同。从安全角度来看,控制平面仍然是LISP体系结构的关键部分。为了减轻映射系统上的威胁,应对所有控制平面消息使用身份验证。这个

current specification defines security mechanisms [RFC6836] [LISP-SEC] that can reduce threats in open network environments. The LISP specification defines a generic authentication data field for control-plane messages [RFC6836], which could be used for a general authentication mechanism for the LISP control plane while staying backward compatible.


7. References
7. 工具书类
7.1. Normative References
7.1. 规范性引用文件

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

[RFC6830]Farinaci,D.,Fuller,V.,Meyer,D.,和D.Lewis,“定位器/身份分离协议(LISP)”,RFC 6830,DOI 10.17487/RFC6830,2013年1月<>.

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

[RFC6831]Farinaci,D.,Meyer,D.,Zwiebel,J.,和S.Venaas,“用于多播环境的定位器/ID分离协议(LISP)”,RFC 6831,DOI 10.17487/RFC6831,2013年1月<>.

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

[RFC6832]Lewis,D.,Meyer,D.,Farinaci,D.,和V.Fuller,“定位器/ID分离协议(LISP)和非LISP站点之间的互通”,RFC 6832,DOI 10.17487/RFC6832,2013年1月<>.

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

[RFC6833]Fuller,V.和D.Farinaci,“定位器/ID分离协议(LISP)地图服务器接口”,RFC 6833,DOI 10.17487/RFC6833,2013年1月<>.

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

[RFC6834]Iannone,L.,Saucez,D.,和O.Bonaventure,“定位器/ID分离协议(LISP)地图版本控制”,RFC 6834,DOI 10.17487/RFC6834,2013年1月<>.

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

[RFC6836]Fuller,V.,Farinaci,D.,Meyer,D.,和D.Lewis,“定位器/ID分离协议替代逻辑拓扑(LISP+ALT)”,RFC 6836,DOI 10.17487/RFC6836,2013年1月<>.

[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-Pascual, J., and D. Lewis, "Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations", RFC 7215, DOI 10.17487/RFC7215, April 2014, <>.

[RFC7215]Jakab,L.,Cabellos Aparicio,A.,Coras,F.,Domingo Pascual,J.,和D.Lewis,“定位器/标识符分离协议(LISP)网元部署注意事项”,RFC 7215,DOI 10.17487/RFC7215,2014年4月<>.

[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Threat Analysis", RFC 7835, DOI 10.17487/RFC7835, April 2016, <>.

[RFC7835]Saucez,D.,Iannone,L.,和O.Bonaventure,“定位器/身份分离协议(LISP)威胁分析”,RFC 7835,DOI 10.17487/RFC7835,2016年4月<>.

7.2. Informative References
7.2. 资料性引用

[CCR13] Saucez, D., Iannone, L., and B. Donnet, "A First Measurement Look at the Deployment and Evolution of the Locator/ID Separation Protocol", ACM SIGCOMM Computer Communication Review, Vol. 43, Issue 2, pp. 37-43, DOI 10.1145/2479957.2479963, April 2013.

[CCR13]Saucez,D.,Iannone,L.,和B.Donnet,“定位器/ID分离协议部署和演变的第一次测量研究”,ACM SIGCOMM计算机通信评论,第43卷,第2期,第37-43页,DOI 10.1145/2479957.2479963,2013年4月。

[CDLC] Coras, F., Domingo, J., Lewis, D., and A. Cabellos, "An Analytical Model for Loc/ID Mappings Caches", IEEE/ACM Transactions on Networking, Vol. 24, Issue 1, pp. 506-516, DOI 10.1109/TNET.2014.2373398, February 2014.

[CDLC]Coras,F.,Domingo,J.,Lewis,D.,和A.Cabellos,“Loc/ID映射缓存的分析模型”,IEEE/ACM网络交易,第24卷,第1期,第506-516页,DOI 10.1109/TNET.2014.2373398,2014年2月。

[CDM12] Coras, F., Domingo-Pascual, J., Maino, F., Farinacci, D., and A. Cabellos-Aparicio, "Lcast: Software-defined Inter-Domain Multicast", Computer Networks, Vol. 59, pp. 153-170, DOI 10.1016/j.bjp.2013.10.010, February 2014.

[CDM12]Coras,F.,Domingo Pascual,J.,Maino,F.,Farinaci,D.,和A.Cabellos Aparicio,“Lcast:软件定义的域间多播”,计算机网络,第59卷,第153-170页,DOI 10.1016/J.bjp.2013.10.010,2014年2月。

[ConteXtream] ConteXtream Software Company, , "SDN and NFV solutions for carrier networks. (Further details on LISP only through private inquiry.)", <>.


[IB07] Iannone, L. and O. Bonaventure, "On the cost of caching locator/ID mappings", in Proceedings of ACM CoNEXT 2007, DOI 0.1145/1364654.1364663, December 2007.

[IB07]Ianone,L.和O.Bonaventure,“缓存定位器/ID映射的成本”,载于ACM CoNEXT 2007年会议记录,DOI 0.1145/1364654.13646632007年12月。

[IL10] Iannone, L. and T. Leva, "Modeling the economics of Loc/ID Split for the Future Internet", IOS Press, pp. 11-20, DOI 10.3233/978-1-60750-539-6-11, May 2010.

[IL10]Iannone,L.和T.Leva,“为未来互联网建模Loc/ID拆分的经济性”,IOS出版社,第11-20页,DOI 10.3233/978-1-60750-539-6-11,2010年5月。

[IOSNXOS] Cisco Systems Inc., "Locator/ID Separation Protocol (LISP)", 2015, <>.


[KIF13] Kim, J., Iannone, L., and A. Feldmann, "Caching Locator/ID mappings: An experimental scalability analysis and its implications", Computer Networks, Vol. 57, Issue 4, DOI 10.1016/j.comnet.2012.11.007, March 2013.

[KIF13]Kim,J.,Iannone,L.,和A.Feldmann,“缓存定位器/ID映射:实验性可伸缩性分析及其影响”,计算机网络,第57卷,第4期,DOI 10.1016/J.comnet.2012.11.007,2013年3月。

[LISP-CRYPTO] Farinacci, D. and B. Weis, "LISP Data-Plane Confidentiality", Work in Progress, draft-ietf-lisp-crypto-03, September 2015.


[LISP-DDT] Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Delegated Database Tree", Work in Progress, draft-ietf-lisp-ddt-03, April 2015.


[LISP-ITR-GRACEFUL] Saucez, D., Bonaventure, O., Iannone, L., and C. Filsfils, "LISP ITR Graceful Restart", Work in Progress, draft-saucez-lisp-itr-graceful-03, December 2013.


[LISP-LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", Work in Progress, draft-ietf-lisp-lcaf-12, September 2015.


[LISP-MN] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Mobile Node", Work in Progress, draft-meyer-lisp-mn-14, July 2015.


[LISP-MULTI-SIGNALING] Farinacci, D. and M. Napierala, "LISP Control-Plane Multicast Signaling", Work in Progress, draft-farinacci-lisp-mr-signaling-06, February 2015.


[LISP-PRESERVE] Bonaventure, O., Francois, P., and D. Saucez, "Preserving the reachability of LISP ETRs in case of failures", Work in Progress, draft-bonaventure-lisp-preserve-00, July 2009.

[LISP-PRESERVE]Bonaventure,O.,Francois,P.,和D.Saucez,“在发生故障时保持LISP ETR的可达性”,正在进行的工作,草稿-Bonaventure-LISP-PRESERVE-00,2009年7月。

[LISP-RE] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Maino, F., and D. Farinacci, "LISP Replication Engineering", Work in Progress, draft-coras-lisp-re-08, November 2015.

[LISP-RE]Coras,F.,Cabellos Aparicio,A.,Domingo Pascual,J.,Maino,F.,和D.Farinaci,“LISP复制工程”,在建工程,草稿-Coras-LISP-RE-082015年11月。

[LISP-SEC] Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Saucez, "LISP-Security (LISP-SEC)", Work in Progress, draft-ietf-lisp-sec-10, October 2015.

[LISP-SEC]Maino,F.,Ermagan,V.,Cabellos Aparicio,A.,和D.Saucez,“LISP安全(LISP-SEC)”,正在进行的工作,草案-ietf-LISP-SEC-10,2015年10月。

[LISP-SFM] Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", Work in Progress, draft-ietf-lisp-signal-free-multicast-01, April 2016.


[LISP-TE] Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic Engineering Use-Cases", Work in Progress, draft-farinacci-lisp-te-10, September 2015.


[LISPClick] Saucez, D. and V. Nguyen, "LISP-Click: A Click implementation of the Locator/ID Separation Protocol", 1st Symposium on Click Modular Router, November 2009, <>.

[LISPClick]Saucez,D.和V.Nguyen,“LISP Click:Locator/ID分离协议的Click实现”,第一届Click模块化路由器研讨会,2009年11月<>.

[LISPcp] "LIP6-LISP open source project", 2014, <>.


[lispfirewall] "LISP and Zone-Based Firewalls Integration and Interoperability", 2014, < sec_data_zbf/configuration/xe-3s/sec-data-zbf-xe-book/ sec-zbf-lisp-inner-pac-insp.html>.

[lispfirewall]“LISP和基于区域的防火墙集成和互操作性”,2014年< sec_data_zbf/configuration/xe-3s/sec data zbf xe book/sec zbf lisp internal pac insp.html>。

[LISPfritz] "Unsere FRITZ!Box-Produkte", 2014, <>.


[LISPmob] "An open-source LISP implementation for Linux, Android and OpenWRT", 2015, <>.


[OpenLISP] "The OpenLISP Project", 2013, <>.


[QIdLB07] Quoitin, B., Iannone, L., de Launois, C., and O. Bonaventure, "Evaluating the Benefits of the Locator/ Identifier Separation", in Proceedings of MobiArch, Article No. 5, DOI 10.1145/1366919.1366926, August 2007.

[QIdLB07]Quoitin,B.,Iannone,L.,de Launois,C.,和O.Bonaventure,“评估定位器/标识符分离的好处”,MobiArch会议记录,第5条,DOI 10.1145/1366919.1366926,2007年8月。

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

[RFC4984]Meyer,D.,Ed.,Zhang,L.,Ed.,和K.Fall,Ed.,“来自IAB路由和寻址研讨会的报告”,RFC 4984,DOI 10.17487/RFC49842007年9月<>.

[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <>.

[RFC7258]Farrell,S.和H.Tschofenig,“普遍监控是一种攻击”,BCP 188,RFC 7258,DOI 10.17487/RFC7258,2014年5月<>.

[S11] Saucez, D., "Mechanisms for Interdomain Traffic Engineering with LISP", PhD Thesis, Universite catholique de Louvain, September 2011, <>.


[SD12] Saucez, D. and B. Donnet, "On the Dynamics of Locators in LISP", in Proceedings of IFIP/TC6 Networking, pp. 385-396, DOI 10.1007/978-3-642-30045-5_29, May 2012.

[SD12]Saucez,D.和B.Donnet,“关于LISP中定位器的动态”,载于IFIP/TC6网络会议录,第385-396页,DOI 10.1007/978-3-642-30045-529,2012年5月。

[SDIB08] Saucez, D., Donnet, B., Iannone, L., and O. Bonaventure, "Interdomain Traffic Engineering in a Locator/Identifier Separation Context", in Proceedings of Internet Network Management Workshop, DOI 10.1109/INETMW.2008.4660330, October 2008.

[SDIB08]Saucez,D.,Donnet,B.,Iannone,L.,和O.Bonaventure,“定位符/标识符分离上下文中的域间流量工程”,互联网网络管理研讨会论文集,DOI 10.1109/INETMW.2008.46603302008年10月。

[SKI12] Saucez, D., Kim, J., Iannone, L., Bonaventure, O., and C. Filsfils, "A Local Approach to Fast Failure Recovery of LISP Ingress Tunnel Routers", in Proceedings of IFIP Networking 2012, pp. 397-408, DOI 10.1007/978-3-642-30045-5_30, May 2012.

[SKI12]Saucez,D.,Kim,J.,Iannone,L.,Bonaventure,O.,和C.Filsfils,“LISP入口隧道路由器快速故障恢复的本地方法”,载于IFIP Networking 2012,第397-408页,DOI 10.1007/978-3-642-30045-5_30,2012年5月。

[Was09] Wasserman, M., "LISP Interoperability Testing", IETF 76, LISP WG Presentation, November 2009.

[Was09]Wasserman,M.,“LISP互操作性测试”,IETF 76,LISP工作组演示,2009年11月。



Thanks to Deborah Brungard, Ben Campbell, Spencer Dawkins, Stephen Farrel, Wassim Haddad, Kathleen Moriarty, and Hilarie Orman for their thorough reviews, comments, and suggestions.

感谢Deborah Brungard、Ben Campbell、Spencer Dawkins、Stephen Farrel、Wassim Haddad、Kathleen Moriarty和Hilarie Orman的全面审查、评论和建议。

The people that contributed to this document are Alia Atlas, Sharon Barkai, Ron Bonica, Ross Callon, Vince Fuller, Joel Halpern, Terry Manderson, and Gregg Schudel.

对本文件作出贡献的人有Alia Atlas、Sharon Barkai、Ron Bonica、Ross Callon、Vince Fuller、Joel Halpern、Terry Manderson和Gregg Schudel。

The work of Luigi Iannone has been partially supported by the ANR 13 INFR 0009 LISP-Lab Project <>.

Luigi Iannone的工作得到了ANR 13 INFR 0009 LISP实验室项目的部分支持<>.

Authors' Addresses


Damien Saucez INRIA 2004 route des Lucioles BP 93 06902 Sophia Antipolis Cedex France

Damien Saucez INRIA 2004 Lucioles路线BP 93 06902 Sophia Antipolis Cedex法国


Luigi Iannone Telecom ParisTech 23, Avenue d'Italie, CS 51327 75214 Paris Cedex 13 France

路易吉·伊安诺电信巴黎公司,意大利大道23号,CS 51327 75214巴黎Cedex 13法国


Albert Cabellos Technical University of Catalonia C/Jordi Girona, s/n 08034 Barcelona Spain

加泰罗尼亚艾伯特CabelLOS技术大学C /霍尔迪赫罗纳,S/N 08034西班牙巴塞罗那


Florin Coras Technical University of Catalonia C/Jordi Girona, s/n 08034 Barcelona Spain

加泰罗尼亚佛罗林科拉斯技术大学C/霍尔迪赫罗纳,S/N 08034西班牙巴塞罗那