Independent Submission D. Farinacci
Request for Comments: 8112 lispers.net
Category: Informational A. Jain
ISSN: 2070-1721 Juniper Networks
I. Kouvelas
Arista
D. Lewis
Cisco Systems
May 2017
Independent Submission D. Farinacci
Request for Comments: 8112 lispers.net
Category: Informational A. Jain
ISSN: 2070-1721 Juniper Networks
I. Kouvelas
Arista
D. Lewis
Cisco Systems
May 2017
Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) Referral Internet Groper (RIG)
定位器/ID分离协议委托数据库树（LISP-DDT）参考互联网搜索器（RIG）
Abstract
摘要
A simple tool called the Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) Referral Internet Groper (RIG), also referred to in this document as "rig", can be used to query the LISP-DDT hierarchy. This document describes how the "rig" tool works.
一个称为定位器/ID分离协议委托数据库树（LISP-DDT）的简单工具可用于查询LISP-DDT层次结构，该工具在本文档中也称为“RIG”。本文档描述了“装备”工具的工作原理。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc8112.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8112.
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................2
2. Requirements Language ...........................................3
3. Definitions of Terms ............................................3
4. Basic Overview ..................................................5
5. Implementation Details ..........................................7
6. Security Considerations .........................................9
7. IANA Considerations .............................................9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References ....................................10
Acknowledgments ...................................................11
Authors' Addresses ................................................11
1. Introduction ....................................................2
2. Requirements Language ...........................................3
3. Definitions of Terms ............................................3
4. Basic Overview ..................................................5
5. Implementation Details ..........................................7
6. Security Considerations .........................................9
7. IANA Considerations .............................................9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References ....................................10
Acknowledgments ...................................................11
Authors' Addresses ................................................11
"The Locator/ID Separation Protocol (LISP)" [RFC6830] specifies an architecture and mechanism for replacing the semantics of an address currently used by IP with two separate namespaces: Endpoint Identifiers (EIDs), used within sites; and Routing Locators (RLOCs), used on the transit networks that make up the Internet infrastructure. To achieve this separation, LISP defines protocol mechanisms for mapping from EIDs to RLOCs. In addition, LISP assumes the existence of a database to store and propagate those mappings globally. This document focuses on the LISP Delegated Database Tree (LISP-DDT) [RFC8111] mapping database system.
“定位器/ID分离协议（LISP）”[RFC6830]指定了一种体系结构和机制，用于将IP当前使用的地址的语义替换为两个单独的名称空间：在站点内使用的端点标识符（EID）；和路由定位器（RLOC），用于构成互联网基础设施的交通网络。为了实现这种分离，LISP定义了从EID映射到RLOCs的协议机制。此外，LISP假设存在一个数据库来全局存储和传播这些映射。本文档重点介绍LISP委托数据库树（LISP-DDT）[RFC8111]映射数据库系统。
The "rig" tool is a manual management tool to query the LISP-DDT mapping database hierarchy. It can be run by all devices that implement LISP, including Ingress Tunnel Routers (ITRs), Egress Tunnel Routers (ETRs), Proxy ITRs (PITRs), Proxy ETRs (PETRs), Map-Resolvers, Map-Servers, and LISP-DDT nodes, as well as by a host system at either a LISP-capable or non-LISP-capable site.
“rig”工具是一种手动管理工具，用于查询LISP-DDT映射数据库层次结构。它可以由实现LISP的所有设备运行，包括入口隧道路由器（ITR）、出口隧道路由器（ETR）、代理ITR（PITR）、代理ETR（PETR）、地图解析程序、地图服务器和LISP-DDT节点，也可以由支持LISP或不支持LISP的站点上的主机系统运行。
The LISP-DDT "rig" tool is similar to the "LISP Internet Groper" ("lig") tool [RFC6835] in that they are both diagnostic tools to query a database. However, the "rig" tool is used to find Map-Servers serving an EID-prefix, specifically within a LISP-DDT mapping database framework. And "lig" can be used on top of any mapping database system to retrieve locators used for packet encapsulation.
LISP-DDT“rig”工具类似于“LISP Internet Groper”（“lig”）工具[RFC6835]，因为它们都是查询数据库的诊断工具。但是，“rig”工具用于查找提供EID前缀的地图服务器，特别是在LISP-DDT地图数据库框架内。“lig”可以用于任何映射数据库系统之上，以检索用于数据包封装的定位器。
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]所述进行解释。
Endpoint Identifier (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value (or an address encoded per [RFC8060]) used in the source and destination address fields of the first (innermost) LISP header of a packet. The host obtains a destination EID the same way it obtains a destination address today -- for example, through a Domain Name System (DNS) [RFC1034] lookup or a Session Initiation Protocol (SIP) [RFC3261] exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID used on the public Internet must have the same properties as any other IP address used in that manner; this means, among other things, that it must be globally unique. An EID is allocated to a host from an EID-prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks MAY be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site may have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system. In theory, the bit string that represents an EID for one device can represent an RLOC for a different device. As the architecture is realized, if a given bit string is both an RLOC and an EID, it must refer to the same entity in both cases. When used in "discussions" with other Locator/ID separation proposals, a LISP EID will be called an "LEID". Throughout this document, any references to "EID" refer to an LEID.
端点标识符（EID）：数据包第一个（最内层）LISP头的源地址和目标地址字段中使用的32位（IPv4）或128位（IPv6）值（或按照[RFC8060]编码的地址）。主机获取目标EID的方式与当前获取目标地址的方式相同——例如，通过域名系统（DNS）[RFC1034]查找或会话启动协议（SIP）[RFC3261]交换。源EID通过用于设置主机“本地”IP地址的现有机制获得。在公共互联网上使用的EID必须与以这种方式使用的任何其他IP地址具有相同的属性；这意味着，除其他外，它必须是全球唯一的。EID从与主机所在站点关联的EID前缀块分配给主机。主机可以使用EID引用其他主机。EID不得用作LISP RLOC。注意，EID块可以独立于网络拓扑以分层方式分配，以便于映射数据库的缩放。此外，分配给站点的EID块可以具有用于在站点内路由的站点本地结构（子网）；此结构对全局路由系统不可见。理论上，表示一个设备的EID的位字符串可以表示另一个设备的RLOC。随着体系结构的实现，如果给定的位字符串既是RLOC又是EID，那么在这两种情况下它必须引用同一个实体。当在与其他定位器/ID分离方案的“讨论”中使用时，LISP EID将被称为“LEID”。在本文件中，对“EID”的任何引用均指LEID。
Extended EID (XEID): a LISP EID, optionally extended with a non-zero Instance ID (IID) if the EID is intended for use in a context where it may not be a unique value, such as in a Virtual Private Network where private address space [RFC1918] is used. See Section 5.5 of [RFC6830] for more discussion of IIDs.
扩展EID（XEID）：一种LISP EID，如果EID用于可能不是唯一值的上下文中，例如在使用专用地址空间[RFC1918]的虚拟专用网络中，则可以选择使用非零实例ID（IID）进行扩展。有关IID的更多讨论，请参见[RFC6830]第5.5节。
Routing Locator (RLOC): an IPv4 [RFC791] or IPv6 [RFC2460] address of an Egress Tunnel Router (ETR). An RLOC is the output of an EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically aggregatable blocks that are assigned to a site at each point to which it
路由定位器（RLOC）：出口隧道路由器（ETR）的IPv4[RFC791]或IPv6[RFC2460]地址。RLOC是EID到RLOC映射查找的输出。EID映射到一个或多个RLOC。通常，RLOC是从拓扑上可聚合的块中编号的，这些块分配给它所在的每个点上的站点
attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as Provider-Assigned (PA) addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site.
连接到全球互联网；如果拓扑由提供商网络的连接性定义，则可以将RLOC视为提供商分配（PA）地址。可以将多个RLOC分配给同一ETR设备或一个站点的多个ETR设备。
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 ITR to implement DDT client functionality. A DDT client can be a device that is originating "rig" requests.
DDT客户端：一个网络基础设施组件，用于发送DDT映射请求消息并实现映射引用结果的迭代跟踪。通常，DDT客户端将是映射解析器（如[RFC6833]所定义），但ITR也可以实现DDT客户端功能。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-Resolver: a network infrastructure element that accepts a Map-Request, adds the XEID to its lookup queue, then queries one or more DDT nodes for the requested EID, following returned referrals until it receives one with the MS-ACK action code [RFC8111]. This 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 original sender. A DDT Map-Resolver maintains both (1) a cache of Map-Referral message results (termed the "referral cache") containing RLOCs for DDT nodes responsible for XEID-prefixes of interest and (2) a lookup queue of XEIDs that are being resolved through iterative querying of DDT nodes.
DDT映射解析器：一种网络基础设施元素，它接受映射请求，将XEID添加到其查找队列中，然后根据返回的引用查询一个或多个DDT节点以获取请求的EID，直到收到一个带有MS-ACK操作代码的引用[RFC8111]。这表示Map请求已发送到Map服务器，该服务器将其转发给ETR，ETR将向原始发件人提供Map回复。DDT映射解析器维护（1）映射引用消息结果缓存（称为“引用缓存”），其中包含负责感兴趣的XEID前缀的DDT节点的RLOC；（2）通过DDT节点的迭代查询解析的XEID查找队列。
Encapsulated Map-Request: a LISP Map-Request that is carried within an Encapsulated Control Message (ECM) and that has an additional LISP header prepended. Sent to UDP destination port 4342. The "outer" addresses are globally routable IP addresses, also known as RLOCs. Used by an ITR when sending a Map-Request to a Map-Resolver and by a Map-Server when forwarding a Map-Request to an ETR as documented in [RFC6833].
封装映射请求：封装控制消息（ECM）中携带的一种LISP映射请求，该请求带有一个附加的LISP头。发送到UDP目标端口4342。“外部”地址是全局可路由的IP地址，也称为RLOC。ITR在向Map解析器发送Map请求时使用，Map服务器在向ETR转发Map请求时使用，如[RFC6833]中所述。
Map-Referral: a LISP message sent by a DDT node when it receives a DDT Map-Request for an XEID that matches a configured XEID-prefix delegation. A non-Negative Map-Referral message includes a "referral" -- a set of RLOCs for DDT nodes that have more information about the sub-prefix; a DDT client "follows the
映射引用：DDT节点在接收到与配置的XEID前缀委托匹配的XEID的DDT映射请求时发送的LISP消息。非负Map参考消息包括“参考”——DDT节点的一组RLOC，其具有关于子前缀的更多信息；“滴滴涕客户机”遵循以下原则：
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 a more-specific XEID-prefix.
通过向其中一个RLOC发送另一个DDT映射请求，以获得应答或向负责更具体XEID前缀的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节点可为其提供更具体子前缀的进一步委托。
LISP-DDT [RFC8111] is a hierarchical distributed database that embodies the delegation of authority to provide mappings from LISP EIDs to 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.
LISP-DDT[RFC8111]是一个分层分布式数据库，它体现了提供从LISP EID到RLOCs映射的授权。它是EID名称空间在一组称为“DDT节点”的LISP语言服务器之间的静态定义分布。每个DDT节点被配置为一个或多个EID前缀的“权威”，以及一组用于映射服务器的RLOC或将更多特定EID前缀委托给的“子”DDT节点。
Map-Resolvers send Map-Requests to the DDT hierarchy and maintain referral caches by receiving Map-Referral messages from DDT nodes. Map-Resolvers follow the DDT hierarchy for a given EID lookup based on the EID-prefix and delegation referrals contained in the Map-Referral messages. The "rig" tool is intended to perform the same operation as that of a Map-Resolver but to also be used as a management tool for the network administrator.
Map解析器向DDT层次结构发送Map请求，并通过从DDT节点接收Map引用消息来维护引用缓存。映射解析程序根据映射引用消息中包含的EID前缀和委派引用，遵循给定EID查找的DDT层次结构。“rig”工具旨在执行与地图解析器相同的操作，但也可用作网络管理员的管理工具。
When the "rig" command is run, an Encapsulated Control Message Map-Request is sent for a destination EID. When a LISP-DDT Map-Referral is returned, the contents are displayed to the user. The information displayed includes:
当运行“rig”命令时，将为目标EID发送一个封装的控制消息映射请求。返回LISP-DDT映射引用时，内容将显示给用户。显示的信息包括：
o A delegated EID-prefix configured in a DDT node or a configured site EID-prefix in a DDT Map-Server that matches the requested EID.
o 在DDT节点中配置的委派EID前缀或在DDT映射服务器中配置的与请求的EID匹配的站点EID前缀。
o The type of DDT node that sent the Map-Referral.
o 发送地图引用的DDT节点的类型。
o The action code and TTL set by the sender of the Map-Referral.
o 映射引用的发件人设置的操作代码和TTL。
o The referral RLOC addresses from the Map-Referral message.
o 来自映射引用消息的引用RLOC地址。
o A round-trip-time estimate for the ECM-Map-Request / Map-Referral message exchange.
o ECM Map请求/Map参考消息交换的往返时间估计。
A possible syntax for a "rig" command MAY be:
“rig”命令的可能语法为：
rig [instance-id <iid>] <eid> to <ddt-node> [follow-all-referrals]
rig [instance-id <iid>] <eid> to <ddt-node> [follow-all-referrals]
Parameter descriptions:
参数说明：
[instance-id <iid>]: <iid> is the IID portion of the XEID used as a VPN identifier or for other future purposes. When the DDT hierarchy is not configured with IIDs, this argument is omitted from the command line.
[实例id<iid>]：<iid>是XEID的iid部分，用作VPN标识符或用于其他未来用途。当DDT层次结构未配置IID时，此参数将从命令行中忽略。
<eid>: <eid> is either a Fully Qualified Domain Name or a destination EID that is being queried in the LISP-DDT mapping database.
<eid>：<eid>是在LISP-DDT映射数据库中查询的完全限定域名或目标eid。
<ddt-node>: <ddt-node> is the RLOC address of any DDT node in the DDT hierarchy. This can be the DDT root node, a DDT transit node, or a DDT Map-Server.
<ddt node>：<ddt node>是ddt层次结构中任何ddt节点的RLOC地址。这可以是DDT根节点、DDT传输节点或DDT地图服务器。
[follow-all-referrals]: When this keyword is used, each referral RLOC is queried so "rig" can descend the entire DDT hierarchy starting from the node <ddt-node>. When this keyword is not used, one of the referral RLOCs will be selected to descend a branch of the DDT hierarchy.
[遵循所有引用]：使用此关键字时，将查询每个引用RLOC，以便“rig”可以从节点<DDT node>开始降低整个DDT层次结构。如果不使用此关键字，将选择其中一个转诊RLOC来降低DDT层次结构的分支。
The "rig" utility not only shows branches of the delegation hierarchy but can also report:
“rig”实用程序不仅显示委派层次结构的分支，还可以报告：
o When a DDT Map-Server would forward a Map-Request to the ETRs at a registered LISP site. This is known as an "MS-ACK" action.
o DDT映射服务器将映射请求转发到注册LISP站点的ETRs时。这称为“MS-ACK”动作。
o When a DDT Map-Server sends a Negative Map-Referral indicating that a requested EID is configured but not registered to the mapping database system. This is known as an "MS-NOT-REGISTERED" action.
o DDT地图服务器发送否定地图参考时，表示已配置请求的EID，但未注册到地图数据库系统。这被称为“MS未注册”操作。
o When a DDT node is sending referrals for a transit or leaf node in the hierarchy. These are known as "NODE-REFERRAL" and "MS-REFERRAL" actions, respectively.
o 当DDT节点为层次结构中的transit或leaf节点发送转介时。这些分别称为“节点转诊”和“MS转诊”操作。
o When a DDT node finds a hole in the address space that has not been allocated or configured in the delegation hierarchy. This is typically associated with a hole in a DDT node's configured authoritative prefix. This is known as a "DELEGATION-HOLE" action.
o DDT节点在地址空间中发现未在委派层次结构中分配或配置的漏洞时。这通常与DDT节点配置的权威前缀中的孔相关联。这被称为“授权洞”行动。
o When a DDT node finds a hole in the address space that has not been allocated or configured in the delegation hierarchy at all. This is typically associated with a hole that is outside of a DDT node's authoritative prefix. This is known as a "NOT-AUTHORITATIVE" action.
o 当DDT节点在地址空间中发现一个根本没有在委派层次结构中分配或配置的漏洞时。这通常与DDT节点权威前缀之外的孔相关联。这被称为“非权威”行为。
Refer to [RFC8111] for more details about Map-Referral actions.
有关地图参考操作的更多详细信息，请参阅[RFC8111]。
The Cisco LISP prototype implementations on IOS and NX-OS have "rig" support for IPv4 and IPv6 EIDs in either the default instance or a non-zero IID.
IOS和NX-OS上的Cisco LISP原型实现在默认实例或非零IID中对IPv4和IPv6 EID具有“装备”支持。
The IOS syntax is:
IOS语法为：
rig [instance-id <iid>] <eid> to <ddt-node> [follow-all-referrals]
rig [instance-id <iid>] <eid> to <ddt-node> [follow-all-referrals]
The NX-OS syntax is:
NX-OS语法为：
rig [instance-id <iid>] { <hostname> | {<eid> | <eid6>} }
to { <ddt-hostname> | {<ddt> | <ddt6>} }
rig [instance-id <iid>] { <hostname> | {<eid> | <eid6>} }
to { <ddt-hostname> | {<ddt> | <ddt6>} }
Here is some sample IOS output:
以下是一些IOS输出示例：
Router# rig 12.0.1.1 to 1.1.1.1
路由器#钻机12.0.1.1至1.1.1.1
Send Map-Request to DDT-node 1.1.1.1 ... node referral, rtt: 0 ms
EID-prefix: [0] 12.0.0.0/16, ttl: 1440
referrals: 2.2.2.2
Send Map-Request to DDT-node 1.1.1.1 ... node referral, rtt: 0 ms
EID-prefix: [0] 12.0.0.0/16, ttl: 1440
referrals: 2.2.2.2
Send Map-Request to DDT-node 2.2.2.2 ... node referral, rtt: 0 ms
EID-prefix: [0] 12.0.1.0/24, ttl: 1440
referrals: 4.4.4.4, 5.5.5.5
Send Map-Request to DDT-node 2.2.2.2 ... node referral, rtt: 0 ms
EID-prefix: [0] 12.0.1.0/24, ttl: 1440
referrals: 4.4.4.4, 5.5.5.5
Send Map-Request to DDT-node 4.4.4.4 ... map-server acknowledgement, rtt: 0 ms EID-prefix: [0] 12.0.1.0/28, ttl: 1440 referrals: 4.4.4.4, 5.5.5.5
向DDT节点4.4.4.4发送Map请求。。。映射服务器确认，rtt:0毫秒EID前缀：[0]12.0.1.0/28，ttl:1440引用：4.4.4.4，5.5.5.5
Router# rig 12.0.1.1 to 1.1.1.1 follow-all-referrals
路由器#装备12.0.1.1至1.1.1.1遵循所有推荐
Send Map-Request to DDT-node 1.1.1.1 ... node referral, rtt: 4 ms
EID-prefix: [0] 12.0.0.0/16, ttl: 1440
referrals: 2.2.2.2
Send Map-Request to DDT-node 1.1.1.1 ... node referral, rtt: 4 ms
EID-prefix: [0] 12.0.0.0/16, ttl: 1440
referrals: 2.2.2.2
Send Map-Request to DDT-node 2.2.2.2 ... node referral, rtt: 0 ms
EID-prefix: [0] 12.0.1.0/24, ttl: 1440
referrals: 4.4.4.4, 5.5.5.5
Send Map-Request to DDT-node 2.2.2.2 ... node referral, rtt: 0 ms
EID-prefix: [0] 12.0.1.0/24, ttl: 1440
referrals: 4.4.4.4, 5.5.5.5
Send Map-Request to DDT-node 4.4.4.4 ... map-server acknowledgement, rtt: 0 ms EID-prefix: [0] 12.0.1.0/28, ttl: 1440 referrals: 4.4.4.4, 5.5.5.5
向DDT节点4.4.4.4发送Map请求。。。映射服务器确认，rtt:0毫秒EID前缀：[0]12.0.1.0/28，ttl:1440引用：4.4.4.4，5.5.5.5
Send Map-Request to DDT-node 5.5.5.5 ... map-server acknowledgement, rtt: 0 ms EID-prefix: [0] 12.0.1.0/28, ttl: 1440 referrals: 4.4.4.4, 5.5.5.5
向DDT节点5.5.5.5发送Map请求。。。映射服务器确认，rtt:0毫秒EID前缀：[0]12.0.1.0/28，ttl:1440引用：4.4.4.4，5.5.5.5
No more referrals to pursue.
没有更多的转介。
Here is some sample NX-OS output:
以下是一些NX-OS输出示例：
Router# rig 12.0.1.1 to 1.1.1.1
路由器#钻机12.0.1.1至1.1.1.1
rig LISP-DDT hierarchy for EID [0] 12.0.1.1
Send Map-Request to DDT-node 1.1.1.1 ... replied, rtt: 0.003509 secs
EID-prefix [0] *, ttl: 1440, action: node-referral, referrals:
2.2.2.2, priority/weight: 0/0
rig LISP-DDT hierarchy for EID [0] 12.0.1.1
Send Map-Request to DDT-node 1.1.1.1 ... replied, rtt: 0.003509 secs
EID-prefix [0] *, ttl: 1440, action: node-referral, referrals:
2.2.2.2, priority/weight: 0/0
Send Map-Request to DDT-node 2.2.2.2 ... replied, rtt: 0.003173 secs
EID-prefix [0] 12.0.0.0/20, ttl: 1440, action: node-referral,
referrals:
3.3.3.3, priority/weight: 0/0
Send Map-Request to DDT-node 2.2.2.2 ... replied, rtt: 0.003173 secs
EID-prefix [0] 12.0.0.0/20, ttl: 1440, action: node-referral,
referrals:
3.3.3.3, priority/weight: 0/0
Send Map-Request to DDT-node 3.3.3.3 ... replied, rtt: 0.004145 secs
EID-prefix [0] 12.0.1.0/24, ttl: 1440, action: node-referral,
referrals:
5.5.5.5, priority/weight: 0/0
6.6.6.6, priority/weight: 0/0
Send Map-Request to DDT-node 3.3.3.3 ... replied, rtt: 0.004145 secs
EID-prefix [0] 12.0.1.0/24, ttl: 1440, action: node-referral,
referrals:
5.5.5.5, priority/weight: 0/0
6.6.6.6, priority/weight: 0/0
Send Map-Request to DDT-node 6.6.6.6 ... replied, rtt: 0.005800 secs
EID-prefix [0] 12.0.1.0/28, ttl: 1440, action: ms-ack, referrals:
5.5.5.5, priority/weight: 0/0
6.6.6.6, priority/weight: 0/0
Send Map-Request to DDT-node 6.6.6.6 ... replied, rtt: 0.005800 secs
EID-prefix [0] 12.0.1.0/28, ttl: 1440, action: ms-ack, referrals:
5.5.5.5, priority/weight: 0/0
6.6.6.6, priority/weight: 0/0
The use of "rig" does not affect the security of the LISP infrastructure, as it is simply a tool that facilitates diagnostic querying. See [RFC6830], [RFC6833], [RFC7835], and [RFC8111] for descriptions of the security properties of the LISP infrastructure.
“rig”的使用不会影响LISP基础设施的安全性，因为它只是一个方便诊断查询的工具。请参阅[RFC6830]、[RFC6833]、[RFC7835]和[RFC8111]以了解LISP基础结构的安全属性的描述。
LISP "rig" provides easy access to the information in the public mapping database. Therefore, it is important to protect the mapping information for private use. This can be provided by disallowing access to specific mapping entries or placing such entries in a private mapping database system.
LISP“rig”提供了对公共映射数据库中信息的轻松访问。因此，保护地图信息以供私人使用非常重要。这可以通过禁止访问特定映射条目或将此类条目放置在专用映射数据库系统中来实现。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.
[RFC791]Postel，J.，“互联网协议”，STD 5，RFC 791，DOI 10.17487/RFC07911981年9月<http://www.rfc-editor.org/info/rfc791>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，DOI 10.17487/RFC1034，1987年11月<http://www.rfc-editor.org/info/rfc1034>.
[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>.
[RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation Protocol Internet Groper (LIG)", RFC 6835, DOI 10.17487/RFC6835, January 2013, <http://www.rfc-editor.org/info/rfc6835>.
[RFC6835]Farinaci，D.和D.Meyer，“定位器/身份分离协议互联网格罗珀（LIG）”，RFC 6835，DOI 10.17487/RFC6835，2013年1月<http://www.rfc-editor.org/info/rfc6835>.
[RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, "Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, May 2017, <http://www.rfc-editor.org/info/rfc8111>.
[RFC8111]Fuller，V.，Lewis，D.，Ermagan，V.，Jain，A.，和A.Smirnov，“定位器/身份分离协议委托数据库树（LISP-DDT）”，RFC 8111，DOI 10.17487/RFC8111，2017年5月<http://www.rfc-editor.org/info/rfc8111>.
[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>.
[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>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，DOI 10.17487/RFC2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Threat Analysis", RFC 7835, DOI 10.17487/RFC7835, April 2016, <http://www.rfc-editor.org/info/rfc7835>.
[RFC7835]Saucez，D.，Iannone，L.，和O.Bonaventure，“定位器/身份分离协议（LISP）威胁分析”，RFC 7835，DOI 10.17487/RFC7835，2016年4月<http://www.rfc-editor.org/info/rfc7835>.
[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>.
Acknowledgments
致谢
The authors would like to thank Damien Saucez and Fabio Maino for their ideas and comments. Appreciation also goes to Joel Halpern, Luigi Iannone, and Nevil Brownlee for their help with this document.
作者要感谢Damien Saucez和Fabio Maino的想法和评论。感谢Joel Halpern、Luigi Iannone和Nevil Brownlee在本文档中提供的帮助。
Authors' Addresses
作者地址
Dino Farinacci lispers.net San Jose, California United States of America
美国加利福尼亚州圣何塞Dino Farinaci lispers.net
Phone: 408-718-2001 Email: farinacci@gmail.com
电话：408-718-2001电子邮件：farinacci@gmail.com
Amit Jain Juniper Networks San Jose, California United States of America
Amit Jain Juniper Networks美国加利福尼亚州圣何塞
Email: atjain@juniper.net
Email: atjain@juniper.net
Isidor Kouvelas Arista Santa Clara, California United States of America
Isidor Kouvelas Arista Santa Clara，美国加利福尼亚州
Email: kouvelas@arista.com
Email: kouvelas@arista.com
Darrel Lewis Cisco Systems Tasman Ave. San Jose, California United States of America
美国加利福尼亚州圣何塞市塔斯曼大道Darrel Lewis Cisco Systems
Email: darlewis@cisco.com
Email: darlewis@cisco.com