Internet Engineering Task Force (IETF) V. Fuller
Request for Comments: 6833
Category: Experimental D. Farinacci
ISSN: 2070-1721 Cisco Systems
January 2013
Internet Engineering Task Force (IETF) V. Fuller
Request for Comments: 6833
Category: Experimental D. Farinacci
ISSN: 2070-1721 Cisco Systems
January 2013
Locator/ID Separation Protocol (LISP) Map-Server Interface
定位器/ID分离协议（LISP）地图服务器接口
Abstract
摘要
This document describes the Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two new types of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID to Routing Locator mapping databases.
本文档描述了定位器/ID分离协议（LISP）的映射服务，该协议由两种新型的LISP语言设备——LISP映射解析程序和LISP映射服务器——实现，它为一个或多个端点ID到路由定位器映射数据库提供了一个简化的“前端”。
By using this service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers and Egress Tunnel Routers are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs. Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP.
通过使用此服务接口并与Map解析器和Map服务器通信，LISP入口隧道路由器和出口隧道路由器不依赖于映射数据库系统的细节，这有助于实验不同的数据库设计。由于这些设备实现了LISP基础设施的“边缘”，直接连接到支持LISP的互联网终端站点，并构成了大部分讲LISP的设备，因此降低其实现和操作复杂性也应降低部署LISP的总体成本和工作量。
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/rfc6833.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6833.
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 ....................................................2
2. Definition of Terms .............................................3
3. Basic Overview ..................................................4
4. Interactions with Other LISP Components .........................5
4.1. ITR EID-to-RLOC Mapping Resolution .........................5
4.2. EID-Prefix Configuration and ETR Registration ..............6
4.3. Map-Server Processing ......................................8
4.4. Map-Resolver Processing ....................................9
4.4.1. Anycast Map-Resolver Operation .....................10
5. Open Issues and Considerations .................................10
6. Security Considerations ........................................11
7. References .....................................................12
7.1. Normative References ......................................12
7.2. Informative References ....................................12
Appendix A. Acknowledgments .......................................13
1. Introduction ....................................................2
2. Definition of Terms .............................................3
3. Basic Overview ..................................................4
4. Interactions with Other LISP Components .........................5
4.1. ITR EID-to-RLOC Mapping Resolution .........................5
4.2. EID-Prefix Configuration and ETR Registration ..............6
4.3. Map-Server Processing ......................................8
4.4. Map-Resolver Processing ....................................9
4.4.1. Anycast Map-Resolver Operation .....................10
5. Open Issues and Considerations .................................10
6. Security Considerations ........................................11
7. References .....................................................12
7.1. Normative References ......................................12
7.2. Informative References ....................................12
Appendix A. Acknowledgments .......................................13
The Locator/ID Separation Protocol [RFC6830] specifies an architecture and mechanism for replacing the addresses currently used by IP with two separate name spaces: Endpoint IDs (EIDs), used within sites; and Routing Locators (RLOCs), used on the transit networks that make up the Internet infrastructure. To achieve this separation, LISP defines protocol mechanisms for mapping from EIDs to RLOCs. In addition, LISP assumes the existence of a database to store and propagate those mappings globally. Several such databases have been proposed; among them are the Content distribution Overlay Network Service for LISP (LISP-CONS) [LISP-CONS], LISP-NERD (a Not-so-novel EID-to-RLOC Database) [RFC6837], and LISP Alternative Logical Topology (LISP+ALT) [RFC6836].
定位器/ID分离协议[RFC6830]指定了一种体系结构和机制，用于将IP当前使用的地址替换为两个单独的名称空间：在站点内使用的端点ID（EID）；和路由定位器（RLOC），用于构成互联网基础设施的交通网络。为了实现这种分离，LISP定义了从EID映射到RLOCs的协议机制。此外，LISP假设存在一个数据库来全局存储和传播这些映射。已经提出了几个这样的数据库；其中包括LISP内容分发覆盖网络服务（LISP-CONS）[LISP-CONS]、LISP-NERD（一种对RLOC数据库不太新颖的EID）[RFC6837]和LISP替代逻辑拓扑（LISP+ALT）[RFC6836]。
The LISP Mapping Service defines two new types of LISP-speaking devices: the Map-Resolver, which accepts Map-Requests from an Ingress Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a mapping database; and the Map-Server, which learns authoritative EID-to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes them in a database.
LISP映射服务定义了两种新类型的LISP语言设备：映射解析器，它接受来自入口隧道路由器（ITR）的映射请求，并使用映射数据库“解析”EID到RLOC的映射；以及映射服务器，它从出口隧道路由器（ETR）学习权威EID到RLOC的映射，并将其发布到数据库中。
Conceptually, LISP Map-Servers share some of the same basic configuration and maintenance properties as Domain Name System (DNS) [RFC1035] servers; likewise, Map-Resolvers are conceptually similar to DNS caching resolvers. With this in mind, this specification borrows familiar terminology (resolver and server) from the DNS specifications.
从概念上讲，LISP映射服务器与域名系统（DNS）[RFC1035]服务器共享一些相同的基本配置和维护属性；同样，映射解析程序在概念上类似于DNS缓存解析程序。考虑到这一点，本规范借用了DNS规范中熟悉的术语（解析器和服务器）。
Note that while this document assumes a LISP+ALT database mapping infrastructure to illustrate certain aspects of Map-Server and Map-Resolver operation, the Mapping Service interface can (and likely will) be used by ITRs and ETRs to access other mapping database systems as the LISP infrastructure evolves.
请注意，虽然本文档假设使用LISP+ALT数据库映射基础结构来说明映射服务器和映射解析器操作的某些方面，但随着LISP基础结构的发展，ITRs和ETRs可以（也可能会）使用映射服务接口来访问其他映射数据库系统。
Section 5 of this document notes a number of issues with the Map-Server and Map-Resolver design that are not yet completely understood and are subjects of further experimentation.
本文档第5节说明了地图服务器和地图解析器设计中的一些问题，这些问题尚未完全理解，有待进一步实验。
The LISP Mapping Service is an important component of the LISP toolset. Issues and concerns about the deployment of LISP for Internet traffic are discussed in [RFC6830].
LISP映射服务是LISP工具集的一个重要组件。[RFC6830]中讨论了有关为Internet流量部署LISP的问题和顾虑。
Map-Server: A network infrastructure component that learns of EID-Prefix mapping entries from an ETR, via the registration mechanism described below, or some other authoritative source if one exists. A Map-Server publishes these EID-Prefixes in a mapping database.
映射服务器：一种网络基础设施组件，通过下面描述的注册机制或其他权威来源（如果存在）从ETR中学习EID前缀映射条目。地图服务器在地图数据库中发布这些EID前缀。
Map-Resolver: A network infrastructure component that accepts LISP Encapsulated Map-Requests, typically from an ITR, and determines whether or not the destination IP address is part of the EID namespace; if it is not, a Negative Map-Reply is returned. Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC mapping by consulting a mapping database system.
映射解析器：一个网络基础设施组件，它接受LISP封装的映射请求（通常来自ITR），并确定目标IP地址是否是EID命名空间的一部分；如果不是，则返回否定映射答复。否则，映射解析器将通过查询映射数据库系统找到适当的EID到RLOC映射。
Encapsulated Map-Request: A LISP Map-Request carried within an Encapsulated Control Message, which has an additional LISP header prepended. Sent to UDP destination port 4342. The "outer" addresses are globally routable IP addresses, also known as RLOCs. Used by an ITR when sending to a Map-Resolver and by a Map-Server when forwarding a Map-Request to an ETR.
封装的映射请求：封装的控制消息中包含的LISP映射请求，该消息前面有一个附加的LISP头。发送到UDP目标端口4342。“外部”地址是全局可路由的IP地址，也称为RLOC。ITR在发送到Map解析器时使用，Map服务器在将Map请求转发到ETR时使用。
Negative Map-Reply: A LISP Map-Reply that contains an empty Locator-Set. Returned in response to a Map-Request if the destination EID does not exist in the mapping database. Typically, this means that the "EID" being requested is an IP address connected to a non-LISP site.
否定映射应答：包含空定位器集的LISP映射应答。如果映射数据库中不存在目标EID，则在响应映射请求时返回。通常，这意味着请求的“EID”是连接到非LISP站点的IP地址。
Map-Register message: A LISP message sent by an ETR to a Map-Server to register its associated EID-Prefixes. In addition to the set of EID-Prefixes to register, the message includes one or more RLOCs to be used by the Map-Server when forwarding Map-Requests (re-formatted as Encapsulated Map-Requests) received through the database mapping system. An ETR may request that the Map-Server answer Map-Requests on its behalf by setting the "proxy Map-Reply" flag (P-bit) in the message.
映射注册消息：ETR发送给映射服务器的LISP消息，用于注册其关联的EID前缀。除了要注册的EID前缀集之外，消息还包括一个或多个RLOC，当转发通过数据库映射系统接收的映射请求（重新格式化为封装的映射请求）时，映射服务器将使用这些RLOC。ETR可以通过在消息中设置“proxy Map Reply”（代理映射回复）标志（P位），请求映射服务器代表其应答映射请求。
Map-Notify message: A LISP message sent by a Map-Server to an ETR to confirm that a Map-Register has been received and processed. An ETR requests that a Map-Notify be returned by setting the "want-map-notify" flag (M-bit) in the Map-Register message. Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both source and destination.
映射通知消息：映射服务器发送给ETR的LISP消息，以确认已接收并处理映射寄存器。ETR通过在映射寄存器消息中设置“想要映射通知”标志（M位），请求返回映射通知。与映射回复不同，映射通知对源和目标都使用UDP端口4342。
For definitions of other terms -- notably Map-Request, Map-Reply, Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please consult the LISP specification [RFC6830].
关于其他术语的定义——特别是映射请求、映射应答、入口隧道路由器（ITR）和出口隧道路由器（ETR）——请参考LISP规范[RFC6830]。
A Map-Server is a device that publishes EID-Prefixes in a LISP mapping database on behalf of a set of ETRs. When it receives a Map Request (typically from an ITR), it consults the mapping database to find an ETR that can answer with the set of RLOCs for an EID-Prefix. To publish its EID-Prefixes, an ETR periodically sends Map-Register messages to the Map-Server. A Map-Register message contains a list of EID-Prefixes plus a set of RLOCs that can be used to reach the ETR when a Map-Server needs to forward a Map-Request to it.
映射服务器是代表一组ETR在LISP映射数据库中发布EID前缀的设备。当它接收到映射请求（通常来自ITR）时，它会咨询映射数据库以找到一个ETR，该ETR可以使用一组RLOCs来回答EID前缀。要发布其EID前缀，ETR会定期向Map服务器发送Map Register消息。映射寄存器消息包含EID前缀列表和一组RLOC，当映射服务器需要向其转发映射请求时，这些RLOC可用于到达ETR。
When LISP+ALT is used as the mapping database, a Map-Server connects to the ALT network and acts as a "last-hop" ALT-Router. Intermediate ALT-Routers forward Map-Requests to the Map-Server that advertises a particular EID-Prefix, and the Map-Server forwards them to the owning ETR, which responds with Map-Reply messages.
当LISP+ALT用作映射数据库时，映射服务器连接到ALT网络并充当“最后一跳”ALT路由器。中间ALT路由器将Map请求转发给播发特定EID前缀的Map服务器，Map服务器将其转发给所属ETR，ETR将用Map回复消息进行响应。
A Map-Resolver receives Encapsulated Map-Requests from its client ITRs and uses a mapping database system to find the appropriate ETR to answer those requests. On a LISP+ALT network, a Map-Resolver acts as a "first-hop" ALT-Router. It has Generic Routing Encapsulation (GRE) tunnels configured to other ALT-Routers and uses BGP to learn paths to ETRs for different prefixes in the LISP+ALT database. The Map-Resolver uses this path information to forward Map-Requests over the ALT to the correct ETRs.
映射解析程序从其客户端ITR接收封装的映射请求，并使用映射数据库系统找到相应的ETR来响应这些请求。在LISP+ALT网络上，映射解析器充当“第一跳”ALT路由器。它具有配置到其他ALT路由器的通用路由封装（GRE）隧道，并使用BGP学习LISP+ALT数据库中不同前缀的ETR路径。映射解析器使用此路径信息通过ALT将映射请求转发到正确的ETR。
Note that while it is conceivable that a Map-Resolver could cache responses to improve performance, issues surrounding cache management will need to be resolved so that doing so will be reliable and practical. As initially deployed, Map-Resolvers will operate only in a non-caching mode, decapsulating and forwarding Encapsulated Map Requests received from ITRs. Any specification of caching functionality is left for future work.
请注意，虽然可以想象映射解析器可以缓存响应以提高性能，但需要解决缓存管理相关的问题，以便这样做是可靠和实用的。最初部署时，Map解析器将仅在非缓存模式下运行，解除封装并转发从ITRs接收的封装Map请求。缓存功能的任何规范都留待将来的工作。
Note that a single device can implement the functions of both a Map-Server and a Map-Resolver, and in many cases the functions will be co-located in that way.
请注意，单个设备可以实现地图服务器和地图解析器的功能，在许多情况下，这些功能将以这种方式共存。
Detailed descriptions of the LISP packet types referenced by this document may be found in [RFC6830].
本文件引用的LISP数据包类型的详细说明见[RFC6830]。
An ITR is configured with one or more Map-Resolver addresses. These addresses are "Locators" (or RLOCs) and must be routable on the underlying core network; they must not need to be resolved through LISP EID-to-RLOC mapping, as that would introduce a circular dependency. When using a Map-Resolver, an ITR does not need to connect to any other database mapping system. In particular, the ITR need not connect to the LISP+ALT infrastructure or implement the BGP and GRE protocols that it uses.
ITR配置有一个或多个映射解析器地址。这些地址是“定位符”（或RLOC），必须可在底层核心网络上路由；它们不需要通过LISP EID到RLOC的映射来解析，因为这会引入循环依赖关系。使用映射解析器时，ITR不需要连接到任何其他数据库映射系统。特别是，ITR不需要连接到LISP+ALT基础设施或实现其使用的BGP和GRE协议。
An ITR sends an Encapsulated Map-Request to a configured Map-Resolver when it needs an EID-to-RLOC mapping that is not found in its local map-cache. Using the Map-Resolver greatly reduces both the complexity of the ITR implementation and the costs associated with its operation.
当ITR需要在其本地映射缓存中找不到的EID到RLOC映射时，它会向配置的映射解析程序发送封装的映射请求。使用Map解析器可以大大降低ITR实现的复杂性和与其操作相关的成本。
In response to an Encapsulated Map-Request, the ITR can expect one of the following:
为了响应封装的Map请求，ITR可以预期以下情况之一：
o An immediate Negative Map-Reply (with action code of "Natively-Forward", 15-minute Time to Live (TTL)) from the Map-Resolver if the Map-Resolver can determine that the requested EID does not exist. The ITR saves the EID-Prefix returned in the Map-Reply in its cache, marks it as non-LISP-capable, and knows not to attempt LISP encapsulation for destinations matching it.
o 如果Map解析器可以确定请求的EID不存在，则立即从Map解析器发出否定Map回复（操作代码为“本机转发”，15分钟生存时间（TTL））。ITR将映射应答中返回的EID前缀保存在其缓存中，将其标记为不支持LISP，并且知道不尝试对匹配它的目的地进行LISP封装。
o A Negative Map-Reply, with action code of "Natively-Forward", from a Map-Server that is authoritative for an EID-Prefix that matches the requested EID but that does not have an actively registered, more-specific ID-prefix. In this case, the requested EID is said to match a "hole" in the authoritative EID-Prefix. If the requested EID matches a more-specific EID-Prefix that has been delegated by the Map-Server but for which no ETRs are currently registered, a 1-minute TTL is returned. If the requested EID matches a non-delegated part of the authoritative EID-Prefix, then it is not a LISP EID and a 15-minute TTL is returned. See Section 4.2 for discussion of aggregate EID-Prefixes and details of Map-Server EID-Prefix matching.
o 来自映射服务器的否定映射回复，操作代码为“本机转发”，该映射服务器对与请求的EID匹配的EID前缀具有权威性，但没有主动注册的更具体的ID前缀。在这种情况下，所请求的EID被称为与权威EID前缀中的“洞”匹配。如果请求的EID与地图服务器委派但当前未注册ETR的更具体的EID前缀匹配，则返回1分钟的TTL。如果请求的EID与权威EID前缀的非委托部分匹配，则它不是LISP EID，并返回15分钟TTL。有关聚合EID前缀的讨论以及映射服务器EID前缀匹配的详细信息，请参见第4.2节。
o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or possibly from a Map-Server answering on behalf of the ETR. See Section 4.4 for more details on Map-Resolver message processing.
o 来自拥有EID到RLOC映射的ETR或可能来自代表ETR应答的映射服务器的LISP映射应答。有关Map解析器消息处理的更多详细信息，请参见第4.4节。
Note that an ITR may be configured to both use a Map-Resolver and to participate in a LISP+ALT logical network. In such a situation, the ITR should send Map-Requests through the ALT network for any EID-Prefix learned via ALT BGP. Such a configuration is expected to be very rare, since there is little benefit to using a Map-Resolver if an ITR is already using LISP+ALT. There would be, for example, no need for such an ITR to send a Map-Request to a possibly non-existent EID (and rely on Negative Map-Replies) if it can consult the ALT database to verify that an EID-Prefix is present before sending that Map-Request.
请注意，可以将ITR配置为既使用映射解析器，又参与LISP+ALT逻辑网络。在这种情况下，ITR应通过ALT网络发送Map请求，以获取通过ALT BGP学习到的任何EID前缀。这种配置预计非常罕见，因为如果ITR已经在使用LISP+ALT，那么使用映射解析器几乎没有什么好处。例如，这样的ITR不需要向可能不存在的EID发送映射请求（并且依赖于否定的映射回复）如果它可以在发送映射请求之前咨询ALT数据库以验证EID前缀是否存在。
An ETR publishes its EID-Prefixes on a Map-Server by sending LISP Map-Register messages. A Map-Register message includes authentication data, so prior to sending a Map-Register message, the ETR and Map-Server must be configured with a shared secret or other relevant authentication information. A Map-Server's configuration must also include a list of the EID-Prefixes for which each ETR is authoritative. Upon receipt of a Map-Register from an ETR, a Map-Server accepts only EID-Prefixes that are configured for that
ETR通过发送LISP映射寄存器消息在映射服务器上发布其EID前缀。地图注册信息包括身份验证数据，因此在发送地图注册信息之前，ETR和地图服务器必须配置共享密钥或其他相关身份验证信息。地图服务器的配置还必须包括一个EID前缀列表，每个ETR对该前缀具有权威性。从ETR收到映射寄存器后，映射服务器仅接受为此配置的EID前缀
ETR. Failure to implement such a check would leave the mapping system vulnerable to trivial EID-Prefix hijacking attacks. As developers and operators gain experience with the mapping system, additional, stronger security measures may be added to the registration process.
ETR。未能实现这样的检查将使映射系统容易受到简单的EID前缀劫持攻击。随着开发商和运营商获得测绘系统的经验，注册过程中可能会增加更多、更强大的安全措施。
In addition to the set of EID-Prefixes defined for each ETR that may register, a Map-Server is typically also configured with one or more aggregate prefixes that define the part of the EID numbering space assigned to it. When LISP+ALT is the database in use, aggregate EID-Prefixes are implemented as discard routes and advertised into ALT BGP. The existence of aggregate EID-Prefixes in a Map-Server's database means that it may receive Map Requests for EID-Prefixes that match an aggregate but do not match a registered prefix; Section 4.3 describes how this is handled.
除了为每个可能注册的ETR定义的EID前缀集外，映射服务器通常还配置有一个或多个聚合前缀，这些前缀定义分配给它的EID编号空间的一部分。当LISP+ALT是正在使用的数据库时，聚合EID前缀作为丢弃路由实现，并播发到ALT BGP中。地图服务器数据库中存在聚合EID前缀，这意味着它可能会收到与聚合匹配但与注册前缀不匹配的EID前缀的地图请求；第4.3节描述了如何处理这一问题。
Map-Register messages are sent periodically from an ETR to a Map-Server with a suggested interval between messages of one minute. A Map-Server should time out and remove an ETR's registration if it has not received a valid Map-Register message within the past three minutes. When first contacting a Map-Server after restart or changes to its EID-to-RLOC database mappings, an ETR may initially send Map-Register messages at an increased frequency, up to one every 20 seconds. This "quick registration" period is limited to five minutes in duration.
地图注册信息从ETR定期发送到地图服务器，建议消息间隔为一分钟。如果地图服务器在过去三分钟内未收到有效的地图注册信息，则应超时并删除ETR的注册。当重新启动或更改其EID到RLOC数据库映射后首次联系地图服务器时，ETR最初可能会以更高的频率发送地图注册信息，最多每20秒发送一条。这一“快速注册”时间限制为五分钟。
An ETR may request that a Map-Server explicitly acknowledge receipt and processing of a Map-Register message by setting the "want-map-notify" (M-bit) flag. A Map-Server that receives a Map-Register with this flag set will respond with a Map-Notify message. Typical use of this flag by an ETR would be to set it for Map-Register messages sent during the initial "quick registration" with a Map-Server but then set it only occasionally during steady-state maintenance of its association with that Map-Server. Note that the Map-Notify message is sent to UDP destination port 4342, not to the source port specified in the original Map-Register message.
ETR可通过设置“想要地图通知”（M位）标志，请求地图服务器明确确认收到和处理地图注册信息。接收具有此标志集的映射寄存器的映射服务器将以映射通知消息进行响应。ETR使用此标志的典型用途是为地图服务器初始“快速注册”期间发送的地图注册信息设置此标志，但仅在与该地图服务器关联的稳定状态维护期间偶尔设置此标志。请注意，映射通知消息发送到UDP目标端口4342，而不是原始映射寄存器消息中指定的源端口。
Note that a one-minute minimum registration interval during maintenance of an ETR-Map-Server association places a lower bound on how quickly and how frequently a mapping database entry can be updated. This may have implications for what sorts of mobility can be supported directly by the mapping system; shorter registration intervals or other mechanisms might be needed to support faster mobility in some cases. For a discussion on one way that faster mobility may be implemented for individual devices, please see [LISP-MN].
请注意，在维护ETR地图服务器关联期间，最短一分钟的注册间隔为地图数据库条目的更新速度和频率设置了下限。这可能意味着测绘系统可以直接支持哪些类型的流动性；在某些情况下，可能需要更短的注册间隔或其他机制来支持更快的移动性。有关为单个设备实现更快移动性的一种方法的讨论，请参见[LISP-MN]。
An ETR may also request, by setting the "proxy Map-Reply" flag (P-bit) in the Map-Register message, that a Map-Server answer Map-Requests instead of forwarding them to the ETR. See [RFC6830] for details on how the Map-Server sets certain flags (such as those indicating whether the message is authoritative and how returned Locators should be treated) when sending a Map-Reply on behalf of an ETR. When an ETR requests proxy reply service, it should include all RLOCs for all ETRs for the EID-Prefix being registered, along with the routable flag ("R-bit") setting for each RLOC. The Map-Server includes all of this information in Map-Reply messages that it sends on behalf of the ETR. This differs from a non-proxy registration, since the latter need only provide one or more RLOCs for a Map-Server to use for forwarding Map-Requests; the registration information is not used in Map-Replies, so it being incomplete is not incorrect.
ETR还可以通过在Map Register消息中设置“proxy Map Reply”（代理映射回复）标志（P位）请求Map服务器应答Map请求，而不是将其转发给ETR。请参阅[RFC6830]了解有关在代表ETR发送映射回复时映射服务器如何设置某些标志（例如指示消息是否具有权威性以及如何处理返回的定位器的标志）的详细信息。当ETR请求代理回复服务时，它应该包括所有ETR的所有RLOC（针对注册的EID前缀），以及每个RLOC的可路由标志（“R位”）设置。地图服务器在代表ETR发送的地图回复消息中包含所有这些信息。这与非代理注册不同，因为后者只需要为地图服务器提供一个或多个RLOC以用于转发地图请求；注册信息未在地图回复中使用，因此不完整并不是不正确的。
An ETR that uses a Map-Server to publish its EID-to-RLOC mappings does not need to participate further in the mapping database protocol(s). When using a LISP+ALT mapping database, for example, this means that the ETR does not need to implement GRE or BGP, which greatly simplifies its configuration and reduces its cost of operation.
使用映射服务器发布其EID到RLOC映射的ETR不需要进一步参与映射数据库协议。例如，当使用LISP+ALT映射数据库时，这意味着ETR不需要实现GRE或BGP，这大大简化了其配置并降低了操作成本。
Note that use of a Map-Server does not preclude an ETR from also connecting to the mapping database (i.e., it could also connect to the LISP+ALT network), but doing so doesn't seem particularly useful, as the whole purpose of using a Map-Server is to avoid the complexity of the mapping database protocols.
请注意，使用地图服务器并不妨碍ETR也连接到地图数据库（即，它也可以连接到LISP+ALT网络），但这样做似乎并不特别有用，因为使用地图服务器的全部目的是避免地图数据库协议的复杂性。
Once a Map-Server has EID-Prefixes registered by its client ETRs, it can accept and process Map-Requests for them.
一旦地图服务器的客户端ETR注册了EID前缀，它就可以接受并处理这些前缀的地图请求。
In response to a Map-Request (received over the ALT if LISP+ALT is in use), the Map-Server first checks to see if the destination EID matches a configured EID-Prefix. If there is no match, the Map-Server returns a Negative Map-Reply with action code "Natively-Forward" and a 15-minute TTL. This may occur if a Map Request is received for a configured aggregate EID-Prefix for which no more-specific EID-Prefix exists; it indicates the presence of a non-LISP "hole" in the aggregate EID-Prefix.
为了响应映射请求（如果使用LISP+ALT，则通过ALT接收），映射服务器首先检查目标EID是否与配置的EID前缀匹配。如果没有匹配项，映射服务器将返回一个带有操作代码“本机转发”和15分钟TTL的否定映射回复。如果接收到配置的聚合EID前缀的Map请求，并且没有更具体的EID前缀，则可能会发生这种情况；它表示聚合EID前缀中存在非LISP“孔”。
Next, the Map-Server checks to see if any ETRs have registered the matching EID-Prefix. If none are found, then the Map-Server returns a Negative Map-Reply with action code "Natively-Forward" and a 1-minute TTL.
接下来，地图服务器检查是否有任何ETR注册了匹配的EID前缀。如果没有找到，则映射服务器返回一个带有操作代码“本机转发”和1分钟TTL的否定映射回复。
If any of the registered ETRs for the EID-Prefix have requested proxy reply service, then the Map-Server answers the request instead of forwarding it. It returns a Map-Reply with the EID-Prefix, RLOCs, and other information learned through the registration process.
如果EID前缀的任何已注册ETR已请求代理回复服务，则地图服务器将响应该请求，而不是转发该请求。它返回带有EID前缀、RLOCs和通过注册过程了解到的其他信息的映射回复。
If none of the ETRs have requested proxy reply service, then the Map-Server re-encapsulates and forwards the resulting Encapsulated Map-Request to one of the registered ETRs. It does not otherwise alter the Map-Request, so any Map-Reply sent by the ETR is returned to the RLOC in the Map-Request, not to the Map-Server. Unless also acting as a Map-Resolver, a Map-Server should never receive Map-Replies; any such messages should be discarded without response, perhaps accompanied by the logging of a diagnostic message if the rate of Map-Replies is suggestive of malicious traffic.
如果没有一个ETR请求了代理回复服务，则映射服务器将重新封装生成的封装映射请求，并将其转发给其中一个已注册的ETR。它不会改变Map请求，因此ETR发送的任何Map回复都会返回到Map请求中的RLOC，而不是Map服务器。除非还充当映射解析程序，否则映射服务器永远不会接收映射回复；如果Map回复率提示存在恶意流量，则应在没有响应的情况下丢弃任何此类消息，并可能同时记录诊断消息。
Upon receipt of an Encapsulated Map-Request, a Map-Resolver decapsulates the enclosed message and then searches for the requested EID in its local database of mapping entries (statically configured or learned from associated ETRs if the Map-Resolver is also a Map-Server offering proxy reply service). If it finds a matching entry, it returns a LISP Map-Reply with the known mapping.
收到封装的Map请求后，Map解析器将对所附消息进行解封，然后在其本地映射条目数据库中搜索请求的EID（如果Map解析器也是提供代理回复服务的Map服务器，则静态配置或从相关ETR学习）。如果它找到一个匹配的条目，它将返回一个带有已知映射的LISP映射回复。
If the Map-Resolver does not have the mapping entry and if it can determine that the EID is not in the mapping database (for example, if LISP+ALT is used, the Map-Resolver will have an ALT forwarding table that covers the full EID space), it immediately returns a negative LISP Map-Reply, with action code "Natively-Forward" and a 15-minute TTL. To minimize the number of negative cache entries needed by an ITR, the Map-Resolver should return the least-specific prefix that both matches the original query and does not match any EID-Prefix known to exist in the LISP-capable infrastructure.
如果映射冲突解决程序没有映射条目，并且如果它可以确定EID不在映射数据库中（例如，如果使用LISP+ALT，映射冲突解决程序将有一个覆盖整个EID空间的ALT转发表），它将立即返回一个否定的LISP映射回复，操作代码为“本机转发”和15分钟的TTL。为了最大限度地减少ITR所需的负缓存项的数量，映射解析器应返回与原始查询匹配且与支持LISP的基础结构中已知的任何EID前缀都不匹配的最不特定的前缀。
If the Map-Resolver does not have sufficient information to know whether the EID exists, it needs to forward the Map-Request to another device that has more information about the EID being requested. To do this, it forwards the unencapsulated Map-Request, with the original ITR RLOC as the source, to the mapping database system. Using LISP+ALT, the Map-Resolver is connected to the ALT network and sends the Map-Request to the next ALT hop learned from its ALT BGP neighbors. The Map-Resolver does not send any response to the ITR; since the source RLOC is that of the ITR, the ETR or Map-Server that receives the Map-Request over the ALT and responds will do so directly to the ITR.
如果映射解析程序没有足够的信息来知道EID是否存在，它需要将映射请求转发给另一个具有关于所请求EID的更多信息的设备。为此，它将原始ITR RLOC作为源的未封装映射请求转发到映射数据库系统。使用LISP+ALT，映射解析器连接到ALT网络，并将映射请求发送到从其ALT BGP邻居学习到的下一个ALT跃点。Map解析器不向ITR发送任何响应；由于源RLOC是ITR的源RLOC，因此通过ALT接收Map请求并作出响应的ETR或Map服务器将直接向ITR进行响应。
A Map-Resolver can be set up to use "anycast", where the same address is assigned to multiple Map-Resolvers and is propagated through IGP routing, to facilitate the use of a topologically close Map-Resolver by each ITR.
可以将地图解析程序设置为使用“选播”，其中相同的地址分配给多个地图解析程序，并通过IGP路由进行传播，以便于每个ITR使用拓扑紧密的地图解析程序。
Note that Map-Server associations with ETRs should not use anycast addresses, as registrations need to be established between an ETR and a specific set of Map-Servers, each identified by a specific registration association.
请注意，与ETR的地图服务器关联不应使用选播地址，因为需要在ETR和一组特定的地图服务器之间建立注册，每个服务器由特定的注册关联标识。
There are a number of issues with the Map-Server and Map-Resolver design that are not yet completely understood. Among these are:
地图服务器和地图解析程序设计中有许多问题尚未完全理解。其中包括：
o Constants, such as those used for Map-Register frequency, retransmission timeouts, retransmission limits, Negative Map-Reply TTLs, et al. are subject to further refinement as more experience with prototype deployment is gained.
o 常数，例如用于Map寄存器频率、重传超时、重传限制、负Map应答TTL等的常数，随着原型部署经验的增加，将进一步细化。
o Convergence time when an EID-to-RLOC mapping changes, and mechanisms for detecting and refreshing or removing stale, cached information.
o EID到RLOC映射更改时的收敛时间，以及用于检测、刷新或删除过时缓存信息的机制。
o Deployability and complexity tradeoffs of implementing stronger security measures in both EID-Prefix registration and Map-Request/ Map-Reply processing.
o 在EID前缀注册和Map请求/Map应答处理中实施更强安全措施的可部署性和复杂性权衡。
o Requirements for additional state in the registration process between Map-Servers and ETRs.
o 地图服务器和ETR之间注册过程中的附加状态要求。
A discussion of other issues surrounding LISP deployment may also be found in Section 15 of [RFC6830].
[RFC6830]第15节还讨论了围绕LISP部署的其他问题。
The authors expect that experimentation on the LISP pilot network will help answer open questions surrounding these and other issues.
作者期望在LISP试验网络上的实验将有助于回答围绕这些和其他问题的开放性问题。
The 2-way LISP header nonce exchange documented in [RFC6830] can be used to avoid ITR spoofing attacks.
[RFC6830]中记录的双向LISP头nonce交换可用于避免ITR欺骗攻击。
To publish an authoritative EID-to-RLOC mapping with a Map-Server, an ETR includes authentication data that is a hash of the message using a pair-wise shared key. An implementation must support use of HMAC-SHA-1-96 [RFC2104] and should support use of HMAC-SHA-256-128 [RFC6234] (SHA-256 truncated to 128 bits).
要使用映射服务器发布权威EID到RLOC的映射，ETR包含身份验证数据，该数据是使用成对共享密钥的消息散列。实现必须支持使用HMAC-SHA-1-96[RFC2104]，并应支持使用HMAC-SHA-256-128[RFC6234]（SHA-256截断为128位）。
During experimental and prototype deployment, all authentication key configuration will be manual. Should LISP and its components be considered for IETF standardization, further work will be required to follow the BCP 107 [RFC4107] recommendations on automated key management.
在实验和原型部署期间，所有身份验证密钥配置都将是手动的。如果LISP及其组件被考虑用于IETF标准化，则需要进一步的工作来遵循BCP 107[RFC4107]关于自动密钥管理的建议。
As noted in Section 4.2, a Map-Server should verify that all EID-Prefixes registered by an ETR match the configuration stored on the Map-Server.
如第4.2节所述，地图服务器应验证ETR注册的所有EID前缀是否与地图服务器上存储的配置匹配。
The currently defined authentication mechanism for Map-Register messages does not provide protection against "replay" attacks by a "man-in-the-middle". Additional work is needed in this area.
当前定义的映射注册消息的身份验证机制无法防止“中间人”的“重播”攻击。这方面还需要做更多的工作。
[LISP-SEC] defines a proposed mechanism for providing origin authentication, integrity, anti-replay protection, and prevention of man-in-the-middle and "overclaiming" attacks on the Map-Request/ Map-Reply exchange. Work is ongoing on this and other proposals for resolving these open security issues.
[LISP-SEC]定义了一种建议的机制，用于提供源身份验证、完整性、反重放保护，以及防止中间人攻击和对Map请求/Map应答交换的“过度欺骗”攻击。目前正在就解决这些公开安全问题的这项建议和其他建议开展工作。
While beyond the scope of securing an individual Map-Server or Map-Resolver, it should be noted that a BGP-based LISP+ALT network (if ALT is used as the mapping database infrastructure) can take advantage of standards work on adding security to BGP.
虽然超出了保护单个映射服务器或映射解析器的范围，但应注意，基于BGP的LISP+ALT网络（如果将ALT用作映射数据库基础结构）可以利用有关为BGP添加安全性的标准工作。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
[RFC6234]Eastlake，D.和T.Hansen，“美国安全哈希算法（基于SHA和SHA的HMAC和HKDF）”，RFC 6234，2011年5月。
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013.
[RFC6830]Farinaci，D.，Fuller，V.，Meyer，D.，和D.Lewis，“定位器/身份分离协议（LISP）”，RFC 6830，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月。
[LISP-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.
[LISP-CONS]Brim，S.，Chiapa，N.，Farinaci，D.，Fuller，V.，Lewis，D.，和D.Meyer，“LISP-CONS：LISP的内容分发覆盖网络服务”，正在进行中，2008年4月。
[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月。
[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月。
[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月。
The authors would like to thank Gregg Schudel, Darrel Lewis, John Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, Fabio Maino, and members of the lisp@ietf.org mailing list for their feedback and helpful suggestions.
作者要感谢Gregg Schudel、Darrel Lewis、John Zwiebel、Andrew Partan、Dave Meyer、Isidor Kouvelas、Jesper Skriver、Fabio Maino以及lisp@ietf.org他们的反馈和有用建议的邮件列表。
Special thanks are due to Noel Chiappa for his extensive work on caching with LISP-CONS, some of which may be used by Map-Resolvers.
特别感谢Noel Chiappa在LISP-CONS缓存方面所做的大量工作，其中一些可能会被映射解析器使用。
Authors' Addresses
作者地址
Vince Fuller
文斯·富勒
EMail: vaf@vaf.net
EMail: vaf@vaf.net
Dino Farinacci Cisco Systems Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市塔斯曼大道迪诺·法里纳奇思科系统公司，邮编95134
EMail: farinacci@gmail.com
EMail: farinacci@gmail.com