Internet Engineering Task Force (IETF) D. Farinacci
Request for Comments: 6830 Cisco Systems
Category: Experimental V. Fuller
ISSN: 2070-1721
D. Meyer
D. Lewis
Cisco Systems
January 2013
Internet Engineering Task Force (IETF) D. Farinacci
Request for Comments: 6830 Cisco Systems
Category: Experimental V. Fuller
ISSN: 2070-1721
D. Meyer
D. Lewis
Cisco Systems
January 2013
The Locator/ID Separation Protocol (LISP)
定位器/ID分离协议（LISP）
Abstract
摘要
This document describes a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. The Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a "flag day", and offers Traffic Engineering, multihoming, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites.
本文档描述了一种基于网络层的协议，该协议允许将IP地址分离为两个新的编号空间：端点标识符（EID）和路由定位器（RLOC）。不需要对主机协议栈或Internet基础设施的“核心”进行任何更改。定位器/ID分离协议（LISP）可以增量部署，无需“国旗日”，并为早期采用者提供流量工程、多归属和移动性优势，即使支持LISP的站点相对较少。
Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop.
LISP的设计和开发主要受2006年10月IAB路由和寻址研讨会产生的问题陈述的推动。
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.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（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 http://www.rfc-editor.org/info/rfc6830.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6830.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Requirements Notation ...........................................5
3. Definition of Terms .............................................5
4. Basic Overview .................................................10
4.1. Packet Flow Sequence ......................................13
5. LISP Encapsulation Details .....................................15
5.1. LISP IPv4-in-IPv4 Header Format ...........................16
5.2. LISP IPv6-in-IPv6 Header Format ...........................17
5.3. Tunnel Header Field Descriptions ..........................18
5.4. Dealing with Large Encapsulated Packets ...................22
5.4.1. A Stateless Solution to MTU Handling ...............22
5.4.2. A Stateful Solution to MTU Handling ................23
5.5. Using Virtualization and Segmentation with LISP ...........24
6. EID-to-RLOC Mapping ............................................25
6.1. LISP IPv4 and IPv6 Control-Plane Packet Formats ...........25
6.1.1. LISP Packet Type Allocations .......................27
6.1.2. Map-Request Message Format .........................27
6.1.3. EID-to-RLOC UDP Map-Request Message ................30
6.1.4. Map-Reply Message Format ...........................31
6.1.5. EID-to-RLOC UDP Map-Reply Message ..................35
6.1.6. Map-Register Message Format ........................37
6.1.7. Map-Notify Message Format ..........................39
6.1.8. Encapsulated Control Message Format ................41
6.2. Routing Locator Selection .................................42
6.3. Routing Locator Reachability ..............................44
6.3.1. Echo Nonce Algorithm ...............................46
6.3.2. RLOC-Probing Algorithm .............................48
6.4. EID Reachability within a LISP Site .......................49
6.5. Routing Locator Hashing ...................................49
1. Introduction ....................................................3
2. Requirements Notation ...........................................5
3. Definition of Terms .............................................5
4. Basic Overview .................................................10
4.1. Packet Flow Sequence ......................................13
5. LISP Encapsulation Details .....................................15
5.1. LISP IPv4-in-IPv4 Header Format ...........................16
5.2. LISP IPv6-in-IPv6 Header Format ...........................17
5.3. Tunnel Header Field Descriptions ..........................18
5.4. Dealing with Large Encapsulated Packets ...................22
5.4.1. A Stateless Solution to MTU Handling ...............22
5.4.2. A Stateful Solution to MTU Handling ................23
5.5. Using Virtualization and Segmentation with LISP ...........24
6. EID-to-RLOC Mapping ............................................25
6.1. LISP IPv4 and IPv6 Control-Plane Packet Formats ...........25
6.1.1. LISP Packet Type Allocations .......................27
6.1.2. Map-Request Message Format .........................27
6.1.3. EID-to-RLOC UDP Map-Request Message ................30
6.1.4. Map-Reply Message Format ...........................31
6.1.5. EID-to-RLOC UDP Map-Reply Message ..................35
6.1.6. Map-Register Message Format ........................37
6.1.7. Map-Notify Message Format ..........................39
6.1.8. Encapsulated Control Message Format ................41
6.2. Routing Locator Selection .................................42
6.3. Routing Locator Reachability ..............................44
6.3.1. Echo Nonce Algorithm ...............................46
6.3.2. RLOC-Probing Algorithm .............................48
6.4. EID Reachability within a LISP Site .......................49
6.5. Routing Locator Hashing ...................................49
6.6. Changing the Contents of EID-to-RLOC Mappings .............50
6.6.1. Clock Sweep ........................................51
6.6.2. Solicit-Map-Request (SMR) ..........................52
6.6.3. Database Map-Versioning ............................53
7. Router Performance Considerations ..............................54
8. Deployment Scenarios ...........................................55
8.1. First-Hop/Last-Hop Tunnel Routers .........................56
8.2. Border/Edge Tunnel Routers ................................56
8.3. ISP Provider Edge (PE) Tunnel Routers .....................57
8.4. LISP Functionality with Conventional NATs .................58
8.5. Packets Egressing a LISP Site .............................58
9. Traceroute Considerations ......................................58
9.1. IPv6 Traceroute ...........................................59
9.2. IPv4 Traceroute ...........................................60
9.3. Traceroute Using Mixed Locators ...........................60
10. Mobility Considerations .......................................61
10.1. Site Mobility ............................................61
10.2. Slow Endpoint Mobility ...................................61
10.3. Fast Endpoint Mobility ...................................61
10.4. Fast Network Mobility ....................................63
10.5. LISP Mobile Node Mobility ................................64
11. Multicast Considerations ......................................64
12. Security Considerations .......................................65
13. Network Management Considerations .............................67
14. IANA Considerations ...........................................67
14.1. LISP ACT and Flag Fields .................................67
14.2. LISP Address Type Codes ..................................68
14.3. LISP UDP Port Numbers ....................................68
14.4. LISP Key ID Numbers ......................................68
15. Known Open Issues and Areas of Future Work ....................68
16. References ....................................................70
16.1. Normative References .....................................70
16.2. Informative References ...................................71
Appendix A. Acknowledgments .......................................74
6.6. Changing the Contents of EID-to-RLOC Mappings .............50
6.6.1. Clock Sweep ........................................51
6.6.2. Solicit-Map-Request (SMR) ..........................52
6.6.3. Database Map-Versioning ............................53
7. Router Performance Considerations ..............................54
8. Deployment Scenarios ...........................................55
8.1. First-Hop/Last-Hop Tunnel Routers .........................56
8.2. Border/Edge Tunnel Routers ................................56
8.3. ISP Provider Edge (PE) Tunnel Routers .....................57
8.4. LISP Functionality with Conventional NATs .................58
8.5. Packets Egressing a LISP Site .............................58
9. Traceroute Considerations ......................................58
9.1. IPv6 Traceroute ...........................................59
9.2. IPv4 Traceroute ...........................................60
9.3. Traceroute Using Mixed Locators ...........................60
10. Mobility Considerations .......................................61
10.1. Site Mobility ............................................61
10.2. Slow Endpoint Mobility ...................................61
10.3. Fast Endpoint Mobility ...................................61
10.4. Fast Network Mobility ....................................63
10.5. LISP Mobile Node Mobility ................................64
11. Multicast Considerations ......................................64
12. Security Considerations .......................................65
13. Network Management Considerations .............................67
14. IANA Considerations ...........................................67
14.1. LISP ACT and Flag Fields .................................67
14.2. LISP Address Type Codes ..................................68
14.3. LISP UDP Port Numbers ....................................68
14.4. LISP Key ID Numbers ......................................68
15. Known Open Issues and Areas of Future Work ....................68
16. References ....................................................70
16.1. Normative References .....................................70
16.2. Informative References ...................................71
Appendix A. Acknowledgments .......................................74
This document describes the Locator/Identifier Separation Protocol (LISP), which provides a set of functions for routers to exchange information used to map from Endpoint Identifiers (EIDs) that are not globally routable to routable Routing Locators (RLOCs). It also defines a mechanism for these LISP routers to encapsulate IP packets addressed with EIDs for transmission across a network infrastructure that uses RLOCs for routing and forwarding.
本文档描述了定位器/标识符分离协议（LISP），该协议为路由器提供了一组功能，用于交换用于从不可全局路由的端点标识符（EID）映射到可路由的路由定位器（RLOC）的信息。它还为这些LISP路由器定义了一种机制，用于封装用EID寻址的IP数据包，以便在使用RLOC进行路由和转发的网络基础设施上进行传输。
Creation of LISP was initially motivated by discussions during the IAB-sponsored Routing and Addressing Workshop held in Amsterdam in October 2006 (see [RFC4984]). A key conclusion of the workshop was that the Internet routing and addressing system was not scaling well in the face of the explosive growth of new sites; one reason for this poor scaling is the increasing number of multihomed sites and other sites that cannot be addressed as part of topology-based or provider-based aggregated prefixes. Additional work that more completely describes the problem statement may be found in [RADIR].
LISP的创建最初是由IAB于2006年10月在阿姆斯特丹举办的路由和寻址研讨会（见[RFC4984]）期间的讨论推动的。研讨会的一个重要结论是，面对新网站的爆炸性增长，互联网路由和寻址系统的扩展性不好；这种扩展性差的一个原因是，越来越多的多址站点和其他站点无法作为基于拓扑或基于提供程序的聚合前缀的一部分进行处理。更完整地描述问题陈述的其他工作可在[RADIR]中找到。
A basic observation, made many years ago in early networking research such as that documented in [CHIAPPA] and [RFC4984], is that using a single address field for both identifying a device and for determining where it is topologically located in the network requires optimization along two conflicting axes: for routing to be efficient, the address must be assigned topologically; for collections of devices to be easily and effectively managed, without the need for renumbering in response to topological change (such as that caused by adding or removing attachment points to the network or by mobility events), the address must explicitly not be tied to the topology.
多年前在早期网络研究（如[Chiapa]和[RFC4984]中记录的研究）中进行的一项基本观察表明，使用单个地址字段来识别设备和确定其在网络中的拓扑位置需要沿两个冲突轴进行优化：为了使路由有效，地址必须按拓扑分配；为了方便有效地管理设备集合，而无需响应拓扑更改（例如，由于向网络添加或删除连接点或移动事件而导致的更改），地址不得明确绑定到拓扑。
The approach that LISP takes to solving the routing scalability problem is to replace IP addresses with two new types of numbers: Routing Locators (RLOCs), which are topologically assigned to network attachment points (and are therefore amenable to aggregation) and used for routing and forwarding of packets through the network; and Endpoint Identifiers (EIDs), which are assigned independently from the network topology, are used for numbering devices, and are aggregated along administrative boundaries. LISP then defines functions for mapping between the two numbering spaces and for encapsulating traffic originated by devices using non-routable EIDs for transport across a network infrastructure that routes and forwards using RLOCs. Both RLOCs and EIDs are syntactically identical to IP addresses; it is the semantics of how they are used that differs.
LISP解决路由可伸缩性问题的方法是将IP地址替换为两种新类型的数字：路由定位器（RLOC），它们在拓扑上分配给网络连接点（因此易于聚合），用于通过网络路由和转发数据包；端点标识符（EID）独立于网络拓扑分配，用于设备编号，并沿管理边界聚合。然后，LISP定义了两个编号空间之间的映射函数，以及封装由使用不可路由EID的设备发起的通信量的函数，以便通过使用RLOCs进行路由和转发的网络基础设施进行传输。RLOC和EID在语法上与IP地址相同；不同之处在于它们如何使用的语义。
This document describes the protocol that implements these functions. The database that stores the mappings between EIDs and RLOCs is explicitly a separate "module" to facilitate experimentation with a variety of approaches. One database design that is being developed for experimentation as part of the LISP working group work is [RFC6836]. Others that have been described include [CONS], [EMACS], and [RFC6837]. Finally, [RFC6833] documents a general-purpose service interface for accessing a mapping database; this interface is intended to make the mapping database modular so that different approaches can be tried without the need to modify installed LISP-capable devices in LISP sites.
本文档描述了实现这些功能的协议。存储EID和RLOCs之间映射的数据库是一个单独的“模块”，用于促进各种方法的实验。作为LISP工作组工作的一部分，正在为实验开发的一个数据库设计是[RFC6836]。已描述的其他内容包括[CONS]、[EMACS]和[RFC6837]。最后，[RFC6833]记录了用于访问映射数据库的通用服务接口；此接口旨在使映射数据库模块化，以便可以尝试不同的方法，而无需修改LISP站点中已安装的支持LISP的设备。
This experimental specification has areas that require additional experience and measurement. It is NOT RECOMMENDED for deployment beyond experimental situations. Results of experimentation may lead to modifications and enhancements of protocol mechanisms defined in this document. See Section 15 for specific, known issues that are in need of further work during development, implementation, and experimentation.
本实验性规范包含需要额外经验和测量的领域。不建议将其部署到实验环境之外。实验结果可能会导致本文档中定义的协议机制的修改和增强。请参阅第15节，了解在开发、实施和实验期间需要进一步工作的特定已知问题。
An examination of the implications of LISP on Internet traffic, applications, routers, and security is for future study. This analysis will explain what role LISP can play in scalable routing and will also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on.
LISP对互联网流量、应用程序、路由器和安全性的影响有待于进一步研究。此分析将解释LISP在可伸缩路由中可以扮演什么角色，还将研究封装、去封装、活动性等所需的可伸缩性和状态级别。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Provider-Independent (PI) Addresses: PI addresses are an address block assigned from a pool where blocks are not associated with any particular location in the network (e.g., from a particular service provider) and are therefore not topologically aggregatable in the routing system.
独立于提供商（PI）地址：PI地址是从池中分配的地址块，其中块与网络中的任何特定位置（例如，来自特定服务提供商）不关联，因此在路由系统中不可拓扑聚合。
Provider-Assigned (PA) Addresses: PA addresses are an address block assigned to a site by each service provider to which a site connects. Typically, each block is a sub-block of a service provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and is aggregated into the larger block before being advertised into the global Internet. Traditionally, IP multihoming has been implemented by each multihomed site acquiring its own globally visible prefix. LISP uses only topologically assigned and aggregatable address blocks for RLOCs, eliminating this demonstrably non-scalable practice.
提供商分配（PA）地址：PA地址是站点所连接的每个服务提供商分配给站点的地址块。通常，每个块都是服务提供商无类域间路由（CIDR）[RFC4632]块的子块，在发布到全球互联网之前聚合到更大的块中。传统上，IP多址是由每个多址站点获取自己的全局可见前缀来实现的。LISP仅为RLOC使用拓扑分配和可聚合的地址块，消除了这种明显不可扩展的做法。
Routing Locator (RLOC): An RLOC is an IPv4 [RFC0791] or IPv6 [RFC2460] address of an Egress Tunnel Router (ETR). An RLOC is the output of an EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site.
路由定位器（RLOC）：RLOC是出口隧道路由器（ETR）的IPv4[RFC0791]或IPv6[RFC2460]地址。RLOC是EID到RLOC映射查找的输出。EID映射到一个或多个RLOC。通常，RLOC从拓扑上可聚合的块中进行编号，这些块被分配到其连接到全球互联网的每个点处的站点；如果拓扑由提供商网络的连接性定义，则可以将RLOC视为PA地址。可以将多个RLOC分配给同一ETR设备或一个站点的多个ETR设备。
Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains a destination address today, for example, through a Domain Name System (DNS) [RFC1034] lookup or Session Initiation Protocol (SIP) [RFC3261] exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID used on the public Internet must have the same properties as any other IP address used in that manner; this means, among other things, that it must be globally unique. An EID is allocated to a host from an EID-Prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks MAY be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site may have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system. In theory, the bit string that represents an EID for one device can represent an RLOC for a different device. As the architecture is realized, if a given bit string is both an RLOC and an EID, it must refer to the same entity in both cases. When used in discussions with other Locator/ID separation proposals, a LISP EID will be called an "LEID". Throughout this document, any references to "EID" refer to an LEID.
端点ID（EID）：EID是一个32位（对于IPv4）或128位（对于IPv6）的值，用于数据包的第一个（最内部）LISP头的源和目标地址字段。主机获取目的地EID的方式与今天获取目的地地址的方式相同，例如，通过域名系统（DNS）[RFC1034]查找或会话启动协议（SIP）[RFC3261]交换。源EID通过用于设置主机“本地”IP地址的现有机制获得。在公共互联网上使用的EID必须与以这种方式使用的任何其他IP地址具有相同的属性；这意味着，除其他外，它必须是全球唯一的。EID从与主机所在站点关联的EID前缀块分配给主机。主机可以使用EID引用其他主机。EID不得用作LISP RLOC。注意，EID块可以独立于网络拓扑以分层方式分配，以便于映射数据库的缩放。此外，分配给站点的EID块可以具有用于在站点内路由的站点本地结构（子网）；此结构对全局路由系统不可见。理论上，表示一个设备的EID的位字符串可以表示另一个设备的RLOC。随着体系结构的实现，如果给定的位字符串既是RLOC又是EID，那么在这两种情况下它必须引用同一个实体。当与其他定位器/ID分离方案讨论时，LISP EID将被称为“LEID”。在本文件中，对“EID”的任何引用均指LEID。
EID-Prefix: An EID-Prefix is a power-of-two block of EIDs that are allocated to a site by an address allocation authority. EID-Prefixes are associated with a set of RLOC addresses that make up a "database mapping". EID-Prefix allocations can be broken up into smaller blocks when an RLOC set is to be associated with the larger EID-Prefix block. A globally routed address block (whether PI or PA) is not inherently an EID-Prefix. A globally routed address block MAY be used by its assignee as an EID block. The converse is not supported. That is, a site that receives an explicitly allocated EID-Prefix may not use that EID-Prefix as a globally routed prefix. This would require coordination and cooperation with the entities managing the mapping infrastructure. Once this has been done, that block could be removed from the globally routed IP system, if other suitable transition and access mechanisms are in place. Discussion of such transition and access mechanisms can be found in [RFC6832] and [LISP-DEPLOY].
EID前缀：EID前缀是地址分配机构分配给站点的两个EID块的幂。EID前缀与组成“数据库映射”的一组RLOC地址相关联。当RLOC集合要与较大的EID前缀块关联时，EID前缀分配可以分解为较小的块。全局路由地址块（无论是PI还是PA）本质上不是EID前缀。全局路由地址块可由其受让人用作EID块。反之则不受支持。也就是说，接收显式分配的EID前缀的站点可能不会将该EID前缀用作全局路由前缀。这将需要与管理测绘基础设施的实体进行协调与合作。一旦完成此操作，如果其他合适的转换和访问机制到位，则可以从全局路由IP系统中删除该块。[RFC6832]和[LISP-DEPLOY]中对此类转换和访问机制进行了讨论。
End-system: An end-system is an IPv4 or IPv6 device that originates packets with a single IPv4 or IPv6 header. The end-system supplies an EID value for the destination address field of the IP header when communicating globally (i.e., outside of its routing domain). An end-system can be a host computer, a switch or router device, or any network appliance.
终端系统：终端系统是一个IPv4或IPv6设备，它使用单个IPv4或IPv6报头发起数据包。当进行全局通信（即，在其路由域之外）时，终端系统为IP报头的目标地址字段提供EID值。终端系统可以是主机、交换机或路由器设备或任何网络设备。
Ingress Tunnel Router (ITR): An ITR is a router that resides in a LISP site. Packets sent by sources inside of the LISP site to destinations outside of the site are candidates for encapsulation by the ITR. The ITR treats the IP destination address as an EID and performs an EID-to-RLOC mapping lookup. The router then prepends an "outer" IP header with one of its globally routable RLOCs in the source address field and the result of the mapping lookup in the destination address field. Note that this destination RLOC MAY be an intermediate, proxy device that has better knowledge of the EID-to-RLOC mapping closer to the destination EID. In general, an ITR receives IP packets from site end-systems on one side and sends LISP-encapsulated IP packets toward the Internet on the other side.
入口隧道路由器（ITR）：ITR是驻留在LISP站点中的路由器。LISP站点内部的源发送到站点外部的目的地的数据包是ITR封装的候选数据包。ITR将IP目标地址视为EID，并执行EID到RLOC的映射查找。然后，路由器在“源地址”字段中为“外部”IP报头添加一个全局可路由RLOC，并在“目标地址”字段中添加映射查找的结果。注意，该目的地RLOC可以是一个中间代理设备，它对更接近目的地EID的EID到RLOC映射有更好的了解。通常，ITR在一端接收来自站点端系统的IP数据包，在另一端向Internet发送LISP封装的IP数据包。
Specifically, when a service provider prepends a LISP header for Traffic Engineering purposes, the router that does this is also regarded as an ITR. The outer RLOC the ISP ITR uses can be based on the outer destination address (the originating ITR's supplied RLOC) or the inner destination address (the originating host's supplied EID).
具体而言，当服务提供商出于流量工程目的预先准备LISP报头时，执行此操作的路由器也被视为ITR。ISP ITR使用的外部RLOC可以基于外部目标地址（发起ITR提供的RLOC）或内部目标地址（发起主机提供的EID）。
TE-ITR: A TE-ITR is an ITR that is deployed in a service provider network that prepends an additional LISP header for Traffic Engineering purposes.
TE-ITR:TE-ITR是部署在服务提供商网络中的一种ITR，它为流量工程目的预先准备了一个额外的LISP头。
Egress Tunnel Router (ETR): An ETR is a router that accepts an IP packet where the destination address in the "outer" IP header is one of its own RLOCs. The router strips the "outer" header and forwards the packet based on the next IP header found. In general, an ETR receives LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the other side. ETR functionality does not have to be limited to a router device. A server host can be the endpoint of a LISP tunnel as well.
出口隧道路由器（ETR）：ETR是接受IP数据包的路由器，其中“外部”IP报头中的目标地址是其自己的RLOC之一。路由器剥离“外部”报头，并根据找到的下一个IP报头转发数据包。通常，ETR在一侧从Internet接收LISP封装的IP数据包，并将解封装的IP数据包发送到另一侧的站点端系统。ETR功能不必局限于路由器设备。服务器主机也可以是LISP隧道的端点。
TE-ETR: A TE-ETR is an ETR that is deployed in a service provider network that strips an outer LISP header for Traffic Engineering purposes.
TE-ETR:TE-ETR是部署在服务提供商网络中的ETR，该网络为流量工程目的剥离外部LISP标头。
xTR: An xTR is a reference to an ITR or ETR when direction of data flow is not part of the context description. "xTR" refers to the router that is the tunnel endpoint and is used synonymously with the term "Tunnel Router". For example, "An xTR can be located at the Customer Edge (CE) router" indicates both ITR and ETR functionality at the CE router.
xTR：当数据流的方向不是上下文描述的一部分时，xTR是对ITR或ETR的引用。“xTR”是指作为隧道端点的路由器，与术语“隧道路由器”同义。例如，“xTR可位于客户边缘（CE）路由器”表示CE路由器的ITR和ETR功能。
LISP Router: A LISP router is a router that performs the functions of any or all of the following: ITR, ETR, Proxy-ITR (PITR), or Proxy-ETR (PETR).
LISP路由器：LISP路由器是执行以下任何或所有功能的路由器：ITR、ETR、代理ITR（PITR）或代理ETR（PETR）。
EID-to-RLOC Cache: The EID-to-RLOC Cache is a short-lived, on-demand table in an ITR that stores, tracks, and is responsible for timing out and otherwise validating EID-to-RLOC mappings. This cache is distinct from the full "database" of EID-to-RLOC mappings; it is dynamic, local to the ITR(s), and relatively small, while the database is distributed, relatively static, and much more global in scope.
EID到RLOC缓存：EID到RLOC缓存是ITR中的一个短期按需表，用于存储、跟踪EID到RLOC的映射，并负责超时和验证EID到RLOC的映射。该缓存不同于EID到RLOC映射的完整“数据库”；它是动态的，在ITR中是局部的，并且相对较小，而数据库是分布式的，相对静态的，并且范围更大。
EID-to-RLOC Database: The EID-to-RLOC Database is a global distributed database that contains all known EID-Prefix-to-RLOC mappings. Each potential ETR typically contains a small piece of the database: the EID-to-RLOC mappings for the EID-Prefixes "behind" the router. These map to one of the router's own globally visible IP addresses. The same database mapping entries MUST be configured on all ETRs for a given site. In a steady state, the EID-Prefixes for the site and the Locator-Set for each EID-Prefix MUST be the same on all ETRs. Procedures to enforce and/or verify this are outside the scope of this document. Note that there MAY be transient conditions when the EID-Prefix for the site and Locator-Set for each EID-Prefix may not be the same on all ETRs. This has no negative implications, since a partial set of Locators can be used.
EID到RLOC数据库：EID到RLOC数据库是一个全局分布式数据库，包含所有已知EID前缀到RLOC的映射。每个潜在的ETR通常包含数据库的一小部分：路由器后面的EID前缀的EID到RLOC映射。这些映射到路由器自己的全局可见IP地址之一。必须在给定站点的所有ETR上配置相同的数据库映射条目。在稳定状态下，站点的EID前缀和为每个EID前缀设置的定位器在所有ETR上必须相同。强制执行和/或验证的程序不在本文件的范围内。请注意，当站点的EID前缀和为每个EID前缀设置的定位器在所有ETR上可能不相同时，可能存在暂时情况。这没有负面影响，因为可以使用部分定位器集。
Recursive Tunneling: Recursive Tunneling occurs when a packet has more than one LISP IP header. Additional layers of tunneling MAY be employed to implement Traffic Engineering or other re-routing as needed. When this is done, an additional "outer" LISP header is added, and the original RLOCs are preserved in the "inner" header. Any references to tunnels in this specification refer to dynamic encapsulating tunnels; they are never statically configured.
递归隧道：当数据包具有多个LISP IP头时，会发生递归隧道。根据需要，可采用额外的隧道层来实施交通工程或其他重新布线。完成此操作后，将添加一个附加的“外部”LISP标头，并且原始RLOC将保留在“内部”标头中。本规范中提及的隧道均指动态封装隧道；它们从来都不是静态配置的。
Re-encapsulating Tunnels: Re-encapsulating Tunneling occurs when an ETR removes a LISP header, then acts as an ITR to prepend another LISP header. Doing this allows a packet to be re-routed by the re-encapsulating router without adding the overhead of additional tunnel headers. Any references to tunnels in this specification
重新封装隧道：当ETR删除一个LISP头，然后充当一个ITR来预写另一个LISP头时，就会发生重新封装隧道。这样做允许重新封装的路由器重新路由数据包，而不增加额外隧道头的开销。本规范中对隧道的任何引用
refer to dynamic encapsulating tunnels; they are never statically configured. When using multiple mapping database systems, care must be taken to not create re-encapsulation loops through misconfiguration.
指动态封装隧道；它们从来都不是静态配置的。使用多个映射数据库系统时，必须注意不要通过错误配置创建重新封装循环。
LISP Header: LISP header is a term used in this document to refer to the outer IPv4 or IPv6 header, a UDP header, and a LISP-specific 8-octet header that follow the UDP header and that an ITR prepends or an ETR strips.
LISP标头：LISP标头是本文档中使用的一个术语，用于指外部IPv4或IPv6标头、UDP标头以及UDP标头之后的特定于LISP的8-octet标头，以及ITR前缀或ETR条带。
Address Family Identifier (AFI): AFI is a term used to describe an address encoding in a packet. An address family currently pertains to an IPv4 or IPv6 address. See [AFI] and [RFC3232] for details. An AFI value of 0 used in this specification indicates an unspecified encoded address where the length of the address is 0 octets following the 16-bit AFI value of 0.
地址族标识符（AFI）：AFI是一个术语，用于描述数据包中的地址编码。地址族当前属于IPv4或IPv6地址。详见[AFI]和[RFC3232]。本规范中使用的AFI值0表示未指定的编码地址，其中地址长度为16位AFI值0后的0个八位字节。
Negative Mapping Entry: A negative mapping entry, also known as a negative cache entry, is an EID-to-RLOC entry where an EID-Prefix is advertised or stored with no RLOCs. That is, the Locator-Set for the EID-to-RLOC entry is empty or has an encoded Locator count of 0. This type of entry could be used to describe a prefix from a non-LISP site, which is explicitly not in the mapping database. There are a set of well-defined actions that are encoded in a Negative Map-Reply (Section 6.1.5).
负映射项：负映射项（也称为负缓存项）是EID到RLOC项，其中EID前缀在没有RLOC的情况下播发或存储。也就是说，为EID to RLOC条目设置的定位器为空或编码定位器计数为0。这种类型的条目可用于描述非LISP站点的前缀，该站点明确不在映射数据库中。有一组定义明确的动作，编码在否定Map回复中（第6.1.5节）。
Data-Probe: A Data-Probe is a LISP-encapsulated data packet where the inner-header destination address equals the outer-header destination address used to trigger a Map-Reply by a decapsulating ETR. In addition, the original packet is decapsulated and delivered to the destination host if the destination EID is in the EID-Prefix range configured on the ETR. Otherwise, the packet is discarded. A Data-Probe is used in some of the mapping database designs to "probe" or request a Map-Reply from an ETR; in other cases, Map-Requests are used. See each mapping database design for details. When using Data-Probes, by sending Map-Requests on the underlying routing system, EID-Prefixes must be advertised. However, this is discouraged if the core is to scale by having less EID-Prefixes stored in the core router's routing tables.
数据探测：数据探测是LISP封装的数据包，其中内部报头目标地址等于外部报头目标地址，用于触发解封装ETR的映射回复。此外，如果目标EID在ETR上配置的EID前缀范围内，则原始数据包被解除封装并传送到目标主机。否则，数据包将被丢弃。在某些映射数据库设计中，使用数据探针“探测”或从ETR请求映射回复；在其他情况下，使用映射请求。有关详细信息，请参见每个映射数据库设计。使用数据探测时，通过在基础路由系统上发送映射请求，必须公布EID前缀。但是，如果核心路由器的路由表中存储的EID前缀较少，则不鼓励这样做。
Proxy-ITR (PITR): A PITR is defined and described in [RFC6832]. A PITR acts like an ITR but does so on behalf of non-LISP sites that send packets to destinations at LISP sites.
代理ITR（PITR）：PITR的定义和描述见[RFC6832]。PITR的作用类似于ITR，但它代表向LISP站点的目的地发送数据包的非LISP站点。
Proxy-ETR (PETR): A PETR is defined and described in [RFC6832]. A PETR acts like an ETR but does so on behalf of LISP sites that send packets to destinations at non-LISP sites.
代理ETR（PETR）：在[RFC6832]中定义和描述了一个PETR。PETR的作用类似于ETR，但它代表向非LISP站点的目的地发送数据包的LISP站点。
Route-returnability: Route-returnability is an assumption that the underlying routing system will deliver packets to the destination. When combined with a nonce that is provided by a sender and returned by a receiver, this limits off-path data insertion. A route-returnability check is verified when a message is sent with a nonce, another message is returned with the same nonce, and the destination of the original message appears as the source of the returned message.
路由可返回性：路由可返回性是一种假设，即底层路由系统将向目的地发送数据包。当与发送方提供并由接收方返回的nonce组合时，这将限制非路径数据插入。当使用nonce发送消息，使用相同的nonce返回另一条消息，并且原始消息的目的地显示为返回消息的源时，将验证路由可返回性检查。
LISP site: LISP site is a set of routers in an edge network that are under a single technical administration. LISP routers that reside in the edge network are the demarcation points to separate the edge network from the core network.
LISP站点：LISP站点是边缘网络中的一组路由器，由单一技术管理。驻留在边缘网络中的LISP路由器是将边缘网络与核心网络分开的分界点。
Client-side: Client-side is a term used in this document to indicate a connection initiation attempt by an EID. The ITR(s) at the LISP site are the first to get involved in obtaining database Map-Cache entries by sending Map-Request messages.
客户端：客户端是本文档中使用的一个术语，用于指示EID发起连接的尝试。LISP站点上的ITR是第一个通过发送映射请求消息来获取数据库映射缓存项的人。
Server-side: Server-side is a term used in this document to indicate that a connection initiation attempt is being accepted for a destination EID. The ETR(s) at the destination LISP site are the first to send Map-Replies to the source site initiating the connection. The ETR(s) at this destination site can obtain mappings by gleaning information from Map-Requests, Data-Probes, or encapsulated packets.
服务器端：服务器端是本文档中使用的一个术语，用于表示正在接受目标EID的连接启动尝试。目标LISP站点上的ETR是第一个向发起连接的源站点发送映射回复的站点。此目标站点的ETR可以通过从映射请求、数据探测或封装的数据包中收集信息来获取映射。
Locator-Status-Bits (LSBs): Locator-Status-Bits are present in the LISP header. They are used by ITRs to inform ETRs about the up/ down status of all ETRs at the local site. These bits are used as a hint to convey up/down router status and not path reachability status. The LSBs can be verified by use of one of the Locator reachability algorithms described in Section 6.3.
定位器状态位（LSB）：定位器状态位存在于LISP标头中。ITRs使用它们通知ETRs本地站点所有ETR的上/下状态。这些位被用作向上/向下传送路由器状态而不是路径可达性状态的提示。LSB可通过使用第6.3节中描述的定位器可达性算法之一进行验证。
Anycast Address: Anycast Address is a term used in this document to refer to the same IPv4 or IPv6 address configured and used on multiple systems at the same time. An EID or RLOC can be an anycast address in each of their own address spaces.
选播地址：选播地址是本文档中使用的一个术语，指在多个系统上同时配置和使用的相同IPv4或IPv6地址。EID或RLOC可以是各自地址空间中的选播地址。
One key concept of LISP is that end-systems (hosts) operate the same way they do today. The IP addresses that hosts use for tracking sockets and connections, and for sending and receiving packets, do not change. In LISP terminology, these IP addresses are called Endpoint Identifiers (EIDs).
LISP的一个关键概念是，终端系统（主机）的运行方式与今天相同。主机用于跟踪套接字和连接以及发送和接收数据包的IP地址不变。在LISP术语中，这些IP地址称为端点标识符（EID）。
Routers continue to forward packets based on IP destination addresses. When a packet is LISP encapsulated, these addresses are referred to as Routing Locators (RLOCs). Most routers along a path between two hosts will not change; they continue to perform routing/ forwarding lookups on the destination addresses. For routers between the source host and the ITR as well as routers from the ETR to the destination host, the destination address is an EID. For the routers between the ITR and the ETR, the destination address is an RLOC.
路由器继续根据IP目标地址转发数据包。当一个包被LISP封装时，这些地址被称为路由定位器（RLOC）。沿着两台主机之间的路径的大多数路由器不会改变；它们继续对目标地址执行路由/转发查找。对于源主机和ITR之间的路由器以及从ETR到目标主机的路由器，目标地址是EID。对于ITR和ETR之间的路由器，目标地址是RLOC。
Another key LISP concept is the "Tunnel Router". A Tunnel Router prepends LISP headers on host-originated packets and strips them prior to final delivery to their destination. The IP addresses in this "outer header" are RLOCs. During end-to-end packet exchange between two Internet hosts, an ITR prepends a new LISP header to each packet, and an ETR strips the new header. The ITR performs EID-to-RLOC lookups to determine the routing path to the ETR, which has the RLOC as one of its IP addresses.
另一个关键的LISP概念是“隧道路由器”。隧道路由器在源于主机的数据包上预先设置LISP头，并在最终传送到目的地之前将其剥离。此“外部标头”中的IP地址是RLOC。在两台Internet主机之间的端到端数据包交换过程中，ITR会为每个数据包预先添加一个新的LISP头，ETR会剥离新的头。ITR执行EID到RLOC的查找，以确定到ETR的路由路径，ETR将RLOC作为其IP地址之一。
Some basic rules governing LISP are:
管理LISP的一些基本规则包括：
o End-systems (hosts) only send to addresses that are EIDs. They don't know that addresses are EIDs versus RLOCs but assume that packets get to their intended destinations. In a system where LISP is deployed, LISP routers intercept EID-addressed packets and assist in delivering them across the network core where EIDs cannot be routed. The procedure a host uses to send IP packets does not change.
o 终端系统（主机）仅发送到EID地址。他们不知道地址是EID还是RLOC，但假设数据包到达了它们的预期目的地。在部署LISP的系统中，LISP路由器拦截EID寻址的数据包，并协助在EID无法路由的网络核心上传送这些数据包。主机用于发送IP数据包的过程不会更改。
o EIDs are always IP addresses assigned to hosts.
o EID始终是分配给主机的IP地址。
o LISP routers mostly deal with Routing Locator addresses. See details in Section 4.1 to clarify what is meant by "mostly".
o LISP路由器主要处理路由定位器地址。详见第4.1节，以澄清“大部分”的含义。
o RLOCs are always IP addresses assigned to routers, preferably topologically oriented addresses from provider CIDR (Classless Inter-Domain Routing) blocks.
o RLOC始终是分配给路由器的IP地址，最好是来自提供者CIDR（无类域间路由）块的面向拓扑的地址。
o When a router originates packets, it may use as a source address either an EID or RLOC. When acting as a host (e.g., when terminating a transport session such as Secure SHell (SSH), TELNET, or the Simple Network Management Protocol (SNMP)), it may use an EID that is explicitly assigned for that purpose. An EID that identifies the router as a host MUST NOT be used as an RLOC; an EID is only routable within the scope of a site. A typical BGP configuration might demonstrate this "hybrid" EID/RLOC usage where a router could use its "host-like" EID to terminate iBGP sessions to other routers in a site while at the same time using RLOCs to terminate eBGP sessions to routers outside the site.
o 当路由器发起数据包时，它可以使用EID或RLOC作为源地址。当充当主机时（例如，当终止传输会话时，如Secure SHell（SSH）、TELNET或简单网络管理协议（SNMP）），它可能会使用为此目的明确分配的EID。将路由器标识为主机的EID不得用作RLOC；EID只能在站点范围内路由。典型的BGP配置可能会演示这种“混合”EID/RLOC用法，其中路由器可以使用其“类似主机”的EID终止与站点中其他路由器的iBGP会话，同时使用RLOC终止与站点外路由器的eBGP会话。
o Packets with EIDs in them are not expected to be delivered end-to-end in the absence of an EID-to-RLOC mapping operation. They are expected to be used locally for intra-site communication or to be encapsulated for inter-site communication.
o 在没有EID到RLOC映射操作的情况下，不希望包含EID的数据包被端到端地传递。它们预计将在本地用于站点内通信，或封装用于站点间通信。
o EID-Prefixes are likely to be hierarchically assigned in a manner that is optimized for administrative convenience and to facilitate scaling of the EID-to-RLOC mapping database. The hierarchy is based on an address allocation hierarchy that is independent of the network topology.
o EID前缀可能以一种优化的方式进行分层分配，以方便管理，并促进EID到RLOC映射数据库的扩展。该层次结构基于独立于网络拓扑的地址分配层次结构。
o EIDs may also be structured (subnetted) in a manner suitable for local routing within an Autonomous System (AS).
o EID也可以以适合于自治系统（AS）内的本地路由的方式被构造（子网化）。
An additional LISP header MAY be prepended to packets by a TE-ITR when re-routing of the path for a packet is desired. A potential use-case for this would be an ISP router that needs to perform Traffic Engineering for packets flowing through its network. In such a situation, termed "Recursive Tunneling", an ISP transit acts as an additional ITR, and the RLOC it uses for the new prepended header would be either a TE-ETR within the ISP (along an intra-ISP traffic engineered path) or a TE-ETR within another ISP (an inter-ISP traffic engineered path, where an agreement to build such a path exists).
当需要对分组的路径进行重新路由时，TE-ITR可以在分组之前附加LISP报头。一个潜在的使用案例是ISP路由器，它需要对流经其网络的数据包执行流量工程。在这种被称为“递归隧道”的情况下，ISP传输充当附加的ITR，并且它用于新的前置报头的RLOC将是ISP内的TE-ETR（沿ISP内流量工程路径）或另一ISP内的TE-ETR（ISP间流量工程路径，其中存在建立此类路径的协议）。
In order to avoid excessive packet overhead as well as possible encapsulation loops, this document mandates that a maximum of two LISP headers can be prepended to a packet. For initial LISP deployments, it is assumed that two headers is sufficient, where the first prepended header is used at a site for Location/Identity separation and the second prepended header is used inside a service provider for Traffic Engineering purposes.
为了避免过多的数据包开销以及可能的封装循环，本文档要求一个数据包最多可以预加两个LISP头。对于初始LISP部署，假设两个标头就足够了，其中第一个前置标头用于站点位置/身份分离，第二个前置标头用于服务提供商内部的流量工程目的。
Tunnel Routers can be placed fairly flexibly in a multi-AS topology. For example, the ITR for a particular end-to-end packet exchange might be the first-hop or default router within a site for the source host. Similarly, the ETR might be the last-hop router directly connected to the destination host. Another example, perhaps for a VPN service outsourced to an ISP by a site, the ITR could be the site's border router at the service provider attachment point. Mixing and matching of site-operated, ISP-operated, and other Tunnel Routers is allowed for maximum flexibility. See Section 8 for more details.
隧道路由器可以相当灵活地放置在多AS拓扑中。例如，特定端到端分组交换的ITR可能是源主机站点内的第一跳或默认路由器。类似地，ETR可能是直接连接到目标主机的最后一跳路由器。另一个例子是，对于由站点外包给ISP的VPN服务，ITR可能是该站点在服务提供商连接点的边界路由器。现场操作、ISP操作和其他隧道路由器的混合和匹配允许实现最大的灵活性。详见第8节。
This section provides an example of the unicast packet flow with the following conditions:
本节提供具有以下条件的单播分组流的示例：
o Source host "host1.abc.example.com" is sending a packet to "host2.xyz.example.com", exactly what host1 would do if the site was not using LISP.
o 源主机“host1.abc.example.com”正在向“host2.xyz.example.com”发送一个数据包，这正是如果站点未使用LISP，host1将执行的操作。
o Each site is multihomed, so each Tunnel Router has an address (RLOC) assigned from the service provider address block for each provider to which that particular Tunnel Router is attached.
o 每个站点都是多址的，因此每个隧道路由器都有一个地址（RLOC），该地址是从服务提供商地址块为该特定隧道路由器所连接的每个提供商分配的。
o The ITR(s) and ETR(s) are directly connected to the source and destination, respectively, but the source and destination can be located anywhere in the LISP site.
o ITR和ETR分别直接连接到源和目标，但源和目标可以位于LISP站点中的任何位置。
o Map-Requests can be sent on the underlying routing system topology, to a mapping database system, or directly over an Alternative Logical Topology [RFC6836]. A Map-Request is sent for an external destination when the destination is not found in the forwarding table or matches a default route.
o 映射请求可以在基础路由系统拓扑上发送到映射数据库系统，或者直接通过替代逻辑拓扑发送[RFC6836]。当在转发表中找不到外部目的地或与默认路由匹配时，会发送外部目的地的映射请求。
o Map-Replies are sent on the underlying routing system topology.
o 映射答复在基础路由系统拓扑上发送。
Client host1.abc.example.com wants to communicate with server host2.xyz.example.com:
客户端host1.abc.example.com希望与服务器host2.xyz.example.com通信：
1. host1.abc.example.com wants to open a TCP connection to host2.xyz.example.com. It does a DNS lookup on host2.xyz.example.com. An A/AAAA record is returned. This address is the destination EID. The locally assigned address of host1.abc.example.com is used as the source EID. An IPv4 or IPv6 packet is built and forwarded through the LISP site as a normal IP packet until it reaches a LISP ITR.
1. host1.abc.example.com想要打开到host2.xyz.example.com的TCP连接。它在host2.xyz.example.com上执行DNS查找。返回A/AAAA记录。此地址是目标EID。本地分配的host1.abc.example.com地址用作源EID。IPv4或IPv6数据包作为普通IP数据包构建并通过LISP站点转发，直到到达LISP ITR。
2. The LISP ITR must be able to map the destination EID to an RLOC of one of the ETRs at the destination site. The specific method used to do this is not described in this example. See [RFC6836] or [CONS] for possible solutions.
2. LISP ITR必须能够将目标EID映射到目标站点上一个ETR的RLOC。此示例中未描述用于执行此操作的特定方法。有关可能的解决方案，请参见[RFC6836]或[CONS]。
3. The ITR will send a LISP Map-Request. Map-Requests SHOULD be rate-limited.
3. ITR将发送LISP映射请求。Map请求应具有速率限制。
4. When an alternate mapping system is not in use, the Map-Request packet is routed through the underlying routing system. Otherwise, the Map-Request packet is routed on an alternate logical topology, for example, the [RFC6836] database mapping system. In either case, when the Map-Request arrives at one of the ETRs at the destination site, it will process the packet as a control message.
4. 当备用映射系统未使用时，映射请求数据包通过底层路由系统进行路由。否则，映射请求数据包将在备用逻辑拓扑上路由，例如，[RFC6836]数据库映射系统。在任何一种情况下，当Map请求到达目标站点的一个ETR时，它都会将数据包作为控制消息进行处理。
5. The ETR looks at the destination EID of the Map-Request and matches it against the prefixes in the ETR's configured EID-to-RLOC mapping database. This is the list of EID-Prefixes the ETR is supporting for the site it resides in. If there is no match, the Map-Request is dropped. Otherwise, a LISP Map-Reply is returned to the ITR.
5. ETR查看映射请求的目标EID，并将其与ETR配置的EID到RLOC映射数据库中的前缀进行匹配。这是ETR所在站点支持的EID前缀列表。如果没有匹配项，则删除映射请求。否则，将向ITR返回LISP映射回复。
6. The ITR receives the Map-Reply message, parses the message (to check for format validity), and stores the mapping information from the packet. This information is stored in the ITR's EID-to-RLOC mapping cache. Note that the map-cache is an on-demand cache. An ITR will manage its map-cache in such a way that optimizes for its resource constraints.
6. ITR接收Map应答消息，解析消息（检查格式有效性），并存储来自数据包的映射信息。此信息存储在ITR的EID到RLOC映射缓存中。请注意，映射缓存是按需缓存。ITR将以优化其资源约束的方式管理其地图缓存。
7. Subsequent packets from host1.abc.example.com to host2.xyz.example.com will have a LISP header prepended by the ITR using the appropriate RLOC as the LISP header destination address learned from the ETR. Note that the packet MAY be sent to a different ETR than the one that returned the Map-Reply due to the source site's hashing policy or the destination site's Locator-Set policy.
7. 从host1.abc.example.com到host2.xyz.example.com的后续数据包将具有一个LISP头，由ITR使用适当的RLOC作为从ETR学习到的LISP头目标地址预先设置。注意，由于源站点的哈希策略或目标站点的定位器集策略，数据包可能被发送到不同于返回映射回复的ETR。
8. The ETR receives these packets directly (since the destination address is one of its assigned IP addresses), checks the validity of the addresses, strips the LISP header, and forwards packets to the attached destination host.
8. ETR直接接收这些数据包（因为目标地址是其分配的IP地址之一），检查地址的有效性，剥离LISP标头，并将数据包转发到连接的目标主机。
In order to defer the need for a mapping lookup in the reverse direction, an ETR MAY create a cache entry that maps the source EID (inner-header source IP address) to the source RLOC (outer-header source IP address) in a received LISP packet. Such a cache entry is termed a "gleaned" mapping and only contains a single RLOC for the EID in question. More complete information about additional RLOCs SHOULD be verified by sending a LISP Map-Request for that EID. Both the ITR and the ETR may also influence the decision the other makes in selecting an RLOC. See Section 6 for more details.
为了推迟反向映射查找的需要，ETR可以创建一个缓存条目，将接收到的LISP数据包中的源EID（内部报头源IP地址）映射到源RLOC（外部报头源IP地址）。这样的缓存项被称为“收集”映射，只包含一个用于所讨论的EID的RLOC。应通过发送该EID的LISP映射请求来验证有关其他RLOC的更完整信息。ITR和ETR也可能影响其他人选择RLOC的决策。详见第6节。
Since additional tunnel headers are prepended, the packet becomes larger and can exceed the MTU of any link traversed from the ITR to the ETR. It is RECOMMENDED in IPv4 that packets do not get fragmented as they are encapsulated by the ITR. Instead, the packet is dropped and an ICMP Too Big message is returned to the source.
由于预先附加了隧道头，数据包会变大，并且可能超过从ITR到ETR的任何链路的MTU。在IPv4中，建议不要将数据包分段，因为它们由ITR封装。相反，数据包被丢弃，ICMP过大消息返回到源。
This specification RECOMMENDS that implementations provide support for one of the proposed fragmentation and reassembly schemes. Two existing schemes are detailed in Section 5.4.
本规范建议实现为其中一个提议的碎片和重组方案提供支持。第5.4节详细介绍了两个现有方案。
Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner header is in IPv4 packet format and the outer header is in IPv6 packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header is in IPv6 packet format and the outer header is in IPv4 packet format). The next sub-sections illustrate packet formats for the homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4 combinations MUST be supported.
由于IPv4或IPv6地址可以是EID或RLOCs，LISP体系结构支持带有IPv6 RLOCs的IPv4 EID（其中内部报头为IPv4数据包格式，外部报头为IPv6数据包格式）或带有IPv4 RLOCs的IPv6 EID（其中内部报头为IPv6数据包格式，外部报头为IPv4数据包格式）。下一小节说明了同构情况下的数据包格式（IPv4-in-IPv4和IPv6-in-IPv6），但必须支持所有4种组合。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| IHL |Type of Service| Total Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identification |Flags| Fragment Offset |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OH | Time to Live | Protocol = 17 | Header Checksum |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source Routing Locator |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Destination Routing Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4341 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L |N|L|E|V|I|flags| Nonce/Map-Version |
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | Instance ID/Locator-Status-Bits |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| IHL |Type of Service| Total Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identification |Flags| Fragment Offset |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IH | Time to Live | Protocol | Header Checksum |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source EID |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Destination EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| IHL |Type of Service| Total Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identification |Flags| Fragment Offset |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OH | Time to Live | Protocol = 17 | Header Checksum |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source Routing Locator |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Destination Routing Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4341 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L |N|L|E|V|I|flags| Nonce/Map-Version |
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | Instance ID/Locator-Status-Bits |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| IHL |Type of Service| Total Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identification |Flags| Fragment Offset |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IH | Time to Live | Protocol | Header Checksum |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source EID |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Destination EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IHL = IP-Header-Length
IHL = IP-Header-Length
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| Traffic Class | Flow Label |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Payload Length | Next Header=17| Hop Limit |
v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
O + +
u | |
t + Source Routing Locator +
e | |
r + +
| |
H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
d | |
r + +
| |
^ + Destination Routing Locator +
| | |
\ + +
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4341 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L |N|L|E|V|I|flags| Nonce/Map-Version |
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | Instance ID/Locator-Status-Bits |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| Traffic Class | Flow Label |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Payload Length | Next Header | Hop Limit |
v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| Traffic Class | Flow Label |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Payload Length | Next Header=17| Hop Limit |
v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
O + +
u | |
t + Source Routing Locator +
e | |
r + +
| |
H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
d | |
r + +
| |
^ + Destination Routing Locator +
| | |
\ + +
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4341 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L |N|L|E|V|I|flags| Nonce/Map-Version |
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | Instance ID/Locator-Status-Bits |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| Traffic Class | Flow Label |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Payload Length | Next Header | Hop Limit |
v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
I + +
n | |
n + Source EID +
e | |
r + +
| |
H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
d | |
r + +
| |
^ + Destination EID +
\ | |
\ + +
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
I + +
n | |
n + Source EID +
e | |
r + +
| |
H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
d | |
r + +
| |
^ + Destination EID +
\ | |
\ + +
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inner Header (IH): The inner header is the header on the datagram received from the originating host. The source and destination IP addresses are EIDs [RFC0791] [RFC2460].
内部报头（IH）：内部报头是从发起主机接收的数据报上的报头。源和目标IP地址为EIDs[RFC0791][RFC2460]。
Outer Header: (OH) The outer header is a new header prepended by an ITR. The address fields contain RLOCs obtained from the ingress router's EID-to-RLOC Cache. The IP protocol number is "UDP (17)" from [RFC0768]. The setting of the Don't Fragment (DF) bit 'Flags' field is according to rules listed in Sections 5.4.1 and 5.4.2.
外部收割台：（哦）外部收割台是由ITR预先设置的新收割台。地址字段包含从入口路由器的EID到RLOC缓存获得的RLOC。IP协议编号为[RFC0768]中的“UDP（17）”。不分段（DF）位“标志”字段的设置符合第5.4.1节和第5.4.2节中列出的规则。
UDP Header: The UDP header contains an ITR selected source port when encapsulating a packet. See Section 6.5 for details on the hash algorithm used to select a source port based on the 5-tuple of the inner header. The destination port MUST be set to the well-known IANA-assigned port value 4341.
UDP报头：封装数据包时，UDP报头包含ITR选择的源端口。有关用于基于内部头的5元组选择源端口的哈希算法的详细信息，请参见第6.5节。目标端口必须设置为众所周知的IANA分配端口值4341。
UDP Checksum: The 'UDP Checksum' field SHOULD be transmitted as zero by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS] [UDP-ZERO]. When a packet with a zero UDP checksum is received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be silently dropped. If the ETR chooses not to perform the verification, or performs the verification successfully, the packet MUST be accepted for decapsulation. The handling of UDP
UDP校验和：对于IPv4[RFC0768]或IPv6封装[UDP-TUNNELS][UDP-zero]，ITR应将“UDP校验和”字段传输为零。当ETR接收到UDP校验和为零的数据包时，ETR必须接受该数据包进行解除封装。当ITR传输UDP校验和的非零值时，它必须在此字段中发送正确计算的值。当ETR接收到具有非零UDP校验和的数据包时，它可以选择验证校验和值。如果它选择执行这种验证，并且验证失败，则必须悄悄地丢弃数据包。如果ETR选择不执行验证，或成功执行验证，则必须接受数据包进行去封装。UDP协议的处理
checksums for all tunneling protocols, including LISP, is under active discussion within the IETF. When that discussion concludes, any necessary changes will be made to align LISP with the outcome of the broader discussion.
IETF内部正在积极讨论所有隧道协议（包括LISP）的校验和。讨论结束后，将进行任何必要的更改，使LISP与更广泛讨论的结果保持一致。
UDP Length: The 'UDP Length' field is set for an IPv4-encapsulated packet to be the sum of the inner-header IPv4 Total Length plus the UDP and LISP header lengths. For an IPv6-encapsulated packet, the 'UDP Length' field is the sum of the inner-header IPv6 Payload Length, the size of the IPv6 header (40 octets), and the size of the UDP and LISP headers.
UDP长度：IPv4封装数据包的“UDP长度”字段设置为内部报头IPv4总长度加上UDP和LISP报头长度之和。对于IPv6封装的数据包，“UDP长度”字段是内部报头IPv6有效负载长度、IPv6报头大小（40个八位字节）以及UDP和LISP报头大小的总和。
N: The N-bit is the nonce-present bit. When this bit is set to 1, the low-order 24 bits of the first 32 bits of the LISP header contain a Nonce. See Section 6.3.1 for details. Both N- and V-bits MUST NOT be set in the same packet. If they are, a decapsulating ETR MUST treat the 'Nonce/Map-Version' field as having a Nonce value present.
N：N位是当前位。当该位设置为1时，LISP头的前32位的低位24位包含一个Nonce。详见第6.3.1节。不能在同一个数据包中同时设置N位和V位。如果是，反封装ETR必须将“Nonce/Map Version”字段视为存在Nonce值。
L: The L-bit is the 'Locator-Status-Bits' field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32 bits of the LISP header are in use.
L：L位是“定位器状态位”字段启用位。当该位设置为1时，LISP头的第二个32位中的定位器状态位正在使用。
x 1 x x 0 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
x 1 x x 0 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E: The E-bit is the echo-nonce-request bit. This bit MUST be ignored and has no meaning when the N-bit is set to 0. When the N-bit is set to 1 and this bit is set to 1, an ITR is requesting that the nonce value in the 'Nonce' field be echoed back in LISP-encapsulated packets when the ITR is also an ETR. See Section 6.3.1 for details.
E：E位是回送当前请求位。当N位设置为0时，此位必须忽略且没有意义。当N位设置为1且该位设置为1时，当ITR也是ETR时，ITR请求在LISP封装的数据包中回显“nonce”字段中的nonce值。详见第6.3.1节。
V: The V-bit is the Map-Version present bit. When this bit is set to 1, the N-bit MUST be 0. Refer to Section 6.6.3 for more details. This bit indicates that the LISP header is encoded in this case as:
V：V位是地图版本当前位。当该位设置为1时，N位必须为0。有关更多详细信息，请参阅第6.6.3节。此位表示在这种情况下LISP头编码为：
0 x 0 1 x x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Source Map-Version | Dest Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID/Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 x 0 1 x x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Source Map-Version | Dest Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID/Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I: The I-bit is the Instance ID bit. See Section 5.5 for more details. When this bit is set to 1, the 'Locator-Status-Bits' field is reduced to 8 bits and the high-order 24 bits are used as an Instance ID. If the L-bit is set to 0, then the low-order 8 bits are transmitted as zero and ignored on receipt. The format of the LISP header would look like this:
I：I-bit是实例ID位。详见第5.5节。当该位设置为1时，“定位器状态位”字段减少为8位，高阶24位用作实例ID。如果L位设置为0，则低阶8位作为零传输，并在接收时忽略。LISP标头的格式如下所示：
x x x x 1 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID | LSBs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
x x x x 1 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID | LSBs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
flags: The 'flags' field is a 3-bit field reserved for future flag use. It MUST be set to 0 on transmit and MUST be ignored on receipt.
标志：“标志”字段是为将来标志使用而保留的3位字段。传输时必须将其设置为0，接收时必须忽略。
LISP Nonce: The LISP 'Nonce' field is a 24-bit value that is randomly generated by an ITR when the N-bit is set to 1. Nonce generation algorithms are an implementation matter but are required to generate different nonces when sending to different destinations. However, the same nonce can be used for a period of time to the same destination. The nonce is also used when the E-bit is set to request the nonce value to be echoed by the other side when packets are returned. When the E-bit is clear but the N-bit is set, a remote ITR is either echoing a previously requested echo-nonce or providing a random nonce. See Section 6.3.1 for more details.
LISP Nonce:LISP“Nonce”字段是一个24位的值，当N位设置为1时，由ITR随机生成。Nonce生成算法是一个实现问题，但需要在发送到不同目的地时生成不同的Nonce。但是，相同的nonce可以在一段时间内用于相同的目的地。当E位被设置为请求在返回数据包时由另一方回显nonce值时，也使用nonce。当E位清除但设置了N位时，远程ITR要么回显先前请求的回显nonce，要么提供随机nonce。详见第6.3.1节。
LISP Locator-Status-Bits (LSBs): When the L-bit is also set, the 'Locator-Status-Bits' field in the LISP header is set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator-Status-Bits are numbered from 0 to n-1 from the least significant bit of the field. The field is 32 bits when the I-bit is set to 0 and is 8 bits when the I-bit is set to 1. When a Locator-Status-Bit is set to 1, the ITR is indicating to the ETR that the RLOC associated with the bit ordinal has up status. See Section 6.3 for details on how an ITR can determine the status of the ETRs at the same site. When a site has multiple EID-Prefixes that result in multiple mappings (where each could have a different Locator-Set), the Locator-Status-Bits setting in an encapsulated packet MUST reflect the mapping for the EID-Prefix that the inner-header source EID address matches. If the LSB for an anycast Locator is set to 1, then there is at least one RLOC with that address, and the ETR is considered 'up'.
LISP定位器状态位（LSB）：同时设置L位时，ITR会设置LISP标题中的“定位器状态位”字段，以向ETR指示源站点中定位器的向上/向下状态。映射回复中的每个RLOC都被分配一个从0到n-1的顺序值（当映射条目中有n个RLOC时）。定位器状态位从字段的最低有效位开始从0到n-1进行编号。当I位设置为0时，字段为32位，当I位设置为1时，字段为8位。当定位器状态位设置为1时，ITR向ETR指示与位序号关联的RLOC具有up状态。有关ITR如何确定同一站点ETR状态的详细信息，请参见第6.3节。当一个站点有多个EID前缀导致多个映射（其中每个都可能有不同的定位器集）时，封装数据包中的定位器状态位设置必须反映内部报头源EID地址匹配的EID前缀的映射。如果选播定位器的LSB设置为1，则至少有一个具有该地址的RLOC，ETR被视为“向上”。
When doing ITR/PITR encapsulation:
进行ITR/PITR封装时：
o The outer-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the inner-header 'Time to Live' field.
o 外部标头“生存时间”字段（或“跃点限制”字段，在IPv6的情况下）应从内部标头“生存时间”字段复制。
o The outer-header 'Type of Service' field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the inner-header 'Type of Service' field (with one exception; see below).
o 外部标头“服务类型”字段（如果是IPv6，则为“流量类别”字段）应从内部标头“服务类型”字段复制（只有一个例外；请参见下文）。
When doing ETR/PETR decapsulation:
进行ETR/PETR去封装时：
o The inner-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the outer-header 'Time to Live' field, when the Time to Live value of the outer header is less than the Time to Live value of the inner header. Failing to perform this check can cause the Time to Live of the inner header to increment across encapsulation/decapsulation cycles. This check is also performed when doing initial encapsulation, when a packet comes to an ITR or PITR destined for a LISP site.
o 当外部标头的生存时间值小于内部标头的生存时间值时，应从外部标头的“生存时间”字段复制内部标头的“生存时间”字段（如果是IPv6，则为“跃点限制”字段）。未能执行此检查可能会导致内部收割台的生存时间在封装/脱封装周期中增加。当数据包到达以LISP站点为目的地的ITR或PITR时，在进行初始封装时也会执行此检查。
o The inner-header 'Type of Service' field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the outer-header 'Type of Service' field (with one exception; see below).
o 内部报头“服务类型”字段（如果是IPv6，则为“流量类别”字段）应从外部报头“服务类型”字段复制（只有一个例外；请参见下文）。
Note that if an ETR/PETR is also an ITR/PITR and chooses to re-encapsulate after decapsulating, the net effect of this is that the new outer header will carry the same Time to Live as the old outer header minus 1.
请注意，如果ETR/PETR也是一个ITR/PITR，并选择在解封后重新封装，则其净效果是新的外部收割台将与旧的外部收割台减去1的生存时间相同。
Copying the Time to Live (TTL) serves two purposes: first, it preserves the distance the host intended the packet to travel; second, and more importantly, it provides for suppression of looping packets in the event there is a loop of concatenated tunnels due to misconfiguration. See Section 9.3 for TTL exception handling for traceroute packets.
复制生存时间（TTL）有两个目的：第一，它保留了主机希望数据包移动的距离；第二，也是更重要的一点，它提供了在由于配置错误而出现连接隧道循环时抑制循环数据包的功能。有关跟踪路由数据包的TTL异常处理，请参见第9.3节。
The Explicit Congestion Notification ('ECN') field occupies bits 6 and 7 of both the IPv4 'Type of Service' field and the IPv6 'Traffic Class' field [RFC3168]. The 'ECN' field requires special treatment in order to avoid discarding indications of congestion [RFC3168]. ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner header to the outer header. Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the new outer header. If the 'ECN' field contains a congestion indication codepoint (the value is '11', the Congestion Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the surviving inner header that is used to forward the
显式拥塞通知（“ECN”）字段占用IPv4“服务类型”字段和IPv6“流量类别”字段[RFC3168]的第6位和第7位。“ECN”字段需要特殊处理，以避免丢弃拥塞指示[RFC3168]。ITR封装必须将2位“ECN”字段从内部标头复制到外部标头。重新封装必须将2位“ECN”字段从剥离的外部标头复制到新的外部标头。如果“ECN”字段包含拥塞指示码点（值为“11”，即拥塞经历（CE）码点），则ETR解除封装必须将2位“ECN”字段从剥离的外部标头复制到用于转发数据的剩余内部标头
packet beyond the ETR. These requirements preserve CE indications when a packet that uses ECN traverses a LISP tunnel and becomes marked with a CE indication due to congestion between the tunnel endpoints.
超出ETR的数据包。当使用ECN的数据包通过LISP隧道并且由于隧道端点之间的拥塞而被标记为CE指示时，这些要求保留CE指示。
This section proposes two mechanisms to deal with packets that exceed the path MTU between the ITR and ETR.
本节提出两种机制来处理超出ITR和ETR之间路径MTU的数据包。
It is left to the implementor to decide if the stateless or stateful mechanism should be implemented. Both or neither can be used, since it is a local decision in the ITR regarding how to deal with MTU issues, and sites can interoperate with differing mechanisms.
由实现者来决定是应该实现无状态机制还是有状态机制。两者都可以使用，或者两者都不能使用，因为这是ITR关于如何处理MTU问题的本地决定，站点可以使用不同的机制进行互操作。
Both stateless and stateful mechanisms also apply to Re-encapsulating and Recursive Tunneling, so any actions below referring to an ITR also apply to a TE-ITR.
无状态和有状态机制也适用于重新封装和递归隧道，因此下面提及ITR的任何操作也适用于TE-ITR。
An ITR stateless solution to handle MTU issues is described as follows:
处理MTU问题的ITR无状态解决方案描述如下：
1. Define H to be the size, in octets, of the outer header an ITR prepends to a packet. This includes the UDP and LISP header lengths.
1. 定义H为ITR向数据包发送的外部报头的大小（以八位字节为单位）。这包括UDP和LISP标头长度。
2. Define L to be the size, in octets, of the maximum-sized packet an ITR can send to an ETR without the need for the ITR or any intermediate routers to fragment the packet.
2. 将L定义为ITR可以发送到ETR的最大大小数据包的大小（以八位字节为单位），而无需ITR或任何中间路由器对数据包进行分段。
3. Define an architectural constant S for the maximum size of a packet, in octets, an ITR must receive so the effective MTU can be met. That is, S = L - H.
3. 为数据包的最大大小定义一个体系结构常数S，以八位字节为单位，ITR必须接收，以满足有效MTU的要求。也就是说，S=L-H。
When an ITR receives a packet from a site-facing interface and adds H octets worth of encapsulation to yield a packet size greater than L octets, it resolves the MTU issue by first splitting the original packet into 2 equal-sized fragments. A LISP header is then prepended to each fragment. The size of the encapsulated fragments is then (S/2 + H), which is less than the ITR's estimate of the path MTU between the ITR and its correspondent ETR.
当ITR从面向站点的接口接收数据包并添加H个八位字节值的封装以产生大于L个八位字节的数据包大小时，它通过首先将原始数据包拆分为2个大小相等的片段来解决MTU问题。然后在每个片段前面加上一个LISP头。然后，封装片段的大小为（S/2+H），这小于ITR对ITR与其对应ETR之间路径MTU的估计值。
When an ETR receives encapsulated fragments, it treats them as two individually encapsulated packets. It strips the LISP headers and then forwards each fragment to the destination host of the destination site. The two fragments are reassembled at the
当ETR接收到封装的片段时，它将它们视为两个单独封装的数据包。它剥离LISP头，然后将每个片段转发到目标站点的目标主机。这两个碎片在同一时刻重新组装
destination host into the single IP datagram that was originated by the source host. Note that reassembly can happen at the ETR if the encapsulated packet was fragmented at or after the ITR.
将目标主机转换为源主机发起的单个IP数据报。请注意，如果封装的数据包在ITR时或之后出现碎片，则可在ETR处重新组装。
This behavior is performed by the ITR when the source host originates a packet with the 'DF' field of the IP header set to 0. When the 'DF' field of the IP header is set to 1, or the packet is an IPv6 packet originated by the source host, the ITR will drop the packet when the size is greater than L and send an ICMP Too Big message to the source with a value of S, where S is (L - H).
当源主机在IP头的“DF”字段设置为0的情况下发起数据包时，ITR将执行此行为。当IP报头的“DF”字段设置为1，或者数据包是源主机发起的IPv6数据包时，ITR将在数据包大小大于L时丢弃该数据包，并向源发送一条ICMP过大消息，其值为S，其中S为（L-H）。
When the outer-header encapsulation uses an IPv4 header, an implementation SHOULD set the DF bit to 1 so ETR fragment reassembly can be avoided. An implementation MAY set the DF bit in such headers to 0 if it has good reason to believe there are unresolvable path MTU issues between the sending ITR and the receiving ETR.
当外部标头封装使用IPv4标头时，实现应将DF位设置为1，以避免ETR片段重新组装。如果有充分理由相信发送ITR和接收ETR之间存在无法解决的路径MTU问题，则实现可以将此类报头中的DF位设置为0。
This specification RECOMMENDS that L be defined as 1500.
本规范建议将L定义为1500。
An ITR stateful solution to handle MTU issues is described as follows and was first introduced in [OPENLISP]:
处理MTU问题的ITR有状态解决方案描述如下，并首次在[OPENLISP]中介绍：
1. The ITR will keep state of the effective MTU for each Locator per Map-Cache entry. The effective MTU is what the core network can deliver along the path between the ITR and ETR.
1. ITR将为每个地图缓存条目保留每个定位器的有效MTU状态。有效的MTU是核心网络可以在ITR和ETR之间的路径上提供的。
2. When an IPv6-encapsulated packet, or an IPv4-encapsulated packet with the DF bit set to 1, exceeds what the core network can deliver, one of the intermediate routers on the path will send an ICMP Too Big message to the ITR. The ITR will parse the ICMP message to determine which Locator is affected by the effective MTU change and then record the new effective MTU value in the Map-Cache entry.
2. 当IPv6封装数据包或DF位设置为1的IPv4封装数据包超出核心网络的传输能力时，路径上的一个中间路由器将向ITR发送ICMP过大消息。ITR将解析ICMP消息，以确定哪个定位器受到有效MTU更改的影响，然后在地图缓存条目中记录新的有效MTU值。
3. When a packet is received by the ITR from a source inside of the site and the size of the packet is greater than the effective MTU stored with the Map-Cache entry associated with the destination EID the packet is for, the ITR will send an ICMP Too Big message back to the source. The packet size advertised by the ITR in the ICMP Too Big message is the effective MTU minus the LISP encapsulation length.
3. 当ITR从站点内部的源接收到数据包，并且数据包的大小大于与数据包所针对的目的地EID相关联的映射缓存项存储的有效MTU时，ITR将向源发送ICMP过大消息。ITR在ICMP太大消息中公布的数据包大小是有效MTU减去LISP封装长度。
Even though this mechanism is stateful, it has advantages over the stateless IP fragmentation mechanism, by not involving the destination host with reassembly of ITR fragmented packets.
尽管这种机制是有状态的，但它与无状态IP碎片机制相比具有优势，因为它不涉及目标主机重新组装ITR碎片数据包。
When multiple organizations inside of a LISP site are using private addresses [RFC1918] as EID-Prefixes, their address spaces MUST remain segregated due to possible address duplication. An Instance ID in the address encoding can aid in making the entire AFI-based address unique. See IANA Considerations (Section 14.2) for details on possible address encodings.
当LISP站点内的多个组织使用专用地址[RFC1918]作为EID前缀时，由于可能存在地址重复，它们的地址空间必须保持隔离。地址编码中的实例ID有助于使整个基于AFI的地址唯一。有关可能的地址编码的详细信息，请参见IANA注意事项（第14.2节）。
An Instance ID can be carried in a LISP-encapsulated packet. An ITR that prepends a LISP header will copy a 24-bit value used by the LISP router to uniquely identify the address space. The value is copied to the 'Instance ID' field of the LISP header, and the I-bit is set to 1.
实例ID可以在LISP封装的数据包中携带。在LISP报头前面加上前缀的ITR将复制LISP路由器用于唯一标识地址空间的24位值。该值被复制到LISP头的“实例ID”字段，I位设置为1。
When an ETR decapsulates a packet, the Instance ID from the LISP header is used as a table identifier to locate the forwarding table to use for the inner destination EID lookup.
ETR解除数据包封装时，LISP头中的实例ID用作表标识符，以定位用于内部目标EID查找的转发表。
For example, an 802.1Q VLAN tag or VPN identifier could be used as a 24-bit Instance ID.
例如，802.1Q VLAN标记或VPN标识符可以用作24位实例ID。
The following UDP packet formats are used by the LISP control plane.
LISP控制平面使用以下UDP数据包格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol = 17 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Routing Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Routing Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port | Dest Port |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| LISP Message |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol = 17 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Routing Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Routing Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port | Dest Port |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| LISP Message |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header=17| Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Routing Locator +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Routing Locator +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port | Dest Port |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| LISP Message |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header=17| Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Routing Locator +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Routing Locator +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port | Dest Port |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| LISP Message |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LISP UDP-based messages are the Map-Request and Map-Reply messages. When a UDP Map-Request is sent, the UDP source port is chosen by the sender and the destination UDP port number is set to 4342. When a UDP Map-Reply is sent, the source UDP port number is set to 4342 and the destination UDP port number is copied from the source port of either the Map-Request or the invoking data packet. Implementations MUST be prepared to accept packets when either the source port or destination UDP port is set to 4342 due to NATs changing port number values.
基于LISP UDP的消息是映射请求和映射回复消息。发送UDP映射请求时，发送方选择UDP源端口，目标UDP端口号设置为4342。发送UDP映射应答时，源UDP端口号设置为4342，目标UDP端口号从映射请求或调用数据包的源端口复制。当源端口或目标UDP端口由于NAT更改端口号值而设置为4342时，实现必须准备好接受数据包。
The 'UDP Length' field will reflect the length of the UDP header and the LISP Message payload.
“UDP长度”字段将反映UDP标头和LISP消息负载的长度。
The UDP checksum is computed and set to non-zero for Map-Request, Map-Reply, Map-Register, and Encapsulated Control Message (ECM) control messages. It MUST be checked on receipt, and if the checksum fails, the packet MUST be dropped.
对于映射请求、映射应答、映射寄存器和封装控制消息（ECM）控制消息，计算UDP校验和并将其设置为非零。必须在收到时对其进行检查，如果校验和失败，则必须丢弃数据包。
The format of control messages includes the UDP header so the checksum and length fields can be used to protect and delimit message boundaries.
控制消息的格式包括UDP报头，因此校验和和长度字段可用于保护和划定消息边界。
This section will be the authoritative source for allocating LISP Type values and for defining LISP control message formats. Current allocations are:
本节将是分配LISP类型值和定义LISP控制消息格式的权威来源。目前的拨款是：
Reserved: 0 b'0000' LISP Map-Request: 1 b'0001' LISP Map-Reply: 2 b'0010' LISP Map-Register: 3 b'0011' LISP Map-Notify: 4 b'0100' LISP Encapsulated Control Message: 8 b'1000'
保留：0 b'0000'LISP映射请求：1 b'0001'LISP映射答复：2 b'0010'LISP映射寄存器：3 b'0011'LISP映射通知：4 b'0100'LISP封装控制消息：8 b'1000'
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 |A|M|P|S|p|s| Reserved | IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-EID-AFI | Source EID Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI n | ITR-RLOC Address n ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Reserved | EID mask-len | EID-Prefix-AFI |
Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | EID-Prefix ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Map-Reply Record ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 |A|M|P|S|p|s| Reserved | IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-EID-AFI | Source EID Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI n | ITR-RLOC Address n ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Reserved | EID mask-len | EID-Prefix-AFI |
Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | EID-Prefix ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Map-Reply Record ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions:
数据包字段说明：
Type: 1 (Map-Request)
类型：1（地图请求）
A: This is an authoritative bit, which is set to 0 for UDP-based Map-Requests sent by an ITR. It is set to 1 when an ITR wants the destination site to return the Map-Reply rather than the mapping database system.
答：这是一个权威位，对于ITR发送的基于UDP的映射请求，它被设置为0。当ITR希望目标站点返回地图回复而不是地图数据库系统时，它被设置为1。
M: This is the map-data-present bit. When set, it indicates that a Map-Reply Record segment is included in the Map-Request.
M：这是地图数据显示位。设置后，表示映射请求中包含映射应答记录段。
P: This is the probe-bit, which indicates that a Map-Request SHOULD be treated as a Locator reachability probe. The receiver SHOULD respond with a Map-Reply with the probe-bit set, indicating that the Map-Reply is a Locator reachability probe reply, with the nonce copied from the Map-Request. See Section 6.3.2 for more details.
P：这是探测位，它表示映射请求应被视为定位器可达性探测。接收器应使用设置了探测位的Map应答进行响应，表明Map应答是定位器可达性探测应答，nonce从Map请求复制。详见第6.3.2节。
S: This is the Solicit-Map-Request (SMR) bit. See Section 6.6.2 for details.
S：这是请求映射请求（SMR）位。详见第6.6.2节。
p: This is the PITR bit. This bit is set to 1 when a PITR sends a Map-Request.
p:这是PITR位。当PITR发送Map请求时，该位设置为1。
s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is sending a Map-Request in response to a received SMR-based Map-Request.
s：这是SMR调用的位。当xTR发送Map请求以响应收到的基于SMR的Map请求时，此位设置为1。
Reserved: This field MUST be set to 0 on transmit and MUST be ignored on receipt.
保留：此字段在传输时必须设置为0，在接收时必须忽略。
IRC: This 5-bit field is the ITR-RLOC Count, which encodes the additional number of ('ITR-RLOC-AFI', 'ITR-RLOC Address') fields present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC-Address) pair MUST be encoded. Multiple 'ITR-RLOC Address' fields are used, so a Map-Replier can select which destination address to use for a Map-Reply. The IRC value ranges from 0 to 31. For a value of 0, there is 1 ITR-RLOC address encoded; for a value of 1, there are 2 ITR-RLOC addresses encoded, and so on up to 31, which encodes a total of 32 ITR-RLOC addresses.
IRC：此5位字段是ITR-RLOC计数，它对此消息中存在的额外（'ITR-RLOC-AFI'，'ITR-RLOC地址'）字段进行编码。必须对至少一对（ITR-RLOC-AFI、ITR-RLOC地址）进行编码。使用多个“ITR-RLOC地址”字段，因此映射应答器可以选择用于映射应答的目标地址。IRC值的范围为0到31。对于值0，有1个ITR-RLOC地址编码；对于值1，有2个编码的ITR-RLOC地址，以此类推，最多31个，总共编码32个ITR-RLOC地址。
Record Count: This is the number of records in this Map-Request message. A record is comprised of the portion of the packet that is labeled 'Rec' above and occurs the number of times equal to Record Count. For this version of the protocol, a receiver MUST accept and process Map-Requests that contain one or more records,
记录计数：这是此映射请求消息中的记录数。记录由上面标记为“Rec”的数据包部分组成，出现的次数等于记录计数。对于此版本的协议，接收方必须接受并处理包含一条或多条记录的Map请求，
but a sender MUST only send Map-Requests containing one record. Support for requesting multiple EIDs in a single Map-Request message will be specified in a future version of the protocol.
但发送方只能发送包含一条记录的映射请求。该协议的未来版本将指定支持在单个Map请求消息中请求多个EID。
Nonce: This is an 8-octet random value created by the sender of the Map-Request. This nonce will be returned in the Map-Reply. The security of the LISP mapping protocol critically depends on the strength of the nonce in the Map-Request message. The nonce SHOULD be generated by a properly seeded pseudo-random (or strong random) source. See [RFC4086] for advice on generating security-sensitive random data.
Nonce：这是由映射请求的发送方创建的8个八位字节的随机值。此nonce将在映射回复中返回。LISP映射协议的安全性在很大程度上取决于映射请求消息中nonce的强度。nonce应该由一个适当种子的伪随机（或强随机）源生成。有关生成安全敏感随机数据的建议，请参阅[RFC4086]。
Source-EID-AFI: This is the address family of the 'Source EID Address' field.
Source EID AFI：这是“Source EID address”字段的地址系列。
Source EID Address: This is the EID of the source host that originated the packet that caused the Map-Request. When Map-Requests are used for refreshing a Map-Cache entry or for RLOC-Probing, an AFI value 0 is used and this field is of zero length.
Source EID Address：这是发起导致Map请求的数据包的源主机的EID。当映射请求用于刷新映射缓存条目或用于RLOC探测时，将使用AFI值0，并且此字段的长度为零。
ITR-RLOC-AFI: This is the address family of the 'ITR-RLOC Address' field that follows this field.
ITR-RLOC-AFI：这是该字段后面的“ITR-RLOC地址”字段的地址系列。
ITR-RLOC Address: This is used to give the ETR the option of selecting the destination address from any address family for the Map-Reply message. This address MUST be a routable RLOC address of the sender of the Map-Request message.
ITR-RLOC地址：用于为ETR提供从任何地址系列中为Map回复消息选择目标地址的选项。此地址必须是映射请求消息的发送方的可路由RLOC地址。
EID mask-len: This is the mask length for the EID-Prefix.
EID掩码长度：这是EID前缀的掩码长度。
EID-Prefix-AFI: This is the address family of the EID-Prefix according to [AFI].
EID前缀AFI：根据[AFI]，这是EID前缀的地址族。
EID-Prefix: This prefix is 4 octets for an IPv4 address family and 16 octets for an IPv6 address family. When a Map-Request is sent by an ITR because a data packet is received for a destination where there is no mapping entry, the EID-Prefix is set to the destination IP address of the data packet, and the 'EID mask-len' is set to 32 or 128 for IPv4 or IPv6, respectively. When an xTR wants to query a site about the status of a mapping it already has cached, the EID-Prefix used in the Map-Request has the same mask length as the EID-Prefix returned from the site when it sent a Map-Reply message.
EID前缀：对于IPv4地址系列，此前缀为4个八位字节，对于IPv6地址系列，此前缀为16个八位字节。当ITR发送映射请求时，因为接收到没有映射条目的目的地的数据包，EID前缀设置为数据包的目的地IP地址，对于IPv4或IPv6，“EID掩码len”分别设置为32或128。当xTR希望查询站点已缓存映射的状态时，映射请求中使用的EID前缀的掩码长度与发送映射回复消息时从站点返回的EID前缀的掩码长度相同。
Map-Reply Record: When the M-bit is set, this field is the size of a single "Record" in the Map-Reply format. This Map-Reply record contains the EID-to-RLOC mapping entry associated with the Source EID. This allows the ETR that will receive this Map-Request to cache the data if it chooses to do so.
映射回复记录：设置M位时，此字段是映射回复格式中单个“记录”的大小。此映射回复记录包含与源EID关联的EID到RLOC映射项。这允许将接收此映射请求的ETR在选择缓存数据时缓存数据。
A Map-Request is sent from an ITR when it needs a mapping for an EID, wants to test an RLOC for reachability, or wants to refresh a mapping before TTL expiration. For the initial case, the destination IP address used for the Map-Request is the data packet's destination address (i.e., the destination EID) that had a mapping cache lookup failure. For the latter two cases, the destination IP address used for the Map-Request is one of the RLOC addresses from the Locator-Set of the Map-Cache entry. The source address is either an IPv4 or IPv6 RLOC address, depending on whether the Map-Request is using an IPv4 or IPv6 header, respectively. In all cases, the UDP source port number for the Map-Request message is a 16-bit value selected by the ITR/PITR, and the UDP destination port number is set to the well-known destination port number 4342. A successful Map-Reply, which is one that has a nonce that matches an outstanding Map-Request nonce, will update the cached set of RLOCs associated with the EID-Prefix range.
当ITR需要EID的映射、想要测试RLOC的可达性或想要在TTL过期之前刷新映射时，会从ITR发送映射请求。对于初始情况，用于映射请求的目标IP地址是发生映射缓存查找故障的数据包的目标地址（即，目标EID）。对于后两种情况，用于映射请求的目标IP地址是来自映射缓存项的定位器集的RLOC地址之一。源地址是IPv4或IPv6 RLOC地址，具体取决于映射请求分别使用的是IPv4头还是IPv6头。在所有情况下，映射请求消息的UDP源端口号都是由ITR/PITR选择的16位值，UDP目标端口号设置为众所周知的目标端口号4342。成功的映射应答（其nonce与未完成的映射请求nonce匹配）将更新与EID前缀范围关联的RLOC缓存集。
One or more Map-Request ('ITR-RLOC-AFI', 'ITR-RLOC-Address') fields MUST be filled in by the ITR. The number of fields (minus 1) encoded MUST be placed in the 'IRC' field. The ITR MAY include all locally configured Locators in this list or just provide one locator address from each address family it supports. If the ITR erroneously provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map-Request.
ITR必须填写一个或多个映射请求（“ITR-RLOC-AFI”、“ITR RLOC地址”）字段。编码的字段数（减1）必须放在“IRC”字段中。ITR可以在该列表中包括所有本地配置的定位器，或者仅从其支持的每个地址系列中提供一个定位器地址。如果ITR错误地没有提供ITR-RLOC地址，则映射应答器必须放弃映射请求。
Map-Requests can also be LISP encapsulated using UDP destination port 4342 with a LISP Type value set to "Encapsulated Control Message", when sent from an ITR to a Map-Resolver. Likewise, Map-Requests are LISP encapsulated the same way from a Map-Server to an ETR. Details on Encapsulated Map-Requests and Map-Resolvers can be found in [RFC6833].
映射请求也可以使用UDP目标端口4342进行LISP封装，当从ITR发送到映射解析器时，LISP类型值设置为“封装的控制消息”。同样，映射请求以相同的方式从映射服务器封装到ETR。有关封装的映射请求和映射解析器的详细信息，请参见[RFC6833]。
Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map-Request for the same EID-Prefix be sent no more than once per second.
映射请求必须有速率限制。建议每秒最多发送一次相同EID前缀的映射请求。
An ITR that is configured with mapping database information (i.e., it is also an ETR) MAY optionally include those mappings in a Map-Request. When an ETR configured to accept and verify such "piggybacked" mapping data receives such a Map-Request and it does
配置了映射数据库信息的ITR（即，它也是ETR）可以选择在映射请求中包含这些映射。当配置为接受和验证此类“搭载”映射数据的ETR收到此类映射请求时，它会
not have this mapping in the map-cache, it MAY originate a "verifying Map-Request", addressed to the map-requesting ITR and the ETR MAY add a Map-Cache entry. If the ETR has a Map-Cache entry that matches the "piggybacked" EID and the RLOC is in the Locator-Set for the entry, then it may send the "verifying Map-Request" directly to the originating Map-Request source. If the RLOC is not in the Locator-Set, then the ETR MUST send the "verifying Map-Request" to the "piggybacked" EID. Doing this forces the "verifying Map-Request" to go through the mapping database system to reach the authoritative source of information about that EID, guarding against RLOC-spoofing in the "piggybacked" mapping data.
如果地图缓存中没有此映射，它可能会发起一个“验证地图请求”，发往地图请求ITR，ETR可能会添加一个地图缓存条目。如果ETR的地图缓存条目与“搭载”EID匹配，且RLOC位于该条目的定位器集中，则ETR可将“验证地图请求”直接发送至原始地图请求源。如果RLOC不在定位器集中，则ETR必须将“验证映射请求”发送到“搭载”EID。这样做会迫使“验证映射请求”通过映射数据库系统到达关于该EID的权威信息源，从而防止“搭载”映射数据中的RLOC欺骗。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=2 |P|E|S| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Rsvd | Map-Version Number | EID-Prefix-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-Prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=2 |P|E|S| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Rsvd | Map-Version Number | EID-Prefix-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-Prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions:
数据包字段说明：
Type: 2 (Map-Reply)
类型：2（地图回复）
P: This is the probe-bit, which indicates that the Map-Reply is in response to a Locator reachability probe Map-Request. The 'Nonce' field MUST contain a copy of the nonce value from the original Map-Request. See Section 6.3.2 for more details.
P：这是探测位，表示Map应答是对定位器可达性探测Map请求的响应。“Nonce”字段必须包含原始映射请求的Nonce值的副本。详见第6.3.2节。
E: This bit indicates that the ETR that sends this Map-Reply message is advertising that the site is enabled for the Echo-Nonce Locator reachability algorithm. See Section 6.3.1 for more details.
E：此位表示发送此Map回复消息的ETR正在通知站点已启用Echo Nonce Locator可达性算法。详见第6.3.1节。
S: This is the Security bit. When set to 1, the following authentication information will be appended to the end of the Map-Reply. The detailed format of the Authentication Data Content is for further study.
S:这是安全部分。当设置为1时，以下身份验证信息将附加到映射回复的末尾。认证数据内容的详细格式有待进一步研究。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD Type | Authentication Data Content . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD Type | Authentication Data Content . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: This field MUST be set to 0 on transmit and MUST be ignored on receipt.
保留：此字段在传输时必须设置为0，在接收时必须忽略。
Record Count: This is the number of records in this reply message. A record is comprised of that portion of the packet labeled 'Record' above and occurs the number of times equal to Record Count.
Record Count：这是此回复消息中的记录数。记录由上面标记为“记录”的数据包部分组成，出现的次数等于记录计数。
Nonce: This is a 24-bit value set in a Data-Probe packet, or a 64-bit value from the Map-Request is echoed in this 'Nonce' field of the Map-Reply. When a 24-bit value is supplied, it resides in the low-order 64 bits of the 'Nonce' field.
Nonce：这是在数据探测数据包中设置的24位值，或者来自Map请求的64位值在Map应答的这个“Nonce”字段中被回显。提供24位值时，它位于“Nonce”字段的低位64位。
Record TTL: This is the time in minutes the recipient of the Map-Reply will store the mapping. If the TTL is 0, the entry SHOULD be removed from the cache immediately. If the value is 0xffffffff, the recipient can decide locally how long to store the mapping.
记录TTL：这是映射回复的收件人存储映射的时间（分钟）。如果TTL为0，则应立即从缓存中删除该项。如果该值为0xFFFFFF，则收件人可以在本地决定映射的存储时间。
Locator Count: This is the number of Locator entries. A Locator entry comprises what is labeled above as 'Loc'. The Locator count can be 0, indicating that there are no Locators for the EID-Prefix.
定位器计数：这是定位器条目的数量。定位器条目包含上面标记为“Loc”的内容。定位器计数可以为0，表示EID前缀没有定位器。
EID mask-len: This is the mask length for the EID-Prefix.
EID掩码长度：这是EID前缀的掩码长度。
ACT: This 3-bit field describes Negative Map-Reply actions. In any other message type, these bits are set to 0 and ignored on receipt. These bits are used only when the 'Locator Count' field is set to 0. The action bits are encoded only in Map-Reply messages. The actions defined are used by an ITR or PITR when a destination EID matches a negative Map-Cache entry. Unassigned values should cause a Map-Cache entry to be created, and when packets match this negative cache entry, they will be dropped. The current assigned values are:
ACT：此3位字段描述负面映射回复操作。在任何其他消息类型中，这些位设置为0，并在收到时忽略。这些位仅在“定位器计数”字段设置为0时使用。动作位仅在映射回复消息中编码。当目标EID与负映射缓存项匹配时，ITR或PITR将使用定义的操作。未分配的值应导致创建映射缓存项，当数据包与此负缓存项匹配时，它们将被丢弃。当前指定的值为：
(0) No-Action: The map-cache is kept alive, and no packet encapsulation occurs.
(0) 无操作：映射缓存保持活动状态，并且不会发生数据包封装。
(1) Natively-Forward: The packet is not encapsulated or dropped but natively forwarded.
(1) 本机转发：数据包不被封装或丢弃，而是本机转发。
(2) Send-Map-Request: The packet invokes sending a Map-Request.
(2) 发送映射请求：数据包调用发送映射请求。
(3) Drop: A packet that matches this map-cache entry is dropped. An ICMP Destination Unreachable message SHOULD be sent.
(3) Drop：删除与此映射缓存项匹配的数据包。应发送ICMP目标不可访问消息。
A: The Authoritative bit, when sent, is always set to 1 by an ETR. When a Map-Server is proxy Map-Replying [RFC6833] for a LISP site, the Authoritative bit is set to 0. This indicates to requesting ITRs that the Map-Reply was not originated by a LISP node managed at the site that owns the EID-Prefix.
答：ETR发送时，权威位始终设置为1。当地图服务器为LISP站点的代理地图应答[RFC6833]时，权威位设置为0。这向请求的ITRs表明映射回复不是由拥有EID前缀的站点上管理的LISP节点发起的。
Map-Version Number: When this 12-bit value is non-zero, the Map-Reply sender is informing the ITR what the version number is for the EID record contained in the Map-Reply. The ETR can allocate this number internally but MUST coordinate this value with other ETRs for the site. When this value is 0, there is no versioning information conveyed. The Map-Version Number can be included in Map-Request and Map-Register messages. See Section 6.6.3 for more details.
映射版本号：当此12位值非零时，映射回复发送器将通知ITR映射回复中包含的EID记录的版本号。ETR可以在内部分配此编号，但必须与站点的其他ETR协调此值。当该值为0时，不传递版本控制信息。地图版本号可以包含在地图请求和地图注册信息中。详见第6.6.3节。
EID-Prefix-AFI: Address family of the EID-Prefix according to [AFI].
EID前缀AFI：根据[AFI]的EID前缀的地址族。
EID-Prefix: This prefix is 4 octets for an IPv4 address family and 16 octets for an IPv6 address family.
EID前缀：对于IPv4地址系列，此前缀为4个八位字节，对于IPv6地址系列，此前缀为16个八位字节。
Priority: Each RLOC is assigned a unicast Priority. Lower values are more preferable. When multiple RLOCs have the same Priority, they MAY be used in a load-split fashion. A value of 255 means the RLOC MUST NOT be used for unicast forwarding.
优先级：为每个RLOC分配一个单播优先级。值越低越好。当多个RLOC具有相同的优先级时，可以以负载分割方式使用它们。值255表示RLOC不得用于单播转发。
Weight: When priorities are the same for multiple RLOCs, the Weight indicates how to balance unicast traffic between them. Weight is encoded as a relative weight of total unicast packets that match the mapping entry. For example, if there are 4 Locators in a Locator-Set, where the Weights assigned are 30, 20, 20, and 10, the first Locator will get 37.5% of the traffic, the 2nd and 3rd Locators will get 25% of the traffic, and the 4th Locator will get 12.5% of the traffic. If all Weights for a Locator-Set are equal, the receiver of the Map-Reply will decide how to load-split the traffic. See Section 6.5 for a suggested hash algorithm to distribute the load across Locators with the same Priority and equal Weight values.
权重：当多个RLOC的优先级相同时，权重指示如何平衡它们之间的单播流量。权重被编码为匹配映射条目的全部单播数据包的相对权重。例如，如果定位器集中有4个定位器，其中分配的权重为30、20、20和10，则第一个定位器将获得37.5%的流量，第二个和第三个定位器将获得25%的流量，第四个定位器将获得12.5%的流量。如果定位器集的所有权重相等，则Map回复的接收者将决定如何加载拆分流量。请参阅第6.5节，以了解建议的哈希算法，该算法用于在具有相同优先级和相等权重值的定位器之间分配负载。
M Priority: Each RLOC is assigned a multicast Priority used by an ETR in a receiver multicast site to select an ITR in a source multicast site for building multicast distribution trees. A value of 255 means the RLOC MUST NOT be used for joining a multicast distribution tree. For more details, see [RFC6831].
M优先级：为每个RLOC分配一个多播优先级，该优先级由接收方多播站点中的ETR使用，以选择源多播站点中的ITR以构建多播分发树。值255表示RLOC不得用于加入多播分发树。有关更多详细信息，请参阅[RFC6831]。
M Weight: When priorities are the same for multiple RLOCs, the Weight indicates how to balance building multicast distribution trees across multiple ITRs. The Weight is encoded as a relative weight (similar to the unicast Weights) of the total number of trees built to the source site identified by the EID-Prefix. If all Weights for a Locator-Set are equal, the receiver of the Map-Reply will decide how to distribute multicast state across ITRs. For more details, see [RFC6831].
M权重：当多个RLOC的优先级相同时，权重指示如何在多个ITR之间平衡构建多播分发树。权重被编码为EID前缀标识的源站点构建的树总数的相对权重（类似于单播权重）。如果定位器集的所有权重相等，则Map应答的接收器将决定如何在ITR之间分配多播状态。有关更多详细信息，请参阅[RFC6831]。
Unused Flags: These are set to 0 when sending and ignored on receipt.
未使用标志：发送时将其设置为0，接收时将其忽略。
L: When this bit is set, the Locator is flagged as a local Locator to the ETR that is sending the Map-Reply. When a Map-Server is doing proxy Map-Replying [RFC6833] for a LISP site, the L-bit is set to 0 for all Locators in this Locator-Set.
L：设置此位时，定位器被标记为发送地图回复的ETR的本地定位器。当地图服务器为LISP站点执行代理地图应答[RFC6833]时，此定位器集中的所有定位器的L位都设置为0。
p: When this bit is set, an ETR informs the RLOC-Probing ITR that the locator address for which this bit is set is the one being RLOC-probed and MAY be different from the source address of the Map-Reply. An ITR that RLOC-probes a particular Locator MUST use this Locator for retrieving the data structure used to store the fact that the Locator is reachable. The p-bit is set for a single Locator in the same Locator-Set. If an implementation sets more than one p-bit erroneously, the receiver of the Map-Reply MUST select the first Locator. The p-bit MUST NOT be set for Locator-Set records sent in Map-Request and Map-Register messages.
p：当设置此位时，ETR通知RLOC探测ITR，为其设置此位的定位器地址是正在进行RLOC探测的定位器地址，并且可能与Map应答的源地址不同。RLOC探测特定定位器的ITR必须使用此定位器来检索用于存储定位器可访问事实的数据结构。为同一定位器集中的单个定位器设置p位。如果实现错误地设置了多个p位，则Map应答的接收器必须选择第一个定位器。不得为地图请求和地图注册消息中发送的定位器集记录设置p位。
R: This is set when the sender of a Map-Reply has a route to the Locator in the Locator data record. This receiver may find this useful to know if the Locator is up but not necessarily reachable from the receiver's point of view. See also Section 6.4 for another way the R-bit may be used.
R：这是在地图回复的发送者在定位器数据记录中有到定位器的路由时设置的。该接收器可能会发现这有助于了解定位器是否向上，但从接收器的角度看不一定可以到达。另见第6.4节，了解使用R位的另一种方法。
Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) assigned to an ETR. Note that the destination RLOC address MAY be an anycast address. A source RLOC can be an anycast address as well. The source or destination RLOC MUST NOT be the broadcast address (255.255.255.255 or any subnet broadcast address known to the router) and MUST NOT be a link-local multicast address. The source RLOC MUST NOT be a multicast address. The destination RLOC SHOULD be a multicast address if it is being mapped from a multicast destination EID.
定位器：这是分配给ETR的IPv4或IPv6地址（由“Loc AFI”字段编码）。注意，目标RLOC地址可以是选播地址。源RLOC也可以是选播地址。源或目标RLOC不能是广播地址（255.255.255.255或路由器已知的任何子网广播地址），也不能是链路本地多播地址。源RLOC不能是多播地址。如果目标RLOC是从多播目标EID映射的，则它应该是多播地址。
A Map-Reply returns an EID-Prefix with a prefix length that is less than or equal to the EID being requested. The EID being requested is either from the destination field of an IP header of a Data-Probe or the EID record of a Map-Request. The RLOCs in the Map-Reply are globally routable IP addresses of all ETRs for the LISP site. Each RLOC conveys status reachability but does not convey path reachability from a requester's perspective. Separate testing of path reachability is required. See Section 6.3 for details.
映射应答返回前缀长度小于或等于所请求EID的EID前缀。请求的EID来自数据探测器IP头的目标字段或映射请求的EID记录。Map应答中的RLOC是LISP站点所有ETR的全局可路由IP地址。每个RLOC传递状态可达性，但不从请求者的角度传递路径可达性。需要单独测试路径可达性。详见第6.3节。
Note that a Map-Reply may contain different EID-Prefix granularity (prefix + length) than the Map-Request that triggers it. This might occur if a Map-Request were for a prefix that had been returned by an earlier Map-Reply. In such a case, the requester updates its cache with the new prefix information and granularity. For example, a requester with two cached EID-Prefixes that are covered by a Map-Reply containing one less-specific prefix replaces the entry with the less-specific EID-Prefix. Note that the reverse, replacement of one less-specific prefix with multiple more-specific prefixes, can also occur, not by removing the less-specific prefix but rather by adding the more-specific prefixes that, during a lookup, will override the less-specific prefix.
请注意，映射回复可能包含与触发它的映射请求不同的EID前缀粒度（前缀+长度）。如果映射请求是针对先前映射答复返回的前缀，则可能会发生这种情况。在这种情况下，请求者使用新的前缀信息和粒度更新其缓存。例如，具有两个缓存EID前缀的请求者（包含一个不太特定的前缀的映射答复包含这两个前缀）将使用不太特定的EID前缀替换条目。请注意，反过来，也可以将一个不太特定的前缀替换为多个更特定的前缀，方法不是删除不太特定的前缀，而是添加更特定的前缀，在查找过程中，这些前缀将覆盖不太特定的前缀。
When an ETR is configured with overlapping EID-Prefixes, a Map-Request with an EID that best matches any EID-Prefix MUST be returned in a single Map-Reply message. For instance, if an ETR had database mapping entries for EID-Prefixes:
当ETR配置为具有重叠EID前缀时，必须在单个映射回复消息中返回EID与任何EID前缀最匹配的映射请求。例如，如果ETR具有EID前缀的数据库映射项：
10.0.0.0/8 10.1.0.0/16 10.1.1.0/24 10.1.2.0/24
10.0.0.0/8 10.1.0.0/16 10.1.1.0/24 10.1.2.0/24
A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record count of 1 to be returned with a mapping record EID-Prefix of 10.1.1.0/24.
EID 10.1.1.1的映射请求将导致返回记录计数为1的映射回复，映射记录EID前缀为10.1.1.0/24。
A Map-Request for EID 10.1.5.5 would cause a Map-Reply with a record count of 3 to be returned with mapping records for EID-Prefixes 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24.
EID 10.1.5.5的映射请求将导致返回记录计数为3的映射回复，并返回EID前缀10.1.0.0/16、10.1.1.0/24和10.1.2.0/24的映射记录。
Note that not all overlapping EID-Prefixes need to be returned but only the more-specific entries (note that in the second example above 10.0.0.0/8 was not returned for requesting EID 10.1.5.5) for the matching EID-Prefix of the requesting EID. When more than one EID-Prefix is returned, all SHOULD use the same Time to Live value so they can all time out at the same time. When a more-specific EID-Prefix is received later, its Time to Live value in the Map-Reply record can be stored even when other less-specific entries exist. When a less-specific EID-Prefix is received later, its map-cache expiration time SHOULD be set to the minimum expiration time of any more-specific EID-Prefix in the map-cache. This is done so the integrity of the EID-Prefix set is wholly maintained and so no more-specific entries are removed from the map-cache while keeping less-specific entries.
请注意，不需要返回所有重叠的EID前缀，只需要返回请求EID的匹配EID前缀的更具体的条目（请注意，在上面的第二个示例中，10.0.0.0/8不是为请求EID 10.1.5.5而返回的）。当返回多个EID前缀时，所有EID前缀都应使用相同的生存时间值，以便它们可以同时超时。当稍后收到更具体的EID前缀时，即使存在其他不太具体的条目，也可以将其生存时间值存储在映射回复记录中。稍后接收到不太特定的EID前缀时，其映射缓存过期时间应设置为映射缓存中任何更特定EID前缀的最小过期时间。这样做是为了完全维护EID前缀集的完整性，因此不会从映射缓存中删除更多特定项，同时保留不太特定的项。
Map-Replies SHOULD be sent for an EID-Prefix no more often than once per second to the same requesting router. For scalability, it is expected that aggregation of EID addresses into EID-Prefixes will allow one Map-Reply to satisfy a mapping for the EID addresses in the prefix range, thereby reducing the number of Map-Request messages.
对于EID前缀，Map回复应不超过每秒一次发送到同一请求路由器。为了可伸缩性，预计将EID地址聚合到EID前缀中将允许一个映射应答来满足前缀范围内EID地址的映射，从而减少映射请求消息的数量。
Map-Reply records can have an empty Locator-Set. A Negative Map-Reply is a Map-Reply with an empty Locator-Set. Negative Map-Replies convey special actions by the sender to the ITR or PITR that have solicited the Map-Reply. There are two primary applications for Negative Map-Replies. The first is for a Map-Resolver to instruct an ITR or PITR when a destination is for a LISP site versus a non-LISP site, and the other is to source quench Map-Requests that are sent for non-allocated EIDs.
映射回复记录可以设置空的定位器。负面地图回复是带有空定位器集的地图回复。负面Map回复将发件人的特殊行动传达给请求Map回复的ITR或PITR。有两个主要应用程序用于否定映射答复。第一种是当目标是LISP站点而不是非LISP站点时，Map解析器指示ITR或PITR，另一种是为未分配的EID发送源淬火Map请求。
For each Map-Reply record, the list of Locators in a Locator-Set MUST appear in the same order for each ETR that originates a Map-Reply message. The Locator-Set MUST be sorted in order of ascending IP address where an IPv4 locator address is considered numerically 'less than' an IPv6 locator address.
对于每个地图回复记录，定位器集中的定位器列表必须以相同的顺序显示，用于生成地图回复消息的每个ETR。定位器集必须按IP地址升序排序，其中IPv4定位器地址在数字上被视为“小于”IPv6定位器地址。
When sending a Map-Reply message, the destination address is copied from one of the 'ITR-RLOC' fields from the Map-Request. The ETR can choose a locator address from one of the address families it supports. For Data-Probes, the destination address of the Map-Reply is copied from the source address of the Data-Probe message that is invoking the reply. The source address of the Map-Reply is one of the local IP addresses chosen to allow Unicast Reverse Path Forwarding (uRPF) checks to succeed in the upstream service provider. The destination port of a Map-Reply message is copied from the source port of the Map-Request or Data-Probe, and the source port of the Map-Reply message is set to the well-known UDP port 4342.
发送映射回复消息时，从映射请求的“ITR-RLOC”字段之一复制目标地址。ETR可以从其支持的地址族中选择定位器地址。对于数据探测，映射应答的目标地址从调用应答的数据探测消息的源地址复制。映射应答的源地址是选择的本地IP地址之一，以允许单播反向路径转发（uRPF）检查在上游服务提供商中成功。映射应答消息的目标端口从映射请求或数据探测的源端口复制，映射应答消息的源端口设置为众所周知的UDP端口4342。
When an ETR is misconfigured or compromised, it could return coarse EID-Prefixes in Map-Reply messages it sends. The EID-Prefix could cover EID-Prefixes that are allocated to other sites, redirecting their traffic to the Locators of the compromised site.
当ETR配置错误或受损时，它可能会在发送的映射回复消息中返回粗略的EID前缀。EID前缀可以覆盖分配给其他站点的EID前缀，从而将其流量重定向到受损站点的定位器。
To solve this problem, there are two basic solutions that could be used. The first is to have Map-Servers proxy Map-Reply on behalf of ETRs so their registered EID-Prefixes are the ones returned in Map-Replies. Since the interaction between an ETR and Map-Server is secured with shared keys, it is easier for an ETR to detect misbehavior. The second solution is to have ITRs and PITRs cache EID-Prefixes with mask lengths that are greater than or equal to a configured prefix length. This limits the damage to a specific width of any EID-Prefix advertised but needs to be coordinated with the allocation of site prefixes. These solutions can be used independently or at the same time.
要解决这个问题，可以使用两种基本的解决方案。第一种方法是让地图服务器代表ETR代理地图回复，这样它们注册的EID前缀就是在地图回复中返回的前缀。由于ETR和地图服务器之间的交互使用共享密钥进行保护，因此ETR更容易检测错误行为。第二种解决方案是使ITRs和PITR缓存EID前缀的掩码长度大于或等于配置的前缀长度。这将损害限制在任何EID前缀的特定宽度，但需要与站点前缀的分配相协调。这些解决方案可以单独使用，也可以同时使用。
At the time of this writing, other approaches are being considered and researched.
在撰写本文时，其他方法正在考虑和研究中。
The usage details of the Map-Register message can be found in specification [RFC6833]. This section solely defines the message format.
映射寄存器消息的使用详细信息可在规范[RFC6833]中找到。本节仅定义消息格式。
The message is sent in UDP with a destination UDP port of 4342 and a randomly selected UDP source port number.
消息以UDP发送，目标UDP端口为4342，随机选择UDP源端口号。
The Map-Register message format is:
地图注册信息格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3 |P| Reserved |M| Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Rsvd | Map-Version Number | EID-Prefix-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-Prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3 |P| Reserved |M| Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Rsvd | Map-Version Number | EID-Prefix-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-Prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions:
数据包字段说明：
Type: 3 (Map-Register)
类型：3（映射寄存器）
P: This is the proxy Map-Reply bit. When set to 1, an ETR sends a Map-Register message requesting the Map-Server to proxy a Map-Reply. The Map-Server will send non-authoritative Map-Replies on behalf of the ETR. Details on this usage can be found in [RFC6833].
这是代理映射回复位。当设置为1时，ETR将发送一条地图注册消息，请求地图服务器代理地图回复。地图服务器将代表ETR发送非权威地图回复。有关此用法的详细信息，请参见[RFC6833]。
Reserved: This field MUST be set to 0 on transmit and MUST be ignored on receipt.
保留：此字段在传输时必须设置为0，在接收时必须忽略。
M: This is the want-map-notify bit. When set to 1, an ETR is requesting a Map-Notify message to be returned in response to sending a Map-Register message. The Map-Notify message sent by a Map-Server is used to acknowledge receipt of a Map-Register message.
M：这是want map通知位。当设置为1时，ETR请求返回Map Notify消息以响应发送Map Register消息。Map服务器发送的Map Notify消息用于确认收到Map Register消息。
Record Count: This is the number of records in this Map-Register message. A record is comprised of that portion of the packet labeled 'Record' above and occurs the number of times equal to Record Count.
记录计数：这是此映射寄存器消息中的记录数。记录由上面标记为“记录”的数据包部分组成，出现的次数等于记录计数。
Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register messages. Since the Map-Register message is authenticated, the 'Nonce' field is not currently used for any security function but may be in the future as part of an anti-replay solution.
Nonce：在映射寄存器消息中，此8个八位字节的“Nonce”字段设置为0。由于映射寄存器消息经过身份验证，“Nonce”字段当前未用于任何安全功能，但将来可能会作为反重播解决方案的一部分。
Key ID: This is a configured ID to find the configured Message Authentication Code (MAC) algorithm and key value used for the authentication function. See Section 14.4 for codepoint assignments.
密钥ID：这是一个配置的ID，用于查找用于身份验证功能的配置消息身份验证代码（MAC）算法和密钥值。有关代码点分配，请参见第14.4节。
Authentication Data Length: This is the length in octets of the 'Authentication Data' field that follows this field. The length of the 'Authentication Data' field is dependent on the MAC algorithm used. The length field allows a device that doesn't know the MAC algorithm to correctly parse the packet.
身份验证数据长度：此字段后面的“身份验证数据”字段的长度（以八位字节为单位）。“身份验证数据”字段的长度取决于所使用的MAC算法。长度字段允许不知道MAC算法的设备正确解析数据包。
Authentication Data: This is the message digest used from the output of the MAC algorithm. The entire Map-Register payload is authenticated with this field preset to 0. After the MAC is computed, it is placed in this field. Implementations of this specification MUST include support for HMAC-SHA-1-96 [RFC2404], and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED.
身份验证数据：这是MAC算法输出中使用的消息摘要。通过将此字段预设为0对整个Map寄存器有效负载进行身份验证。计算MAC后，将其放置在此字段中。本规范的实施必须包括对HMAC-SHA-1-96[RFC2404]的支持，建议支持HMAC-SHA-256-128[RFC4868]。
The definition of the rest of the Map-Register can be found in Section 6.1.4.
Map寄存器其余部分的定义见第6.1.4节。
The usage details of the Map-Notify message can be found in specification [RFC6833]. This section solely defines the message format.
Map Notify消息的使用细节可以在规范[RFC6833]中找到。本节仅定义消息格式。
The message is sent inside a UDP packet with source and destination UDP ports equal to 4342.
消息在源和目标UDP端口等于4342的UDP数据包内发送。
The Map-Notify message format is:
地图通知消息格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=4 | Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Rsvd | Map-Version Number | EID-Prefix-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-Prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=4 | Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Rsvd | Map-Version Number | EID-Prefix-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-Prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions:
数据包字段说明：
Type: 4 (Map-Notify)
类型：4（地图通知）
The Map-Notify message has the same contents as a Map-Register message. See the Map-Register section for field descriptions.
Map Notify消息的内容与Map Register消息的内容相同。有关字段描述，请参见映射寄存器部分。
An Encapsulated Control Message (ECM) is used to encapsulate control packets sent between xTRs and the mapping database system described in [RFC6833].
封装控制消息（ECM）用于封装在XTR和映射数据库系统之间发送的控制数据包，如[RFC6833]所述。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header |
OH | (uses RLOC addresses) |
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4342 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LH |Type=8 |S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header |
IH | (uses RLOC or EID addresses) |
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = yyyy |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LCM | LISP Control Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header |
OH | (uses RLOC addresses) |
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4342 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LH |Type=8 |S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header |
IH | (uses RLOC or EID addresses) |
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = yyyy |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LCM | LISP Control Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet header descriptions:
数据包头描述：
OH: The outer IPv4 or IPv6 header, which uses RLOC addresses in the source and destination header address fields.
OH：外部IPv4或IPv6标头，在源和目标标头地址字段中使用RLOC地址。
UDP: The outer UDP header with destination port 4342. The source port is randomly allocated. The checksum field MUST be non-zero.
UDP：具有目标端口4342的外部UDP标头。源端口是随机分配的。校验和字段必须为非零。
LH: Type 8 is defined to be a "LISP Encapsulated Control Message", and what follows is either an IPv4 or IPv6 header as encoded by the first 4 bits after the 'Reserved' field.
LH:Type 8被定义为“LISP封装的控制消息”，下面是由“Reserved”字段后的前4位编码的IPv4或IPv6头。
S: This is the Security bit. When set to 1, the field following the 'Reserved' field will have the following format. The detailed format of the Authentication Data Content is for further study.
S:这是安全部分。当设置为1时，“保留”字段后面的字段将采用以下格式。认证数据内容的详细格式有待进一步研究。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD Type | Authentication Data Content . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD Type | Authentication Data Content . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IH: The inner IPv4 or IPv6 header, which can use either RLOC or EID addresses in the header address fields. When a Map-Request is encapsulated in this packet format, the destination address in this header is an EID.
IH：内部IPv4或IPv6标头，可以在标头地址字段中使用RLOC或EID地址。当Map请求以该数据包格式封装时，该报头中的目标地址是EID。
UDP: The inner UDP header, where the port assignments depend on the control packet being encapsulated. When the control packet is a Map-Request or Map-Register, the source port is selected by the ITR/PITR and the destination port is 4342. When the control packet is a Map-Reply, the source port is 4342 and the destination port is assigned from the source port of the invoking Map-Request. Port number 4341 MUST NOT be assigned to either port. The checksum field MUST be non-zero.
UDP：内部UDP报头，其中端口分配取决于封装的控制数据包。当控制包是映射请求或映射寄存器时，源端口由ITR/PITR选择，目标端口为4342。当控制包是Map应答时，源端口是4342，并且从调用Map请求的源端口分配目标端口。端口号4341不得分配给任何一个端口。校验和字段必须为非零。
LCM: The format is one of the control message formats described in this section. At this time, only Map-Request messages are allowed to be encapsulated. In the future, PIM Join/Prune messages [RFC6831] might be allowed. Encapsulating other types of LISP control messages is for further study. When Map-Requests are sent for RLOC-Probing purposes (i.e., the probe-bit is set), they MUST NOT be sent inside Encapsulated Control Messages.
LCM：该格式是本节中描述的控制消息格式之一。此时，只允许封装映射请求消息。将来，可能会允许PIM加入/删除消息[RFC6831]。封装其他类型的LISP控制消息有待进一步研究。当出于RLOC探测目的发送Map请求时（即设置探测位），不得在封装的控制消息内发送Map请求。
Both the client-side and server-side may need control over the selection of RLOCs for conversations between them. This control is achieved by manipulating the 'Priority' and 'Weight' fields in EID-to-RLOC Map-Reply messages. Alternatively, RLOC information MAY be gleaned from received tunneled packets or EID-to-RLOC Map-Request messages.
客户端和服务器端可能都需要控制用于它们之间对话的RLOC的选择。此控制通过操纵EID到RLOC映射回复消息中的“优先级”和“权重”字段来实现。或者，可以从接收到的隧道分组或EID到RLOC映射请求消息收集RLOC信息。
The following are different scenarios for choosing RLOCs and the controls that are available:
以下是选择RLOC和可用控件的不同方案：
o The server-side returns one RLOC. The client-side can only use one RLOC. The server-side has complete control of the selection.
o 服务器端返回一个RLOC。客户端只能使用一个RLOC。服务器端完全控制选择。
o The server-side returns a list of RLOCs where a subset of the list has the same best Priority. The client can only use the subset list according to the weighting assigned by the server-side. In this case, the server-side controls both the subset list and
o 服务器端返回RLOC列表，其中列表的子集具有相同的最佳优先级。客户端只能根据服务器端分配的权重使用子集列表。在这种情况下，服务器端控制子集列表和
load-splitting across its members. The client-side can use RLOCs outside of the subset list if it determines that the subset list is unreachable (unless RLOCs are set to a Priority of 255). Some sharing of control exists: the server-side determines the destination RLOC list and load distribution while the client-side has the option of using alternatives to this list if RLOCs in the list are unreachable.
在其成员之间拆分负载。如果客户端确定无法访问子集列表，则可以在子集列表之外使用RLOCs（除非RLOCs的优先级设置为255）。存在一些控制共享：服务器端确定目标RLOC列表和负载分布，而客户端可以选择在列表中的RLOC无法访问时使用此列表的替代方案。
o The server-side sets a Weight of 0 for the RLOC subset list. In this case, the client-side can choose how the traffic load is spread across the subset list. Control is shared by the server-side determining the list and the client determining load distribution. Again, the client can use alternative RLOCs if the server-provided list of RLOCs is unreachable.
o 服务器端将RLOC子集列表的权重设置为0。在这种情况下，客户端可以选择流量负载如何分布在子集列表中。控制由确定列表的服务器端和确定负载分布的客户端共享。同样，如果无法访问服务器提供的RLOC列表，则客户端可以使用替代RLOC。
o Either side (more likely the server-side ETR) decides not to send a Map-Request. For example, if the server-side ETR does not send Map-Requests, it gleans RLOCs from the client-side ITR, giving the client-side ITR responsibility for bidirectional RLOC reachability and preferability. Server-side ETR gleaning of the client-side ITR RLOC is done by caching the inner-header source EID and the outer-header source RLOC of received packets. The client-side ITR controls how traffic is returned and can alternate using an outer-header source RLOC, which then can be added to the list the server-side ETR uses to return traffic. Since no Priority or Weights are provided using this method, the server-side ETR MUST assume that each client-side ITR RLOC uses the same best Priority with a Weight of zero. In addition, since EID-Prefix encoding cannot be conveyed in data packets, the EID-to-RLOC Cache on Tunnel Routers can grow to be very large.
o 任何一方（更可能是服务器端ETR）决定不发送映射请求。例如，如果服务器端ETR不发送Map请求，它将从客户端ITR收集RLOC，从而使客户端ITR负责双向RLOC可达性和优先性。通过缓存所接收数据包的内部报头源EID和外部报头源RLOC，完成客户端ITR RLOC的服务器端ETR收集。客户端ITR控制流量的返回方式，并可以使用外部标头源RLOC进行替换，然后可以将外部标头源RLOC添加到服务器端ETR用于返回流量的列表中。由于使用此方法不提供优先级或权重，服务器端ETR必须假设每个客户端ITR RLOC使用相同的最佳优先级，权重为零。此外，由于EID前缀编码不能在数据包中传输，因此隧道路由器上的EID到RLOC缓存可能会变得非常大。
o A "gleaned" Map-Cache entry, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner-header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the Map-Cache entry for the "gleaned" EID and is stored and used for the time indicated from the 'TTL' field of a received Map-Reply. When a verified Map-Cache entry is stored, data gleaning no longer occurs for subsequent packets that have a source EID that matches the EID-Prefix of the verified entry.
o “收集的”映射缓存条目（从接收到的封装数据包的源RLOC中学习的条目）仅存储并使用几秒钟，等待验证。通过向接收到的封装数据包的源EID（内部报头IP源地址）发送映射请求来执行验证。此“验证映射请求”的回复用于完全填充“已收集”EID的映射缓存条目，并在收到映射回复的“TTL”字段指示的时间内存储和使用。存储已验证映射缓存项时，对于具有与已验证项的EID前缀匹配的源EID的后续数据包，不再进行数据收集。
RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit for the Locator record is set to 1. When the R-bit is set to 0, an ITR or PITR MUST NOT encapsulate to the RLOC. Neither the information contained in a Map-Reply nor that stored in the mapping database system provides reachability
当定位器记录的R位设置为1时，将假定出现在EID到RLOC映射回复消息中的RLOC是可访问的。当R位设置为0时，ITR或PITR不得封装到RLOC。地图回复中包含的信息和地图数据库系统中存储的信息都不提供可访问性
information for RLOCs. Note that reachability is not part of the mapping system and is determined using one or more of the Routing Locator reachability algorithms described in the next section.
RLOCs的信息。请注意，可达性不是映射系统的一部分，而是使用下一节中描述的一个或多个路由定位器可达性算法确定的。
Several mechanisms for determining RLOC reachability are currently defined:
目前定义了几种确定RLOC可达性的机制：
1. An ETR may examine the Locator-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC.
1. ETR可以检查从ITR接收的封装数据包的LISP报头中的定位器状态位。如果ETR也充当ITR，并且有返回原始ITR站点的流量，则ETR可以使用此状态信息帮助选择RLOC。
2. An ITR may receive an ICMP Network Unreachable or Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. Note that trusting ICMP messages may not be desirable, but neither is ignoring them completely. Implementations are encouraged to follow current best practices in treating these conditions.
2. ITR可能会收到其正在使用的RLOC的ICMP网络无法访问或主机无法访问消息。这表明RLOC可能下降。请注意，信任ICMP消息可能并不可取，但也不是完全忽略它们。在处理这些情况时，鼓励实施遵循当前的最佳实践。
3. An ITR that participates in the global routing system can determine that an RLOC is down if no BGP Routing Information Base (RIB) route exists that matches the RLOC IP address.
3. 如果不存在与RLOC IP地址匹配的BGP路由信息库（RIB）路由，则参与全局路由系统的ITR可以确定RLOC已关闭。
4. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [RFC6832] and LISP-encapsulated data is sent to a non-LISP-capable site.
4. ITR可能从目标主机接收ICMP端口不可访问消息。如果ITR尝试使用互通[RFC6832]，并且LISP封装的数据被发送到不支持LISP的站点，则会发生这种情况。
5. An ITR may receive a Map-Reply from an ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up, since the ETR was able to send the Map-Reply to the ITR.
5. ITR可以从ETR接收Map回复，以响应先前发送的Map请求。Map回复的RLOC源可能已启动，因为ETR能够将Map回复发送给ITR。
6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up.
6. 当ETR从ITR接收到封装的数据包时，来自数据包外部报头的源RLOC很可能向上。
7. An ITR/ETR pair can use the Locator reachability algorithms described in this section, namely Echo-Noncing or RLOC-Probing.
7. ITR/ETR对可以使用本节中描述的定位器可达性算法，即回声非编码或RLOC探测。
When determining Locator up/down reachability by examining the Locator-Status-Bits from the LISP-encapsulated data packet, an ETR will receive up-to-date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows:
当通过检查LISP封装数据包中的定位器状态位来确定定位器上/下可达性时，ETR将从封装ITR接收关于站点所有ETR可达性的最新状态。源站点基于CE的ITR可以使用站点IGP确定彼此的可达性，如下所示：
o Under normal circumstances, each ITR will advertise a default route into the site IGP.
o 在正常情况下，每个ITR将公布进入站点IGP的默认路由。
o If an ITR fails or if the upstream link to its PE fails, its default route will either time out or be withdrawn.
o 如果ITR发生故障，或者到其PE的上游链路发生故障，则其默认路由将超时或被撤销。
Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator-Status-Bits it sets for them.
因此，每个ITR可以观察是否存在由其他ITR发起的默认路由，以确定为其设置的定位器状态位。
RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Locator-Status-Bits in a LISP-encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the 'Locator-Status-Bits' field for the packets they encapsulate.
映射回复中列出的RLOC使用序号0到n-1进行编号。LISP封装数据包中的定位器状态位从0到n-1编号，从最低有效位开始。例如，如果Map应答的第3个位置中列出的RLOC下降（序数值2），则站点上的所有ITR将清除其封装的数据包的“定位器状态位”字段的第3个最低有效位（xxxx x0xx）。
When an ETR decapsulates a packet, it will check for any change in the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the ETR, if acting also as an ITR, will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Locator-Status-Bit returns to a value of 1. Locator-Status-Bits are associated with a Locator-Set per EID-Prefix. Therefore, when a Locator becomes unreachable, the Locator-Status-Bit that corresponds to that Locator's position in the list returned by the last Map-Reply will be set to zero for that particular EID-Prefix.
当ETR解除数据包的封装时，它将检查“定位器状态位”字段中的任何更改。当一个位从1变为0时，如果ETR也充当ITR，则ETR将避免将数据包封装到指示为down的RLOC。只有当相应的定位器状态位返回到值1时，才会恢复使用该RLOC。定位器状态位与每个EID前缀的定位器集相关联。因此，当定位器变得不可访问时，对于该特定EID前缀，与该定位器在上一次地图回复返回的列表中的位置相对应的定位器状态位将设置为零。
When ITRs at the site are not deployed in CE routers, the IGP can still be used to determine the reachability of Locators, provided they are injected into the IGP. This is typically done when a /32 address is configured on a loopback interface.
当站点的ITR未部署在CE路由器中时，IGP仍然可以用于确定定位器的可达性，前提是它们被注入IGP中。这通常在环回接口上配置/32地址时完成。
When ITRs receive ICMP Network Unreachable or Host Unreachable messages as a method to determine unreachability, they will refrain from using Locators that are described in Locator lists of Map-Replies. However, using this approach is unreliable because many network operators turn off generation of ICMP Destination Unreachable messages.
当ITR接收ICMP网络不可访问或主机不可访问消息作为确定不可访问性的方法时，他们将避免使用地图回复定位器列表中描述的定位器。然而，使用这种方法是不可靠的，因为许多网络运营商关闭了ICMP目标不可到达消息的生成。
If an ITR does receive an ICMP Network Unreachable or Host Unreachable message, it MAY originate its own ICMP Destination Unreachable message destined for the host that originated the data packet the ITR encapsulated.
如果ITR确实收到ICMP网络不可访问或主机不可访问消息，则它可能会发起其自己的ICMP目的地不可访问消息，目的地为发起ITR封装的数据包的主机。
Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a locator address from a Locator-Set in a mapping entry matches a prefix. If it does not find one and BGP is running in the Default-Free Zone (DFZ), it can decide to not use the Locator even though the Locator-Status-Bits indicate that the Locator is up. In this case, the path from the ITR to the ETR that is assigned the Locator is not available. More details are in [LOC-ID-ARCH].
此外，启用BGP的ITR可以单方面检查RIB，以查看映射条目中定位器集的定位器地址是否与前缀匹配。如果未找到定位器，且BGP正在默认自由区（DFZ）中运行，则即使定位器状态位指示定位器已启动，也可以决定不使用定位器。在这种情况下，从ITR到分配了定位器的ETR的路径不可用。更多详情见[LOC-ID-ARCH]。
Optionally, an ITR can send a Map-Request to a Locator, and if a Map-Reply is returned, reachability of the Locator has been determined. Obviously, sending such probes increases the number of control messages originated by Tunnel Routers for active flows, so Locators are assumed to be reachable when they are advertised.
或者，ITR可以向定位器发送Map请求，如果返回Map回复，则定位器的可达性已经确定。显然，发送这样的探测会增加由活动流的隧道路由器发起的控制消息的数量，因此，当定位器被广告时，它们被认为是可到达的。
This assumption does create a dependency: Locator unreachability is detected by the receipt of ICMP Host Unreachable messages. When a Locator has been determined to be unreachable, it is not used for active traffic; this is the same as if it were listed in a Map-Reply with Priority 255.
这种假设确实产生了依赖关系：定位器不可访问性是通过接收ICMP主机不可访问消息来检测的。当一个定位器被确定为不可到达时，它不用于活动流量；这与在优先级为255的地图回复中列出的相同。
The ITR can test the reachability of the unreachable Locator by sending periodic Requests. Both Requests and Replies MUST be rate-limited. Locator reachability testing is never done with data packets, since that increases the risk of packet loss for end-to-end sessions.
ITR可以通过发送周期性请求来测试无法访问的定位器的可达性。请求和答复都必须有费率限制。定位器可达性测试从未对数据包进行过，因为这会增加端到端会话的数据包丢失风险。
When an ETR decapsulates a packet, it knows that it is reachable from the encapsulating ITR because that is how the packet arrived. In most cases, the ETR can also reach the ITR but cannot assume this to be true, due to the possibility of path asymmetry. In the presence of unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD NOT use the lack of return traffic as an indication that the ETR is unreachable. Instead, it MUST use an alternate mechanism to determine reachability.
当ETR解除对数据包的封装时，它知道可以从封装的ITR访问数据包，因为数据包就是这样到达的。在大多数情况下，ETR也可以到达ITR，但由于路径不对称的可能性，不能假设这是真的。在存在从ITR到ETR的单向交通流的情况下，ITR不应将缺少返回交通作为无法到达ETR的指示。相反，它必须使用另一种机制来确定可达性。
When data flows bidirectionally between Locators from different sites, a data-plane mechanism called "nonce echoing" can be used to determine reachability between an ITR and ETR. When an ITR wants to solicit a nonce echo, it sets the N- and E-bits and places a 24-bit nonce [RFC4086] in the LISP header of the next encapsulated data packet.
当数据在来自不同站点的定位器之间双向流动时，可以使用称为“nonce-echocing”的数据平面机制来确定ITR和ETR之间的可达性。当ITR想要请求一个nonce echo时，它设置N位和E位，并在下一个封装数据包的LISP报头中放置一个24位nonce[RFC4086]。
When this packet is received by the ETR, the encapsulated packet is forwarded as normal. When the ETR next sends a data packet to the ITR, it includes the nonce received earlier with the N-bit set and E-bit cleared. The ITR sees this "echoed nonce" and knows that the path to and from the ETR is up.
当ETR接收到此数据包时，封装的数据包将正常转发。当ETR下一次向ITR发送数据包时，它包括先前接收到的N位设置和E位清除的nonce。ITR看到这个“回响的时刻”，并知道进出ETR的路径是向上的。
The ITR will set the E-bit and N-bit for every packet it sends while in the echo-nonce-request state. The time the ITR waits to process the echoed nonce before it determines the path is unreachable is variable and is a choice left for the implementation.
ITR将在echo nonce请求状态下为其发送的每个数据包设置E位和N位。ITR在确定路径不可访问之前等待处理回显nonce的时间是可变的，这是留给实现的一个选择。
If the ITR is receiving packets from the ETR but does not see the nonce echoed while being in the echo-nonce-request state, then the path to the ETR is unreachable. This decision may be overridden by other Locator reachability algorithms. Once the ITR determines that the path to the ETR is down, it can switch to another Locator for that EID-Prefix.
如果ITR正在从ETR接收数据包，但在处于echo nonce请求状态时未看到nonce被回送，则ETR的路径不可访问。此决定可能会被其他定位器可达性算法覆盖。一旦ITR确定ETR的路径已关闭，它可以切换到该EID前缀的另一个定位器。
Note that "ITR" and "ETR" are relative terms here. Both devices MUST be implementing both ITR and ETR functionality for the echo nonce mechanism to operate.
请注意，“ITR”和“ETR”在这里是相对术语。这两个设备必须同时实现ITR和ETR功能，以便echo nonce机制运行。
The ITR and ETR may both go into the echo-nonce-request state at the same time. The number of packets sent or the time during which echo nonce requests are sent is an implementation-specific setting. However, when an ITR is in the echo-nonce-request state, it can echo the ETR's nonce in the next set of packets that it encapsulates and subsequently continue sending echo-nonce-request packets.
ITR和ETR可能同时进入回显当前请求状态。发送的数据包数或发送echo nonce请求的时间是特定于实现的设置。但是，当ITR处于echo nonce请求状态时，它可以在其封装的下一组数据包中回显ETR的nonce，然后继续发送echo nonce请求数据包。
This mechanism does not completely solve the forward path reachability problem, as traffic may be unidirectional. That is, the ETR receiving traffic at a site may not be the same device as an ITR that transmits traffic from that site, or the site-to-site traffic is unidirectional so there is no ITR returning traffic.
这种机制不能完全解决前向路径可达性问题，因为流量可能是单向的。也就是说，站点上接收流量的ETR可能与从该站点传输流量的ITR不同，或者站点到站点的流量是单向的，因此没有ITR返回流量。
The echo-nonce algorithm is bilateral. That is, if one side sets the E-bit and the other side is not enabled for echo-noncing, then the echoing of the nonce does not occur and the requesting side may erroneously consider the Locator unreachable. An ITR SHOULD only set the E-bit in an encapsulated data packet when it knows the ETR is enabled for echo-noncing. This is conveyed by the E-bit in the Map-Reply message.
echo nonce算法是双向的。也就是说，如果一方设置E-BIT，而另一侧不能启用回声回调，则不发生NoCE的回声，请求侧可能错误地认为定位器不可到达。只有当ITR知道ETR已启用回声非编码时，才应在封装数据包中设置E位。这是通过Map回复消息中的E位传递的。
Note that other Locator reachability mechanisms are being researched and can be used to compliment or even override the echo nonce algorithm. See the next section for an example of control-plane probing.
请注意，其他定位器可达性机制正在研究中，可用于补充甚至覆盖echo nonce算法。有关控制平面探测的示例，请参见下一节。
RLOC-Probing is a method that an ITR or PITR can use to determine the reachability status of one or more Locators that it has cached in a Map-Cache entry. The probe-bit of the Map-Request and Map-Reply messages is used for RLOC-Probing.
RLOC探测是一种方法，ITR或PITR可使用该方法确定已缓存在地图缓存项中的一个或多个定位器的可达性状态。Map请求和Map回复消息的探测位用于RLOC探测。
RLOC-Probing is done in the control plane on a timer basis, where an ITR or PITR will originate a Map-Request destined to a locator address from one of its own locator addresses. A Map-Request used as an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or to the mapping database system as one would when soliciting mapping data. The EID record encoded in the Map-Request is the EID-Prefix of the Map-Cache entry cached by the ITR or PITR. The ITR may include a mapping data record for its own database mapping information that contains the local EID-Prefixes and RLOCs for its site. RLOC-probes are sent periodically using a jittered timer interval.
RLOC探测是在控制平面上以定时器为基础进行的，其中ITR或PITR将从其自身的定位器地址之一发起以定位器地址为目的地的映射请求。用作RLOC探测的映射请求没有封装，也没有像请求映射数据时那样发送到映射服务器或映射数据库系统。映射请求中编码的EID记录是ITR或PITR缓存的映射缓存项的EID前缀。ITR可以包括其自身数据库映射信息的映射数据记录，该数据库映射信息包含其站点的本地EID前缀和RLOC。使用抖动的计时器间隔定期发送RLOC探测。
When an ETR receives a Map-Request message with the probe-bit set, it returns a Map-Reply with the probe-bit set. The source address of the Map-Reply is set according to the procedure described in Section 6.1.5. The Map-Reply SHOULD contain mapping data for the EID-Prefix contained in the Map-Request. This provides the opportunity for the ITR or PITR that sent the RLOC-probe to get mapping updates if there were changes to the ETR's database mapping entries.
当ETR接收到设置了探测位的Map请求消息时，它将返回设置了探测位的Map回复。Map应答的源地址根据第6.1.5节所述的程序设置。映射回复应该包含映射请求中包含的EID前缀的映射数据。这为发送RLOC探测器的ITR或PITR提供了在ETR的数据库映射条目发生更改时获取映射更新的机会。
There are advantages and disadvantages of RLOC-Probing. The greatest benefit of RLOC-Probing is that it can handle many failure scenarios allowing the ITR to determine when the path to a specific Locator is reachable or has become unreachable, thus providing a robust mechanism for switching to using another Locator from the cached Locator. RLOC-Probing can also provide rough Round-Trip Time (RTT) estimates between a pair of Locators, which can be useful for network management purposes as well as for selecting low delay paths. The major disadvantage of RLOC-Probing is in the number of control messages required and the amount of bandwidth used to obtain those benefits, especially if the requirement for failure detection times is very small.
RLOC探测有优点也有缺点。RLOC探测的最大好处是，它可以处理许多故障场景，从而允许ITR确定特定定位器的路径何时可到达或已不可到达，从而提供一种健壮的机制，用于从缓存定位器切换到使用另一定位器。RLOC探测还可以提供一对定位器之间的粗略往返时间（RTT）估计，这对于网络管理目的以及选择低延迟路径非常有用。RLOC探测的主要缺点在于所需的控制消息数量和用于获得这些好处的带宽量，特别是在故障检测时间要求非常小的情况下。
Continued research and testing will attempt to characterize the tradeoffs of failure detection times versus message overhead.
持续的研究和测试将试图描述故障检测时间与消息开销之间的权衡。
A site may be multihomed using two or more ETRs. The hosts and infrastructure within a site will be addressed using one or more EID-Prefixes that are mapped to the RLOCs of the relevant ETRs in the mapping system. One possible failure mode is for an ETR to lose reachability to one or more of the EID-Prefixes within its own site. When this occurs when the ETR sends Map-Replies, it can clear the R-bit associated with its own Locator. And when the ETR is also an ITR, it can clear its Locator-Status-Bit in the encapsulation data header.
一个站点可以使用两个或多个ETR进行多址。站点内的主机和基础设施将使用一个或多个EID前缀进行寻址，这些前缀映射到映射系统中相关ETR的RLOC。一种可能的故障模式是ETR无法访问其自身站点内的一个或多个EID前缀。当ETR发送Map应答时发生这种情况时，它可以清除与其自身定位器关联的R位。当ETR也是ITR时，它可以清除封装数据头中的定位器状态位。
It is recognized that there are no simple solutions to the site partitioning problem because it is hard to know which part of the EID-Prefix range is partitioned and which Locators can reach any sub-ranges of the EID-Prefixes. This problem is under investigation with the expectation that experiments will tell us more. Note that this is not a new problem introduced by the LISP architecture. The problem exists today when a multihomed site uses BGP to advertise its reachability upstream.
众所周知，站点分区问题没有简单的解决方案，因为很难知道EID前缀范围的哪个部分被分区，以及哪些定位器可以到达EID前缀的任何子范围。这个问题正在调查中，希望实验能告诉我们更多。请注意，这不是LISP体系结构引入的新问题。如今，当多宿站点使用BGP向上游宣传其可达性时，问题就存在了。
When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to a requesting ITR, the Locator-Set for the EID-Prefix may contain different Priority values for each locator address. When more than one best Priority Locator exists, the ITR can decide how to load-share traffic against the corresponding Locators.
当ETR在映射回复消息中向请求ITR提供EID到RLOC的映射时，为EID前缀设置的定位器可能包含每个定位器地址的不同优先级值。当存在多个最佳优先级定位器时，ITR可以决定如何针对相应定位器加载共享流量。
The following hash algorithm may be used by an ITR to select a Locator for a packet destined to an EID for the EID-to-RLOC mapping:
ITR可以使用以下散列算法为EID到RLOC映射的目的地为EID的分组选择定位器：
1. Either a source and destination address hash or the traditional 5-tuple hash can be used. The traditional 5-tuple hash includes the source and destination addresses; source and destination TCP, UDP, or Stream Control Transmission Protocol (SCTP) port numbers; and the IP protocol number field or IPv6 next-protocol fields of a packet that a host originates from within a LISP site. When a packet is not a TCP, UDP, or SCTP packet, the source and destination addresses only from the header are used to compute the hash.
1. 可以使用源地址和目标地址哈希或传统的5元组哈希。传统的5元组散列包括源地址和目标地址；源和目标TCP、UDP或流控制传输协议（SCTP）端口号；以及主机在LISP站点内发起的数据包的IP协议编号字段或IPv6下一个协议字段。当数据包不是TCP、UDP或SCTP数据包时，仅使用来自报头的源地址和目标地址来计算哈希。
2. Take the hash value and divide it by the number of Locators stored in the Locator-Set for the EID-to-RLOC mapping.
2. 获取散列值并将其除以存储在用于EID到RLOC映射的定位器集中的定位器数量。
3. The remainder will yield a value of 0 to "number of Locators minus 1". Use the remainder to select the Locator in the Locator-Set.
3. 余数将产生0到“定位器数量减1”的值。使用余数选择定位器集中的定位器。
Note that when a packet is LISP encapsulated, the source port number in the outer UDP header needs to be set. Selecting a hashed value allows core routers that are attached to Link Aggregation Groups (LAGs) to load-split the encapsulated packets across member links of such LAGs. Otherwise, core routers would see a single flow, since packets have a source address of the ITR, for packets that are originated by different EIDs at the source site. A suggested setting for the source port number computed by an ITR is a 5-tuple hash function on the inner header, as described above.
请注意，当数据包被LISP封装时，需要设置外部UDP报头中的源端口号。选择散列值允许连接到链路聚合组（LAG）的核心路由器跨此类LAG的成员链路加载和拆分封装的数据包。否则，对于源站点上由不同EID发起的数据包，核心路由器将看到单个流，因为数据包具有ITR的源地址。ITR计算的源端口号的建议设置是内部报头上的5元组哈希函数，如上所述。
Many core router implementations use a 5-tuple hash to decide how to balance packet load across members of a LAG. The 5-tuple hash includes the source and destination addresses of the packet and the source and destination ports when the protocol number in the packet is TCP or UDP. For this reason, UDP encoding is used for LISP encapsulation.
许多核心路由器实现使用5元组散列来决定如何在LAG成员之间平衡数据包负载。当数据包中的协议号为TCP或UDP时，5元组哈希包括数据包的源地址和目标地址以及源端口和目标端口。因此，UDP编码用于LISP封装。
Since the LISP architecture uses a caching scheme to retrieve and store EID-to-RLOC mappings, the only way an ITR can get a more up-to-date mapping is to re-request the mapping. However, the ITRs do not know when the mappings change, and the ETRs do not keep track of which ITRs requested its mappings. For scalability reasons, we want to maintain this approach but need to provide a way for ETRs to change their mappings and inform the sites that are currently communicating with the ETR site using such mappings.
由于LISP体系结构使用缓存方案来检索和存储EID到RLOC的映射，因此ITR获得最新映射的唯一方法是重新请求映射。但是，ITRs不知道映射何时更改，ETRs也不跟踪哪个ITRs请求其映射。出于可扩展性的原因，我们希望保持这种方法，但需要为ETR提供一种方法来更改其映射，并通知当前正在使用此类映射与ETR站点通信的站点。
When adding a new Locator record in lexicographic order to the end of a Locator-Set, it is easy to update mappings. We assume that new mappings will maintain the same Locator ordering as the old mapping but will just have new Locators appended to the end of the list. So, some ITRs can have a new mapping while other ITRs have only an old mapping that is used until they time out. When an ITR has only an old mapping but detects bits set in the Locator-Status-Bits that correspond to Locators beyond the list it has cached, it simply ignores them. However, this can only happen for locator addresses that are lexicographically greater than the locator addresses in the existing Locator-Set.
当以字典顺序将新的定位器记录添加到定位器集的末尾时，很容易更新映射。我们假设新映射将保持与旧映射相同的定位器顺序，但只将新定位器附加到列表的末尾。因此，一些ITR可以有一个新的映射，而其他ITR只有一个旧的映射，直到它们超时为止。当ITR只有一个旧映射，但检测到定位器状态位中设置的位，这些位对应于它缓存的列表之外的定位器时，它只是忽略它们。但是，这种情况只能发生在按字典顺序大于现有定位器集中定位器地址的定位器地址上。
When a Locator record is inserted in the middle of a Locator-Set, to maintain lexicographic order, the SMR procedure in Section 6.6.2 is used to inform ITRs and PITRs of the new Locator-Status-Bit mappings.
当定位器记录插入定位器集的中间时，为了保持字典顺序，在第63.2节中的SMR程序用于通知ITRs和PITRS新的定位器状态位映射。
When a Locator record is removed from a Locator-Set, ITRs that have the mapping cached will not use the removed Locator because the xTRs will set the Locator-Status-Bit to 0. So, even if the Locator is in the list, it will not be used. For new mapping requests, the xTRs
当从定位器集中删除定位器记录时，缓存映射的ITR将不使用删除的定位器，因为XTR将定位器状态位设置为0。因此，即使定位器在列表中，也不会使用它。对于新的映射请求，XTR
can set the Locator AFI to 0 (indicating an unspecified address), as well as setting the corresponding Locator-Status-Bit to 0. This forces ITRs with old or new mappings to avoid using the removed Locator.
可以将定位器AFI设置为0（表示未指定的地址），并将相应的定位器状态位设置为0。这将强制ITR使用旧的或新的映射，以避免使用已删除的定位器。
If many changes occur to a mapping over a long period of time, one will find empty record slots in the middle of the Locator-Set and new records appended to the Locator-Set. At some point, it would be useful to compact the Locator-Set so the Locator-Status-Bit settings can be efficiently packed.
如果在长时间内发生映射的许多更改，则会在定位器集的中间找到空记录槽，并将新记录附加到定位器集。在某些情况下，压缩定位器集是有用的，这样定位器状态位设置可以有效地打包。
We propose here three approaches for Locator-Set compaction: one operational mechanism and two protocol mechanisms. The operational approach uses a clock sweep method. The protocol approaches use the concept of Solicit-Map-Requests and Map-Versioning.
本文提出了三种定位集压缩方法：一种操作机制和两种协议机制。操作方法使用时钟扫描方法。协议方法使用请求映射请求和映射版本控制的概念。
The clock sweep approach uses planning in advance and the use of count-down TTLs to time out mappings that have already been cached. The default setting for an EID-to-RLOC mapping TTL is 24 hours. So, there is a 24-hour window to time out old mappings. The following clock sweep procedure is used:
时钟扫描方法使用预先规划和倒计时TTL来超时已经缓存的映射。EID到RLOC映射TTL的默认设置为24小时。因此，有一个24小时的窗口来超时旧的映射。使用以下时钟扫描程序：
1. 24 hours before a mapping change is to take effect, a network administrator configures the ETRs at a site to start the clock sweep window.
1. 映射更改生效前24小时，网络管理员在站点配置ETR以启动时钟扫描窗口。
2. During the clock sweep window, ETRs continue to send Map-Reply messages with the current (unchanged) mapping records. The TTL for these mappings is set to 1 hour.
2. 在时钟扫描窗口期间，ETR继续发送带有当前（未更改）映射记录的映射回复消息。这些映射的TTL设置为1小时。
3. 24 hours later, all previous cache entries will have timed out, and any active cache entries will time out within 1 hour. During this 1-hour window, the ETRs continue to send Map-Reply messages with the current (unchanged) mapping records with the TTL set to 1 minute.
3. 24小时后，所有以前的缓存项都将超时，任何活动缓存项都将在1小时内超时。在此1小时窗口内，ETRs继续发送带有当前（未更改）映射记录的映射回复消息，TTL设置为1分钟。
4. At the end of the 1-hour window, the ETRs will send Map-Reply messages with the new (changed) mapping records. So, any active caches can get the new mapping contents right away if not cached, or in 1 minute if they had the mapping cached. The new mappings are cached with a TTL equal to the TTL in the Map-Reply.
4. 在1小时窗口结束时，ETRs将发送带有新（更改）映射记录的映射回复消息。因此，如果没有缓存，任何活动缓存都可以立即获取新的映射内容，如果缓存了映射，则可以在1分钟内获取。缓存新映射时，使用与映射回复中的TTL相同的TTL。
Soliciting a Map-Request is a selective way for ETRs, at the site where mappings change, to control the rate they receive requests for Map-Reply messages. SMRs are also used to tell remote ITRs to update the mappings they have cached.
请求Map请求是ETR在映射更改的站点控制接收Map回复消息请求的速率的一种选择性方法。SMR还用于通知远程ITR更新它们缓存的映射。
Since the ETRs don't keep track of remote ITRs that have cached their mappings, they do not know which ITRs need to have their mappings updated. As a result, an ETR will solicit Map-Requests (called an SMR message) from those sites to which it has been sending encapsulated data for the last minute. In particular, an ETR will send an SMR to an ITR to which it has recently sent encapsulated data.
由于ETR不跟踪缓存了映射的远程ITR，因此他们不知道哪些ITR需要更新映射。因此，ETR将从其在最后一分钟向其发送封装数据的站点请求Map请求（称为SMR消息）。特别是，ETR将向最近向其发送封装数据的ITR发送SMR。
An SMR message is simply a bit set in a Map-Request message. An ITR or PITR will send a Map-Request when they receive an SMR message. Both the SMR sender and the Map-Request responder MUST rate-limit these messages. Rate-limiting can be implemented as a global rate-limiter or one rate-limiter per SMR destination.
SMR消息只是映射请求消息中的一个位集。ITR或PITR在收到SMR消息时将发送Map请求。SMR发送方和映射请求响应方都必须对这些消息进行速率限制。速率限制可以实现为全局速率限制器或每个SMR目的地一个速率限制器。
The following procedure shows how an SMR exchange occurs when a site is doing Locator-Set compaction for an EID-to-RLOC mapping:
以下过程显示了当站点为EID到RLOC映射执行定位器集压缩时，SMR交换是如何发生的：
1. When the database mappings in an ETR change, the ETRs at the site begin to send Map-Requests with the SMR bit set for each Locator in each Map-Cache entry the ETR caches.
1. 当ETR中的数据库映射发生更改时，站点上的ETR开始发送映射请求，并为ETR缓存的每个映射缓存条目中的每个定位器设置SMR位。
2. A remote ITR that receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message or to the mapping database system. A newly allocated random nonce is selected, and the EID-Prefix used is the one copied from the SMR message. If the source Locator is the only Locator in the cached Locator-Set, the remote ITR SHOULD send a Map-Request to the database mapping system just in case the single Locator has changed and may no longer be reachable to accept the Map-Request.
2. 接收SMR消息的远程ITR将计划向SMR消息的源定位器地址或映射数据库系统发送映射请求消息。选择新分配的随机nonce，使用的EID前缀是从SMR消息复制的前缀。如果源定位器是缓存定位器集中的唯一定位器，则远程ITR应向数据库映射系统发送映射请求，以防单个定位器已更改，并且可能无法再访问以接受映射请求。
3. The remote ITR MUST rate-limit the Map-Request until it gets a Map-Reply while continuing to use the cached mapping. When Map-Versioning as described in Section 6.6.3 is used, an SMR sender can detect if an ITR is using the most up-to-date database mapping.
3. 远程ITR必须对映射请求进行速率限制，直到它在继续使用缓存映射的同时获得映射回复。当使用第6.6.3节所述的映射版本控制时，SMR发送方可以检测ITR是否使用最新的数据库映射。
4. The ETRs at the site with the changed mapping will reply to the Map-Request with a Map-Reply message that has a nonce from the SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate-limited. This is important to avoid Map-Reply implosion.
4. 具有更改映射的站点上的ETR将使用映射回复消息回复映射请求，该消息具有来自SMR调用映射请求的nonce。映射回复消息应为速率限制。这对于避免映射回复内爆非常重要。
5. The ETRs at the site with the changed mapping record the fact that the site that sent the Map-Request has received the new mapping data in the Map-Cache entry for the remote site so the Locator-Status-Bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending SMR messages.
5. 具有更改映射的站点上的ETR记录发送映射请求的站点已在远程站点的映射缓存条目中接收到新映射数据的事实，因此定位器状态位反映了发送到远程站点的数据包的新映射。ETR随后停止发送SMR消息。
Experimentation is in progress to determine the appropriate rate-limit parameters.
目前正在进行实验，以确定适当的速率限制参数。
For security reasons, an ITR MUST NOT process unsolicited Map-Replies. To avoid Map-Cache entry corruption by a third party, a sender of an SMR-based Map-Request MUST be verified. If an ITR receives an SMR-based Map-Request and the source is not in the Locator-Set for the stored Map-Cache entry, then the responding Map-Request MUST be sent with an EID destination to the mapping database system. Since the mapping database system is a more secure way to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data.
出于安全原因，ITR不得处理未经请求的Map回复。为了避免第三方损坏映射缓存条目，必须验证基于SMR的映射请求的发送方。如果ITR接收到基于SMR的映射请求，且源不在存储的映射缓存项的定位器集中，则必须将响应的映射请求与EID目标一起发送到映射数据库系统。由于地图数据库系统是访问权威ETR的更安全的方法，因此它将向地图数据的权威来源发送地图请求。
When an ITR receives an SMR-based Map-Request for which it does not have a cached mapping for the EID in the SMR message, it MAY not send an SMR-invoked Map-Request. This scenario can occur when an ETR sends SMR messages to all Locators in the Locator-Set it has stored in its map-cache but the remote ITRs that receive the SMR may not be sending packets to the site. There is no point in updating the ITRs until they need to send, in which case they will send Map-Requests to obtain a Map-Cache entry.
当ITR接收到SMR消息中没有EID缓存映射的基于SMR的映射请求时，它可能不会发送SMR调用的映射请求。当ETR向其地图缓存中存储的定位器集中的所有定位器发送SMR消息，但接收SMR的远程ITR可能未向站点发送数据包时，可能会出现这种情况。在需要发送之前，更新ITR是没有意义的，在这种情况下，ITR将发送Map请求以获取Map缓存条目。
When there is unidirectional packet flow between an ITR and ETR, and the EID-to-RLOC mappings change on the ETR, it needs to inform the ITR so encapsulation to a removed Locator can stop and can instead be started to a new Locator in the Locator-Set.
当ITR和ETR之间存在单向数据包流，且ETR上的EID到RLOC映射发生变化时，它需要通知ITR，以便停止对已移除定位器的封装，而可以开始对定位器集中的新定位器进行封装。
An ETR, when it sends Map-Reply messages, conveys its own Map-Version Number. This is known as the Destination Map-Version Number. ITRs include the Destination Map-Version Number in packets they encapsulate to the site. When an ETR decapsulates a packet and detects that the Destination Map-Version Number is less than the current version for its mapping, the SMR procedure described in Section 6.6.2 occurs.
ETR在发送Map回复消息时，会传递其自己的Map版本号。这称为目标地图版本号。ITR在封装到站点的数据包中包含目标地图版本号。当ETR解除对数据包的封装并检测到目标映射版本号小于其映射的当前版本时，将执行第6.6.2节中描述的SMR程序。
An ITR, when it encapsulates packets to ETRs, can convey its own Map-Version Number. This is known as the Source Map-Version Number. When an ETR decapsulates a packet and detects that the Source Map-Version Number is greater than the last Map-Version Number sent in a Map-Reply from the ITR's site, the ETR will send a Map-Request to one of the ETRs for the source site.
当ITR将数据包封装到ETR时，它可以传递自己的Map版本号。这称为源映射版本号。当ETR解除对数据包的封装并检测到源地图版本号大于ITR站点在地图回复中发送的最后一个地图版本号时，ETR将向其中一个ETR发送源站点的地图请求。
A Map-Version Number is used as a sequence number per EID-Prefix, so values that are greater are considered to be more recent. A value of 0 for the Source Map-Version Number or the Destination Map-Version Number conveys no versioning information, and an ITR does no comparison with previously received Map-Version Numbers.
映射版本号用作每个EID前缀的序列号，因此较大的值被视为较新的值。源地图版本号或目标地图版本号的值为0时，不会传递版本控制信息，并且ITR不会与以前收到的地图版本号进行比较。
A Map-Version Number can be included in Map-Register messages as well. This is a good way for the Map-Server to assure that all ETRs for a site registering to it will be synchronized according to Map-Version Number.
地图版本号也可以包含在地图注册信息中。对于地图服务器来说，这是一种很好的方法，可以确保注册到地图服务器的站点的所有ETR都将根据地图版本号进行同步。
See [RFC6834] for a more detailed analysis and description of Database Map-Versioning.
有关数据库映射版本控制的更详细分析和说明，请参见[RFC6834]。
LISP is designed to be very "hardware-based forwarding friendly". A few implementation techniques can be used to incrementally implement LISP:
LISP的设计非常“基于硬件的转发友好”。一些实现技术可用于增量实现LISP：
o When a tunnel-encapsulated packet is received by an ETR, the outer destination address may not be the address of the router. This makes it challenging for the control plane to get packets from the hardware. This may be mitigated by creating special Forwarding Information Base (FIB) entries for the EID-Prefixes of EIDs served by the ETR (those for which the router provides an RLOC translation). These FIB entries are marked with a flag indicating that control-plane processing should be performed. The forwarding logic of testing for particular IP protocol number values is not necessary. There are a few proven cases where no changes to existing deployed hardware were needed to support the LISP data-plane.
o 当ETR接收到隧道封装的数据包时，外部目标地址可能不是路由器的地址。这使得控制平面很难从硬件获取数据包。这可以通过为ETR服务的EID（路由器提供RLOC转换的EID）的EID前缀创建特殊转发信息库（FIB）条目来缓解。这些FIB条目用一个标志标记，指示应执行控制平面处理。不需要测试特定IP协议编号值的转发逻辑。有一些经过验证的案例表明，支持LISP数据平面不需要对现有部署的硬件进行任何更改。
o On an ITR, prepending a new IP header consists of adding more octets to a MAC rewrite string and prepending the string as part of the outgoing encapsulation procedure. Routers that support Generic Routing Encapsulation (GRE) tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already support this action.
o 在ITR上，预编新IP头包括向MAC重写字符串添加更多的八位字节，并作为传出封装过程的一部分预编该字符串。支持通用路由封装（GRE）隧道[RFC2784]或6to4隧道[RFC3056]的路由器可能已经支持此操作。
o A packet's source address or interface the packet was received on can be used to select VRF (Virtual Routing/Forwarding). The VRF's routing table can be used to find EID-to-RLOC mappings.
o 数据包的源地址或接收数据包的接口可用于选择VRF（虚拟路由/转发）。VRF的路由表可用于查找EID到RLOC的映射。
For performance issues related to map-cache management, see Section 12.
有关映射缓存管理的性能问题，请参阅第12节。
This section will explore how and where ITRs and ETRs can be deployed and will discuss the pros and cons of each deployment scenario. For a more detailed deployment recommendation, refer to [LISP-DEPLOY].
本节将探讨如何以及在何处部署ITR和ETR，并将讨论每个部署场景的优缺点。有关更详细的部署建议，请参阅[LISP-DEPLOY]。
There are two basic deployment tradeoffs to consider: centralized versus distributed caches; and flat, Recursive, or Re-encapsulating Tunneling. When deciding on centralized versus distributed caching, the following issues should be considered:
有两个基本的部署权衡需要考虑：集中式缓存与分布式缓存；以及平坦、递归或重新封装隧道。在决定集中缓存还是分布式缓存时，应考虑以下问题：
o Are the Tunnel Routers spread out so that the caches are spread across all the memories of each router? A centralized cache is when an ITR keeps a cache for all the EIDs it is encapsulating to. The packet takes a direct path to the destination Locator. A distributed cache is when an ITR needs help from other re-encapsulating routers because it does not store all the cache entries for the EIDs it is encapsulating to. So, the packet takes a path through re-encapsulating routers that have a different set of cache entries.
o 隧道路由器是否分散，以便缓存分布在每个路由器的所有内存中？集中式缓存是指ITR为其封装到的所有EID保留一个缓存。数据包采用直接路径到达目的地定位器。分布式缓存是指ITR需要其他重新封装路由器的帮助时，因为它不存储它要封装到的EID的所有缓存项。因此，数据包通过具有不同缓存项集的重新封装路由器获得路径。
o Should management "touch points" be minimized by only choosing a few Tunnel Routers, just enough for redundancy?
o 管理“接触点”是否应该通过只选择几个隧道路由器来最小化，只需要冗余就可以了？
o In general, using more ITRs doesn't increase management load, since caches are built and stored dynamically. On the other hand, using more ETRs does require more management, since EID-Prefix-to-RLOC mappings need to be explicitly configured.
o 通常，使用更多ITR不会增加管理负载，因为缓存是动态构建和存储的。另一方面，使用更多ETR确实需要更多的管理，因为需要显式配置EID前缀到RLOC的映射。
When deciding on flat, Recursive, or Re-encapsulating Tunneling, the following issues should be considered:
在决定平坦、递归或重新封装隧道时，应考虑以下问题：
o Flat tunneling implements a single tunnel between the source site and destination site. This generally offers better paths between sources and destinations with a single tunnel path.
o 平面隧道在源站点和目标站点之间实现单个隧道。这通常使用单个隧道路径在源和目标之间提供更好的路径。
o Recursive Tunneling is when tunneled traffic is again further encapsulated in another tunnel, either to implement VPNs or to perform Traffic Engineering. When doing VPN-based tunneling, the site has some control, since the site is prepending a new tunnel header. In the case of TE-based tunneling, the site may have
o 递归隧道是指隧道传输的流量再次封装在另一个隧道中，以实现VPN或执行流量工程。在进行基于VPN的隧道时，站点具有一定的控制权，因为站点正在预先设置一个新的隧道头。在基于TE的隧洞工程中，现场可能有
control if it is prepending a new tunnel header, but if the site's ISP is doing the TE, then the site has no control. Recursive Tunneling generally will result in suboptimal paths but with the benefit of steering traffic to parts of the network that have more resources available.
控制是否正在预处理新的隧道标头，但如果站点的ISP正在执行TE，则站点没有控制权。递归隧道通常会导致次优路径，但有利于将流量引导到具有更多可用资源的网络部分。
o The technique of re-encapsulation ensures that packets only require one tunnel header. So, if a packet needs to be re-routed, it is first decapsulated by the ETR and then re-encapsulated with a new tunnel header using a new RLOC.
o 重新封装技术确保数据包只需要一个隧道头。因此，如果数据包需要重新路由，它首先由ETR解除封装，然后使用新的RLOC使用新的隧道报头重新封装。
The next sub-sections will examine where Tunnel Routers can reside in the network.
下一小节将研究隧道路由器在网络中的位置。
By locating Tunnel Routers close to hosts, the EID-Prefix set is at the granularity of an IP subnet. So, at the expense of more EID-Prefix-to-RLOC sets for the site, the caches in each Tunnel Router can remain relatively small. But caches always depend on the number of non-aggregated EID destination flows active through these Tunnel Routers.
通过将隧道路由器定位在主机附近，EID前缀集的粒度与IP子网相同。因此，以站点的更多EID前缀到RLOC集为代价，每个隧道路由器中的缓存可以保持相对较小。但缓存始终取决于通过这些隧道路由器的非聚合EID目标流的数量。
With more Tunnel Routers doing encapsulation, the increase in control traffic grows as well: since the EID granularity is greater, more Map-Requests and Map-Replies are traveling between more routers.
随着越来越多的隧道路由器进行封装，控制流量的增加也随之增加：由于EID粒度更大，更多的Map请求和Map回复在更多的路由器之间传输。
The advantage of placing the caches and databases at these stub routers is that the products deployed in this part of the network have better price-memory ratios than their core router counterparts. Memory is typically less expensive in these devices, and fewer routes are stored (only IGP routes). These devices tend to have excess capacity, both for forwarding and routing states.
在这些存根路由器上放置缓存和数据库的优势在于，部署在网络这一部分的产品比其核心路由器具有更好的价格内存比。在这些设备中，内存通常较便宜，存储的路由也较少（仅IGP路由）。对于转发和路由状态，这些设备往往具有过剩的容量。
LISP functionality can also be deployed in edge switches. These devices generally have layer-2 ports facing hosts and layer-3 ports facing the Internet. Spare capacity is also often available in these devices.
LISP功能也可以部署在边缘交换机中。这些设备通常具有面向主机的第2层端口和面向Internet的第3层端口。这些设备中通常也有备用容量。
Using Customer Edge (CE) routers for tunnel endpoints allows the EID space associated with a site to be reachable via a small set of RLOCs assigned to the CE routers for that site. This is the default behavior envisioned in the rest of this specification.
将客户边缘（CE）路由器用于隧道端点允许通过分配给该站点CE路由器的一小组RLOC来访问与站点相关联的EID空间。这是本规范其余部分中设想的默认行为。
This offers the opposite benefit of the first-hop/last-hop Tunnel Router scenario: the number of mapping entries and network management touch points is reduced, allowing better scaling.
这提供了与第一跳/最后一跳隧道路由器方案相反的好处：减少了映射条目和网络管理接触点的数量，允许更好的扩展。
One disadvantage is that fewer network resources are used to reach host endpoints, thereby centralizing the point-of-failure domain and creating network choke points at the CE router.
一个缺点是，用于到达主机端点的网络资源较少，因此集中了故障点域，并在CE路由器上创建了网络阻塞点。
Note that more than one CE router at a site can be configured with the same IP address. In this case, an RLOC is an anycast address. This allows resilience between the CE routers. That is, if a CE router fails, traffic is automatically routed to the other routers using the same anycast address. However, this comes with the disadvantage where the site cannot control the entrance point when the anycast route is advertised out from all border routers. Another disadvantage of using anycast Locators is the limited advertisement scope of /32 (or /128 for IPv6) routes.
请注意，一个站点上的多个CE路由器可以配置相同的IP地址。在这种情况下，RLOC是选播地址。这允许CE路由器之间具有弹性。也就是说，如果一个CE路由器出现故障，流量将自动路由到使用相同选播地址的其他路由器。然而，这带来了一个缺点，即当从所有边界路由器公布选播路由时，站点无法控制入口点。使用选播定位器的另一个缺点是/32（或IPv6的/128）路由的播发范围有限。
The use of ISP PE routers as tunnel endpoint routers is not the typical deployment scenario envisioned in this specification. This section attempts to capture some of the reasoning behind this preference for implementing LISP on CE routers.
使用ISP PE路由器作为隧道端点路由器不是本规范中设想的典型部署场景。本节试图抓住在CE路由器上实现LISP这一偏好背后的一些原因。
The use of ISP PE routers as tunnel endpoint routers gives an ISP, rather than a site, control over the location of the egress tunnel endpoints. That is, the ISP can decide whether the tunnel endpoints are in the destination site (in either CE routers or last-hop routers within a site) or at other PE edges. The advantage of this case is that two tunnel headers can be avoided. By having the PE be the first router on the path to encapsulate, it can choose a TE path first, and the ETR can decapsulate and re-encapsulate for a tunnel to the destination end site.
将ISP PE路由器用作隧道端点路由器使ISP而不是站点能够控制出口隧道端点的位置。也就是说，ISP可以决定隧道端点是在目标站点（在站点内的CE路由器或最后一跳路由器中）还是在其他PE边缘。这种情况的优点是可以避免两个隧道头。通过让PE成为要封装的路径上的第一个路由器，它可以首先选择TE路径，ETR可以解除封装并重新封装到目标端站点的隧道。
An obvious disadvantage is that the end site has no control over where its packets flow or over the RLOCs used. Other disadvantages include difficulty in synchronizing path liveness updates between CE and PE routers.
一个明显的缺点是，终端站点无法控制其数据包的流向或RLOC的使用。其他缺点包括难以在CE和PE路由器之间同步路径活跃度更新。
As mentioned in earlier sections, a combination of these scenarios is possible at the expense of extra packet header overhead; if both site and provider want control, then Recursive or Re-encapsulating Tunnels are used.
如前几节所述，这些场景的组合是可能的，代价是额外的分组报头开销；如果站点和提供者都需要控制，则使用递归或重新封装隧道。
LISP routers can be deployed behind Network Address Translator (NAT) devices to provide the same set of packet services hosts have today when they are addressed out of private address space.
LISP路由器可以部署在网络地址转换器（NAT）设备后面，以提供与主机今天在专用地址空间之外寻址时相同的数据包服务集。
It is important to note that a locator address in any LISP control message MUST be a globally routable address and therefore SHOULD NOT contain [RFC1918] addresses. If a LISP router is configured with private addresses, they MUST be used only in the outer IP header so the NAT device can translate properly. Otherwise, EID addresses MUST be translated before encapsulation is performed. Both NAT translation and LISP encapsulation functions could be co-located in the same device.
需要注意的是，任何LISP控制消息中的定位器地址必须是全局可路由地址，因此不应包含[RFC1918]地址。如果LISP路由器配置了专用地址，则必须仅在外部IP报头中使用这些地址，以便NAT设备能够正确转换。否则，必须在执行封装之前转换EID地址。NAT转换和LISP封装功能都可以位于同一设备中。
More details on LISP address translation can be found in [RFC6832].
有关LISP地址转换的更多详细信息，请参见[RFC6832]。
When a LISP site is using two ITRs for redundancy, the failure of one ITR will likely shift outbound traffic to the second. This second ITR's cache may not be populated with the same EID-to-RLOC mapping entries as the first. If this second ITR does not have these mappings, traffic will be dropped while the mappings are retrieved from the mapping system. The retrieval of these messages may increase the load of requests being sent into the mapping system. Deployment and experimentation will determine whether this issue requires more attention.
当LISP站点使用两个ITR进行冗余时，一个ITR的故障可能会将出站流量转移到第二个。第二个ITR的缓存可能不会使用与第一个相同的EID到RLOC映射项填充。如果第二个ITR没有这些映射，则在从映射系统检索映射时，将丢弃通信量。检索这些消息可能会增加发送到映射系统的请求的负载。部署和实验将决定是否需要更多关注此问题。
When a source host in a LISP site initiates a traceroute to a destination host in another LISP site, it is highly desirable for it to see the entire path. Since packets are encapsulated from the ITR to the ETR, the hop across the tunnel could be viewed as a single hop. However, LISP traceroute will provide the entire path so the user can see 3 distinct segments of the path from a source LISP host to a destination LISP host:
当LISP站点中的源主机启动到另一个LISP站点中的目标主机的跟踪路由时，它非常希望看到整个路径。由于数据包是从ITR封装到ETR的，因此可以将隧道中的跳视为单个跳。但是，LISP traceroute将提供整个路径，因此用户可以看到从源LISP主机到目标LISP主机的3个不同的路径段：
Segment 1 (in source LISP site based on EIDs):
段1（基于EID的源LISP站点中）：
source host ---> first hop ... next hop ---> ITR
source host ---> first hop ... next hop ---> ITR
Segment 2 (in the core network based on RLOCs):
段2（在基于RLOCs的核心网络中）：
ITR ---> next hop ... next hop ---> ETR
ITR ---> next hop ... next hop ---> ETR
Segment 3 (in the destination LISP site based on EIDs):
段3（在基于EID的目标LISP站点中）：
ETR ---> next hop ... last hop ---> destination host
ETR ---> next hop ... last hop ---> destination host
For segment 1 of the path, ICMP Time Exceeded messages are returned in the normal manner as they are today. The ITR performs a TTL decrement and tests for 0 before encapsulating. Therefore, the ITR's hop is seen by the traceroute source as having an EID address (the address of the site-facing interface).
对于路径的第1段，ICMP超时消息将以今天的正常方式返回。ITR执行TTL递减，并在封装前测试0。因此，跟踪路由源将ITR的跃点视为具有EID地址（面向站点的接口的地址）。
For segment 2 of the path, ICMP Time Exceeded messages are returned to the ITR because the TTL decrement to 0 is done on the outer header, so the destinations of the ICMP messages are the ITR RLOC address and the source RLOC address of the encapsulated traceroute packet. The ITR looks inside of the ICMP payload to inspect the traceroute source so it can return the ICMP message to the address of the traceroute client and also retain the core router IP address in the ICMP message. This is so the traceroute client can display the core router address (the RLOC address) in the traceroute output. The ETR returns its RLOC address and responds to the TTL decrement to 0, as the previous core routers did.
对于路径的段2，ICMP超时消息返回到ITR，因为TTL减量为0是在外部报头上完成的，因此ICMP消息的目的地是封装的跟踪路由数据包的ITR RLOC地址和源RLOC地址。ITR查看ICMP有效负载的内部以检查跟踪路由源，以便将ICMP消息返回到跟踪路由客户端的地址，并在ICMP消息中保留核心路由器IP地址。这样跟踪路由客户端就可以在跟踪路由输出中显示核心路由器地址（RLOC地址）。ETR返回其RLOC地址并响应TTL减量为0，就像以前的核心路由器一样。
For segment 3, the next-hop router downstream from the ETR will be decrementing the TTL for the packet that was encapsulated, sent into the core, decapsulated by the ETR, and forwarded because it isn't the final destination. If the TTL is decremented to 0, any router on the path to the destination of the traceroute, including the next-hop router or destination, will send an ICMP Time Exceeded message to the source EID of the traceroute client. The ICMP message will be encapsulated by the local ITR and sent back to the ETR in the originated traceroute source site, where the packet will be delivered to the host.
对于段3，ETR下游的下一跳路由器将减少封装、发送到核心、由ETR解除封装并转发的数据包的TTL，因为它不是最终目的地。如果TTL递减为0，则到跟踪路由目的地的路径上的任何路由器（包括下一跳路由器或目的地）都将向跟踪路由客户端的源EID发送ICMP超时消息。ICMP消息将由本地ITR封装，并发送回原始跟踪路由源站点中的ETR，在那里数据包将被传送到主机。
IPv6 traceroute follows the procedure described above, since the entire traceroute data packet is included in the ICMP Time Exceeded message payload. Therefore, only the ITR needs to pay special attention to forwarding ICMP messages back to the traceroute source.
IPv6跟踪路由遵循上述过程，因为整个跟踪路由数据包包含在ICMP超时消息有效负载中。因此，只有ITR需要特别注意将ICMP消息转发回跟踪路由源。
For IPv4 traceroute, we cannot follow the above procedure, since IPv4 ICMP Time Exceeded messages only include the invoking IP header and 8 octets that follow the IP header. Therefore, when a core router sends an IPv4 Time Exceeded message to an ITR, all the ITR has in the ICMP payload is the encapsulated header it prepended, followed by a UDP header. The original invoking IP header, and therefore the identity of the traceroute source, is lost.
对于IPv4跟踪路由，我们无法遵循上述过程，因为IPv4 ICMP超时消息仅包括调用IP头和IP头后面的8个八位字节。因此，当核心路由器向ITR发送IPv4超时消息时，ITR在ICMP有效负载中的所有内容都是它预先封装的头，后面是UDP头。原始的调用IP报头以及跟踪路由源的标识丢失。
The solution we propose to solve this problem is to cache traceroute IPv4 headers in the ITR and to match them up with corresponding IPv4 Time Exceeded messages received from core routers and the ETR. The ITR will use a circular buffer for caching the IPv4 and UDP headers of traceroute packets. It will select a 16-bit number as a key to find them later when the IPv4 Time Exceeded messages are received. When an ITR encapsulates an IPv4 traceroute packet, it will use the 16-bit number as the UDP source port in the encapsulating header. When the ICMP Time Exceeded message is returned to the ITR, the UDP header of the encapsulating header is present in the ICMP payload, thereby allowing the ITR to find the cached headers for the traceroute source. The ITR puts the cached headers in the payload and sends the ICMP Time Exceeded message to the traceroute source retaining the source address of the original ICMP Time Exceeded message (a core router or the ETR of the site of the traceroute destination).
我们提出的解决方案是在ITR中缓存跟踪路由IPv4报头，并将其与从核心路由器和ETR接收的相应IPv4超时消息相匹配。ITR将使用循环缓冲区缓存跟踪路由数据包的IPv4和UDP头。它将选择一个16位数字作为密钥，以便在稍后收到IPv4超时消息时查找它们。当ITR封装IPv4跟踪路由数据包时，它将在封装头中将16位数字用作UDP源端口。当ICMP Time EXCENDED消息返回到ITR时，封装头的UDP头出现在ICMP有效负载中，从而允许ITR查找跟踪路由源的缓存头。ITR将缓存的头放入有效负载中，并将ICMP超时消息发送到跟踪路由源，该跟踪路由源保留原始ICMP超时消息的源地址（核心路由器或跟踪路由目标站点的ETR）。
The signature of a traceroute packet comes in two forms. The first form is encoded as a UDP message where the destination port is inspected for a range of values. The second form is encoded as an ICMP message where the IP identification field is inspected for a well-known value.
跟踪路由数据包的签名有两种形式。第一种形式被编码为UDP消息，其中检查目标端口的值范围。第二种形式编码为ICMP消息，其中检查IP标识字段是否存在已知值。
When either an IPv4 traceroute or IPv6 traceroute is originated and the ITR encapsulates it in the other address family header, one cannot get all 3 segments of the traceroute. Segment 2 of the traceroute cannot be conveyed to the traceroute source, since it is expecting addresses from intermediate hops in the same address format for the type of traceroute it originated. Therefore, in this case, segment 2 will make the tunnel look like one hop. All the ITR has to do to make this work is to not copy the inner TTL to the outer, encapsulating header's TTL when a traceroute packet is encapsulated using an RLOC from a different address family. This will cause no TTL decrement to 0 to occur in core routers between the ITR and ETR.
当IPv4跟踪路由或IPv6跟踪路由发起且ITR将其封装在其他地址族标头中时，无法获取跟踪路由的所有3段。无法将跟踪路由的段2传送到跟踪路由源，因为它期望来自中间跃点的地址与它发起的跟踪路由类型的地址格式相同。因此，在这种情况下，段2将使隧道看起来像一个跳跃。ITR所要做的就是，当使用来自不同地址族的RLOC封装跟踪路由数据包时，不要将内部TTL复制到外部，封装报头的TTL。这将导致ITR和ETR之间的核心路由器中不会出现TTL递减为0的情况。
There are several kinds of mobility, of which only some might be of concern to LISP. Essentially, they are as follows.
有几种类型的移动性，其中只有一些可能与LISP有关。基本上，它们如下所示。
A site wishes to change its attachment points to the Internet, and its LISP Tunnel Routers will have new RLOCs when it changes upstream providers. Changes in EID-to-RLOC mappings for sites are expected to be handled by configuration, outside of LISP.
一个站点希望更改其与Internet的连接点，当它更改上游提供商时，其LISP隧道路由器将具有新的RLOC。站点的EID到RLOC映射的更改预计将由配置在LISP之外处理。
An individual endpoint wishes to move but is not concerned about maintaining session continuity. Renumbering is involved. LISP can help with the issues surrounding renumbering [RFC4192] [LISA96] by decoupling the address space used by a site from the address spaces used by its ISPs [RFC4984].
单个端点希望移动，但不关心保持会话连续性。需要重新编号。LISP通过将站点使用的地址空间与其ISP使用的地址空间分离[RFC4984]，可以帮助解决重新编号[RFC4192][LISA96]的问题。
Fast endpoint mobility occurs when an endpoint moves relatively rapidly, changing its IP-layer network attachment point. Maintenance of session continuity is a goal. This is where the Mobile IPv4 [RFC5944] and Mobile IPv6 [RFC6275] [RFC4866] mechanisms are used and primarily where interactions with LISP need to be explored.
当端点移动相对较快时，会发生快速端点移动，从而改变其IP层网络连接点。保持会话连续性是一个目标。这是使用移动IPv4[RFC5944]和移动IPv6[RFC6275][RFC4866]机制的地方，主要是需要探索与LISP的交互。
The problem is that as an endpoint moves, it may require changes to the mapping between its EID and a set of RLOCs for its new network location. When this is added to the overhead of Mobile IP binding updates, some packets might be delayed or dropped.
问题在于，随着端点的移动，它可能需要更改其EID和一组RLOC之间的映射，以确定其新的网络位置。当这被添加到移动IP绑定更新的开销中时，一些数据包可能会被延迟或丢弃。
In IPv4 mobility, when an endpoint is away from home, packets to it are encapsulated and forwarded via a home agent that resides in the home area the endpoint's address belongs to. The home agent will encapsulate and forward packets either directly to the endpoint or to a foreign agent that resides where the endpoint has moved to. Packets from the endpoint may be sent directly to the correspondent node, may be sent via the foreign agent, or may be reverse-tunneled back to the home agent for delivery to the mobile node. As the mobile node's EID or available RLOC changes, LISP EID-to-RLOC
在IPv4移动性中，当一个端点离家时，到它的数据包被封装并通过驻留在该端点地址所属的归属区域中的归属代理转发。归属代理将封装数据包，并将其直接转发到端点，或转发到端点移动到的外部代理。来自端点的分组可以直接发送到对应节点，可以经由外部代理发送，或者可以反向隧道返回到归属代理以交付到移动节点。随着移动节点的EID或可用RLOC的更改，LISP EID将更改为RLOC
mappings are required for communication between the mobile node and the home agent, whether via the foreign agent or not. As a mobile endpoint changes networks, up to three LISP mapping changes may be required:
无论是否通过外部代理，移动节点和归属代理之间的通信都需要映射。随着移动端点更改网络，可能需要最多三个LISP映射更改：
o The mobile node moves from an old location to a new visited network location and notifies its home agent that it has done so. The Mobile IPv4 control packets the mobile node sends pass through one of the new visited network's ITRs, which needs an EID-to-RLOC mapping for the home agent.
o 移动节点从旧位置移动到新访问的网络位置，并通知其归属代理它已经这样做。移动节点发送的移动IPv4控制数据包通过一个新访问的网络的ITR，该ITR需要归属代理的EID到RLOC映射。
o The home agent might not have the EID-to-RLOC mappings for the mobile node's "care-of" address or its foreign agent in the new visited network, in which case it will need to acquire them.
o 归属代理可能没有新访问网络中移动节点的“转交”地址或其外部代理的EID到RLOC映射，在这种情况下，它将需要获取它们。
o When packets are sent directly to the correspondent node, it may be that no traffic has been sent from the new visited network to the correspondent node's network, and the new visited network's ITR will need to obtain an EID-to-RLOC mapping for the correspondent node's site.
o 当分组被直接发送到对应节点时，可能没有从新访问的网络向对应节点的网络发送通信量，并且新访问的网络的ITR将需要获得对应节点站点的EID到RLOC映射。
In addition, if the IPv4 endpoint is sending packets from the new visited network using its original EID, then LISP will need to perform a route-returnability check on the new EID-to-RLOC mapping for that EID.
此外，如果IPv4端点使用其原始EID从新访问的网络发送数据包，则LISP需要对该EID的新EID到RLOC映射执行路由可返回性检查。
In IPv6 mobility, packets can flow directly between the mobile node and the correspondent node in either direction. The mobile node uses its "care-of" address (EID). In this case, the route-returnability check would not be needed but one more LISP mapping lookup may be required instead:
在IPv6移动中，数据包可以在移动节点和对应节点之间以任意方向直接流动。移动节点使用其“转交”地址（EID）。在这种情况下，不需要进行路线可返回性检查，但可能需要多进行一次LISP映射查找：
o As above, three mapping changes may be needed for the mobile node to communicate with its home agent and to send packets to the correspondent node.
o 如上所述，移动节点可能需要三个映射更改来与其归属代理通信并向对应节点发送分组。
o In addition, another mapping will be needed in the correspondent node's ITR, in order for the correspondent node to send packets to the mobile node's "care-of" address (EID) at the new network location.
o 此外，对应节点的ITR中将需要另一个映射，以便对应节点将分组发送到新网络位置处移动节点的“转交”地址（EID）。
When both endpoints are mobile, the number of potential mapping lookups increases accordingly.
当两个端点都是移动的时，潜在映射查找的数量相应增加。
As a mobile node moves, there are not only mobility state changes in the mobile node, correspondent node, and home agent, but also state changes in the ITRs and ETRs for at least some EID-Prefixes.
当移动节点移动时，不仅移动节点、对应节点和归属代理中的移动状态发生变化，而且ITRs和ETRs中至少有一些EID前缀的状态发生变化。
The goal is to support rapid adaptation, with little delay or packet loss for the entire system. Also, IP mobility can be modified to require fewer mapping changes. In order to increase overall system performance, there may be a need to reduce the optimization of one area in order to place fewer demands on another.
目标是支持快速适应，整个系统几乎没有延迟或数据包丢失。此外，可以修改IP移动性以减少映射更改。为了提高整体系统性能，可能需要减少一个区域的优化，以减少对另一个区域的需求。
In LISP, one possibility is to "glean" information. When a packet arrives, the ETR could examine the EID-to-RLOC mapping and use that mapping for all outgoing traffic to that EID. It can do this after performing a route-returnability check, to ensure that the new network location does have an internal route to that endpoint. However, this does not cover the case where an ITR (the node assigned the RLOC) at the mobile-node location has been compromised.
在LISP中，一种可能是“收集”信息。当数据包到达时，ETR可以检查EID到RLOC的映射，并将该映射用于到该EID的所有传出流量。它可以在执行路由可返回性检查后执行此操作，以确保新网络位置确实具有到该端点的内部路由。然而，这不包括移动节点位置处的ITR（分配了RLOC的节点）被破坏的情况。
Mobile IP packet exchange is designed for an environment in which all routing information is disseminated before packets can be forwarded. In order to allow the Internet to grow to support expected future use, we are moving to an environment where some information may have to be obtained after packets are in flight. Modifications to IP mobility should be considered in order to optimize the behavior of the overall system. Anything that decreases the number of new EID-to-RLOC mappings needed when a node moves, or maintains the validity of an EID-to-RLOC mapping for a longer time, is useful.
移动IP数据包交换是为这样一种环境而设计的：在数据包被转发之前，所有路由信息都被传播。为了使互联网能够发展，以支持预期的未来使用，我们正在转向一个在数据包传输后可能必须获取某些信息的环境。应考虑对IP移动性进行修改，以优化整个系统的行为。任何减少节点移动时所需的新EID到RLOC映射的数量或在较长时间内保持EID到RLOC映射的有效性的方法都是有用的。
In addition to endpoints, a network can be mobile, possibly changing xTRs. A "network" can be as small as a single router and as large as a whole site. This is different from site mobility in that it is fast and possibly short-lived, but different from endpoint mobility in that a whole prefix is changing RLOCs. However, the mechanisms are the same, and there is no new overhead in LISP. A map request for any endpoint will return a binding for the entire mobile prefix.
除了端点，网络还可以是移动的，可能会改变XTR。“网络”可以小到单个路由器，也可以大到整个站点。这不同于站点移动，因为它速度快，可能寿命短，但不同于端点移动，因为整个前缀都在改变RLOCs。但是，这些机制是相同的，LISP中没有新的开销。任何端点的映射请求都将返回整个移动前缀的绑定。
If mobile networks become a more common occurrence, it may be useful to revisit the design of the mapping service and allow for dynamic updates of the database.
如果移动网络变得更常见，那么重新审视映射服务的设计并允许动态更新数据库可能会很有用。
The issue of interactions between mobility and LISP needs to be explored further. Specific improvements to the entire system will depend on the details of mapping mechanisms. Mapping mechanisms should be evaluated on how well they support session continuity for mobile nodes.
需要进一步探讨移动性和LISP之间的交互问题。整个系统的具体改进将取决于映射机制的细节。应评估映射机制对移动节点会话连续性的支持程度。
A mobile device can use the LISP infrastructure to achieve mobility by implementing the LISP encapsulation and decapsulation functions and acting as a simple ITR/ETR. By doing this, such a "LISP mobile node" can use topologically independent EID IP addresses that are not advertised into and do not impose a cost on the global routing system. These EIDs are maintained at the edges of the mapping system (in LISP Map-Servers and Map-Resolvers) and are provided on demand to only the correspondents of the LISP mobile node.
移动设备可以通过实现LISP封装和去封装功能并充当简单的ITR/ETR，使用LISP基础设施实现移动性。通过这样做，这样的“LISP移动节点”可以使用拓扑上独立的EID IP地址，这些地址不会被广告到，也不会对全局路由系统造成成本。这些EID保存在映射系统的边缘（在LISP映射服务器和映射解析器中），并根据需要仅提供给LISP移动节点的对应者。
Refer to [LISP-MN] for more details.
有关更多详细信息，请参阅[LISP-MN]。
A multicast group address, as defined in the original Internet architecture, is an identifier of a grouping of topologically independent receiver host locations. The address encoding itself does not determine the location of the receiver(s). The multicast routing protocol, and the network-based state the protocol creates, determine where the receivers are located.
在原始Internet体系结构中定义的多播组地址是一组拓扑独立的接收器主机位置的标识符。地址编码本身并不确定接收器的位置。多播路由协议以及该协议创建的基于网络的状态决定了接收器的位置。
In the context of LISP, a multicast group address is both an EID and a Routing Locator. Therefore, no specific semantic or action needs to be taken for a destination address, as it would appear in an IP header. Therefore, a group address that appears in an inner IP header built by a source host will be used as the destination EID. The outer IP header (the destination Routing Locator address), prepended by a LISP router, will use the same group address as the destination Routing Locator.
在LISP上下文中，多播组地址既是EID又是路由定位器。因此，不需要对目标地址采取特定的语义或操作，因为它会出现在IP报头中。因此，出现在源主机构建的内部IP头中的组地址将用作目标EID。外部IP头（目标路由定位器地址）由LISP路由器预先设置，将使用与目标路由定位器相同的组地址。
Having said that, only the source EID and source Routing Locator need to be dealt with. Therefore, an ITR merely needs to put its own IP address in the source 'Routing Locator' field when prepending the outer IP header. This source Routing Locator address, like any other Routing Locator address, MUST be globally routable.
话虽如此，只需要处理源EID和源路由定位器。因此，ITR只需在预处理外部IP头时将其自己的IP地址放入源“路由定位器”字段中。与任何其他路由定位器地址一样，此源路由定位器地址必须是全局可路由的。
Therefore, an EID-to-RLOC mapping does not need to be performed by an ITR when a received data packet is a multicast data packet or when processing a source-specific Join (either by IGMPv3 or PIM). But the source Routing Locator is decided by the multicast routing protocol in a receiver site. That is, an EID-to-RLOC translation is done at control time.
因此，当接收到的数据分组是多播数据分组或当处理源特定加入（通过IGMPv3或PIM）时，EID到RLOC映射不需要由ITR执行。但是，源路由定位器是由接收站点中的多播路由协议决定的。也就是说，EID到RLOC的转换是在控制时间完成的。
Another approach is to have the ITR not encapsulate a multicast packet and allow the packet built by the host to flow into the core even if the source address is allocated out of the EID namespace. If the RPF-Vector TLV [RFC5496] is used by PIM in the core, then core
另一种方法是让ITR不封装多播数据包，并允许主机构建的数据包流入核心，即使源地址分配到EID命名空间之外。如果PIM在core中使用RPF向量TLV[RFC5496]，则core
routers can RPF to the ITR (the locator address, which is injected into core routing) rather than the host source address (the EID address, which is not injected into core routing).
路由器可以RPF到ITR（定位器地址，注入核心路由），而不是主机源地址（EID地址，未注入核心路由）。
To avoid any EID-based multicast state in the network core, the first approach is chosen for LISP-Multicast. Details for LISP-Multicast and interworking with non-LISP sites are described in [RFC6831] and [RFC6832].
为了避免在网络核心中出现任何基于EID的多播状态，LISP多播选择了第一种方法。[RFC6831]和[RFC6832]中描述了LISP多播和与非LISP站点交互的详细信息。
It is believed that most of the security mechanisms will be part of the mapping database service when using control-plane procedures for obtaining EID-to-RLOC mappings. For data-plane-triggered mappings, as described in this specification, protection is provided against ETR spoofing by using route-returnability (see Section 3) mechanisms evidenced by the use of a 24-bit 'Nonce' field in the LISP encapsulation header and a 64-bit 'Nonce' field in the LISP control message.
当使用控制平面过程来获取EID到RLOC的映射时，相信大多数安全机制都是映射数据库服务的一部分。对于数据平面触发的映射，如本规范所述，通过使用路由可返回性（见第3节）机制提供ETR欺骗保护，该机制通过在LISP封装头中使用24位“Nonce”字段和在LISP控制消息中使用64位“Nonce”字段来证明。
The nonce, coupled with the ITR accepting only solicited Map-Replies, provides a basic level of security, in many ways similar to the security experienced in the current Internet routing system. It is hard for off-path attackers to launch attacks against these LISP mechanisms, as they do not have the nonce values. Sending a large number of packets to accidentally find the right nonce value is possible but would already by itself be a denial-of-service (DoS) attack. On-path attackers can perform far more serious attacks, but on-path attackers can launch serious attacks in the current Internet as well, including eavesdropping, blocking, or redirecting traffic. See more discussion on this topic in Section 6.1.5.1.
nonce加上仅接受请求的Map回复的ITR，提供了基本的安全级别，在许多方面类似于当前Internet路由系统中所经历的安全级别。非路径攻击者很难对这些LISP机制发起攻击，因为它们没有nonce值。发送大量数据包以意外找到正确的nonce值是可能的，但其本身已经是拒绝服务（DoS）攻击。路径上攻击者可以执行更严重的攻击，但路径上攻击者也可以在当前Internet上发起严重的攻击，包括窃听、阻止或重定向流量。有关此主题的更多讨论，请参见第6.1.5.1节。
LISP does not rely on a PKI or a more heavyweight authentication system. These systems challenge one of the primary design goals of LISP -- scalability.
LISP不依赖PKI或更重的身份验证系统。这些系统挑战LISP的主要设计目标之一——可伸缩性。
DoS attack prevention will depend on implementations rate-limiting Map-Requests and Map-Replies to the control plane as well as rate-limiting the number of data-triggered Map-Replies.
DoS攻击预防将取决于对控制平面的Map请求和Map回复的速率限制以及对数据触发的Map回复数量的速率限制。
An incorrectly implemented or malicious ITR might choose to ignore the Priority and Weights provided by the ETR in its Map-Reply. This traffic-steering would be limited to the traffic that is sent by this ITR's site and no more severe than if the site initiated a bandwidth DoS attack on (one of) the ETR's ingress links. The ITR's site would typically gain no benefit from not respecting the Weights and would likely receive better service by abiding by them.
错误实施或恶意ITR可能会选择忽略ETR在其Map回复中提供的优先级和权重。此流量控制将限于此ITR站点发送的流量，并且不会比站点在ETR的（其中一个）入口链路上发起带宽DoS攻击更严重。ITR的站点通常不会从不尊重权重中获得任何好处，并且遵守权重可能会获得更好的服务。
To deal with map-cache exhaustion attempts in an ITR/PITR, the implementation should consider putting a maximum cap on the number of entries stored with a reserve list for special or frequently accessed sites. This should be a configuration policy control set by the network administrator who manages ITRs and PITRs. When overlapping EID-Prefixes occur across multiple Map-Cache entries, the integrity of the set must be wholly maintained. So, if a more-specific entry cannot be added due to reaching the maximum cap, then none of the less-specific entries should be stored in the map-cache.
为了处理ITR/PITR中的MAP缓存穷举尝试，实现应该考虑对特定或频繁访问的站点的储备列表中存储的条目的数量进行最大限度的覆盖。这应该是由管理ITR和PITR的网络管理员设置的配置策略控制。当多个映射缓存项之间出现重叠的EID前缀时，必须完全保持集合的完整性。因此，如果由于达到最大上限而无法添加更具体的条目，则不应将不太具体的条目存储在地图缓存中。
Given that the ITR/PITR maintains a cache of EID-to-RLOC mappings, cache sizing and maintenance are issues to be kept in mind during implementation. It is a good idea to have instrumentation in place to detect thrashing of the cache. Implementation experimentation will be used to determine which cache management strategies work best. In general, it is difficult to defend against cache-thrashing attacks. It should be noted that an undersized cache in an ITR/PITR not only causes adverse effects on the site or region it supports but may also cause increased Map-Request loads on the mapping system.
考虑到ITR/PITR维护EID到RLOC映射的缓存，缓存大小和维护是实现过程中需要记住的问题。最好在适当的位置安装检测工具来检测缓存的抖动。实现实验将用于确定哪种缓存管理策略最有效。通常，很难抵御缓存抖动攻击。应该注意的是，ITR/PITR中的缓存过小不仅会对其支持的站点或区域造成不利影响，还可能会增加映射系统上的映射请求负载。
"Piggybacked" mapping data as discussed in Section 6.1.3 specifies how to handle such mappings and includes the possibility for an ETR to temporarily accept such a mapping before verification when running in "trusted" environments. In such cases, there is a potential threat that a fake mapping could be inserted (even if only for a short period) into a map-cache. As noted in Section 6.1.3, an ETR MUST be specifically configured to run in such a mode and might usefully only consider some specific ITRs as also running in that same trusted environment.
第6.1.3节中讨论的“背负式”映射数据规定了如何处理此类映射，并包括ETR在“受信任”环境中运行时在验证前临时接受此类映射的可能性。在这种情况下，存在一个潜在的威胁，即可能会将一个伪造的映射插入到映射缓存中（即使只是很短的一段时间）。正如在第1.1.3节中所指出的，ETR必须被专门配置为以这样的模式运行，并且可能只考虑一些特定的ITR也在相同的可信环境中运行。
There is a security risk implicit in the fact that ETRs generate the EID-Prefix to which they are responding. An ETR can claim a shorter prefix than it is actually responsible for. Various mechanisms to ameliorate or resolve this issue will be examined in the future [LISP-SEC].
ETR生成其响应的EID前缀这一事实隐含着安全风险。ETR可以声明比其实际负责的前缀更短的前缀。未来将研究改善或解决此问题的各种机制[LISP-SEC]。
Spoofing of inner-header addresses of LISP-encapsulated packets is possible, as with any tunneling mechanism. ITRs MUST verify the source address of a packet to be an EID that belongs to the site's EID-Prefix range prior to encapsulation. An ETR must only decapsulate and forward datagrams with an inner-header destination that matches one of its EID-Prefix ranges. If, upon receipt and decapsulation, the destination EID of a datagram does not match one of the ETR's configured EID-Prefixes, the ETR MUST drop the datagram. If a LISP-encapsulated packet arrives at an ETR, it SHOULD compare the inner-header source EID address and the outer-header source RLOC address with the mapping that exists in the mapping database. Then,
与任何隧道机制一样，可以欺骗LISP封装数据包的内部头地址。ITRs必须在封装之前验证数据包的源地址是否为属于站点EID前缀范围的EID。ETR只能解封装并转发具有与其EID前缀范围之一匹配的内部标头目标的数据报。如果在接收和解除封装时，数据报的目标EID与ETR配置的EID前缀之一不匹配，ETR必须删除数据报。如果LISP封装的数据包到达ETR，则应将内部报头源EID地址和外部报头源RLOC地址与映射数据库中存在的映射进行比较。然后
when spoofing attacks occur, the outer-header source RLOC address can be used to trace back the attack to the source site, using existing operational tools.
当发生欺骗攻击时，可以使用现有操作工具使用外部标头源RLOC地址将攻击追溯到源站点。
This experimental specification does not address automated key management (AKM). BCP 107 [RFC4107] provides guidance in this area. In addition, at the time of this writing, substantial work is being undertaken to improve security of the routing system [RFC6518] [RFC6480] [BGP-SEC] [LISP-SEC]. Future work on LISP should address the issues discussed in BCP 107 as well as other open security considerations, which may require changes to this specification.
本实验性规范不涉及自动密钥管理（AKM）。BCP 107[RFC4107]在这方面提供指导。此外，在撰写本文时，正在开展大量工作，以提高路由系统[RFC6518][RFC6480][BGP-SEC][LISP-SEC]的安全性。关于LISP的未来工作应解决BCP 107中讨论的问题以及其他开放安全注意事项，这可能需要对本规范进行更改。
Considerations for network management tools exist so the LISP protocol suite can be operationally managed. These mechanisms can be found in [LISP-MIB] and [RFC6835].
存在网络管理工具的注意事项，因此可以对LISP协议套件进行操作管理。这些机制可以在[LISP-MIB]和[RFC6835]中找到。
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the LISP specification, in accordance with BCP 26 [RFC5226].
本节根据BCP 26[RFC5226]为互联网分配号码管理局（IANA）提供有关LISP规范相关值注册的指南。
There are four namespaces (listed in the sub-sections below) in LISP that have been registered.
LISP中有四个已注册的名称空间（在下面的小节中列出）。
o LISP IANA registry allocations should not be made for purposes unrelated to LISP routing or transport protocols.
o LISP IANA注册表分配不应用于与LISP路由或传输协议无关的目的。
o The following policies are used here with the meanings defined in BCP 26: "Specification Required", "IETF Review", "Experimental Use", and "First Come First Served".
o 以下政策在这里使用，其含义见BCP 26：“所需规范”、“IETF审查”、“实验使用”和“先到先得”。
New ACT values (Section 6.1.4) can be allocated through IETF review or IESG approval. Four values have already been allocated by this specification (Section 6.1.4).
新的ACT值（第6.1.4节）可通过IETF审查或IESG批准进行分配。本规范已经分配了四个值（第6.1.4节）。
In addition, LISP has a number of flag fields and reserved fields, such as the LISP header flags field (Section 5.3). New bits for flags in these fields can be implemented after IETF review or IESG approval, but these need not be managed by IANA.
此外，LISP还有许多标志字段和保留字段，例如LISP标题标志字段（第5.3节）。在IETF审查或IESG批准后，可以实现这些字段中标志的新位，但这些位不需要由IANA管理。
LISP Address [LCAF] type codes have a range from 0 to 255. New type codes MUST be allocated consecutively, starting at 0. Type Codes 0-127 are to be assigned by IETF review or IESG approval.
LISP地址[LCAF]类型代码的范围为0到255。新类型代码必须从0开始连续分配。类型代码0-127由IETF审查或IESG批准分配。
Type Codes 128-255 are available according to the [RFC5226] First Come First Served policy.
根据[RFC5226]先到先得政策，类型代码128-255可用。
This registry, initially empty, is constructed for future use in experimental work related to LISP Canonical Address Format (LCAF) values. See [LCAF] for details of other possible unapproved address encodings. The unapproved LCAF encodings are an area for further study and experimentation.
这个注册表最初是空的，是为了将来在与LISP规范地址格式（LCAF）值相关的实验工作中使用而构建的。有关其他可能未经批准的地址编码的详细信息，请参见[LCAF]。未经批准的LCAF编码是进一步研究和实验的领域。
The IANA registry has allocated UDP port numbers 4341 and 4342 for lisp-data and lisp-control operation, respectively. IANA has updated the description for UDP ports 4341 and 4342 as follows:
IANA注册表分别为lisp数据和lisp控制操作分配了UDP端口号4341和4342。IANA已将UDP端口4341和4342的说明更新如下：
lisp-data 4341 udp LISP Data Packets lisp-control 4342 udp LISP Control Packets
lisp数据4341 udp lisp数据包lisp控制4342 udp lisp控制包
The following Key ID values are defined by this specification as used in any packet type that references a 'Key ID' field:
以下密钥ID值由本规范定义，用于引用“密钥ID”字段的任何数据包类型：
Name Number Defined in
-----------------------------------------------
None 0 n/a
HMAC-SHA-1-96 1 [RFC2404]
HMAC-SHA-256-128 2 [RFC4868]
Name Number Defined in
-----------------------------------------------
None 0 n/a
HMAC-SHA-1-96 1 [RFC2404]
HMAC-SHA-256-128 2 [RFC4868]
Number values are in the range of 0 to 65535. The allocation of values is on a first come first served basis.
数值在0到65535之间。价值分配以先到先得的方式进行。
As an experimental specification, this work is, by definition, incomplete. Specific areas where additional experience and work are needed include the following:
作为一个实验规范，根据定义，这项工作是不完整的。需要额外经验和工作的具体领域包括：
o At present, only [RFC6836] is defined for implementing a database of EID-to-RLOC mapping information. Additional research on other mapping database systems is strongly encouraged.
o 目前，只有[RFC6836]被定义用于实现EID到RLOC映射信息的数据库。强烈鼓励对其他地图数据库系统进行更多研究。
o Failure and recovery of LISP site partitioning (see Section 6.4) in the presence of redundant configuration (see Section 8.5) needs further research and experimentation.
o 在存在冗余配置（见第8.5节）的情况下，LISP站点分区（见第6.4节）的故障和恢复需要进一步研究和实验。
o The characteristics of map-cache management under exceptional conditions, such as denial-of-service attacks, are not fully understood. Further experience is needed to determine whether current caching methods are practical or in need of further development. In particular, the performance, scaling, and security characteristics of the map-cache will be discovered as part of this experiment. Performance metrics to be observed are packet reordering associated with the LISP Data-Probe and loss of the first packet in a flow associated with map-caching. The impact of these upon TCP will be observed. See Section 12 for additional thoughts and considerations.
o 在特殊情况下，如拒绝服务攻击，地图缓存管理的特点尚未完全了解。需要进一步的经验来确定当前的缓存方法是实用的还是需要进一步的开发。特别是，作为本实验的一部分，将发现映射缓存的性能、缩放和安全特性。要观察的性能指标是与LISP数据探测相关联的数据包重新排序，以及与映射缓存相关联的流中第一个数据包的丢失。将观察这些因素对TCP的影响。更多想法和注意事项见第12节。
o Preliminary work has been done to ensure that sites employing LISP can interconnect with the rest of the Internet. This work is documented in [RFC6832], but further experimentation and experience are needed.
o 为确保使用LISP的站点能够与Internet的其余部分互连，已经做了初步工作。这项工作记录在[RFC6832]中，但还需要进一步的实验和经验。
o At present, no mechanism for automated key management for message authentication is defined. Addressing automated key management is necessary before this specification can be developed into a Standards Track RFC. See Section 12 for further details regarding security considerations.
o 目前，尚未定义用于消息身份验证的自动密钥管理机制。在将本规范发展为标准跟踪RFC之前，必须解决自动密钥管理问题。有关安全注意事项的更多详细信息，请参见第12节。
o In order to maintain security and stability, Internet protocols typically isolate the control and data planes. Therefore, user activity cannot cause control-plane state to be created or destroyed. LISP does not maintain this separation. The degree to which the loss of separation impacts security and stability is a topic for experimental observation.
o 为了保持安全性和稳定性，Internet协议通常会隔离控制平面和数据平面。因此，用户活动不能导致创建或销毁控制平面状态。LISP不保持这种分离。分离损失对安全性和稳定性的影响程度是实验观察的主题。
o LISP allows for the use of different mapping database systems. While only one [RFC6836] is currently well defined, each mapping database will likely have some impact on the security of the EID-to-RLOC mappings. How each mapping database system's security properties impact LISP overall is for further study.
o LISP允许使用不同的映射数据库系统。虽然目前只定义了一个[RFC6836]，但每个映射数据库可能会对EID到RLOC映射的安全性产生一些影响。每个映射数据库系统的安全属性如何影响LISP整体，有待进一步研究。
o An examination of the implications of LISP on Internet traffic, applications, routers, and security is needed. This will help implementors understand the consequences for network stability, routing protocol function, routing scalability, migration and backward compatibility, and implementation scalability (as influenced by additional protocol components; additional state; and additional processing for encapsulation, decapsulation, and liveness).
o 需要研究LISP对互联网流量、应用程序、路由器和安全性的影响。这将帮助实施者了解网络稳定性、路由协议功能、路由可伸缩性、迁移和向后兼容性以及实施可伸缩性（受附加协议组件、附加状态以及封装、解封装和活动性的附加处理的影响）的后果。
o Experiments need to verify that LISP produces no significant change in the behavior of protocols run between end-systems over a LISP infrastructure versus being run directly between those same end-systems.
o 实验需要验证LISP在LISP基础设施上的终端系统之间运行的协议的行为与直接在这些相同的终端系统之间运行的协议相比，不会产生显著的变化。
o Experiments need to verify that the issues raised in the Critique section of [RFC6115] are either insignificant or have been addressed by updates to LISP.
o 实验需要验证[RFC6115]评论部分提出的问题是否无关紧要，或者是否已通过LISP更新得到解决。
Other LISP documents may also include open issues and areas for future work.
其他LISP文档还可能包括未解决的问题和未来工作的领域。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2404]Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[RFC3232]Reynolds，J.，“分配号码：RFC 1700被在线数据库取代”，RFC 3232，2002年1月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[RFC4632]Fuller，V.和T.Li，“无类域间路由（CIDR）：互联网地址分配和聚合计划”，BCP 122，RFC 4632，2006年8月。
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
[RFC4868]Kelly，S.和S.Frankel，“在IPsec中使用HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512”，RFC 4868，2007年5月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009.
[RFC5496]Wijnands，IJ.，Boers，A.，和E.Rosen，“反向路径转发（RPF）向量TLV”，RFC 54962009年3月。
[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
[RFC5944]Perkins，C.，“IPv4的IP移动支持，修订版”，RFC 59442010年11月。
[RFC6115] Li, T., "Recommendation for a Routing Architecture", RFC 6115, February 2011.
[RFC6115]Li，T.，“路由架构的建议”，RFC61152011年2月。
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275]Perkins，C.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 62752011年7月。
[RFC6833] Farinacci, D. and V. Fuller, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, January 2013.
[RFC6833]Farinaci，D.和V.Fuller，“定位器/ID分离协议（LISP）地图服务器接口”，RFC 6833，2013年1月。
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 6834, January 2013.
[RFC6834]Iannone，L.，Saucez，D.，和O.Bonaventure，“定位器/ID分离协议（LISP）地图版本控制”，RFC 6834，2013年1月。
[RFC6836] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, January 2013.
[RFC6836]Farinaci，D.，Fuller，V.，Meyer，D.，和D.Lewis，“定位器/ID分离协议替代逻辑拓扑（LISP+ALT）”，RFC 68362013年1月。
[AFI] IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers>.
[AFI]IANA，“地址家庭编号”<http://www.iana.org/assignments/address-family-numbers>.
[BGP-SEC] Lepinski, M. and S. Turner, "An Overview of BGPSEC", Work in Progress, May 2012.
[BGP-SEC]Lepinski，M.和S.Turner，“BGPSEC概述”，正在进行的工作，2012年5月。
[CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed Enhancement to the Internet Architecture", 1999, <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>.
[Chiapa]Chiapa，J.，“端点和端点名称：互联网架构的拟议增强”，1999年<http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>。
[CONS] Brim, S., Chiappa, N., Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP-CONS: A Content distribution Overlay Network Service for LISP", Work in Progress, April 2008.
[CONS]Brim，S.，Chiapa，N.，Farinaci，D.，Fuller，V.，Lewis，D.，和D.Meyer，“LISP-CONS：LISP的内容分发覆盖网络服务”，正在进行的工作，2008年4月。
[EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID Mappings Multicast Across Cooperating Systems for LISP", Work in Progress, November 2007.
[EMACS]Brim，S.，Farinaci，D.，Meyer，D.，和J.Curran，“跨LISP协作系统的EID映射多播”，正在进行的工作，2007年11月。
[LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", Work in Progress, January 2013.
[LCAF]Farinaci，D.，Meyer，D.，和J.Snijders，“LISP规范地址格式（LCAF）”，正在进行的工作，2013年1月。
[LISA96] Lear, E., Tharp, D., Katinsky, J., and J. Coffin, "Renumbering: Threat or Menace?", Usenix Tenth System Administration Conference (LISA 96), October 1996.
[LISA96]李尔，E.，塔普，D.，卡廷斯基，J.，和J.科芬，“重新编号：威胁还是威胁？”，Usenix第十届系统管理会议（LISA 96），1996年10月。
[LISP-DEPLOY] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-Pascual, J., and D. Lewis, "LISP Network Element Deployment Considerations", Work in Progress, October 2012.
[LISP-DEPLOY]Jakab，L.，Cabellos Aparicio，A.，Coras，F.，Domingo Pascual，J.，和D.Lewis，“LISP网元部署注意事项”，正在进行的工作，2012年10月。
[LISP-MIB] Schudel, G., Jain, A., and V. Moreno, "LISP MIB", Work in Progress, January 2013.
[LISP-MIB]Schudel，G.，Jain，A.，和V.Moreno，“LISP-MIB”，在建工程，2013年1月。
[LISP-MN] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Mobile Node", Work in Progress, October 2012.
[LISP-MN]Farinaci，D.，Lewis，D.，Meyer，D.，和C.White，“LISP移动节点”，正在进行的工作，2012年10月。
[LISP-SEC] Maino, F., Ermagan, V., Cabellos, A., Saucez, D., and O. Bonaventure, "LISP-Security (LISP-SEC)", Work in Progress, October 2012.
[LISP-SEC]Maino，F.，Ermagan，V.，Cabellos，A.，Saucez，D.，和O.Bonaventure，“LISP安全（LISP-SEC）”，正在进行的工作，2012年10月。
[LOC-ID-ARCH] Meyer, D. and D. Lewis, "Architectural Implications of Locator/ID Separation", Work in Progress, January 2009.
[LOC-ID-ARCH]Meyer，D.和D.Lewis，“定位器/ID分离的架构含义”，正在进行的工作，2009年1月。
[OPENLISP] Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP Implementation Report", Work in Progress, July 2008.
[OPENLISP]Iannone，L.，Saucez，D.，和O.Bonaventure，“OPENLISP实施报告”，正在进行的工作，2008年7月。
[RADIR] Narten, T., "On the Scalability of Internet Routing", Work in Progress, February 2010.
[RADIR]Narten，T.，“互联网路由的可扩展性”，正在进行的工作，2010年2月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107]Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，2005年6月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192]Baker，F.，Lear，E.，和R.Droms，“在没有国旗日的情况下对IPv6网络重新编号的程序”，RFC 41922005年9月。
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007.
[RFC4866]Arkko，J.，Vogt，C.，和W.Haddad，“移动IPv6的增强路由优化”，RFC 4866，2007年5月。
[RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007.
[RFC4984]Meyer，D.，Zhang，L.，和K.Fall，“IAB路由和寻址研讨会报告”，RFC 4984，2007年9月。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480]Lepinski，M.和S.Kent，“支持安全互联网路由的基础设施”，RFC 6480，2012年2月。
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, February 2012.
[RFC6518]Lebovitz，G.和M.Bhatia，“路由协议的键控和认证（KARP）设计指南”，RFC 6518，2012年2月。
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, January 2013.
[RFC6831]Farinaci，D.，Meyer，D.，Zwiebel，J.，和S.Venaas，“用于多播环境的定位器/ID分离协议（LISP）”，RFC 68312013年1月。
[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.
[RFC6832]Lewis，D.，Meyer，D.，Farinaci，D.，和V.Fuller，“定位器/ID分离协议（LISP）和非LISP站点之间的互通”，RFC 6832，2013年1月。
[RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation Protocol Internet Groper (LIG)", RFC 6835, January 2013.
[RFC6835]Farinaci，D.和D.Meyer，“定位器/身份分离协议互联网搜索器（LIG）”，RFC 68352013年1月。
[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database", RFC 6837, January 2013.
[RFC6837]李尔，E.“NERD：路由定位器（RLOC）数据库的一个不太新颖的端点ID（EID）”，RFC 6837，2013年1月。
[UDP-TUNNELS] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", Work in Progress, January 2013.
[UDP-TUNNELS]Eubanks，M.，Chimento，P.，和M.Westerlund，“隧道数据包的IPv6和UDP校验和”，正在进行的工作，2013年1月。
[UDP-ZERO] Fairhurst, G. and M. Westerlund, "Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums", Work in Progress, December 2012.
[UDP-ZERO]Fairhurst，G.和M.Westerlund，“使用具有零校验和的IPv6 UDP数据报的适用性声明”，正在进行的工作，2012年12月。
An initial thank you goes to Dave Oran for planting the seeds for the initial ideas for LISP. His consultation continues to provide value to the LISP authors.
首先感谢Dave Oran为LISP的最初想法播下种子。他的咨询继续为LISP作者提供价值。
A special and appreciative thank you goes to Noel Chiappa for providing architectural impetus over the past decades on separation of location and identity, as well as detailed reviews of the LISP architecture and documents, coupled with enthusiasm for making LISP a practical and incremental transition for the Internet.
特别感谢Noel Chiapa，感谢他在过去几十年中为位置和身份的分离提供了架构动力，并对LISP架构和文档进行了详细的审查，同时也感谢他对使LISP成为互联网的一个实用和增量过渡的热情。
The authors would like to gratefully acknowledge many people who have contributed discussions and ideas to the making of this proposal. They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller, Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston, David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina Ermagan, Albert Cabellos, Fabio Maino, Victor Moreno, Chris White, Clarence Filsfils, and Alia Atlas.
作者要感谢许多为本提案的提出提供了讨论和想法的人。他们包括斯科特·布里姆、安德鲁·帕坦、约翰·兹维贝尔、杰森·席勒、张丽霞、道林·金、彼得·舍恩马克、维杰·吉尔、杰夫·休斯顿、大卫·康拉德、马克·汉德利、罗恩·博尼卡、特德·希利、马克·汤斯利、克里斯·莫罗、布莱恩·维斯、戴夫·麦克格雷夫、彼得·洛斯伯格、戴夫·泰勒、艾略特·李尔、谢恩·阿曼特、维德·卡夫勒、奥利维尔·博纳文特、路易吉·伊安农、，罗宾·惠特尔、布赖恩·卡彭特、乔尔·哈尔彭、特里·曼德森、罗杰·乔根森、兰恩·阿特金森、斯蒂格·维纳斯、伊尔吉奇·范贝伊纳姆、罗兰·布莱斯、达娜·布莱尔、比尔·林奇、马克·伍尔沃德、达米恩·索切斯、达米安·莱扎马、阿提拉·格罗特、巴拉塔普·拉赫里、大卫·布莱克、罗克·加利亚诺、伊西多·库韦拉斯、杰斯帕·斯克里夫、弗雷德·坦普林、玛格丽特·瓦瑟曼、，山姆·哈特曼、迈克尔·霍夫林、佩德罗·马尔克斯、贾里·阿尔科、格雷格·舒德尔、斯里尼瓦斯·萨布拉曼尼安、阿米特·贾恩、徐晓虎、迪伦德拉·特里维迪、亚科夫·雷赫特、约翰·斯卡德尔、约翰·德雷克、迪米特里·帕帕迪米特里欧、罗斯·卡隆、塞琳娜·海姆利希、乔布斯·斯奈德、维娜·埃尔马根、阿尔伯特·卡贝罗斯、法比奥·梅诺、维克多·莫雷诺、克里斯·怀特、克拉伦斯·菲尔斯菲尔斯、，和艾莉亚·阿特拉斯。
This work originated in the Routing Research Group (RRG) of the IRTF. An individual submission was converted into the IETF LISP working group document that became this RFC.
这项工作起源于IRTF的路由研究小组（RRG）。一份单独提交的文件被转换为IETF LISP工作组文件，成为本RFC。
The LISP working group would like to give a special thanks to Jari Arkko, the Internet Area AD at the time that the set of LISP documents were being prepared for IESG last call, and for his meticulous reviews and detailed commentaries on the 7 working group last call documents progressing toward experimental RFCs.
LISP工作组要特别感谢Jari Arkko，他是为IESG last call编写LISP文档集时的互联网广告，并感谢他对7份工作组last call文档进行了细致的审查和详细的评论，这些文档正朝着实验性RFC的方向发展。
Authors' Addresses
作者地址
Dino Farinacci Cisco Systems Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市塔斯曼大道迪诺·法里纳奇思科系统公司，邮编95134
EMail: farinacci@gmail.com
EMail: farinacci@gmail.com
Vince Fuller
文斯·富勒
EMail: vaf@vaf.net
EMail: vaf@vaf.net
Dave Meyer Cisco Systems 170 Tasman Drive San Jose, CA USA
美国加利福尼亚州圣何塞塔斯曼大道170号Dave Meyer Cisco Systems
EMail: dmm@1-4-5.net
EMail: dmm@1-4-5.net
Darrel Lewis Cisco Systems 170 Tasman Drive San Jose, CA USA
美国加利福尼亚州圣何塞塔斯曼大道170号Darrel Lewis Cisco Systems
EMail: darlewis@cisco.com
EMail: darlewis@cisco.com