[要約] RFC 8111は、LISP-DDT（Locator/ID Separation Protocol Delegated Database Tree）の仕様を定義しています。LISP-DDTは、LISPプロトコルのための分散データベースツリーを提供し、エンドポイントの位置情報と識別子を分離することを目的としています。
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.
このドキュメントでは、Locator / ID分離プロトコル委任データベースツリー（LISP-DDT）について説明します。これは、「DDTノード」と呼ばれる一連のLISP対応サーバー間のEID名前空間の静的に定義された分散です。各DDTノードは、1つ以上のEIDプレフィックスに対して「権限のある」ものとして構成され、さらにMap-Serverの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.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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:
Locator / ID Separation Protocol（LISP）[RFC6830]は、IPで現在使用されているアドレスを2つの別個の名前空間に置き換えるためのアーキテクチャとメカニズムを指定しています。
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）。トポロジロケーションにバインドされ、インターネットインフラストラクチャを介したルーティングと転送に使用されます。
[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へのマッピングを見つけるためにその情報を使用するMap-Resolversに委任情報を提供します。特定のマッピングを見つける必要のあるMap-Resolverは、ツリー構造のデータベースを通るパスをたどり、そのパスに沿った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は、1つ以上のXEIDプレフィックスに対して権限のあるものとして構成される、新しいデバイスタイプであるDDTノードを定義します。また、他のDDTノードにさらに委任される、より具体的なサブプレフィックスのセットで構成されます。サブプレフィックスを委任するために、「親」DDTノードは、サブプレフィックスに対して権限を持つ各子DDTノードのRLOCで構成されます。各RLOCは、出力トンネルルーター（ETR）がそのサブプレフィックスを登録したDDT Map-Server（MS）を指すか、またはサブプレフィックスをさらに委任するデータベースツリー内の別のDDTノードを指します。 Map-ServerおよびMap-Resolverの機能の説明については、[RFC6833]を参照してください。循環依存を回避するために、委任のターゲットは常に（EIDではなく）RLOCでなければならないことに注意してください。
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メッセージタイプであるMap-Referralを定義します。これは、受信DDTノードが別のDDTノードに送信者を参照できるときにMap-Requestの送信者に返されます。より詳細な情報があります。 Map-Referralメッセージの定義については、セクション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 Map-Resolver）が、事前に構成されたDDTノードのRLOCにカプセル化されたMap-Requestを送信することから始めます。 DDTノードはMap-Referralメッセージで応答し、（1）要求のマッピングを見つけて要求の処理を完了するか、（2）DDTクライアントがより具体的な情報を持つ別のDDTノードに接続する必要があることを示します。後者の場合、DDTノードは新しいEncapsulated Map-Requestを次のDDTノードに送信し、プロセスは反復的に繰り返されます。
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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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 Map-Requestメッセージを送信し、Map-Referralの結果に続く反復を実装するネットワークインフラストラクチャコンポーネント。通常、DDTクライアントはMap-Resolver（[RFC6833]で定義）ですが、Ingress Tunnel Router（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 Map-Server：委任されたプレフィックスのサブセットに対してMap-Server機能（Map-Requestの転送、および/またはプロキシMap-Replyサービスを提供している場合はMap-Repliesを返す）も実装するDDTノード。 Map-Repliesのプロキシを含むMap-Server関数は、[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 Map-Serverピア：同じプレフィックスに対してMap-Server機能を実行するすべてのDDT Map-Serverのリスト。ピアがDDT Map-Serverで構成されている場合、後者はそのMap-Repliesのプレフィックスに関する完全な情報を提供します。それ以外の場合、Map-Serverは返された応答を潜在的に不完全としてマークします。
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 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.
DDT Map-Resolver：[RFC6833]で定義されているDDTクライアント機能とMap-Resolver機能の両方を実装するネットワークインフラストラクチャ要素。 DDT Map-Resolverは、ITRからのMap-Requestsを受け入れ、DDTノードにDDT Map-Requestsを送信し、Map-Referralsに続く反復を実装します。 Map-ResolverはMap-Requestを送信したクライアントに応答しないことに注意してください。それらは、Map-Requestが、元のリクエスタに信頼できる応答を提供するLISPデバイス（ETRまたはプロキシMap-Server）に転送されたことを確認するだけです。 DDT Map-Resolverは、通常、関心のあるXEIDプレフィックスを担当するDDTノードのRLOCを含む、以前に受信したMap-Referralメッセージ結果のキャッシュ（「参照キャッシュ」と呼ばれます）を維持します。
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とも呼ばれます。 [RFC6833]に記載されているように、Map-RequestをMap-Resolverに送信するときにITRによって使用され、Map-RequestをETRに転送するときにMap-Serverによって使用されます。
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 Map-Request：DDTクライアントからDDTノードに送信されるカプセル化されたMap-Request。 「DDT-originated」フラグはカプセル化ヘッダーで設定され、Map-Request EIDがDDTノードに既知の委任されたXEIDプレフィックスと一致する場合、DDTノードがMap-Referralメッセージを返す必要があることを示します。セクション7.3.1では、DDT Map-Requestsの送信方法について説明します。セクション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ノードに委任され、DDTノードがより具体的なサブプレフィックスの委任を提供できるXEIDプレフィックス。
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.
Map-Referral：構成されたXEIDプレフィックス委任と一致するXEIDのDDT Map-Requestに応答してDDTノードによって送信されるLISPメッセージ。非負のMap-Referralには「紹介」が含まれています。これは、要求されたXEIDをカバーする、より具体的なXEIDプレフィックスに関する情報を持つDDTノードの一連のRLOCです。 DDTクライアントは、これらのRLOCの1つに別のDDT Map-Requestを送信して回答を取得するか、より具体的なXEIDプレフィックスを担当するDDTノードへの別の紹介を取得することにより、「紹介をフォロー」します。 Map-Referralメッセージの送信と処理の詳細については、セクション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).
Negative Map-Referral：要求されたXEIDのマッピングがないという信頼できるDDTノードからの回答。ネガティブMap-Referralは、信頼できるXEIDプレフィックスと一致するDDT Map-Requestに応答して送信されるが、委任が構成されていない（またはDDT Map-Serverから送信された場合はETR登録がない）Map-Referralです。
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 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".
保留中の要求リスト：DDT Map-ResolverがXEIDのEID-to-RLOCマッピングを求めるクライアントからカプセル化されたMap-Requestsを受け取った未解決の要求のセット。リストの各エントリには、XEID、XEIDのリクエスター（通常は1つ以上のITR）、最後に受信および追跡された保存済みの情報（XEIDプレフィックスと一致）を含む、参照フォロープロセスに必要な追加の状態が含まれます。アクションコード、RLOCセット、RLOCセットで照会された最後のRLOCのインデックス）、およびDDTクライアントMap-Requestに含まれていたすべてのLISP-Security（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].
その他の用語、特にMap-Request、Map-Reply、ITR、ETR、Map-Server、Map-Resolverの定義については、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値に応じて変数）の重要度順に並べられた4つのバイナリエンコードフィールドで構成されます。フィールドは連結されており、最も重要なフィールドは上記のとおりです。
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 Map-Requestには、常に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ビット以下、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へのマッピングを保存しないことに注意することが重要です。むしろ、これらのマッピングを取得するためにLISPでクエリできるデバイス（DDT Map-ServerにEIDを登録したETR）を見つけるために使用できる分散インデックスです。 EIDからRLOCへのマッピングの変更は、DDTノード構成ではなく、それらを定義するETRに対して行われます。 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ノードは、他のDDTノードへのXEIDプレフィックスの委任のリストと共に、権限のある1つ以上のXEIDプレフィックスで構成されます。信頼できるXEIDプレフィックスのすべてのサブプレフィックスの委任のリストを維持するには、DDTノードが必要です。また、その親、ルート、またはXEIDプレフィックス階層内の他のポイントに属していることがわかっているプレフィックスである「ヒント」をリストすることもあります。委任（またはヒント）は、XEIDプレフィックス、XEIDプレフィックスのより詳細な知識を持つDDTノードの一連のRLOC、および付随するセキュリティ情報（セキュリティ情報交換とその使用の詳細については、セクション10を参照）で構成されます。 。これらのRLOCは、DDTノードが委任に一致するXEIDを持つDDT Map-Requestを受信すると、Map-Referralメッセージで返されます。 DDT Map-Serverには、ETRマッピング登録を受け入れ、Map-Requestを転送（またはプロキシMap-Replyサービスを提供する場合は応答）する一連のサブプレフィックスもあります。
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ノードが信頼できる1つ以上のXEIDプレフィックス、およびサブプレフィックスの権限の委任は、DDTノードの構成の一部として提供されます。実装では、この接頭辞の権限と委任を表現する言語が開発される可能性があります。 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-Requestは、ルートノードに参照されます（DDT Map-Requestがルートノードに転送される条件の正式な説明については、セクション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クライアント（通常はMap-Resolver）は、LISPカプセル化制御メッセージ（ECM）を使用してMap-RequestメッセージをDDTノードに送信します。 ECMのフォーマットは[RFC6830]で定義されています。この仕様では、図に示され、以下で説明されているように、カプセル化された制御メッセージ（ECM）ヘッダーに新しいフラグ "DDT-originated"が追加されています。
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由来」フラグ。このフラグは、DDTクライアントによって設定され、受信者が必要に応じてMap-Referralメッセージを返す必要があることを示します。このフラグの使用については、セクション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.
この仕様は、Map-Referralメッセージと呼ばれる新しいLISPメッセージを定義します。 Map-Referralメッセージは、DDTノードからDDT Map-Requestメッセージへの応答としてDDTクライアントに送信されます。 Map-Referralメッセージフィールドの詳細なレイアウトについては、セクション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.
NODE-REFERRAL（0）：応答するDDTノードが、要求されたXEIDと一致するXEIDプレフィックスを1つ以上の他のDDTノードに委任したことを示します。 Map-Referralメッセージには、「map-record」と追加情報が含まれます。最も重要なのは、プレフィックスが委任された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プレフィックスを1つ以上のDDT Map-Serverに委任したことを示します。 NODE-REFERRALと同じ追加情報が含まれていますが、受信側の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-Serverが、1つ以上の登録済みETRを持つ信頼できるXEIDプレフィックスと一致するDDT Map-Requestを受信したことを示します。これは、クエリを実行しているITRへの回答を提供するために、要求がこれらのETRの1つに転送されたことを意味します。
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 Map-Serverが、ETRが登録されていない構成済みXEIDプレフィックスの1つに対するMap-Requestを受信したことを示します。
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 Map-ServerまたはETRに委任されていません。詳細については、セクション7.1.2を参照してください。また、要求されたEIDをカバーするが、特定のサイトETRが構成されていない信頼できる構成を持つDDT Map-Serverによって送信されます。
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-AUTHORITATIVE（5）：応答するDDTノードが、権限のないXEIDのMap-Requestを受信し、構成された一致するヒント紹介がないことを示します。これは、データベース階層の変更により、キャッシュされた参照が無効になった場合に発生する可能性があります。ただし、そのようなDDTノードに、要求されたEIDをカバーする「ヒント」委任がある場合、NODE-REFERRALまたはMS-REFERRALを適切に返すことを選択できます（MAY）。アクションコードNOT-AUTHORITATIVEを返す場合、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ノードは、返されるXEIDプレフィックスに対して信頼できるDDTノードのRLOCのリストをMap-Referralメッセージに含める必要があります。 DDTクライアントはこの情報を使用して、紹介を「フォロー」するときに、これらのDDTノードの1つに接続します。
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ノードはMap-Referralメッセージに「不完全」フラグを設定します。これは、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-REGISTEREDを設定しているが、一致するXEIDプレフィックスに設定で「完了」のフラグが付いていない場合。 DDT Map-ServerのXEIDプレフィックス構成は、XEIDプレフィックスの構成が同じXEIDプレフィックスに対しても信頼できるすべての「ピア」DDTノードをリストする場合、または、ローカルDDTノードは、XEIDプレフィックスの唯一の信頼できるノードです。
o If it is setting action code NOT-AUTHORITATIVE.
o アクションコードNOT-AUTHORITATIVEを設定している場合。
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]で将来使用するために予約されていました。このドキュメントでは、この値を割り当ててMap-Referralメッセージを識別します。
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：Map-ReferralメッセージのマッピングレコードのACT（アクション）フィールドは、NODE-REFERRAL、MS-REFERRAL、MS-ACK、MS-NOT-REGISTERED、DELEGATION-HOLE、または権限のない。これらのアクションタイプの説明については、セクション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ノードの参照ロケーターのセットが不完全であり、このメッセージの受信者が参照をキャッシュしてはならない（SHOULD NOT）ことを示します。 DDTは、「不完全」フラグ、TTL、およびアクションフィールドを次のように設定します。
-------------------------------------------------------------------
Type (Action field) Incomplete Referral Set TTL values
-------------------------------------------------------------------
0 NODE-REFERRAL No Yes 1440
1 MS-REFERRAL No Yes 1440
1 MS-REFERRALいいえはい1440
2 MS-ACK * * 1440
2 MS-ACK * * 1440
3 MS-NOT-REGISTERED * * 1
3 MS-NOT-REGISTERED * * 1
4 DELEGATION-HOLE No No 15
４ でぇがちおんーほぇ の の １５
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タイプのMap-Server由来の参照の「不完全」フラグ設定は、Map-Serverが同じプレフィックスの完全なピアMap-Server構成を持ち、マッピングレコードの情報。 Map-Serverが情報をエンコードした場合、「不完全」ビットは設定されません。つまり、参照セットには、プレフィックスを提供するすべてのMap-ServerのすべてのRLOCが含まれます。 Map-Serverの構成が、「ピア」Map-Serverに関する完全な情報で構成された一致するプレフィックスにフラグを付けない場合、またはMap-Serverが構成されたロケーターをすべて返さない場合に設定する必要があります。
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：レコードに存在する署名（Signatureセクション）の数を示します。 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：LocatorフィールドのAFI。 AFI値がLISP Canonical Address Format（LCAF）AFIと異なる場合、セキュリティキーはレコードに含まれません。 AFI値がLCAF AFIと等しい場合、LCAFの内容はLCAFのTypeフィールドによって異なります。 LCAFタイプ11は、ロケーターのAFIとともにセキュリティー資料を保管するために使用されます。 DDTノードおよびDDT Map-Serverは、このLCAFタイプを使用して、XEIDプレフィックスMap-Referral Recordの子DDTノードに関連付けられた公開鍵を含めることができます。 LCAFのタイプとフォーマットは[RFC8060]で定義されています。
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]で定義されているMap-Replyメッセージのフィールドと同じです。ただし、RLOCのセットは、照会の結果として照会されるDDTノードに対応し、実際のEIDからRLOCへのマッピングのRLOCには対応しないことに注意してください。
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: The original Record TTL for this Record that is covered by the signature. The Record TTL value is specified in minutes.
元のレコードTTL：署名の対象となるこのレコードの元のレコードTTL。 Record 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.
署名の有効期限と署名の開始：署名の有効期間を指定します。署名は、開始日の前の認証に使用してはならず（MUST NOT）、有効期限後の認証に使用してはなりません（MUST NOT）。各フィールドは、1970年1月1日00:00:00 UTCから経過した32ビットの符号なし秒数の形式で日付と時刻を指定し、うるう秒を無視して、ネットワークバイト順で示します。
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.
鍵タグ：署名DDTノードに複数の有効な鍵が存在する場合に、この署名に使用される鍵を指定する識別子。
Sig Length: The length of the Signature field in bytes.
Sig長さ：バイト単位の署名フィールドの長さ。
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-Algorithm：署名に使用される暗号アルゴリズムの識別子。この仕様で定義されているSig-Algorithm値を表1に示します。この仕様に準拠する実装は、DDT署名用に少なくともRSA-SHA256を実装する必要があります。 Sig-Algorithmタイプ1（RSA-SHA1）は非推奨であり、使用すべきではありません（SHOULD NOT）。
+---------------+------------+-----------+------------+
| 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.
署名：この署名が属するMap-Referral Record全体をカバーする暗号署名が含まれています。署名を計算する目的で、レコード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ノード）を導入し、Map-ServerおよびMap-Resolversの機能を拡張してMap-Referralメッセージを送受信します。これらの各デバイスの動作を以下に説明します。
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 Map-Requestを受信すると、要求された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ノードの委任されたプレフィックスの1つと一致する場合、Map-Referralメッセージは、一致するより具体的なXEIDプレフィックスと、関連するセキュリティ情報を含む、参照ターゲットDDTノードのRLOCのセットとともに返されます（セクション10を参照）セキュリティの詳細については）。委任の少なくとも1つのDDTノードがDDT Map-Serverであることがわかっている場合、Map-ReferralメッセージをアクションコードMS-REFERRALとともに送信して、LISP-SEC情報であることを受信者に示す必要があります（保留中に保存されている場合）リクエスト）次のDDT Map-Requestに含める必要があります。それ以外の場合は、アクションコードNODE-REFERRALを使用する必要があります。
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ノードは、データベース階層内の任意の場所にあるDDTノードへの参照を提供できる他のXEIDプレフィックスで構成することもできます。 「ショートカットヒント」を定義するこの機能は、構成する必要はありませんが、特にプライベートネットワークの展開では、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.
リフェラルヒントを適切に使用すると、解決されるXEIDプレフィックスに対して信頼できるDDT Map-Serverを見つけるためにDDTクライアントが従う必要があるリフェラルの数を減らすことができます。一方、ヒントを誤って使用すると、DDTノード間に循環依存関係（または「参照ループ」）が作成される可能性があります。 DDTクライアントは、このような循環参照を処理できるように準備する必要があります。循環参照を検出して無限ループを防止するためにDDTクライアントが実装する必要のある参照ループと対策については、セクション7.3.4を参照してください。
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 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.
ヒントの使用に関連するもう1つの危険は、DDTの展開が複数の管理ドメインにまたがる場合です（つまり、異なる機関が同じDDTデータベース内のDDTノードを管理する場合）。この場合、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ノードは、 DDTノード。アクションコードはDELEGATION-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-AUTHORITATIVEを含む否定的なMap-Referralを返す必要があります。
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-ServerがDDT Map-Requestを受信すると、その操作は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-Requestは宛先ETR RLOCの1つに転送されます（または、プロキシMap-Replyサービスを提供している場合、Map-ServerはMap-Replyを送信します）。アクションコードMS-ACKのMap-Referralは、DDT Map-Requestの送信者に返される必要があります。
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プレフィックスと一致する場合、アクションコードMS-NOT-REGISTEREDの否定のMap-ReferralがDDT Map-Requestの送信者に返される必要があります。
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クライアントは、1つ以上のDDTノードにクエリを実行し、アクションコードMS-ACK（またはエラー表示）で受信するまで、返された参照をたどる反復プロセスを使用します。 MS-ACKは、Map-RequestがETRに転送されるMap-Serverに送信されたことを示し、ETRはMap-Request内のロケーターアドレスにMap-Replyを提供します。
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 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.
DDTクライアント機能は、通常、DDT Map-Resolversによって実装されます。他のMap-Resolverと同様に、DDT Map-Resolverはクライアント（通常はITR）からのMap-Requestを受け入れ、それらのMap-RequestがMap-Repliesを生成する正しいETRに確実に転送されるようにします。ただし、LISP代替論理トポロジ（LISP + ALT）マッピングシステム[RFC6836]を使用するMap-Resolverとは異なり、DDT Map-ResolverはDDTクライアント機能を実装して、Map-Requestに応答する正しいETRを見つけます。これには、追加の状態を維持するためにDDT Map-Resolverが必要です。Map-Referralキャッシュと、反復参照プロセスを実行している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クライアント機能はITRに実装できます。この場合、DDTクライアントは別のネットワーク要素からMap-Requestを受信しません。代わりに、同等の情報がプログラミングインターフェイスを介してDDTクライアントに提供されます。
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 Map-Resolverの場合、これは受信したカプセル化されたMap-Requestの形式になります）、最初にそのXEIDの最長一致検索を実行します参照キャッシュ。一致が見つからない場合、または負のキャッシュエントリが見つかった場合、宛先はデータベースにありません。 Negative Map-Replyを返さなければならず（MUST）、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-Resolverの場合、これは元のMap-Requestからカプセル化ヘッダーを差し引いたものです）。反復参照プロセスを通じて進捗状況を追跡するために必要な情報。 「紹介XEIDプレフィックス」も初期化され、紹介がまだ受信されていないことを示します。次に、DDTクライアントはXEIDのDDT Map-Request（メッセージヘッダーに「DDT-originated」フラグが設定されたカプセル化Map-Requestです）を作成しますが、元の要求に含まれている可能性のある認証データはありません。選択した参照キャッシュエントリのRLOCの1つにDDT Map-Requestを送信します。紹介キャッシュには、最初に1つ以上の静的に構成されたエントリが読み込まれます。以下に説明するように、紹介をたどると追加のエントリが追加されます。参照をキャッシュするために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 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クライアントの静的に構成された初期紹介キャッシュには、ルートDDTノードまたはルートDDTノードのヒントを含む1つ以上のDDTノードのRLOCを含む「デフォルト」エントリを含める必要があります。 DDTクライアントにそのような構成がない場合、既知のマッピングデータベースのサブセットの外部にあるEIDのクエリを受信すると、否定マップ応答を返します。これは、プライベートネットワークの展開や、LISPへの初期移行時に使用するサイトが少ない場合に望ましい場合がありますが、LISPがインターネットで一般的に使用されている場合は適切ではありません。セクション10で説明されているようにDDTメッセージ交換が認証される場合、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-Requestを送信した後、DDTクライアントはMap-Referral応答を受信することを期待します。タイムアウト期間内に何も発生しない場合、DDTクライアントは要求を再送信し、参照キャッシュエントリの次のRLOCが使用可能な場合は、それをRLOCに送信します。すべてのRLOCが試行され、それぞれに最大数の再送信が発生した場合、保留中の要求リストエントリはデキューされ、破棄されます。この場合、DDTクライアントは元の要求の送信者に応答を返しません。
A DDT client processes a received Map-Referral message according to each action code:
DDTクライアントは、各アクションコードに従って、受信したMap-Referralメッセージを処理します。
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.
NODE-REFERRAL：DDTクライアントは、セクション7.3.4で説明されているように、可能な参照ループをチェックします。ループが見つからない場合、DDTクライアントは、Map-Referralメッセージで返されたプレフィックスを参照キャッシュに保存し、保留中の要求リストエントリの保存されたプレフィックスと保存されたRLOCを更新し、新しいDDT Map-Requestを送信して紹介に従います参照セットにリストされているDDTノードのRLOCの1つに。元のMap-Requestで保存されたセキュリティ情報は含めないでください。
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クライアントは、元のMap-Requestで保存されたセキュリティ情報をMap-Serverに送信される新しいMap-Requestに含める必要があることを除いて、NODE-REFERRALと同じ方法でMS-REFERRALを処理します（参照）セキュリティの詳細については、セクション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 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.
MS-ACK：DDT Map-ServerからMS-ACKが返され、XEIDのMap-Requestに応答できる1つ以上の登録済みETRがあり、要求がそれらのいずれかに転送されていることを示します（または、 Map-Serverがプレフィックスのプロキシサービスを提供している場合、クエリを実行しているITRに応答が送信されます）。保留中の要求に保存されたLISP-SEC情報が含まれていない場合、またはその情報が以前のDDT Map-Requestにすでに含まれている場合（MS-REFERRALまたは以前のMS-ACK参照への応答としてDDTクライアントによって送信されます）、次にXEIDの保留中の要求が完了しています。要求の処理は停止し、すべての要求状態を破棄できます。それ以外の場合、LISP-SEC情報は必須であり、信頼できるDDT Map-Serverにはまだ送信されていません。 DDTクライアントは、LISP-SEC情報が含まれたDDT Map-Requestを再送信する必要があり、保留中の要求キューエントリは、アクションコードMS-ACKを持つ別のMap-Referralが受信されるまで残ります。 「不完全」フラグが設定されていない場合、プレフィックスは参照キャッシュに保存されます。
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：一致する信頼できるXEIDプレフィックスに登録されたETRがなかったため、クエリされたDDT Map-Serverは要求を処理できませんでした。 DDTクライアントは、保留中の要求で保存されたすべてのRLOCをまだ試行していない場合、Map-Requestをそのリスト内の次のRLOCに送信します。すべてのRLOCが試行された場合、宛先XEIDは登録されておらず、到達できません。 DDTクライアントは、リクエスターに（または、DDT Map-Resolverの場合は、元のMap-Requestの送信者に）負のMap-Replyを返さなければなりません（MUST）。このMap-Replyには、このDDT Map-Serverが権限を持ち、登録が存在しない範囲で、最も固有性の低いXEIDプレフィックスが含まれています。 Negative Map-ReplyのTTL値を1分に設定する必要があります（SHOULD）。接頭辞に対して負の参照キャッシュエントリが作成され（そのTTLも1分に設定する必要があります（SHOULD））、要求の処理は停止します。
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 Map-Serverには、要求されたXEIDと一致するXEIDプレフィックスが定義されていなかったため、XEIDはマッピングデータベースに存在しません。 DDTクライアントは、否定的なMap-Replyをリクエスターに（または、DDT Map-Resolverの場合は、元のMap-Requestの送信者に）返す必要があります。このMap-Replyは、委任が存在せず、要求されたXEIDと一致する最も固有性の低いXEIDプレフィックスを示し、15分のTTL値を持つ必要があります（SHOULD）。接頭辞に対して負の参照キャッシュエントリが作成され（これもTTLが15分である必要があります（SHOULD））、保留中の要求の処理が停止します。
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.
NOT-AUTHORITATIVE：照会されたDDT Map-Serverは、要求されたXEIDに対して権限がありません。これは、データベース階層の変更により、キャッシュされた参照が無効になった場合に発生する可能性があります。このメッセージを受信するDDTクライアントが古いキャッシュ情報を使用していると判断できる場合、そのキャッシュ情報を削除して、「ルート」キャッシュエントリから元のMap-Requestを再試行することを選択できます。キャッシュされた参照情報を使用しなかったクエリへの応答としてこのアクションコードが受信された場合、データベースの同期の問題または構成エラーを示しています。保留中のリクエストは通知なく破棄されます。つまり、この回答の原因となったリクエストのすべての状態が削除され、元のリクエスタには回答が返されません。
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クライアントにMap-Replyを返す、誤って構成されたDDTノード（たとえば、プロキシMap-Serverとして機能）などの他の状態が考えられます。それらはエラーと見なされ、そのようにログに記録されます。そのような場合にDDTクライアントが他に何をすべきかは明確ではありません。 1つの可能性は、保留中の要求リストエントリを削除し、ネガティブマップ応答をリクエスター（または、DDTマップリゾルバーの場合は、元のマップ要求の送信者）に送信することです。または、DDTクライアントがDDTノードによる予期しない動作を検出した場合、そのノードを参照キャッシュで使用不可としてマークし、保留中の要求を更新して、参照キャッシュに複数のノードがリストされている場合に別のDDTノードを試すことができます。いずれの場合も、参照エラー（参照ループを含む）を引き起こすMap-Referralメッセージに含まれる接頭辞は、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クライアントは、要求されたXEIDのより具体的なXEIDプレフィックス情報を持つことが期待されるDDTノードRLOCの新しいセットをクエリするように指示されます。可能な「反復ループ」（応答を見つけることなく一連のDDTノード間で参照を前後に追跡すること）を防ぐために、DDTクライアントは保留中の各要求について最後に受信した参照XEIDプレフィックスを保存し、新しく受信したかどうかを確認しますNODE-REFERRALまたはMS-REFERRALメッセージには、より具体的な参照XEIDプレフィックスが含まれています。保存されたXEIDプレフィックスの完全一致またはそれほど具体的でない一致は、参照ループを示します。ループが検出された場合、DDT Map-Resolverは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 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.
DDTクライアントがルックアップキューにエントリを追加し、XEIDの初期Map-Requestを送信する場合、キューエントリには以前の参照XEIDプレフィックスがないことに注意してください。つまり、DDT Map-Resolverが接続する最初のDDTノードは、DDT階層内のどこにでも参照を提供できます。これにより、DDTクライアントは最初のキャッシュエントリに基本的にすべてのDDTノードRLOCを使用でき、最初のリフェラルに依存してMap-Requestsの適切な開始点を提供できます。すべての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 Map-Server関数とDDT Map-Resolver関数のそれぞれを以下に説明します。最初に単純な「疑似コード」を使用し、次に決定木の形式で説明します。
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
if ( authentication signature validation failed ) {
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
}
}
switch (map_referral_type) {
スイッチ（map_referral_type）{
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
ケースDELEGATION_HOLE：キャッシュし、ネガティブマップ応答を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 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_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
}
}
+----------------+
| 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
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'
}
}
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
Default_DdtNode_Ttl 1440分Default_Registered_Ttl 1440分Default_Negative_Referral_Ttl 15分Default_Configured_Not_Registered_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
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-Resolverに到達するMap-Requestsとそれに続く反復DDT参照のいくつかの可能なシナリオを示します。この例では、EDTがIPv6 AFにある間、DDTノードのRLOCがIPv4アドレス空間に表示されます。階層的な委任と紹介の正確な特定の同じ原則は、関連する長さのビット文字列としてアドレス階層を表現できるすべてのAFに等しく適用できます。 IPv4プレフィックスのDDT「ツリー」は、すぐに実用的な価値を持つもう1つのAFです。このセクションは、おそらくIPv4 EIDを使用するものとIPv6 RLOCを使用するものを含む追加の例から利益を得ることができます。このドキュメントを標準化トラックに移動する場合は、そのような例を追加することを検討してください。
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のRLOCを見つけるために参照がどのように行われるかを示すために、DBID = 0、IID = 0、AFI = 2、およびEID = 0/0の次のEIDトポロジーの例を検討してください。
+---------------------+ +---------------------+
| 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 Map-Resolversは、これらのアドレスのデフォルトの参照キャッシュエントリで構成されています。
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の2つの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 Map-Serverに委任します。
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 Map-Serverは、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および2001：db8：0501 :: / 48のDDT Map-Serverに委任するようにさらに構成されています。 RLOC 192.0.2.221を使用するDDT Map-Server。
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 Map-Serverは、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 Map-Serverは、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 Map-Serverへの別の委任が続くDDT Map-Resolverを示しています。
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のカプセル化されたMap-Requestを、構成された（DDT）Map-Resolverの1つに送信します。 DDT Map-Resolverは次のように進行します。
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 Map-Request（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、アクションコードNODE-REFERRAL、RLOCセット（192.0.2.11、192.0.2.12）のMap-Referralを受信（および参照キャッシュに保存）します。
3. Send a DDT Map-Request to 192.0.2.11 or 192.0.2.12.
3. DDT Map-Requestを192.0.2.11または192.0.2.12に送信します。
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）のMap-Referralを受信（および参照キャッシュに保存）します。
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. DDT Map-Requestを192.0.2.101に送信します。 ITRから発信されたカプセル化Map-Requestに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のDDT Map-Serverは、DDT Map-Requestをカプセル化解除し、Map：Requestを2001：db8：0103 :: / 48の登録済みsite1 ETRに転送します。
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-Serverは、EIDプレフィックス2001：db8：0103 :: / 48のMap-Referralメッセージ、アクションコードMS-ACKをDDT Map-Resolverに送信します。
8. The DDT Map-Resolver receives the Map-Referral message and dequeues the pending request for 2001:db8:0103:1::1.
8. DDT Map-ResolverはMap-Referralメッセージを受信し、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. 2001：db8：0103 :: / 48のsite1 ETRは、DDT Map-Serverによって転送されたMap-Requestを受け取り、Map-ReplyをITR1に送信します。
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.
次の例は、3つのレベルの委任を示しています。ルートから最初のDDTノード、最初のDDTノードから2番目のDDTノード、2番目のDDTノードからDDT Map-Serverです。
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のカプセル化されたMap-Requestを、ITR1とは異なる構成済み（DDT）Map-Resolverの1つに送信します。 DDT Map-Resolverは次のように進行します。
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 Map-Request（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、アクションコードNODE-REFERRAL、RLOCセット（192.0.2.11、192.0.2.12）のMap-Referralを受信（および参照キャッシュに保存）します。
3. Send a DDT Map-Request to 192.0.2.11 or 192.0.2.12.
3. DDT Map-Requestを192.0.2.11または192.0.2.12に送信します。
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、アクションコードNODE-REFERRAL、RLOCセット（192.0.2.201）のMap-Referralを受信（および参照キャッシュに保存）します。
5. Send a DDT Map-Request to 192.0.2.201.
5. DDT Map-Requestを192.0.2.201に送信します。
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）のMap-Referralを受信（および参照キャッシュに保存）します。
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. DDT Map-Requestを192.0.2.221に送信します。 ITRから発信されたカプセル化Map-Requestに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にあるDDT Map-Serverは、DDT Map-Requestをカプセル化解除し、Map-Requestを2001：db8：0501：8 :: / 64の登録済みサイト5 ETRに転送します。
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-Serverは、EIDプレフィックス2001：db8：0501：8 :: / 64のMap-Referralメッセージ、アクションコードMS-ACKをDDT Map-Resolverに送信します。
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-ResolverはMap-Referral（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. 2001：db8：0501：8 :: / 64のsite5 ETRは、DDT Map-Serverによって転送されたMap-Requestを受け取り、Map-ReplyをITR2に送信します。
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 Map-Resolverが保存済みの紹介キャッシュエントリを使用して紹介プロセスをスキップし、以前に要求されたものと同様の接頭辞のDDT Map-Serverに直接移動する方法を示しています。
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の例で使用されているのと同じMap-Resolverを使用します。それは、2001：db8：0104：2 :: 2のカプセル化されたMap-Requestをその（DDT）Map-Resolverに送信します。 DDT Map-Resolverは、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. DDT Map-Request（2001：db8：0104：2 :: 2の場合）を192.0.2.101に送信します。 ITRから発信されたカプセル化Map-Requestに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のDDT Map-Serverは、DDT Map-Requestをカプセル化解除し、Map-Requestを2001：db8：0104 :: / 48の登録済みsite2 ETRに転送します。
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-Serverは、EIDプレフィックス2001：db8：0104 :: / 48のMap-Referralメッセージ、アクションコードMS-ACKをDDT Map-Resolverに送信します。
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-ResolverはMap-Referral（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. 2001：db8：0104 :: / 48のsite2 ETRはMap-Requestを受信し、Map-Replyを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 Map-Resolverが保存済みの紹介キャッシュエントリを使用して、以前に要求されたものと同様のプレフィックスの非ルート中間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の例で使用されているのと同じMap-Resolverを使用します。 2001：db8：0500：2：4 :: 1のカプセル化されたMap-Requestをその（DDT）Map-Resolverに送信し、RLOCが設定された2001：db8：0500 :: / 40のNODE-REFERRALキャッシュエントリを見つけます。 （192.0.2.201）。次のように進行します。
1. Send a DDT Map-Request (for 2001:db8:0500:2:4::1) to 192.0.2.201.
1. DDT Map-Request（2001：db8：0500：2：4 :: 1の場合）を192.0.2.201に送信します。
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）のMap-Referralを受信（および参照キャッシュに保存）します。
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. DDT Map-Requestを192.0.2.211に送信します。 ITRから発信されたカプセル化されたMap-Requestに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のDDT Map-Serverは、DDT Map-Requestをカプセル化解除し、Map-Requestを2001：db8：0500：2 :: / 64の登録済みサイト4 ETRに転送します。
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 Map-Serverは、EIDプレフィックス2001：db8：0500：2 :: / 64のMap-Referralメッセージ、アクションコードMS-ACKをDDT Map-Resolverに送信します。
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-ResolverはMap-Referral（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. 2001：db8：0500：2 :: / 64のsite4 ETRは、Map-Requestを受け取り、Map-Replyを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:
この例では、上記で学習した2001：db8：0500 :: / 48のキャッシュされたMS-REFERRALを使用して、192.0.2.211のDDT Map-Serverでルックアッププロセスを開始します。 DDT Map-Resolverは次のように進行します。
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. DDT Map-Request（2001：db8：0500 :: 1の場合）を192.0.2.211に送信します。 ITRから発信されたカプセル化Map-Requestに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. 2001：db8：0500 :: / 48に対して権限がある192.0.2.211のDDT Map-Serverには、2001：db8：0500 :: 1に対応する委任がありません。 2001：db8：0500 :: / 64のMap-Referralメッセージ、アクションコードDELEGATION-HOLEでDDT Map-Resolverに応答します。プレフィックス2001：db8：0500 :: / 64が使用されるのは、要求されたEIDと一致するが、構成された委任の1つとは一致しない最も固有性の低いプレフィックスであるためです（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-Resolverは委任を受け取り、2001：db8：0500 :: / 64の負の参照キャッシュエントリを追加し、2001：db8：0500 :: 1の保留中の要求をデキューし、負のMap-Replyを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プレフィックスのMap-Referralレコードにデジタル署名するために使用される1つ以上の公開/秘密キーペアで構成されます。つまり、各公開/秘密鍵ペアは、DDTノードと、それが信頼できるXEIDプレフィックスの組み合わせに関連付けられています。すべてのDDTノードは、その子DDTノードの公開鍵でも構成されます。ターゲットの子DDTノードの公開キーをMap-Referral Recordsに含め、DDTノードの秘密キーで各レコードに署名することにより、DDTノードはその信頼できるXEIDプレフィックスのサブプレフィックスを子DDTノードに安全に委任できます。ヒントを提供するように構成されたDDTノードには、そのヒントが指すDDTノードの公開鍵も必要です。 LCDTタイプ11を使用してDDTノードキーをエンコードし、参照されるDDTノードのRLOCにキーを関連付けることができます。ノードに複数の公開鍵がある場合、ノードはこれらの鍵の少なくとも1つでレコードに署名する必要があります。ノードに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.
Map-Resolversは、「トラストアンカー」と呼ばれる1つ以上の信頼できる公開鍵で構成されます。トラストアンカーは、DDTセキュリティインフラストラクチャの認証に使用されます。 Map-Resolversは、（1）トラストアンカーとして構成されているか、（2）署名されたMap-Referralの一部としてノードの親から取得することにより、DDTノードの公開鍵を検出できます。ノードの親から取得した公開鍵は、トラストアンカーによって署名されている場合、または以前に信頼されていた鍵によって署名されている場合、信頼されていると見なされます。通常、Map-Resolverでは、ルートDDTノードの公開鍵をトラストアンカーとして構成する必要があります。 Map-Resolverが公開鍵を認証すると、関連する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-Referralsに署名します。すべての署名済みMap-Referralには、各子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-Resolverは、構成されたトラストアンカー（通常はルートDDTノード）からリーフノード（Map-Server）への認証チェーンを形成できます。 Map-Resolversはこの認証チェーンを利用して、指定されたXEIDプレフィックスに対して権限のあるMap-Serverに到達するまでDDTツリーを歩きながらMap-Referral署名を検証します。
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-Requestを受信すると、DDTノードはセクション7で指定されたMap-Referralで応答します。Map-Referralに存在するすべてのレコードについて、DDTノードはレコードのXEIDプレフィックスとRLOCに関連付けられた公開キーも含みます子DDTノードの。 Map-Referralに含まれる各レコードは、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 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ノードの1つの公開鍵をアドバタイズする場合、子DDTノードは後でその鍵を取り消すことができます。 DDTノードはそれらをクエリするMap-Resolverを追跡しないため、失効はプルモデルで行われ、Map-Resolverは、そのキーを所有するノードをクエリするときにのみ、キーの失効について通知されます。親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ノードは、このレコードをカバーするレコードに署名も含める必要があります。これは、取り消されるキーに対応する秘密キーを使用して計算されます。このようなレコードは「失効レコード」と呼ばれます。このレコードをMap-Referralsに含めることにより、DDTノードはMap-Resolversのクエリに失効したキーを通知します。取り消された鍵で計算されたデジタル署名は、取り消しの認証にのみ使用でき、データの検証には使用すべきではありません（SHOULD NOT）。侵害されたキーが他の有効なキーを取り消すのを防ぐために、特定のキーはその特定のキーの取り消しに署名するためにのみ使用できます。他のキーを取り消すために使用することはできません。これは、[RFC5011]で説明されているように、他の有効なキーを取り消すために危険にさらされたキーの使用を防ぎます。失効レコードは、最初にキーをアドバタイズしたレコードのTTL値以上の期間、親DDTノードからの削除によってキーのアドバタイズが停止された時間からアドバタイズされなければなりません（MUST）。
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ノードと同様に、Map-Serverは、Map-Referralsへの署名に使用する必要がある1つ以上の公開/秘密鍵ペアで構成されます。
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ノードとは異なり、Map-Serverはプレフィックスを委任しないため、生成するMap-Referralsにキーを含める必要はありません。
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 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.
Map-Referralを受信すると、Map-Resolverは最初に、トラストアンカーまたはMap-Referralを送信するDDTノードに関連付けられた以前に認証された公開鍵を使用して署名を検証する必要があります。このMap-Referralを送信するDDTノードに複数の認証済みキーが関連付けられている場合、署名のKey Tagフィールド（セクション6.4.1）を使用して、署名を検証するための正しい公開鍵を選択できます。キータグがそのDDTノードに関連付けられた複数のキーと一致する場合、Map-Resolverは一致するすべてのキーで署名を検証する必要があります。一致するすべてのキーについて、Map-Resolverは、キーがMap-Referral RecordのXEIDプレフィックスに対して信頼できるものであることも確認する必要があります。そのようなキーが見つかった場合、Map-Resolverはそのキーを使用して、レコード内の関連する署名を検証する必要があります。 （1）一致するキーが見つからない、（2）Map-Referral RecordのXEIDプレフィックスに対して信頼できる一致するキーがない、または（3）そのようなキーが見つかったが署名が有効でない場合、マップ-参照レコードは破損していると見なされ、破棄する必要があります。これは、期限切れのキーが原因である可能性があります。同じ接頭辞に対して信頼できる代替ノードがある場合、Map-Resolverはこのノードの他の兄弟を試してもよい（MAY）。そうでない場合、Map-ResolverはDDTノードの親にクエリを実行して、有効なキーを取得できます。数回試行してもMap-Resolverが署名を検証できない場合は、カウンターまたはタイマーを使用してこのプロセスを繰り返さないようにすることをお勧めします。
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.
署名が検証されると、Map-ResolverはMap-ReferralのXEIDプレフィックス委任を検証しました。これは、子DDTノードの公開鍵が認証されたことも意味します。 Map-Resolverはこれらのキーを、各子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 [RFC8060]で定義されている追加のEID形式をサポートするためのキー構造など、LISP-DDTで使用するための追加のキー構造。
o Management of the DDT Map-Resolver referral cache -- in particular, detecting and removing outdated entries.
o DDT Map-Resolver参照キャッシュの管理-特に、古いエントリの検出と削除。
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-Referral」が「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インフラストラクチャ内でデータ発信元認証、データ整合性保護、およびXEIDプレフィックス委任を提供するDDTセキュリティアーキテクチャについて説明します。
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プレフィックス承認はこのドキュメントの範囲外ですが、Secure Inter-Domain Routing（SIDR）ワーキンググループ[RFC6480]は、インターネットルーティングのセキュリティ強化をサポートするインフラストラクチャを開発しています。 SIDRの公開鍵基盤（PKI）と、それがPKIデータオブジェクトの格納と配布に使用する分散リポジトリシステムをDDTデバイスで使用して、それらが一連の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-Referralメッセージ、およびMap-Request / Map-Replyプロトコルを保護する方法について説明します。将来的には、LISP-SECに代わる他のLISPセキュリティメカニズムが開発される可能性があります。このような将来のセキュリティメカニズムでは、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公開鍵インフラストラクチャを使用して、Map-Resolverから対応するMap-ServerへのLISP-SEC鍵マテリアル（ワンタイムキー）の転送を保護できます。このため、LISP-SECがLISP-DDTマッピングデータベースと組み合わせて展開され、Map-ResolverとMap-Server間のパスを保護する必要がある場合は、セクション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] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「The Locator / ID Separation Protocol（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. Farinacci、「Locator / ID Separation Protocol（LISP）Map-Server Interface」、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。、「Early IANA Allocation of Standards Track Code Points」、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.、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>。
[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] Farinacci、D.、Meyer、D。、およびJ. Snijders、「LISP Canonical Address Format（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、「Address Family Numbers」、<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-Security（LISP-SEC）」、Work in Progress、draft-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：DNS Hierarchy to Support the LISP Mapping System」、IEEE Journal Communications、Volume 28、Issue 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.、Farinacci、D.、Meyer、D。、およびD. Lewis、「Locator / ID Separation Protocol Alternative Logical Topology（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：A Not-so-novel Endpoint ID（EID）to Routing Locator（RLOC）Database」、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.
著者は、階層データベース構造とルックアップ反復アプローチに影響を与えたLISP-TREE [LISP-TREE]とLISP反復可能マッピングに関する作業に対して、Lorand Jakab、Albert Cabellos、Florin Coras、Damien Saucez、Olivier Bonaventureに感謝の意を表しますこのドキュメントで説明します。また、Dino FarinacciとIsidor Kouvelasの実装作業にも感謝します。テストのためにセリーナ・ハイムリッチとスリン・サブラマニアンに。セキュリティ処理に関する作業については、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
Darrel Lewis Cisco Systems
ダレルルイスシスコシステムズ
Email: darlewis@cisco.com
Vina Ermagan Cisco Systems
ワインErmagan Tsisco Systems
Email: vermagan@cisco.com
Amit Jain Juniper Networks
Amit Jain Juniper Networks
Email: atjain@juniper.net
Anton Smirnov Cisco Systems
アントンスミルノフシスコシステムズ
Email: as@cisco.com