[要約] RFC 9301 は、LISPの制御プレーンとマッピングサービスに関する要約であり、LISP Map-Resolver と LISP Map-Server がエンドポイント ID (EID) とルーティングロケータのマッピングデータベースを提供することで、LISPのエッジ部分を実装し、LISPサイトの EID アドレス可能ノードを接続することを目的としています。
Internet Engineering Task Force (IETF) D. Farinacci
Request for Comments: 9301 lispers.net
Obsoletes: 6830, 6833 F. Maino
Category: Standards Track Cisco Systems
ISSN: 2070-1721 V. Fuller
vaf.net Internet Consulting
A. Cabellos, Ed.
Universitat Politecnica de Catalunya
October 2022
Locator/ID Separation Protocol (LISP) Control Plane
ロケーター/ID分離プロトコル（LISP）制御プレーン
Abstract
概要
This document describes the control plane and Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two types of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provide a simplified "front end" for one or more Endpoint IDs (EIDs) to Routing Locator mapping databases.
このドキュメントでは、2つのタイプのLISP話（LISP Map-ResolverとLISP Map-Server）によって実装されたロケーター/ID分離プロトコル（LISP）のコントロールプレーンとマッピングサービスについて説明します。「1つ以上のエンドポイントID（EIDS）のロードロケーターマッピングデータベースへ。
By using this control plane service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) are not dependent on the details of mapping database systems; this behavior facilitates modularity with different database designs. Since these devices implement the "edge" of the LISP control plane infrastructure, connecting EID addressable nodes of a LISP site, the implementation and operational complexity of the overall cost and effort of deploying LISP is reduced.
このコントロールプレーンサービスインターフェイスを使用して、マップリゾルバーとマップサーバーと通信することにより、Lisp Ingressトンネルルーター（ITR）および出力トンネルルーター（ETR）は、マッピングデータベースシステムの詳細に依存しません。この動作は、さまざまなデータベース設計でモジュール性を促進します。これらのデバイスは、LISPコントロールプレーンインフラストラクチャの「エッジ」を実装し、LISPサイトのEIDアドレス指定可能なノードを接続するため、LISPの展開の全体的なコストと努力の実装と運用の複雑さが削減されます。
This document obsoletes RFCs 6830 and 6833.
このドキュメントは、RFCS 6830および6833を廃止します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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 https://www.rfc-editor.org/info/rfc9301.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9301で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
1.1. Scope of Applicability
2. Requirements Notation
3. Definitions of Terms
4. Basic Overview
5. LISP IPv4 and IPv6 Control Plane Packet Formats
5.1. LISP Control Packet Type Allocations
5.2. Map-Request Message Format
5.3. EID-to-RLOC UDP Map-Request Message
5.4. Map-Reply Message Format
5.5. EID-to-RLOC UDP Map-Reply Message
5.6. Map-Register Message Format
5.7. Map-Notify and Map-Notify-Ack Message Formats
5.8. Encapsulated Control Message Format
6. Changing the Contents of EID-to-RLOC Mappings
6.1. Solicit-Map-Request (SMR)
7. Routing Locator Reachability
7.1. RLOC-Probing Algorithm
8. Interactions with Other LISP Components
8.1. ITR EID-to-RLOC Mapping Resolution
8.2. EID-Prefix Configuration and ETR Registration
8.3. Map-Server Processing
8.4. Map-Resolver Processing
8.4.1. Anycast Operation
9. Security Considerations
10. Privacy Considerations
11. Changes Related to RFCs 6830 and 6833
12. IANA Considerations
12.1. LISP UDP Port Numbers
12.2. LISP Packet Type Codes
12.3. LISP Map-Reply EID-Record Action Codes
12.4. LISP Address Type Codes
12.5. LISP Algorithm ID Numbers
12.6. LISP Bit Flags
13. References
13.1. Normative References
13.2. Informative References
Acknowledgments
Authors' Addresses
The Locator/ID Separation Protocol [RFC9300] (see also [RFC9299]) specifies an architecture and mechanism for dynamic tunneling by logically separating the addresses currently used by IP in two separate namespaces: Endpoint IDs (EIDs), used within sites; and Routing Locators (RLOCs), used on the transit networks that make up the Internet infrastructure. To achieve this separation, LISP defines protocol mechanisms for mapping from EIDs to RLOCs. In addition, LISP assumes the existence of a database to store and propagate those mappings across Mapping System nodes. Several such databases have been proposed; among them are the Content distribution Overlay Network Service for LISP-NERD (a Not-so-novel EID-to-RLOC Database) [RFC6837], LISP Alternative Logical Topology (LISP-ALT) [RFC6836], and LISP Delegated Database Tree (LISP-DDT) [RFC8111].
ロケーター/ID分離プロトコル[RFC9300]（[RFC9299]も参照）は、サイト内で使用されている2つの別々の名前空間で現在使用されている2つの名前空間で現在使用されているアドレスを論理的に分離することにより、動的トンネリングのアーキテクチャとメカニズムを指定します。インターネットインフラストラクチャを構成するトランジットネットワークで使用されるルーティングロケーター（RLOC）。この分離を実現するために、LISPはEIDからRLOCへのマッピングのプロトコルメカニズムを定義します。さらに、LISPは、マッピングシステムノード全体にこれらのマッピングを保存および伝播するデータベースの存在を想定しています。そのようなデータベースがいくつか提案されています。その中には、LISP-NERDのコンテンツ配信オーバーレイネットワークサービス（それほどノーフではないEIDからRLOCデータベース）[RFC6837）、LISP代替論理トポロジ（LISP-ALT）[RFC6836]、およびLISP委任データベースツリー（lisp-ddt）[rfc8111]。
The LISP Mapping Service defines two types of LISP-speaking devices: the Map-Resolver, which accepts Map-Requests from an Ingress Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a mapping database; and the Map-Server, which learns authoritative EID-to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes them in a database.
LISPマッピングサービスは、2種類のLISPスピーキングデバイスを定義します。IngressTunnelルーター（ITR）からのマップリクエストを受け入れ、マッピングデータベースを使用してEid-to-RLOCマッピングを「解決」するMAP-Resolver。また、出力トンネルルーター（ETR）から権威あるEIDからRLOCへのマッピングを学習し、データベースで公開するマップサーバー。
This LISP control plane and Mapping Service can be used by many different encapsulation-based or translation-based data planes, including but not limited to those defined in LISP [RFC9300], the LISP Generic Protocol Extension (LISP-GPE) [RFC9305], Virtual eXtensible Local Area Networks (VXLANs) [RFC7348], VXLAN-GPE [NVO3-VXLAN-GPE], GRE [RFC2890], the GPRS Tunneling Protocol (GTP) [GTP-3GPP], Identifier-Locator Addressing (ILA) [INTAREA-ILA], and Segment Routing (SRv6) [RFC8402].
このLISP制御プレーンおよびマッピングサービスは、LISP [RFC9300]、LISPジェネリックプロトコル拡張（LISP-GPE）[RFC9305]で定義されているものを含むがこれらに限定されない多くの異なるカプセル化ベースまたは翻訳ベースのデータプレーンで使用できます。仮想拡張可能なローカルエリアネットワーク（VXLANS）[RFC7348]、VXLAN-GPE [NVO3-VXLAN-GPE]、GRE [RFC2890]、GPRSトンネルプロトコル（GTP）[GTP-3GPP]、識別剤アドレス（ILA）[INTAREA-ILA]、およびセグメントルーティング（SRV6）[RFC8402]。
Conceptually, LISP Map-Servers share some of the same basic configuration and maintenance properties as Domain Name System (DNS) servers [RFC1035]; likewise, Map-Resolvers are conceptually similar to DNS caching resolvers. With this in mind, this specification borrows familiar terminology (resolver and server) from the DNS specifications.
概念的には、LISP Map-Serversは、ドメイン名システム（DNS）サーバー[RFC1035]と同じ基本構成とメンテナンスプロパティの一部を共有しています。同様に、MAP-Resolversは概念的にDNSキャッシュリゾルバーに似ています。これを念頭に置いて、この仕様はDNS仕様から馴染みのある用語（リゾルバーとサーバー）を借用しています。
Note that this document doesn't assume any particular database mapping infrastructure to illustrate certain aspects of Map-Server and Map-Resolver operations. The Mapping Service interface can (and likely will) be used by ITRs and ETRs to access other mapping database systems as the LISP infrastructure evolves.
このドキュメントは、地図サーバーおよびマップ再配置操作の特定の側面を説明するために、特定のデータベースマッピングインフラストラクチャを想定していないことに注意してください。Mapping Serviceインターフェイスは、ITRとETRによって使用される可能性があります（およびおそらく使用する可能性があります）。LISPインフラストラクチャが進化するにつれて、他のマッピングデータベースシステムにアクセスできます。
LISP is not intended to address problems of connectivity and scaling on behalf of arbitrary communicating parties. Relevant situations are described in Section 1.1 of [RFC9300].
LISPは、arbitrary意的な通信当事者に代わって、接続性とスケーリングの問題に対処することを意図していません。関連する状況は、[RFC9300]のセクション1.1で説明されています。
This document obsoletes [RFC6830] and [RFC6833].
この文書は、[RFC6830]および[RFC6833]を廃止します。
LISP was originally developed to address the Internet-wide route scaling problem [RFC4984]. While there are a number of approaches of interest for that problem, as LISP has been developed and refined, a large number of other uses for LISP have been found and are being implemented. As such, the design and development of LISP have changed so as to focus on these use cases. The common property of these uses is a large set of cooperating entities seeking to communicate over the public Internet or other large underlay IP infrastructures while keeping the addressing and topology of the cooperating entities separate from the underlay and Internet topology, routing, and addressing.
LISPはもともと、インターネット全体のルートスケーリング問題に対処するために開発されました[RFC4984]。LISPが開発され、洗練されているため、その問題には多くの関心のあるアプローチがありますが、LISPの他の多くの用途が発見され、実装されています。そのため、LISPの設計と開発は、これらのユースケースに焦点を当てるように変更されました。これらの用途の共通の特性は、パブリックインターネットやその他の大規模なアンダーレイIPインフラストラクチャを介して通信しようとする協力エンティティの大規模なセットであり、協力エンティティのアドレス指定とトポロジーを、アンダーレイおよびインターネットトポロジ、ルーティング、およびアドレス指定とは別に維持します。
When communicating over the public Internet, deployers MUST consider the following guidelines:
パブリックインターネットを介して通信する場合、展開者は次のガイドラインを考慮する必要があります。
1. LISP Security (LISP-SEC) MUST be implemented [RFC9303]. This means that the S-bit MUST be set in the Map-Reply (Section 5.4), Map-Register (Section 5.6), and Encapsulated Control Messages (ECMs) (Section 5.8).
1. LISPセキュリティ（LISP-SEC）を実装する必要があります[RFC9303]。これは、S-BITをマップ応答（セクション5.4）、マップレジスター（セクション5.6）、およびカプセル化されたコントロールメッセージ（ECM）（セクション5.8）に設定する必要があることを意味します。
2. Implementations SHOULD use 'HMAC-SHA256-128+HKDF-SHA256' as the Algorithm ID (Section 12.5) in the Map-Register message (Section 5.6) and MUST NOT use 'None' or 'HMAC-SHA-1-96-None' as the Algorithm ID (Section 12.5) in the Map-Register message (Section 5.6).
2. 実装は、マップ登録メッセージ（セクション5.6）のアルゴリズムID（セクション12.5）として「HMAC-SHA256-128 HKDF-SHA256」を使用する必要があり、「None」または「HMAC-Sha-1-96-None」を使用してはなりません。マップ登録メッセージ（セクション5.6）のアルゴリズムID（セクション12.5）として。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Map-Server: A network infrastructure component that learns of EID-Prefix mapping entries from an ETR, via the registration mechanism described below, or some other authoritative source if one exists. A Map-Server publishes these EID-Prefixes in a mapping database.
MAP-SERVER：ETRからEID-PREFIXマッピングエントリを学習するネットワークインフラストラクチャコンポーネント、以下の登録メカニズム、または存在する場合は他の権威あるソースを介して。Map-Serverは、これらのEid-Prefixesをマッピングデータベースに公開します。
Map-Request: A control plane message that queries the Mapping System to resolve an EID. A LISP Map-Request can also be sent to an RLOC to test for reachability and to exchange security keys between an encapsulator and a decapsulator. This type of Map-Request is also known as an RLOC-Probe Request.
Map-Request：EIDを解決するためにマッピングシステムを照会するコントロールプレーンメッセージ。LISP Map-RequestをRLOCに送信して、到達可能性をテストし、エンカプセーターと脱カプセレーターの間のセキュリティキーを交換することもできます。このタイプのMap-Requestは、RLOC-Probeリクエストとも呼ばれます。
Map-Reply: A control plane message returned in response to a Map-Request sent to the Mapping System when resolving an EID. A LISP Map-Reply can also be returned by a decapsulator in response to a Map-Request sent by an encapsulator to test for reachability. This type of Map-Reply is known as an RLOC-Probe Reply.
MAP-REPLY：EIDを解決する際にマッピングシステムに送信されるマップリケストに応じて返されたコントロールプレーンメッセージ。Lisp Map-Replyは、到達可能性をテストするために、エンコートレーターから送信されたマップ再クエストに応じて、脱カプセレーターによって返すこともできます。このタイプのMAP-Replyは、RLOCプローブの返信として知られています。
Encapsulated Map-Request: A LISP Map-Request carried within an ECM. This Map-Request has an additional LISP header prepended. Sent to UDP destination port 4342. The "outer" addresses are routable IP addresses, also known as RLOCs. Used by an ITR when sending to a Map-Resolver and by a Map-Server when forwarding a Map-Request to an ETR.
カプセル化されたMap-Request：ECM内で運ばれるLISP Map-Request。このMap-Requestには、追加のLISPヘッダーが準備されています。UDP宛先ポート4342に送信されます。「外側」アドレスは、RLOCSとも呼ばれるルーティング可能なIPアドレスです。Map-Resolverに送信するときにITRが使用し、Map-RequestをETRに転送するときにマップサーバーによって使用されます。
Map-Resolver: A network infrastructure component that accepts LISP Encapsulated (ECM) Map-Requests, typically from an ITR, and determines whether or not the destination IP address is part of the EID namespace; if it is not, a Negative Map-Reply is returned. Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC mapping by consulting a mapping database system.
MAP-Resolver：通常はITRからのLISPカプセル化（ECM）マップ要求を受け入れ、宛先IPアドレスがEIDネームスペースの一部であるかどうかを判断するネットワークインフラストラクチャコンポーネント。そうでない場合は、ネガティブマップ繰り返しが返されます。それ以外の場合、Map-Resolverは、マッピングデータベースシステムに相談することにより、適切なEid-to-RLOCマッピングを見つけます。
Negative Map-Reply: A LISP Map-Reply that contains an empty Locator-Set. Returned in response to a Map-Request if the destination EID is not registered in the Mapping System, is policy-denied, or fails authentication.
ネガティブマップリプリー：空のロケーターセットを含むLISPマップリップ。宛先EIDがマッピングシステムに登録されていない、ポリシー除去、または認証に失敗した場合、マップ要求に応じて返されます。
Map-Register message: A LISP message sent by an ETR to a Map-Server to register its associated EID-Prefixes. In addition to the set of EID-Prefixes to register, the message includes one or more RLOCs to reach ETR(s). The Map-Server uses these RLOCs when forwarding Map-Requests (reformatted as Encapsulated Map-Requests). An ETR MAY request that the Map-Server answer Map-Requests on its behalf by setting the "proxy Map-Reply" flag (P-bit) in the message.
マップ登録メッセージ：ETRからMAPサーバーに送信されたLISPメッセージは、関連するEID-PREFIXESを登録します。登録するEID-PREFIXSのセットに加えて、メッセージにはETRに到達する1つ以上のRLOCが含まれています。Map-Serverは、Map-Requestsを転送するときにこれらのRLOCを使用します（カプセル化されたMap-Requestsとして再フォーマットされます）。ETRは、メッセージ内の「プロキシマップリプリー」フラグ（Pビット）を設定することにより、マップサーバーに代わってマップリケストに回答することを要求する場合があります。
Map-Notify message: A LISP message sent by a Map-Server to an ETR to confirm that a Map-Register has been received and processed. An ETR requests that a Map-Notify be returned by setting the "want-map-notify" flag (M-bit) in the Map-Register message. Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both source and destination. Map-Notify messages are also sent to ITRs by Map-Servers when there are RLOC-Set changes.
Map-Notifyメッセージ：Map-ServerからETRに送信されたLISPメッセージは、マップレジスターが受信および処理されたことを確認します。ETRは、Map-Registerメッセージに「Want-Map-Notify」フラグ（Mビット）を設定することにより、Map-Notifyを返すことを要求します。Map-Replyとは異なり、Map-Notifyは、ソースと宛先の両方にUDPポート4342を使用します。RLOC-SETの変更がある場合、Map-NotifyメッセージはMAPサーバーによってITRに送信されます。
For definitions of other terms, notably Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), and Re-encapsulating Tunnel Router (RTR), refer to the LISP data plane specification [RFC9300].
他の用語の定義、特にトンネルルーター（ITR）、出口トンネルルーター（ETR）、および再カプセンティングトンネルルーター（RTR）の定義については、LISPデータプレーン仕様[RFC9300]を参照してください。
A Map-Server is a device that publishes EID-Prefixes in a LISP mapping database on behalf of a set of ETRs. When it receives a Map-Request (typically originating from an ITR), it consults the mapping database to find an ETR that can answer with the set of RLOCs for an EID-Prefix. To publish its EID-Prefixes, an ETR periodically sends Map-Register messages to the Map-Server. A Map-Register message contains a list of EID-Prefixes plus a set of RLOCs that can be used to reach the ETRs.
Map-Serverは、ETRのセットに代わってLISPマッピングデータベースでEid-Prefixesを公開するデバイスです。Map-Request（通常はITRに由来する）を受信すると、マッピングデータベースを参照して、EID-PrefixのRLOCのセットで回答できるETRを見つけます。EID-PREFIXESを公開するには、ETRが定期的にMap-Registerメッセージをマップサーバーに送信します。Map-Registerメッセージには、EID-Prefixesのリストに加えて、ETRに到達するために使用できるRLOCのセットが含まれています。
When LISP-ALT [RFC6836] is used as the mapping database, a Map-Server connects to the ALT network and acts as a "last-hop" ALT-Router. Intermediate ALT-Routers forward Map-Requests to the Map-Server that advertises a particular EID-Prefix, and the Map-Server forwards them to the owning ETR, which responds with Map-Reply messages.
LISP-ALT [RFC6836]がマッピングデータベースとして使用される場合、MAPサーバーはALTネットワークに接続し、「ラストホップ」ALTルーターとして機能します。中間ALTルーターは、特定のEid-Prefixを宣伝するMap-Serverに移行し、Map-Serverはそれらを所有ETRに転送し、Map Replyメッセージで応答します。
When LISP-DDT [RFC8111] is used as the mapping database, a Map-Server sends the final Map-Referral messages from the Delegated Database Tree.
LISP-DDT [RFC8111]がマッピングデータベースとして使用されると、Map-Serverは委任されたデータベースツリーから最終的なマップ再送信メッセージを送信します。
A Map-Resolver receives Encapsulated Map-Requests from its client ITRs and uses a mapping database system to find the appropriate ETR to answer those requests. On a LISP-ALT network, a Map-Resolver acts as a "first-hop" ALT-Router. It has Generic Routing Encapsulation (GRE) tunnels configured to other ALT-Routers and uses BGP to learn paths to ETRs for different prefixes in the LISP-ALT database. The Map-Resolver uses this path information to forward Map-Requests over the ALT to the correct ETRs. On a LISP-DDT network [RFC8111], a Map-Resolver maintains a referral cache and acts as a "first-hop" DDT node. The Map-Resolver uses the referral information to forward Map-Requests.
Map-Resolverは、クライアントITRSからカプセル化されたマップ再クエストを受信し、マッピングデータベースシステムを使用して適切なETRを見つけてそれらの要求に応答します。LISP-ALTネットワークでは、マップ分解装置が「最初のホップ」Alt-Routerとして機能します。他のALTルーターに構成された一般的なルーティングカプセル化（GRE）トンネルがあり、BGPを使用して、LISP-ALTデータベースのさまざまなプレフィックスのETRへのパスを学習します。Map-Resolverはこのパス情報を使用して、ALTを介したMap-Requestsを正しいETRに転送します。LISP-DDTネットワーク[RFC8111]では、MAP-Resolverは紹介キャッシュを維持し、「ファーストホップ」DDTノードとして機能します。Map-Resolverは、紹介情報を使用して、Map-Requestsを転送します。
Note that while it is conceivable that a Map-Resolver could cache responses to improve performance, issues surrounding cache management would need to be resolved so that doing so would be reliable and practical. In this specification, Map-Resolvers will operate only in a non-caching mode, decapsulating and forwarding Encapsulated Map-Requests received from ITRs. Any specification of caching functionality is out of scope for this document.
マップ分解者がパフォーマンスを改善するために応答をキャッシュすることができると考えられますが、キャッシュ管理を取り巻く問題は、そうすることが信頼できる実用的であるために解決する必要があります。この仕様では、MAP-Resolversは非キャッシングモードでのみ動作し、ITRから受信したカプセル化されたマップ再クエストを脱カプセル化し、転送します。キャッシュ機能の仕様は、このドキュメントの範囲外です。
Note that a single device can implement the functions of both a Map-Server and a Map-Resolver, and in many cases, the functions will be co-located in that way. Also, there can be ALT-only nodes and DDT-only nodes, when LISP-ALT and LISP-DDT are used, respectively, connecting Map-Resolvers and Map-Servers together to make up the Mapping System.
単一のデバイスは、Map-ServerとMap-Resolverの両方の機能を実装できることに注意してください。多くの場合、機能はその方法で共同で共同で開催されることに注意してください。また、LISP-ALTとLISP-DDTがそれぞれ使用されている場合、MAP-ResolversとMap-Serversを一緒に接続してマッピングシステムを構成する場合、AltのみのノードとDDTのみのノードがあります。
The following UDP packet formats are used by the LISP control plane.
次のUDPパケット形式は、LISPコントロールプレーンで使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol = 17 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Routing Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Routing Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port | Dest Port |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| LISP Message |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPv4 UDP LISP Control Message
図1：IPv4 UDP LISPコントロールメッセージ
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header=17| Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Routing Locator +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Routing Locator +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port | Dest Port |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| LISP Message |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IPv6 UDP LISP Control Message
図2：IPv6 UDP LISPコントロールメッセージ
When a UDP Map-Request, Map-Register, or Map-Notify (when used as a notification message) is sent, the UDP source port is chosen by the sender and the destination UDP port number is set to 4342. When a UDP Map-Reply, Map-Notify (when used as an acknowledgment to a Map-Register), or Map-Notify-Ack is sent, the source UDP port number is set to 4342 and the destination UDP port number is copied from the source port of either the Map-Request or the invoking data packet. Implementations MUST be prepared to accept packets when either the source port or destination UDP port is set to 4342 due to NATs changing port number values.
UDP Map-Request、Map-Register、またはMap-Notify（通知メッセージとして使用される場合）が送信されると、UDPソースポートが送信者によって選択され、宛先UDPポート番号は4342に設定されます。-reply、map-notify（map-registerへの謝辞として使用される場合）またはmap-notify-ackが送信されると、ソースUDPポート番号は4342に設定され、宛先UDPポート番号はソースポートからコピーされますMap-RequestまたはInving Data Packetのいずれか。NATがポート番号の値を変更するため、ソースポートまたは宛先UDPポートが4342に設定されている場合、パケットを受け入れるために実装を準備する必要があります。
The 'UDP Length' field will reflect the length of the UDP header and the LISP Message payload. LISP is expected to be deployed by cooperating entities communicating over underlays. Deployers are expected to set the MTU according to the specific deployment guidelines to prevent fragmentation of either the inner packet or the outer encapsulated packet. For deployments not aware of the underlay restrictions on the path MTU, the message size MUST be limited to 576 bytes for IPv4 or 1280 bytes for IPv6 -- considering the entire IP packet -- as outlined in [RFC8085].
「UDPの長さ」フィールドは、UDPヘッダーの長さとLISPメッセージペイロードを反映します。LISPは、アンダーレイで通信する協力エンティティによって展開されることが期待されています。展開者は、特定の展開ガイドラインに従ってMTUを設定して、内側のパケットまたは外側のカプセル化されたパケットのいずれかの断片化を防ぐことが期待されています。パスMTUのアンダーレイ制限を展開しない場合、[RFC8085]で概説されているように、メッセージサイズはIPv4の場合は576バイトまたはIPv6の1280バイト（IPパケット全体を考慮して）に制限する必要があります。
The UDP checksum is computed and set to non-zero for all messages sent to or from port 4342. It MUST be checked on receipt, and if the checksum fails, the control message MUST be dropped [RFC1071].
UDPチェックサムは計算され、ポート4342から送信されたすべてのメッセージに対して非ゼロに設定されます。受信時にチェックする必要があり、チェックサムが失敗した場合、コントロールメッセージをドロップする必要があります[RFC1071]。
The format of control messages includes the UDP header so the checksum and length fields can be used to protect and delimit message boundaries.
コントロールメッセージの形式にはUDPヘッダーが含まれるため、チェックサムと長さのフィールドを使用してメッセージの境界を保護および区切ることができます。
This section defines the LISP control message formats and summarizes for IANA the LISP Type codes assigned by this document. For completeness, the summary below includes the LISP Shared Extension Message assigned by [RFC9304]. Message type definitions are:
このセクションでは、LISPコントロールメッセージフォーマットを定義し、このドキュメントで割り当てられたLISPタイプコードをIANAに要約します。完全性については、以下の要約には、[RFC9304]によって割り当てられたLISP共有拡張メッセージが含まれています。メッセージタイプの定義は次のとおりです。
+===================================+======+==================+
| Message | Code | Codepoint |
+===================================+======+==================+
| Reserved | 0 | b'0000' |
+-----------------------------------+------+------------------+
| LISP Map-Request | 1 | b'0001' |
+-----------------------------------+------+------------------+
| LISP Map-Reply | 2 | b'0010' |
+-----------------------------------+------+------------------+
| LISP Map-Register | 3 | b'0011' |
+-----------------------------------+------+------------------+
| LISP Map-Notify | 4 | b'0100' |
+-----------------------------------+------+------------------+
| LISP Map-Notify-Ack | 5 | b'0101' |
+-----------------------------------+------+------------------+
| LISP DDT Map-Referral | 6 | b'0110' |
+-----------------------------------+------+------------------+
| Unassigned | 7 | b'0111' |
+-----------------------------------+------+------------------+
| LISP Encapsulated Control Message | 8 | b'1000' |
+-----------------------------------+------+------------------+
| Unassigned | 9-14 | b'1001'- b'1110' |
+-----------------------------------+------+------------------+
| LISP Shared Extension Message | 15 | b'1111' |
+-----------------------------------+------+------------------+
Table 1
表1
Protocol designers experimenting with new message formats are recommended to use the LISP Shared Extension Message Type described in [RFC9304].
[RFC9304]で説明されているLISP共有拡張メッセージタイプを使用するには、新しいメッセージ形式を実験するプロトコル設計者が推奨されます。
All LISP control plane messages use Address Family Identifiers (AFIs) [AFN] or LISP Canonical Address Format (LCAF) entries [RFC8060] to encode either fixed-length or variable-length addresses. This includes explicit fields in each control message or part of EID-Records or RLOC-Records in commonly formatted messages. LISP control plane messages that include an unrecognized AFI MUST be dropped, and the event MUST be logged.
すべてのLISPコントロールプレーンメッセージは、アドレスファミリ識別子（AFIS）[AFN]またはLISP Canonicalアドレス形式（LCAF）エントリ[RFC8060]を使用して、固定長または可変長アドレスのいずれかをエンコードします。これには、各コントロールメッセージの明示的なフィールドまたは一般的にフォーマットされたメッセージのeid-recordsまたはrloc-recordの一部が含まれます。認識されていないAFIを含むLISPコントロールプレーンメッセージを削除する必要があり、イベントを記録する必要があります。
The LISP control plane describes how other data planes can encode messages to support the soliciting of Map-Requests as well as RLOC-Probing procedures.
LISPコントロールプレーンは、他のデータプレーンがメッセージをエンコードして、RLOCプロビング手順と同様にマップリケストの勧誘をサポートする方法を説明しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 |A|M|P|S|p|s|R|R| Rsvd |L|D| IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-EID-AFI | Source EID Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI n | ITR-RLOC Address n ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Reserved | EID mask-len | EID-Prefix-AFI |
Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | EID-Prefix ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Map-Reply Record ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions:
パケットフィールドの説明：
Type: 1 (Map-Request)
タイプ：1（Map-Request）
A: This is an authoritative bit. It is set to 1 when an ITR wants the destination site to return the Map-Reply rather than the mapping database system returning a Map-Reply and is set to 0 otherwise.
A：これは権威あるビットです。ITRがマッピングデータベースシステムがマップ応答を返し、それ以外の場合は0に設定されているのではなく、宛先サイトがマップレプリーを返すことを望んでいる場合に1に設定されます。
M: This is the map-data-present bit. When set, it indicates that a Map-Reply Record segment is included in the Map-Request.
M：これはMap-Data-Present Bitです。設定すると、Map-Reply Recordセグメントがマップレクエストに含まれていることを示します。
P: This is the probe-bit, which indicates that a Map-Request MUST be treated as a Locator reachability probe. The receiver MUST respond with a Map-Reply with the probe-bit set, indicating that the Map-Reply is a Locator reachability probe reply, with the nonce copied from the Map-Request. See "RLOC-Probing Algorithm" (Section 7.1) for more details. This RLOC-Probe Map-Request MUST NOT be sent to the Mapping System. If a Map-Resolver or Map-Server receives a Map-Request with the probe-bit set, it MUST drop the message.
P：これはプローブビットです。これは、マップリケストがロケーターリーチビリティプローブとして扱わなければならないことを示しています。受信者は、プローブビットセットでマップ応答で応答する必要があります。これは、マップリプリーがロケーターリーチビリティプローブの応答であり、NonCeがMap-Requestからコピーされていることを示しています。詳細については、「rloc-probingアルゴリズム」（セクション7.1）を参照してください。このRLOC-Probe Map-Requestをマッピングシステムに送信してはなりません。Map-ResolverまたはMap-Serverがプローブビットセットを使用してMap-Requestを受信した場合、メッセージをドロップする必要があります。
S: This is the Solicit-Map-Request (SMR) bit. See "Solicit-Map-Request (SMR)" (Section 6.1) for details.
S：これはSolict-Map-Request（SMR）ビットです。詳細については、「Solicit-Map-Request（SMR）」（セクション6.1）を参照してください。
p: This is the Proxy Ingress Tunnel Router (PITR) bit. This bit is set to 1 when a PITR sends a Map-Request. The use of this bit is deployment specific.
P：これは、プロキシイングレストンネルルーター（PITR）ビットです。このビットは、PITRがマップレクエストを送信するときに1に設定されます。このビットの使用は展開固有です。
s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is sending a Map-Request in response to a received SMR-based Map-Request.
S：これはSMRに投票されたビットです。このビットは、XTRが受信したSMRベースのMAP-Requestに応じてMap-Requestを送信している場合に1に設定されます。
R: This reserved and unassigned bit MUST be set to 0 on transmit and MUST be ignored on receipt.
R：この予約済みのビットと未割り当てビットは、送信時に0に設定する必要があり、受信時に無視する必要があります。
Rsvd: This field MUST be set to 0 on transmit and MUST be ignored on receipt.
RSVD：このフィールドは送信時に0に設定する必要があり、受領時に無視する必要があります。
L: This is the local-xtr bit. It is used by an xTR in a LISP site to tell other xTRs in the same site that it is part of the RLOC-Set for the LISP site. The L-bit is set to 1 when the RLOC is the sender's IP address.
L：これはローカルXTRビットです。LISPサイトのXTRによって使用され、同じサイトの他のXTRにLISPサイトのRLOC-SETの一部であることを伝えます。rlocが送信者のIPアドレスである場合、Lビットは1に設定されます。
D: This is the dont-map-reply bit. It is used in the SMR procedure described in Section 6.1. When an xTR sends an SMR message, it doesn't need a Map-Reply returned. When this bit is set, the receiver of the Map-Request does not return a Map-Reply.
D：これはDont-Map-Replyビットです。セクション6.1で説明したSMR手順で使用されます。XTRがSMRメッセージを送信するとき、マップ返品を返す必要はありません。このビットが設定されている場合、Map-Requestの受信機はマップ返済を返さない。
IRC: This 5-bit field is the ITR-RLOC Count, which encodes the additional number of ('ITR-RLOC-AFI', 'ITR-RLOC Address') fields present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC Address) pair MUST be encoded. Multiple 'ITR-RLOC Address' fields are used, so a Map-Replier can select which destination address to use for a Map-Reply. The IRC value ranges from 0 to 31. For a value of 0, there is 1 ITR-RLOC address encoded; for a value of 1, there are 2 ITR-RLOC addresses encoded, and so on up to 31, which encodes a total of 32 ITR-RLOC addresses.
IRC：この5ビットフィールドは、このメッセージに存在する追加の（ 'itr-rloc-afi'、 'itr-rlocアドレス'）フィールドをコードするITR-rlocカウントです。少なくとも1つの（ITR-RLOC-AFI、ITR-RLOCアドレス）ペアをエンコードする必要があります。複数の「ITR-RLOCアドレス」フィールドが使用されているため、マップレプライヤーは、マップ応答に使用する宛先アドレスを選択できます。IRC値の範囲は0から31の範囲です。値は0の場合、1つのITR-RLOCアドレスがエンコードされています。1の値の場合、エンコードされた2つのITR-RLOCアドレスがあります。
Record Count: This is the number of records in this Map-Request message. A record is comprised of the portion of the packet that is labeled 'Rec' above and occurs the number of times equal to Record Count. For this version of the protocol, a receiver MUST accept and process Map-Requests that contain one or more records, but a sender MUST only send Map-Requests containing one record.
レコードカウント：これは、このマップレクエストメッセージのレコードの数です。レコードは、上記の「rec」とラベル付けされ、レコードカウントに等しい回数が発生するパケットの部分で構成されています。このバージョンのプロトコルの場合、受信者は1つ以上のレコードを含むマップリクエストを受け入れて処理する必要がありますが、送信者は1つのレコードを含むマップリケストのみを送信する必要があります。
Nonce: This is an 8-octet random value created by the sender of the Map-Request. This nonce will be returned in the Map-Reply. The nonce is used as an index to identify the corresponding Map-Request when a Map-Reply message is received. The nonce MUST be generated by a properly seeded pseudo-random source; for example, see [RFC4086].
NONCE：これは、Map-Requestの送信者によって作成された8オクテットのランダム値です。このノンセは、マップ繰り返しで返されます。NONCEは、マップリプのメッセージが受信されたときに、対応するマップリケストを識別するためのインデックスとして使用されます。非CEは、適切に種まきの擬似ランダム源によって生成されなければなりません。たとえば、[RFC4086]を参照してください。
Source-EID-AFI: This is the address family of the 'Source EID Address' field.
Source-EID-AFI：これは、「ソースEIDアドレス」フィールドの住所ファミリです。
Source EID Address: This is the EID of the source host that originated the packet that caused the Map-Request. When Map-Requests are used for refreshing a Map-Cache entry or for RLOC-Probing, an AFI value of 0 is used, and this field is of zero length.
ソースEIDアドレス：これは、マップレクエストを引き起こしたパケットを発信したソースホストのEIDです。マップキャッシュエントリの更新またはRLOCプロビングのためにマップリケストが使用される場合、AFI値は0で使用され、このフィールドは長さがゼロです。
ITR-RLOC-AFI: This is the address family of the 'ITR-RLOC Address' field that follows this field.
ITR-RLOC-AFI：これは、このフィールドに続く「ITR-RLOCアドレス」フィールドのアドレスファミリです。
ITR-RLOC Address: This is used to give the ETR the option of selecting the destination address from any address family for the Map-Reply message. This address MUST be a routable RLOC address of the sender of the Map-Request message.
ITR-RLOCアドレス：これは、ETRに、マップ対応メッセージのアドレスファミリから宛先アドレスを選択するオプションを提供するために使用されます。このアドレスは、Map-Requestメッセージの送信者のルーティング可能なRLOCアドレスでなければなりません。
EID mask-len: This is the mask length for the EID-Prefix.
Eid Mask-Len：これはEid-Prefixのマスク長です。
EID-Prefix-AFI: This is the address family of the EID-Prefix according to [AFN] and [RFC8060].
Eid-Prefix-Afi：これは、[AFN]および[RFC8060]によると、Eid-Prefixのアドレスファミリーです。
EID-Prefix: This prefix address length is 4 octets for an IPv4 address family and 16 octets for an IPv6 address family when the EID-Prefix-AFI is 1 or 2, respectively. For other AFIs [AFN], the address length varies, and for the LCAF AFI, the format is defined in [RFC8060]. When a Map-Request is sent by an ITR because a data packet is received for a destination where there is no mapping entry, the EID-Prefix is set to the destination IP address of the data packet, and the 'EID mask-len' field is set to 32 or 128 for IPv4 or IPv6, respectively. When an xTR wants to query a site about the status of a mapping it already has cached, the EID-Prefix used in the Map-Request has the same mask length as the EID-Prefix returned from the site when it sent a Map-Reply message.
EID-PREFIX：このプレフィックスアドレスの長さは、IPv4アドレスファミリの場合は4オクテット、IPv6アドレスファミリーの場合は16オクテットです。他のAFI [AFN]の場合、アドレスの長さは異なり、LCAF AFIの場合、形式は[RFC8060]で定義されています。マッピングエントリがない宛先のデータパケットが受信されるため、ITRによってマップリケストが送信されると、eid-prefixはデータパケットの宛先IPアドレスに設定され、「eid mask-len」が設定されます。フィールドは、それぞれIPv4またはIPv6で32または128に設定されています。XTRがマッピングのステータスに関するサイトを既にキャッシュしているサイトをクエリしたい場合、Map-Requestで使用されているEid-Prefixは、Map-Replyを送信したときにサイトから返されたEid-Prefixがサイトから返されたのと同じマスクの長さを持っています。メッセージ。
Map-Reply Record: When the M-bit is set, this field is the size of a single "Record" in the Map-Reply format. This Map-Reply record contains the EID-to-RLOC mapping entry associated with the source EID. This allows the ETR that will receive this Map-Request to cache the data if it chooses to do so. It is important to note that this mapping has not been validated by the Mapping System.
Map-Reply Record：M-Bitが設定されている場合、このフィールドは、マップReply形式の単一の「レコード」のサイズです。このマップReplyレコードには、Source Eidに関連付けられたEid-to-RLOCマッピングエントリが含まれています。これにより、このMap-Requestを受け取るETRが、そうすることを選択した場合にデータをキャッシュすることができます。このマッピングはマッピングシステムによって検証されていないことに注意することが重要です。
A Map-Request is sent from an ITR when it needs a mapping for an EID, wants to test an RLOC for reachability, or wants to refresh a mapping before Time to Live (TTL) expiration. For the initial case, the destination IP address used for the Map-Request is the data packet's destination address (i.e., the destination EID) that had a mapping cache lookup failure. For the latter two cases, the destination IP address used for the Map-Request is one of the RLOC addresses from the Locator-Set of the Map-Cache entry. The source address is either an IPv4 or IPv6 RLOC address, depending on whether the Map-Request is using an IPv4 or IPv6 header, respectively. In all cases, the UDP source port number for the Map-Request message is a 16-bit value selected by the ITR/PITR, and the UDP destination port number is set to the well-known destination port number 4342. A successful Map-Reply, which is one that has a nonce that matches an outstanding Map-Request nonce, will update the cached set of RLOCs associated with the EID-Prefix range.
EIDのマッピングが必要な場合、ITRからMAP-REQUESTが送信され、RLOCの到達可能性のテスト、またはライブ（TTL）の有効期限の前にマッピングを更新したい場合があります。最初のケースでは、マップレクエストに使用される宛先IPアドレスは、マッピングキャッシュルックアップ障害があるデータパケットの宛先アドレス（つまり、宛先EID）です。後者の2つのケースの場合、Map-Requestに使用される宛先IPアドレスは、Map-CacheエントリのロケーターセットからのRLOCアドレスの1つです。ソースアドレスは、MAP-RequestがそれぞれIPv4ヘッダーを使用しているかIPv6ヘッダーを使用しているかによって、IPv4またはIPv6 RLOCアドレスのいずれかです。すべての場合において、Map-RequestメッセージのUDPソースポート番号は、ITR/PITRによって選択された16ビット値であり、UDP宛先ポート番号は、よく知られている宛先ポート番号4342に設定されています。返信は、未解決のMap-Request NonCeと一致するNonCEを持つもので、EID-Prefix範囲に関連付けられたRLOCのキャッシュセットを更新します。
One or more Map-Request ('ITR-RLOC-AFI', 'ITR-RLOC Address') fields MUST be filled in by the ITR. The number of fields (minus 1) encoded MUST be placed in the 'IRC' field. The ITR MAY include all locally configured Locators in this list or just provide one Routing Locator Address from each address family it supports. If the ITR erroneously provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map-Request.
1つ以上のMap-Request（ 'itr-rloc-afi'、 'itr-rlocアドレス'）フィールドは、ITRによって記入する必要があります。エンコードされたフィールドの数（マイナス1）は、「IRC」フィールドに配置する必要があります。ITRには、このリストにローカルで構成されたすべてのロケーターを含めるか、サポートする各アドレスファミリから1つのルーティングロケーターアドレスを提供する場合があります。ITRが誤ってITR-RLOCアドレスを提供しない場合、MAP-Replierはマップレクエストをドロップする必要があります。
Map-Requests can also be LISP encapsulated using UDP destination port 4342 with a LISP Type value set to "Encapsulated Control Message", when sent from an ITR to a Map-Resolver. Likewise, Map-Requests are LISP encapsulated the same way from a Map-Server to an ETR. Details on Encapsulated Map-Requests and Map-Resolvers can be found in Section 5.8.
MAP-Requestは、ITRからMap-Resolverに送信された場合、「カプセル化されたコントロールメッセージ」に設定されたLISPタイプの値を使用して、UDP宛先ポート4342を使用してLISPをカプセル化することもできます。同様に、Map-Requestsは、Map-ServerからETRまで同じ方法でLISPカプセル化されています。カプセル化されたマップリケストとマップリゾルバーの詳細は、セクション5.8にあります。
Map-Requests MUST be rate limited to 1 per second per EID-Prefix. After 10 retransmits without receiving the corresponding Map-Reply, the sender MUST wait 30 seconds.
マップ再クエストは、eid-prefixあたり1秒あたり1秒に制限されている必要があります。対応するマップリプリーを受け取らずに10回再送信した後、送信者は30秒待つ必要があります。
An ITR that is configured with mapping database information (i.e., it is also an ETR) MAY optionally include those mappings in a Map-Request. When an ETR configured to accept and verify such "piggybacked" mapping data receives such a Map-Request and it does not have this mapping in the Map-Cache, it MUST originate a "verifying Map-Request" through the mapping database to validate the "piggybacked" mapping data.
マッピングデータベース情報で構成されているITR（つまり、ETRでもあります）は、オプションでマップレクエストにそれらのマッピングを含めることができます。このような「ピギーバック」マッピングデータを受け入れて検証するように構成されたETRがこのようなマップリクエストを受信し、マップキャッシュにこのマッピングがない場合、マッピングデータベースを介して「マップリケストの検証」を発信して、検証する必要があります。「ピギーバック」マッピングデータ。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=2 |P|E|S| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Rsvd | Map-Version Number | EID-Prefix-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-Prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions:
パケットフィールドの説明：
Type: 2 (Map-Reply)
タイプ：2（マップ繰り返し）
P: This is the probe-bit, which indicates that the Map-Reply is in response to a Locator reachability probe Map-Request. The 'Nonce' field must contain a copy of the nonce value from the original Map-Request. See "RLOC-Probing Algorithm" (Section 7.1) for more details. When the probe-bit is set to 1 in a Map-Reply message, the A-bit in each EID-Record included in the message MUST be set to 1; otherwise, it MUST be silently discarded.
P：これはプローブビットです。これは、MAP-ReplyがロケーターReachability Probe Probe Map-Requestに応じていることを示しています。「NonCe」フィールドには、元のMap-RequestからのNonCe値のコピーを含める必要があります。詳細については、「rloc-probingアルゴリズム」（セクション7.1）を参照してください。プローブビットがマップレプリーメッセージで1に設定されている場合、メッセージに含まれる各EID記録のAビットは1に設定する必要があります。それ以外の場合は、静かに廃棄する必要があります。
E: This bit indicates that the ETR that sends this Map-Reply message is advertising that the site is enabled for the Echo-Nonce Locator reachability algorithm. See Section 10.1 ("Echo-Nonce Algorithm") of [RFC9300] for more details.
E：このビットは、このマップReplyメッセージを送信するETRが、Echo-Nonce Locator Reachabilityアルゴリズムに対してサイトが有効になっていることを宣伝していることを示しています。詳細については、[RFC9300]のセクション10.1（ "Echo-Nonce Algorithm"）を参照してください。
S: This is the Security bit. When set to 1, the following authentication information will be appended to the end of the Map-Reply. Details can be found in [RFC9303].
S：これはセキュリティビットです。1に設定すると、次の認証情報がマップ応答の最後まで追加されます。詳細は[RFC9303]にあります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD Type | Authentication Data Content . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: This unassigned field MUST be set to 0 on transmit and MUST be ignored on receipt.
予約済み：この割り当てされていないフィールドは、送信時に0に設定する必要があり、受信時に無視する必要があります。
Record Count: This is the number of records in this reply message. A record is comprised of that portion of the packet labeled 'Record' above and occurs the number of times equal to Record Count. Note that the reply count can be larger than the requested count, for instance, when more-specific prefixes are present.
レコードカウント：これは、この返信メッセージのレコードの数です。レコードは、上記の「レコード」とラベル付けされたパケットのその部分で構成され、レコードカウントに等しい回数が発生します。応答カウントは、より固有のプレフィックスが存在する場合、要求されたカウントよりも大きくなる可能性があることに注意してください。
Nonce: This 64-bit value from the Map-Request is echoed in this 'Nonce' field of the Map-Reply.
Nonce：Map-Requestからのこの64ビット値は、MAP Replyのこの「ノンセ」フィールドに反映されています。
Record TTL: This is the time in minutes the recipient of the Map-Reply can store the mapping. If the TTL is 0, the entry MUST be removed from the cache immediately. If the value is 0xffffffff, the recipient can decide locally how long to store the mapping.
レコードTTL：これは、マップReplyの受信者がマッピングを保存できる数分での時間です。TTLが0の場合、エントリはすぐにキャッシュから削除する必要があります。値が0xffffffffの場合、受信者はマッピングを保存する時間をローカルで決定できます。
Locator Count: This is the number of Locator entries in the given Record. A Locator entry comprises what is labeled above as 'Loc'. The Locator count can be 0, indicating that there are no Locators for the EID-Prefix.
ロケーターカウント：これは、指定されたレコードのロケーターエントリの数です。ロケーターエントリは、上記の「loc」とラベル付けされているもので構成されています。ロケーター数は0である可能性があり、Eid-Prefixのロケーターがないことを示しています。
EID mask-len: This is the mask length for the EID-Prefix.
Eid Mask-Len：これはEid-Prefixのマスク長です。
ACT: This 3-bit field describes Negative Map-Reply actions. In any other message type, these bits are set to 0 and ignored on receipt. These bits are used only when the 'Locator Count' field is set to 0. The action bits are encoded only in Map-Reply messages. They are used to tell an ITR or PITR why an empty Locator-Set was returned from the Mapping System and how it stores the Map-Cache entry. See Section 12.3 for additional information.
ACT：この3ビットフィールドは、否定的なマップ繰り返しアクションを説明しています。他のメッセージタイプでは、これらのビットは0に設定され、受領時に無視されます。これらのビットは、「ロケーターカウント」フィールドが0に設定されている場合にのみ使用されます。アクションビットは、マップ応答メッセージでのみエンコードされます。これらは、ITRまたはPITRに、空のロケーターセットがマッピングシステムから返された理由と、マップキャッシュエントリをどのように保存するかを伝えるために使用されます。詳細については、セクション12.3を参照してください。
(0) No-Action: The Map-Cache is kept alive, and no packet encapsulation occurs.
(0) アクションなし：マップキャッシュは生存され、パケットカプセル化は発生しません。
(1) Natively-Forward: The packet is not encapsulated or dropped but natively forwarded.
(1) ネイティブに：パケットはカプセル化またはドロップされていませんが、ネイティブに転送されます。
(2) Send-Map-Request: The Map-Cache entry is created and flagged so that any packet matching this entry invokes sending a Map-Request.
(2) Send-Map-Request：マップキャッシュエントリが作成され、フラグが付けられているため、このエントリに一致するパケットがマップリクエストの送信を呼び出します。
(3) Drop/No-Reason: A packet that matches this Map-Cache entry is dropped. An ICMP Destination Unreachable message SHOULD be sent.
(3) ドロップ/ノーリーズン：このマップキャッシュエントリに一致するパケットが削除されます。ICMP宛先の到達不可能なメッセージを送信する必要があります。
(4) Drop/Policy-Denied: A packet that matches this Map-Cache entry is dropped. The reason for the Drop action is that a Map-Request for the target EID is being policy-denied by either an xTR or the Mapping System.
(4) Drop/Policy-Denied：このマップキャッシュエントリに一致するパケットが削除されます。ドロップアクションの理由は、ターゲットEIDのマップ要求がXTRまたはマッピングシステムによってポリシー依存されているためです。
(5) Drop/Auth-Failure: A packet that matches this Map-Cache entry is dropped. The reason for the Drop action is that a Map-Request for the target EID fails an authentication verification check by either an xTR or the Mapping System.
(5) ドロップ/認証：このマップキャッシュエントリに一致するパケットが削除されます。ドロップアクションの理由は、ターゲットEIDのMAP-RequestがXTRまたはマッピングシステムのいずれかによる認証確認チェックに失敗したためです。
A: The Authoritative bit MAY only be set to 1 by an ETR. A Map-Server generating Map-Reply messages as a proxy MUST NOT set the A-bit to 1. This bit indicates to the requesting ITRs if the Map-Reply was originated by a LISP node managed at the site that owns the EID-Prefix.
A：権威あるビットは、ETRによってのみ1に設定できます。プロキシとしてのマップサーバー生成マップ繰り返しメッセージは、Aビットを1に設定してはなりません。。
Map-Version Number: When this 12-bit value in an EID-Record of a Map-Reply message is non-zero, see [RFC9302] for details.
マップバージョン番号：Map-ReplyメッセージのEid-Recordにあるこの12ビット値がゼロではない場合は、詳細については[RFC9302]を参照してください。
EID-Prefix-AFI: This is the address family of the EID-Prefix according to [AFN] and [RFC8060].
Eid-Prefix-Afi：これは、[AFN]および[RFC8060]によると、Eid-Prefixのアドレスファミリーです。
EID-Prefix: This prefix is 4 octets for an IPv4 address family and 16 octets for an IPv6 address family.
Eid-Prefix：このプレフィックスは、IPv4アドレスファミリの場合は4オクテット、IPv6アドレスファミリでは16オクテットです。
Priority: Each RLOC is assigned a unicast Priority. Lower values are preferable. When multiple RLOCs have the same Priority, they may be used in a load-split fashion. A value of 255 means the RLOC MUST NOT be used for unicast forwarding.
優先度：各RLOCにはユニキャストの優先度が割り当てられます。低い値が望ましいです。複数のRLOCが同じ優先順位を持っている場合、それらは負荷分散方法で使用される場合があります。255の値は、RLOCをユニキャスト転送に使用してはならないことを意味します。
Weight: When priorities are the same for multiple RLOCs, the Weight indicates how to balance unicast traffic between them. Weight is encoded as a relative weight of total unicast packets that match the mapping entry. For example, if there are 4 Locators in a Locator-Set, where the Weights assigned are 30, 20, 20, and 10, the first Locator will get 37.5% of the traffic, the second and third Locators will each get 25% of the traffic, and the fourth Locator will get 12.5% of the traffic. If all Weights for a Locator-Set are equal, the receiver of the Map-Reply will decide how to load-split the traffic. See Section 12 ("Routing Locator Hashing") of [RFC9300] for a suggested hash algorithm to distribute the load across Locators with the same Priority and equal Weight values.
重量：複数のRLOCで優先順位が同じ場合、重量はそれらの間のユニキャストトラフィックのバランスをとる方法を示します。重量は、マッピングエントリに一致するユニキャストパケットの総重量としてエンコードされます。たとえば、ロケーターセットに4つのロケーターがあり、割り当てられた重みが30、20、20、および10の場合、最初のロケーターはトラフィックの37.5％を取得します。トラフィックと4番目のロケーターは、トラフィックの12.5％を取得します。ロケーターセットのすべての重みが等しい場合、マップ繰り返しの受信者はトラフィックをロードする方法を決定します。推奨されるハッシュアルゴリズムについては、[RFC9300]のセクション12（ "ルーティングロケーターハッシュ"）を参照してください。
M Priority: Each RLOC is assigned a multicast Priority used by an ETR in a receiver multicast site to select an ITR in a source multicast site for building multicast distribution trees. A value of 255 means the RLOC MUST NOT be used for joining a multicast distribution tree. For more details, see [RFC6831].
M優先順位：各RLOCには、レシーバーマルチキャストサイトのETRが使用するマルチキャストの優先度が割り当てられ、マルチキャスト配布ツリーを構築するためのソースマルチキャストサイトでITRを選択します。255の値は、RLOCをマルチキャスト分布ツリーの結合に使用してはならないことを意味します。詳細については、[RFC6831]を参照してください。
M Weight: When priorities are the same for multiple RLOCs, the Weight indicates how to balance building multicast distribution trees across multiple ITRs. The Weight is encoded as a relative weight (similar to the unicast Weights) of the total number of trees built to the source site identified by the EID-Prefix. If all Weights for a Locator-Set are equal, the receiver of the Map-Reply will decide how to distribute multicast state across ITRs. For more details, see [RFC6831].
M重量：複数のRLOCで優先順位が同じ場合、重量は複数のITRにわたって建物のマルチキャスト分布ツリーのバランスをとる方法を示します。重量は、EID-Prefixによって識別されたソースサイトに構築されたツリーの総数の相対重量（ユニキャスト重量と同様）としてエンコードされます。ロケーターセットのすべての重みが等しい場合、MAP Replyの受信機は、ITR全体にマルチキャスト状態を配布する方法を決定します。詳細については、[RFC6831]を参照してください。
Unused Flags: These are set to 0 when sending and ignored on receipt.
未使用のフラグ：これらは、受信時に送信時に0に設定されます。
L: When this bit is set, the Locator is flagged as a local Locator to the ETR that is sending the Map-Reply. When a Map-Server is doing proxy Map-Replying for a LISP site, the L-bit is set to 0 for all Locators in this Locator-Set.
L：このビットが設定されると、ロケーターは、MAP REPLYを送信しているETRのローカルロケーターとしてフラグを立てられます。マップサーバーがLISPサイトでプロキシマップを繰り返している場合、このロケーターセットのすべてのロケーターに対してLビットは0に設定されます。
p: When this bit is set, an ETR informs the RLOC-Probing ITR that the Routing Locator Address for which this bit is set is the one being RLOC-Probed and may be different from the source address of the Map-Reply. An ITR that RLOC-Probes a particular Locator MUST use this Locator for retrieving the data structure used to store the fact that the Locator is reachable. The p-bit is set for a single Locator in the same Locator-Set. If an implementation sets more than one p-bit erroneously, the receiver of the Map-Reply MUST select the first set p-bit Locator. The p-bit MUST NOT be set for Locator-Set records sent in Map-Request and Map-Register messages.
P：このビットが設定されている場合、ETRはRLOCプロビングITRに、このビットが設定されているルーティングロケーターアドレスがRLOCプロビングであり、MAP REPLYのソースアドレスとは異なる場合があることを通知します。特定のロケーターをRLOCポーチにするITRは、このロケーターを使用して、ロケーターに到達可能であるという事実を保存するために使用されるデータ構造を取得する必要があります。Pビットは、同じロケーターセットの単一のロケーターに設定されています。実装が複数のPビットを誤って設定する場合、MAP Replyの受信者は最初のセットPビットロケーターを選択する必要があります。Pビットは、Map-RequestおよびMap-Registerメッセージで送信されたロケーターセットレコードに設定してはなりません。
R: This is set when the sender of a Map-Reply has a route to the Locator in the Locator data record. This receiver may find this useful to know if the Locator is up but not necessarily reachable from the receiver's point of view.
R：これは、マップReplyの送信者がロケーターデータレコードのロケーターへのルートを持っているときに設定されます。このレシーバーは、ロケーターが起きているかどうかを知るのに役立つかもしれませんが、レシーバーの観点から必ずしも到達可能ではありません。
Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) assigned to an ETR and used by an ITR as a destination RLOC address in the outer header of a LISP encapsulated packet. Note that the destination RLOC address of a LISP encapsulated packet MAY be an anycast address. A source RLOC of a LISP encapsulated packet can be an anycast address as well. The source or destination RLOC MUST NOT be the broadcast address (255.255.255.255 or any subnet broadcast address known to the router) and MUST NOT be a link-local multicast address. The source RLOC MUST NOT be a multicast address. The destination RLOC SHOULD be a multicast address if it is being mapped from a multicast destination EID.
ロケーター：これは、ETRに割り当てられ、LISPカプセル化されたパケットの外側ヘッダーの宛先RLOCアドレスとしてITRによって使用されたIPv4またはIPv6アドレス（「loc-afi」フィールドによってエンコードされる）です。LISPカプセル化されたパケットの宛先RLOCアドレスは、Anycastアドレスである可能性があることに注意してください。LISPカプセル化されたパケットのソースRLOCは、AnyCastアドレスでもあります。ソースまたは宛先RLOCは、放送アドレス（255.255.255.255またはルーターに知られているサブネットブロードキャストアドレス）であってはなりません。また、リンクローカルマルチキャストアドレスであってはなりません。ソースRLOCはマルチキャストアドレスであってはなりません。宛先RLOCは、マルチキャストの宛先EIDからマッピングされている場合は、マルチキャストアドレスである必要があります。
Map-Replies MUST be rate limited. It is RECOMMENDED that a Map-Reply for the same destination RLOC be sent to no more than one packet every 3 seconds.
マップレプリーはレート制限されている必要があります。同じ宛先RLOCのマップ応答を3秒ごとに1パケット以下に送信することをお勧めします。
The Record format, as defined here, is used both in the Map-Reply and Map-Register messages; this includes all the field definitions.
ここで定義されているレコード形式は、Map-ReplyとMap-Registerメッセージの両方で使用されます。これには、すべてのフィールド定義が含まれます。
A Map-Reply returns an EID-Prefix with a mask length that is less than or equal to the EID being requested. The EID being requested is either from the destination field of an IP header of a Data-Probe or the EID of a record of a Map-Request. The RLOCs in the Map-Reply are routable IP addresses of all ETRs for the LISP site. Each RLOC conveys status reachability but does not convey path reachability from a requester's perspective. Separate testing of path reachability is required. See "RLOC-Probing Algorithm" (Section 7.1) for details.
MAP-REPLYは、要求されているEID以下のマスク長でEid-Prefixを返します。要求されているEIDは、データプローブのIPヘッダーの宛先フィールドまたはMap-Requestの記録のEidからのものです。MAP-ReplyのRLOCは、LISPサイトのすべてのETRのルーティング可能なIPアドレスです。各RLOCはステータスの到達可能性を伝えますが、要求者の視点からパスの到達可能性を伝えません。パスの到達可能性の個別のテストが必要です。詳細については、「rloc-probingアルゴリズム」（セクション7.1）を参照してください。
Note that a Map-Reply MAY contain different EID-Prefix granularity (prefix + mask length) than the Map-Request that triggers it. This might occur if a Map-Request were for a prefix that had been returned by an earlier Map-Reply. In such a case, the requester updates its cache with the new prefix information and granularity. For example, a requester with two cached EID-Prefixes that are covered by a Map-Reply containing one less-specific prefix replaces the entry with the less-specific EID-Prefix. Note that the reverse, replacement of one less-specific prefix with multiple more-specific prefixes, can also occur, not by removing the less-specific prefix but rather by adding the more-specific prefixes that, during a lookup, will override the less-specific prefix.
マップ応答には、それをトリガーするMAP-Requestとは異なるeid-prefix粒度（プレフィックスマスク長）が含まれている場合があることに注意してください。これは、以前のマップ応答によって返されていたプレフィックス用のマップレクストが発生する場合があります。そのような場合、要求者は新しいプレフィックス情報と粒度でキャッシュを更新します。たとえば、1つの特異的なプレフィックスを含むマップReplyでカバーされている2つのキャッシュされたEID-PREFIXを備えたリクエスカーは、エントリをより特定のEID-PREFIXに置き換えます。1つのより特異的なプレフィックスを複数のより特異的なプレフィックスに置き換えることも、それほど固有のプレフィックスを削除するのではなく、検索中に検索中により少ないほどオーバーライドするより固有のプレフィックスを追加することで発生する可能性があることに注意してください。 - 固有のプレフィックス。
When an EID moves out of a LISP site [EID-MOBILITY], the database Mapping System may have overlapping EID-Prefixes. Or when a LISP site is configured with multiple sets of ETRs that support different EID-Prefix mask lengths, the database Mapping System may have overlapping EID-Prefixes. When overlapping EID-Prefixes exist, a Map-Request with an EID that best matches any EID-Prefix MUST be returned in a single Map-Reply message. For instance, if an ETR had database mapping entries for EID-Prefixes:
EIDがLISPサイト[EID-Mobility]から外に出ると、データベースマッピングシステムにEID-PREFIXESが重複している可能性があります。または、異なるEID-PREFIXマスクの長さをサポートする複数のETRセットでLISPサイトが構成されている場合、データベースマッピングシステムにはEID-PREFIXが重複している可能性があります。EID-PREFIXが重複する場合、EID-Prefixに最も一致するEIDを備えたマップリクエストは、単一のマップ応答メッセージで返される必要があります。たとえば、ETRにEID-PREFIXESのデータベースマッピングエントリがある場合：
2001:db8::/32
2001:db8:1::/48
2001:db8:1:1::/64
2001:db8:1:2::/64
A Map-Request for EID 2001:db8:1:1::1 would cause a Map-Reply with a record count of 1 to be returned with a mapping record EID-Prefix of 2001:db8:1:1::/64.
Eid 2001のマップリクエスト：DB8：1：1 :: 1は、2001年のマッピングレコードEid-Prefix：DB8：1：1 ::/64で1のレコードカウントが返されるマップ応答を引き起こします。。
A Map-Request for EID 2001:db8:1:5::5 would cause a Map-Reply with a record count of 3 to be returned with mapping records for EID-Prefixes 2001:db8:1::/48, 2001:db8:1:1::/64, and 2001:db8:1:2::/64, filling out the /48 with more-specific prefixes that exist in the Mapping System.
Eid 2001のマップ要求：DB8：1：5 :: 5は、Eid-Prefixes 2001：DB8：1 ::/48、2001のマッピングレコードで3のレコードカウントが返されるマップ応答を引き起こします。DB8：1：1 ::/64、および2001：DB8：1：2 ::/64、マッピングシステムに存在するより固有のプレフィックスを/48に記入します。
Note that not all overlapping EID-Prefixes need to be returned but only the more-specific entries (note in the second example above that 2001:db8::/32 was not returned for requesting EID 2001:db8:1:5::5) for the matching EID-Prefix of the requesting EID. When more than one EID-Prefix is returned, all SHOULD use the same TTL value so they can all time out at the same time. When a more-specific EID-Prefix is received later, its TTL value in the Map-Reply record can be stored even when other less-specific entries exist. When a less-specific EID-Prefix is received later, its Map-Cache expiration time SHOULD be set to the minimum expiration time of any more-specific EID-Prefix in the Map-Cache. This is done so the integrity of the EID-Prefix set is wholly maintained and so no more-specific entries are removed from the Map-Cache while keeping less-specific entries.
すべての重複するEID-PREFIXを返す必要があるわけではありませんが、より特定のエントリのみを返す必要があります（上記の2番目の例では、2001年：DB8 ::/32はEID 2001：DB8：1：5 :: 5を要求するために返されませんでした）要求するEidの一致するEid-Prefixの場合。複数のEid-Prefixが返された場合、すべてが同じTTL値を使用して、同時に常に時間をかけることができるようにする必要があります。より固有のEID-Prefixを後で受信すると、他の特異的なエントリが存在する場合でも、マップ対応レコードのTTL値を保存できます。あまり固有のEid-Prefixを後で受信すると、マップキャッシュのより固有のEid-Prefixの最小有効期限にマップキャッシュの有効期限を設定する必要があります。これが行われるため、Eid-Prefixセットの整合性が完全にメンテナンスされているため、より特定のエントリを維持しながら、より特定のエントリはマップキャッシュから削除されません。
For scalability, it is expected that aggregation of EID addresses into EID-Prefixes will allow one Map-Reply to satisfy a mapping for the EID addresses in the prefix range, thereby reducing the number of Map-Request messages.
スケーラビリティのために、EIDアドレスのEID-Prefixesへの集約により、1つのMAP-Replyがプレフィックス範囲のEIDアドレスのマッピングを満たすことで、Map-Requestメッセージの数を減らすことが期待されます。
Map-Reply records can have an empty Locator-Set. A Negative Map-Reply is a Map-Reply with an empty Locator-Set. Negative Map-Replies convey special actions by the Map-Reply sender to the ITR or PITR that have solicited the Map-Reply. There are two primary applications for Negative Map-Replies. The first is for a Map-Resolver to instruct an ITR or PITR when a destination is for a LISP site versus a non-LISP site, and the other is to source quench Map-Requests that are sent for non-allocated EIDs.
Map-Replyレコードには、空のロケーターセットがあります。ネガティブマップリプリーは、空のロケーターセットを備えたマップ繰り返しです。ネガティブマップレプリーズは、マップレンダーまたはMAP Replyを勧誘したITRまたはPITRに特別なアクションを伝えます。ネガティブマップレプリーには2つの主要なアプリケーションがあります。1つ目は、宛先がLISPサイトと非リスプサイトである場合に宛先がITRまたはPITRに指示することで、もう1つは、不割りやしたEIDに送信されるクエンチマップリケストを調達することです。
For each Map-Reply record, the list of Locators in a Locator-Set MUST be sorted in order of ascending IP address where an IPv4 Routing Locator Address is considered numerically "less than" an IPv6 Routing Locator Address.
各MAP-Replyレコードについて、Locator-Setのロケーターのリストは、IPv4ルーティングロケーターアドレスが数値的に「小さい」と見なされるIPアドレスを上昇する順にソートする必要があります。
When sending a Map-Reply message, the destination address is copied from one of the 'ITR-RLOC' fields from the Map-Request. The ETR can choose a Routing Locator Address from one of the address families it supports. For Data-Probes, the destination address of the Map-Reply is copied from the source address of the Data-Probe message that is invoking the reply. The source address of the Map-Reply is one of the chosen local IP addresses; this allows Unicast Reverse Path Forwarding (uRPF) checks to succeed in the upstream service provider. The destination port of a Map-Reply message is copied from the source port of the Map-Request or Data-Probe, and the source port of the Map-Reply message is set to the well-known UDP port 4342.
Map-Replyメッセージを送信すると、宛先アドレスは、Map-Requestから「ITR-RLOC」フィールドの1つからコピーされます。ETRは、サポートするアドレスファミリのいずれかからルーティングロケーターアドレスを選択できます。データポーチの場合、マップ対応の宛先アドレスは、返信を呼び出すデータプローブメッセージのソースアドレスからコピーされます。MAP-Replyのソースアドレスは、選択したローカルIPアドレスの1つです。これにより、ユニキャストリバースパス転送（URPF）チェックがアップストリームサービスプロバイダーで成功することができます。マップレプリーメッセージの宛先ポートは、マップレクエストまたはデータプローブのソースポートからコピーされ、マップ対応メッセージのソースポートは、よく知られているUDPポート4342に設定されています。
This section specifies the encoding format for the Map-Register message. The message is sent in UDP with a destination UDP port of 4342 and a randomly selected UDP source port number.
このセクションでは、Map-Registerメッセージのエンコード形式を指定します。このメッセージは、4342の宛先UDPポートとランダムに選択されたUDPソースポート番号でUDPで送信されます。
The fields below are used in multiple control messages. They are defined for Map-Register, Map-Notify, and Map-Notify-Ack message types.
以下のフィールドは、複数の制御メッセージで使用されます。それらは、Map-Register、Map-Notify、およびMap-Notify-cackメッセージタイプ用に定義されています。
The Map-Register message format is:
Map-Registerメッセージ形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3 |P|S|I| Reserved |E|T|a|R|M| Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Algorithm ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Rsvd | Map-Version Number | EID-Prefix-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-Prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions:
パケットフィールドの説明：
Type: 3 (Map-Register)
タイプ：3（Map-Register）
P: This is the proxy Map-Reply bit. When set to 1, the ETR sending the Map-Register message is requesting the Map-Server to proxy a Map-Reply. The Map-Server will send non-authoritative Map-Replies on behalf of the ETR.
P：これはプロキシマップリプリービットです。1に設定すると、Map-Registerメッセージを送信するETRは、マップサーバーにマップ応答をプロキシに要求しています。Map-Serverは、ETRに代わって非認証マップレプリーを送信します。
S: This is the security-capable bit. When set, the procedures from [RFC9303] are supported.
S：これはセキュリティ利用可能なビットです。設定すると、[RFC9303]からの手順がサポートされます。
I: This is the ID-present bit. This bit is set to 1 to indicate that a 128-bit 'xTR-ID' field and a 64-bit 'Site-ID' field are present at the end of the Map-Register message. If an xTR is configured with an xTR-ID and Site-ID, it MUST set the I-bit to 1 and include its xTR-ID and Site-ID in the Map-Register messages it generates. The combination of Site-ID plus xTR-ID uniquely identifies an xTR in a LISP domain and serves to track its last seen nonce.
I：これはID-Present Bitです。このビットは、128ビットの「XTR-ID」フィールドと64ビット「サイトID」フィールドがマップレジスターメッセージの最後に存在することを示しています。XTRがXTR-IDおよびSite-IDで構成されている場合、Iビットを1に設定し、生成するMap-RegisterメッセージにXTR-IDとSite-IDを含める必要があります。Site-ID Plus Xtr-IDの組み合わせは、LISPドメインのXTRを一意に識別し、最後の見られたNonCEを追跡するのに役立ちます。
Reserved: This unassigned field MUST be set to 0 on transmit and MUST be ignored on receipt.
予約済み：この割り当てされていないフィールドは、送信時に0に設定する必要があり、受信時に無視する必要があります。
E: This is the Map-Register EID-notify bit. This is used by a First-Hop Router that discovers a dynamic EID. This EID-notify-based Map-Register is sent by the First-Hop Router to a same site xTR that propagates the Map-Register to the Mapping System. The site xTR keeps state to later Map-Notify the First-Hop Router after the EID has moved away. See [EID-MOBILITY] for a detailed use case.
E：これは、Map-Register eid-notifyビットです。これは、ダイナミックなEIDを発見する最初のホップルーターによって使用されます。このEid-NotifyベースのMap-Registerは、ファーストホップルーターによってMap-Registerをマッピングシステムに伝播する同じサイトXTRに送信されます。サイトXtrは、Eidが退去した後、後のMap-Notify First Hopルーターを後で状態に保ちます。詳細なユースケースについては、[Eid-Mobility]を参照してください。
T: This is the use TTL for timeout bit. When set to 1, the xTR wants the Map-Server to time out registrations based on the value in the 'Record TTL' field of this message. Otherwise, the default timeout described in Section 8.2 is used.
T：これは、タイムアウトビットの使用TTLです。1に設定すると、XTRは、このメッセージの「レコードTTL」フィールドの値に基づいて、マップサーバーが登録をタイムアウトすることを望みます。それ以外の場合、セクション8.2で説明したデフォルトのタイムアウトが使用されます。
a: This is the merge-request bit. When set to 1, the xTR requests to merge RLOC-Records from different xTRs registering the same EID-Record. See Signal-Free Multicast [RFC8378] for one use-case example.
A：これはマージリクエストビットです。1に設定すると、XTRは、同じEid-Recordを登録する異なるXTRからRLOCレコードをマージするように要求します。1つのユースケースの例については、信号のないマルチキャスト[RFC8378]を参照してください。
R: This reserved and unassigned bit MUST be set to 0 on transmit and MUST be ignored on receipt.
R：この予約済みのビットと未割り当てビットは、送信時に0に設定する必要があり、受信時に無視する必要があります。
M: This is the want-map-notify bit. When set to 1, an ETR is requesting a Map-Notify message to be returned in response to sending a Map-Register message. The Map-Notify message sent by a Map-Server is used to acknowledge receipt of a Map-Register message.
M：これはWant-Map-Notifyビットです。1に設定すると、ETRはMap-Registerメッセージの送信に応じてMap-Notifyメッセージを返すように要求しています。Map-Serverによって送信されたMap-Notifyメッセージは、マップ登録メッセージの受信を確認するために使用されます。
Record Count: This is the number of records in this Map-Register message. A record is comprised of that portion of the packet labeled 'Record' above and occurs the number of times equal to Record Count.
レコードカウント：これは、このマップ登録メッセージのレコードの数です。レコードは、上記の「レコード」とラベル付けされたパケットのその部分で構成され、レコードカウントに等しい回数が発生します。
Nonce: This 8-octet 'Nonce' field is incremented each time a Map-Register message is sent. When a Map-Register acknowledgment is requested, the nonce is returned by Map-Servers in Map-Notify messages. Since the entire Map-Register message is authenticated, the 'Nonce' field serves to protect against Map-Register replay attacks. An ETR that registers to the Mapping System SHOULD store the last nonce sent in persistent storage, so when it restarts, it can continue using an incrementing nonce. If the ETR cannot support saving the nonce, then when it restarts, it MUST use a new authentication key to register to the Mapping System. A Map-Server MUST track and save in persistent storage the last nonce received for each ETR xTR-ID and key pair. If a Map-Register is received with a nonce value that is not greater than the saved nonce, it MUST drop the Map-Register message and SHOULD log the fact that a replay attack could have occurred.
Nonce：この8-OCTET「NonCe」フィールドは、マップ登録メッセージが送信されるたびに増加します。Map-Registerの確認が要求されると、NonceはMap-NotifyメッセージのMap-Serversによって返されます。Map-Registerメッセージ全体が認証されているため、「NonCe」フィールドは、Map-Registerリプレイ攻撃から保護するのに役立ちます。マッピングシステムに登録するETRは、送信された最後のnonCEを永続的なストレージに保存する必要があるため、再起動すると、増分の非CEを使用し続けることができます。ETRがNONCEの節約をサポートできない場合、再起動すると、新しい認証キーを使用してマッピングシステムに登録する必要があります。Map-Serverは、ETR XTR-IDごとに受け取った最後のNONCEとキーペアに対して受け取った最後のNONCEを追跡および保存する必要があります。保存されたNonCEよりも大きくないNonCE値でMAP-Registerが受信された場合、Map-Registerメッセージをドロップする必要があり、リプレイ攻撃が発生した可能性があるという事実を記録する必要があります。
Key ID: This is a key-id value that identifies a pre-shared secret between an ETR and a Map-Server. Per-message keys are derived from the pre-shared secret to authenticate the origin and protect the integrity of the Map-Register. The Key ID allows rotating between multiple pre-shared secrets in a nondisruptive way. The pre-shared secret MUST be unique per each LISP Site-ID.
キーID：これは、ETRとマップサーバーの間の事前に共有された秘密を識別するキーID値です。メッセージごとのキーは、起源を認証し、マップレジスターの完全性を保護するために、事前に共有された秘密から派生しています。キーIDは、破壊的な方法で複数の事前に共有された秘密を回転させることができます。事前に共有された秘密は、各LISPサイトIDごとに一意でなければなりません。
Algorithm ID: This field identifies the Key Derivation Function (KDF) and Message Authentication Code (MAC) algorithms used to derive the key and to compute the Authentication Data of a Map-Register. This 8-bit field identifies the KDF and MAC algorithm pair. See Section 12.5 for codepoint assignments.
アルゴリズムID：このフィールドは、キーを導き出し、MAP-Registerの認証データを計算するために使用されるキー派生関数（KDF）およびメッセージ認証コード（MAC）アルゴリズムを識別します。この8ビットフィールドは、KDFおよびMACアルゴリズムペアを識別します。CodePointの割り当てについては、セクション12.5を参照してください。
Authentication Data Length: This is the length in octets of the 'Authentication Data' field that follows this field. The length of the 'Authentication Data' field is dependent on the MAC algorithm used. The length field allows a device that doesn't know the MAC algorithm to correctly parse the packet.
認証データの長さ：これは、このフィールドに続く「認証データ」フィールドのオクテットの長さです。「認証データ」フィールドの長さは、使用されるMacアルゴリズムに依存します。長さフィールドを使用すると、Macアルゴリズムを知らないデバイスがパケットを正しく解析できます。
Authentication Data: This is the output of the MAC algorithm placed in this field after the MAC computation. The MAC output is computed as follows:
認証データ：これは、MAC計算後にこのフィールドに配置されたMACアルゴリズムの出力です。MAC出力は次のように計算されます。
1. The KDF algorithm is identified by the 'Algorithm ID' field according to the table in Section 12.5. Implementations of this specification MUST implement HMAC-SHA-256-128 [RFC4868] and SHOULD implement HMAC-SHA-256-128+HKDF-SHA256 [RFC5869].
1. KDFアルゴリズムは、セクション12.5の表に従って「アルゴリズムID」フィールドによって識別されます。この仕様の実装は、HMAC-SHA-256-128 [RFC4868]を実装する必要があり、HMAC-SHA-256-128 HKDF-SHA256 [RFC5869]を実装する必要があります。
2. The MAC algorithm is identified by the 'Algorithm ID' field according to the table in Section 12.5.
2. Macアルゴリズムは、セクション12.5の表に従って「アルゴリズムID」フィールドによって識別されます。
3. The pre-shared secret used to derive the per-message key is represented by PSK[Key ID], that is, the pre-shared secret identified by the Key ID.
3. メッセージごとのキーを導き出すために使用される事前に共有された秘密は、PSK [キーID]、つまりキーIDによって識別される事前に共有された秘密で表されます。
4. The derived per-message key is computed as: per-msg-key=KDF(nonce+PSK[Key ID],s). Where the nonce is the value in the 'Nonce' field of the Map-Register, "+" denotes concatenation and "s" (the salt) is a string that corresponds to the message type being authenticated. For Map-Register messages, it is equal to "Map-Register Authentication". Similarly, for Map-Notify and Map-Notify-Ack messages, it is "Map-Notify Authentication" and "Map-Notify-Ack Authentication", respectively. For those Algorithm IDs defined in Section 12.5 that specify a 'none' KDF, the per-message key is computed as: per-msg-key = PSK[Key ID]. This means that the same key is used across multiple protocol messages.
4. 導出されたメッセージごとのキーは、次のように計算されます：per-msg-key = kdf（nonce psk [key id]、s）。ここでは、NonCeはMap-Registerの「NonCe」フィールドの値です」「Concatenationと「S」（塩）は、認証されているメッセージタイプに対応する文字列です。Map-Registerメッセージの場合、「Map-Register Authentication」と等しくなります。同様に、Map-notifyおよびMap-notify-ackメッセージの場合、それぞれ「Map-notify認証」と「Map-notify-ack認証」です。「none」KDFを指定するセクション12.5で定義されているアルゴリズムIDの場合、メッセージごとのキーは次のように計算されます：per-msg-key = psk [key id]。これは、複数のプロトコルメッセージで同じキーが使用されることを意味します。
5. The MAC output is computed using the MAC algorithm and the per-msg-key over the entire Map-Register payload (from and including the LISP message type field through the end of the last RLOC-Record) with the authenticated data field preset to 0.
5. MAC出力は、マップ登録ペイロード全体（最後のRLOC-RECORDの終わりからLISPメッセージタイプフィールドを含む）全体でMACアルゴリズムとPer-MSG-Keyを使用して計算されます。。
The definition of the rest of the Map-Register can be found in the EID-Record description in Section 5.4. When the I-bit is set, the following fields are added to the end of the Map-Register message:
Map-Registerの残りの部分の定義は、セクション5.4のEID記録の説明に記載されています。Iビットが設定されると、次のフィールドがマップレジスターメッセージの最後に追加されます。
xTR-ID: 'xTR-ID' is a 128-bit field at the end of the Map-Register message, starting after the final Record in the message. The xTR-ID is used to uniquely identify an xTR. The same xTR-ID value MUST NOT be used in two different xTRs in the scope of the Site-ID.
XTR-ID： 'XTR-ID'は、メッセージの最終レコードの後に始まるMap-Registerメッセージの最後にある128ビットフィールドです。XTR-IDは、XTRを一意に識別するために使用されます。同じXTR-ID値を、サイトIDの範囲の2つの異なるXTRで使用してはなりません。
Site-ID: 'Site-ID' is a 64-bit field at the end of the Map-Register message, following the xTR-ID. The Site-ID is used to uniquely identify to which site the xTR that sent the message belongs. This document does not specify a strict meaning for the 'Site-ID' field. Informally, it provides an indication that a group of xTRs have some relationship, either administratively, topologically, or otherwise.
Site-ID： 'Site-ID'は、XTR-IDに続いて、Map-Registerメッセージの最後にある64ビットフィールドです。サイトIDは、メッセージを送信したXTRが属するサイトがどのサイトに属しているかを一意に識別するために使用されます。このドキュメントでは、「サイトID」フィールドの厳格な意味を指定しません。非公式には、XTRのグループが、管理上、トポロジー的、またはその他のいずれかで何らかの関係を持っていることを示しています。
This section specifies the encoding format for the Map-Notify and Map-Notify-Ack messages. The messages are sent inside a UDP packet with source and destination UDP ports equal to 4342.
このセクションでは、Map-notifyおよびMap-notify-ackメッセージのエンコード形式を指定します。メッセージは、4342に等しいソースと宛先UDPポートを備えたUDPパケット内で送信されます。
The Map-Notify and Map-Notify-Ack message formats are:
Map-notifyおよびmap-notify-ackメッセージ形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=4/5| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Algorithm ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Rsvd | Map-Version Number | EID-Prefix-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-Prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions:
パケットフィールドの説明：
Type: 4/5 (Map-Notify/Map-Notify-Ack)
The Map-Notify message has the same contents as a Map-Register message. See "Map-Register Message Format" (Section 5.6) for field descriptions and "Map-Reply Message Format" (Section 5.4) for EID-Record and RLOC-Record descriptions.
Map-Notifyメッセージは、Map-Registerメッセージと同じ内容を持っています。フィールドの説明については、「Map-Register Message Format」（セクション5.6）と「Map-Replyメッセージ形式」（セクション5.4）（セクション5.4）を参照してください。
The fields of the Map-Notify are copied from the corresponding Map-Register to acknowledge its correct processing. In the Map-Notify, the 'Authentication Data' field is recomputed using the corresponding per-message key and according to the procedure defined in the previous section. The Map-Notify message can also be used in an unsolicited manner. This topic is out of scope for this document. See [LISP-PUBSUB] for details.
Map-Notifyのフィールドは、対応するMAP-Registerからコピーされて、正しい処理を確認します。Map-notifyでは、「認証データ」フィールドは、対応するメッセージごとのキーを使用して、前のセクションで定義された手順に従って再計算されます。Map-Notifyメッセージは、未承諾の方法でも使用できます。このトピックは、このドキュメントの範囲外です。詳細については、[lisp-pubsub]を参照してください。
After sending a Map-Register, if a Map-Notify is not received after 1 second, the transmitter MUST retransmit the original Map-Register with an exponential backoff (base of 2, that is, the next backoff timeout interval is doubled); the maximum backoff is 1 minute. Map-Notify messages are only transmitted upon the reception of a Map-Register with the M-bit set; Map-Notify messages are not retransmitted. The only exception to this is for unsolicited Map-Notify messages; see below.
Map-Registerを送信した後、1秒後にMap-Notifyが受信されない場合、送信機は指数バックオフ（2のベース、つまり次のバックオフタイムアウト間隔が2倍になる）で元のMap-Registerを再送信する必要があります。最大バックオフは1分です。Map-Notifyメッセージは、Mビットセットを使用したマップレジスターの受信時にのみ送信されます。Map-Notifyメッセージは再送信されません。これの唯一の例外は、未承諾のMap-Notifyメッセージです。下記参照。
A Map-Server sends an unsolicited Map-Notify message (one that is not used as an acknowledgment to a Map-Register message) only in conformance with Section 3.1 ("Congestion Control Guidelines") of [RFC8085] and Section 3.3 ("Reliability Guidelines") of [RFC8085]. A Map-Notify is retransmitted until a Map-Notify-Ack is received by the Map-Server with the same nonce used in the Map-Notify message. An implementation SHOULD retransmit up to 3 times at 3-second retransmission intervals, after which time the retransmission interval is exponentially backed off (base of 2, that is, the next backoff timeout interval is doubled) for another 3 retransmission attempts. Map-Notify-Ack messages are only transmitted upon the reception of an unsolicited Map-Notify; Map-Notify-Ack messages are not retransmitted.
マップサーバーは、[RFC8085]およびセクション3.3（「信頼性」のセクション3.1（「混雑制御ガイドライン」）のセクション3.1（「混雑制御ガイドライン」）に準拠してのみ、未承諾のマップノティイメッセージメッセージ（マップ登録メッセージの確認として使用されないもの）を送信します。[RFC8085]のガイドライン "）。Map-Notify-ackがMap-notifyメッセージで使用されているのと同じnonceを使用して、Map-notify-ackがMap-Serverによって受信されるまで再送信されます。実装は、3秒の再送信間隔で最大3回再送信する必要があります。その後、再送信間隔は指数関数的にバックアウトされます（つまり、次のバックオフタイムアウト間隔は2倍になります）。Map-notify-ackメッセージは、未承諾のMap-notifyの受信時にのみ送信されます。Map-notify-ackメッセージは再送信されません。
The Map-Notify-Ack message has the same contents as a Map-Notify message. It is used to acknowledge the receipt of an unsolicited Map-Notify and, once the Authentication Data is validated, allows the sender to stop retransmitting a Map-Notify with the same nonce and (validated) Authentication Data. The fields of the Map-Notify-Ack are copied from the corresponding Map-Notify message to acknowledge its correct processing. The 'Authentication Data' field is recomputed using the corresponding per-message key and according to the procedure defined in the previous section.
Map-notify-ackメッセージは、Map-notifyメッセージと同じ内容を持っています。未承諾のMap-Notifyの受領を確認するために使用され、認証データが検証されたら、送信者が同じNonCEおよび（検証済みの）認証データを使用してMap-Notifyの再送信を停止できます。Map-Notify-ackのフィールドは、対応するMap-Notifyメッセージからコピーされ、正しい処理を確認します。「認証データ」フィールドは、対応するメッセージごとのキーを使用して再計算され、前のセクションで定義されている手順に従って再計算されます。
Upon reception of a Map-Register, Map-Notify, or Map-Notify-Ack, the receiver verifies the Authentication Data. If the Authentication Data fails to validate, the message is dropped without further processing.
Map-Register、Map-Notify、またはMap-notify-ackを受信すると、受信者は認証データを検証します。認証データが検証に失敗した場合、メッセージはさらに処理せずに削除されます。
An Encapsulated Control Message (ECM) is used to encapsulate control packets sent between xTRs and the mapping database system or internal to the mapping database system.
カプセル化されたコントロールメッセージ（ECM）は、XTRとマッピングデータベースシステム間で送信されるコントロールパケットまたはマッピングデータベースシステムの内部をカプセル化するために使用されます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LISP |Type=8 |S|D|R|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header |
IH | (uses RLOC or EID addresses) |
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = yyyy |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LCM | LISP Control Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet header descriptions:
パケットヘッダーの説明：
OH: This is the outer IPv4 or IPv6 header, which uses RLOC addresses in the source and destination header address fields.
OH：これは、ソースおよび宛先ヘッダーアドレスフィールドでRLOCアドレスを使用する外側IPv4またはIPv6ヘッダーです。
UDP: This is the outer UDP header with destination port 4342. The source port is randomly allocated. The checksum field MUST be non-zero.
UDP：これは、宛先ポート4342を備えた外側のUDPヘッダーです。ソースポートはランダムに割り当てられています。チェックサムフィールドはゼロ以外でなければなりません。
LISP: Type 8 is defined to be a "LISP Encapsulated Control Message", and what follows is either an IPv4 or IPv6 header, as encoded by the first 4 bits after the 'Reserved' field, or the 'Authentication Data' field [RFC9303] if the S-bit (see below) is set.
LISP：タイプ8は「LISPカプセル化されたコントロールメッセージ」であると定義されています。「予約済み」フィールドの後の最初の4ビットによってエンコードされるIPv4またはIPv6ヘッダーまたは「認証データ」フィールド[RFC9303] S-BIT（以下を参照）が設定されている場合。
Type: 8 (Encapsulated Control Message (ECM))
タイプ：8（カプセル化されたコントロールメッセージ（ECM））
S: This is the Security bit. When set to 1, the field following the 'Reserved' field will have the following Authentication Data format and follow the procedures from [RFC9303].
S：これはセキュリティビットです。1に設定すると、「予約済み」フィールドに続くフィールドには、次の認証データ形式があり、[RFC9303]の手順に従います。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD Type | Authentication Data Content . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D: This is the DDT-bit. When set to 1, the sender is requesting a Map-Referral message to be returned. Details regarding this procedure are described in [RFC8111].
D：これはDDTビットです。1に設定すると、送信者はマップ参照メッセージを返すように要求しています。この手順に関する詳細は、[RFC8111]で説明されています。
R: This reserved and unassigned bit MUST be set to 0 on transmit and MUST be ignored on receipt.
R：この予約済みのビットと未割り当てビットは、送信時に0に設定する必要があり、受信時に無視する必要があります。
IH: This is the inner IPv4 or IPv6 header, which can use either RLOC or EID addresses in the header address fields. When a Map-Request is encapsulated in this packet format, the destination address in this header is an EID.
IH：これは、内側のIPv4またはIPv6ヘッダーであり、ヘッダーアドレスフィールドでRLOCまたはEIDアドレスのいずれかを使用できます。このパケット形式でマップリケストがカプセル化されている場合、このヘッダーの宛先アドレスはEIDです。
UDP: This is the inner UDP header, where the port assignments depend on the control packet being encapsulated. When the control packet is a Map-Request or Map-Register, the source port is selected by the ITR/PITR and the destination port is 4342. When the control packet is a Map-Reply, the source port is 4342 and the destination port is assigned from the source port of the invoking Map-Request. Port number 4341 MUST NOT be assigned to either port. The checksum field MUST be non-zero.
UDP：これは内側のUDPヘッダーであり、ポート割り当てはカプセル化されているコントロールパケットに依存します。コントロールパケットがマップリクエストまたはマップレジスターの場合、ソースポートはITR/PITRによって選択され、宛先ポートは4342です。コントロールパケットがマップ応答の場合、ソースポートは4342と宛先ポートです。Inving Map-Requestのソースポートから割り当てられます。ポート番号4341は、どちらのポートにも割り当てられないでください。チェックサムフィールドはゼロ以外でなければなりません。
LCM: The format is one of the control message formats described in Section 5. Map-Request messages are allowed to be control plane (ECM) encapsulated. When Map-Requests are sent for RLOC-Probing purposes (i.e., the probe-bit is set), they MUST NOT be sent inside Encapsulated Control Messages. PIM Join/Prune messages [RFC6831] are also allowed to be control plane (ECM) encapsulated.
LCM：この形式は、セクション5で説明されているコントロールメッセージ形式の1つです。マップレクエストメッセージは、カプセル化されたコントロールプレーン（ECM）になります。MAP-RequestがRLOCプロビング目的で送信される場合（つまり、プローブビットが設定されています）、カプセル化されたコントロールメッセージ内で送信してはなりません。PIM Join/Pruneメッセージ[RFC6831]も、カプセル化されたコントロールプレーン（ECM）であることが許可されています。
In the LISP architecture, ITRs/PITRs use a local Map-Cache to store EID-to-RLOC mappings for forwarding. When an ETR updates a mapping, a mechanism is required to inform ITRs/PITRs that are using such mappings.
LISPアーキテクチャでは、ITRS/PITRSはローカルマップキャッシュを使用して、Eid-to-RLOCマッピングを転送用に保存します。ETRがマッピングを更新する場合、そのようなマッピングを使用しているITR/PITRを通知するためにメカニズムが必要です。
The LISP data plane defines several mechanisms to update mappings [RFC9300]. This document specifies the Solicit-Map-Request (SMR), a control plane push-based mechanism. An additional control plane mechanism based on the Publish/Subscribe paradigm is specified in [LISP-PUBSUB].
LISPデータプレーンは、マッピングを更新するためのいくつかのメカニズムを定義します[RFC9300]。このドキュメントは、コントロールプレーンのプッシュベースのメカニズムであるSolict-Map-Request（SMR）を指定します。パブリッシュ/サブスクライブパラダイムに基づく追加の制御プレーンメカニズムは、[lisp-pubsub]で指定されています。
Soliciting a Map-Request is a selective way for ETRs, at the site where mappings change, to control the rate they receive requests for Map-Reply messages. SMRs are also used to tell remote ITRs to update the mappings they have cached.
Map-Requestの勧誘は、マッピングが変更されるサイトで、Map Requestsのリクエストを受信するレートを制御するためのETRの選択的な方法です。SMRは、リモートITRにキャッシュしたマッピングを更新するように指示するためにも使用されます。
Since ETRs are not required to keep track of remote ITRs that have cached their mappings, they do not know which ITRs need to have their mappings updated. As a result, an ETR will solicit Map-Requests to those sites to which it has been sending LISP encapsulated data packets for the last minute, and when an ETR is also acting as an ITR, it will send an SMR to an ITR to which it has recently sent encapsulated data.
ETRは、マッピングをキャッシュしたリモートITRを追跡する必要はないため、どのITRがマッピングを更新する必要があるかを知りません。その結果、ETRは、最後の最後にLISPカプセル化データパケットを送信しているサイトにMap-Requestsを募集し、ETRもITRとして機能している場合、ITRにSMRを送信します。最近、カプセル化されたデータを送信しました。
An SMR message is simply a bit set in a Map-Request message. An ITR or PITR will send a Map-Request (SMR-invoked Map-Request) when it receives an SMR message. While the SMR message is sent through the data plane, the SMR-invoked Map-Request MUST be sent through the Mapping System (not directly).
SMRメッセージは、マップレクエストメッセージに少し設定されています。ITRまたはPITRは、SMRメッセージを受信するときにMap-Request（SMR-Invoked Map-Request）を送信します。SMRメッセージはデータプレーンを介して送信されますが、SMRが吹き込まれたMap-Requestはマッピングシステムを介して（直接ではなく）送信する必要があります。
Both the SMR sender and the SMR responder MUST rate limit these messages. It is RECOMMENDED that the SMR sender rate limit a Map-Request for the same destination RLOC to no more than one packet every 3 seconds. It is RECOMMENDED that the SMR responder rate limit a Map-Request for the same EID-Prefix to no more than once every 3 seconds.
SMR送信者とSMRレスポンダーの両方が、これらのメッセージを制限する必要があります。SMR送信者レートは、同じ宛先RLOCのMAP-REQUESTを3秒ごとに1パケット以下に制限することをお勧めします。SMRレスポンダーレートは、同じEid-PrefixのMAP-Requestを3秒ごとに1回以下に制限することをお勧めします。
When an ITR receives an SMR message for which it does not have a cached mapping for the EID in the SMR message, it SHOULD NOT send an SMR-invoked Map-Request. This scenario can occur when an ETR sends SMR messages to all Locators in the Locator-Set it has stored in its Map-Cache but the remote ITRs that receive the SMR may not be sending packets to the site. There is no point in updating the ITRs until they need to send, in which case they will send Map-Requests to obtain a Map-Cache entry.
ITRがSMRメッセージにEIDのキャッシュマッピングを持たないSMRメッセージを受信した場合、SMRに吹き込まれたMap-Requestを送信しないでください。このシナリオは、ETRがマップキャッシュに保存したロケーターセットのすべてのロケーターにSMRメッセージを送信すると発生する可能性がありますが、SMRを受け取ったリモートITRはパケットをサイトに送信していない可能性があります。ITRが送信する必要があるまで更新することには意味がありません。その場合、マップキャッシュエントリを取得するためにマップリケストを送信します。
This document defines several control plane mechanisms for determining RLOC reachability. Please note that additional data plane reachability mechanisms are defined in [RFC9300].
このドキュメントでは、RLOCの到達可能性を決定するためのいくつかの制御プレーンメカニズムを定義しています。追加のデータプレーンリーチビリティメカニズムは[RFC9300]で定義されていることに注意してください。
1. An ITR may receive an ICMP Network Unreachable or Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. Note that trusting ICMP messages may not be desirable, but neither is ignoring them completely. Implementations are encouraged to follow current best practices in treating these conditions [OPSEC-ICMP-FILTER].
1. ITRは、使用しているRLOCに対して、ICMPネットワークが到達不可能またはホストの到達不可能なメッセージを受信する場合があります。これは、RLOCがダウンしている可能性が高いことを示しています。ICMPメッセージを信頼することは望ましくないかもしれませんが、それも完全に無視していないことに注意してください。実装は、これらの条件[OPSEC-ICMP-FILTER]を治療する際の現在のベストプラクティスに従うことをお勧めします。
2. When an ITR participates in the routing protocol that operates in the underlay routing system, it can determine that an RLOC is down when no Routing Information Base (RIB) entry exists that matches the RLOC IP address.
2. ITRがアンダーレイルーティングシステムで動作するルーティングプロトコルに参加すると、RLOC IPアドレスと一致するルーティング情報ベース（RIB）エントリが存在しない場合、RLOCがダウンしていると判断できます。
3. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [RFC6832] and LISP-encapsulated data is sent to a non-LISP-capable site.
3. ITRは、宛先ホストからICMPポートの到達不可能なメッセージを受信する場合があります。これは、ITRがインターワーキング[RFC6832]を使用しようとする場合に発生し、LISPにカプセル化されたデータが非リスプ対応サイトに送信されます。
4. An ITR may receive a Map-Reply from an ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up, since the ETR was able to send the Map-Reply to the ITR. Please note that in some scenarios the RLOC -- from the outer header -- can be a spoofable field.
4. ITRは、以前に送信されたMap-Requestに応じて、ETRからマップ対応を受信する場合があります。ETRがITRにマップ応答を送信することができたため、MAP-ReplyのRLOCソースが上昇している可能性があります。いくつかのシナリオでは、外側のヘッダーからRLOCがスプーフィング可能なフィールドになる可能性があることに注意してください。
5. An ITR/ETR pair can use the 'RLOC-Probing' mechanism described below.
5. ITR/ETRペアは、以下で説明する「RLOCプロビング」メカニズムを使用できます。
When ITRs receive ICMP Network Unreachable or Host Unreachable messages as a method to determine unreachability, they will refrain from using Locators that are described in Locator lists of Map-Replies. However, using this approach is unreliable because many network operators turn off generation of ICMP Destination Unreachable messages.
ITRが到達不能を決定する方法としてICMPネットワークを受け取ることができない、または到達不能なメッセージをホストしない場合、マップレプリーのロケーターリストに記載されているロケーターの使用を控えます。ただし、多くのネットワークオペレーターがICMP宛先の到達不可能なメッセージの生成をオフにするため、このアプローチを使用することは信頼できません。
If an ITR does receive an ICMP Network Unreachable or Host Unreachable message, it MAY originate its own ICMP Destination Unreachable message destined for the host that originated the data packet the ITR encapsulated.
ITRがICMPネットワークが到達不能またはホストの到達不可能なメッセージを受け取った場合、ITRがカプセル化されたデータパケットを発信したホストに任命された独自のICMP宛先の到達不可能なメッセージを発生する可能性があります。
This assumption does create a dependency: Locator unreachability is detected by the receipt of ICMP Host Unreachable messages. When a Locator has been determined to be unreachable, it is not used for active traffic; this is the same as if it were listed in a Map-Reply with Priority 255.
この仮定は依存関係を作成します。ロケーターの到達不能は、ICMPホストの到達不可能なメッセージを受信することによって検出されます。ロケーターが到達不能であると判断された場合、アクティブなトラフィックには使用されません。これは、優先度255を備えたマップ応答にリストされている場合と同じです。
The ITR can test the reachability of the unreachable Locator by sending periodic Map-Requests. Both Map-Requests and Map-Replies MUST be rate limited; see Sections 5.3 and 5.4 for information about rate limiting. Locator reachability testing is never done with data packets, since that increases the risk of packet loss for end-to-end sessions.
ITRは、定期的なマップリクエストを送信することにより、到達不可能なロケーターの到達可能性をテストできます。マップリクエストとマップレプリーの両方がレート制限されている必要があります。レートの制限については、セクション5.3および5.4を参照してください。ロケーターの到達可能性テストは、データパケットでは決して行われません。これにより、エンドツーエンドセッションのパケット損失のリスクが高まるためです。
RLOC-Probing is a method that an ITR or PITR can use to determine the reachability status of one or more Locators that it has cached in a Map-Cache entry. The probe-bit of the Map-Request and Map-Reply messages is used for RLOC-Probing.
Rloc-Probingは、ITRまたはPITRがマップキャッシュエントリでキャッシュされた1つ以上のロケーターの到達可能性ステータスを決定するために使用できる方法です。Map-RequestおよびMap-Replyメッセージのプローブビットは、RLOCプロビングに使用されます。
RLOC-Probing is done in the control plane on a timer basis, where an ITR or PITR will originate a Map-Request destined to a Routing Locator Address from one of its own Routing Locator Addresses. A Map-Request used as an RLOC-Probe is NOT encapsulated and NOT sent to a Map-Server or to the mapping database system as one would when requesting mapping data. The EID-Record encoded in the Map-Request is the EID-Prefix of the Map-Cache entry cached by the ITR or PITR. The ITR MAY include a mapping data record for its own database mapping information that contains the local EID-Prefixes and RLOCs for its site. RLOC-Probes are sent periodically using a jittered timer interval.
RLOC-Probingは、ITRまたはPITRが独自のルーティングロケーターアドレスのいずれかからルーティングロケーターアドレスに向けられたマップリクエストを作成するタイマーベースでコントロールプレーンで行われます。RLOC-Probeとして使用されるマップレクエストは、カプセル化されておらず、マッピングデータを要求するときにマップサーバーまたはマッピングデータベースシステムに送信されません。Map-RequestでエンコードされたEid-Recordは、ITRまたはPITRによってキャッシュされたマップキャッシュエントリのEid-Prefixです。ITRには、サイトのローカルEID-PREFIXSとRLOCを含む独自のデータベースマッピング情報のマッピングデータレコードが含まれる場合があります。RLOC-Probesは、ジッタータイマー間隔を使用して定期的に送信されます。
When an ETR receives a Map-Request message with the probe-bit set, it returns a Map-Reply with the probe-bit set. The source address of the Map-Reply is set to the IP address of the outgoing interface the Map-Reply destination address routes to. The Map-Reply SHOULD contain mapping data for the EID-Prefix contained in the Map-Request. This provides the opportunity for the ITR or PITR that sent the RLOC-Probe to get mapping updates if there were changes to the ETR's database mapping entries.
ETRがプローブビットセットを使用してMap-Requestメッセージを受信すると、プローブビットセットでマップ応答を返します。Map-Replyのソースアドレスは、マップ応答の宛先アドレスルートが発信インターフェイスのIPアドレスに設定されています。MAP-Replyには、Map-Requestに含まれるEid-Prefixのマッピングデータを含める必要があります。これにより、ETRのデータベースマッピングエントリに変更があった場合、RLOC-Probeを送信したITRまたはPITRがマッピング更新を取得する機会を提供します。
There are advantages and disadvantages of RLOC-Probing. The main benefit of RLOC-Probing is that it can handle many failure scenarios, allowing the ITR to determine when the path to a specific Locator is reachable or has become unreachable, thus providing a robust mechanism for switching to using another Locator from the cached Locator. RLOC-Probing can also provide rough Round-Trip Time (RTT) estimates between a pair of Locators, which can be useful for network management purposes as well as for selecting low-delay paths. The major disadvantage of RLOC-Probing is in the number of control messages required and the amount of bandwidth used to obtain those benefits, especially if the requirement for failure detection times is very small.
RLOCプロビングには利点と短所があります。RLOCプロビングの主な利点は、多くの障害シナリオを処理できることであり、ITRが特定のロケーターへのパスが到達可能または到達不能になった時期を判断できるため、キャッシュされたロケーターから別のロケーターを使用するための堅牢なメカニズムを提供することです。。RLOCプロビングは、ロケーターのペア間で大まかな往復時間（RTT）推定値を提供することもできます。これは、ネットワーク管理の目的や低遅延パスの選択に役立ちます。RLOCプロビングの主な欠点は、特に障害検出時間の要件が非常に少ない場合、必要な制御メッセージの数とそれらの利点を得るために使用される帯域幅の量です。
An ITR is configured with one or more Map-Resolver addresses. These addresses are "Locators" (or RLOCs) and MUST be routable on the underlying core network; they MUST NOT need to be resolved through LISP EID-to-RLOC mapping, as that would introduce a circular dependency. When using a Map-Resolver, an ITR does not need to connect to any other database Mapping System.
ITRは、1つ以上のMap-Resolverアドレスで構成されています。これらのアドレスは「ロケーター」（またはRLOC）であり、基礎となるコアネットワークでルーティング可能でなければなりません。Lisp Eid-to-RLOCマッピングを通じて解決する必要はありません。Map-Resolverを使用する場合、ITRは他のデータベースマッピングシステムに接続する必要はありません。
An ITR sends an Encapsulated Map-Request to a configured Map-Resolver when it needs an EID-to-RLOC mapping that is not found in its local Map-Cache. Using the Map-Resolver greatly reduces both the complexity of the ITR implementation and the costs associated with its operation.
ITRは、ローカルマップキャッシュには見られないEid-to-RLOCマッピングが必要な場合に、設定されたマップ再配置にカプセル化されたMap-Requestを送信します。Map-Resolverを使用すると、ITR実装の複雑さとその動作に関連するコストの両方が大幅に削減されます。
In response to an Encapsulated Map-Request, the ITR can expect one of the following:
カプセル化されたMAP-Requestに応じて、ITRは次のいずれかを期待できます。
* An immediate Negative Map-Reply (with action code "Natively-Forward" and a 15-minute TTL) from the Map-Resolver if the Map-Resolver can determine that the requested EID does not exist. The ITR saves the EID-Prefix returned in the Map-Reply in its cache, marks it as non-LISP-capable, and knows not to attempt LISP encapsulation for destinations matching it.
* マップリゾルバーが要求されたEIDが存在しないと判断できる場合、マップ分解型からの即時の負のマップ応答（アクションコード「ネイティブにフォワード」と15分間のTTL）。ITRは、キャッシュでマップリプリーで返されたEid-Prefixを保存し、それを非リスプ対応としてマークし、それに一致する宛先のLISPカプセル化を試みないことを知っています。
* A Negative Map-Reply (with action code "Natively-Forward") from a Map-Server that is authoritative (within the LISP deployment (Section 1.1)) for an EID-Prefix that matches the requested EID but that does not have an actively registered, more-specific EID-Prefix. In this case, the requested EID is said to match a "hole" in the authoritative EID-Prefix. If the requested EID matches a more-specific EID-Prefix that has been delegated by the Map-Server but for which no ETRs are currently registered, a 1-minute TTL is returned. If the requested EID matches a non-delegated part of the authoritative EID-Prefix, then it is not a LISP EID and a 15-minute TTL is returned. See Section 8.2 for a discussion of aggregate EID-Prefixes and details regarding Map-Server EID-Prefix matching.
* 要求されたEIDと一致するが、積極的にはないEID-PREFIXの権威ある（LISP展開内（セクション1.1））のマップサーバーからのネガティブマップ応答（アクションコードを「ネイティブにフォワード」して）登録された、より固有のEid-Prefix。この場合、要求されたEIDは、権威あるEid-Prefixの「穴」に一致すると言われています。要求されたEIDが、MAPサーバーによって委任されたが現在登録されていないより固有のEid-Prefixと一致する場合、1分間のTTLが返されます。要求されたEIDが権威あるEid-Prefixの非決定部分と一致する場合、それはLISP EIDではなく、15分のTTLが返されます。集計Eid-PrefixesとMap-Server Eid-Prefixマッチングに関する詳細の説明については、セクション8.2を参照してください。
* A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or possibly from a Map-Server answering on behalf of the ETR. See Section 8.4 for more details on Map-Resolver message processing.
* EIDからRLOCへのマッピングを所有するETRから、またはETRに代わって回答しているマップサーバーからのLISPマップ応答。マップ再配置メッセージ処理の詳細については、セクション8.4を参照してください。
Note that an ITR may be configured to both use a Map-Resolver and participate in a LISP-ALT logical network. In such a situation, the ITR SHOULD send Map-Requests through the ALT network for any EID-Prefix learned via ALT BGP. Such a configuration is expected to be very rare, since there is little benefit to using a Map-Resolver if an ITR is already using LISP-ALT. There would be, for example, no need for such an ITR to send a Map-Request to a possibly non-existent EID (and rely on Negative Map-Replies) if it can consult the ALT database to verify that an EID-Prefix is present before sending that Map-Request.
ITRは、MAP-Resolverを使用し、LISP-ALT論理ネットワークに参加するように構成されている可能性があることに注意してください。このような状況では、ITRはALT BGPを介して学習したEID-PrefixのALTネットワークを介してMAP-Requestsを送信する必要があります。ITRが既にLISP-ALTを使用している場合、MAP-Resolverを使用することにはほとんど利点がないため、このような構成は非常にまれであると予想されます。たとえば、ALTデータベースを参照してeid-prefixであることを確認することができる場合、そのようなITRが存在しない可能性のないEID（およびネガティブマップレプリーズに依存する）にMAP-Requestを送信する必要はありません。そのマップレクエストを送信する前に存在します。
An ETR publishes its EID-Prefixes on a Map-Server by sending LISP Map-Register messages. A Map-Register message includes Authentication Data, so prior to sending a Map-Register message, the ETR and Map-Server MUST be configured with a pre-shared secret used to derive Map-Register authentication keys. A Map-Server's configuration SHOULD also include a list of the EID-Prefixes for which each ETR is authoritative. Upon receipt of a Map-Register from an ETR, a Map-Server accepts only EID-Prefixes that are configured for that ETR. Failure to implement such a check would leave the Mapping System vulnerable to trivial EID-Prefix hijacking attacks.
ETRは、LISP Map-Registerメッセージを送信することにより、Map-ServerでEid-Prefixesを公開します。Map-Registerメッセージには認証データが含まれているため、Map-Registerメッセージを送信する前に、ETRとMap-Serverは、Map-Register認証キーの導出に使用される事前共有秘密で構成する必要があります。Map-Serverの構成には、各ETRが権威あるEID-Prefixesのリストも含める必要があります。ETRからマップ登録を受け取ると、MAPサーバーはそのETR用に構成されたEID-PREFIXのみを受け入れます。このようなチェックの実装に失敗すると、マッピングシステムが些細なEid-Prefixハイジャック攻撃に対して脆弱になります。
In addition to the set of EID-Prefixes defined for each ETR that may register, a Map-Server is typically also configured with one or more aggregate prefixes that define the part of the EID numbering space assigned to it. When LISP-ALT is the database in use, aggregate EID-Prefixes are implemented as discard routes and advertised into ALT BGP. The existence of aggregate EID-Prefixes in a Map-Server's database means that it may receive Map-Requests for EID-Prefixes that match an aggregate but do not match a registered prefix; Section 8.3 describes how this is handled.
登録する可能性のある各ETRに対して定義されたEid-Prefixesのセットに加えて、マップサーバーは通常、それに割り当てられたEid番号のスペースの一部を定義する1つ以上の集約接続プレフィックスで構成されます。LISP-ALTが使用されているデータベースである場合、集約EID-PREFIXESは廃棄ルートとして実装され、ALT BGPに宣伝されます。Map-Serverのデータベースに集約されたEid-Prefixesが存在することは、集計と一致するが登録されたプレフィックスと一致しないEid-PrefixesのMap-Requestsを受信することを意味します。セクション8.3では、これがどのように処理されるかについて説明します。
Map-Register messages are sent periodically from an ETR to a Map-Server with a suggested interval between messages of one minute. A Map-Server SHOULD time out and remove an ETR's registration if it has not received a valid Map-Register message within the past three minutes. When first contacting a Map-Server after restart or changes to its EID-to-RLOC database mappings, an ETR MAY initially send Map-Register messages at an increased frequency, up to one every 20 seconds. This "quick registration" period is limited to five minutes in duration.
Map-Registerメッセージは、1分間のメッセージ間に推奨される間隔を持つETRからマップサーバーに定期的に送信されます。マップサーバーは、過去3分以内に有効なマップ登録メッセージを受信していない場合、ETRの登録をタイムアウトして削除する必要があります。再起動後にマップサーバーに最初に連絡するとき、またはEIDからRLOCデータベースマッピングの変更を変更すると、ETRは最初に20秒ごとに最大1つの周波数でマップ登録メッセージを送信する場合があります。この「クイック登録」期間は、期間が5分に制限されています。
An ETR MAY request that a Map-Server explicitly acknowledge receipt and processing of a Map-Register message by setting the "want-map-notify" (M-bit) flag. A Map-Server that receives a Map-Register with this flag set will respond with a Map-Notify message. Typical use of this flag by an ETR would be to set it for Map-Register messages sent during the initial "quick registration" with a Map-Server but then set it only occasionally during steady-state maintenance of its association with that Map-Server. Note that the Map-Notify message is sent to UDP destination port 4342, not to the source port specified in the original Map-Register message.
ETRは、マップサーバーが「Want-Map-Notify」（MBIT）フラグを設定することにより、マップ登録メッセージの領収書と処理を明示的に確認することを要求する場合があります。このフラグセットでマップレジスターを受信するマップサーバーは、Map-Notifyメッセージで応答します。ETRによるこのフラグの典型的な使用は、最初の「クイック登録」中にMap-Serverを使用して送信されたMap-Registerメッセージに設定することですが、そのマップサーバーとの関連の定常状態のメンテナンス中にたまにのみ設定することです。。Map-Notifyメッセージは、元のMap-Registerメッセージで指定されたソースポートにはなく、UDP宛先ポート4342に送信されることに注意してください。
Note that a one-minute minimum registration interval during maintenance of an ETR-Map-Server association places a lower bound on how quickly and how frequently a mapping database entry can be updated. This may have implications for what sorts of mobility can be supported directly by the Mapping System; shorter registration intervals or other mechanisms might be needed to support faster mobility in some cases. For a discussion on one way that faster mobility may be implemented for individual devices, please see [LISP-MN].
ETR-Map-Server Associationのメンテナンス中の1分間の最小登録間隔は、マッピングデータベースエントリを更新できる速さと頻度の速度と頻度の下限を設けていることに注意してください。これは、マッピングシステムによって直接サポートできるモビリティの種類に影響を与える可能性があります。場合によっては、より速いモビリティをサポートするには、登録間隔またはその他のメカニズムが必要になる場合があります。個々のデバイスに対してより速いモビリティを実装できるという1つの方法についての議論については、[LISP-MN]を参照してください。
An ETR MAY also request, by setting the "proxy Map-Reply" flag (P-bit) in the Map-Register message, that a Map-Server answer Map-Requests instead of forwarding them to the ETR. See Section 7.1 for details on how the Map-Server sets certain flags (such as those indicating whether the message is authoritative and how returned Locators SHOULD be treated) when sending a Map-Reply on behalf of an ETR. When an ETR requests proxy reply service, it SHOULD include all RLOCs for all ETRs for the EID-Prefix being registered, along with the routable flag ("R-bit") setting for each RLOC. The Map-Server includes all of this information in Map-Reply messages that it sends on behalf of the ETR. This differs from a non-proxy registration, since the latter need only provide one or more RLOCs for a Map-Server to use for forwarding Map-Requests; the registration information is not used in Map-Replies, so it being incomplete is not incorrect.
ETRは、Map-Registerメッセージに「Proxy Map-Reply」フラグ（Pビット）を設定することにより、Map-ServerがETRに転送する代わりにMap-Requestに回答することを要求することもできます。Map-Serverが特定のフラグを設定する方法の詳細については、ETRに代わってマップ応答を送信する際の特定のフラグ（メッセージが権威あるかどうか、返されたロケーターをどのように扱うべきかを示すなど）を参照してください。ETRがプロキシ応答サービスを要求する場合、登録されているEID-PREFIXのすべてのETRのすべてのRLOCを、各RLOCのルータブルフラグ（「Rビット」）設定とともに含める必要があります。Map-Serverには、ETRに代わって送信されるMap-Replyメッセージにこのすべての情報が含まれています。これは、非プロキシ登録とは異なります。後者の必要性は、Map-Requestsを転送するために使用するためにMap-Serverが1つ以上のRLOCしか提供しないためです。登録情報はマップレプリーで使用されていないため、不完全であることは間違っていません。
An ETR that uses a Map-Server to publish its EID-to-RLOC mappings does not need to participate further in the mapping database protocol(s). When using a LISP-ALT mapping database, for example, this means that the ETR does not need to implement GRE or BGP, which greatly simplifies its configuration and reduces its cost of operation.
Map-Serverを使用してEid-to-RLOCマッピングを公開するETRは、マッピングデータベースプロトコルにさらに参加する必要はありません。たとえば、LISP-ALTマッピングデータベースを使用する場合、これはETRがGREまたはBGPを実装する必要がないことを意味します。これにより、構成が大幅に簡素化され、運用コストが削減されます。
Note that use of a Map-Server does not preclude an ETR from also connecting to the mapping database (i.e., it could also connect to the LISP-ALT network), but doing so doesn't seem particularly useful, as the whole purpose of using a Map-Server is to avoid the complexity of the mapping database protocols.
マップサーバーの使用は、ETRがマッピングデータベースに接続することを妨げるものではないことに注意してください（つまり、LISP-ALTネットワークに接続することもできます）が、そうすることは特に有用ではないようです。マップサーバーを使用することは、マッピングデータベースプロトコルの複雑さを回避するためです。
Once a Map-Server has EID-Prefixes registered by its client ETRs, it can accept and process Map-Requests for them.
マップサーバーがクライアントETRによって登録されているEID-PREFIXESを持っていると、マップリケストを受け入れて処理できます。
In response to a Map-Request, the Map-Server first checks to see if the destination EID matches a configured EID-Prefix. If there is no match, the Map-Server returns a Negative Map-Reply with action code "Natively-Forward" and a 15-minute TTL. This can occur if a Map-Request is received for a configured aggregate EID-Prefix for which no more-specific EID-Prefix exists; it indicates the presence of a non-LISP "hole" in the aggregate EID-Prefix.
Map-Requestに応じて、Map-Serverは最初にチェックして、宛先EIDが構成されたEid-Prefixと一致するかどうかを確認します。一致していない場合、マップサーバーは、アクションコード「ネイティブにフォワード」と15分間のTTLを使用して、ネガティブマップ応答を返します。これは、より特異的なEid-Prefixが存在しない構成された集約eid-Prefixに対してMAP-Requestを受信した場合に発生する可能性があります。これは、総eid-prefixに非リスプの「穴」が存在することを示しています。
Next, the Map-Server checks to see if any ETRs have registered the matching EID-Prefix. If none are found, then the Map-Server returns a Negative Map-Reply with action code "Natively-Forward" and a 1-minute TTL.
次に、Map-Serverがチェックして、ETRが一致するEid-Prefixを登録しているかどうかを確認します。何も見つかっていない場合、マップサーバーは、アクションコード「ネイティブにフォワード」と1分間のTTLを使用して、ネガティブマップ応答を返します。
If the EID-Prefix is either registered or not registered to the Mapping System and there is a policy in the Map-Server to have the requester drop packets for the matching EID-Prefix, then a Drop/ Policy-Denied action is returned. If the EID-Prefix is registered or not registered and there is an authentication failure, then a Drop/ Auth-Failure action is returned. If either of these actions results as a temporary state in policy or authentication, then a Send-Map-Request action with a 1-minute TTL MAY be returned to allow the requester to retry the Map-Request.
Eid-Prefixがマッピングシステムに登録されているか、マッピングシステムに登録されていない場合、マップサーバーには、一致するEid-Prefixのリクエスタードロップパケットを持つポリシーがある場合、ドロップ/ポリシーが除外されたアクションが返されます。Eid-Prefixが登録されているか、登録されていない場合、認証障害がある場合、ドロップ/認証対策アクションが返されます。これらのアクションのいずれかがポリシーまたは認証における一時的な状態として生じる場合、リクエスターがマップリケストを再試行できるように、1分間のTTLを使用した送信マップリクエストアクションが返される場合があります。
If any of the registered ETRs for the EID-Prefix have requested proxy reply service, then the Map-Server answers the request instead of forwarding it. It returns a Map-Reply with the EID-Prefix, RLOCs, and other information learned through the registration process.
Eid-Prefixの登録されたETRのいずれかがプロキシ返信サービスを要求している場合、Map-Serverはそれを転送する代わりにリクエストに答えます。Eid-Prefix、RLOCS、および登録プロセスを通じて学んだその他の情報を使用してマップ応答を返します。
If none of the ETRs have requested proxy reply service, then the Map-Server re-encapsulates and forwards the resulting Encapsulated Map-Request to one of the registered ETRs. It does not otherwise alter the Map-Request, so any Map-Reply sent by the ETR is returned to the RLOC in the Map-Request, not to the Map-Server. Unless also acting as a Map-Resolver, a Map-Server should never receive Map-Replies; any such messages SHOULD be discarded without response, perhaps accompanied by the logging of a diagnostic message if the rate of Map-Replies is suggestive of malicious traffic.
ETRがプロキシ応答サービスを要求していない場合、Map-Serverは、結果のカプセル化されたMap-Requestを登録されたETRのいずれかに再発行して転送します。それ以外の場合は、Map-Requestを変更するわけではないため、ETRから送信されたマップから送信されたマップは、Map-Serverではなく、Map-RequestのRLOCに返されます。地図販売業者としても機能しない限り、地図のサーバーは決してマップレプリーを受け取るべきではありません。このようなメッセージは、マップレプリーのレートが悪意のあるトラフィックを示唆している場合、おそらく診断メッセージのログを伴うことを伴うもので、応答せずに破棄する必要があります。
Upon receipt of an Encapsulated Map-Request, a Map-Resolver decapsulates the enclosed message and then searches for the requested EID in its local database of mapping entries (statically configured or learned from associated ETRs if the Map-Resolver is also a Map-Server offering proxy reply service). If it finds a matching entry, it returns a LISP Map-Reply with the known mapping.
カプセル化されたマップリクエストを受信すると、マップリゾルバーは囲まれたメッセージを脱カプセル化し、マッピングエントリのローカルデータベースで要求されたEIDを検索します（マップリゾルバーがマップサーバーである場合、関連するETRから静的に構成または学習しましたプロキシ返信サービスの提供）。一致するエントリが見つかった場合、既知のマッピングでLISPマップの繰り返しを返します。
If the Map-Resolver does not have the mapping entry and if it can determine that the EID is not in the mapping database (for example, if LISP-ALT is used, the Map-Resolver will have an ALT forwarding table that covers the full EID space), it immediately returns a Negative Map-Reply with action code "Natively-Forward" and a 15-minute TTL. To minimize the number of negative cache entries needed by an ITR, the Map-Resolver SHOULD return the least-specific prefix that both matches the original query and does not match any EID-Prefix known to exist in the LISP-capable infrastructure.
Map-Resolverにマッピングエントリがなく、EIDがマッピングデータベースにないことを判断できる場合（たとえば、LISP-ALTが使用されている場合、Map-Resolverには完全なカバーをカバーするALT転送テーブルがあります。Eidスペース）、アクションコード「ネイティブにフォワード」と15分間のTTLを使用して、直ちにネガティブマップ応答を返します。ITRが必要とするネガティブキャッシュエントリの数を最小限に抑えるために、MAP-Resolverは、元のクエリと一致し、LISP対応インフラストラクチャに存在することが知られているEid-Prefixと一致しない最小固有のプレフィックスを返す必要があります。
If the Map-Resolver does not have sufficient information to know whether the EID exists, it needs to forward the Map-Request to another device that has more information about the EID being requested. To do this, it forwards the unencapsulated Map-Request, with the original ITR RLOC as the source, to the mapping database system. Using LISP-ALT, the Map-Resolver is connected to the ALT network and sends the Map-Request to the next ALT hop learned from its ALT BGP neighbors. The Map-Resolver does not send any response to the ITR; since the source RLOC is that of the ITR, the ETR or Map-Server that receives the Map-Request over the ALT and responds will do so directly to the ITR.
Map-ResolverにEIDが存在するかどうかを知るのに十分な情報がない場合、要求されているEIDに関するより多くの情報を持っている別のデバイスにMap-Requestを転送する必要があります。これを行うには、元のITR RLOCをソースとして、マッピングデータベースシステムに、カプセル化されていないマップレクエストを転送します。LISP-ALTを使用して、MAP-ResolverはALTネットワークに接続されており、ALT BGPの隣人から学んだ次のALTホップにMAP-REQUESTを送信します。Map-Resolverは、ITRへの応答を送信しません。ソースRLOCはITRのRLOCであるため、ALTを介してMAP-Requestを受信して応答するETRまたはMAPサーバーは、ITRに直接行います。
A Map-Resolver can be set up to use "anycast", where the same address is assigned to multiple Map-Resolvers and is propagated through IGP routing, to facilitate the use of a topologically close Map-Resolver by each ITR.
マップリゾルバーをセットアップして、「Anycast」を使用することができます。このアドレスは、複数のMAP-Resolversに割り当てられ、IGPルーティングを通じて伝播され、各ITRがトポロジカルに近いマップ収集者の使用を容易にします。
ETRs MAY have anycast RLOC addresses that are registered as part of their RLOC-Set to the Mapping System. However, registrations MUST use their unique RLOC addresses, distinct authentication keys, or different xTR-IDs to identify security associations with the Map-Servers.
ETRには、マッピングシステムへのRLOC-SETの一部として登録されているAnyCast RLOCアドレスがある場合があります。ただし、登録は、マップサーバーとのセキュリティ関連を特定するには、一意のRLOCアドレス、個別の認証キー、または異なるXTR-IDを使用する必要があります。
A LISP threat analysis can be found in [RFC7835]. Here, we highlight security considerations that apply when LISP is deployed in environments such as those specified in Section 1.1, where the following assumptions hold:
LISP脅威分析は[RFC7835]に記載されています。ここでは、次の仮定が保持されているセクション1.1で指定されているものなどの環境にLISPが展開されている場合に適用されるセキュリティ上の考慮事項を強調します。
1. The Mapping System is secure and trusted, and for the purpose of these security considerations, the Mapping System is considered as one trusted element.
1. マッピングシステムは安全で信頼されており、これらのセキュリティに関する考慮事項の目的のために、マッピングシステムは信頼できる要素の1つと見なされます。
2. The ETRs have a preconfigured trust relationship with the Mapping System, including some form of shared secret. The Mapping System is aware of which EIDs an ETR can advertise. How those keys and mappings are established is out of scope for this document.
2. ETRは、何らかの形の共有秘密を含む、マッピングシステムとの事前に構成された信頼関係を持っています。マッピングシステムは、ETRが宣伝できるEidsがどのEidsが宣伝できるかを認識しています。これらのキーとマッピングの確立方法は、このドキュメントの範囲外です。
3. LISP-SEC [RFC9303] MUST be implemented. Network operators should carefully weigh how the LISP-SEC threat model applies to their particular use case or deployment. If they decide to ignore a particular recommendation, they should make sure the risk associated with the corresponding threats is well understood.
3. LISP-SEC [RFC9303]を実装する必要があります。ネットワークオペレーターは、LISP-SECの脅威モデルが特定のユースケースまたは展開にどのように適用されるかを慎重に検討する必要があります。特定の推奨事項を無視することにした場合、対応する脅威に関連するリスクがよく理解されていることを確認する必要があります。
The Map-Request/Map-Reply message exchange can be exploited by an attacker to mount DoS and/or amplification attacks. Attackers can send Map-Requests at high rates to overload LISP nodes and increase the state maintained by such nodes or consume CPU cycles. Such threats can be mitigated by systematically applying filters and rate limiters.
Map-Request/Map-Replyメッセージ交換は、攻撃者によってDOSのマウントおよび/または増幅攻撃に悪用される可能性があります。攻撃者は、LISPノードをオーバーロードして、そのようなノードによって維持されている状態を増やしたり、CPUサイクルを消費したりするために、高速でマップリケストを送信できます。このような脅威は、フィルターとレートのリミッターを体系的に適用することで軽減できます。
The Map-Request/Map-Reply message exchange can also be exploited to inject forged mappings directly into the ITR EID-to-RLOC Map-Cache. This can lead to traffic being redirected to the attacker; see further details in [RFC7835]. In addition, valid ETRs in the system can perform overclaiming attacks. In this case, attackers can claim to own an EID-Prefix that is larger than the prefix owned by the ETR. Such attacks can be addressed by using LISP-SEC [RFC9303]. The LISP-SEC protocol defines a mechanism for providing origin authentication, integrity protection, and prevention of 'man-in-the-middle' and 'prefix overclaiming' attacks on the Map-Request/Map-Reply exchange. In addition, and while beyond the scope of securing an individual Map-Server or Map-Resolver, it should be noted that LISP-SEC can be complemented by additional security mechanisms defined by the Mapping System infrastructure. For instance, BGP-based LISP-ALT [RFC6836] can take advantage of standards work on adding security to BGP, while LISP-DDT [RFC8111] defines its own additional security mechanisms.
Map-Request/Map-Reply Message Exchangeを悪用して、鍛造マッピングをITR EIDからRLOCマップキャッシュに直接注入することもできます。これにより、トラフィックが攻撃者にリダイレクトされる可能性があります。 [RFC7835]の詳細を参照してください。さらに、システム内の有効なETRは、オーバークレーム攻撃を実行できます。この場合、攻撃者は、ETRが所有する接頭辞よりも大きいEid-Prefixを所有していると主張できます。このような攻撃は、LISP-SEC [RFC9303]を使用して対処できます。 LISP-SECプロトコルは、Map-Request/Map-Reply Exchangeに対する「Man-in-the-Middle」および「Man-in-the-Middle」および「Overclaiming」攻撃の原点認証、整合性保護、および予防を提供するためのメカニズムを定義します。さらに、個々のマップサーバーまたはマップ再分解体を保護する範囲を超えている間、マッピングシステムインフラストラクチャによって定義された追加のセキュリティメカニズムによってLISP-SECが補完できることに注意する必要があります。たとえば、BGPベースのLISP-ALT [RFC6836]は、BGPにセキュリティを追加する標準作業を活用できますが、LISP-DDT [RFC8111]は独自の追加のセキュリティメカニズムを定義します。
To publish an authoritative EID-to-RLOC mapping with a Map-Server using the Map-Register message, an ETR includes Authentication Data that is a MAC of the entire message using a key derived from the pre-shared secret. An implementation SHOULD support HMAC-SHA256- 128+HKDF-SHA256 [RFC5869]. The Map-Register message includes protection against replay attacks by a man in the middle. However, there is a potential attack where a compromised ETR could overclaim the prefix it owns and successfully register it on its corresponding Map-Server. To mitigate this, as noted in Section 8.2, a Map-Server MUST verify that all EID-Prefixes registered by an ETR match the configuration stored on the Map-Server.
Map-Registerメッセージを使用してMAP-SERVERを使用して権威あるEIDからRLOCへのマッピングを公開するには、ETRには、事前に共有された秘密から派生したキーを使用して、メッセージ全体のMACである認証データが含まれています。実装は、HMAC-SHA256-128 HKDF-SHA256 [RFC5869]をサポートする必要があります。Map-Registerメッセージには、真ん中の男性によるリプレイ攻撃に対する保護が含まれています。ただし、侵害されたETRが所有しているプレフィックスをオーバーリュートし、対応するマップサーバーに正常に登録する可能性がある潜在的な攻撃があります。これを軽減するために、セクション8.2に記載されているように、MAPサーバーは、ETRによって登録されているすべてのEID-PREFIXがマップサーバーに保存されている構成と一致することを確認する必要があります。
Deployments concerned about manipulations of Map-Request and Map-Reply messages and malicious ETR EID-Prefix overclaiming MUST drop LISP control plane messages that do not contain LISP-SEC material (S-bit, EID-AD, OTK-AD, PKT-AD). See Section 3 of [RFC9303] for definitions of "EID-AD", "OTK-AD", and "PKT-AD".
マップレクエストとマップの繰り返しメッセージの操作に関する展開、悪意のあるETR EID-PREFIXオーバーリレーティングは、LISP-SECマテリアルを含まないLISPコントロールプレーンメッセージをドロップする必要があります（S-BIT、EID-AD、OTK-AD、PKT-AD）。[eid-ad]、「otk-ad」、および「pkt-ad」の定義については、[RFC9303]のセクション3を参照してください。
Mechanisms to encrypt, support privacy, and prevent eavesdropping and packet tampering for messages exchanged between xTRs, between xTRs and the Mapping System, and between nodes that make up the Mapping System SHOULD be deployed. Examples of this are DTLS [RFC9147] or "lisp-crypto" [RFC8061].
XTRS、XTRSとマッピングシステム間、およびマッピングシステムを構成するノード間で交換されるメッセージの暗号化、プライバシーをサポートし、パケットの改ざんを防ぐメカニズムを展開する必要があります。この例は、DTL [RFC9147]または「LISP-CRYPTO」[RFC8061]です。
As noted by [RFC6973], privacy is a complex issue that greatly depends on the specific protocol use case and deployment. As noted in Section 1.1 of [RFC9300], LISP focuses on use cases where entities communicate over the public Internet while keeping separate addressing and topology. Here, we detail the privacy threats introduced by the LISP control plane; the analysis is based on the guidelines detailed in [RFC6973].
[RFC6973]で述べたように、プライバシーは、特定のプロトコルの使用ケースと展開に大きく依存する複雑な問題です。[RFC9300]のセクション1.1で述べたように、LISPは、エンティティがパブリックインターネットを介して通信しながら、個別のアドレス指定とトポロジを維持するユースケースに焦点を当てています。ここでは、LISPコントロールプレーンによって導入されたプライバシーの脅威について詳しく説明します。分析は、[RFC6973]で詳述されているガイドラインに基づいています。
LISP can use long-lived identifiers (EIDs) that survive mobility events. Such identifiers bind to the RLOCs of the nodes. The RLOCs represent the topological location with respect to the specific LISP deployments. In addition, EID-to-RLOC mappings are typically considered public information within the LISP deployment when control plane messages are not encrypted and can be eavesdropped while Map-Request messages are sent to the corresponding Map-Resolvers or Map-Register messages to Map-Servers.
LISPは、モビリティイベントに耐える長寿命識別子（EID）を使用できます。このような識別子は、ノードのRLOCにバインドします。RLOCは、特定のLISP展開に関してトポロジカル位置を表します。さらに、コントロールプレーンのメッセージが暗号化されていない場合、Eid-to-RLOCマッピングは通常、LISP展開内の公開情報と見なされ、MAP-Requestメッセージが対応するMap-ResolversまたはMap-RegisterメッセージにMap-Registerメッセージに送信されている間、盗聴できます。サーバー。
In this context, attackers can correlate the EID with the RLOC and track the corresponding user topological location and/or mobility. This can be achieved by off-path attackers, if they are authenticated, by querying the Mapping System. Deployments concerned about this threat can use access control lists or stronger authentication mechanisms [ECDSA-AUTH] in the Mapping System to make sure that only authorized users can access this information (data minimization). Use of ephemeral EIDs [EID-ANONYMITY] to achieve anonymity is another mechanism to lessen persistency and identity tracking.
これに関連して、攻撃者はEIDをRLOCと相関させ、対応するユーザーのトポロジカル位置および/またはモビリティを追跡できます。これは、マッピングシステムを照会することにより、認証されている場合、オフパス攻撃者が実現できます。この脅威に関係する展開は、マッピングシステムでアクセス制御リストまたはより強力な認証メカニズム[ECDSA-AUTH]を使用して、認定ユーザーのみがこの情報（データの最小化）にアクセスできるようにすることができます。匿名性を達成するためには、EPHEMERAL EIDS [EID-Anonymity]の使用は、持続性とアイデンティティ追跡を軽減するもう1つのメカニズムです。
For implementation considerations, the following major changes have been made to this document since [RFC6830] and [RFC6833] were published:
実装に関する考慮事項のために、[RFC6830]と[RFC6833]が公開されて以来、次の主要な変更がこのドキュメントに行われました。
* The 16-bit 'Key ID' field of the Map-Register and Map-Notify messages as defined in [RFC6830] has been split into an 8-bit 'Key ID' field and an 8-bit 'Algorithm ID' field. Note that this change also applies to the Map-Notify-Ack message defined by this document. See Sections 5.6 and 5.7.
* [RFC6830]で定義されているマップレジスターおよびMap-Notifyメッセージの16ビット「キーID」フィールドは、8ビット「キーID」フィールドと8ビットの「アルゴリズムID」フィールドに分割されています。この変更は、このドキュメントで定義されたMap-notify-ackメッセージにも適用されることに注意してください。セクション5.6および5.7を参照してください。
* This document defines a Map-Notify-Ack message to provide reliability for Map-Notify messages. Any receiver of a Map-Notify message must respond with a Map-Notify-Ack message. Map-Servers who are senders of Map-Notify messages must queue the Map-Notify contents until they receive a Map-Notify-Ack with the nonce used in the Map-Notify message. Note that implementations for Map-Notify-Ack support already exist and predate this document.
* このドキュメントでは、Map-notify-notifyメッセージの信頼性を提供するMap-notify-ackメッセージを定義します。Map-notifyメッセージの受信者は、Map-notify-ackメッセージで応答する必要があります。Map-notifyメッセージの送信者であるMap-Serversは、Map-notifyメッセージで使用されているNonCEを使用してMap-notify-ackを受信するまで、Map-notifyコンテンツをキューする必要があります。Map-notify-ackサポートの実装はすでに存在し、このドキュメントに先行することに注意してください。
* This document has incorporated the codepoint for the Map-Referral message from the LISP-DDT specification [RFC8111] to indicate that a Map-Server must send the final Map-Referral message when it participates in the LISP-DDT Mapping System procedures.
* このドキュメントには、LISP-DDT仕様[RFC8111]からのマップ参照メッセージのCodePointが組み込まれており、LISP-DDTマッピングシステムの手順に参加したときにマップサーバーが最終的なMAP参照メッセージを送信する必要があることを示します。
* Bits L and D have been added to the Map-Request message. See Section 5.3 for details.
* ビットLとDは、マップレクエストメッセージに追加されました。詳細については、セクション5.3を参照してください。
* Bits S, I, E, T, a, R, and M have been added to the Map-Register message. See Section 5.6 for details.
* ビットs、i、e、t、a、r、およびmは、マップ登録メッセージに追加されました。詳細については、セクション5.6を参照してください。
* The nonce and the Authentication Data in the Map-Register message each behave differently; see Section 5.6 for details.
* Map-RegisterメッセージのNONCEと認証データはそれぞれ異なって動作します。詳細については、セクション5.6を参照してください。
* This document adds two new action values that are in an EID-Record that appears in Map-Reply, Map-Register, Map-Notify, and Map-Notify-Ack messages. These new action values are Drop/Policy-Denied and Drop/Auth-Failure. See Section 5.4 for details.
* このドキュメントには、Map-Reply、Map-Register、Map-Notify、およびMap-Notify-ackメッセージに表示されるEid-Recordにある2つの新しいアクション値が追加されます。これらの新しいアクション値は、ドロップ/ポリシーが除外され、ドロップ/認証を受けます。詳細については、セクション5.4を参照してください。
This section provides guidance to IANA regarding registration of values related to this LISP control plane specification, in accordance with BCP 26 [RFC8126].
このセクションでは、BCP 26 [RFC8126]に従って、このLISPコントロールプレーンの仕様に関連する値の登録に関するIANAへのガイダンスを提供します。
* LISP IANA registry allocations should not be made for purposes unrelated to LISP routing or transport protocols.
* LISP IANAレジストリの割り当ては、LISPルーティングまたは輸送プロトコルとは無関係の目的のために作成されるべきではありません。
* The following policies are used here with the meanings defined in BCP 26 [RFC8126]: "Specification Required", "IETF Review", "Experimental Use", and "First Come First Served".
* ここでは、BCP 26 [RFC8126]で定義されている意味で次のポリシーが使用されています。「仕様が必要」、「IETFレビュー」、「実験使用」、および「最初に来る」。
There are three namespaces (listed in the sub-sections below) in LISP that have been registered (see [RFC9299].
登録されているLISPには、3つの名前空間（下のサブセクションにリストされています）があります（[RFC9299]を参照してください。
IANA allocated UDP port number 4342 for the LISP control plane. IANA has updated the description for UDP port 4342 to reflect the following:
IANAは、LISPコントロールプレーンにUDPポート番号4342を割り当てました。IANAは、UDPポート4342の説明を更新して、以下を反映しています。
+==============+=============+===========+==============+===========+
| Service Name | Port | Transport | Description | Reference |
| | Number | Protocol | | |
+==============+=============+===========+==============+===========+
| lisp-control | 4342 | udp | LISP Control | RFC 9301 |
| | | | Packets | |
+--------------+-------------+-----------+--------------+-----------+
Table 2
表2
IANA is now authoritative for LISP Packet Type definitions, so they have replaced the registry references to [RFC6830] with references to this document.
IANAは現在、LISPパケットタイプの定義に対して権威あるため、[RFC6830]へのレジストリ参照をこのドキュメントへの参照に置き換えました。
Based on deployment experience related to [RFC6830], the Map-Notify-Ack message (message type 5) is defined in this document. IANA has registered it in the "LISP Packet Types" registry.
[RFC6830]に関連する展開エクスペリエンスに基づいて、Map-Notify-ackメッセージ（メッセージタイプ5）はこのドキュメントで定義されています。IANAは、「LISPパケットタイプ」レジストリに登録しています。
+=====================+======+===========+
| Message | Code | Reference |
+=====================+======+===========+
| LISP Map-Notify-Ack | 5 | RFC 9301 |
+---------------------+------+-----------+
Table 3
表3
New ACT values can be allocated through IETF Review or IESG Approval. Four values have already been allocated by [RFC6830]. IANA has replaced the reference pointing to [RFC6830] to point to this document. This specification changes the Action name of value 3 from "Drop" to "Drop/No-Reason". It also adds the following new ACT values.
新しいACT値は、IETFレビューまたはIESGの承認を通じて割り当てることができます。[RFC6830]によって4つの値がすでに割り当てられています。IANAは、[RFC6830]を指す参照を置き換えて、このドキュメントを指しています。この仕様は、値3のアクション名を「ドロップ」から「ドロップ/ノーリーズン」に変更します。また、次の新しいACT値を追加します。
+=======+===============+=============================+===========+
| Value | Action | Description | Reference |
+=======+===============+=============================+===========+
| 4 | Drop/Policy- | A packet matching this Map- | RFC 9301 |
| | Denied | Cache entry is dropped | |
| | | because the target EID is | |
| | | policy-denied by the xTR or | |
| | | the Mapping System. | |
+-------+---------------+-----------------------------+-----------+
| 5 | Drop/Auth- | A packet matching this Map- | RFC 9301 |
| | Failure | Cache entry is dropped | |
| | | because the Map-Request for | |
| | | the target EID fails an | |
| | | authentication check by the | |
| | | xTR or the Mapping System. | |
+-------+---------------+-----------------------------+-----------+
Table 4: LISP Map-Reply Action Values
表4：LISP Map-Replyアクション値
In addition, LISP has a number of flag fields and reserved fields, such as the flags of the LISP header fields [RFC9300]. New bits for flags in these fields can be implemented after IETF Review or IESG Approval, but these need not be managed by IANA.
さらに、LISPには、LISPヘッダーフィールドのフラグ[RFC9300]など、多くのフラグフィールドと予約フィールドがあります。これらのフィールドのフラグの新しいビットは、IETFレビューまたはIESGの承認後に実装できますが、これらはIANAによって管理する必要はありません。
LISP Canonical Address Format (LCAF) [RFC8060] has an 8-bit Type field that defines LISP-specific encodings for AFI value 16387. LCAF encodings are used for specific use cases where different address types for EID-Records and RLOC-Records are required.
LISP Canonical Address Format（LCAF）[RFC8060]には、AFI値16387のLISP固有のエンコーディングを定義する8ビット型フィールドがあります。LCAFエンコーディングは、EID-RECORDSとRLOC-RECORDSの異なるアドレスタイプが必要な特定のユースケースに使用されます。。
The "LISP Canonical Address Format (LCAF) Types" registry is used for LCAF types. The registry for LCAF types uses the Specification Required policy [RFC8126]. Initial values for the registry as well as further information can be found in [RFC8060].
「LISP Canonical Address Format（LCAF）タイプ」レジストリは、LCAFタイプに使用されます。LCAFタイプのレジストリは、必要なポリシー[RFC8126]の仕様を使用します。レジストリの初期値と詳細情報は、[RFC8060]に記載されています。
Therefore, there is no longer a need for the "LISP Address Type Codes" registry requested by [RFC6830]. Per this document, the registry has been closed.
したがって、[RFC6830]によって要求された「LISPアドレスタイプコード」レジストリの必要はなくなりました。このドキュメントに従って、レジストリは閉じられています。
In [RFC6830], a request for a "LISP Key ID Numbers" registry was submitted. Per this document, IANA has renamed the registry to "LISP Algorithm ID Numbers" and listed this document as the registry reference.
[RFC6830]では、「LISPキーID番号」レジストリのリクエストが送信されました。このドキュメントに従って、IANAはレジストリを「LISPアルゴリズムID番号」に変更し、このドキュメントをレジストリリファレンスとしてリストしました。
The following Algorithm ID values are defined by this specification, as used in any packet type that references an 'Algorithm ID' field:
次のアルゴリズムID値は、「アルゴリズムID」フィールドを参照するパケットタイプで使用されるこの仕様によって定義されます。
+=============================+========+===========+===========+
| Name | Number | MAC | KDF |
+=============================+========+===========+===========+
| None | 0 | None | None |
+-----------------------------+--------+-----------+-----------+
| HMAC-SHA-1-96-None | 1 | [RFC2404] | None |
+-----------------------------+--------+-----------+-----------+
| HMAC-SHA-256-128-None | 2 | [RFC4868] | None |
+-----------------------------+--------+-----------+-----------+
| HMAC-SHA256-128+HKDF-SHA256 | 3 | [RFC4868] | [RFC4868] |
+-----------------------------+--------+-----------+-----------+
Table 5
表5
Number values are in the range of 0 to 255. Values are assigned on a First Come First Served basis.
数値の値は0〜255の範囲です。値は、先着順で割り当てられます。
This document asks IANA to create a registry for allocation of bits in several headers of the LISP control plane, namely in Map-Request messages, Map-Reply messages, Map-Register messages, and Encapsulated Control Messages. Bit allocations are also requested for EID-Records and RLOC-Records. The registry created should be named "LISP Control Plane Header Bits". A subregistry needs to be created per each message and EID-Record. The name of each subregistry is indicated below, along with its format and allocation of bits defined in this document. Any additional bit allocations require a specification, in accordance with policies defined in [RFC8126].
このドキュメントは、IANAに、LISPコントロールプレーンのいくつかのヘッダー、つまりMap-Requestメッセージ、Map-Replyメッセージ、Map-Registerメッセージ、およびカプセル化されたコントロールメッセージのいくつかのヘッダーにビットの割り当てのレジストリを作成するよう求めています。Eid-RecordsおよびRLOC-Recordsのビット割り当ても要求されます。作成されたレジストリには、「LISPコントロールプレーンヘッダービット」と呼ばれる必要があります。各メッセージとeid-recordごとにサブレジストリを作成する必要があります。各サブレジストリの名前は、このドキュメントで定義されているビットの形式と割り当てとともに、以下に示されています。追加のビット割り当てでは、[RFC8126]で定義されているポリシーに従って、仕様が必要です。
Subregistry: Map-Request Header Bits (Section 5.2):
サブレジストリ：Map-Requestヘッダービット（セクション5.2）：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 |A|M|P|S|p|s|R|R| Rsvd |L|D| IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+===========+===============+==============+========================+
| Spec Name | IANA Name | Bit Position | Description |
+===========+===============+==============+========================+
| A | Map-Request-A | 4 | Authoritative Bit |
+-----------+---------------+--------------+------------------------+
| M | Map-Request-M | 5 | Map Data Present Bit |
+-----------+---------------+--------------+------------------------+
| P | Map-Request-P | 6 | RLOC-Probe Request |
| | | | Bit |
+-----------+---------------+--------------+------------------------+
| S | Map-Request-S | 7 | Solicit Map-Request |
| | | | (SMR) Bit |
+-----------+---------------+--------------+------------------------+
| p | Map-Request-p | 8 | Proxy-ITR Bit |
+-----------+---------------+--------------+------------------------+
| s | Map-Request-s | 9 | Solicit Map-Request |
| | | | Invoked Bit |
+-----------+---------------+--------------+------------------------+
| L | Map-Request-L | 17 | Local xTR Bit |
+-----------+---------------+--------------+------------------------+
| D | Map-Request-D | 18 | Don't Map-Reply Bit |
+-----------+---------------+--------------+------------------------+
Table 6: LISP Map-Request Header Bits
表6：LISP Map-Requestヘッダービット
Subregistry: Map-Reply Header Bits (Section 5.4):
サブレジストリ：マップ繰り返しヘッダービット（セクション5.4）：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=2 |P|E|S| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+===========+=============+==============+========================+
| Spec Name | IANA Name | Bit Position | Description |
+===========+=============+==============+========================+
| P | Map-Reply-P | 4 | RLOC-Probe Bit |
+-----------+-------------+--------------+------------------------+
| E | Map-Reply-E | 5 | Echo-Nonce Capable Bit |
+-----------+-------------+--------------+------------------------+
| S | Map-Reply-S | 6 | Security Bit |
+-----------+-------------+--------------+------------------------+
Table 7: LISP Map-Reply Header Bits
表7：LISP Map-Replyヘッダービット
Subregistry: Map-Register Header Bits (Section 5.6):
サブレジストリ：マップ登録ヘッダービット（セクション5.6）：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3 |P|S|I| Reserved |E|T|a|R|M| Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+===========+================+==============+======================+
| Spec Name | IANA Name | Bit Position | Description |
+===========+================+==============+======================+
| P | Map-Register-P | 4 | Proxy Map-Reply Bit |
+-----------+----------------+--------------+----------------------+
| S | Map-Register-S | 5 | LISP-SEC Capable Bit |
+-----------+----------------+--------------+----------------------+
| I | Map-Register-I | 6 | xTR-ID Present Bit |
+-----------+----------------+--------------+----------------------+
Table 8: LISP Map-Register Header Bits
表8：LISPマップ登録ヘッダービット
Subregistry: Encapsulated Control Message (ECM) Header Bits (Section 5.8):
サブレジストリ：カプセル化されたコントロールメッセージ（ECM）ヘッダービット（セクション5.8）：
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=8 |S|D|E|M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+===========+===========+==============+============================+
| Spec Name | IANA Name | Bit Position | Description |
+===========+===========+==============+============================+
| S | ECM-S | 4 | Security Bit |
+-----------+-----------+--------------+----------------------------+
| D | ECM-D | 5 | LISP-DDT Bit |
+-----------+-----------+--------------+----------------------------+
| E | ECM-E | 6 | Forward to ETR Bit |
+-----------+-----------+--------------+----------------------------+
| M | ECM-M | 7 | Destined to Map- |
| | | | Server Bit |
+-----------+-----------+--------------+----------------------------+
Table 9: LISP Encapsulated Control Message (ECM) Header Bits
表9：LISPカプセル化コントロールメッセージ（ECM）ヘッダービット
Subregistry: EID-Record Header Bits (Section 5.4):
サブレジストリ：Eid-Recordヘッダービット（セクション5.4）：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Count | EID mask-len | ACT |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+===========+==============+==============+===================+
| Spec Name | IANA Name | Bit Position | Description |
+===========+==============+==============+===================+
| A | EID-Record-A | 19 | Authoritative Bit |
+-----------+--------------+--------------+-------------------+
Table 10: LISP EID-Record Header Bits
表10：Lisp Eid-Recordヘッダービット
Subregistry: RLOC-Record Header Bits (Section 5.4):
サブレジストリ：RLOC-Recordヘッダービット（セクション5.4）：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused Flags |L|p|R| Loc-AFI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+===========+===============+==============+======================+
| Spec Name | IANA Name | Bit Position | Description |
+===========+===============+==============+======================+
| L | RLOC-Record-L | 13 | Local RLOC Bit |
+-----------+---------------+--------------+----------------------+
| p | RLOC-Record-p | 14 | RLOC-Probe Reply Bit |
+-----------+---------------+--------------+----------------------+
| R | RLOC-Record-R | 15 | RLOC Reachable Bit |
+-----------+---------------+--------------+----------------------+
Table 11: LISP RLOC-Record Header Bits
表11：lisp rloc-recordヘッダービット
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November 1998, <https://www.rfc-editor.org/info/rfc2404>.
[RFC2404] Madson、C。およびR. Glenn、「ESPおよびAH内のHMAC-SHA-1-96の使用」、RFC 2404、DOI 10.17487/RFC2404、1998年11月、<https：//www.rfc-editor.org/info/rfc2404>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4086] EastLake 3rd、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、DOI 10.17487/RFC4086、2005年6月、<https：//www.rfc-editor.org/info/rfc4086>。
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, <https://www.rfc-editor.org/info/rfc4868>.
[RFC4868] Kelly、S。and S. Frankel、「HMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512を使用してIPSECを使用して」、RFC 4868、DOI 10.17487/RFC4868、2007年5月、<HTTPS：//www.rfc-editor.org/info/rfc4868>。
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>.
[RFC5869] Krawczyk、H。およびP. Eronen、「HMACベースの抽出および拡張キー誘導関数（HKDF）」、RFC 5869、DOI 10.17487/RFC5869、2010年5月、<https：//ww.rfc-editor.org/info/rfc5869>。
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, DOI 10.17487/RFC6833, January 2013, <https://www.rfc-editor.org/info/rfc6833>.
[RFC6833] Fuller、V。およびD. Farinacci、「ロケーター/ID分離プロトコル（LISP）マップサーバーインターフェイス」、RFC 6833、DOI 10.17487/RFC6833、2013年1月、<https：//www.rfc-editor.org/info/rfc6833>。
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8085] Eggert、L.、Fairhurst、G.、およびG. Shepherd、「UDP使用ガイドライン」、BCP 145、RFC 8085、DOI 10.17487/RFC8085、2017年3月、<https://www.rfc-editor.org/info/rfc8085>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126] Cotton、M.、Leiba、B。、およびT. Narten、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487/RFC8126、2017年6月、<https：// wwwwwwwwwwwwwwwwwwww.rfc-editor.org/info/rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos, Ed., "The Locator/ID Separation Protocol (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022, <https://www.rfc-editor.org/info/rfc9300>.
[RFC9300] Farinacci、D.、Fuller、V.、Meyer、D.、Lewis、D.、およびA. Cabellos、ed。、「ロケーター/ID分離プロトコル（LISP）」、RFC 9300、DOI 10.17487/RFC9300、2022年10月、<https://www.rfc-editor.org/info/rfc9300>。
[RFC9302] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 9302, DOI 10.17487/RFC9302, October 2022, <https://www.rfc-editor.org/info/rfc9302>.
[RFC9302] Iannone、L.、Sauce、D。、およびO. Bonaventure、「ロケーター/ID分離プロトコル（LISP）マップバージョン」、RFC 9302、DOI 10.17487/RFC9302、2022年10月、<https：// ww。rfc-editor.org/info/rfc9302>。
[RFC9303] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, "Locator/ID Separation Protocol Security (LISP-SEC)", RFC 9303, DOI 10.17487/RFC9303, October 2022, <https://www.rfc-editor.org/info/rfc9303>.
[RFC9303] Maino、F.、Ermagan、V.、Cabellos、A。、およびD. Sauce、「ロケーター/ID分離プロトコルセキュリティ（LISP-SEC）」、RFC 9303、DOI 10.17487/RFC9303、2022年10月、<https：//www.rfc-editor.org/info/rfc9303>。
[RFC9304] Boucadair, M. and C. Jacquenet, "Locator/ID Separation Protocol (LISP): Shared Extension Message and IANA Registry for Packet Type Allocations", RFC 9304, DOI 10.17487/RFC9304, October 2022, <https://www.rfc-editor.org/info/rfc9304>.
[RFC9304] Boucadair、M。and C. Jacquenet、「ロケーター/ID分離プロトコル（LISP）：パケットタイプの割り当ての共有拡張メッセージとIANAレジストリ」、RFC 9304、DOI 10.17487/RFC9304、2022年10月、<https：//www.rfc-editor.org/info/rfc9304>。
[AFN] IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers/>.
[AFN] IANA、「Family Numbers」、<http://www.iana.org/assignments/address-family-numbers/>。
[ECDSA-AUTH] Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA Authentication and Authorization", Work in Progress, Internet-Draft, draft-ietf-lisp-ecdsa-auth-09, 11 September 2022, <https://datatracker.ietf.org/doc/html/ draft-ietf-lisp-ecdsa-auth-09>.
[ECDSA-AUTH] FARINACCI、D。およびE. NORDMARK、「LISP Control-Plane-Plane ECDSA認証と承認」、Work in Progress、Internet-Draft、Draft-IITF-LISP-ECDSA-AUTH-09、2022年9月11日、<<https://datatracker.ietf.org/doc/html/ draft-ietf-lisp-ecdsa-auth-09>。
[EID-ANONYMITY] Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP EID Anonymity", Work in Progress, Internet-Draft, draft-ietf-lisp-eid-anonymity-13, 11 September 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-eid-anonymity-13>.
[Eid-Anonymity] Farinacci、D.、Pillay-Esnault、P。、およびW. Haddad、「Lisp eid匿名性」、作業中の作業、インターネットドラフト、ドラフト-ITEF-LISP-EID-Anonymity-13、9月11日2022、<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-eid-anonymity-13>。
[EID-MOBILITY] Portoles, M., Ashtaputre, V., Maino, F., Moreno, V., and D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified Control Plane", Work in Progress, Internet-Draft, draft-ietf-lisp-eid-mobility-10, 10 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-eid-mobility-10>.
[Eid-Mobility] Portoles、M.、Ashtaputre、V.、Maino、F.、Moreno、V.、およびD. Farinacci、「統合コントロールプレーンを使用したLisp L2/L3 Eidモビリティ」、進行中の作業、インターネット - ドラフト、ドラフト-ITEP-LISP-EID-Mobility-10、2022年7月10日、<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-eid-mobility-10>。
[GTP-3GPP] 3GPP, "General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)", TS.29.281, June 2022, <https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx?specificationId=1699>.
[GTP-3GPP] 3GPP、「一般的なパケット無線システム（GPRS）トンネリングプロトコルユーザープレーン（GTPV1-U）」、Ts.29.281、2022年6月、<https://portal.3gpp.org/desktopmodules/specifications/仕様。aspx？specificationid = 1699>。
[INTAREA-ILA] Herbert, T. and P. Lapukhov, "Identifier-locator addressing for IPv6", Work in Progress, Internet-Draft, draft-herbert-intarea-ila-01, 5 March 2018, <https://datatracker.ietf.org/doc/html/draft-herbert-intarea-ila-01>.
[INTAREA-ILA] Herbert、T。およびP. Lapukhov、「IPv6の識別子ドレッシング」、進行中の作業、インターネットドラフト、Draft-Herbert-Intarea-ILA-01、2018年3月5日、<https：//datatracker.ietf.org/doc/html/draft-herbert-intarea-ila-01>。
[LISP-MN] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Mobile Node", Work in Progress, Internet-Draft, draft-ietf-lisp-mn-12, 24 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-mn-12>.
[lisp-mn] Farinacci、D.、Lewis、D.、Meyer、D.、およびC. White、 "Lisp Mobile Node"、Work in Progress、Internet-Draft、Draft-Itef-Lisp-MN-12、242022年7月、<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-mn-12>。
[LISP-PUBSUB] Rodriguez-Natal, A., Ermagan, V., Cabellos-Aparicio, A., Barkai, S., and M. Boucadair, "Publish/Subscribe Functionality for LISP", Work in Progress, Internet-Draft, draft-ietf-lisp-pubsub-09, 28 June 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-09>.
[Lisp-Pubsub] Rodriguez-Natal、A.、Ermagan、V.、Cabellos-Aparicio、A.、Barkai、S。、およびM. Boucadair、「LISPの機能を公開/購読する」、進行中の作業、インターネットドラフト、ドラフト-ITEF-LISP-PUBSUB-09、2021年6月28日、<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-09>。
[NVO3-VXLAN-GPE] Maino, F., Ed., Kreeger, L., Ed., and U. Elzur, Ed., "Generic Protocol Extension for VXLAN (VXLAN-GPE)", Work in Progress, Internet-Draft, draft-ietf-nvo3-vxlan-gpe-12, 22 September 2021, <https://datatracker.ietf.org/doc/html/ draft-ietf-nvo3-vxlan-gpe-12>.
[NVO3-VXLAN-GPE] Maino、F.、ed。、Kreeger、L.、Ed。、およびU. Elzur、ed。、「Vxlan（Vxlan-GPE）の汎用プロトコル拡張」、進行中の作業、インターネット - ドラフト、ドラフト-ITETF-NVO3-VXLAN-GPE-12、2021年9月22日、<https://datatracker.ietf.org/doc/html/ draft-ietf-nvo3-vxlan-gpe-12>。
[OPSEC-ICMP-FILTER] Gont, F., Gont, G., and C. Pignataro, "Recommendations for filtering ICMP messages", Work in Progress, Internet-Draft, draft-ietf-opsec-icmp-filtering-04, 3 July 2013, <https://datatracker.ietf.org/doc/html/draft-ietf-opsec-icmp-filtering-04>.
[Opsec-Icmp-filter] Gont、F.、Gont、G。、およびC. Pignataro、「ICMPメッセージのフィルタリングに関する推奨事項」、進行中の作業、インターネットドラフト、Draft-IITF-OPSEC-ICMP-FILTERING-04、2013年7月3日、<https://datatracker.ietf.org/doc/html/draft-ietf-opsec-filtering-04>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、DOI 10.17487/RFC1035、1987年11月、<https://www.rfc-editor.org/info/rfc1035>
[RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the Internet checksum", RFC 1071, DOI 10.17487/RFC1071, September 1988, <https://www.rfc-editor.org/info/rfc1071>.
[RFC1071] Braden、R.、Borman、D。、およびC. Partridge、「Internet Checkumのコンピューティング」、RFC 1071、DOI 10.17487/RFC1071、1988年9月、<https://www.rfc-editor.org/info/RFC1071>。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, DOI 10.17487/RFC2890, September 2000, <https://www.rfc-editor.org/info/rfc2890>.
[RFC2890] Dommety、G。、「Key and Sequence Number GREへの拡張」、RFC 2890、DOI 10.17487/RFC2890、2000年9月、<https://www.rfc-editor.org/info/rfc2890>
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, DOI 10.17487/RFC4984, September 2007, <https://www.rfc-editor.org/info/rfc4984>.
[RFC4984] Meyer、D.、ed。、Zhang、L.、ed。、およびK. Fall、ed。、「ルーティングとアドレス指定に関するIABワークショップからの報告」、RFC 4984、DOI 10.17487/RFC4984、2007年9月、<https://www.rfc-editor.org/info/rfc4984>。
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, <https://www.rfc-editor.org/info/rfc6830>.
[RFC6830] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「ロケーター/ID分離プロトコル（LISP）」、RFC 6830、DOI 10.17487/RFC6830、2013年1月、<https：/<https：//www.rfc-editor.org/info/rfc6830>。
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, DOI 10.17487/RFC6831, January 2013, <https://www.rfc-editor.org/info/rfc6831>.
[RFC6831] Farinacci、D.、Meyer、D.、Zwiebel、J。、およびS. Venaas、「マルチキャスト環境のロケーター/ID分離プロトコル（LISP）」、RFC 6831、DOI 10.17487/RFC6831、2013年1月、<<<<https://www.rfc-editor.org/info/rfc6831>。
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, DOI 10.17487/RFC6832, January 2013, <https://www.rfc-editor.org/info/rfc6832>.
[RFC6832] Lewis、D.、Meyer、D.、Farinacci、D.、およびV. Fuller、「ロケーター/ID分離プロトコル（LISP）と非リスプサイト間のインターワーキング」、RFC 6832、DOI 10.17487/RFC6832、1月2013、<https://www.rfc-editor.org/info/rfc6832>。
[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, <https://www.rfc-editor.org/info/rfc6836>.
[RFC6836] Fuller、V.、Farinacci、D.、Meyer、D。、およびD. Lewis、「ロケーター/ID分離プロトコル代替論理トポロジ（LISP ALT）」、RFC 6836、DOI 10.17487/RFC6836、2013年1月、<<<<https://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, <https://www.rfc-editor.org/info/rfc6837>.
[RFC6837] Lear、E。、「Nerd：A Not-Novel Endpoint ID（eid）ルーティングロケーター（RLOC）データベースへのnot-Novel Endpoint ID（eid）、RFC 6837、DOI 10.17487/RFC6837、2013年1月、<https：//www.rfc-editor.org/info/rfc6837>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、doi10.17487/rfc6973、2013年7月、<https://www.rfc-editor.org/info/rfc6973>。
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, <https://www.rfc-editor.org/info/rfc7348>.
[RFC7348] Mahalingam、M.、Dutt、D.、Duda、K.、Agarwal、P.、Kreeger、L.、Sridhar、T.、Bursell、M。、およびC. Wright、「仮想拡張可能なローカルエリアネットワーク（VXLAN）：仮想化されたレイヤー2ネットワークを重ねるためのフレームワーク3ネットワーク "、RFC 7348、DOI 10.17487/RFC7348、2014年8月、<https://www.rfc-editor.org/info/rfc7348>
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Threat Analysis", RFC 7835, DOI 10.17487/RFC7835, April 2016, <https://www.rfc-editor.org/info/rfc7835>.
[RFC7835] Saucez、D.、Iannone、L。、およびO. Bonaventure、「ロケーター/ID分離プロトコル（LISP）脅威分析」、RFC 7835、DOI 10.17487/RFC7835、2016年4月、<https：//ww.rfc-editor.org/info/rfc7835>。
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, February 2017, <https://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月、<https：//ww.rfc-editor。org/info/rfc8060>。
[RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality", RFC 8061, DOI 10.17487/RFC8061, February 2017, <https://www.rfc-editor.org/info/rfc8061>.
[RFC8061] Farinacci、D。およびB. Weis、「ロケーター/ID分離プロトコル（LISP）データプレーン機密性」、RFC 8061、DOI 10.17487/RFC8061、2017年2月、<https：//www.rfc-editor.org/info/rfc8061>。
[RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, "Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, May 2017, <https://www.rfc-editor.org/info/rfc8111>.
[RFC8111] Fuller、V.、Lewis、D.、Ermagan、V.、Jain、A。、およびA. Smirnov、「ロケーター/ID分離プロトコル委任データベースツリー（LISP-DDT）」、RFC 8111、DOI 10.17487/RFC8111、2017年5月、<https://www.rfc-editor.org/info/rfc8111>。
[RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID Separation Protocol (LISP) Multicast", RFC 8378, DOI 10.17487/RFC8378, May 2018, <https://www.rfc-editor.org/info/rfc8378>.
[RFC8378] Moreno、V。およびD. Farinacci、「信号なしロケーター/ID分離プロトコル（LISP）マルチキャスト」、RFC 8378、DOI 10.17487/RFC8378、2018年5月、<https：//www.rfc-editor.org/info/rfc8378>。
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8402] Filsfils、C.、Ed。、Previdi、S.、Ed。、Ginsberg、L.、Decraene、B.、Litkowski、S.、およびR. Shakir、「セグメントルーティングアーキテクチャ」、RFC 8402、DOI 10.17487/RFC8402、2018年7月、<https://www.rfc-editor.org/info/rfc8402>。
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/info/rfc9147>.
[RFC9147] Rescorla、E.、Tschofenig、H。、およびN. Modadugu、「データグラム輸送層セキュリティ（DTLS）プロトコルバージョン1.3」、RFC 9147、DOI 10.17487/RFC9147、2022年4月、<https：// www。rfc-editor.org/info/rfc9147>。
[RFC9299] Cabellos, A. and D. Saucez, Ed., "An Architectural Introduction to the Locator/ID Separation Protocol (LISP)", RFC 9299, DOI 10.17487/RFC9299, October 2022, <https://www.rfc-editor.org/info/rfc9299>.
[RFC9299] Cabellos、A。and D. Sauce、ed。、「ロケーター/ID分離プロトコル（LISP）の建築紹介」、RFC 9299、DOI 10.17487/RFC9299、2022年10月、<https：//ww.rfc-editor.org/info/rfc9299>。
[RFC9305] Maino, F., Ed., Lemon, J., Agarwal, P., Lewis, D., and M. Smith, "Locator/ID Separation Protocol (LISP) Generic Protocol Extension", RFC 9305, DOI 10.17487/RFC9305, October 2022, <https://www.rfc-editor.org/info/rfc9305>.
[RFC9305] Maino、F.、Ed。、Lemon、J.、Agarwal、P.、Lewis、D.、およびM. Smith、「ロケーター/ID分離プロトコル（LISP）ジェネリックプロトコル拡張」、RFC 9305、DOI 10.17487/RFC9305、2022年10月、<https://www.rfc-editor.org/info/rfc9305>。
Acknowledgments
謝辞
The original authors would like to thank Greg Schudel, Darrel Lewis, John Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, and members of the lisp@ietf.org mailing list for their feedback and helpful suggestions.
元の著者は、Greg Schudel、Darrel Lewis、John Zwiebel、Andrew Partan、Dave Meyer、Isidor Kouvelas、Jesper Skriver、およびlisp@ietf.orgメーリングリストのメンバーにフィードバックと有益な提案に感謝します。
Special thanks are due to Noel Chiappa for his extensive work and thought about caching in Map-Resolvers.
Noel Chiappaが豊富な仕事をしてくれたことに感謝し、地図解除者でのキャッシュについて考えました。
The current authors would like to give a sincere thank you to the people who help put LISP on the Standards Track in the IETF. They include Joel Halpern, Luigi Iannone, Deborah Brungard, Fabio Maino, Scott Bradner, Kyle Rose, Takeshi Takahashi, Sarah Banks, Pete Resnick, Colin Perkins, Mirja Kühlewind, Francis Dupont, Benjamin Kaduk, Eric Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper, Suresh Krishnan, Alberto Rodriguez-Natal, Vina Ermagan, Mohamed Boucadair, Brian Trammell, Sabrina Tanamal, and John Drake. The contributions they offered greatly added to the security, scale, and robustness of the LISP architecture and protocols.
現在の著者は、IETFの標準トラックにLISPを置くのを手伝ってくれた人々に心から感謝したいと思います。ジョエル・ハルパーン、ルイジ・イアンノーネ、デボラ・ブランガード、ファビオ・マニョ、スコット・ブラッドナー、カイル・ローズ、タカハシ、サラ・バンクス、ピート・レストニック、コリン・パーキンス、ミルジャ・キュルウィンド、フランシス・デュポン、ベンジャミン・カドゥク、エリック・レスカルラ、アルヴァロ・レクサイ、アリッサ・クーパー、スレシュ・クリシュナン、アルベルト・ロドリゲス・ナタール、ヴィナ・エルマガン、モハメド・ブーカデア、ブライアン・トラメル、サブリナ・タナマル、ジョン・ドレイク。彼らが提供した貢献は、LISPアーキテクチャとプロトコルのセキュリティ、規模、堅牢性に大きく追加されました。
Authors' Addresses
著者のアドレス
Dino Farinacci lispers.net San Jose, CA United States of America Email: farinacci@gmail.com
Dino Farinacci lispers.netサンノゼ、カリフォルニア州統一されたアメリカ電子メール：farinacci@gmail.com
Fabio Maino Cisco Systems San Jose, CA United States of America Email: fmaino@cisco.com
Fabio Maino Cisco Systems San Jose、CA Neciment States of America Email：fmaino@cisco.com
Vince Fuller vaf.net Internet Consulting Email: vince.fuller@gmail.com
Vince Fuller vaf.netインターネットコンサルティングメール：vince.fuller@gmail.com
Albert Cabellos (editor) Universitat Politecnica de Catalunya c/ Jordi Girona s/n 08034 Barcelona Spain Email: acabello@ac.upc.edu
Albert Cabellos（編集者）Politecnica de Catalunya C/ Jordi Girona S/ N 08034バルセロナスペインメール：acabello@ac.upc.edu