Internet Engineering Task Force (IETF) V. Fuller
Request for Comments: 8111 VAF.NET Internet Consulting
Category: Experimental D. Lewis
ISSN: 2070-1721 V. Ermagan
Cisco Systems
A. Jain
Juniper Networks
A. Smirnov
Cisco Systems
May 2017
Internet Engineering Task Force (IETF) V. Fuller
Request for Comments: 8111 VAF.NET Internet Consulting
Category: Experimental D. Lewis
ISSN: 2070-1721 V. Ermagan
Cisco Systems
A. Jain
Juniper Networks
A. Smirnov
Cisco Systems
May 2017
Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)
定位器/ID分离协议委托数据库树（LISP-DDT）
Abstract
摘要
This document describes the Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT), a hierarchical distributed database that embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically defined distribution of the EID namespace among a set of LISP-speaking servers called "DDT nodes". Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map-Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated.
本文档描述了定位器/ID分离协议委托数据库树（LISP-DDT），这是一个分层分布式数据库，体现了提供从LISP端点标识符（EID）到路由定位器（RLOC）的映射的授权。它是EID名称空间在一组称为“DDT节点”的LISP语言服务器之间的静态定义分布。每个DDT节点被配置为一个或多个EID前缀的“权威”，以及一组用于映射服务器的RLOC或将更多特定EID前缀委托给的“子”DDT节点。
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 7841.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第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/rfc8111.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8111.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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 ....................................................4
2. Requirements Language ...........................................5
3. Definitions of Terms ............................................6
4. Database Organization ...........................................8
4.1. XEID-Prefixes ..............................................8
4.2. Structure of the DDT Database ..............................8
4.3. Configuring Prefix Delegation ..............................9
4.3.1. The Root DDT Node ..................................10
5. DDT Map-Request ................................................10
6. The Map-Referral Message .......................................11
6.1. Action Codes ..............................................11
6.2. Referral Set ..............................................12
6.3. "Incomplete" Flag .........................................12
6.4. Map-Referral Message Format ...............................13
6.4.1. Signature Section ..................................15
7. DDT Network Elements and Their Operation .......................17
7.1. DDT Node ..................................................17
7.1.1. Matching of a Delegated Prefix (or Sub-prefix) .....17
7.1.2. Missing Delegation from an Authoritative Prefix ....18
7.2. DDT Map-Server ............................................18
7.3. DDT Client ................................................18
7.3.1. Queuing and Sending DDT Map-Requests ...............19
7.3.2. Receiving and Following Referrals ..................20
7.3.3. Handling Referral Errors ...........................22
7.3.4. Referral Loop Detection ............................22
1. Introduction ....................................................4
2. Requirements Language ...........................................5
3. Definitions of Terms ............................................6
4. Database Organization ...........................................8
4.1. XEID-Prefixes ..............................................8
4.2. Structure of the DDT Database ..............................8
4.3. Configuring Prefix Delegation ..............................9
4.3.1. The Root DDT Node ..................................10
5. DDT Map-Request ................................................10
6. The Map-Referral Message .......................................11
6.1. Action Codes ..............................................11
6.2. Referral Set ..............................................12
6.3. "Incomplete" Flag .........................................12
6.4. Map-Referral Message Format ...............................13
6.4.1. Signature Section ..................................15
7. DDT Network Elements and Their Operation .......................17
7.1. DDT Node ..................................................17
7.1.1. Matching of a Delegated Prefix (or Sub-prefix) .....17
7.1.2. Missing Delegation from an Authoritative Prefix ....18
7.2. DDT Map-Server ............................................18
7.3. DDT Client ................................................18
7.3.1. Queuing and Sending DDT Map-Requests ...............19
7.3.2. Receiving and Following Referrals ..................20
7.3.3. Handling Referral Errors ...........................22
7.3.4. Referral Loop Detection ............................22
8. Pseudocode and Decision Tree Diagrams ..........................23
8.1. Map-Resolver Processing of ITR Map-Request ................23
8.1.1. Pseudocode Summary .................................23
8.1.2. Decision Tree Diagram ..............................24
8.2. Map-Resolver Processing of Map-Referral Message ...........25
8.2.1. Pseudocode Summary .................................25
8.2.2. Decision Tree Diagram ..............................27
8.3. DDT Node Processing of DDT Map-Request Message ............28
8.3.1. Pseudocode Summary .................................28
8.3.2. Decision Tree Diagram ..............................30
9. Example Topology and Request/Referral Following ................31
9.1. Lookup of 2001:db8:0103:1::1/128 ..........................33
9.2. Lookup of 2001:db8:0501:8:4::1/128 ........................34
9.3. Lookup of 2001:db8:0104:2::2/128 ..........................35
9.4. Lookup of 2001:db8:0500:2:4::1/128 ........................36
9.5. Lookup of 2001:db8:0500::1/128 (Nonexistent EID) ..........37
10. Securing the Database and Message Exchanges ...................37
10.1. XEID-Prefix Delegation ...................................38
10.2. DDT Node Operation .......................................38
10.2.1. DDT Public Key Revocation .........................38
10.3. Map-Server Operation .....................................39
10.4. Map-Resolver Operation ...................................39
11. Open Issues and Considerations ................................40
12. IANA Considerations ...........................................41
13. Security Considerations .......................................41
14. References ....................................................42
14.1. Normative References .....................................42
14.2. Informative References ...................................43
Acknowledgments ...................................................44
Authors' Addresses ................................................44
8. Pseudocode and Decision Tree Diagrams ..........................23
8.1. Map-Resolver Processing of ITR Map-Request ................23
8.1.1. Pseudocode Summary .................................23
8.1.2. Decision Tree Diagram ..............................24
8.2. Map-Resolver Processing of Map-Referral Message ...........25
8.2.1. Pseudocode Summary .................................25
8.2.2. Decision Tree Diagram ..............................27
8.3. DDT Node Processing of DDT Map-Request Message ............28
8.3.1. Pseudocode Summary .................................28
8.3.2. Decision Tree Diagram ..............................30
9. Example Topology and Request/Referral Following ................31
9.1. Lookup of 2001:db8:0103:1::1/128 ..........................33
9.2. Lookup of 2001:db8:0501:8:4::1/128 ........................34
9.3. Lookup of 2001:db8:0104:2::2/128 ..........................35
9.4. Lookup of 2001:db8:0500:2:4::1/128 ........................36
9.5. Lookup of 2001:db8:0500::1/128 (Nonexistent EID) ..........37
10. Securing the Database and Message Exchanges ...................37
10.1. XEID-Prefix Delegation ...................................38
10.2. DDT Node Operation .......................................38
10.2.1. DDT Public Key Revocation .........................38
10.3. Map-Server Operation .....................................39
10.4. Map-Resolver Operation ...................................39
11. Open Issues and Considerations ................................40
12. IANA Considerations ...........................................41
13. Security Considerations .......................................41
14. References ....................................................42
14.1. Normative References .....................................42
14.2. Informative References ...................................43
Acknowledgments ...................................................44
Authors' Addresses ................................................44
The Locator/ID Separation Protocol (LISP) [RFC6830] specifies an architecture and mechanism for replacing the addresses currently used by IP with two separate namespaces:
定位器/ID分离协议（LISP）[RFC6830]指定了一种体系结构和机制，用于将IP当前使用的地址替换为两个单独的名称空间：
o Endpoint Identifiers (EIDs), used end to end for terminating transport-layer associations, and
o 端点标识符（EID），用于端到端终止传输层关联，以及
o Routing Locators (RLOCs), which are bound to topological locations and are used for routing and forwarding through the Internet infrastructure.
o 路由定位器（RLOC），绑定到拓扑位置，用于通过Internet基础设施进行路由和转发。
[RFC6833] specifies an interface between a database storing EID-to-RLOC mappings and LISP devices that need this information for packet forwarding. The internal organization of such a database is beyond the scope of [RFC6833]. Multiple architectures of the database have been proposed, each having its advantages and disadvantages (see, for example, [RFC6836] and [RFC6837]).
[RFC6833]指定存储EID到RLOC映射的数据库与需要此信息进行数据包转发的LISP设备之间的接口。此类数据库的内部组织超出了[RFC6833]的范围。已经提出了多种数据库架构，每种架构都有其优缺点（例如，请参见[RFC6836]和[RFC6837]）。
This document specifies an architecture for a database of LISP EID-to-RLOC mappings, with an emphasis on high scalability. The LISP Delegated Database Tree (LISP-DDT) is a hierarchical distributed database that embodies the delegation of authority to provide mappings, i.e., its internal structure mirrors the hierarchical delegation of address space. It also provides delegation information to Map-Resolvers, which use the information to locate EID-to-RLOC mappings. A Map-Resolver that needs to locate a given mapping will follow a path through the tree-structured database and will contact, one after another, the DDT nodes along that path until it reaches the leaf DDT node(s) authoritative for the mapping it is seeking.
本文档指定了LISP EID到RLOC映射数据库的体系结构，重点是高可扩展性。LISP委托数据库树（LISP-DDT）是一个分层分布式数据库，体现了提供映射的授权，即其内部结构反映了地址空间的分层委托。它还向映射解析程序提供委托信息，解析程序使用该信息定位EID到RLOC的映射。需要定位给定映射的映射解析器将沿着树结构数据库中的路径，并将沿着该路径一个接一个地与DDT节点联系，直到它到达其正在寻找的映射的叶DDT节点。
LISP offers a general-purpose mechanism for mapping between EIDs and RLOCs. In organizing a database of EID-to-RLOC mappings, this specification extends the definition of the EID numbering space by logically prepending and appending several fields for purposes of defining the database index key:
LISP为EID和RLOC之间的映射提供了一种通用机制。在组织EID到RLOC映射的数据库时，本规范扩展了EID编号空间的定义，方法是在逻辑上预先添加和附加几个字段，以定义数据库索引键：
o Database-ID (DBID) (16 bits),
o 数据库ID（DBID）（16位），
o Instance Identifier (IID) (32 bits),
o 实例标识符（IID）（32位），
o Address Family Identifier (AFI) (16 bits), and
o 地址族标识符（AFI）（16位），以及
o EID-prefix (variable, according to the AFI value).
o EID前缀（变量，根据AFI值）。
The resulting concatenation of these fields is termed an "Extended EID-prefix", or XEID-prefix.
这些字段的结果连接称为“扩展EID前缀”或XEID前缀。
LISP-DDT defines a new device type, the DDT node, that is configured as authoritative for one or more XEID-prefixes. It is also configured with the set of more-specific sub-prefixes that are further delegated to other DDT nodes. To delegate a sub-prefix, the "parent" DDT node is configured with the RLOCs of each child DDT node that is authoritative for the sub-prefix. Each RLOC either points to a DDT Map-Server (MS) to which an Egress Tunnel Router (ETR) has registered that sub-prefix or points to another DDT node in the database tree that further delegates the sub-prefix. See [RFC6833] for a description of the functionality of the Map-Server and Map-Resolver. Note that the target of a delegation must always be an RLOC (not an EID) to avoid any circular dependency.
LISP-DDT定义了一种新的设备类型，即DDT节点，它被配置为一个或多个XEID前缀的权威设备。它还配置了一组更具体的子前缀，这些子前缀进一步委托给其他DDT节点。为了委托子前缀，“父”DDT节点配置有每个子DDT节点的RLOC，该子前缀具有权威性。每个RLOC要么指向出口隧道路由器（ETR）已注册该子前缀的DDT映射服务器（MS），要么指向数据库树中进一步委托该子前缀的另一个DDT节点。有关映射服务器和映射解析器功能的说明，请参见[RFC6833]。请注意，委派的目标必须始终是RLOC（而不是EID），以避免任何循环依赖。
To provide a mechanism for traversing the database tree, LISP-DDT defines a new LISP message type, the Map-Referral, which is returned to the sender of a Map-Request when the receiving DDT node can refer the sender to another DDT node that has more detailed information. See Section 6 for the definition of the Map-Referral message.
为了提供一种遍历数据库树的机制，LISP-DDT定义了一种新的LISP消息类型，即映射引用，当接收DDT节点可以将发送方引用到另一个具有更详细信息的DDT节点时，该消息类型将返回给映射请求的发送方。有关Map参考消息的定义，请参见第6节。
To find an EID-to-RLOC mapping, a LISP-DDT client, usually a DDT Map-Resolver, starts by sending an Encapsulated Map-Request to a preconfigured DDT node RLOC. The DDT node responds with a Map-Referral message indicating that either (1) it will find the requested mapping to complete processing of the request or (2) the DDT client should contact another DDT node that has more-specific information; in the latter case, the DDT node then sends a new Encapsulated Map-Request to the next DDT node and the process repeats in an iterative manner.
要查找EID到RLOC的映射，LISP-DDT客户端（通常是DDT映射解析器）首先向预配置的DDT节点RLOC发送封装的映射请求。DDT节点响应一条Map参考消息，指示（1）它将找到请求的映射以完成请求的处理，或者（2）DDT客户端应联系另一个具有更具体信息的DDT节点；在后一种情况下，DDT节点随后向下一DDT节点发送新的封装Map请求，并且该过程以迭代方式重复。
Conceptually, this is similar to the way that a client of the Domain Name System (DNS) follows referrals (DNS responses that contain only NS records) from a series of DNS servers until it finds an answer.
从概念上讲，这类似于域名系统（DNS）的客户机遵循一系列DNS服务器的引用（仅包含NS记录的DNS响应），直到找到答案。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Extended EID (XEID): a LISP EID extended with data uniquely identifying the address space to which it belongs (LISP IID, address family, etc.). See Section 4.1 for a detailed description of XEID data.
扩展EID（XEID）：用唯一标识其所属地址空间（LISP IID、地址族等）的数据扩展的LISP EID。有关XEID数据的详细说明，请参见第4.1节。
Extended EID-prefix (XEID-prefix): a LISP EID-prefix prepended with XEID data. An XEID-prefix is used as a key index into the DDT database. XEID-prefixes are used to describe database organization and are not seen as a single entity in protocol messages, though messages contain individual fields constituting XEID-prefixes.
扩展EID前缀（XEID前缀）：以XEID数据为前缀的LISP EID前缀。XEID前缀用作DDT数据库的键索引。XEID前缀用于描述数据库组织，在协议消息中不被视为单个实体，尽管消息包含构成XEID前缀的各个字段。
DDT node: a network infrastructure component responsible for specific XEID-prefix(es) and for the delegation of more-specific sub-prefixes to other DDT nodes.
DDT节点：一个网络基础设施组件，负责特定的XEID前缀，并将更特定的子前缀委托给其他DDT节点。
DDT client: a network infrastructure component that sends DDT Map-Request messages and implements the iterative following of Map-Referral results. Typically, a DDT client will be a Map-Resolver (as defined by [RFC6833]), but it is also possible for an Ingress Tunnel Router (ITR) to implement DDT client functionality.
DDT客户端：一个网络基础设施组件，用于发送DDT映射请求消息并实现映射引用结果的迭代跟踪。通常，DDT客户端将是映射解析器（如[RFC6833]所定义），但入口隧道路由器（ITR）也可以实现DDT客户端功能。
DDT Map-Server: a DDT node that also implements Map-Server functionality (forwarding Map-Requests and/or returning Map-Replies if offering a proxy Map-Reply service) for a subset of its delegated prefixes. Map-Server functions, including proxying Map-Replies, are described in [RFC6833].
DDT映射服务器：一个DDT节点，它还为其委派前缀的子集实现映射服务器功能（转发映射请求和/或返回映射答复，如果提供代理映射答复服务）。[RFC6833]中描述了地图服务器功能，包括代理地图回复。
DDT Map-Server peers: a list of all DDT Map-Servers performing Map-Server functionality for the same prefix. If peers are configured on a DDT Map-Server, then the latter will provide complete information about the prefix in its Map-Replies; otherwise, the Map-Server will mark the returned reply as potentially incomplete.
DDT地图服务器对等点：为同一前缀执行地图服务器功能的所有DDT地图服务器的列表。如果在DDT Map服务器上配置了对等点，则后者将在其Map应答中提供有关前缀的完整信息；否则，映射服务器会将返回的回复标记为可能不完整。
DDT Map-Resolver: a network infrastructure element that implements both DDT client functionality and Map-Resolver functionality as defined by [RFC6833]. A DDT Map-Resolver accepts Map-Requests from ITRs, sends DDT Map-Requests to DDT nodes, and implements the iterative following of Map-Referrals. Note that Map-Resolvers do not respond to clients that sent Map-Requests; they only ensure that the Map-Request has been forwarded to a LISP device (ETR or proxy Map-Server) that will provide an authoritative response to the original requester. A DDT Map-Resolver will typically
DDT映射解析程序：一种网络基础设施元素，实现[RFC6833]定义的DDT客户端功能和映射解析程序功能。DDT映射解析器接受来自ITR的映射请求，将DDT映射请求发送到DDT节点，并实现映射引用的迭代跟踪。请注意，映射解析程序不响应发送映射请求的客户端；它们仅确保映射请求已转发到LISP设备（ETR或代理映射服务器），该设备将向原始请求者提供权威响应。DDT映射解析器通常会
maintain a cache (termed the "referral cache") of previously received Map-Referral message results containing RLOCs for DDT nodes responsible for XEID-prefixes of interest.
维护先前接收的Map参考消息结果的缓存（称为“参考缓存”），其中包含负责感兴趣的XEID前缀的DDT节点的RLOC。
Encapsulated Map-Request: a LISP Map-Request that is carried within an Encapsulated Control Message and that has an additional LISP header prepended to it. Sent to UDP destination port 4342. The "outer" addresses are globally routable IP addresses, also known as RLOCs. Used by an ITR when sending a Map-Request to a Map-Resolver and by a Map-Server when forwarding a Map-Request to an ETR as documented in [RFC6833].
封装的映射请求：封装的控制消息中包含的一个LISP映射请求，该请求前面有一个附加的LISP头。发送到UDP目标端口4342。“外部”地址是全局可路由的IP地址，也称为RLOC。ITR在向Map解析器发送Map请求时使用，Map服务器在向ETR转发Map请求时使用，如[RFC6833]中所述。
DDT Map-Request: an Encapsulated Map-Request sent by a DDT client to a DDT node. The "DDT-originated" flag is set in the encapsulation header, indicating that the DDT node should return Map-Referral messages if the Map-Request EID matches a delegated XEID-prefix known to the DDT node. Section 7.3.1 describes how DDT Map-Requests are sent. Section 5 defines the position of the "DDT-originated" flag in the Encapsulated Control Message header.
DDT映射请求：DDT客户端向DDT节点发送的封装映射请求。在封装头中设置“DDT origined”标志，指示如果映射请求EID与DDT节点已知的委托XEID前缀匹配，DDT节点应返回映射引用消息。第7.3.1节描述了DDT Map请求的发送方式。第5节定义了“源自DDT”标志在封装控制报文头中的位置。
Authoritative XEID-prefix: an XEID-prefix delegated to a DDT node and for which the DDT node may provide further delegations of more-specific sub-prefixes.
权威XEID前缀：委托给DDT节点的XEID前缀，DDT节点可为其提供更具体子前缀的进一步委托。
Map-Referral: a LISP message sent by a DDT node in response to a DDT Map-Request for an XEID that matches a configured XEID-prefix delegation. A non-Negative Map-Referral includes a "referral" -- a set of RLOCs for DDT nodes that have information about the more-specific XEID-prefix covering the requested XEID; a DDT client "follows the referral" by sending another DDT Map-Request to one of those RLOCs to obtain either an answer or another referral to DDT nodes responsible for an XEID-prefix that is even more specific. See Sections 7.1 and 7.3.2 for details on the sending and processing of Map-Referral messages.
映射引用：DDT节点发送的LISP消息，用于响应DDT映射请求，请求与配置的XEID前缀委托匹配的XEID。非负Map参考包括“参考”——DDT节点的一组RLOC，其具有关于覆盖请求的XEID的更具体的XEID前缀的信息；DDT客户端通过向其中一个RLOC发送另一个DDT映射请求来“跟踪引用”，以获得应答或对负责更具体的XEID前缀的DDT节点的另一个引用。有关Map参考消息的发送和处理的详细信息，请参见第7.1节和第7.3.2节。
Negative Map-Referral: an answer from an authoritative DDT node that there is no mapping for the requested XEID. A Negative Map-Referral is a Map-Referral sent in response to a DDT Map-Request that matches an authoritative XEID-prefix but for which there is no delegation configured (or no ETR registration, if sent by a DDT Map-Server).
否定映射引用：来自权威DDT节点的回答，表示请求的XEID没有映射。负面Map参考是响应DDT Map请求而发送的Map参考，该请求与权威XEID前缀匹配，但没有为其配置委派（或没有ETR注册，如果由DDT Map服务器发送）。
Pending Request List: the set of outstanding requests for which a DDT Map-Resolver has received Encapsulated Map-Requests from its clients seeking EID-to-RLOC mapping for an XEID. Each entry in the list contains additional state needed by the referral-following process, including the XEID, requester(s) of the XEID (typically one or more ITRs), saved information about the
挂起的请求列表：DDT映射解析程序已从其客户端接收到封装的映射请求的一组未完成的请求，这些请求寻求XEID的EID到RLOC映射。列表中的每个条目都包含以下引用过程所需的附加状态，包括XEID、XEID的请求者（通常是一个或多个itr）、已保存的有关
last referral received and followed (matching XEID-prefix, action code, RLOC set, index of the last RLOC queried in the RLOC set), and any LISP-Security (LISP-SEC) information [LISP-SEC] that was included in the DDT client Map-Request. An entry in the list may be interchangeably termed a "pending request list entry" or simply a "pending request".
收到并遵循最后一次引用（匹配XEID前缀、操作代码、RLOC集、RLOC集中查询的最后一次RLOC的索引）以及DDT客户端映射请求中包含的任何LISP安全（LISP-SEC）信息[LISP-SEC]。列表中的条目可以互换地称为“未决请求列表条目”或简单地称为“未决请求”。
For definitions of other terms -- notably Map-Request, Map-Reply, ITR, ETR, Map-Server, and Map-Resolver -- please consult the LISP specification [RFC6830] and the LISP Mapping Service specification [RFC6833].
有关其他术语的定义，尤其是映射请求、映射回复、ITR、ETR、映射服务器和映射解析器，请参考LISP规范[RFC6830]和LISP映射服务规范[RFC6833]。
A DDT database is indexed by Extended EID-prefixes (XEID-prefixes). An XEID-prefix is a LISP EID-prefix, together with data extending it to uniquely identify the address space of the prefix. An XEID-prefix is composed of four binary-encoded fields, ordered by significance: DBID (16 bits), IID (32 bits), AFI (16 bits), and EID-prefix (variable, according to the AFI value). The fields are concatenated, with the most significant fields as listed above.
DDT数据库由扩展EID前缀（XEID前缀）编制索引。XEID前缀是LISP EID前缀，以及扩展它以唯一标识前缀地址空间的数据。XEID前缀由四个二进制编码字段组成，按重要性排序：DBID（16位）、IID（32位）、AFI（16位）和EID前缀（变量，根据AFI值）。这些字段是串联的，最重要的字段如上所列。
The DBID is the LISP-DDT Database-ID, a 16-bit field provided to allow the definition of multiple databases. Implementations that are compliant with this document must always set this field to 0. Other values of the DBID are reserved for future use.
DBID是LISP-DDT数据库ID，一个16位字段，用于定义多个数据库。符合此文档的实现必须始终将此字段设置为0。DBID的其他值保留供将来使用。
The Instance ID (IID) is a 32-bit value describing the context of the EID-prefix, if the latter is intended for use in an environment where addresses may not be unique, such as in a Virtual Private Network where the [RFC1918] address space is used. See Section 5.5 of [RFC6830] for more discussion of IIDs. Encoding of the IID is specified by [RFC8060].
实例ID（IID）是描述EID前缀上下文的32位值，如果后者用于地址可能不唯一的环境中，例如在使用[RFC1918]地址空间的虚拟专用网络中。有关IID的更多讨论，请参见[RFC6830]第5.5节。IID的编码由[RFC8060]指定。
The AFI is a 16-bit value defining the syntax of the EID-prefix. AFI values are assigned by IANA [AFI].
AFI是定义EID前缀语法的16位值。AFI值由IANA[AFI]分配。
The LISP-DDT database for each DDT node is organized as a tree structure that is indexed by XEID-prefixes. Leaves of the database tree describe the delegation of authority between DDT nodes (see Section 4.3 for details regarding delegation and information kept in the database entries).
每个DDT节点的LISP-DDT数据库组织为一个树结构，由XEID前缀索引。数据库树的叶子描述了DDT节点之间的授权（有关授权和数据库条目中保存的信息的详细信息，请参见第4.3节）。
DDT Map-Requests sent by the DDT client to DDT nodes always contain specific values for the DBID, IID, and AFI; unspecified values or ranges of values are never used for any of these fields. Thus, an XEID-prefix used as a key for searches in the database tree will have a length of at least 64 bits.
DDT客户端向DDT节点发送的DDT映射请求始终包含DBID、IID和AFI的特定值；这些字段中的任何字段都不会使用未指定的值或值范围。因此，用作数据库树中搜索键的XEID前缀的长度至少为64位。
A DDT node may, for example, be authoritative for a consecutive range of 3-tuples (DBID, IID, AFI) and all associated EID-prefixes, or only for a specific EID-prefix of a single 3-tuple. Thus, XEID-prefixes/keys of the database tree leaves may have lengths less than, equal to, or more than 64 bits.
例如，DDT节点可以对连续范围的3元组（DBID、IID、AFI）和所有相关联的EID前缀具有权威性，或者仅对单个3元组的特定EID前缀具有权威性。因此，数据库树叶的XEID前缀/键的长度可能小于、等于或大于64位。
It is important to note that LISP-DDT does not store actual EID-to-RLOC mappings; it is, rather, a distributed index that can be used to find the devices (ETRs that registered their EIDs with DDT Map-Servers) that can be queried with LISP to obtain those mappings. Changes to EID-to-RLOC mappings are made on the ETRs that define them, not to any DDT node configuration. DDT node configuration changes are only required when branches of the database hierarchy are added, removed, or modified.
需要注意的是，LISP-DDT不存储实际的EID到RLOC的映射；相反，它是一个分布式索引，可用于查找设备（向DDT映射服务器注册EID的ETR），可使用LISP查询这些设备以获得这些映射。对EID到RLOC映射的更改是在定义它们的ETR上进行的，而不是在任何DDT节点配置上进行的。只有在添加、删除或修改数据库层次结构的分支时，才需要更改DDT节点配置。
Every DDT node is configured with one or more XEID-prefixes for which it is authoritative, along with a list of delegations of XEID-prefixes to other DDT nodes. A DDT node is required to maintain a list of delegations for all sub-prefixes of its authoritative XEID-prefixes; it also may list "hints", which are prefixes that it knows about that belong to its parents, to the root, or to any other point in the XEID-prefix hierarchy. A delegation (or hint) consists of an XEID-prefix, a set of RLOCs for DDT nodes that have more detailed knowledge of the XEID-prefix, and accompanying security information (for details regarding security information exchange and its use, see Section 10). Those RLOCs are returned in Map-Referral messages when the DDT node receives a DDT Map-Request with an XEID that matches a delegation. A DDT Map-Server will also have a set of sub-prefixes for which it accepts ETR mapping registrations and for which it will forward (or answer, if it provides a proxy Map-Reply service) Map-Requests.
每个DDT节点都配置有一个或多个其具有权威性的XEID前缀，以及向其他DDT节点委派XEID前缀的列表。DDT节点需要维护其权威XEID前缀的所有子前缀的授权列表；它还可以列出“提示”，即它知道的属于其父级、根或XEID前缀层次结构中任何其他点的前缀。委派（或提示）包括一个XEID前缀、一组用于DDT节点的RLOC（这些DDT节点具有更详细的XEID前缀知识）以及附带的安全信息（有关安全信息交换及其使用的详细信息，请参阅第10节）。当DDT节点接收到带有与委派匹配的XEID的DDT Map请求时，这些RLOC将在Map引用消息中返回。DDT地图服务器还将具有一组子前缀，它接受ETR地图注册，并转发（或回答，如果它提供代理地图回复服务）地图请求。
One or more XEID-prefixes for which a DDT node is authoritative, and the delegation of authority for sub-prefixes, are provided as part of the configuration of the DDT node. Implementations will likely develop a language to express this prefix authority and delegation. Since DDT configuration is static (i.e., not exchanged between DDT nodes as part of the protocol itself), such language is implementation dependent and is outside the scope of this specification.
作为DDT节点配置的一部分，提供了DDT节点具有权威性的一个或多个XEID前缀以及子前缀的授权。实现可能会开发一种语言来表达这种前缀权限和委托。由于DDT配置是静态的（即，不作为协议本身的一部分在DDT节点之间交换），因此这种语言依赖于实现，不在本规范的范围内。
The root DDT node is the logical "top" of the distributed database hierarchy. It is authoritative for all XEID-prefixes -- that is, for all valid 3-tuples (DBID, IID, AFI) and their EID-prefixes. A DDT Map-Request that matches no configured XEID-prefix will be referred to the root node (see Section 8 for a formal description of conditions where a DDT Map-Request is forwarded to the root node). The root node in a particular instantiation of LISP-DDT therefore MUST be configured, at a minimum, with delegations for all defined IIDs and AFIs.
根DDT节点是分布式数据库层次结构的逻辑“顶部”。它对所有XEID前缀都是权威的——也就是说，对所有有效的3元组（DBID、IID、AFI）及其EID前缀都是权威的。不匹配配置的XEID前缀的DDT-Map请求将被引用到根节点（有关DDT-Map请求转发到根节点的条件的正式描述，请参见第8节）。因此，LISP-DDT特定实例化中的根节点必须至少配置为所有已定义IID和AFI的委托。
A DDT client (usually a Map-Resolver) uses LISP Encapsulated Control Messages (ECMs) to send Map-Request messages to a DDT node. The format of the ECM is defined by [RFC6830]. This specification adds to the Encapsulated Control Message (ECM) header a new flag, "DDT-originated", as shown in the diagram and described below.
DDT客户端（通常是映射解析器）使用LISP封装的控制消息（ECM）向DDT节点发送映射请求消息。ECM的格式由[RFC6830]定义。本规范在封装控制信息（ECM）标题中添加了一个新标志“DDT起源”，如图所示，如下所述。
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|D| 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|D| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D: The "DDT-originated" flag. This flag is set by a DDT client to indicate that the receiver SHOULD return Map-Referral messages as appropriate. The use of this flag is further described in Section 7.3.1. This bit is allocated from LISP message header bits marked as "Reserved" in [RFC6830].
D：“源自滴滴涕”的标志。DDT客户端设置此标志，以指示接收方应酌情返回Map参考消息。第7.3.1节进一步说明了该标志的使用。该位是从[RFC6830]中标记为“保留”的LISP消息头位分配的。
This specification defines a new LISP message called the Map-Referral message. A Map-Referral message is sent by a DDT node to a DDT client in response to a DDT Map-Request message. See Section 6.4 for a detailed layout of the Map-Referral message fields.
此规范定义了一个新的LISP消息，称为映射引用消息。DDT节点向DDT客户端发送Map参考消息，以响应DDT Map请求消息。有关地图参考消息字段的详细布局，请参见第6.4节。
The message consists of an action code along with delegation information about the XEID-prefix that matches the requested XEID.
该消息由一个操作代码以及与请求的XEID匹配的XEID前缀的委托信息组成。
The action codes are as follows:
行动代码如下：
NODE-REFERRAL (0): indicates that the replying DDT node has delegated an XEID-prefix that matches the requested XEID to one or more other DDT nodes. The Map-Referral message contains a "map-record" with additional information -- most significantly, the set of RLOCs to which the prefix has been delegated -- that is used by a DDT client to "follow" the referral.
节点引用（0）：表示应答DDT节点已将与请求的XEID匹配的XEID前缀委派给一个或多个其他DDT节点。Map参考消息包含一个带有附加信息的“Map记录”——最重要的是，前缀已委托给的RLOC集——DDT客户端使用该信息“跟踪”参考。
MS-REFERRAL (1): indicates that the replying DDT node has delegated an XEID-prefix that matches the requested XEID to one or more DDT Map-Servers. It contains the same additional information as a NODE-REFERRAL but is handled slightly differently by the receiving DDT client (see Section 7.3.2).
MS-REFERRAL（1）：表示应答DDT节点已将与请求的XEID匹配的XEID前缀委派给一个或多个DDT映射服务器。它包含与节点转诊相同的附加信息，但接收DDT客户端的处理方式略有不同（见第7.3.2节）。
MS-ACK (2): indicates that the replying DDT Map-Server received a DDT Map-Request that matches an authoritative XEID-prefix for which it has one or more registered ETRs. This means that the request has been forwarded to one of those ETRs to provide an answer to the querying ITR.
MS-ACK（2）：表示应答DDT Map服务器接收到一个DDT Map请求，该请求与权威XEID前缀匹配，该前缀具有一个或多个已注册的ETR。这意味着请求已转发到其中一个ETR，以提供对查询ITR的答复。
MS-NOT-REGISTERED (3): indicates that the replying DDT Map-Server received a Map-Request for one of its configured XEID-prefixes that has no ETRs registered.
MS-NOT-REGISTERED（3）：表示应答DDT映射服务器接收到一个映射请求，请求其配置的XEID前缀之一未注册ETR。
DELEGATION-HOLE (4): indicates that the requested XEID matches a non-delegated sub-prefix of the XEID space. This is a non-LISP "hole", which has not been delegated to any DDT Map-Server or ETR. See Section 7.1.2 for details. Also sent by a DDT Map-Server with authoritative configuration covering the requested EID but for which no specific site ETR is configured.
DELEGATION-HOLE（4）：表示请求的XEID与XEID空间的非委托子前缀匹配。这是一个非LISP“漏洞”，尚未委托给任何DDT地图服务器或ETR。详见第7.1.2节。也由DDT地图服务器发送，其权威配置涵盖请求的EID，但未为其配置特定站点ETR。
NOT-AUTHORITATIVE (5): indicates that the replying DDT node received a Map-Request for an XEID for which it is not authoritative and has no configured matching hint referrals. This can occur if a cached referral has become invalid due to a change in the database hierarchy. However, if such a DDT node has a "hint" delegation covering the requested EID, it MAY choose to return NODE-REFERRAL or MS-REFERRAL as appropriate. When returning action code NOT-AUTHORITATIVE, the DDT node MUST provide the EID-prefix received in the request and the TTL MUST be set to 0.
NOT-Authority（5）：表示应答DDT节点接收到一个XEID的映射请求，该请求不是权威的，并且没有配置匹配的提示引用。如果缓存的引用由于数据库层次结构中的更改而变得无效，则可能发生这种情况。然而，如果这样的DDT节点具有覆盖所请求的EID的“提示”委托，则它可以根据需要选择返回node-REFERRAL或MS-REFERRAL。当返回非权威的操作代码时，DDT节点必须提供请求中接收到的EID前缀，并且TTL必须设置为0。
For "positive" action codes (NODE-REFERRAL, MS-REFERRAL, MS-ACK), a DDT node MUST include in the Map-Referral message a list of RLOCs for DDT nodes that are authoritative for the XEID-prefix being returned; a DDT client uses this information to contact one of those DDT nodes as it "follows" a referral.
对于“积极”行动代码（NODE-REFERRAL、MS-REFERRAL、MS-ACK），DDT节点必须在Map REFERRAL消息中包含DDT节点的RLOC列表，这些RLOC对于返回的XEID前缀具有权威性；DDT客户端使用此信息联系其中一个DDT节点，因为它“跟踪”了一个转诊。
A DDT node sets the "Incomplete" flag in a Map-Referral message if the Referral Set is incomplete; this is intended to prevent a DDT client from caching a referral with incomplete information. A DDT node MUST set the "Incomplete" flag in the following cases:
如果参考集不完整，DDT节点在地图参考消息中设置“不完整”标志；这是为了防止DDT客户端缓存信息不完整的引用。在下列情况下，DDT节点必须设置“不完整”标志：
o If it is setting action code MS-ACK or MS-NOT-REGISTERED but the matching XEID-prefix is not flagged as "complete" in the configuration. The XEID-prefix configuration on the DDT Map-Server SHOULD be marked as "complete" when the configuration of the XEID-prefix lists all "peer" DDT nodes that are also authoritative for the same XEID-prefix or when it is known that a local DDT node is the only authoritative node for the XEID-prefix.
o 如果正在设置操作代码MS-ACK或MS-NOT-REGISTER，但匹配的XEID前缀在配置中未标记为“完成”。当XEID前缀的配置列出了对同一XEID前缀具有权威性的所有“对等”DDT节点时，或者当已知本地DDT节点是XEID前缀的唯一权威节点时，DDT映射服务器上的XEID前缀配置应标记为“完成”。
o If it is setting action code NOT-AUTHORITATIVE.
o 如果设置的动作代码不具有权威性。
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=6 | Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Referral Count| EID mask-len | ACT |A|I| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c |SigCnt | Map Version Number | EID-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-prefix ... |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| e | Unused Flags |L|p|R| Loc-AFI |
| f +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator ... |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~ Sig section ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=6 | Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Referral Count| EID mask-len | ACT |A|I| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c |SigCnt | Map Version Number | EID-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-prefix ... |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| e | Unused Flags |L|p|R| Loc-AFI |
| f +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator ... |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~ Sig section ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type value 6 was reserved for future use in [RFC6830]. This document allocates this value to identify Map-Referral messages.
类型：类型值6保留在[RFC6830]中供将来使用。此文档分配此值以标识映射引用消息。
ACT: The ACT (Action) field of the mapping Record in a Map-Referral message encodes one of the following six action types: NODE-REFERRAL, MS-REFERRAL, MS-ACK, MS-NOT-REGISTERED, DELEGATION-HOLE, or NOT-AUTHORITATIVE. See Section 6.1 for descriptions of these action types.
ACT：映射引用消息中映射记录的ACT（Action）字段对以下六种操作类型之一进行编码：NODE-Referral、MS-Referral、MS-ACK、MS-NOT-REGISTERED、DELEGATION-HOLE或NOT-Authority。有关这些动作类型的说明，请参见第6.1节。
Incomplete: The "I" bit indicates that a DDT node's Referral Set of locators is incomplete and the receiver of this message SHOULD NOT cache the referral. A DDT sets the "Incomplete" flag, the TTL, and the Action field as follows:
不完整：“I”位表示DDT节点的引用定位器集不完整，此消息的接收者不应缓存引用。DDT设置“未完成”标志、TTL和操作字段，如下所示：
-------------------------------------------------------------------
Type (Action field) Incomplete Referral Set TTL values
-------------------------------------------------------------------
0 NODE-REFERRAL No Yes 1440
-------------------------------------------------------------------
Type (Action field) Incomplete Referral Set TTL values
-------------------------------------------------------------------
0 NODE-REFERRAL No Yes 1440
1 MS-REFERRAL No Yes 1440
1 MS-转诊编号：是1440
2 MS-ACK * * 1440
2 MS-ACK**1440
3 MS-NOT-REGISTERED * * 1
3 MS-未注册**1
4 DELEGATION-HOLE No No 15
4号孔15号
5 NOT-AUTHORITATIVE Yes No 0
-------------------------------------------------------------------
5 NOT-AUTHORITATIVE Yes No 0
-------------------------------------------------------------------
*: The "Incomplete" flag setting for the Map-Server-originated referral of MS-ACK and MS-NOT-REGISTERED types depends on whether the Map-Server has the full peer Map-Server configuration for the same prefix and has encoded the information in the mapping Record. The "Incomplete" bit is not set when the Map-Server has encoded the information; this means that the Referral Set includes all the RLOCs of all Map-Servers that serve the prefix. It MUST be set when the configuration of the Map-Server does not flag the matching prefix as configured with the complete information about "peer" Map-Servers or when the Map-Server does not return all configured locators.
*：源于MS-ACK和MS-NOT-REGISTERED类型的映射服务器引用的“未完成”标志设置取决于映射服务器是否具有相同前缀的完整对等映射服务器配置，以及是否已在映射记录中对信息进行编码。当地图服务器对信息进行编码时，未设置“不完整”位；这意味着引用集包括提供前缀的所有地图服务器的所有RLOC。当地图服务器的配置未将匹配前缀标记为使用“对等”地图服务器的完整信息配置时，或者当地图服务器未返回所有配置的定位器时，必须设置该前缀。
Referral Count: Number of RLOCs in the current Referral Set. This number is equal to the number of "Ref" sections in the message (as shown in the diagram above).
转诊计数：当前转诊集中的RLOC数。该数字等于消息中“Ref”部分的数量（如上图所示）。
SigCnt: Indicates the number of signatures (Signature section) present in the Record. If SigCnt is larger than 0, the signature information captured in a Signature section as described in Section 6.4.1 will be appended to the end of the Record. The number of Signature sections at the end of the Record MUST match the SigCnt. Note that bits occupied by SigCnt were marked as "Reserved" in Records embedded into messages defined by [RFC6830] and were required to be set to zero.
SigCnt：表示记录中存在的签名数（签名部分）。如果SigCnt大于0，则第6.4.1节中描述的签名部分中捕获的签名信息将附加到记录末尾。记录末尾的签名节数必须与SigCnt匹配。注意，SigCnt占用的位在嵌入到[RFC6830]定义的消息中的记录中被标记为“保留”，并且需要设置为零。
Loc-AFI: AFI of the Locator field. If the AFI value is different from the LISP Canonical Address Format (LCAF) AFI, security keys are not included in the Record. If the AFI value is equal to the LCAF AFI, the contents of the LCAF depend on the Type field of the LCAF. LCAF Type 11 is used to store security material along with the AFI of the locator. DDT nodes and DDT Map-Servers can use this LCAF Type to include public keys associated with their child DDT nodes for an XEID-prefix Map-Referral Record. LCAF Types and formats are defined in [RFC8060].
Loc AFI：定位器字段的AFI。如果AFI值与LISP规范地址格式（LCAF）AFI不同，则记录中不包括安全密钥。如果AFI值等于LCAF AFI，则LCAF的内容取决于LCAF的类型字段。LCAF类型11用于存储安全材料以及定位器的AFI。DDT节点和DDT映射服务器可以使用此LCAF类型为XEID前缀映射引用记录包含与其子DDT节点关联的公钥。[RFC8060]中定义了LCAF类型和格式。
Locator: RLOC of a DDT node to which the DDT client is being referred. This is a variable-length field; its length is determined by the Loc-AFI setting.
定位器：DDT客户端所引用的DDT节点的RLOC。这是一个可变长度字段；其长度由Loc AFI设置决定。
All other fields and their descriptions are equivalent to those in the Map-Reply message, as defined in LISP [RFC6830]. Note, though, that the set of RLOCs correspond to the DDT node to be queried as a result of the referral and not to the RLOCs for an actual EID-to-RLOC mapping.
所有其他字段及其描述与映射回复消息中的字段及其描述等效，如LISP[RFC6830]中所定义。但是，请注意，RLOCs集合对应于作为引用结果查询的DDT节点，而不是实际EID到RLOC映射的RLOCs。
SigCnt counts the number of signature sections that appear at the end of the Record. The format of the signature section is described below.
SigCnt统计出现在记录末尾的签名节数。签名部分的格式如下所述。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/| Original Record TTL |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Signature Expiration |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
s | Signature Inception |
i +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
g | Key Tag | Sig Length |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Sig-Algorithm | Reserved | Reserved |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ~ Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/| Original Record TTL |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Signature Expiration |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
s | Signature Inception |
i +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
g | Key Tag | Sig Length |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Sig-Algorithm | Reserved | Reserved |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ~ Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Original Record TTL: The original Record TTL for this Record that is covered by the signature. The Record TTL value is specified in minutes.
原始记录TTL：签名涵盖的该记录的原始记录TTL。记录TTL值以分钟为单位指定。
Signature Expiration and Signature Inception: Specify the validity period for the signature. The signature MUST NOT be used for authentication prior to the inception date and MUST NOT be used for authentication after the expiration date. Each field specifies a date and time in the form of a 32-bit unsigned number of seconds elapsed since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network byte order.
签名到期和签名起始：指定签名的有效期。签名不得用于起始日期之前的身份验证，也不得用于过期日期之后的身份验证。每个字段以32位无符号秒数的形式指定日期和时间，该秒数自1970年1月1日00:00:00 UTC起经过，忽略闰秒，以网络字节顺序排列。
Key Tag: An identifier to specify which key is used for this signature if more than one valid key exists for the signing DDT node.
Key Tag：如果签名DDT节点存在多个有效密钥，则用于指定此签名使用的密钥的标识符。
Sig Length: The length of the Signature field in bytes.
Sig Length：签名字段的长度（以字节为单位）。
Sig-Algorithm: The identifier of the cryptographic algorithm used for the signature. Sig-Algorithm values defined in this specification are listed in Table 1. Implementations conforming to this specification MUST implement at least RSA-SHA256 for DDT signing. Sig-Algorithm type 1 (RSA-SHA1) is deprecated and SHOULD NOT be used.
Sig算法：用于签名的加密算法的标识符。表1列出了本规范中定义的Sig算法值。符合本规范的实现必须至少实现用于DDT签名的RSA-SHA256。Sig算法类型1（RSA-SHA1）已弃用，不应使用。
+---------------+------------+-----------+------------+
| Sig-Algorithm | Name | Reference | Notes |
+---------------+------------+-----------+------------+
| 1 | RSA-SHA1 | [RFC8017] | DEPRECATED |
| | | | |
| 2 | RSA-SHA256 | [RFC8017] | MANDATORY |
+---------------+------------+-----------+------------+
+---------------+------------+-----------+------------+
| Sig-Algorithm | Name | Reference | Notes |
+---------------+------------+-----------+------------+
| 1 | RSA-SHA1 | [RFC8017] | DEPRECATED |
| | | | |
| 2 | RSA-SHA256 | [RFC8017] | MANDATORY |
+---------------+------------+-----------+------------+
Table 1: Sig-Algorithm Values
表1:Sig算法值
Reserved: MUST be set to 0 on transmit and MUST be ignored on receipt.
保留：传输时必须设置为0，接收时必须忽略。
Signature: Contains the cryptographic signature that covers the entire Map-Referral Record to which this signature belongs. For the purpose of computing the signature, the Record TTL (Section 6.4) value is set to the value of Original Record TTL and the Signature field is filled with zeros.
签名：包含覆盖此签名所属的整个映射引用记录的加密签名。为了计算签名，将记录TTL（第6.4节）的值设置为原始记录TTL的值，签名字段用零填充。
As described above, LISP-DDT introduces a new network element -- the DDT node -- and extends the functionality of Map-Servers and Map-Resolvers to send and receive Map-Referral messages. The operation of each of these devices is described below.
如上所述，LISP-DDT引入了一个新的网络元素——DDT节点——并扩展了地图服务器和地图解析程序的功能，以发送和接收地图引用消息。下面描述这些设备中的每一个的操作。
When a DDT node receives a DDT Map-Request, it compares the requested XEID against its list of XEID-prefix delegations and its list of authoritative XEID-prefixes, and proceeds as follows:
当DDT节点接收到DDT映射请求时，它会将请求的XEID与其XEID前缀委派列表和权威XEID前缀列表进行比较，并按如下步骤进行：
If the requested XEID matches one of the DDT node's delegated prefixes, then a Map-Referral message is returned with the matching more-specific XEID-prefix and the set of RLOCs for the referral target DDT nodes, including associated security information (see Section 10 for details on security). If at least one DDT node of the delegation is known to be a DDT Map-Server, then the Map-Referral message SHOULD be sent with action code MS-REFERRAL to indicate to the receiver that LISP-SEC information (if saved in the pending request) SHOULD be included in the next DDT Map-Request; otherwise, the action code NODE-REFERRAL SHOULD be used.
如果请求的XEID与DDT节点的一个委派前缀匹配，则返回一条映射引用消息，其中包含匹配的更具体的XEID前缀和引用目标DDT节点的RLOC集，包括相关的安全信息（有关安全性的详细信息，请参阅第10节）。如果已知委派的至少一个DDT节点是DDT Map服务器，则应发送Map参考消息，并附上操作代码MS-REFERER，以向接收方指示LISP-SEC信息（如果保存在待决请求中）应包含在下一个DDT Map请求中；否则，应使用操作代码节点引用。
Note that a matched delegation does not have to be for a sub-prefix of an authoritative prefix; in addition to being configured to delegate sub-prefixes of an authoritative prefix, a DDT node may also be configured with other XEID-prefixes for which it can provide referrals to DDT nodes anywhere in the database hierarchy. This capability to define "shortcut hints" is never required to be configured, but it may be a useful heuristic for reducing the number of iterations needed to find an EID, particularly for private network deployments.
请注意，匹配的委托不必是权威前缀的子前缀；除了配置为委托权威前缀的子前缀外，DDT节点还可以配置其他XEID前缀，它可以为这些前缀向数据库层次结构中任何位置的DDT节点提供引用。这种定义“快捷提示”的功能从来都不需要配置，但它可能是减少查找EID所需迭代次数的一种有用的启发式方法，特别是对于专用网络部署。
Referral hints, if used properly, may reduce the number of referrals a DDT client needs to follow to locate a DDT Map-Server authoritative for the XEID-prefix being resolved. On the other hand, the incorrect use of hints may create circular dependencies (or "referral loops") between DDT nodes. A DDT client MUST be prepared to handle such circular referrals. See Section 7.3.4 for a discussion of referral loops and measures that the DDT client must implement in order to detect circular referrals and prevent infinite looping.
引用提示如果使用得当，可能会减少DDT客户端需要遵循的引用数量，以查找对正在解析的XEID前缀具有权威性的DDT映射服务器。另一方面，提示的不正确使用可能会在DDT节点之间创建循环依赖（或“引用循环”）。滴滴涕客户必须准备好处理此类循环转介。参见第7.3.4节，了解DDT客户为检测循环转介和防止无限循环而必须实施的转介循环和措施的讨论。
Another danger related to the use of hints is when a DDT deployment spans multiple administrative domains (i.e., different authorities manage DDT nodes in the same DDT database). In this case, an
与使用提示相关的另一个危险是，DDT部署跨越多个管理域（即，不同的机构在同一DDT数据库中管理DDT节点）。在这种情况下
operator managing a DDT node may not be aware of the fact that the node is being referred to by hints. Locator addresses in hints may become stale when referred DDT nodes are taken out of service or change their locator addresses.
管理DDT节点的操作员可能不知道该节点正被提示引用。当引用的DDT节点停止服务或更改其定位器地址时，提示中的定位器地址可能会过时。
If the requested XEID did not match a configured delegation but does match an authoritative XEID-prefix, then the DDT node MUST return a Negative Map-Referral that uses the least-specific XEID-prefix that does not match any XEID-prefix delegated by the DDT node. The action code is set to DELEGATION-HOLE; this indicates that the XEID is not a LISP destination.
如果请求的XEID与配置的委派不匹配，但与权威的XEID前缀匹配，则DDT节点必须返回使用最不特定的XEID前缀的否定映射引用，该前缀与DDT节点委派的任何XEID前缀都不匹配。动作代码设置为-HOLE；这表示XEID不是LISP目标。
If the requested XEID did not match either a configured delegation, an authoritative XEID-prefix, or a hint, then a Negative Map-Referral with action code NOT-AUTHORITATIVE MUST be returned.
如果请求的XEID与配置的委派、权威XEID前缀或提示不匹配，则必须返回操作代码为not-Authority的否定映射引用。
When a DDT Map-Server receives a DDT Map-Request, its operation is similar to that of a DDT node, with additional processing as follows:
当DDT Map服务器收到DDT Map请求时，其操作与DDT节点类似，附加处理如下：
o If the requested XEID matches a registered XEID-prefix, then the Map-Request is forwarded to one of the destination ETR RLOCs (or the Map-Server sends a Map-Reply, if it is providing a proxy Map-Reply service), and a Map-Referral with action code MS-ACK MUST be returned to the sender of the DDT Map-Request.
o 如果请求的XEID与注册的XEID前缀匹配，则Map请求将转发到目标ETR RLOC之一（或者Map服务器发送Map应答，如果它提供代理Map应答服务），并且必须将带有操作代码MS-ACK的Map引用返回给DDT Map请求的发送方。
o If the requested XEID matches a configured XEID-prefix for which no ETR registration has been received, then a Negative Map-Referral with action code MS-NOT-REGISTERED MUST be returned to the sender of the DDT Map-Request.
o 如果请求的XEID与未收到ETR注册的已配置XEID前缀匹配，则必须向DDT Map请求的发送方返回操作代码为MS-NOT-REGISTER的否定Map参考。
A DDT client queries one or more DDT nodes and uses an iterative process of following returned referrals until it receives one with action code MS-ACK (or an error indication). MS-ACK indicates that the Map-Request has been sent to a Map-Server that will forward it to an ETR that, in turn, will provide a Map-Reply to the locator address in the Map-Request.
DDT客户端查询一个或多个DDT节点，并使用一个迭代过程跟踪返回的引用，直到收到一个带有操作代码MS-ACK（或错误指示）的引用。MS-ACK表示Map请求已发送至Map服务器，该服务器将其转发至ETR，ETR将向Map请求中的定位器地址提供Map回复。
DDT client functionality will typically be implemented by DDT Map-Resolvers. Just as would any other Map-Resolver, a DDT Map-Resolver accepts Map-Requests from its clients (typically ITRs) and ensures that those Map-Requests are forwarded to the correct ETR, which generates Map-Replies. However, unlike a Map-Resolver that
DDT客户端功能通常由DDT映射解析器实现。与任何其他Map解析器一样，DDT Map解析器接受来自其客户端（通常是ITR）的Map请求，并确保将这些Map请求转发到正确的ETR，ETR生成Map回复。但是，与映射解析器不同
uses the LISP Alternative Logical Topology (LISP+ALT) mapping system [RFC6836], a DDT Map-Resolver implements DDT client functionality to find the correct ETR to answer a Map-Request; this requires a DDT Map-Resolver to maintain additional state: a Map-Referral cache and a pending request list of XEIDs that are going through the iterative referral process.
使用LISP替代逻辑拓扑（LISP+ALT）映射系统[RFC6836]，DDT映射解析器实现DDT客户端功能，以找到正确的ETR来响应映射请求；这需要DDT映射解析器来维护额外的状态：映射引用缓存和正在进行迭代引用过程的XEID的挂起请求列表。
DDT client functionality may be implemented on ITRs. In this case, the DDT client will not receive a Map-Request from another network element; instead, equivalent information will be provided to the DDT client via a programming interface.
DDT客户端功能可以在ITRs上实现。在这种情况下，DDT客户端将不会从另一个网元接收Map请求；相反，将通过编程接口向滴滴涕客户端提供同等信息。
When a DDT client receives a request to resolve an XEID (in the case of a DDT Map-Resolver, this will be in the form of a received Encapsulated Map-Request), it first performs a longest-match search for the XEID in its referral cache. If no match is found or if a negative cache entry is found, then the destination is not in the database; a Negative Map-Reply MUST be returned, and no further processing is performed by the DDT client.
当DDT客户端接收到解析XEID的请求时（对于DDT映射解析器，这将以接收到的封装映射请求的形式），它首先在其引用缓存中对XEID执行最长匹配搜索。如果未找到匹配项或找到负缓存项，则目标不在数据库中；必须返回否定的Map回复，DDT客户端不执行进一步的处理。
If a match is found, the DDT client creates a pending request list entry for the XEID and saves the original request (in the case of a DDT Map-Resolver, this will be the original Map-Request minus the encapsulation header) along with other information needed to track progress through the iterative referral process; the "referral XEID-prefix" is also initialized to indicate that no referral has yet been received. The DDT client then creates a DDT Map-Request (which is an Encapsulated Map-Request with the "DDT-originated" flag set in the message header) for the XEID but without any authentication data that may have been included in the original request. It sends the DDT Map-Request to one of the RLOCs in the chosen referral cache entry. The referral cache is initially populated with one or more statically configured entries; additional entries are added when referrals are followed, as described below. A DDT client is not absolutely required to cache referrals, but doing so will decrease latency and reduce lookup delays.
如果找到匹配项，DDT客户端将为XEID创建一个挂起的请求列表条目，并保存原始请求（对于DDT Map解析器，这将是原始Map请求减去封装头）以及跟踪迭代引用过程进度所需的其他信息；“参考XEID前缀”也被初始化，以指示尚未收到任何参考。然后，DDT客户端为XEID创建DDT映射请求（这是一个封装的映射请求，在消息头中设置了“DDT origined”标志），但没有原始请求中可能包含的任何身份验证数据。它将DDT Map请求发送到所选转诊缓存项中的一个RLOC。引用缓存最初由一个或多个静态配置的条目填充；如下文所述，在遵循转介时会添加其他条目。DDT客户端并非绝对需要缓存引用，但这样做将减少延迟并减少查找延迟。
Note that in normal use on the public Internet, the statically configured initial referral cache for a DDT client should include a "default" entry with RLOCs for either the root DDT node or one or more DDT nodes that contain hints for the root DDT node. If a DDT client does not have such a configuration, it will return a Negative Map-Reply if it receives a query for an EID outside the subset of the mapping database known to it. While this may be desirable on private network deployments or during early transition to LISP when few sites are using it, this behavior is not appropriate when LISP is in
请注意，在公共Internet上正常使用时，DDT客户端的静态配置初始引用缓存应包括根DDT节点或一个或多个包含根DDT节点提示的DDT节点的带有RLOCs的“默认”条目。如果DDT客户端没有这样的配置，那么如果它接收到对已知映射数据库子集之外的EID的查询，它将返回否定的映射应答。虽然这在专用网络部署上或在少数站点使用LISP的早期过渡期间可能是可取的，但在LISP处于运行状态时，这种行为并不合适
general use on the Internet. If DDT message exchanges are authenticated as described in Section 10, then the DDT client MUST also be configured with public keys of DDT nodes pointed to by the "default" cache entry. In this case, the "default" entry will typically be for the root DDT node.
互联网上的一般用途。如果DDT消息交换按照第10节所述进行身份验证，则DDT客户端还必须配置“默认”缓存项所指向的DDT节点的公钥。在这种情况下，“默认”条目通常用于根DDT节点。
After sending a DDT Map-Request, a DDT client expects to receive a Map-Referral response. If none occurs within the timeout period, the DDT client retransmits the request, sending it to the next RLOC in the referral cache entry if one is available. If all RLOCs have been tried and the maximum number of retransmissions has occurred for each, then the pending request list entry is dequeued and discarded. In this case, the DDT client returns no response to the sender of the original request.
在发送DDT Map请求后，DDT客户端希望收到Map参考响应。如果在超时时间内没有发生任何请求，DDT客户端将重新传输请求，并将其发送到引用缓存项中的下一个RLOC（如果有）。如果已尝试所有RLOC，并且每个RLOC的最大重传次数已达到，则挂起的请求列表条目将退出队列并丢弃。在这种情况下，DDT客户端不向原始请求的发送方返回响应。
A DDT client processes a received Map-Referral message according to each action code:
DDT客户端根据每个操作代码处理收到的Map参考消息：
NODE-REFERRAL: The DDT client checks for a possible referral loop as described in Section 7.3.4. If no loop is found, the DDT client saves the prefix returned in the Map-Referral message in the referral cache, updates the saved prefix and saved RLOCs in the pending request list entry, and follows the referral by sending a new DDT Map-Request to one of the DDT node RLOCs listed in the Referral Set; security information saved with the original Map-Request SHOULD NOT be included.
节点转诊：DDT客户端检查第7.3.4节中所述的可能转诊循环。如果未找到循环，DDT客户端将映射引用消息中返回的前缀保存在引用缓存中，更新未决请求列表条目中保存的前缀和保存的RLOC，并通过向引用集中列出的DDT节点RLOC之一发送新的DDT映射请求来跟踪引用；不应包括与原始地图请求一起保存的安全信息。
MS-REFERRAL: The DDT client processes an MS-REFERRAL in the same manner as a NODE-REFERRAL, except that security information saved with the original Map-Request MUST be included in the new Map-Request sent to a Map-Server (see Section 10 for details on security).
MS-REFERRAL：DDT客户端处理MS-REFERRAL的方式与处理NODE-REFERRAL的方式相同，只是原始Map请求中保存的安全信息必须包含在发送到Map服务器的新Map请求中（有关安全性的详细信息，请参阅第10节）。
MS-ACK: An MS-ACK is returned by a DDT Map-Server to indicate that it has one or more registered ETRs that can answer a Map-Request for the XEID and the request has been forwarded to one of them (or, if the Map-Server is providing a proxy service for the prefix, then a reply has been sent to the querying ITR). If the pending request did not include saved LISP-SEC information or if that information was already included in the previous DDT Map-Request (sent by the DDT client in response to either an MS-REFERRAL or a previous MS-ACK referral), then the pending request for the XEID is complete; processing of the request stops, and all request state can be discarded. Otherwise, LISP-SEC information is required and has not yet been sent to the authoritative DDT Map-Server; the DDT client MUST resend the DDT
MS-ACK：DDT映射服务器返回一个MS-ACK，以表明它有一个或多个已注册的ETR，这些ETR可以回答XEID的映射请求，并且请求已转发给其中一个ETR（或者，如果映射服务器为前缀提供代理服务，则回复已发送到查询ITR）。如果挂起的请求不包括保存的LISP-SEC信息，或者如果该信息已经包含在先前的DDT Map请求中（由DDT客户端响应MS-REFERRAL或先前的MS-ACK REFERRAL发送），则XEID的挂起请求完成；请求的处理停止，并且可以放弃所有请求状态。否则，LISP-SEC信息是必需的，尚未发送到权威DDT地图服务器；滴滴涕客户端必须重新发送滴滴涕
Map-Request with LISP-SEC information included, and the pending request queue entry remains until another Map-Referral with action code MS-ACK is received. If the "Incomplete" flag is not set, the prefix is saved in the referral cache.
包含LISP-SEC信息的Map请求，在收到另一个带有操作代码MS-ACK的Map引用之前，挂起的请求队列条目保持不变。如果未设置“未完成”标志，则前缀将保存在引用缓存中。
MS-NOT-REGISTERED: The DDT Map-Server queried could not process the request because it did not have any ETRs registered for a matching, authoritative XEID-prefix. If the DDT client has not yet tried all of the RLOCs saved with the pending request, then it sends a Map-Request to the next RLOC in that list. If all RLOCs have been tried, then the destination XEID is not registered and is unreachable. The DDT client MUST return a Negative Map-Reply to the requester (or, in the case of a DDT Map-Resolver, to the sender of the original Map-Request). This Map-Reply contains the least-specific XEID-prefix in the range for which this DDT Map-Server is authoritative and in which no registrations exist. The TTL value of the Negative Map-Reply SHOULD be set to 1 minute. A negative referral cache entry is created for the prefix (whose TTL also SHOULD be set to 1 minute), and processing of the request stops.
MS-NOT-REGISTERED:查询的DDT映射服务器无法处理该请求，因为它没有为匹配的权威XEID前缀注册任何ETR。如果DDT客户端尚未尝试与挂起的请求一起保存的所有RLOC，则它会向该列表中的下一个RLOC发送Map请求。如果已尝试所有RLOC，则目标XEID未注册且无法访问。DDT客户端必须向请求者返回否定的Map应答（或者，对于DDT Map解析器，向原始Map请求的发送者返回否定的Map应答）。此映射回复包含此DDT映射服务器授权范围内且不存在注册的最不特定的XEID前缀。负面地图回复的TTL值应设置为1分钟。为前缀（其TTL也应设置为1分钟）创建负引用缓存项，并停止处理请求。
DELEGATION-HOLE: The DDT Map-Server queried did not have an XEID-prefix defined that matched the requested XEID, so the XEID does not exist in the mapping database. The DDT client MUST return a Negative Map-Reply to the requester (or, in the case of a DDT Map-Resolver, to the sender of the original Map-Request); this Map-Reply SHOULD indicate the least-specific XEID-prefix matching the requested XEID for which no delegations exist and SHOULD have a TTL value of 15 minutes. A negative referral cache entry is created for the prefix (which also SHOULD have a TTL of 15 minutes), and processing of the pending request stops.
DELEGATION-HOLE：查询的DDT映射服务器没有定义与请求的XEID匹配的XEID前缀，因此映射数据库中不存在该XEID。DDT客户端必须向请求者（或者，如果是DDT Map解析器，则向原始Map请求的发送者）返回否定Map回复；此映射回复应指示与请求的XEID匹配的最不特定的XEID前缀，该前缀不存在任何委托，且TTL值应为15分钟。将为前缀创建一个负引用缓存项（其TTL也应为15分钟），并停止处理挂起的请求。
NOT-AUTHORITATIVE: The DDT Map-Server queried is not authoritative for the requested XEID. This can occur if a cached referral has become invalid due to a change in the database hierarchy. If the DDT client receiving this message can determine that it is using old cached information, it MAY choose to delete that cached information and retry the original Map-Request, starting from its "root" cache entry. If this action code is received in response to a query that did not use cached referral information, then it indicates a database synchronization problem or configuration error. The pending request is silently discarded; i.e., all state for the request that caused this answer is removed, and no answer is returned to the original requester.
非权威性：查询的DDT映射服务器对于请求的XEID不是权威性的。如果缓存的引用由于数据库层次结构中的更改而变得无效，则可能发生这种情况。如果接收此消息的DDT客户端可以确定它正在使用旧的缓存信息，则它可以选择删除该缓存信息，并从其“根”缓存条目开始重试原始映射请求。如果收到此操作代码是为了响应未使用缓存的引用信息的查询，则表示数据库同步问题或配置错误。挂起的请求被静默地丢弃；i、 例如，导致此应答的请求的所有状态都将被删除，并且不会将应答返回给原始请求者。
Other states are possible, such as a misconfigured DDT node (acting as a proxy Map-Server, for example) returning a Map-Reply to the DDT client; they should be considered errors and logged as such. It is not clear exactly what else the DDT client should do in such cases; one possibility is to remove the pending request list entry and send a Negative Map-Reply to the requester (or, in the case of a DDT Map-Resolver, to the sender of the original Map-Request). Alternatively, if a DDT client detects unexpected behavior by a DDT node, it could mark that node as unusable in its referral cache and update the pending request to try a different DDT node if more than one is listed in the referral cache. In any case, any prefix contained in a Map-Referral message that causes a referral error (including a referral loop) is not saved in the DDT client referral cache.
其他状态也是可能的，例如配置错误的DDT节点（例如充当代理映射服务器）将映射回复返回给DDT客户端；应将其视为错误并记录为错误。目前尚不清楚滴滴涕客户在这种情况下还应该做些什么；一种可能是删除挂起的请求列表条目，并向请求者（或者，在DDT Map解析器的情况下，向原始Map请求的发送者）发送否定Map回复。或者，如果DDT客户端检测到DDT节点的意外行为，它可以在其引用缓存中将该节点标记为不可用，并在引用缓存中列出多个DDT节点时更新挂起的请求以尝试其他DDT节点。在任何情况下，导致转诊错误（包括转诊循环）的Map转诊消息中包含的任何前缀都不会保存在DDT客户端转诊缓存中。
In response to a Map-Referral message with action code NODE-REFERRAL or MS-REFERRAL, a DDT client is directed to query a new set of DDT node RLOCs that are expected to have more-specific XEID-prefix information for the requested XEID. To prevent a possible "iteration loop" (following referrals back and forth among a set of DDT nodes without ever finding an answer), a DDT client saves the last received referral XEID-prefix for each pending request and checks to see if a newly received NODE-REFERRAL or MS-REFERRAL message contains a more-specific referral XEID-prefix; an exact or less-specific match of the saved XEID-prefix indicates a referral loop. If a loop is detected, the DDT Map-Resolver handles the request as described in Section 7.3.3. Otherwise, the DDT client saves the most recently received referral XEID-prefix with the pending request when it follows the referral.
为了响应带有操作代码NODE-Referral或MS-Referral的Map Referral消息，DDT客户端被指示查询一组新的DDT节点RLOC，这些DDT节点RLOC预期具有针对请求的XEID的更具体的XEID前缀信息。为了防止可能的“迭代循环”（在一组DDT节点之间来回跟踪转诊，但从未找到答案），DDT客户端为每个未决请求保存最后收到的转诊XEID前缀，并检查新收到的节点转诊或MS转诊消息是否包含更具体的转诊XEID前缀；保存的XEID前缀的精确匹配或不太具体的匹配表示引用循环。如果检测到循环，DDT Map解析器将按照第7.3.3节所述处理请求。否则，DDT客户端将在引用之后保存最近收到的引用XEID前缀和挂起的请求。
As an extra measure to prevent referral loops, it is probably also wise to limit the total number of referrals for any request to some reasonable number; the exact value of that number will be determined during experimental deployment of LISP-DDT but is bounded by the maximum length of the XEID.
作为防止转介循环的额外措施，将任何请求的转介总数限制在合理的范围内可能也是明智的；该数字的确切值将在LISP-DDT的实验部署期间确定，但受XEID的最大长度限制。
Note that when a DDT client adds an entry to its lookup queue and sends an initial Map-Request for an XEID, the queue entry has no previous referral XEID-prefix; this means that the first DDT node contacted by a DDT Map-Resolver may provide a referral to anywhere in the DDT hierarchy. This, in turn, allows a DDT client to use essentially any DDT node RLOCs for its initial cache entries and
请注意，当DDT客户端向其查找队列添加条目并发送XEID的初始映射请求时，队列条目没有以前的引用XEID前缀；这意味着DDT映射解析程序接触的第一个DDT节点可以提供对DDT层次结构中任何位置的引用。这反过来又允许DDT客户机基本上使用任何DDT节点RLOC作为其初始缓存项和
depend on the initial referral to provide a good starting point for Map-Requests; there is no need to configure the same set of root DDT nodes on all DDT clients.
依靠初始转介为Map请求提供良好的起点；不需要在所有DDT客户端上配置同一组根DDT节点。
To illustrate the DDT algorithms described above and to aid in implementation, each of the major DDT Map-Server and DDT Map-Resolver functions are described below, first using simple "pseudocode" and then in the form of a decision tree.
为了说明上面描述的DDT算法并帮助实现，下面将描述每个主要的DDT映射服务器和DDT映射解析器功能，首先使用简单的“伪代码”，然后以决策树的形式。
if ( request pending, i.e., (ITR,EID) of request same ) {
replace old request with new, & use new request nonce
for future requests
} else if ( no match in refcache ) {
return Negative Map-Reply to ITR
} else if ( match type DELEGATION-HOLE ) {
return Negative Map-Reply to ITR
} else if ( match type MS-ACK ) {
fwd DDT Map-Request to Map-Server
} else {
store & fwd DDT Map-Request w/o security material
to node delegation
}
if ( request pending, i.e., (ITR,EID) of request same ) {
replace old request with new, & use new request nonce
for future requests
} else if ( no match in refcache ) {
return Negative Map-Reply to ITR
} else if ( match type DELEGATION-HOLE ) {
return Negative Map-Reply to ITR
} else if ( match type MS-ACK ) {
fwd DDT Map-Request to Map-Server
} else {
store & fwd DDT Map-Request w/o security material
to node delegation
}
+------------+
| Is request | Yes
| pending? |----> Replace old request with
| | new nonce for future requests
+------------+
|
|No
|
V
+------------+
| Match in | No
| referral |----> Send Negative Map-Reply
| cache? | (not a likely event, as root or
+------------+ hint configured on every Map-Resolver)
|
|Yes
|
V
+-------------+
| Match type | Yes
| DELEGATION- |----> Send Negative Map-Reply
| HOLE? |
+-------------+
|
|No
|
V
+------------+
| Match type | Yes
| MS-ACK? |----> Forward DDT Map-Request to Map-Server
| |
+------------+
|
|No
|
V
Store original request & send DDT Map-Request w/o security material
to DDT node delegation
+------------+
| Is request | Yes
| pending? |----> Replace old request with
| | new nonce for future requests
+------------+
|
|No
|
V
+------------+
| Match in | No
| referral |----> Send Negative Map-Reply
| cache? | (not a likely event, as root or
+------------+ hint configured on every Map-Resolver)
|
|Yes
|
V
+-------------+
| Match type | Yes
| DELEGATION- |----> Send Negative Map-Reply
| HOLE? |
+-------------+
|
|No
|
V
+------------+
| Match type | Yes
| MS-ACK? |----> Forward DDT Map-Request to Map-Server
| |
+------------+
|
|No
|
V
Store original request & send DDT Map-Request w/o security material
to DDT node delegation
if ( authentication signature validation failed ) {
silently drop
}
if ( authentication signature validation failed ) {
silently drop
}
if ( no request pending matched by referral nonce ) {
silently drop
}
if ( no request pending matched by referral nonce ) {
silently drop
}
if ( pfx in referral less specific than last referral used ) {
if ( gone through root ) {
silently drop
} else {
send request to root
}
}
if ( pfx in referral less specific than last referral used ) {
if ( gone through root ) {
silently drop
} else {
send request to root
}
}
switch (map_referral_type) {
开关（地图类型）{
case NOT_AUTHORITATIVE:
if ( gone through root ) {
return Negative Map-Reply to ITR
} else {
send request to root
}
case NOT_AUTHORITATIVE:
if ( gone through root ) {
return Negative Map-Reply to ITR
} else {
send request to root
}
case DELEGATION_HOLE: cache & send Negative Map-Reply to ITR
案例委托：缓存并向ITR发送负面映射回复
case MS_REFERRAL:
if ( referral equal to last used ) {
if ( gone through root ) {
return Negative Map-Reply to ITR
} else {
send request to root
}
} else {
cache
follow the referral; include security material
}
case MS_REFERRAL:
if ( referral equal to last used ) {
if ( gone through root ) {
return Negative Map-Reply to ITR
} else {
send request to root
}
} else {
cache
follow the referral; include security material
}
case NODE_REFERRAL:
if ( referral equal to last used ) {
if ( gone through root ) {
return Negative Map-Reply to ITR
} else {
send request to root
}
} else {
cache
follow the referral; strip security material
}
case NODE_REFERRAL:
if ( referral equal to last used ) {
if ( gone through root ) {
return Negative Map-Reply to ITR
} else {
send request to root
}
} else {
cache
follow the referral; strip security material
}
case MS_ACK:
if ( security material stripped ) {
resend request with security material
if { !incomplete } {
cache
}
}
case MS_ACK:
if ( security material stripped ) {
resend request with security material
if { !incomplete } {
cache
}
}
case MS_NOT_REGISTERED:
if { all Map-Server delegations not tried } {
follow delegations not tried
if ( !incomplete ) {
cache
}
} else {
send Negative Map-Reply to ITR
if { !incomplete } {
cache
}
}
case MS_NOT_REGISTERED:
if { all Map-Server delegations not tried } {
follow delegations not tried
if ( !incomplete ) {
cache
}
} else {
send Negative Map-Reply to ITR
if { !incomplete } {
cache
}
}
case DEFAULT:
drop
}
}
case DEFAULT:
drop
}
}
+----------------+
| Auth signature | No
| valid? |----> Silently drop
+----------------+
| Yes
V
+------------+
| Is request | No
| pending? |----> Silently drop
+------------+
| Yes
V
+------------------------------+ Yes
| Pfx less specific than last? |----> Silently drop
+------------------------------+
|No
V
+---------------------------------------------------+
| What is Map-Referral type? |--Unknown-+
+---------------------------------------------------+ |
| | | | | | V
| | | | | DEL_HOLE Drop
| | | | MS_ACK |
| | | | | V
| | MS_REF NODE_REF | Cache & return
| | | | V Negative Map-Reply
| | | | +---------+
| NOT_AUTH | | | Was sec | Yes
| | | | | material|
| | | | |stripped?|----> Done
| | V V +---------+
| | +------------+ | No
| | Yes | Pfx equal | V
MS_NOT_REGISTERED | +---| to last | +------------+
| | | | used? | |"Incomplete"| Yes
| | | +------------+ | bit set? |---> Resend DDT
| V V |No +------------+ request w/
| +------------+ | |No security
| | Gone | V | material
| | through | Cache & follow V
| | root? | the referral Cache & resend DDT
| +------------+ request with
| |No |Yes security material
| | |
| V V
+----------------+
| Auth signature | No
| valid? |----> Silently drop
+----------------+
| Yes
V
+------------+
| Is request | No
| pending? |----> Silently drop
+------------+
| Yes
V
+------------------------------+ Yes
| Pfx less specific than last? |----> Silently drop
+------------------------------+
|No
V
+---------------------------------------------------+
| What is Map-Referral type? |--Unknown-+
+---------------------------------------------------+ |
| | | | | | V
| | | | | DEL_HOLE Drop
| | | | MS_ACK |
| | | | | V
| | MS_REF NODE_REF | Cache & return
| | | | V Negative Map-Reply
| | | | +---------+
| NOT_AUTH | | | Was sec | Yes
| | | | | material|
| | | | |stripped?|----> Done
| | V V +---------+
| | +------------+ | No
| | Yes | Pfx equal | V
MS_NOT_REGISTERED | +---| to last | +------------+
| | | | used? | |"Incomplete"| Yes
| | | +------------+ | bit set? |---> Resend DDT
| V V |No +------------+ request w/
| +------------+ | |No security
| | Gone | V | material
| | through | Cache & follow V
| | root? | the referral Cache & resend DDT
| +------------+ request with
| |No |Yes security material
| | |
| V V
| Send req Send Negative Map-Reply
| to root
V
+-----------+ Yes +------------+ Yes
| Other MS |---Follow other MS-------->|"Incomplete"|----> Don't cache
| not tried?| | bit set? |
| |--Send Negative Map-Reply->| |----> Cache
+-----------+ No +------------+ No
| Send req Send Negative Map-Reply
| to root
V
+-----------+ Yes +------------+ Yes
| Other MS |---Follow other MS-------->|"Incomplete"|----> Don't cache
| not tried?| | bit set? |
| |--Send Negative Map-Reply->| |----> Cache
+-----------+ No +------------+ No
if ( I am not authoritative ) {
send Map-Referral NOT_AUTHORITATIVE with
"Incomplete" bit set and TTL 0
} else if ( delegation exists ) {
if ( delegated Map-Servers ) {
send Map-Referral MS_REFERRAL with
TTL 'Default_DdtNode_Ttl'
} else {
send Map-Referral NODE_REFERRAL with
TTL 'Default_DdtNode_Ttl'
}
} else {
if ( EID in site) {
if ( site registered ) {
forward Map-Request to ETR
if ( Map-Server peers configured ) {
send Map-Referral MS_ACK with
TTL 'Default_Registered_Ttl'
} else {
send Map-Referral MS_ACK with
TTL 'Default_Registered_Ttl' and "Incomplete" bit set
}
} else {
if ( Map-Server peers configured ) {
send Map-Referral MS_NOT_REGISTERED with
TTL 'Default_Configured_Not_Registered_Ttl'
} else {
send Map-Referral MS_NOT_REGISTERED with
TTL 'Default_Configured_Not_Registered_Ttl'
and "Incomplete" bit set
}
}
if ( I am not authoritative ) {
send Map-Referral NOT_AUTHORITATIVE with
"Incomplete" bit set and TTL 0
} else if ( delegation exists ) {
if ( delegated Map-Servers ) {
send Map-Referral MS_REFERRAL with
TTL 'Default_DdtNode_Ttl'
} else {
send Map-Referral NODE_REFERRAL with
TTL 'Default_DdtNode_Ttl'
}
} else {
if ( EID in site) {
if ( site registered ) {
forward Map-Request to ETR
if ( Map-Server peers configured ) {
send Map-Referral MS_ACK with
TTL 'Default_Registered_Ttl'
} else {
send Map-Referral MS_ACK with
TTL 'Default_Registered_Ttl' and "Incomplete" bit set
}
} else {
if ( Map-Server peers configured ) {
send Map-Referral MS_NOT_REGISTERED with
TTL 'Default_Configured_Not_Registered_Ttl'
} else {
send Map-Referral MS_NOT_REGISTERED with
TTL 'Default_Configured_Not_Registered_Ttl'
and "Incomplete" bit set
}
}
} else {
send Map-Referral DELEGATION_HOLE with
TTL 'Default_Negative_Referral_Ttl'
}
}
} else {
send Map-Referral DELEGATION_HOLE with
TTL 'Default_Negative_Referral_Ttl'
}
}
where architectural constants for TTL are set as follows:
其中，TTL的架构常数设置如下：
Default_DdtNode_Ttl 1440 minutes Default_Registered_Ttl 1440 minutes Default_Negative_Referral_Ttl 15 minutes Default_Configured_Not_Registered_Ttl 1 minute
默认值\u DDT模式\u Ttl 1440分钟默认值\u Ttl 1440分钟默认值\u负面\u转诊\u Ttl 15分钟默认值\u已配置\u未注册\u Ttl 1分钟
+------------+
| Am I | No
| authori- |----> Return NOT_AUTHORITATIVE
| tative? | Incomplete = 1
+------------+ TTL = Default_DdtNode_Ttl
|
|Yes
|
V
+------------+ +-------------+
| Delegation | Yes | Delegations | Yes
| exists? |---->| are |----> Return MS_REFERRAL
| | | Map-Servers?| TTL = Default_DdtNode_Ttl
+------------+ +-------------+
| \ No
|No +--> Return NODE_REFERRAL
| TTL = Default_DdtNode_Ttl
V
+------------+ +------------+ +------------+
| EID in | Yes | Site | Yes | Map-Server |
| site |---->| registered?|----> Forward---->| peers |
| config? | | | Map-Request | configured?|
+------------+ +------------+ to ETR +------------+
| | | |
| |No No| |Yes
| | | |
| | V V
| | Return MS_ACK Return MS_ACK
| V with INC=1
| +------------+ TTL = Default_Registered_Ttl
| | Map-Server | Yes
| | peers |----> Return MS_NOT_REGISTERED
| | configured?| TTL = Default_Negative_Referral_Ttl
| +------------+
| \ No
|No +--> Return MS_NOT_REGISTERED
| Incomplete = 1
V TTL = Default_Negative_Referral_Ttl
Return DELEGATION_HOLE
TTL = Default_Negative_Referral_Ttl
+------------+
| Am I | No
| authori- |----> Return NOT_AUTHORITATIVE
| tative? | Incomplete = 1
+------------+ TTL = Default_DdtNode_Ttl
|
|Yes
|
V
+------------+ +-------------+
| Delegation | Yes | Delegations | Yes
| exists? |---->| are |----> Return MS_REFERRAL
| | | Map-Servers?| TTL = Default_DdtNode_Ttl
+------------+ +-------------+
| \ No
|No +--> Return NODE_REFERRAL
| TTL = Default_DdtNode_Ttl
V
+------------+ +------------+ +------------+
| EID in | Yes | Site | Yes | Map-Server |
| site |---->| registered?|----> Forward---->| peers |
| config? | | | Map-Request | configured?|
+------------+ +------------+ to ETR +------------+
| | | |
| |No No| |Yes
| | | |
| | V V
| | Return MS_ACK Return MS_ACK
| V with INC=1
| +------------+ TTL = Default_Registered_Ttl
| | Map-Server | Yes
| | peers |----> Return MS_NOT_REGISTERED
| | configured?| TTL = Default_Negative_Referral_Ttl
| +------------+
| \ No
|No +--> Return MS_NOT_REGISTERED
| Incomplete = 1
V TTL = Default_Negative_Referral_Ttl
Return DELEGATION_HOLE
TTL = Default_Negative_Referral_Ttl
This section shows an example DDT tree and several possible scenarios of Map-Requests coming to a Map-Resolver and subsequent iterative DDT referrals. In this example, RLOCs of DDT nodes are shown in the IPv4 address space while the EIDs are in the IPv6 AF. The same principle of hierarchical delegation and pinpointing referrals is equally applicable to any AF whose address hierarchy can be expressed as a bit string with associated length. The DDT "tree" of IPv4 prefixes is another AF with immediate practical value. This section could benefit from additional examples, perhaps including one using IPv4 EIDs and another using IPv6 RLOCs. If this document is moved to the Standards Track, consideration should be given to adding such examples.
本节展示了一个示例DDT树和几个可能的Map请求到达Map解析器和后续迭代DDT引用的场景。在此示例中，DDT节点的RLOC显示在IPv4地址空间中，而EID显示在IPv6 AF中。分层委派和精确定位引用的相同原则同样适用于地址层次可以表示为具有相关长度的位字符串的任何AF。IPv4前缀的DDT“树”是另一种具有即时实用价值的AF。本节可以从其他示例中获益，可能包括一个使用IPv4 EID的示例和另一个使用IPv6 RLOCs的示例。如果将本文件移至标准轨道，则应考虑添加此类示例。
To show how referrals are followed to find the RLOCs for a number of EIDs, consider the following example EID topology for DBID=0, IID=0, AFI=2, and EID=0/0:
为了显示如何引用，以找到多个EID的RoCs，考虑下面的示例EID拓扑，用于dBID＝0，IID＝0，AFI＝2，和EID＝0/0：
+---------------------+ +---------------------+
| root1: 192.0.2.1 | | root2: 192.0.2.2 |
| authoritative: ::/0 | | authoritative: ::/0 |
+---------------------+ +---------------------+
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| | | |
V V V V
+-------------------------+ +--------------------------+
| DDT node1: 192.0.2.11 | | DDT node2: 192.0.2.12 |
| authoritative: | | authoritative: |
| 2001:db8::/32 | | 2001:db8::/32 |
+-------------------------+ +--------------------------+
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| | | |
V V V V
+--------------------------+ +---------------------------+
| Map-Server1: 192.0.2.101 | | DDT node3: 192.0.2.201 |
| authoritative: | | authoritative: |
| 2001:db8:0100::/40 | | 2001:db8:0500::/40 |
| site1: 2001:db8:0103::/48| +---------------------------+
| site2: 2001:db8:0104::/48| | |
+--------------------------+ | |
| |
| |
V V
+---------------------------+ +---------------------------+
| Map-Server2: 192.0.2.211 | | Map-Server3: 192.0.2.221 |
| authoritative: | | authoritative: |
| 2001:db8:0500::/48 | | 2001:db8:0501::/48 |
|site3: 2001:db8:0500:1::/64| |site5: 2001:db8:0501:8::/64|
|site4: 2001:db8:0500:2::/64| |site6: 2001:db8:0501:9::/64|
+---------------------------+ +---------------------------+
+---------------------+ +---------------------+
| root1: 192.0.2.1 | | root2: 192.0.2.2 |
| authoritative: ::/0 | | authoritative: ::/0 |
+---------------------+ +---------------------+
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| | | |
V V V V
+-------------------------+ +--------------------------+
| DDT node1: 192.0.2.11 | | DDT node2: 192.0.2.12 |
| authoritative: | | authoritative: |
| 2001:db8::/32 | | 2001:db8::/32 |
+-------------------------+ +--------------------------+
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| | | |
V V V V
+--------------------------+ +---------------------------+
| Map-Server1: 192.0.2.101 | | DDT node3: 192.0.2.201 |
| authoritative: | | authoritative: |
| 2001:db8:0100::/40 | | 2001:db8:0500::/40 |
| site1: 2001:db8:0103::/48| +---------------------------+
| site2: 2001:db8:0104::/48| | |
+--------------------------+ | |
| |
| |
V V
+---------------------------+ +---------------------------+
| Map-Server2: 192.0.2.211 | | Map-Server3: 192.0.2.221 |
| authoritative: | | authoritative: |
| 2001:db8:0500::/48 | | 2001:db8:0501::/48 |
|site3: 2001:db8:0500:1::/64| |site5: 2001:db8:0501:8::/64|
|site4: 2001:db8:0500:2::/64| |site6: 2001:db8:0501:9::/64|
+---------------------------+ +---------------------------+
DDT nodes are configured for this "root" at IP addresses 192.0.2.1 and 192.0.2.2. DDT Map-Resolvers are configured with default referral cache entries for these addresses.
DDT节点在IP地址192.0.2.1和192.0.2.2处为此“根”配置。DDT映射解析器配置了这些地址的默认引用缓存项。
The root DDT nodes delegate 2001:db8::/32 to two DDT nodes with IP addresses 192.0.2.11 and 192.0.2.12.
根DDT节点将2001:db8:：/32委托给两个IP地址为192.0.2.11和192.0.2.12的DDT节点。
The DDT nodes for 2001:db8::/32 delegate 2001:db8:0100::/40 to a DDT Map-Server with RLOC 192.0.2.101.
2001:db8:：/32的DDT节点将2001:db8:0100:：/40委托给具有RLOC 192.0.2.101的DDT映射服务器。
The DDT Map-Server for 2001:db8:0100::/40 is configured to allow ETRs to register the sub-prefixes 2001:db8:0103::/48 and 2001:db8:0104::/48.
2001:db8:0100:：/40的DDT地图服务器配置为允许ETR注册子前缀2001:db8:0103:：/48和2001:db8:0104:：/48。
The DDT nodes for 2001:db8::/32 also delegate 2001:db8:0500::/40 to a DDT node with RLOC 192.0.2.201.
2001:db8:：/32的DDT节点还将2001:db8:0500:：/40委托给具有RLOC 192.0.2.201的DDT节点。
The DDT node for 2001:db8:0500::/40 is further configured to delegate 2001:db8:0500::/48 to a DDT Map-Server with RLOC 192.0.2.211 and 2001:db8:0501::/48 to a DDT Map-Server with RLOC 192.0.2.221.
2001:db8:0500:：/40的DDT节点进一步配置为将2001:db8:0500:：/48委托给具有RLOC 192.0.2.211的DDT映射服务器，并将2001:db8:0501:：/48委托给具有RLOC 192.0.2.221的DDT映射服务器。
The DDT Map-Server for 2001:db8:0500::/48 is configured to allow ETRs to register the sub-prefixes 2001:db8:0500:1::/64 and 2001:db8:0500:2::/64.
2001:db8:0500:：/48的DDT地图服务器配置为允许ETR注册子前缀2001:db8:0500:1:：/64和2001:db8:0500:2:：/64。
The DDT Map-Server for 2001:db8:0501::/48 is configured to allow ETRs to register the sub-prefixes 2001:db8:0501:8::/64 and 2001:db8:0501:9::/64.
2001:db8:0501:：/48的DDT地图服务器配置为允许ETR注册子前缀2001:db8:0501:8:：/64和2001:db8:0501:9:：/64。
The first example shows a DDT Map-Resolver following a delegation from the root to a DDT node followed by another delegation to a DDT Map-Server.
第一个示例显示了一个DDT映射解析器，该解析器在从根节点到DDT节点的委派之后，再经过另一个到DDT映射服务器的委派。
ITR1 sends an Encapsulated Map-Request for 2001:db8:0103:1::1 to one of its configured (DDT) Map-Resolvers. The DDT Map-Resolver proceeds as follows:
ITR1将2001:db8:0103:1:：1的封装映射请求发送到其配置的（DDT）映射解析器之一。DDT Map解析器的操作如下：
1. Send a DDT Map-Request (for 2001:db8:0103:1::1) to one of the root DDT nodes (192.0.2.1 or 192.0.2.2).
1. 向一个根DDT节点（192.0.2.1或192.0.2.2）发送DDT映射请求（对于2001:db8:0103:1:：1）。
2. Receive (and save in the referral cache) the Map-Referral for EID-prefix 2001:db8::/32, action code NODE-REFERRAL, RLOC set (192.0.2.11, 192.0.2.12).
2. 接收（并保存在引用缓存中）EID前缀2001:db8:：/32的映射引用，操作代码节点引用，RLOC集（192.0.2.11192.0.2.12）。
3. Send a DDT Map-Request to 192.0.2.11 or 192.0.2.12.
3. 向192.0.2.11或192.0.2.12发送DDT Map请求。
4. Receive (and save in the referral cache) the Map-Referral for EID-prefix 2001:db8:0100::/40, action code MS-REFERRAL, RLOC set (192.0.2.101).
4. 接收（并保存在引用缓存中）EID前缀2001:db8:0100:：/40的映射引用，操作代码MS-referral，RLOC集合（192.0.2.101）。
5. Send a DDT Map-Request to 192.0.2.101; if the ITR-originated Encapsulated Map-Request had a LISP-SEC signature, it is included.
5. 向192.0.2.101发送DDT Map请求；如果源自ITR的封装映射请求具有LISP-SEC签名，则会包含该签名。
6. The DDT Map-Server at 192.0.2.101 decapsulates the DDT Map-Request and forwards the Map-Request to a registered site1 ETR for 2001:db8:0103::/48.
6. 位于192.0.2.101的滴滴涕地图服务器解除对滴滴涕地图请求的封装，并将地图请求转发到注册的site1 ETR for 2001:db8:0103:：/48。
7. The DDT Map-Server at 192.0.2.101 sends a Map-Referral message for EID-prefix 2001:db8:0103::/48, action code MS-ACK, to the DDT Map-Resolver.
7. 位于192.0.2.101的DDT Map服务器向DDT Map解析器发送EID前缀2001:db8:0103:：/48（操作代码MS-ACK）的Map参考消息。
8. The DDT Map-Resolver receives the Map-Referral message and dequeues the pending request for 2001:db8:0103:1::1.
8. DDT Map解析器接收Map引用消息，并将挂起的2001:db8:0103:1：：1请求从队列中排出。
9. The site1 ETR for 2001:db8:0103::/48 receives the Map-Request forwarded by the DDT Map-Server and sends a Map-Reply to ITR1.
9. site1 ETR for 2001:db8:0103:：/48接收DDT Map服务器转发的Map请求，并向ITR1发送Map回复。
The next example shows a three-level delegation: root to first DDT node, first DDT node to second DDT node, and second DDT node to DDT Map-Server.
下一个示例显示了一个三级委托：root到第一个DDT节点，第一个DDT节点到第二个DDT节点，第二个DDT节点到DDT映射服务器。
ITR2 sends an Encapsulated Map-Request for 2001:db8:0501:8:4::1 to one of its configured (DDT) Map-Resolvers, which are different from those for ITR1. The DDT Map-Resolver proceeds as follows:
ITR2将2001:db8:0501:8:4:：1的封装映射请求发送到其配置的（DDT）映射解析器之一，这与ITR1的映射解析器不同。DDT Map解析器的操作如下：
1. Send a DDT Map-Request (for 2001:db8:0501:8:4::1) to one of the root DDT nodes (192.0.2.1 or 192.0.2.2).
1. 向一个根DDT节点（192.0.2.1或192.0.2.2）发送DDT映射请求（对于2001:db8:0501:8:4:：1）。
2. Receive (and save in the referral cache) the Map-Referral for EID-prefix 2001:db8::/32, action code NODE-REFERRAL, RLOC set (192.0.2.11, 192.0.2.12).
2. 接收（并保存在引用缓存中）EID前缀2001:db8:：/32的映射引用，操作代码节点引用，RLOC集（192.0.2.11192.0.2.12）。
3. Send a DDT Map-Request to 192.0.2.11 or 192.0.2.12.
3. 向192.0.2.11或192.0.2.12发送DDT Map请求。
4. Receive (and save in the referral cache) the Map-Referral for EID-prefix 2001:db8:0500::/40, action code NODE-REFERRAL, RLOC set (192.0.2.201).
4. 接收（并保存在引用缓存中）EID前缀2001:db8:0500:：/40的映射引用，操作代码节点引用，RLOC集（192.0.2.201）。
5. Send a DDT Map-Request to 192.0.2.201.
5. 向192.0.2.201发送DDT Map请求。
6. Receive (and save in the referral cache) the Map-Referral for EID-prefix 2001:db8:0501::/48, action code MS-REFERRAL, RLOC set (192.0.2.221).
6. 接收（并保存在引用缓存中）EID前缀2001:db8:0501:：/48的映射引用，操作代码MS-referral，RLOC集合（192.0.2.221）。
7. Send a DDT Map-Request to 192.0.2.221; if the ITR-originated Encapsulated Map-Request had a LISP-SEC signature, it is included.
7. 向192.0.2.221发送DDT Map请求；如果源自ITR的封装映射请求具有LISP-SEC签名，则会包含该签名。
8. The DDT Map-Server at 192.0.2.221 decapsulates the DDT Map-Request and forwards the Map-Request to a registered site5 ETR for 2001:db8:0501:8::/64.
8. 位于192.0.2.221的滴滴涕地图服务器解除对滴滴涕地图请求的封装，并将地图请求转发到注册站点5 ETR for 2001:db8:0501:8:：/64。
9. The DDT Map-Server at 192.0.2.221 sends a Map-Referral message for EID-prefix 2001:db8:0501:8::/64, action code MS-ACK, to the DDT Map-Resolver.
9. 位于192.0.2.221的DDT Map服务器向DDT Map解析器发送EID前缀2001:db8:0501:8:：/64（操作代码MS-ACK）的Map参考消息。
10. The DDT Map-Resolver receives a Map-Referral(MS-ACK) message and dequeues the pending request for 2001:db8:0501:8:4::1.
10. DDT Map解析器接收Map参考（MS-ACK）消息，并对挂起的2001:db8:0501:8:4:：1请求进行排队。
11. The site5 ETR for 2001:db8:0501:8::/64 receives a Map-Request forwarded by the DDT Map-Server and sends a Map-Reply to ITR2.
11. site5 ETR for 2001:db8:0501:8:：/64接收DDT Map服务器转发的Map请求，并向ITR2发送Map回复。
This example shows how a DDT Map-Resolver uses a saved referral cache entry to skip the referral process and go directly to a DDT Map-Server for a prefix that is similar to one previously requested.
此示例显示DDT映射解析程序如何使用保存的引用缓存项跳过引用过程，并直接转到DDT映射服务器以获取与先前请求的前缀类似的前缀。
In this case, ITR1 uses the same Map-Resolver used in the example in Section 9.1. It sends an Encapsulated Map-Request for 2001:db8:0104:2::2 to that (DDT) Map-Resolver. The DDT Map-Resolver finds an MS-REFERRAL cache entry for 2001:db8:0100::/40 with RLOC set (192.0.2.101) and proceeds as follows:
在这种情况下，ITR1使用第9.1节示例中使用的相同映射解析器。它将2001:db8:0104:2:：2的封装映射请求发送到该（DDT）映射解析器。DDT映射解析器查找设置了RLOC（192.0.2.101）的2001:db8:0100:：/40的MS-REFERRAL缓存项，并按如下步骤进行：
1. Send a DDT Map-Request (for 2001:db8:0104:2::2) to 192.0.2.101; if the ITR-originated Encapsulated Map-Request had a LISP-SEC signature, it is included.
1. 向192.0.2.101发送DDT Map请求（针对2001:db8:0104:2:：2）；如果源自ITR的封装映射请求具有LISP-SEC签名，则会包含该签名。
2. The DDT Map-Server at 192.0.2.101 decapsulates the DDT Map-Request and forwards the Map-Request to a registered site2 ETR for 2001:db8:0104::/48.
2. 位于192.0.2.101的滴滴涕地图服务器解除对滴滴涕地图请求的封装，并将地图请求转发到注册的site2 ETR for 2001:db8:0104:：/48。
3. The DDT Map-Server at 192.0.2.101 sends a Map-Referral message for EID-prefix 2001:db8:0104::/48, action code MS-ACK, to the DDT Map-Resolver.
3. 位于192.0.2.101的DDT Map服务器向DDT Map解析器发送EID前缀2001:db8:0104:：/48（操作代码MS-ACK）的Map参考消息。
4. The DDT Map-Resolver receives the Map-Referral (MS-ACK) and dequeues the pending request for 2001:db8:0104:2::2.
4. DDT Map解析器接收Map引用（MS-ACK）并将挂起的请求从2001:db8:0104:2:：2的队列中排出。
5. The site2 ETR for 2001:db8:0104::/48 receives a Map-Request and sends a Map-Reply to ITR1.
5. site2 ETR for 2001:db8:0104:：/48接收地图请求并向ITR1发送地图回复。
This example shows how a DDT Map-Resolver uses a saved referral cache entry to start the referral process at a non-root, intermediate DDT node for a prefix that is similar to one previously requested.
此示例显示DDT映射解析程序如何使用已保存的引用缓存项在非根中间DDT节点上启动与先前请求的前缀类似的引用过程。
In this case, ITR2 uses the same Map-Resolver used in the example in Section 9.2. It sends an Encapsulated Map-Request for 2001:db8:0500:2:4::1 to that (DDT) Map-Resolver, which finds a NODE-REFERRAL cache entry for 2001:db8:0500::/40 with RLOC set (192.0.2.201). It proceeds as follows:
在这种情况下，ITR2使用第9.2节示例中使用的相同映射解析器。它将2001:db8:0500:2:4：：1的封装映射请求发送到（DDT）映射解析器，该解析器将查找设置了RLOC（192.0.2.201）的2001:db8:0500:：/40的节点引用缓存项。其进展如下：
1. Send a DDT Map-Request (for 2001:db8:0500:2:4::1) to 192.0.2.201.
1. 向192.0.2.201发送DDT映射请求（针对2001:db8:0500:2:4:：1）。
2. Receive (and save in the referral cache) the Map-Referral for EID-prefix 2001:db8:0500::/48, action code MS-REFERRAL, RLOC set (192.0.2.211).
2. 接收（并保存在引用缓存中）EID前缀2001:db8:0500:：/48的映射引用，操作代码MS-referral，RLOC集合（192.0.2.211）。
3. Send a DDT Map-Request to 192.0.2.211; if the ITR-originated Encapsulated Map-Request had a LISP-SEC signature, it is included.
3. 向192.0.2.211发送DDT Map请求；如果源自ITR的封装映射请求具有LISP-SEC签名，则会包含该签名。
4. The DDT Map-Server at 192.0.2.211 decapsulates the DDT Map-Request and forwards the Map-Request to a registered site4 ETR for 2001:db8:0500:2::/64.
4. 位于192.0.2.211的滴滴涕地图服务器解除对滴滴涕地图请求的封装，并将地图请求转发到注册站点4 ETR for 2001:db8:0500:2:：/64。
5. The DDT Map-Server at 192.0.2.211 sends a Map-Referral message for EID-prefix 2001:db8:0500:2::/64, action code MS-ACK, to the DDT Map-Resolver.
5. 位于192.0.2.211的DDT地图服务器向DDT地图解析程序发送EID前缀2001:db8:0500:2:：/64（操作代码MS-ACK）的地图参考消息。
6. The DDT Map-Resolver receives the Map-Referral (MS-ACK) and dequeues the pending request for 2001:db8:0500:2:4::1.
6. DDT Map解析器接收Map引用（MS-ACK）并将挂起的请求从2001:db8:0500:2:4:：1的队列中排出。
7. The site4 ETR for 2001:db8:0500:2::/64 receives a Map-Request and sends a Map-Reply to ITR2.
7. site4 ETR for 2001:db8:0500:2:：/64接收映射请求并向ITR2发送映射回复。
This example uses the cached MS-REFERRAL for 2001:db8:0500::/48 learned above to start the lookup process at the DDT Map-Server at 192.0.2.211. The DDT Map-Resolver proceeds as follows:
此示例使用上面学习的缓存MS-REFERRAL for 2001:db8:0500:：/48在DDT地图服务器192.0.2.211处启动查找过程。DDT Map解析器的操作如下：
1. Send a DDT Map-Request (for 2001:db8:0500::1) to 192.0.2.211; if the ITR-originated Encapsulated Map-Request had a LISP-SEC signature, it is included.
1. 向192.0.2.211发送DDT Map请求（针对2001:db8:0500:：1）；如果源自ITR的封装映射请求具有LISP-SEC签名，则会包含该签名。
2. The DDT Map-Server at 192.0.2.211, which is authoritative for 2001:db8:0500::/48, does not have a matching delegation for 2001:db8:0500::1. It responds with a Map-Referral message for 2001:db8:0500::/64, action code DELEGATION-HOLE, to the DDT Map-Resolver. The prefix 2001:db8:0500::/64 is used because it is the least-specific prefix that does match the requested EID but does not match one of the configured delegations (2001:db8:0500:1::/64 and 2001:db8:0500:2::/64).
2. 位于192.0.2.211的DDT Map服务器（授权于2001:db8:0500:：/48）没有与2001:db8:0500:：1匹配的委派。它会向DDT Map解析器发送一条2001:db8:0500:：/64操作代码DELEGATION-HOLE的Map参考消息。使用前缀2001:db8:0500:：/64是因为它是与请求的EID匹配但与配置的委派之一（2001:db8:0500:1:：/64和2001:db8:0500:2:：/64）不匹配的最不特定的前缀。
3. The DDT Map-Resolver receives the delegation, adds a negative referral cache entry for 2001:db8:0500::/64, dequeues the pending request for 2001:db8:0500::1, and returns a Negative Map-Reply to ITR2.
3. DDT Map解析器接收委托，为2001:db8:0500:：/64添加否定引用缓存项，为2001:db8:0500：：1将挂起的请求排出队列，并将否定Map回复返回给ITR2。
This section specifies the DDT security architecture that provides data origin authentication, data integrity protection, and XEID-prefix delegation. Global XEID-prefix authorization is out of scope for this document.
本节指定提供数据源身份验证、数据完整性保护和XEID前缀委派的DDT安全体系结构。全局XEID前缀授权超出此文档的范围。
Each DDT node is configured with one or more public/private key pairs that are used to digitally sign Map-Referral Records for XEID-prefix(es) for which the DDT node is authoritative. In other words, each public/private key pair is associated with the combination of a DDT node and an XEID-prefix for which it is authoritative. Every DDT node is also configured with the public keys of its child DDT nodes. By including the public keys of target child DDT nodes in the Map-Referral Records and signing each Record with the DDT node's private key, a DDT node can securely delegate sub-prefixes of its authoritative XEID-prefixes to its child DDT nodes. A DDT node configured to provide hints must also have the public keys of the DDT nodes to which its hints point. DDT node keys can be encoded using LCAF Type 11 to associate the key to the RLOC of the referred DDT node. If a node has more than one public key, it should sign its Records with at least one of these keys. When a node has N keys, it can sustain up to N-1 key compromises. The revocation mechanism is described in Section 10.2.1.
每个DDT节点配置有一个或多个公钥/私钥对，用于对DDT节点具有权威性的XEID前缀的映射引用记录进行数字签名。换句话说，每个公钥/私钥对都与DDT节点和其权威的XEID前缀的组合相关联。每个DDT节点还配置了其子DDT节点的公钥。通过在映射引用记录中包含目标子DDT节点的公钥，并使用DDT节点的私钥对每个记录进行签名，DDT节点可以安全地将其权威XEID前缀的子前缀委托给其子DDT节点。配置为提供提示的DDT节点还必须具有其提示指向的DDT节点的公钥。DDT节点密钥可以使用LCAF类型11进行编码，以将密钥与所引用DDT节点的RLOC相关联。如果一个节点有多个公钥，那么它应该使用至少一个公钥对其记录进行签名。当一个节点有N个密钥时，它可以支持多达N-1个密钥折衷。撤销机制见第10.2.1节。
Map-Resolvers are configured with one or more trusted public keys, referred to as "trust anchors". Trust anchors are used to authenticate the DDT security infrastructure. Map-Resolvers can discover a DDT node's public key by either (1) having it configured as a trust anchor or (2) obtaining it from the node's parent as part of a signed Map-Referral. When a public key is obtained from a node's parent, it is considered trusted if it is signed by a trust anchor or if it is signed by a key that was previously trusted. Typically, in a Map-Resolver, the root DDT node's public keys should be configured as trust anchors. Once a Map-Resolver authenticates a public key, it locally caches the key along with the associated DDT node RLOC and XEID-prefix for future use.
映射解析器配置有一个或多个受信任的公钥，称为“信任锚”。信任锚用于验证DDT安全基础设施。映射解析程序可以通过（1）将DDT节点配置为信任锚点或（2）作为签名映射引用的一部分从节点的父节点获取它来发现DDT节点的公钥。当从节点的父节点获取公钥时，如果公钥由信任锚签名，或者如果公钥由以前受信任的密钥签名，则认为公钥是可信的。通常，在映射解析器中，根DDT节点的公钥应配置为信任锚。一旦映射解析器对公钥进行身份验证，它将本地缓存该密钥以及相关的DDT节点RLOC和XEID前缀，以备将来使用。
In order to delegate XEID sub-prefixes to its child DDT nodes, a parent DDT node signs its Map-Referrals. Every signed Map-Referral MUST also include the public keys associated with each child DDT node. Such a signature indicates that the parent DDT node is delegating the specified XEID-prefix to a given child DDT node. The signature is also authenticating the public keys associated with the child DDT nodes, and authorizing them to be used by the child DDT nodes, to provide origin authentication and integrity protection for further delegations and mapping information of the XEID-prefix allocated to the DDT node.
为了将XEID子前缀委托给其子DDT节点，父DDT节点对其映射引用进行签名。每个签名的Map引用还必须包括与每个子DDT节点关联的公钥。这样的签名表示父DDT节点正在将指定的XEID前缀委托给给定的子DDT节点。签名还验证与子DDT节点相关联的公钥，并授权子DDT节点使用这些公钥，以便为分配给DDT节点的XEID前缀的进一步委托和映射信息提供源身份验证和完整性保护。
As a result, for a given XEID-prefix, a Map-Resolver can form an authentication chain from a configured trust anchor (typically the root DDT node) to the leaf nodes (Map-Servers). Map-Resolvers leverage this authentication chain to verify the Map-Referral signatures while walking the DDT tree until they reach a Map-Server authoritative for the given XEID-prefix.
因此，对于给定的XEID前缀，Map解析器可以形成从配置的信任锚点（通常是根DDT节点）到叶节点（Map服务器）的身份验证链。映射解析程序利用此身份验证链在遍历DDT树时验证映射引用签名，直到它们到达给定XEID前缀的权威映射服务器。
Upon receiving a Map-Request, the DDT node responds with a Map-Referral as specified in Section 7. For every Record present in the Map-Referral, the DDT node also includes the public keys associated with the Record's XEID-prefix and the RLOCs of the child DDT nodes. Each Record contained in the Map-Referral is signed using the DDT node's private key.
在收到Map请求后，DDT节点按照第7节的规定响应Map参考。对于Map引用中存在的每个记录，DDT节点还包括与记录的XEID前缀和子DDT节点的RLOCs相关联的公钥。Map引用中包含的每个记录都使用DDT节点的私钥进行签名。
The node that owns a public key can also revoke that public key. For instance, if a parent DDT node advertises a public key for one of its child DDT nodes, the child DDT node can at a later time revoke that key. Since DDT nodes do not keep track of the Map-Resolvers that
拥有公钥的节点也可以撤销该公钥。例如，如果父DDT节点播发其子DDT节点之一的公钥，则子DDT节点可以在稍后撤销该密钥。由于DDT节点不跟踪
query them, revocation is done in a pull model, where the Map-Resolver is informed of the revocation of a key only when it queries the node that owns that key. If the parent DDT node is configured to advertise that key, the parent DDT node must also be signaled to remove the key from the Records it advertises for the child DDT node; this is necessary to avoid further distribution of the revoked key.
查询它们时，撤销是在拉模型中完成的，在拉模型中，只有当映射解析器查询拥有该密钥的节点时，才会通知该密钥的撤销。如果父DDT节点配置为播发该密钥，则还必须通知父DDT节点从其为子DDT节点播发的记录中删除该密钥；这是避免进一步分发已吊销密钥所必需的。
To securely revoke a key, the DDT node creates a new Record for the associated XEID-prefix and locator, including the revoked key with the R bit set. (See Section 4.7 of [RFC8060] for details regarding the R bit.) The DDT node must also include a signature in the Record that covers this Record; this is computed using the private key corresponding to the key being revoked. Such a Record is termed a "revocation record". By including this Record in its Map-Referrals, the DDT node informs querying Map-Resolvers about the revoked key. A digital signature computed with a revoked key can only be used to authenticate the revocation and SHOULD NOT be used to validate any data. To prevent a compromised key from revoking other valid keys, a given key can only be used to sign a revocation for that specific key; it cannot be used to revoke other keys. This prevents the use of a compromised key to revoke other valid keys as described in [RFC5011]. A revocation record MUST be advertised for a period of time equal to or greater than the TTL value of the Record that initially advertised the key, starting from the time that the advertisement of the key was stopped by removal from the parent DDT node.
为了安全地撤销密钥，DDT节点为相关的XEID前缀和定位器创建一个新记录，包括设置了R位的撤销密钥。（有关R位的详细信息，请参见[RFC8060]第4.7节。）DDT节点还必须在覆盖该记录的记录中包含签名；这是使用与被撤销的密钥对应的私钥计算的。这种记录称为“撤销记录”。通过将此记录包括在其映射引用中，DDT节点会通知查询映射解析程序已吊销的密钥。使用已撤销密钥计算的数字签名只能用于验证撤销，不应用于验证任何数据。为了防止受损密钥撤销其他有效密钥，给定密钥只能用于签署该特定密钥的撤销；它不能用于撤销其他密钥。这可防止使用受损密钥撤销[RFC5011]中所述的其他有效密钥。从通过从父DDT节点删除密钥停止密钥播发的时间开始，吊销记录的播发时间必须等于或大于最初播发密钥的记录的TTL值。
Similar to a DDT node, a Map-Server is configured with one or more public/private key pairs that it must use to sign Map-Referrals.
与DDT节点类似，映射服务器配置有一个或多个公钥/私钥对，它必须使用这些公钥/私钥对对对映射引用进行签名。
However, unlike DDT nodes, Map-Servers do not delegate prefixes and as a result do not need to include keys in the Map-Referrals they generate.
但是，与DDT节点不同，映射服务器不委托前缀，因此不需要在它们生成的映射引用中包含键。
Upon receiving a Map-Referral, the Map-Resolver MUST first verify the signature(s) by using either a trust anchor or a previously authenticated public key associated with the DDT node sending the Map-Referral. If multiple authenticated keys are associated with the DDT node sending this Map-Referral, the Key Tag field (Section 6.4.1) of the signature can be used to select the correct public key for verifying the signature. If the key tag matches more than one key associated with that DDT node, the Map-Resolver MUST try to verify the signature with all matching keys. For every matching key that is
收到Map引用后，Map解析器必须首先使用信任锚或与发送Map引用的DDT节点相关联的先前经过身份验证的公钥来验证签名。如果多个经过身份验证的密钥与发送此Map参考的DDT节点相关联，则可以使用签名的密钥标签字段（第6.4.1节）来选择用于验证签名的正确公钥。如果密钥标记匹配多个与该DDT节点关联的密钥，则映射解析器必须尝试使用所有匹配的密钥验证签名。对于每个匹配的
found, the Map-Resolver MUST also verify that the key is authoritative for the XEID-prefix in the Map-Referral Record. If such a key is found, the Map-Resolver MUST use it to verify the associated signature in the Record. If (1) no matching key is found, (2) none of the matching keys is authoritative for the XEID-prefix in the Map-Referral Record, or (3) such a key is found but the signature is not valid, the Map-Referral Record is considered corrupted and MUST be discarded. This may be due to expired keys. The Map-Resolver MAY try other siblings of this node if there is an alternate node that is authoritative for the same prefix. If not, the Map-Resolver CAN query the DDT node's parent to retrieve a valid key. It is good practice to use a counter or timer to avoid repeating this process if the Map-Resolver cannot verify the signature after several attempts.
找到时，映射解析器还必须验证该密钥对于映射引用记录中的XEID前缀是否具有权威性。如果找到这样的密钥，映射解析器必须使用它来验证记录中的关联签名。如果（1）未找到匹配密钥，（2）匹配密钥中没有一个对映射引用记录中的XEID前缀具有权威性，或者（3）找到此类密钥但签名无效，则映射引用记录被视为已损坏，必须丢弃。这可能是由于密钥过期造成的。如果存在对同一前缀具有权威性的备用节点，则映射解析器可以尝试此节点的其他同级。如果没有，映射解析器可以查询DDT节点的父节点以检索有效密钥。如果映射解析程序在多次尝试后无法验证签名，则最好使用计数器或计时器来避免重复此过程。
Once the signature is verified, the Map-Resolver has verified the XEID-prefix delegation in the Map-Referral. This also means that public keys of the child DDT nodes were authenticated; the Map-Resolver must add these keys to the authenticated keys associated with each child DDT node and XEID-prefix. These keys are considered valid for the duration specified in the Record's TTL field.
验证签名后，映射解析器将验证映射引用中的XEID前缀委托。这也意味着子DDT节点的公钥已通过身份验证；映射解析器必须将这些密钥添加到与每个子DDT节点和XEID前缀关联的经过身份验证的密钥中。这些键在记录的TTL字段中指定的持续时间内被视为有效。
There are a number of issues with the organization of the mapping database that need further investigation. Among these are:
映射数据库的组织存在许多问题，需要进一步调查。其中包括：
o Defining an interface to implement interconnection and/or interoperability with other mapping databases, such as LISP+ALT.
o 定义接口以实现与其他映射数据库（如LISP+ALT）的互连和/或互操作性。
o Additional key structures for use with LISP-DDT, such as key structures to support additional EID formats as defined in [RFC8060].
o 用于LISP-DDT的其他键结构，例如支持[RFC8060]中定义的其他EID格式的键结构。
o Management of the DDT Map-Resolver referral cache -- in particular, detecting and removing outdated entries.
o 管理DDT Map解析器引用缓存——特别是检测和删除过时的条目。
o Best practices for either configuring hint referrals or avoiding their use.
o 配置提示引用或避免使用提示引用的最佳实践。
Operational experience will help answer open questions surrounding these and other issues.
运营经验将有助于回答围绕这些和其他问题的开放性问题。
IANA has made the following early assignment per this document:
IANA已根据本文件提前完成以下任务：
o Message type 6, "LISP DDT Map-Referral", was added to the "LISP Packet Types" registry. See Section 6.4 ("Map-Referral Message Format").
o 消息类型6“LISP DDT Map参考”已添加到“LISP数据包类型”注册表中。参见第6.4节（“地图参考信息格式”）。
As this document is an Experimental RFC, this is an early allocation as per [RFC7120].
由于本文件是一份实验性RFC，因此根据[RFC7120]的规定，这是一份早期分配。
Section 10 describes a DDT security architecture that provides data origin authentication, data integrity protection, and XEID-prefix delegation within the DDT infrastructure.
第10节描述了DDT安全体系结构，该体系结构在DDT基础设施内提供数据源身份验证、数据完整性保护和XEID前缀委派。
Global XEID-prefix authorization is beyond the scope of this document, but the Secure Inter-Domain Routing (SIDR) working group [RFC6480] is developing an infrastructure to support improved security of Internet routing. Further work is required to determine if SIDR's Public Key Infrastructure (PKI) and the distributed repository system it uses for storing and disseminating PKI data objects may also be used by DDT devices to verifiably assert that they are the legitimate holders of a set of XEID-prefixes.
全局XEID前缀授权超出了本文档的范围，但安全域间路由（SIDR）工作组[RFC6480]正在开发一种基础设施，以支持改进的Internet路由安全性。还需要进一步工作，以确定DDT设备是否也可以使用SIDR的公钥基础设施（PKI）及其用于存储和传播PKI数据对象的分布式存储库系统，以可验证的方式断言它们是一组XEID前缀的合法持有者。
This document specifies how DDT security and LISP-SEC [LISP-SEC] complement one another to secure the DDT infrastructure, Map-Referral messages, and the Map-Request/Map-Reply protocols. In the future, other LISP security mechanisms may be developed to replace LISP-SEC. Such future security mechanisms should describe how they can be used together with LISP-DDT to provide similar levels of protection.
本文件规定了DDT安全性和LISP-SEC[LISP-SEC]如何相互补充，以确保DDT基础设施、Map参考消息和Map请求/Map回复协议的安全。将来，可能会开发其他LISP安全机制来取代LISP-SEC。此类未来安全机制应说明如何与LISP-DDT一起使用，以提供类似级别的保护。
LISP-SEC can use the DDT public-key infrastructure to secure the transport of LISP-SEC key material (the One-Time Key) from a Map-Resolver to the corresponding Map-Server. For this reason, when LISP-SEC is deployed in conjunction with a LISP-DDT mapping database and the path between the Map-Resolver and Map-Server needs to be protected, DDT security as described in Section 10 should be enabled as well.
LISP-SEC可以使用DDT公钥基础设施来保护LISP-SEC密钥材料（一次性密钥）从映射解析程序到相应映射服务器的传输。因此，当LISP-SEC与LISP-DDT映射数据库一起部署时，需要保护映射解析程序和映射服务器之间的路径，还应启用第10节中所述的DDT安全。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, <http://www.rfc-editor.org/info/rfc6830>.
[RFC6830]Farinaci，D.，Fuller，V.，Meyer，D.，和D.Lewis，“定位器/身份分离协议（LISP）”，RFC 6830，DOI 10.17487/RFC6830，2013年1月<http://www.rfc-editor.org/info/rfc6830>.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, DOI 10.17487/RFC6833, January 2013, <http://www.rfc-editor.org/info/rfc6833>.
[RFC6833]Fuller，V.和D.Farinaci，“定位器/ID分离协议（LISP）地图服务器接口”，RFC 6833，DOI 10.17487/RFC6833，2013年1月<http://www.rfc-editor.org/info/rfc6833>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <http://www.rfc-editor.org/info/rfc7120>.
[RFC7120]Cotton，M.，“标准轨道代码点的早期IANA分配”，BCP 100，RFC 7120，DOI 10.17487/RFC7120，2014年1月<http://www.rfc-editor.org/info/rfc7120>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <http://www.rfc-editor.org/info/rfc8017>.
[RFC8017]Moriarty，K.，Ed.，Kaliski，B.，Jonsson，J.，和A.Rusch，“PKCS#1:RSA加密规范版本2.2”，RFC 8017，DOI 10.17487/RFC8017，2016年11月<http://www.rfc-editor.org/info/rfc8017>.
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, February 2017, <http://www.rfc-editor.org/info/rfc8060>.
[RFC8060]Farinaci，D.，Meyer，D.，和J.Snijders，“LISP规范地址格式（LCAF）”，RFC 8060，DOI 10.17487/RFC8060，2017年2月<http://www.rfc-editor.org/info/rfc8060>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<http://www.rfc-editor.org/info/rfc8174>.
[AFI] IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers/>.
[AFI]IANA，“地址家庭编号”<http://www.iana.org/assignments/address-family-numbers/>.
[LISP-SEC] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, "LISP-Security (LISP-SEC)", Work in Progress, draft-ietf-lisp-sec-12, November 2016.
[LISP-SEC]Maino，F.，Ermagan，V.，Cabellos，A.，和D.Saucez，“LISP安全（LISP-SEC）”，正在进行的工作，草案-ietf-LISP-SEC-12，2016年11月。
[LISP-TREE] Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D., and O. Bonaventure, "LISP-TREE: a DNS Hierarchy to Support the LISP Mapping System", IEEE Journal on Selected Areas in Communications, Volume 28, Issue 8, DOI 10.1109/JSAC.2010.101011, September 2010, <http://ieeexplore.ieee.org/xpls/ abs_all.jsp?arnumber=5586446>.
[LISP-TREE]Jakab，L.，Cabellos Aparicio，A.，Coras，F.，Saucez，D.，和O.Bonaventure，“LISP-TREE：支持LISP映射系统的DNS层次结构”，IEEE通信选定领域杂志，第28卷，第8期，DOI 10.1109/JSAC.2010.101011，2010年9月<http://ieeexplore.ieee.org/xpls/ abs_all.jsp？arnumber=5586446>。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，DOI 10.17487/RFC1918，1996年2月<http://www.rfc-editor.org/info/rfc1918>.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, September 2007, <http://www.rfc-editor.org/info/rfc5011>.
[RFC5011]StJohns，M.“DNS安全（DNSSEC）信任锚的自动更新”，STD 74，RFC 5011，DOI 10.17487/RFC5011，2007年9月<http://www.rfc-editor.org/info/rfc5011>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <http://www.rfc-editor.org/info/rfc6480>.
[RFC6480]Lepinski，M.和S.Kent，“支持安全互联网路由的基础设施”，RFC 6480，DOI 10.17487/RFC6480，2012年2月<http://www.rfc-editor.org/info/rfc6480>.
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, January 2013, <http://www.rfc-editor.org/info/rfc6836>.
[RFC6836]Fuller，V.，Farinaci，D.，Meyer，D.，和D.Lewis，“定位器/ID分离协议替代逻辑拓扑（LISP+ALT）”，RFC 6836，DOI 10.17487/RFC6836，2013年1月<http://www.rfc-editor.org/info/rfc6836>.
[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database", RFC 6837, DOI 10.17487/RFC6837, January 2013, <http://www.rfc-editor.org/info/rfc6837>.
[RFC6837]李尔，E.“NERD：路由定位器（RLOC）数据库的一个不太新颖的端点ID（EID）”，RFC 6837，DOI 10.17487/RFC6837，2013年1月<http://www.rfc-editor.org/info/rfc6837>.
Acknowledgments
致谢
The authors would like to express their thanks to Lorand Jakab, Albert Cabellos, Florin Coras, Damien Saucez, and Olivier Bonaventure for their work on LISP-TREE [LISP-TREE] and LISP iterable mappings that inspired the hierarchical database structure and lookup iteration approach described in this document. Thanks also go to Dino Farinacci and Isidor Kouvelas for their implementation work; to Selina Heimlich and Srin Subramanian for testing; to Fabio Maino for work on security processing; and to Job Snijders, Glen Wiley, Neel Goyal, and Mike Gibbs for work on operational considerations and initial deployment of a prototype database infrastructure. Special thanks go to Jesper Skriver, Andrew Partan, and Noel Chiappa, all of whom have participated in (and put up with) seemingly endless hours of discussion of mapping database ideas, concepts, and issues.
作者要感谢Lorand Jakab、Albert Cabellos、Florin Coras、Damien Saucez和Olivier Bonaventure在LISP-TREE[LISP-TREE]和LISP iterable映射方面的工作，他们的工作启发了本文档中描述的分层数据库结构和查找迭代方法。还要感谢Dino Farinaci和Isidor Kouvelas的实施工作；给Selina Heimlich和Srin Subramanian进行测试；向Fabio Maino提供安全处理工作；以及Job Snijders、Glen Wiley、Neel Goyal和Mike Gibbs关于操作注意事项和原型数据库基础设施初始部署的工作。特别感谢Jesper Skriver、Andrew Partan和Noel Chiappa，他们都参与（并忍受）了看似没完没了的关于映射数据库想法、概念和问题的讨论。
Authors' Addresses
作者地址
Vince Fuller VAF.NET Internet Consulting
Vince Fuller VAF.NET互联网咨询
Email: vince.fuller@gmail.com
Email: vince.fuller@gmail.com
Darrel Lewis Cisco Systems
达雷尔·刘易斯思科系统公司
Email: darlewis@cisco.com
Email: darlewis@cisco.com
Vina Ermagan Cisco Systems
维娜·埃尔马根思科系统公司
Email: vermagan@cisco.com
Email: vermagan@cisco.com
Amit Jain Juniper Networks
Amit Jain Juniper网络
Email: atjain@juniper.net
Email: atjain@juniper.net
Anton Smirnov Cisco Systems
安东·斯米尔诺夫思科系统公司
Email: as@cisco.com
Email: as@cisco.com