[要約] RFC 9962は、Locator/ID Separation Protocol (LISP) において、サードパーティの集中管理型インフラに依存せず、データプレーンのxTRノード自体が分散型マッピングシステム（DMS）に参加する「LISP-Decent」方式を説明する情報提供目的の文書です。マルチキャストを利用したプッシュ型とDNSを利用したプル型のアプローチを規定し、運用負荷の軽減や攻撃対象領域の縮小を実現します。
Independent Submission D. Farinacci
Request for Comments: 9962 lispers.net
Category: Informational C. Cantrell
ISSN: 2070-1721 Nexus
May 2026
This document describes how the Locator/ID Separation Protocol (LISP) Mapping System can be distributed for scale and decentralized for management, while maintaining trust among data plane nodes. This is an Informational RFC and should be used by LISP-Decent implementations to interoperate with each other.
このドキュメントでは、データ プレーン ノード間の信頼を維持しながら、Locator/ID Separation Protocol (LISP) マッピング システムを大規模化のために分散し、管理のために分散化する方法について説明します。これは情報 RFC であり、LISP-Decent 実装が相互運用するために使用する必要があります。
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書は Internet Standards Track 仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他の RFC ストリームとは独立した、RFC シリーズへの貢献です。RFC 編集者は独自の裁量でこの文書を公開することを選択しており、実装または展開におけるこの文書の価値については何も述べていません。RFC 編集者によって出版が承認された文書は、どのレベルのインターネット標準の候補でもありません。RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9962.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9962 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。
1. Introduction
2. Definitions of Terms
2.1. Requirements Language
3. Overview
4. Decent-Push-Based Mapping System
4.1. Components of a Decent-Push-Based LISP-Decent xTR
4.2. Implementation Considerations
4.3. Configuration and Authentication
4.4. Core Seed-Group
5. Decent-Pull-Based Mapping System
5.1. Components of a Decent-Pulled Based LISP-Decent xTR
5.2. Configurable EID Prefix Lengths for Lookups
5.3. Deployment Example
5.4. Management Considerations
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Authors' Addresses
The LISP architecture [RFC9300] introduces two new numbering spaces that are intended to provide overlay network functionality: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). To map from EIDs to a set of RLOCs, a control plane Mapping System is used [RFC6836] [RFC8111]. These Mapping Systems are naturally distributed in their deployment for scalability but are centrally managed by a third-party entity, namely a Mapping System Provider (MSP). The entities that use the Mapping System, such as data plane LISP Tunnel Routers (xTRs), depend on and trust the MSP. They do not participate in the Mapping System other than to register and retrieve information [RFC9301].
LISP アーキテクチャ [RFC9300] では、オーバーレイ ネットワーク機能を提供することを目的とした 2 つの新しい番号付けスペース、エンドポイント識別子 (EID) とルーティング ロケーター (RLOC) が導入されています。EID から RLOC のセットにマッピングするには、コントロール プレーン マッピング システムが使用されます [RFC6836] [RFC8111]。これらのマッピング システムは、スケーラビリティを確保するために展開時に自然に分散されますが、サードパーティのエンティティ、つまりマッピング システム プロバイダー (MSP) によって集中管理されます。データ プレーン LISP トンネル ルーター (xTR) など、マッピング システムを使用するエンティティは、MSP に依存し、MSP を信頼します。これらは、情報の登録と取得を除き、マッピング システムには参加しません [RFC9301]。
This document introduces a Decentralized Mapping System (DMS) so the xTRs can participate in the Mapping System as well as use it. They can trust each other rather than rely on third-party infrastructure. The xTRs act as Map-Servers to maintain distributed state for scale and reduce the attack surface. The trust relationships between the xTRs are established through authentication and authorization procedures in [RFC9301] and [ECDSA-AUTH].
このドキュメントでは、xTR がマッピング システムに参加できるだけでなく、それを使用できるようにするための分散マッピング システム (DMS) を紹介します。サードパーティのインフラストラクチャに依存するのではなく、お互いを信頼できます。xTR はマップ サーバーとして機能し、規模に応じて分散状態を維持し、攻撃対象領域を減らします。xTR 間の信頼関係は、[RFC9301] および [ECDSA-AUTH] の認証および認可手順を通じて確立されます。
This design was first introduced to the LISP Working Group (WG) in January of 2018. It was presented in London in March 2018 [IETF101-PRESO] and in Prague in March 2019 [IETF104-PRESO]. This Informational document is not a standard and did not reach community consensus to make it an IETF LISP WG document.
この設計は、2018 年 1 月に LISP ワーキング グループ (WG) に初めて導入されました。2018 年 3 月にロンドンで [IETF101-PRESO]、2019 年 3 月にプラハで発表されました [IETF104-PRESO]。この情報ドキュメントは標準ではなく、IETF LISP WG ドキュメントにするというコミュニティのコンセンサスに達していません。
The intended audience for this specification are protocol development engineers who would implement this specification in products as well network engineers who deploy the technology in operational environments.
この仕様の対象読者は、この仕様を製品に実装するプロトコル開発エンジニアと、運用環境にテクノロジーを導入するネットワーク エンジニアです。
This design does not conflict with those designs or contradicts any other LISP design principles produced by the working group. This solution makes no fundamental LISP changes and adheres to the specifications documented in [RFC9301].
この設計は、これらの設計と矛盾したり、作業グループによって作成された他の LISP 設計原則と矛盾したりすることはありません。このソリューションは LISP に基本的な変更を加えず、[RFC9301] に文書化された仕様に準拠しています。
By the nature of this work, this document uses IP addresses as examples. They should not be copied or used outside of a lab environment. Deployments should use addresses appropriate for their environment.
この作業の性質上、このドキュメントでは例として IP アドレスを使用します。これらをコピーしたり、ラボ環境の外で使用したりしないでください。デプロイメントでは、環境に適したアドレスを使用する必要があります。
Mapping System Provider (MSP):
マッピング システム プロバイダー (MSP):
Infrastructure service that deploys LISP Map-Resolvers and Map-Servers [RFC9301] and possibly LISP-ALT nodes [RFC6836] or LISP-DDT nodes [RFC8111]. ALT-nodes and DDT-nodes use different algorithms for connecting Map-Resolvers and Map-Servers together. The MSP can be managed by a separate organization other than the one that manages xTRs. This model provides a business separation between the organization that manages (and is responsible for) the control plane versus the organization that manages the data plane overlay service.
LISP Map-Resolver および Map-Servers [RFC9301]、および場合によっては LISP-ALT ノード [RFC6836] または LISP-DDT ノード [RFC8111] を展開するインフラストラクチャ サービス。ALT ノードと DDT ノードは、Map-Resolver と Map-Server を接続するために異なるアルゴリズムを使用します。MSP は、xTR を管理する組織とは別の組織によって管理できます。このモデルは、コントロール プレーンを管理する (および責任を持つ) 組織と、データ プレーン オーバーレイ サービスを管理する組織との間でビジネスを分離します。
Decentralized Mapping System (DMS):
分散型マッピング システム (DMS):
A mapping system entity that is managed by the xTR nodes that use it and not third-party nodes/ operators. The xTRs themselves are part of the Mapping System. The state of the Mapping System is fully distributed across xTRs, decentralized, and the trust relies on the xTRs that use and participate in their own mapping system.
サードパーティのノード/オペレーターではなく、それを使用する xTR ノードによって管理されるマッピング システム エンティティ。xTR 自体はマッピング システムの一部です。マッピング システムの状態は xTR 全体に完全に分散され、分散化されており、信頼は独自のマッピング システムを使用して参加する xTR に依存します。
Decent-Pull-Based Mapping System:
適切なプルベースのマッピング システム:
The mapping system is pull-based, meaning that xTRs will look up and register mappings by algorithmic transformation to locate which Map-Resolvers and Map-Servers are used. It is required that the lookup and registration uses a consistent algorithmic transformation function. Map-Registers are sent to specific Map-Servers. Map-Requests are considered external lookups when sent to Map-Resolvers on xTRs that do not participate in the mapping system and the Map-Requests are considered internal lookups when they are sent to Map-Resolvers on xTRs that do participate in the mapping system.
マッピング システムはプルベースです。つまり、xTR はアルゴリズム変換によってマッピングを検索して登録し、どのマップ リゾルバーとマップ サーバーが使用されているかを特定します。検索と登録では一貫したアルゴリズム変換関数を使用する必要があります。マップ レジスタは特定のマップ サーバーに送信されます。Map-Request は、マッピング システムに参加していない xTR 上の Map-Resolver に送信される場合は外部ルックアップとみなされ、Map-Request はマッピング システムに参加する xTR 上の Map-Resolver に送信される場合は内部ルックアップとみなされます。
Modulus Value:
モジュラス値:
This value is used in the Pull-based Mapping System. It defines the number of Map-Server sets used for the Mapping System. The modulus value is used to produce a Name Index used for a Domain Name System (DNS) lookup. The Modulus Value is chosen based on the horizontal scale-out width of the Map-Server cluster the network operator chooses to deploy.
この値は、プルベースのマッピング システムで使用されます。マッピング システムに使用されるマップ サーバー セットの数を定義します。モジュラス値は、ドメイン ネーム システム (DNS) ルックアップに使用される名前インデックスを生成するために使用されます。モジュラス値は、ネットワーク オペレータが展開することを選択したマップ サーバー クラスタの水平スケールアウト幅に基づいて選択されます。
Name Index:
名前インデックス:
This index value <index> is used in the Pull-based Mapping System. For a Mapping System that is configured with a Map-Server set of DNS names in the form of <name>.example.com, the Name Index is prepended to <name> to form the lookup name <index>.<name>.example.com. If the Modulus Value is 8, then the Name Indexes are 0 through 7.
このインデックス値 <index> は、プルベースのマッピング システムで使用されます。<name>.example.com の形式の DNS 名のマップ サーバー セットで構成されたマッピング システムの場合、名前インデックスが <name> の前に追加されて、ルックアップ名 <index>.<name>.example.com が形成されます。モジュラス値が 8 の場合、名前インデックスは 0 ～ 7 になります。
Hash Mask:
ハッシュマスク:
The Hash Mask is used in the Pull-based Mapping System. It is a mask value with 1 bit left justified. The mask is used to select what high-order bits of an EID-prefix are used in the hash function.
ハッシュ マスクはプルベースのマッピング システムで使用されます。1ビット左詰めのマスク値です。マスクは、EID プレフィックスのどの上位ビットがハッシュ関数で使用されるかを選択するために使用されます。
Decent-Push-Based Mapping System:
適切なプッシュベースのマッピング システム:
The Mapping System is push-based, meaning that xTRs will push registrations via IP multicast to a group of Map-Servers and do local lookups acting as their own Map-Resolvers.
マッピング システムはプッシュ ベースです。つまり、xTR は IP マルチキャスト経由でマップ サーバーのグループに登録をプッシュし、独自のマップ リゾルバーとして機能するローカル ルックアップを実行します。
Replication List Entry (RLE):
レプリケーション リスト エントリ (RLE):
An RLOC-record format that contains a list of RLOCs that an Ingress Tunnel Router (ITR) replicates multicast packets on a multicast overlay. The RLE format is specified in [RFC8060]. RLEs are used with the Decent-Push-based Mapping System.
入力トンネル ルーター (ITR) がマルチキャスト オーバーレイ上でマルチキャスト パケットを複製する RLOC のリストを含む RLOC レコード フォーマット。RLE フォーマットは [RFC8060] で規定されています。RLE は、Decent-Push ベースのマッピング システムで使用されます。
Group Address EID:
グループアドレスEID:
An EID-record format that contains IPv4 (0.0.0.0/0, G) or IPv6 (0::/0, G) state. This state is encoded as a Multicast Info Type LISP Canonical Address Format (LCAF) specified in [RFC8060]. Members of a seed-group send Map-Registers for (0.0.0.0/0, G) or (0::/0, G) with an RLOC-record that RLE encodes its RLOC address. Details are specified in [RFC8378].
IPv4 (0.0.0.0/0, G) または IPv6 (0::/0, G) 状態を含む EID レコード形式。この状態は、[RFC8060] で指定されている Multicast Info Type LISP Canonical Address Format (LCAF) としてエンコードされます。シード グループのメンバーは、RLE が RLOC アドレスをエンコードした RLOC レコードを含む (0.0.0.0/0, G) または (0::/0, G) の Map-Register を送信します。詳細は[RFC8378]で規定されています。
Seed-Group:
シードグループ:
A set of Map-Servers joined to a multicast group for the Decent-Push-based Mapping System or are mapped by DNS names in a Pull-based Mapping System. A core seed-group is used to bootstrap a set of LISP-Decent xTRs so they can learn about each other and use each other's Mapping System service. A seed-group can be pull-based to bootstrap the Decent-Push-based Mapping System. That is, a set of DNS mapped Map-Servers can be used to join the mapping system's IP multicast group.
Decent-Push ベースのマッピング システムのマルチキャスト グループに参加するマップ サーバーのセット、またはプル ベースのマッピング システムで DNS 名によってマップされるマップ サーバーのセット。コア シード グループは、一連の LISP-Decent xTR をブートストラップするために使用され、相互に学習し、相互のマッピング システム サービスを使用できるようにします。シード グループをプルベースにして、Decent-Push ベースのマッピング システムをブートストラップすることができます。つまり、一連の DNS マップされたマップ サーバーを使用して、マッピング システムの IP マルチキャスト グループに参加できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
The clients of the DMS are also the providers of mapping state, see [RFC9301] for formal details. Clients are typically Egress Tunnel Routers (ETRs) that Map-Register EID-to-RLOC mapping state to the mapping database system. ITRs are clients in that they send Map-Requests to the mapping database system to obtain EID-to-RLOC mappings that are cached for data plane use. When xTRs participate in a DMS, they are also acting as Map-Resolvers and Map-Servers using the protocol machinery defined in LISP control plane specifications [RFC9301], [RFC9303], and [ECDSA-AUTH]. The xTRs are not required to run the database mapping transport system protocols specified in [RFC6836] or [RFC8111].
DMS のクライアントはマッピング状態のプロバイダーでもあります。正式な詳細については [RFC9301] を参照してください。通常、クライアントは EID から RLOC へのマッピング状態をマッピング データベース システムにマップ登録する出力トンネル ルーター (ETR) です。ITR は、データ プレーンで使用するためにキャッシュされた EID から RLOC へのマッピングを取得するためにマッピング データベース システムに Map-Request を送信するという点でクライアントです。xTR が DMS に参加する場合、LISP コントロール プレーン仕様 [RFC9301]、[RFC9303]、および [ECDSA-AUTH] で定義されているプロトコル機構を使用して、マップ リゾルバーおよびマップ サーバーとしても機能します。xTR は、[RFC6836] または [RFC8111] で指定されているデータベース マッピング トランスポート システム プロトコルを実行する必要はありません。
This document will describe two decentralized and distributed mapping system mechanisms. A Decent-Push-based Mapping System uses IP multicast so xTRs can find each other by locally joining an IP multicast group. A Decent-Pull-based Mapping System uses DNS with an algorithmic transformation function so xTRs can find each other.
この文書では、2 つの分散型マッピング システム メカニズムについて説明します。Decent-Push ベースのマッピング システムは IP マルチキャストを使用するため、xTR は IP マルチキャスト グループにローカルに参加することで相互に検索できます。Decent-Pull ベースのマッピング システムは、アルゴリズム変換機能を備えた DNS を使用するため、xTR が相互に検索できるようになります。
The document proposes two approaches to provide state/bandwidth, ease of configurability, and robustness/complexity trade-offs. When the Decent-Push-based approach is used, there is less messaging involved. xTRs can multicast a single Map-Register message that goes to all Map-Servers joined to the multicast group. When Map-Servers are added to or removed from the Map-Server cluster group, the Mapping System updates quickly with little human intervention. In the push model, all mapping state is stored in all Map-Servers so there is robustness achieved through redundancy. However, this requires a multicast underlay in nodes between all xTRs and Map-Servers. When a multicast underlay is not available, the Decent-Pull-based approach can be used with the help of the DNS. This approach uses less state overall among the Map-Servers (they each have different Mapping System state) and the ITRs know which Map-Server to ask by using the hashing techniques described later in this document.
この文書では、状態/帯域幅、構成の容易さ、堅牢性/複雑さのトレードオフを提供する 2 つのアプローチを提案しています。Decent-Push ベースのアプローチを使用すると、関与するメッセージが少なくなります。xTR は、マルチキャスト グループに参加しているすべての Map-Server に送信される単一の Map-Register メッセージをマルチキャストできます。Map-Server クラスタ グループに Map-Server を追加したり、Map-Server クラスタ グループから削除したりすると、マッピング システムは人間の介入をほとんど必要とせずに迅速に更新されます。プッシュ モデルでは、すべてのマッピング状態がすべての Map-Server に保存されるため、冗長性によって堅牢性が実現されます。ただし、これには、すべての xTR とマップ サーバー間のノードにマルチキャスト アンダーレイが必要です。マルチキャスト アンダーレイが利用できない場合は、DNS の助けを借りて Decent-Pull ベースのアプローチを使用できます。このアプローチでは、マップ サーバー間で全体的に使用する状態が少なくなり (マップ サーバーごとに異なるマッピング システム状態を持ちます)、ITR は、このドキュメントで後述するハッシュ技術を使用して、どのマップ サーバーに問い合わせるべきかを認識します。
This document does not describe any compatibility with other mapping systems. The design is intentional so that all xTRs and Map-Servers support this specification. Moreover, all xTRs and Map-Servers MUST support either the pull-based or push-based algorithms. They cannot be mixed. When both are used, they are completely discrete Mapping Systems just like they would be using one of the LISP WG Mapping System designs. An implementation can decide to implement only the pull-based approach or the push-based approach and still be compliant with this specification.
この文書では、他のマッピング システムとの互換性については説明しません。この設計は、すべての xTR と Map-Server がこの仕様をサポートするように意図的に行われています。さらに、すべての xTR と Map-Server は、プルベースまたはプッシュベースのアルゴリズムをサポートしなければなりません (MUST)。混合することはできません。両方を使用すると、LISP WG マッピング システム デザインの 1 つを使用する場合と同様に、完全に個別のマッピング システムになります。実装では、プルベースのアプローチのみを実装するか、プッシュベースのアプローチのみを実装するかを決定し、それでもこの仕様に準拠することができます。
The xTRs are organized in a mapping-system group. The group is identified by an IPv4 or IPv6 multicast group address or using a Decent-Pull-based approach described in Section 5. When using multicast, the xTRs join the same multicast group and receive LISP control plane messages addressed to the group. Messages sent to the multicast group are distributed when the underlay network supports IP multicast [RFC6831] or via the overlay multicast mechanism described in [RFC8378]. When overlay multicast is used and LISP Map-Register messages are sent to the group, they are LISP data encapsulated with an instance-ID set to 0xffffff in the LISP header. The inner header of the encapsulated packet has the destination address set to the multicast group address and the outer header that is prepended has the destination address set to the RLOC of Mapping System group member. The members of the Mapping System group are kept in the LISP data plane map-cache so packets for the group can be replicated to each member RLOC.
xTR はマッピング システム グループに編成されます。グループは、IPv4 または IPv6 マルチキャスト グループ アドレスによって識別されるか、セクション 5 で説明されている Decent-Pull ベースのアプローチを使用して識別されます。マルチキャストを使用する場合、xTR は同じマルチキャスト グループに参加し、そのグループにアドレス指定された LISP コントロール プレーン メッセージを受信します。マルチキャスト グループに送信されるメッセージは、アンダーレイ ネットワークが IP マルチキャスト [RFC6831] をサポートする場合、または [RFC8378] で説明されているオーバーレイ マルチキャスト メカニズムを介して配信されます。オーバーレイ マルチキャストが使用され、LISP Map-Register メッセージがグループに送信される場合、それらのメッセージは、LISP ヘッダーでインスタンス ID が 0xffffff に設定されてカプセル化された LISP データです。カプセル化されたパケットの内部ヘッダーの宛先アドレスはマルチキャスト グループ アドレスに設定され、先頭に追加される外部ヘッダーの宛先アドレスはマッピング システム グループ メンバーの RLOC に設定されます。マッピング システム グループのメンバーは LISP データ プレーン マップ キャッシュに保持されるため、グループのパケットを各メンバー RLOC に複製できます。
All xTRs in a Mapping System group will store the same registered mappings and maintain the state as Map-Servers normally do. The members are not only receivers of the multicast group, but they also send packets to the group.
マッピング システム グループ内のすべての xTR は、同じ登録済みマッピングを保存し、マップ サーバーが通常行うように状態を維持します。メンバーはマルチキャスト グループの受信者であるだけでなく、グループにパケットを送信することもできます。
When an xTR is configured to be a LISP-Decent xTR (or PxTR [RFC6832]), it runs the ITR, ETR, Map-Resolver, and Map-Server LISP network functions.
xTR が LISP-Decent xTR (または PxTR [RFC6832]) として設定されると、ITR、ETR、Map-Resolver、および Map-Server LISP ネットワーク機能が実行されます。
The following diagram shows 3 LISP-Decent xTRs joined to Mapping System group address 233.252.1.1. When the ETR function of xTR1 originates a Map-Register, it is sent to all xTRs (including itself) synchronizing all 3 Map-Servers in xTR1, xTR2, and xTR3. The ITR function can populate its map-cache by sending a Map-Request locally to its Map-Resolver so it can replicate packets to each RLOC for EID 233.252.1.1.
次の図は、マッピング システム グループ アドレス 233.252.1.1 に参加している 3 つの LISP-Decent xTR を示しています。xTR1 の ETR 機能がマップ レジスタを生成すると、そのマップ レジスタがすべての xTR (それ自体を含む) に送信され、xTR1、xTR2、および xTR3 の 3 つのマップ サーバーすべてが同期されます。ITR 機能は、Map-Request を Map-Resolver にローカルに送信することでマップ キャッシュにデータを追加できるため、EID 233.252.1.1 の各 RLOC にパケットを複製できます。
In this document, there is no special meaning for the multicast group address 233.252.1.1. It is used for example purposes only.
この文書では、マルチキャスト グループ アドレス 233.252.1.1 に特別な意味はありません。これは例としてのみ使用されます。
xTR1
Map-Request +--------------------+
(always local) | +-----+ +-----+ |
+---------------| ITR | | ETR |-------------+
| | +-----+ +-----+ | |
| | | | Map-Register to
| | +-------+ | | EID 233.252.1.1
+------------------>| MR/MS |<---------------+ encapsulated to
| +-------+ | | RLOCs xTR1, xTR2,
+--------------------+ | and xTR3
|
+--------------------+------------+
| |
| |
+----------v---------+ +----------v---------+
| +--------+ | | +--------+ |
| | MR/MS | | | | MR/MS | |
| +--------+ | | +--------+ |
| +-----+ +-----+ | | +-----+ +-----+ |
| | ITR | | ETR | | | | ITR | | ETR | |
| +-----+ +-----+ | | +-----+ +-----+ |
+--------------------+ +--------------------+
xTR2 xTR3
Figure 1
Note that if any external xTR would like to use a Map-Resolver from the Mapping System group, it only needs to have one of the LISP-Decent Map-Resolvers configured. By looking at the Map-Resolver for EID 233.252.1.1, the external xTR could get the complete list of members for the Mapping System group.
外部 xTR が Mapping System グループの Map-Resolver を使用したい場合は、LISP-Decent Map-Resolver の 1 つを設定するだけでよいことに注意してください。EID 233.252.1.1 のマップ リゾルバーを調べることにより、外部 xTR はマッピング システム グループのメンバーの完全なリストを取得できます。
For future study, an external xTR could multicast the Map-Request to 233.252.1.1 and either one of the LISP-Decent Map-Resolvers would return a Map-Reply or the external xTR is prepared to receive multiple Map-Replies.
将来の研究のために、外部 xTR が Map-Request を 233.252.1.1 にマルチキャストし、LISP-Decent Map-Resolver のいずれか 1 つが Map-Reply を返すか、外部 xTR が複数の Map-Reply を受信する準備ができている可能性があります。
There are no LISP changes required to support the Decent-Push-based LISP-Decent set of procedures. An implementation that sends Map-Register messages to a multicast group versus a specific Map-Server unicast address MUST change to call the data plane component so the ITR functionality in the node can encapsulate the Map-Register as a unicast packet to each member of the Mapping System group.
Decent-Push ベースの LISP-Decent プロシージャ セットをサポートするために必要な LISP の変更はありません。Map-Register メッセージを特定の Map-Server ユニキャスト アドレスではなくマルチキャスト グループに送信する実装は、ノード内の ITR 機能が Map-Register をマッピング システム グループの各メンバーへのユニキャスト パケットとしてカプセル化できるように、データ プレーン コンポーネントを呼び出すように変更しなければなりません (MUST)。
An ITR SHOULD look up its Mapping System group address periodically to determine if the membership has changed. The lookup interval is a configuration parameter only needed when the ITR does not use the PubSub capability documented in [RFC9437] to be notified when a new member joins or leaves the multicast group. When PubSub is not used, there needs to be coordination (via configuration management) among all xTRs so they rendezvous roughly at the same time and to the same group address.
ITR は、マッピング システム グループ アドレスを定期的に検索して、メンバーシップが変更されたかどうかを判断する必要があります。ルックアップ間隔は、ITR が [RFC9437] に記載されている PubSub 機能を使用して、新しいメンバーがマルチキャスト グループに参加または脱退したときに通知を受け取る場合にのみ必要となる設定パラメータです。PubSub が使用されない場合は、すべての xTR がほぼ同時に同じグループ アドレスにランデブーできるように、すべての xTR 間で調整を行う必要があります (構成管理を介して)。
When xTRs are joined to a multicast group, they MUST have their site registration configuration consistent. Any policy or authentication key material MUST be configured consistently among all members. When [ECDSA-AUTH] is used to sign Map-Register messages, public keys can be registered to the Mapping System group using the site authentication key mentioned above or using a different authentication key from the one used for registering EID records. An out-of-band registration controller, like an ETR dedicated for this function, can send Map-Register messages for public-key encoded EIDs.
xTR がマルチキャスト グループに参加する場合、サイト登録設定の一貫性がなければなりません。ポリシーまたは認証キーマテリアルはすべてのメンバー間で一貫して構成されなければなりません。[ECDSA-AUTH] を使用して Map-Register メッセージに署名する場合、前述のサイト認証キーを使用するか、EID レコードの登録に使用される認証キーとは異なる認証キーを使用して、公開キーをマッピング システム グループに登録できます。この機能専用の ETR などの帯域外登録コントローラーは、公開キーでエンコードされた EID の Map-Register メッセージを送信できます。
A core seed-group can be discovered using a multicast group in a Decent-Push-based system or a Map-Server set of DNS names in a Decent-Pull-based system (see Section 5 for details).
コア シード グループは、Decent-Push ベースのシステムのマルチキャスト グループ、または Decent-Pull ベースのシステムの DNS 名のマップ サーバー セットを使用して検出できます (詳細についてはセクション 5 を参照)。
When using multicast for the Mapping System group, a core seed-group multicast group address can be preconfigured to bootstrap the decentralized Mapping System. The group address (or DNS name that maps to a group address) can be explicitly configured in a few xTRs to start building up the registrations. Then as other xTRs come online, they can add themselves to the core seed-group by joining the seed-group multicast group.
マッピング システム グループにマルチキャストを使用する場合、コア シード グループ マルチキャスト グループ アドレスを事前設定して、分散型マッピング システムをブートストラップすることができます。グループ アドレス (またはグループ アドレスにマップする DNS 名) をいくつかの xTR で明示的に設定して、登録の構築を開始できます。その後、他の xTR がオンラインになると、シード グループ マルチキャスト グループに参加することで、自分自身をコア シード グループに追加できます。
Alternatively or additionally, new xTRs can join a new Mapping System multicast group to form another layer of a decentralized Mapping System. The group address and members of this new layer seed-group would be registered to the core seed-group address and stored in the core seed-group mapping system. Note that each Mapping System layer could have a specific function or a specific circle of trust.
代替的または追加的に、新しい xTR は新しいマッピング システム マルチキャスト グループに参加して、分散型マッピング システムの別の層を形成できます。この新しいレイヤー シード グループのグループ アドレスとメンバーは、コア シード グループ アドレスに登録され、コア シード グループ マッピング システムに保存されます。各マッピング システム層は、特定の機能または特定の信頼サークルを持つことができることに注意してください。
This multi-layer Mapping System can be illustrated:
この多層マッピング システムは次のように説明できます。
____________ -----------
/ core \ 233.252.2.2 / layer-1 \
| seed-group | ----------> | I |
| 233.252.1.1 | | / \ |
\____________/ | J---K |
| \___________/
| 233.252.3.3
|
v
---------
/ layer-2 \
| X |
| / \ |
| Y---Z |
\_________/
Configured in xTRs A, B, and C (they make up the core seed-group):
233.252.1.1 -> RLE: A, B, C
core seed-group DMS, mapping state in A, B, and C:
233.252.2.2 -> RLE: I, J, K
233.252.3.3 -> RLE: X, Y, Z
layer-1 seed-group DMS (inter-continental), mapping state in I, J, K:
EID1 -> RLOCs: i(1), j(2)
...
EIDn -> RLOCs: i(n), j(n)
layer-2 seed-group DMS (intra-continental), mapping sate in X, Y, Z::
EIDa -> RLOCs: x(1), y(2)
...
EIDz -> RLOCs: x(n), y(n)
Figure 2
The core seed-group multicast address 233.252.1.1 is configured in xTRs A, B, and C so when each of them send Map-Register messages, they would all be able to maintain synchronized mapping state. Any EID can be registered to this DMS, but in this example, seed-group multicast group EIDs are being registered only to find other Mapping System groups.
コア シード グループ マルチキャスト アドレス 233.252.1.1 は xTR A、B、および C で設定されているため、各 xTR が Map-Register メッセージを送信すると、すべてが同期されたマッピング状態を維持できます。この DMS には任意の EID を登録できますが、この例では、シード グループ マルチキャスト グループ EID は、他のマッピング システム グループを検索するためだけに登録されています。
For example, xTR I boots up and it wants to find its other peers in its Mapping System group address 233.252.2.2. Group address 233.252.2.2 is configured so xTR I knows what group to join for its Mapping System group. However, xTR I needs a Mapping System to register to, so the core seed-group is used and available to receive Map-Registers. The other xTRs J and K in the Mapping System group do the same so when any of I, J, or K needs to register EIDs, they can now send their Map-Register messages to group address 233.252.2.2. Examples of EIDs being registered are EID1 through EIDn shown above.
たとえば、xTR I が起動すると、マッピング システム グループ アドレス 233.252.2.2 内の他のピアを検索しようとします。グループ アドレス 233.252.2.2 は、xTR I がマッピング システム グループに参加するグループを認識できるように構成されています。ただし、xTR I には登録するマッピング システムが必要であるため、コア シード グループが使用され、マップ レジスタの受信に使用できます。マッピング システム グループ内の他の xTR J および K も同様のことを行うため、I、J、または K のいずれかが EID を登録する必要がある場合、Map-Register メッセージをグループ アドレス 233.252.2.2 に送信できるようになります。登録される EID の例は、上記の EID1 ～ EIDn です。
When Map-Registers are sent to group address 233.252.2.2, they are encapsulated by the LISP data plane by looking up EID 233.252.2.2 in the core seed-group Mapping System. For the map-cache entry to be populated for 233.252.2.2, the data plane MUST send a Map-Request so the RLOCs I, J, and K are cached for replication. To use the core seed-group Mapping System, the data plane MUST know of at least one of the RLOCs A, B, and/or C.
マップ レジスタがグループ アドレス 233.252.2.2 に送信されると、コア シード グループ マッピング システムで EID 233.252.2.2 を検索することにより、LISP データ プレーンによってカプセル化されます。233.252.2.2 のマップ キャッシュ エントリを設定するには、RLOC I、J、および K がレプリケーション用にキャッシュされるように、データ プレーンは Map-Request を送信する必要があります。コア シード グループ マッピング システムを使用するには、データ プレーンは RLOC A、B、C の少なくとも 1 つを認識している必要があります。
When an xTR is configured to be a LISP-Decent xTR (or PxTR [RFC6832]), it runs the ITR, ETR, Map-Resolver, and Map-Server LISP network functions.
xTR が LISP-Decent xTR (または PxTR [RFC6832]) として設定されると、ITR、ETR、Map-Resolver、および Map-Server LISP ネットワーク機能が実行されます。
Unlike the Decent-Push-based Mapping System, the xTRs do not need to be organized by joining a multicast group. In a Decent-Pull-based Mapping System, a hash function over an EID is used to identify which xTR is used as the Map-Resolver and Map-Server. The DNS [RFC1034] [RFC1035] is used as a resource discovery mechanism.
Decent-Push ベースのマッピング システムとは異なり、xTR はマルチキャスト グループに参加して編成する必要がありません。Decent-Pull ベースのマッピング システムでは、EID に対するハッシュ関数を使用して、どの xTR が Map-Resolver および Map-Server として使用されるかを識別します。DNS [RFC1034] [RFC1035] はリソース発見メカニズムとして使用されます。
The RLOC addresses of the xTRs will be A and AAAA records for DNS names that map algorithmically from the hash of the EID. A SHA-256 hash function [RFC6234] over the following ASCII-formatted EID string is used:
xTR の RLOC アドレスは、EID のハッシュからアルゴリズムでマッピングされる DNS 名の A および AAAA レコードになります。次の ASCII 形式の EID 文字列に対する SHA-256 ハッシュ関数 [RFC6234] が使用されます。
[<iid>]<eid>/<ml>
[<iid>]<group>/<gml>-<source>/<sml>
In this section, where you see angle brackets, they are replaced with values in ASCII characters. For example, a unicast EID of 1.1.1.1 in instance-id 11 would be encoded as a string "[11]1.1.1.1/32".
このセクションでは、山括弧が表示されている箇所は、ASCII 文字の値に置き換えられます。たとえば、instance-id 11 のユニキャスト EID 1.1.1.1 は、文字列「[11]1.1.1.1/32」としてエンコードされます。
<iid> is the instance-ID and <eid> is the EID of any EID-type defined in [RFC8060]. The Modulus Value <mv> is used to produce the Name Index <index> used to build the DNS lookup name:
<iid> はインスタンス ID、<eid> は [RFC8060] で定義されている任意の EID タイプの EID です。モジュラス値 <mv> は、DNS ルックアップ名の構築に使用される名前インデックス <index> を生成するために使用されます。
eid = "[<iid>]<eid>/<ml>"
index = hash.sha_256(eid) MOD mv
The Hash Mask is used to select what bits are used in the SHA-256 hash function. This is required to support longest match lookups in the Mapping System. The same Map-Server set needs to be selected when looking up a more-specific EID found in the Map-Request message with one that could match a less-specific EID-prefix registered and found in the Map-Register message. For example, if an EID-prefix [0]240.0.1.0/24 is registered to the Mapping System and EID [0]240.0.1.1/32 is looked up to match the registered prefix, a Hash Mask of 8 bytes can be used to AND both the /32 or /24 entries to produce the same hash string bits of "[0]240.0".
ハッシュ マスクは、SHA-256 ハッシュ関数で使用されるビットを選択するために使用されます。これは、マッピング システムで最長一致検索をサポートするために必要です。Map-Request メッセージで見つかったより具体的な EID と、Map-Register メッセージで登録され見つかった、あまり具体的ではない EID プレフィックスと一致する可能性のある EID を検索する場合、同じ Map-Server セットを選択する必要があります。たとえば、EID プレフィックス [0]240.0.1.0/24 がマッピング システムに登録されており、EID [0]240.0.1.1/32 が登録されたプレフィックスと一致するように検索される場合、8 バイトのハッシュ マスクを使用して /32 または /24 エントリの両方の AND を演算し、同じハッシュ文字列ビット "[0]240.0" を生成できます。
For (*,G) and (S,G) multicast entries in the Mapping System, the hash strings are:
マッピング システムの (*,G) および (S,G) マルチキャスト エントリの場合、ハッシュ文字列は次のとおりです。
sg-eid = "[<iid>]<group>/<gml>-<source>/<sml>"
index = hash.sha_256(sg-eid) MOD mv
starg-eid = "[<iid>]<group>/<gml>-0.0.0.0/0"
index = hash.sha_256(starg-eid) MOD mv
The Hash Mask MUST include the string "[<iid>]<group>" and not string <source>. So when looking up [0](2.2.2.2, 233.252.1.1) that will match a (*, 233.252.1.1/32), the hash string produced with a Hash Mask of 12 bytes is "[0]233.252.1.1".
ハッシュ マスクには、文字列 <source> ではなく、文字列 "[<iid>]<group>" を含める必要があります。したがって、(*, 233.252.1.1/32) に一致する [0](2.2.2.2, 233.252.1.1) を検索する場合、12 バイトのハッシュ マスクで生成されるハッシュ文字列は「[0]233.252.1.1」になります。
When the <index> is computed from a unicast or multicast EID, the DNS lookup name becomes:
<index> がユニキャストまたはマルチキャスト EID から計算される場合、DNS ルックアップ名は次のようになります。
<index>.map-server.example.com
When an xTR does a DNS lookup on the lookup name, it will send Map-Register messages to all A and AAAA records for EID registrations. For Map-Request messages, xTRs MAY round robin EID lookup requests among the A and AAAA records.
xTR がルックアップ名に対して DNS ルックアップを実行すると、EID 登録のためにすべての A および AAAA レコードに Map-Register メッセージが送信されます。Map-Request メッセージの場合、xTR は、A レコードと AAAA レコード間で EID ルックアップ要求をラウンドロビンしてもよい (MAY)。
In implementations where EID allocations follow a predictable pattern, operators MAY configure ITRs to use specific prefix lengths for lookups when the EID falls within well-known allocation ranges. This configuration allows ITRs to compute the correct hash index even when data packets carry more-specific EIDs than the prefix lengths used by ETRs during registration.
EID 割り当てが予測可能なパターンに従う実装では、EID が既知の割り当て範囲内にある場合、通信事業者はルックアップに特定のプレフィックス長を使用するように ITR を設定してもよい(MAY)。この設定により、データ パケットが ETR が登録時に使用するプレフィックス長よりも具体的な EID を伝送する場合でも、ITR は正しいハッシュ インデックスを計算できます。
For example, if an operator allocates EIDs in the range [0]240.11.0.0/16 and all ETRs register these EIDs with a /24 prefix length, ITRs receiving data packets for EIDs like [0]240.11.1.1/32 will still hash on the /24 prefix to locate the correct Map-Server. Without this configuration, the ITR would hash on the /32 and potentially query the wrong Map-Server.
たとえば、オペレータが [0]240.11.0.0/16 の範囲で EID を割り当て、すべての ETR がこれらの EID を /24 プレフィックス長で登録した場合、[0]240.11.1.1/32 のような EID のデータ パケットを受信する ITR は、引き続き /24 プレフィックスでハッシュして正しいマップ サーバーを見つけます。この設定がないと、ITR は /32 でハッシュし、間違ったマップ サーバーにクエリを実行する可能性があります。
ITRs SHOULD support configuration of EID prefix ranges and their associated lookup prefix lengths. When an ITR performs a Map-Request lookup, it SHOULD check if the destination EID matches any configured range. If a match is found, the ITR MUST use the configured lookup prefix length instead of the EID's registered prefix length when computing the hash string. When multiple configured ranges match a given EID, the range with the longest (most-specific) configured prefix length MUST be selected.
ITR は、EID プレフィックス範囲とそれに関連するルックアップ プレフィックス長の設定をサポートすべきです (SHOULD)。ITR が Map-Request ルックアップを実行するとき、宛先 EID が設定された範囲と一致するかどうかをチェックする必要があります (SHOULD)。一致が見つかった場合、ITR はハッシュ文字列を計算するときに、EID の登録されたプレフィックス長の代わりに、設定されたルックアップ プレフィックス長を使用しなければなりません (MUST)。複数の設定された範囲が特定の EID に一致する場合、最も長い (最も具体的な) 設定されたプレフィックス長を持つ範囲を選択しなければなりません (MUST)。
The configuration consists of pairs of EID-prefix (the well-known EID allocation range in Classless Inter-Domain Routing (CIDR) notation, e.g., 240.11.0.0/16) and lookup-length (the prefix length to use for hash computation when EIDs fall within this range, 0-32 bytes for IPv4 and 0-128 bytes for IPv6).
この設定は、EID プレフィックス (クラスレス ドメイン間ルーティング (CIDR) 表記におけるよく知られた EID 割り当て範囲、たとえば 240.11.0.0/16) とルックアップ長 (EID がこの範囲内にある場合にハッシュ計算に使用するプレフィックスの長さ、IPv4 の場合は 0 ～ 32 バイト、IPv6 の場合は 0 ～ 128 バイト) のペアで構成されます。
Implementation note: When computing the hash string for a lookup where the EID matches a configured range, the ITR MUST construct the hash string using the configured lookup-length, ensuring that the bits beyond the lookup-length are zero (i.e., the EID address is masked to the lookup-length before converting to the hash string format).
実装上の注意: EID が設定された範囲に一致するルックアップのハッシュ文字列を計算する場合、ITR は設定されたルックアップ長を使用してハッシュ文字列を構築し、ルックアップ長を超えるビットがゼロであることを保証しなければなりません (つまり、EID アドレスはハッシュ文字列形式に変換する前にルックアップ長にマスクされます)。
Example configuration with multiple EID ranges:
複数の EID 範囲を使用した構成例:
EID Range Configuration:
Range: [0]240.11.0.0/16 -> lookup-length: 24
Range: [0]240.12.0.0/16 -> lookup-length: 30
Range: [0]240.13.0.0/16 -> lookup-length: 25
Lookup Examples:
EID [0]240.11.1.1/32 -> hash on [0]240.11.1.0/24
EID [0]240.12.2.5/32 -> hash on [0]240.12.2.4/30
EID [0]240.13.3.7/32 -> hash on [0]240.13.3.0/25
EID [0]240.14.1.1/32 -> hash on [0]240.14.1.1/32
(no match, use full EID)
This approach is particularly useful in deployments where the Mapping System uses a consistent ETR registration strategy (e.g., all ETRs in a region register with /24 prefixes), but ITRs receive packets with more-specific destinations (/32 addresses). By configuring the expected registration prefix length for each allocation range, ITRs can reliably locate the correct Map-Servers without modifying LISP or introducing complex multi-level lookups.
このアプローチは、マッピング システムが一貫した ETR 登録戦略 (たとえば、リージョン内のすべての ETR が /24 プレフィックスで登録される) を使用するが、ITR がより具体的な宛先 (/32 アドレス) を持つパケットを受信する展開で特に役立ちます。割り当て範囲ごとに予想される登録プレフィックス長を設定することにより、ITR は、LISP を変更したり、複雑なマルチレベル ルックアップを導入したりすることなく、正しいマップ サーバーを確実に見つけることができます。
Here is an example deployment of a Decent-Pull-based model. Let's say that 4 Map-Server sets are provisioned for the Mapping System. Therefore, 4 distinct DNS names are allocated and a Modulus Value 4 is used. Each DNS name is allocated Name Index 0 through 3:
以下は、Decent-Pull ベースのモデルのデプロイ例です。4 つの Map-Server セットがマッピング システム用にプロビジョニングされているとします。したがって、4 つの異なる DNS 名が割り当てられ、モジュラス値 4 が使用されます。各 DNS 名には、名前インデックス 0 ～ 3 が割り当てられます。
0.map-server.lispers.net
1.map-server.lispers.net
2.map-server.lispers.net
3.map-server.lispers.net
The A records for each name can be assigned as:
各名前の A レコードは次のように割り当てることができます。
0.map-server.lispers.net:
A <rloc1-att>
A <rloc2-verizon>
1.map-server.lispers.net:
A <rloc1-bt>
A <rloc2-dt>
2.map-server.lispers.net:
A <rloc1-cn>
A <rloc2-kr>
3.map-server.lispers.net:
A <rloc1-au>
A <rloc2-nz>
When an xTR wants to register "[1000]fd::2222/128", it hashes the EID string to produce, for example, hash value 0x67. Using the modulus value 4 (0x67 & 0x3) produces index 0x3, so the DNS name 3.map-server.lispers.net is used and a Map-Register is sent to <rloc1-au> and <rloc2-nz>.
xTR が「[1000]fd::2222/128」を登録したい場合、EID 文字列をハッシュして、たとえばハッシュ値 0x67 を生成します。モジュラス値 4 (0x67 & 0x3) を使用するとインデックス 0x3 が生成されるため、DNS 名 3.map-server.lispers.net が使用され、Map-Register が <rloc1-au> と <rloc2-nz> に送信されます。
Note that the Decent-Pull-based method can be used for a core seed-group for bootstrapping a Decent-Push-based Mapping System where multicast groups are registered.
Decent-Pull ベースの方法は、マルチキャスト グループが登録されている Decent-Push ベースのマッピング システムをブートストラップするためのコア シード グループに使用できることに注意してください。
An implementation SHOULD do periodic DNS lookups to determine if A records have changed for a DNS entry. This is a configuration parameter the network operator selects. This specification makes no recommendation for an interval value.
実装では、DNS エントリの A レコードが変更されたかどうかを判断するために、定期的に DNS ルックアップを行う必要があります (SHOULD)。これは、ネットワーク オペレータが選択する構成パラメータです。この仕様では、間隔値については推奨しません。
When xTRs derive Map-Resolver and Map-Server names from the DNS, they need to use the same Modulus Value. Otherwise, some xTRs will look up EIDs to the wrong place they were registered.
xTR が DNS から Map-Resolver 名と Map-Server 名を取得する場合、同じモジュラス値を使用する必要があります。そうしないと、一部の xTR は登録された間違った場所で EID を検索します。
The Modulus Value can be configured or pushed to the LISP-Decent xTRs. A future version of this document will describe a push mechanism so all xTRs use a consistent modulus value.
モジュラス値は設定することも、LISP-Decent xTR にプッシュすることもできます。このドキュメントの将来のバージョンでは、すべての xTR が一貫したモジュラス値を使用するようにプッシュ メカニズムについて説明する予定です。
Refer to Section 9 of [RFC9301] for a complete list of security mechanisms as well as pointers to threat analysis documents.
セキュリティメカニズムの完全なリストと脅威分析文書へのポインタについては、[RFC9301] のセクション 9 を参照してください。
Where DNS is deployed for the Pull-based Mapping System, it is recommended to use DNSSEC [RFC9364] to add more security to the DNS lookup system.
DNS がプルベースのマッピング システムに展開されている場合は、DNSSEC [RFC9364] を使用して、DNS ルックアップ システムのセキュリティを強化することが推奨されます。
Replay attacks, spoofing, and trust relationships are discussed in detail in [RFC9301] and [RFC9303].
リプレイ攻撃、スプーフィング、および信頼関係については、[RFC9301] および [RFC9303] で詳細に説明されています。
This document has no IANA actions.
この文書には IANA のアクションはありません。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[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>.
[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>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
Ed., "Locator/ID Separation Protocol (LISP) Control
Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022,
<https://www.rfc-editor.org/info/rfc9301>.
[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>.
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/info/rfc9364>.
[RFC9437] Rodriguez-Natal, A., Ermagan, V., Cabellos, A., Barkai,
S., and M. Boucadair, "Publish/Subscribe Functionality for
the Locator/ID Separation Protocol (LISP)", RFC 9437,
DOI 10.17487/RFC9437, August 2023,
<https://www.rfc-editor.org/info/rfc9437>.
[ECDSA-AUTH]
Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA
Authentication and Authorization", Work in Progress,
Internet-Draft, draft-ietf-lisp-ecdsa-auth-16, 29 January
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
lisp-ecdsa-auth-16>.
[IETF101-PRESO]
Farinacci, D. and C. Cantrell, "A Decentralized Mapping
System: draft-farinacci-lisp-decent-00", IETF 101
Proceedings, March 2018,
<https://datatracker.ietf.org/meeting/101/materials/
slides-101-lisp-lisp-decentralized-mapping-system-00>.
[IETF104-PRESO]
Farinacci, D. and C. Cantrell, "A Decentralized Mapping
System: draft-farinacci-lisp-decent-03", IETF 104
Proceedings, March 2019,
<https://datatracker.ietf.org/meeting/104/materials/
slides-104-lisp-a-decent-lisp-mapping-system-00>.
The authors would like to thank the LISP WG for their review and acceptance of this draft.
著者らは、この草案をレビューし受け入れてくれた LISP WG に感謝したいと思います。
The authors would also like to give a special thanks to Roman Shaposhnik for several discussions that occurred before the initial draft of this document.
著者らはまた、この文書の最初の草案が作成される前に行われたいくつかの議論に対して Roman Shaposhnik に特別な感謝を表したいと思います。
Eliot Lear and Victor Moreno are appreciated for their efforts proofreading the draft before publication as an RFC.
Eliot Lear と Victor Moreno は、RFC として公開する前に草案を校正した努力に対して感謝されます。
Dino Farinacci
lispers.net
San Jose, CA
United States of America
Email: farinacci@gmail.com
Colin Cantrell
Nexus
Tempe, AZ
United States of America
Email: colin@nexus.io