[要約] RFC 9299は、Locator/ID Separation Protocol（LISP）のアーキテクチャを説明し、LISP仕様の詳細についての議論の基盤を提供するための導入的な文書です。詳細はRFC 9300および9301で確認できます。
Internet Engineering Task Force (IETF) A. Cabellos
Request for Comments: 9299 Universitat Politecnica de Catalunya
Category: Informational D. Saucez, Ed.
ISSN: 2070-1721 Inria
October 2022
An Architectural Introduction to the Locator/ID Separation Protocol (LISP)
ロケーター/ID分離プロトコル（LISP）のアーキテクチャの紹介
Abstract
概要
This document describes the architecture of the Locator/ID Separation Protocol (LISP), making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. This document is used for introductory purposes; more details can be found in the protocol specifications, RFCs 9300 and 9301.
このドキュメントでは、ロケーター/ID分離プロトコル（LISP）のアーキテクチャについて説明し、LISP仕様の残りの部分を簡単に読みやすく、LISPプロトコルの詳細に関する議論の基礎を提供します。このドキュメントは、紹介目的で使用されます。詳細については、プロトコル仕様、RFCS 9300および9301をご覧ください。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9299.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9299で取得できます。
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
2. Definitions of Terms
3. LISP Architecture
3.1. Design Principles
3.2. Overview of the Architecture
3.3. Data Plane
3.3.1. LISP Encapsulation
3.3.2. LISP Forwarding State
3.4. Control Plane
3.4.1. LISP Mappings
3.4.2. Mapping System Interface
3.4.3. Mapping System
3.5. Internetworking Mechanisms
4. LISP Operational Mechanisms
4.1. Cache Management
4.2. RLOC Reachability
4.3. ETR Synchronization
4.4. MTU Handling
5. Mobility
6. Multicast
7. Use Cases
7.1. Traffic Engineering
7.2. LISP for IPv6 Co-existence
7.3. LISP for Virtual Private Networks
7.4. LISP for Virtual Machine Mobility in Data Centers
8. Security Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. A Brief History of Location/Identity Separation
A.1. Old LISP Models
Acknowledgments
Authors' Addresses
This document introduces the Locator/ID Separation Protocol (LISP) architecture [RFC9300] [RFC9301], its main operational mechanisms, and its design rationale. Fundamentally, LISP is built following a well-known architectural idea: decoupling the overloaded semantics of IP addresses. As pointed out by Noel Chiappa [RFC4984], currently, IP addresses identify both the topological location of a network attachment point as well as the node's identity. However, nodes and routing have fundamentally different requirements. On one hand, routing systems require that addresses be aggregatable and have topological meaning; on the other hand, nodes must be identified independently of their current location [RFC4984].
このドキュメントでは、ロケーター/ID分離プロトコル（LISP）アーキテクチャ[RFC9300] [RFC9301]、その主な運用メカニズム、およびその設計理論的根拠を紹介します。基本的に、LISPは、よく知られているアーキテクチャのアイデアに従って構築されています。IPアドレスの過負荷セマンティクスの分離です。Noel Chiappa [RFC4984]が指摘したように、現在、IPアドレスは、ネットワーク添付ポイントのトポロジカル位置とノードのIDの両方を識別しています。ただし、ノードとルーティングには根本的に異なる要件があります。一方では、ルーティングシステムでは、アドレスが集約可能であり、トポロジー的な意味を持つことが必要です。一方、ノードは現在の場所とは無関係に識別する必要があります[RFC4984]。
LISP creates two separate namespaces, Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). Both are syntactically identical to the current IPv4 and IPv6 addresses. However, EIDs are used to uniquely identify nodes irrespective of their topological location and are typically routed intra-domain. RLOCs are assigned topologically to network attachment points and are typically routed inter-domain. With LISP, the edge of the Internet (where the nodes are connected) and the core (where inter-domain routing occurs) can be logically separated. LISP-capable routers interconnect the two logical spaces. LISP also introduces a database, called the Mapping System, to store and retrieve mappings between identity and location. LISP-capable routers exchange packets over the Internet core by encapsulating them to the appropriate location.
LISPは、エンドポイント識別子（EID）とルーティングロケーター（RLOC）の2つの別々の名前空間を作成します。どちらも現在のIPv4およびIPv6アドレスと構文的に同一です。ただし、EIDは、トポロジカル位置に関係なくノードを一意に識別するために使用され、通常はドメイン内にルーティングされます。RLOCは、ネットワークアタッチメントポイントにトポロジカルに割り当てられ、通常はドメイン間でルーティングされます。LISPを使用すると、インターネットのエッジ（ノードが接続されている場所）とコア（ドメイン間ルーティングが発生する場所）を論理的に分離できます。LISP対応ルーターは、2つの論理スペースを相互接続します。LISPは、マッピングシステムと呼ばれるデータベースを導入して、アイデンティティと場所の間のマッピングを保存および取得します。LISP対応ルーターは、適切な場所にカプセル化することにより、インターネットコア上でパケットを交換します。
In summary:
要約すれば：
* RLOCs have meaning only in the underlay network, that is, the underlying core routing system.
* RLOCは、アンダーレイネットワーク、つまり基礎となるコアルーティングシステムでのみ意味があります。
* EIDs have meaning only in the overlay network, which is the encapsulation relationship between LISP-capable routers.
* Eidsはオーバーレイネットワークでのみ意味があります。これは、LISP対応ルーター間のカプセル化関係です。
* The LISP edge maps EIDs to RLOCs.
* Lisp Edgeは、eidsをRLOCにマッピングします。
* Within the underlay network, RLOCs have both Locator and identifier semantics.
* アンダーレイネットワーク内では、RLOCにはロケーターと識別子セマンティクスの両方があります。
* An EID within a LISP site carries both identifier and Locator semantics to other nodes within that site.
* LISPサイト内のEIDは、そのサイト内の他のノードに識別子セマンティクスとロケーターセマンティクスの両方を運びます。
* An EID within a LISP site carries identifier and limited Locator semantics to nodes at other LISP sites (i.e., enough Locator information to tell that the EID is external to the site).
* LISPサイト内のEIDには、識別子と制限されたロケーターセマンティクスが他のLISPサイトのノードに限定されています（つまり、EIDがサイトの外部であることを示すのに十分なロケーター情報）。
The relationship described above is not unique to LISP, and it is common to other overlay technologies.
上記の関係はLISPに固有のものではなく、他のオーバーレイテクノロジーに共通しています。
The initial motivation in the LISP effort is to be found in the routing scalability problem [RFC4984], where, if LISP were to be completely deployed, the Internet core is populated with RLOCs while Traffic Engineering (TE) mechanisms are pushed to the Mapping System. In such a scenario, RLOCs are quasi-static (i.e., low churn), hence making the routing system scalable [Quoitin], while EIDs can roam anywhere with no churn to the underlying global routing system. [RFC7215] discusses the impact of LISP on the global routing system during the transition period. However, the separation between location and identity that LISP offers makes it suitable for use in additional scenarios, such as TE, multihoming, and mobility among others.
LISPの取り組みの最初の動機は、ルーティングスケーラビリティ問題[RFC4984]に見られることです。ここで、LISPが完全に展開された場合、インターネットコアにトラフィックエンジニアリング（TE）メカニズムがマッピングシステムにプッシュされている間、インターネットコアにRLOCが入力されます。。このようなシナリオでは、RLOCは準静的（つまり、低いチャーン）であるため、ルーティングシステムをスケーラブル[クオイチン]にしますが、Eidsは基礎となるグローバルルーティングシステムにチャーンなしでどこでも歩き回ることができます。[RFC7215]は、移行期間中のグローバルルーティングシステムに対するLISPの影響について説明します。ただし、LISPが提供する場所とIDの分離により、TE、Multihoming、Mobilityなどの追加のシナリオでの使用に適しています。
This document describes the LISP architecture and its main operational mechanisms as well as its design rationale. It is important to note that this document does not specify or complement LISP. The interested reader should refer to the main LISP specifications (see [RFC9300] and [RFC9301]), as well as the complementary documents (i.e., [RFC6831], [RFC6832], [RFC9302], [RFC6835], [RFC6836], and [RFC7052]) for the protocol specifications along with the LISP deployment guidelines [RFC7215].
このドキュメントでは、LISPアーキテクチャとその主要な運用メカニズム、およびその設計の理論的根拠について説明しています。このドキュメントはLISPを指定または補完しないことに注意することが重要です。興味のある読者は、メインのLISP仕様（[RFC9300]および[RFC9301]を参照）と相補的文書（つまり、[RFC6831]、[RFC6832]、[RFC9302]、[RFC6835]、[RFC6836]を参照する必要があります。および[RFC7052]）Protocol仕様とLISP展開ガイドライン[RFC7215]。
Endpoint Identifier (EID): Addresses used to uniquely identify nodes irrespective of their topological location. Typically routed intra-domain.
エンドポイント識別子（EID）：トポロジカル位置に関係なく、ノードを一意に識別するために使用されるアドレス。通常、ドメイン内をルーティングします。
Routing Locator (RLOC): Addresses assigned topologically to network attachment points. Typically routed inter-domain.
ルーティングロケーター（RLOC）：トポロジカルに割り当てられたアドレスは、ネットワーク添付ファイルポイントに割り当てられます。通常、ドメイン間をルーティングします。
Ingress Tunnel Router (ITR): A LISP-capable router that encapsulates packets from a LISP site towards the core network.
Ingress Tunnel Router（ITR）：LISPサイトからコアネットワークに向かってパケットをカプセル化するLISP対応ルーター。
Egress Tunnel Router (ETR): A LISP-capable router that decapsulates packets from the core of the network towards a LISP site.
出力トンネルルーター（ETR）：ネットワークのコアからLISPサイトにパケットを脱カプセル化するLISP対応ルーター。
xTR: A router that implements both ITR and ETR functionalities.
XTR：ITR機能とETR機能の両方を実装するルーター。
Map-Request: A LISP signaling message used to request an EID-to-RLOC mapping.
Map-Request：Eid-to-RLOCマッピングを要求するために使用されるLISPシグナル伝達メッセージ。
Map-Reply: A LISP signaling message sent in response to a Map-Request that contains a resolved EID-to-RLOC mapping.
MAP-REPLY：解決されたEIDからRLOCへのマッピングを含むMap-Requestに応じて送信されたLISP信号メッセージ。
Map-Register: A LISP signaling message used to register an EID-to-RLOC mapping.
MAP-REGISTER：EID-to-RLOCマッピングの登録に使用されるLISPシグナリングメッセージ。
Map-Notify: A LISP signaling message sent in response of a Map-Register to acknowledge the correct reception of an EID-to-RLOC mapping.
Map-notify：Eid-to-RLOCマッピングの正しい受信を認めるために、Map-Registerの応答で送信されたLISPシグナリングメッセージ。
This document describes the LISP architecture and does not introduce any new terms. The reader is referred to [RFC9300], [RFC9301], [RFC6831], [RFC6832], [RFC9302], [RFC6835], [RFC6836], [RFC7052], and [RFC7215] for the complete definition of terms.
このドキュメントでは、LISPアーキテクチャについて説明し、新しい用語を導入しません。読者は、[RFC9300]、[RFC9301]、[RFC6831]、[RFC6832]、[RFC9302]、[RFC6835]、[RFC6835]、[RFC6835]、[RFC7052]、[RFC7052]、[RFC7052]、[RFC7052]、[RFC6835]、[RFC6835]、[RFC6835]、[RFC6835]、[RFC6835]、[RFC6835]、[RFC6835]、[RFC6835]）が参照されます。
This section presents the LISP architecture. It first details the design principles of LISP, and then it proceeds to describe its main aspects: data plane, control plane, and internetworking mechanisms.
このセクションでは、LISPアーキテクチャを紹介します。まず、LISPの設計原則を詳しく説明し、次にその主な側面、データプレーン、コントロールプレーン、インターネットワークメカニズムを説明します。
The LISP architecture is built on top of four basic design principles:
LISPアーキテクチャは、4つの基本設計原則の上に構築されています。
Locator/Identifier split: Decoupling the overloaded semantics of current IP addresses allows devices to have identity-based addresses that are separate from topologically meaningful addresses. By allowing only the topologically meaningful addresses to be exposed to the Internet core, those topologically meaningful addresses can be aggregated to support substantial scaling. Individual devices are assigned identity-based addresses that are not used for forwarding in the Internet core.
ロケーター/識別子分割：現在のIPアドレスの過負荷セマンティクスをデカップすることで、デバイスがトポロジーに意味のあるアドレスとは別のアイデンティティベースのアドレスを持つことができます。トポロジーに意味のあるアドレスのみをインターネットコアにさらすことを許可することにより、これらのトポロジーに意味のあるアドレスを集計して、実質的なスケーリングをサポートできます。個々のデバイスには、インターネットコアでの転送には使用されないIDベースのアドレスが割り当てられます。
Overlay architecture: This architecture overlays route packets over the current Internet, allowing deployment of new protocols without changing the current infrastructure; hence, this results in a low deployment cost.
オーバーレイアーキテクチャ：このアーキテクチャは、現在のインターネット上のルートパケットをオーバーレイし、現在のインフラストラクチャを変更せずに新しいプロトコルの展開を可能にします。したがって、これにより展開コストが低くなります。
Decoupled data plane and control plane: Separating the data plane from the control plane allows them to scale independently and use different architectural approaches. This is important given that they typically have different requirements and allows for other data planes to be added. Even though the data plane and the control plane are decoupled, they are not completely isolated, because the LISP data plane may trigger control plane activity.
分離されたデータプレーンと制御プレーン：データプレーンを制御プレーンから分離すると、独立してスケーリングし、さまざまなアーキテクチャアプローチを使用できます。これは、通常、異なる要件を持ち、他のデータプレーンを追加できることを考えると重要です。データプレーンとコントロールプレーンは分離されていますが、LISPデータプレーンがコントロールプレーンのアクティビティをトリガーする可能性があるため、完全に分離されていません。
Incremental deployability: This principle ensures that the protocol interoperates with the legacy Internet while providing some of the targeted benefits to early adopters.
増分展開可能性：この原則により、プロトコルがレガシーインターネットと相互運用しながら、早期採用者にターゲットを絞ったメリットの一部を提供することが保証されます。
LISP architecturally splits the core from the edge of the Internet by creating two separate namespaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). The edge consists of LISP sites (e.g., an Autonomous System) that use EID addresses. EIDs are IPv4 or IPv6 addresses that uniquely identify communication end hosts and are assigned and configured by the same mechanisms that exist at the time of this writing. EIDs do not contain inter-domain topological information, and because of this, EIDs are usually routable at the edge (within LISP sites) but not in the core; see Section 3.5 for discussion of LISP site internetworking with non-LISP sites and domains in the Internet.
LISPは、エンドポイント識別子（EID）とルーティングロケーター（RLOC）の2つの別々の名前空間を作成することにより、インターネットの端からコアをアーキテクタルに分割します。エッジは、EIDアドレスを使用するLISPサイト（たとえば、自律システム）で構成されています。EIDは、通信エンドホストを一意に識別し、この執筆時点で存在する同じメカニズムによって割り当てられ、構成されているIPv4またはIPv6アドレスです。Eidsにはドメイン間のトポロジー情報が含まれていません。このため、Eidsは通常、エッジ（LISPサイト内）でルーティング可能ですが、コアではありません。インターネット内の非リスプサイトとドメインを使用したLISPサイトのインターネットワークの議論については、セクション3.5を参照してください。
LISP sites (at the edge) are connected to the interconnecting core of the Internet by means of LISP-capable routers (e.g., border routers). LISP sites are connected across the interconnecting core of the Internet using tunnels between the LISP-capable routers. When packets originated from a LISP site are flowing towards the core network, they ingress into an encapsulated tunnel via an Ingress Tunnel Router (ITR). When packets flow from the core network to a LISP site, they egress from an encapsulated tunnel to an Egress Tunnel Router (ETR). An xTR is a router that can perform both ITR and ETR operations. In this context, ITRs encapsulate packets, while ETRs decapsulate them; hence, LISP operates as an overlay on top of the current Internet core.
LISPサイト（エッジ）は、LISP対応ルーター（境界ルーターなど）を使用して、インターネットの相互接続コアに接続されています。LISPサイトは、LISP対応ルーター間のトンネルを使用して、インターネットの相互接続コア全体に接続されています。LISPサイトから生まれたパケットがコアネットワークに向かって流れると、イングレストンネルルーター（ITR）を介してカプセル化されたトンネルに侵入します。パケットがコアネットワークからLISPサイトに流れると、カプセル化されたトンネルから出口トンネルルーター（ETR）に脱出します。XTRは、ITR操作とETR操作の両方を実行できるルーターです。これに関連して、ITRはパケットをカプセル化しますが、ETRはそれらを脱カプセル化します。したがって、LISPは現在のインターネットコアの上にオーバーレイとして動作します。
/-----------------\ ---
| Mapping | |
. System | | Control
-| |`, | Plane
,' \-----------------/ . |
/ | ---
,.., - _,....,, | ,.., |
/ ` ,' ,-` `', | / ` |
/ \ +-----+ ,' `, +-----+ / \ |
| EID |-| xTR |--/ RLOC ,--| xTR |-| EID | | Data
| Space |-| |--| Space |--| |-| Space | | Plane
\ / +-----+ . / +-----+ \ / |
`. .' `. ,' `. .' |
`'-` `., ,.' `'-` ---
``'''``
LISP Site (Edge) Core LISP Site (Edge)
Figure 1: A Schema of the LISP Architecture
図1：LISPアーキテクチャのスキーマ
With LISP, the core uses RLOCs. An RLOC is an IPv4 or IPv6 address assigned to a core-facing network interface of an ITR or ETR.
LISPを使用すると、CoreはRLOCを使用します。RLOCは、ITRまたはETRのコア向けネットワークインターフェイスに割り当てられたIPv4またはIPv6アドレスです。
A database that is typically distributed, called the Mapping System, stores mappings between EIDs and RLOCs. Such mappings relate the identity of the devices attached to LISP sites (EIDs) to the set of RLOCs configured at the LISP-capable routers servicing the site. Furthermore, the mappings also include TE policies and can be configured to achieve multihoming and load balancing. The LISP Mapping System is conceptually similar to the DNS, where it is organized as a distributed multi-organization network database. With LISP, ETRs register mappings, while ITRs retrieve them.
マッピングシステムと呼ばれる通常、分散されるデータベースは、EIDとRLOCの間にマッピングを保存します。このようなマッピングは、LISPサイト（EIDS）に接続されたデバイスのIDを、サイトにサービスを提供するLISP対応ルーターで構成されたRLOCのセットに関連付けられています。さらに、マッピングにはTEポリシーも含まれており、マルチホームと負荷のバランスを実現するように構成できます。LISPマッピングシステムは、DNSと概念的に類似しており、分散マルチエイジングネットワークデータベースとして編成されています。LISPを使用すると、ETRSはマッピングを登録し、ITRはそれらを取得します。
Finally, the LISP architecture emphasizes incremental deployment. Given that LISP represents an overlay to the current Internet architecture, end hosts, as well as intra-domain and inter-domain routers, remain unchanged. The only required changes to the existing infrastructure are to routers connecting the EID space with the RLOC space. Additionally, LISP requires the deployment of an independent Mapping System; such a distributed database is a new network entity.
最後に、LISPアーキテクチャは増分展開を強調しています。LISPが現在のインターネットアーキテクチャのオーバーレイを表していることを考えると、ドメイン内およびドメイン間のルーターと同様に、エンドホスト、およびドメイン間ルーターは変更されていません。既存のインフラストラクチャに必要な変更唯一の変更は、EIDスペースをRLOCスペースと接続するルーターです。さらに、LISPでは、独立したマッピングシステムの展開が必要です。このような分散データベースは、新しいネットワークエンティティです。
The following describes a simplified packet flow sequence between two nodes that are attached to LISP sites. Please note that typical LISP-capable routers are xTRs (both ITR and ETR). Client HostA wants to send a packet to server HostB.
以下は、LISPサイトに接続されている2つのノード間の簡略化されたパケットフローシーケンスを説明しています。典型的なLISP対応ルーターはXTR（ITRとETRの両方）であることに注意してください。クライアントHostaは、Server HostBにパケットを送信したいと考えています。
/----------------\
| Mapping |
| System |
.| |-
` \----------------/ `.
,` \
/ `.
,' _,..-..,, ',
/ -` `-, \
.' ,' \ `,
` ' \ '
+-----+ | | RLOC_B1+-----+
HostA | | | RLOC |-------| | HostB
EID_A--|ITR_A|----| Space | |ETR_B|--EID_B
| | RLOC_A1 |-------| |
+-----+ | | RLOC_B2+-----+
, /
\ /
`', ,-`
``''-''``
Figure 2: Packet Flow Sequence in LISP
図2：LISPのパケットフローシーケンス
1. HostA retrieves the EID_B of HostB, typically querying the DNS and obtaining an A or AAAA record. Then, it generates an IP packet as in the Internet. The packet has source address EID_A and destination address EID_B.
1. Hostaは、HostBのEID_Bを取得し、通常はDNSを照会し、AまたはAAAAレコードを取得します。次に、インターネットのようにIPパケットを生成します。パケットには、ソースアドレスEID_Aと宛先アドレスEID_Bがあります。
2. The packet is forwarded towards ITR_A in the LISP site using standard intra-domain mechanisms.
2. このパケットは、標準のドメイン内メカニズムを使用して、LISPサイトのITR_Aに転送されます。
3. ITR_A, upon receiving the packet, queries the Mapping System to retrieve the Locator of ETR_B that is servicing HostB's EID_B. In order to do so, it uses a LISP control message called Map-Request. The message contains EID_B as the lookup key. In turn, it receives another LISP control message called Map-Reply. The message contains two Locators: RLOC_B1 and RLOC_B2. It also contains TE policies: priority and weight per Locator. Note that a Map-Reply can contain more Locators if needed. ITR_A can cache the mapping in local storage to speed up forwarding of subsequent packets.
3. ITR_Aは、パケットを受信すると、マッピングシステムをクエリして、HostBのEID_Bにサービスを提供しているETR_Bのロケーターを取得します。そうするために、Map-RequestというLISPコントロールメッセージを使用します。メッセージには、eid_bがルックアップキーとして含まれています。次に、Map-Replyと呼ばれる別のLispコントロールメッセージを受信します。メッセージには、RLOC_B1とRLOC_B2の2つのロケーターが含まれています。また、TEポリシー：ロケーターごとの優先度と重量も含まれています。必要に応じて、マップ対応にはより多くのロケーターを含めることができることに注意してください。ITR_Aは、ローカルストレージのマッピングをキャッシュして、後続のパケットの転送を高速化できます。
4. ITR_A encapsulates the packet towards RLOC_B1 (chosen according to the priorities/weights specified in the mapping). The packet contains two IP headers. The outer header has RLOC_A1 as source and RLOC_B1 as destination. The inner original header has EID_A as source and EID_B as destination. Furthermore, ITR_A adds a LISP header. More details about LISP encapsulation can be found in Section 3.3.1.
4. ITR_Aは、RLOC_B1に向かってパケットをカプセル化します（マッピングで指定された優先順位/重みに従って選択）。パケットには2つのIPヘッダーが含まれています。外側のヘッダーには、ソースとしてRLOC_A1、宛先としてRLOC_B1があります。内側のオリジナルヘッダーには、eid_aがソースとして、eid_bは宛先としてあります。さらに、ITR_AはLISPヘッダーを追加します。LISPカプセル化の詳細については、セクション3.3.1をご覧ください。
5. The encapsulated packet is forwarded over the interconnecting core as a normal IP packet, making the EID invisible from the core.
5. カプセル化されたパケットは、相互接続コアに通常のIPパケットとして転送され、EIDがコアから見えなくなります。
6. Upon reception of the encapsulated packet by ETR_B, it decapsulates the packet and forwards it to HostB.
6. ETR_Bによってカプセル化されたパケットが受信されると、パケットを脱カプセル化し、HOSTBに転送します。
This section provides a high-level description of the LISP data plane, which is specified in detail in [RFC9300]. The LISP data plane is responsible for encapsulating and decapsulating data packets and caching the appropriate forwarding state. It includes two main entities, the ITR and the ETR. Both are LISP-capable routers that connect the EID with the RLOC space (ITR) and vice versa (ETR).
このセクションでは、[RFC9300]で詳細に指定されているLISPデータプレーンの高レベルの説明を提供します。LISPデータプレーンは、データパケットのカプセル化と脱カプセル化、および適切な転送状態のキャッシュを担当します。ITRとETRの2つの主要なエンティティが含まれます。どちらも、EIDをRLOCスペース（ITR）とその逆（ETR）に接続するLISP対応ルーターです。
ITRs encapsulate data packets towards ETRs. LISP data packets are encapsulated using UDP (port 4341). The source port is usually selected by the ITR using a 5-tuple hash of the inner header (so as to be consistent in case of multipath solutions, such as ECMP [RFC2992]) and ignored on reception. LISP data packets are often encapsulated in UDP packets that include a zero checksum [RFC6935] [RFC6936] that may not be verified when it is received, because LISP data packets typically include an inner transport protocol header with a non-zero checksum. The use of UDP zero checksums over IPv6 for all tunneling protocols like LISP is subject to the applicability statement in [RFC6936]. If LISP data packets are encapsulated in UDP packets with non-zero checksums, the outer UDP checksums are verified when the UDP packets are received, as part of normal UDP processing.
ITRSは、データパケットをETRに向けてカプセル化します。LISPデータパケットは、UDP（ポート4341）を使用してカプセル化されています。ソースポートは通常、内側のヘッダーの5タプルハッシュを使用してITRによって選択されます（ECMP [RFC2992]などのマルチパスソリューションの場合に一貫性があるように）、レセプションで無視されます。LISPデータパケットは、LISPデータパケットが通常ゼロチェックサムを持つ内部輸送プロトコルヘッダーを含むため、受信時に検証されない可能性のあるゼロチェックサム[RFC6935] [RFC6936]を含むUDPパケットにカプセル化されることがよくあります。LISPのようなすべてのトンネルプロトコルにIPv6を介したUDPゼロチェックサムの使用は、[RFC6936]の適用声明の対象となります。LISPデータパケットがゼロ以外のチェックサムを備えたUDPパケットにカプセル化されている場合、通常のUDP処理の一部として、UDPパケットが受信されたときに外側のUDPチェックサムが確認されます。
LISP-encapsulated packets also include a LISP header (after the UDP header and before the original IP header). The LISP header is prepended by ITRs and stripped by ETRs. It carries reachability information (see more details in Section 4.2) and the 'Instance ID' field. The 'Instance ID' field is used to distinguish traffic to/ from different tenant address spaces at the LISP site, and this use of the Instance ID may use overlapped but logically separated EID addressing.
LISPにカプセル化されたパケットには、LISPヘッダーも含まれています（UDPヘッダーの後、元のIPヘッダーの前）。LISPヘッダーはITRによって準備され、ETRSによって剥がされます。到達可能な情報（セクション4.2の詳細を参照）と「インスタンスID」フィールドが含まれています。「インスタンスID」フィールドは、LISPサイトのさまざまなテナントアドレススペースとのトラフィックを区別するために使用され、インスタンスIDのこの使用は、重複しているが論理的に分離されたEIDアドレス指定を使用する場合があります。
Overall, LISP works on 4 headers: the inner header the source constructed and the 3 headers a LISP encapsulator prepends ("outer" to "inner"):
全体として、LISPは4つのヘッダーで動作します。ソースが構築された内部ヘッダー、3つのヘッダーがLisp Encapsator Prepends（「外側」から「内側」）：
1. Outer IP header containing RLOCs as source and destination addresses. This header is originated by ITRs and stripped by ETRs.
1. ソースアドレスおよび宛先アドレスとしてRLOCを含む外部IPヘッダー。このヘッダーはITRから発信され、ETRSによって剥がされます。
2. UDP header (port 4341), usually with zero checksum. This header is originated by ITRs and stripped by ETRs.
2. UDPヘッダー（ポート4341）、通常はチェックサムがゼロ。このヘッダーはITRから発信され、ETRSによって剥がされます。
3. LISP header that contains various forwarding-plane features (such as reachability) and an 'Instance ID' field. This header is originated by ITRs and stripped by ETRs.
3. さまざまな転送面の機能（到達可能性など）と「インスタンスID」フィールドを含むLISPヘッダー。このヘッダーはITRから発信され、ETRSによって剥がされます。
4. Inner IP header containing EIDs as source and destination addresses. This header is created by the source end host and is left unchanged by the LISP data plane processing on the ITR and ETR.
4. ソースおよび宛先アドレスとしてEidsを含む内部IPヘッダー。このヘッダーは、ソースエンドホストによって作成され、ITRおよびETRでのLISPデータプレーン処理によって変更されていません。
Finally, in some scenarios, re-encapsulating and/or recursive tunnels are useful to choose a specified path in the underlay network, for instance, to avoid congestion or failure. Re-encapsulating tunnels are consecutive LISP tunnels and occur when a decapsulator (an ETR action) removes a LISP header and then acts as an encapsulator (an ITR action) to prepend another one. On the other hand, recursive tunnels are nested tunnels and are implemented by using multiple LISP encapsulations on a packet. Such functions are implemented by Re-encapsulating Tunnel Routers (RTRs). An RTR can be thought of as a router that first acts as an ETR by decapsulating packets and then as an ITR by encapsulating them towards another Locator; more information can be found in [RFC9300] and [RFC9301].
最後に、いくつかのシナリオでは、輻輳や障害を避けるために、アンダーレイネットワークで指定されたパスを選択するのに役立ちます。再カプセルのトンネルは連続したLISPトンネルであり、脱カプセレーター（ETRアクション）がLISPヘッダーを除去し、その後、エンカプセーター（ITRアクション）として機能して別のものを準備するときに発生します。一方、再帰トンネルはネストされたトンネルであり、パケットに複数のLISPカプセルを使用して実装されます。このような関数は、トンネルルーター（RTR）の再エンコールによって実装されます。RTRは、最初にパケットを脱カプセル化することによりETRとして機能し、次にそれらを別のロケーターにカプセル化することによりITRとして機能するルーターと考えることができます。詳細については、[RFC9300]および[RFC9301]をご覧ください。
In the LISP architecture, ITRs keep just enough information to route traffic flowing through them. In other words, ITRs only need to retrieve from the LISP Mapping System mappings between EID-Prefixes (blocks of EIDs) and RLOCs that are used to encapsulate packets. Such mappings are stored in a local cache called the LISP Map-Cache for subsequent packets addressed to the same EID-Prefix. Note that in the case of overlapping EID-Prefixes, after a request, the ITR may receive a set of mappings covering the requested EID-Prefix and all more-specific EID-Prefixes (cf., Section 5.5 of [RFC9301]). Mappings include a Time to Live (TTL) (set by the ETR). More details about the Map-Cache management can be found in Section 4.1.
LISPアーキテクチャでは、ITRはそれらを流れるトラフィックをルーティングするのに十分な情報を保持します。言い換えれば、ITRは、パケットをカプセル化するために使用されるEID-Prefixes（EIDのブロック）とRLOCの間のLISPマッピングシステムマッピングから取得するだけです。このようなマッピングは、同じEid-Prefixにアドレス指定された後続のパケットのために、LISPマップキャッシュと呼ばれるローカルキャッシュに保存されます。Eid-Prefixesが重複する場合、要求後、ITRは要求されたEid-Prefixおよびすべてのより特定のEid-Prefixesをカバーする一連のマッピングを受信する場合があることに注意してください（[RFC9301]のセクション5.5を参照）。マッピングには、A Time to Live（TTL）（ETRによって設定）が含まれます。マップキャッシュ管理の詳細については、セクション4.1をご覧ください。
The LISP control plane, specified in [RFC9301], provides a standard interface to register and request mappings. The LISP Mapping System is a database that stores such mappings. The following sub-sections first describe the mappings, then the standard interface to the Mapping System, and finally its architecture.
[RFC9301]で指定されたLISP制御プレーンは、マッピングを登録および要求する標準インターフェイスを提供します。LISPマッピングシステムは、そのようなマッピングを保存するデータベースです。次のサブセクションでは、最初にマッピング、次にマッピングシステムへの標準インターフェイス、そして最後にそのアーキテクチャについて説明します。
Each mapping includes the bindings between EID-Prefix(es) and a set of RLOCs as well as TE policies, in the form of priorities and weights for the RLOCs. Priorities allow the ETR to configure active/ backup policies, while weights are used to load-balance traffic among the RLOCs (on a per-flow basis).
各マッピングには、RLOCの優先順位と重みの形で、EID-Prefix（ES）とRLOCのセットとTEポリシーの間のバインディングが含まれます。優先順位により、ETRはアクティブ/バックアップポリシーを構成しますが、重みはRLOC間のトラフィックを負荷するために使用されます（流量ごとに）。
Typical mappings in LISP bind EIDs in the form of IP prefixes with a set of RLOCs, also in the form of IP addresses. IPv4 and IPv6 addresses are encoded using the appropriate Address Family Identifier (AFI) [RFC8060]. However, LISP can also support more general address encoding by means of the ongoing effort around the LISP Canonical Address Format (LCAF) [RFC8060].
LISPの典型的なマッピングは、IPアドレスの形でも、RLOCのセットを持つIPプレフィックスの形でEIDを結合します。IPv4およびIPv6アドレスは、適切なアドレスファミリ識別子（AFI）[RFC8060]を使用してエンコードされます。ただし、LISPは、LISP Canonicalアドレス形式（LCAF）[RFC8060]をめぐる継続的な取り組みによって、より一般的なアドレスエンコードをサポートできます。
With such a general syntax for address encoding in place, LISP aims to provide flexibility to current and future applications. For instance, LCAFs could support Media Access Control (MAC) addresses, geocoordinates, ASCII names, and application-specific data.
LISPは、このような一般的な構文を設置するアドレスエンコードを使用して、現在および将来のアプリケーションに柔軟性を提供することを目指しています。たとえば、LCAFSは、メディアアクセス制御（MAC）アドレス、地理調の、ASCII名、およびアプリケーション固有のデータをサポートできます。
LISP defines a standard interface between data and control planes. The interface is specified in [RFC9301] and defines two entities:
LISPは、データと制御プレーンの間の標準インターフェイスを定義します。インターフェイスは[RFC9301]で指定され、2つのエンティティを定義します。
Map-Server: A network infrastructure component that learns mappings from ETRs and publishes them into the LISP Mapping System. Typically, Map-Servers are not authoritative to reply to queries; hence, they forward them to the ETR. However, they can also operate in proxy-mode, where the ETRs delegate replying to queries to Map-Servers. This setup is useful when the ETR has limited resources (e.g., CPU or power).
MAP-SERVER：ETRからマッピングを学習し、それらをLISPマッピングシステムに公開するネットワークインフラストラクチャコンポーネント。通常、地図サーバーはクエリに返信する権威がありません。したがって、彼らはそれらをETRに転送します。ただし、Proxy-Modeで動作することもできます。Proxy-Modeでは、ETRS委任がマップサーバーにクエリに返信します。このセットアップは、ETRのリソース（CPUや電力など）が限られている場合に役立ちます。
Map-Resolver: A network infrastructure component that interfaces ITRs with the Mapping System by proxying queries and, in some cases, responses.
MAP-Resolver：クエリをプロキシをプロキシ、場合によっては応答することにより、マッピングシステムとインターフェイスするネットワークインフラストラクチャコンポーネント。
The interface defines four LISP control messages that are sent as UDP datagrams (port 4342):
インターフェイスは、UDPデータグラム（ポート4342）として送信される4つのLISP制御メッセージを定義します。
Map-Register: This message is used by ETRs to register mappings in the Mapping System, and it is authenticated using a shared key between the ETR and the Map-Server.
MAP-REGISTER：このメッセージは、ETRSによってマッピングシステムにマッピングを登録するために使用され、ETRとMap-Serverの間の共有キーを使用して認証されます。
Map-Notify: When requested by the ETR, this message is sent by the Map-Server in response to a Map-Register to acknowledge the correct reception of the mapping and convey the latest Map-Server state on the EID-to-RLOC mapping. In some cases, a Map-Notify can be sent to the previous RLOCs when an EID is registered by a new set of RLOCs.
Map-notify：ETRによって要求された場合、このメッセージはマップレジスターに応じてマップサーバーによって送信され、マッピングの正しい受信を認め、EIDからRLOCマッピングの最新のマップサーバー状態を伝えます。場合によっては、EIDが新しいRLOCSセットによって登録されている場合、MAP-Notifyを前のRLOCに送信できます。
Map-Request: This message is used by ITRs or Map-Resolvers to resolve the mapping of a given EID.
Map-Request：このメッセージは、ITRまたはMap-Resolversによって使用され、特定のEIDのマッピングを解決します。
Map-Reply: This message is sent by Map-Servers or ETRs in response to a Map-Request and contains the resolved mapping. Please note that a Map-Reply may contain a negative reply if, for example, the queried EID is not part of the LISP EID space. In such cases, the ITR typically forwards the traffic as is (non-encapsulated) to the public Internet. This behavior is defined to support incremental deployment of LISP.
MAP-Reply：このメッセージは、Map-Requestに応じてMap-ServersまたはETRによって送信され、解決されたマッピングが含まれています。たとえば、Queried EidがLisp Eidスペースの一部ではない場合、マップ応答には否定的な返信が含まれる場合があることに注意してください。そのような場合、ITRは通常、トラフィックをパブリックインターネットにそのまま（非カプセル化）に転送します。この動作は、LISPの増分展開をサポートするために定義されます。
LISP architecturally decouples control and data planes by means of a standard interface. This interface glues the data plane -- routers responsible for forwarding data packets -- with the LISP Mapping System -- a database responsible for storing mappings.
LISPは、標準インターフェイスを使用して、コントロールおよびデータプレーンをアーキテクチャに分離します。このインターフェイスは、マッピングの保存を担当するデータベースであるLISPマッピングシステムを使用して、データプレーン（データパケットの転送を担当するルーター）を接着します。
With this separation in place, the data and control planes can use different architectures if needed and scale independently. Typically, the data plane is optimized to route packets according to hierarchical IP addresses. However, the control plane may have different requirements, for instance, and by taking advantage of the LCAFs, the Mapping System may be used to store nonhierarchical keys (such as MAC addresses), requiring different architectural approaches for scalability. Another important difference between the LISP control and data planes is that, and as a result of the local mapping cache available at the ITR, the Mapping System does not need to operate at line-rate.
この分離が整っていると、データと制御プレーンは、必要に応じて異なるアーキテクチャを使用し、独立してスケーリングできます。通常、データプレーンは、階層IPアドレスに従ってパケットをルーティングするように最適化されます。ただし、たとえば、制御プレーンには異なる要件がある場合があり、LCAFSを活用することにより、マッピングシステムを使用して非階層キー（MACアドレスなど）を保存するために使用でき、スケーラビリティのためにさまざまなアーキテクチャアプローチが必要です。LISP制御プレーンとデータプレーンのもう1つの重要な違いは、ITRで利用可能なローカルマッピングキャッシュの結果として、マッピングシステムはラインレートで動作する必要がないことです。
Many of the existing mechanisms to create distributed systems have been explored and considered for the Mapping System architecture: graph-based databases in the form of LISP Alternative Logical Topology (LISP-ALT) [RFC6836], hierarchical databases in the form of the LISP Delegated Database Tree (LISP-DDT) [RFC8111], monolithic databases in the form of the LISP Not-so-novel EID-to-RLOC Database (LISP-NERD) [RFC6837], flat databases in the form of the LISP Distributed Hash Table (LISP-DHT) [LISP-SHDHT] [Mathy], and a multicast-based database [LISP-EMACS]. Furthermore, it is worth noting that, in some scenarios, such as private deployments, the Mapping System can operate as logically centralized. In such cases, it is typically composed of a single Map-Server/Map-Resolver.
分散システムを作成するための既存のメカニズムの多くは、マッピングシステムアーキテクチャのために検討および考慮されています：LISP代替論理トポロジ（LISP-ALT）[RFC6836]、LISP委任委任形の階層データベースの形のグラフベースのデータベースデータベースツリー（LISP-DDT）[RFC8111]、LISP NOT-NOVEL EID-TO-RLOCデータベース（LISP-NERD）[RFC6837]の形のモノリシックデータベース、LISP分布のハッシュテーブルの形のフラットデータベース（lisp-dht）[lisp-shdht] [mathy]、およびマルチキャストベースのデータベース[lisp-emacs]。さらに、プライベート展開などの一部のシナリオでは、マッピングシステムが論理的に集中化されているように動作できることに注意する価値があります。そのような場合、それは通常、単一のMap-Server/Map-Resolverで構成されています。
The following sub-sections focus on the two Mapping Systems that have been implemented and deployed (LISP-ALT and LISP-DDT).
次のサブセクションは、実装および展開された2つのマッピングシステム（LISP-ALTおよびLISP-DDT）に焦点を当てています。
LISP-ALT [RFC6836] was the first Mapping System proposed, developed, and deployed on the LISP pilot network. It is based on a distributed BGP overlay in which Map-Servers and Map-Resolvers participate. The nodes connect to their peers through static tunnels. Each Map-Server involved in the ALT topology advertises the EID-Prefixes registered by the serviced ETRs, making the EID routable on the ALT topology.
LISP-ALT [RFC6836]は、LISPパイロットネットワークに提案、開発、展開された最初のマッピングシステムでした。これは、マップサーバーとマップリゾルバーが参加する分散BGPオーバーレイに基づいています。ノードは、静的なトンネルを介して仲間に接続します。ALTトポロジに関与する各マップサーバーは、サービスされたETRによって登録されたEid-Prefixesを宣伝し、ALTトポロジでEIDをルーティング可能にします。
When an ITR needs a mapping, it sends a Map-Request to a Map-Resolver that, using the ALT topology, forwards the Map-Request towards the Map-Server responsible for the mapping. Upon reception, the Map-Server forwards the request to the ETR, which in turn replies directly to the ITR.
ITRがマッピングを必要とする場合、ALTトポロジーを使用して、マッピングを担当するマップサーバーにマップリケストを転送するマップリゾルバーにマップリケストを送信します。受信すると、Map-ServerはリクエストをETRに転送し、ETRはITRに直接返信します。
LISP-DDT [RFC8111] is conceptually similar to the DNS, a hierarchical directory whose internal structure mirrors the hierarchical nature of the EID address space. The DDT hierarchy is composed of DDT nodes forming a tree structure; the leafs of the tree are Map-Servers. On top of the structure, there is the DDT root node, which is a particular instance of a DDT node, that matches the entire address space. As in the case of DNS, DDT supports multiple redundant DDT nodes and/or DDT roots. Finally, Map-Resolvers are the clients of the DDT hierarchy and can query the DDT root and/or other DDT nodes.
LISP-DDT [RFC8111]は、内部構造がEIDアドレス空間の階層的性質を反映した階層ディレクトリであるDNSと概念的に類似しています。DDT階層は、ツリー構造を形成するDDTノードで構成されています。木の葉は地図サーバーです。構造の上に、DDTルートノードがあります。これは、DDTノードの特定のインスタンスであり、アドレス空間全体に一致します。DNSの場合と同様に、DDTは複数の冗長DDTノードおよび/またはDDTルートをサポートします。最後に、MAP-ResolversはDDT階層のクライアントであり、DDTルートおよび/または他のDDTノードを照会できます。
/---------\
| |
| DDT Root|
| /0 |
,.\---------/-,
,-'` | `'.,
-'` | `-
/-------\ /-------\ /-------\
| DDT | | DDT | | DDT |
| Node | | Node | | Node | ...
| 0/8 | | 1/8 | | 2/8 |
\-------/ \-------/ \-------/
_. _. . -..,,,_
-` -` \ ````''--
+------------+ +------------+ +------------+ +------------+
| Map-Server | | Map-Server | | Map-Server | | Map-Server |
| EID-Prefix1| | EID-Prefix2| | EID-Prefix3| | EID-Prefix4|
+------------+ +------------+ +------------+ +------------+
Figure 3: A Schematic Representation of the DDT Tree Structure
図3：DDTツリー構造の概略図
Please note that the prefixes and the structure depicted in the figure above should only be considered as an example.
上記の図に描かれている接頭辞と構造は、例としてのみ考慮されるべきであることに注意してください。
The DDT structure does not actually index EID-Prefixes; rather, it indexes Extended EID-Prefixes (XEID-Prefixes). An XEID-Prefix is just the concatenation of the following fields (from most significant bit to less significant bits): Database-ID, Instance ID, Address Family Identifier, and the actual EID-Prefix. The Database-ID is provided for possible future requirements of higher levels in the hierarchy and to enable the creation of multiple and separate database trees.
DDT構造は、実際にはEid-Prefixesをインデックスしません。むしろ、拡張されたeid-prefixes（xeid-prefixes）にインデックスを付けます。Xeid-Prefixは、次のフィールド（最も重要なビットから重要性の低いビットまで）の単なる連結です：データベースID、インスタンスID、アドレスファミリ識別子、および実際のEID-Prefix。データベースIDは、階層のより高いレベルの将来の要件の可能性があり、複数の個別のデータベースツリーの作成を可能にするために提供されます。
In order to resolve a query, LISP-DDT operates in a similar way to the DNS but only supports iterative lookups. DDT clients (usually Map-Resolvers) generate Map-Requests to the DDT root node. In response, they receive a newly introduced LISP control message: a Map-Referral. A Map-Referral provides the list of RLOCs of the set of DDT nodes matching a configured XEID delegation. That is, the information contained in the Map-Referral points to the child of the queried DDT node that has more specific information about the queried XEID-Prefix. This process is repeated until the DDT client walks the tree structure (downwards) and discovers the Map-Server servicing the queried XEID. At this point, the client sends a Map-Request and receives a Map-Reply containing the mappings. It is important to note that DDT clients can also cache the information contained in Map-Referrals; that is, they cache the DDT structure. This is used to reduce the time required to retrieve mappings [Jakab].
クエリを解決するために、LISP-DDTはDNSと同様の方法で動作しますが、反復検索のみをサポートします。DDTクライアント（通常はMAP-Resolvers）は、DDTルートノードにMAP-Requestsを生成します。それに応じて、彼らは新しく導入されたLISPコントロールメッセージ：マップリファレンを受け取ります。MAP-Referralは、構成されたXEID委任と一致するDDTノードのセットのRLOCのリストを提供します。つまり、マップ参照に含まれる情報は、クエリXeid-Prefixに関するより具体的な情報を持つクエリDDTノードの子を指します。このプロセスは、DDTクライアントがツリー構造（下向き）を歩き（下向き）、クエリXeidをサービスするマップサーバーを発見するまで繰り返されます。この時点で、クライアントはマップレクエストを送信し、マッピングを含むマップ応答を受信します。DDTクライアントは、MAP-Referralsに含まれる情報をキャッシュすることもできることに注意することが重要です。つまり、DDT構造をキャッシュします。これは、マッピングを取得するのに必要な時間を短縮するために使用されます[Jakab]。
The DDT Mapping System relies on manual configuration. That is, Map-Resolvers are configured with the set of available DDT root nodes, while DDT nodes are configured with the appropriate XEID delegations. Configuration changes in the DDT nodes are only required when the tree structure changes itself, but it doesn't depend on EID dynamics (RLOC allocation or TE policy changes).
DDTマッピングシステムは、手動構成に依存しています。つまり、MAP-Resolversは利用可能なDDTルートノードのセットで構成され、DDTノードは適切なXEID委任で構成されています。DDTノードの構成の変更は、ツリー構造自体が変更された場合にのみ必要ですが、EIDダイナミクス（RLOC割り当てまたはTEポリシーの変更）に依存しません。
EIDs are typically identical to either IPv4 or IPv6 addresses, and they are stored in the LISP Mapping System. However, they are usually not announced in the routing system beyond the local LISP domain. As a result, LISP requires an internetworking mechanism to allow LISP sites to speak with non-LISP sites and vice versa. LISP internetworking mechanisms are specified in [RFC6832].
EIDは通常、IPv4またはIPv6アドレスと同一であり、LISPマッピングシステムに保存されます。ただし、通常、ローカルLISPドメインを超えたルーティングシステムでは発表されません。その結果、LISPでは、LISPサイトが非リスプサイトと話すことができるように、インターネットワークメカニズムを必要とします。その逆も同様です。LISPインターネットワークメカニズムは[RFC6832]で指定されています。
LISP defines two entities to provide internetworking:
LISPは、インターネットワークを提供する2つのエンティティを定義します。
Proxy Ingress Tunnel Router (PITR): PITRs provide connectivity from the legacy Internet to LISP sites. PITRs announce in the global routing system blocks of EID-Prefixes (aggregating when possible) to attract traffic. For each incoming packet from a source not in a LISP site (a non-EID), the PITR LISP-encapsulates it towards the RLOC(s) of the appropriate LISP site. The impact of PITRs on the routing table size of the Default-Free Zone (DFZ) is, in the worst case, similar to the case in which LISP is not deployed. EID-Prefixes will be aggregated as much as possible, both by the PITR and by the global routing system.
プロキシイングレストンネルルーター（PITR）：PITRは、レガシーインターネットからLISPサイトへの接続を提供します。PITRSは、トラフィックを引き付けるために、EID-PREFIXES（可能な場合は集約）のグローバルルーティングシステムブロックで発表します。LISPサイト（非EID）にないソースからの入っている各パケットについて、PITR LISPが適切なLISPサイトのRLOCに向かってカプセル化します。デフォルトフリーゾーン（DFZ）のルーティングテーブルサイズに対するPITRの影響は、最悪の場合、LISPが展開されない場合と同様です。Eid-Prefixesは、PITRとグローバルルーティングシステムの両方によって、可能な限り集約されます。
Proxy Egress Tunnel Router (PETR): PETRs provide connectivity from LISP sites to the legacy Internet. In some scenarios, LISP sites may be unable to send encapsulated packets with a local EID address as a source to the legacy Internet, for instance, when Unicast Reverse Path Forwarding (uRPF) is used by Provider Edge routers or when an intermediate network between a LISP site and a non-LISP site does not support the desired version of IP (IPv4 or IPv6). In both cases, the PETR overcomes such limitations by encapsulating packets over the network. There is no specified provision for the distribution of PETR RLOC addresses to the ITRs.
プロキシ出力トンネルルーター（PETR）：PETRSは、LISPサイトからレガシーインターネットへの接続を提供します。一部のシナリオでは、LISPサイトでは、ユニキャストリバースパス転送（URPF）がプロバイダーEdgeルーターによって使用される場合、または中間ネットワーク間の中間ネットワークが使用される場合、LegacyインターネットのソースとしてローカルEIDアドレスを持つカプセル化されたパケットを送信できない場合があります。LISPサイトと非リスプサイトは、IP（IPv4またはIPv6）の目的バージョンをサポートしていません。どちらの場合も、PETRはネットワーク上のパケットをカプセル化することにより、そのような制限を克服します。ITRへのPETR RLOCアドレスの分布に関する指定された規定はありません。
Additionally, LISP also defines mechanisms to operate with private EIDs [RFC1918] by means of LISP-NAT [RFC6832]. In this case, the xTR replaces a private EID source address with a routable one. At the time of this writing, work is ongoing to define NAT-traversal capabilities, that is, xTRs behind a NAT using non-routable RLOCs.
さらに、LISPは、LISP-NAT [RFC6832]を使用して、プライベートEID [RFC1918]で動作するメカニズムも定義しています。この場合、XTRはプライベートEIDソースアドレスをルーティング可能なものに置き換えます。この執筆時点では、NATトラバーサル機能を定義するための作業が進行中です。つまり、非ルート不可能なRLOCを使用してNATの背後にあるXTRです。
PITRs, PETRs, and LISP-NAT enable incremental deployment of LISP by providing significant flexibility in the placement of the boundaries between the LISP and non-LISP portions of the network and making it easy to change those boundaries over time.
PITR、PETRS、およびLISP-NATは、ネットワークのLISPと非リスプ部分の間の境界の配置に大きな柔軟性を提供し、時間の経過とともにそれらの境界を簡単に変更できるようにすることにより、LISPの増分展開を可能にします。
This section details the main operational mechanisms defined in LISP.
このセクションでは、LISPで定義されている主な動作メカニズムについて詳しく説明しています。
LISP's decoupled control and data planes, where mappings are stored in the control plane and used for forwarding in the data plane, require a local cache in ITRs to reduce signaling overhead (Map-Request/Map-Reply) and increase forwarding speed. The local cache available at the ITRs, called Map-Cache, is used by the router to LISP-encapsulate packets. The Map-Cache is indexed by (Instance ID, EID-Prefix) and contains basically the set of RLOCs with the associated TE policies (priorities and weights).
マッピングがコントロールプレーンに保存され、データプレーンでの転送に使用されるLISPのデカップされたコントロールおよびデータプレーンは、ITRのローカルキャッシュを必要として、シグナリングオーバーヘッド（Map-Request/Map-Reply）を減らし、転送速度を上げます。ITRで利用可能なローカルキャッシュは、Map-Cacheと呼ばれ、ルーターによってリスプエンコールのパケットに使用されます。マップキャッシュは（インスタンスID、EID-PREFIX）でインデックス付けされており、基本的に関連するTEポリシー（優先順位と重み）を持つRLOCのセットが含まれています。
The Map-Cache, as with any other cache, requires cache coherence mechanisms to maintain up-to-date information. LISP defines three main mechanisms for cache coherence:
マップキャッシュは、他のキャッシュと同様に、最新の情報を維持するためにキャッシュコヒーレンスメカニズムを必要とします。LISPは、キャッシュコヒーレンスの3つの主要なメカニズムを定義します。
Record Time To Live (TTL): Each mapping record contains a TTL set by the ETR. Upon expiration of the TTL, the ITR can't use the mapping until it is refreshed by sending a new Map-Request.
Record Time to Live（TTL）：各マッピングレコードには、ETRによって設定されたTTLが含まれています。TTLの有効期限が切れると、ITRは新しいMap-Requestを送信することで更新されるまでマッピングを使用できません。
Solicit-Map-Request (SMR): SMR is an explicit mechanism to update mapping information. In particular, a special type of Map-Request can be sent on demand by ETRs to request refreshing a mapping. Upon reception of an SMR message, the ITR must refresh the bindings by sending a Map-Request to the Mapping System. Further uses of SMRs are documented in [RFC9301].
Solicit-Map-Request（SMR）：SMRは、マッピング情報を更新するための明示的なメカニズムです。特に、マッピングの更新をリクエストするために、ETRSによって特別なタイプのMAP-Requestを要求することができます。SMRメッセージを受信すると、ITRはマッピングシステムにマップリケストを送信してバインディングを更新する必要があります。SMRのさらなる使用は、[RFC9301]に記録されています。
Map-Versioning: This optional mechanism piggybacks, in the LISP header of data packets, the version number of the mappings used by an xTR. This way, when an xTR receives a LISP-encapsulated packet from a remote xTR, it can check whether its own Map-Cache or the one of the remote xTR is outdated. If its Map-Cache is outdated, it sends a Map-Request for the remote EID so as to obtain the newest mappings. On the contrary, if it detects that the remote xTR Map-Cache is outdated, it sends an SMR to notify it that a new mapping is available. Further details are available in [RFC9302].
マップバージョン：このオプションのメカニズムは、データパケットのLISPヘッダー、XTRで使用されるマッピングのバージョン番号でのピギーバックです。これにより、XTRがリモートXTRからLISPカプセル化パケットを受信すると、独自のマップキャッシュまたはリモートXTRの1つが時代遅れかどうかを確認できます。マップキャッシュが時代遅れの場合、最新のマッピングを取得するために、リモートEIDのマップリクエストを送信します。それどころか、リモートXTRマップキャッシュが時代遅れであることを検出した場合、SMRを送信して新しいマッピングが利用可能であることを通知します。詳細については、[RFC9302]をご覧ください。
Finally, it is worth noting that, in some cases, an entry in the Map-Cache can be proactively refreshed using the mechanisms described in the section below.
最後に、以下のセクションで説明したメカニズムを使用して、マップキャッシュのエントリを積極的に更新できる場合がある場合があることに注意してください。
In most cases, LISP operates with a pull-based Mapping System (e.g., DDT). This results in an edge-to-edge pull architecture. In such a scenario, the network state is stored in the control plane while the data plane pulls it on demand. This has consequences concerning the propagation of xTRs' reachability/liveness information, since pull architectures require explicit mechanisms to propagate this information. As a result, LISP defines a set of mechanisms to inform ITRs and PITRs about the reachability of the cached RLOCs:
ほとんどの場合、LISPはプルベースのマッピングシステム（DDTなど）で動作します。これにより、エッジとエッジのプルアーキテクチャが得られます。このようなシナリオでは、ネットワーク状態はコントロールプレーンに保存され、データプレーンはオンデマンドで引っ張ります。これは、XTRSの到達可能性/livening情報の伝播に関する結果をもたらします。これは、この情報を伝播するために明示的なメカニズムを必要とするためです。その結果、LISPは、キャッシュされたRLOCの到達可能性についてITRとPITRに通知する一連のメカニズムを定義します。
Locator-Status-Bits (LSBs): Using LSBs is a passive technique. The 'LSB' field is carried by data packets in the LISP header and can be set by ETRs to specify which RLOCs of the ETR site are up/down. This information can be used by the ITRs as a hint about the reachability to perform additional checks. Also note that LSBs do not provide path reachability status; they only provide hints about the status of RLOCs. As such, they must not be used over the public Internet and should be coupled with Map-Versioning to prevent race conditions where LSBs are interpreted as referring to different RLOCs than intended.
Locator-Status-Bits（LSB）：LSBSの使用は受動的な手法です。「LSB」フィールドは、LISPヘッダーのデータパケットによって運ばれ、ETRによって設定して、ETRサイトのどのRLOCが上下にあるかを指定できます。この情報は、ITRSによって追加のチェックを実行する到達可能性に関するヒントとして使用できます。また、LSBはパスリーチ性ステータスを提供しないことに注意してください。彼らはRLOCのステータスに関するヒントのみを提供します。そのため、公開インターネットで使用してはなりません。LSBが意図したものとは異なるRLOCを参照すると解釈される人種条件を防ぐために、マップバージョンと結合する必要があります。
Echo-Nonce: This is also a passive technique that can only operate effectively when data flows bidirectionally between two communicating xTRs. Basically, an ITR piggybacks a random number (called a nonce) in LISP data packets. If the path and the probed Locator are up, the ETR will piggyback the same random number on the next data packet; if this is not the case, the ITR can set the Locator as unreachable. When traffic flow is unidirectional or when the ETR receiving the traffic is not the same as the ITR that transmits it back, additional mechanisms are required. The Echo-Nonce mechanism must be used in trusted environments only, not over the public Internet.
Echo-Nonce：これは、2つの通信XTRの間でデータが双方向に流れる場合にのみ効果的に動作できる受動的手法でもあります。基本的に、ITRはLISPデータパケットの乱数（NonCeと呼ばれる）を豚肉にバックします。パスとプローブロケーターが上昇している場合、ETRは次のデータパケットで同じ乱数を貯蔵します。そうでない場合、ITRはロケーターを到達不能として設定できます。トラフィックフローが単方向である場合、またはETRがトラフィックを受け取る場合、それを送信するITRと同じでない場合、追加のメカニズムが必要です。エコーノンセメカニズムは、パブリックインターネット上ではなく、信頼できる環境でのみ使用する必要があります。
RLOC-Probing: This is an active probing algorithm where ITRs send probes to specific Locators. This effectively probes both the Locator and the path. In particular, this is done by sending a Map-Request (with certain flags activated) on the data plane (RLOC space) and then waiting for a Map-Reply (also sent on the data plane). The active nature of RLOC-Probing provides an effective mechanism for determining reachability and, in case of failure, switching to a different Locator. Furthermore, the mechanism also provides useful RTT estimates of the delay of the path that can be used by other network algorithms.
rloc-probing：これは、ITRが特定のロケーターにプローブを送信するアクティブなプロービングアルゴリズムです。これにより、ロケーターとパスの両方を効果的に調査します。特に、これは、データプレーン（RLOCスペース）にマップリクエスト（特定のフラグがアクティブ化された）を送信し、マップリプ（データプレーンでも送信）を待つことによって行われます。RLOCプロビングのアクティブな性質は、到達可能性を決定するための効果的なメカニズムを提供し、障害の場合、異なるロケーターに切り替えます。さらに、このメカニズムは、他のネットワークアルゴリズムで使用できるパスの遅延の有用なRTT推定値も提供します。
It is worth noting that RLOC-Probing and the Echo-Nonce can work together. Specifically, if a nonce is not echoed, an ITR cannot determine which path direction has failed. In this scenario, an ITR can use RLOC-Probing.
rloc-probingとEcho-nonceが一緒に機能することは注目に値します。具体的には、非CEがエコーされていない場合、ITRはどの経路方向が失敗したかを決定できません。このシナリオでは、ITRはRLOCプロビングを使用できます。
Additionally, LISP also recommends inferring the reachability of Locators by using information provided by the underlay, particularly:
さらに、LISPは、特に以下の情報を使用して、ロケーターの到達可能性を推測することも推奨しています。
ICMP signaling: The LISP underlay -- the current Internet -- uses ICMP to signal unreachability (among other things). LISP can take advantage of this, and the reception of an ICMP Network Unreachable or ICMP Host Unreachable message can be seen as a hint that a Locator might be unreachable. This should lead to performing additional checks.
ICMPシグナル伝達：LISPアンダーレイ - 現在のインターネット - は、ICMPを使用して到達不能を信号します（とりわけ）。LISPはこれを利用でき、ICMPネットワークの受信が到達できないまたはICMPホストの到達不可能なメッセージは、ロケーターが到達不可能である可能性があるというヒントと見なすことができます。これにより、追加のチェックの実行につながるはずです。
Underlay routing: Both BGP and IGP carry reachability information. LISP-capable routers that have access to underlay routing information can use it to determine if a given Locator or path is reachable.
アンダーレイルーティング：BGPとIGPの両方に到達可能な情報が含まれます。アンダーレイルーティング情報にアクセスできるLISP対応ルーターは、それを使用して、特定のロケーターまたはパスが到達可能かどうかを判断できます。
All the ETRs that are authoritative to a particular EID-Prefix must announce the same mapping to the requesters. This means that ETRs must be aware of the status of the RLOCs of the remaining ETRs. This is known as ETR synchronization.
特定のEid-Prefixに対して権威あるすべてのETRは、要求者に同じマッピングを発表する必要があります。これは、ETRが残りのETRのRLOCの状態を認識している必要があることを意味します。これはETR同期として知られています。
At the time of this writing, LISP does not specify a mechanism to achieve ETR synchronization. Although many well-known techniques could be applied to solve this issue, it is still under research. As a result, operators must rely on coherent manual configuration.
この執筆時点では、LISPはETR同期を実現するメカニズムを指定していません。この問題を解決するために多くのよく知られている手法を適用できますが、まだ研究中です。その結果、オペレーターは一貫した手動構成に依存する必要があります。
Since LISP encapsulates packets, it requires dealing with packets that exceed the MTU of the path between the ITR and the ETR. Specifically, LISP defines two mechanisms:
LISPはパケットをカプセル化するため、ITRとETRの間のパスのMTUを超えるパケットを処理する必要があります。具体的には、LISPは2つのメカニズムを定義します。
Stateless: With this mechanism, the effective MTU is assumed from the ITR's perspective. If a payload packet is too big for the effective MTU and can be fragmented, the payload packet is fragmented on the ITR, such that reassembly is performed at the destination host.
ステートレス：このメカニズムにより、効果的なMTUはITRの観点から想定されます。ペイロードパケットが効果的なMTUには大きすぎて断片化できる場合、ペイロードパケットはITRで断片化されているため、宛先ホストで再組み立てが実行されます。
Stateful: With this mechanism, ITRs keep track of the MTU of the paths towards the destination Locators by parsing the ICMP Too Big packets sent by intermediate routers. ITRs will send ICMP Too Big messages to inform the sources about the effective MTU. Additionally, ITRs can use mechanisms such as Path MTU Discovery (PMTUD) [RFC1191] or Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] to keep track of the MTU towards the Locators.
ステートフル：このメカニズムにより、ITRSは、中間ルーターによって送信されるICMPが大きすぎるパケットを解析することにより、宛先ロケーターに向かうパスのMTUを追跡します。ITRSは、ICMPに大きなメッセージを送信して、有効なMTUについてソースに通知します。さらに、ITRは、PATH MTU Discovery（PMTUD）[RFC1191]やPacketization Layer Path MTU Discovery（PLPMTUD）[RFC4821]などのメカニズムを使用して、MTUをロケーターに向けて追跡できます。
In both cases, if the packet cannot be fragmented (IPv4 with DF=1 or IPv6), then the ITR drops it and replies with an ICMP Too Big message to the source.
どちらの場合も、パケットを断片化できない場合（DF = 1またはIPv6を搭載したIPv4）、ITRはそれをドロップし、ICMPがソースに大きすぎるメッセージで応答します。
The separation between Locators and identifiers in LISP is suitable for TE purposes where LISP sites can change their attachment points to the Internet (i.e., RLOCs) without impacting endpoints or the Internet core. In this context, the border routers operate the xTR functionality, and endpoints are not aware of the existence of LISP. This functionality is similar to Network Mobility [RFC3963]. However, this mode of operation does not allow seamless mobility of endpoints between different LISP sites, as the EID address might not be routable in a visited site. Nevertheless, LISP can be used to enable seamless IP mobility when LISP is directly implemented in the endpoint or when the endpoint roams to an attached xTR. Each endpoint is then an xTR, and the EID address is the one presented to the network stack used by applications while the RLOC is the address gathered from the network when it is visited. This functionality is similar to Mobile IP ([RFC5944] and [RFC6275]).
LISPのロケーターと識別子間の分離は、LISPサイトがエンドポイントやインターネットコアに影響を与えることなくインターネット（つまりRLOC）に添付ポイントを変更できるTE目的に適しています。これに関連して、ボーダールーターはXTR機能を動作させ、エンドポイントはLISPの存在を認識していません。この機能は、ネットワークモビリティ[RFC3963]に似ています。ただし、この操作モードでは、訪問されたサイトではEIDアドレスがルーティングできない可能性があるため、異なるLISPサイト間のエンドポイントのシームレスなモビリティは許可されていません。それにもかかわらず、LISPを使用して、LISPがエンドポイントで直接実装されている場合、またはエンドポイントが添付のXTRにローミングするときにシームレスなIPモビリティを有効にすることができます。各エンドポイントはXTRであり、EIDアドレスはアプリケーションで使用されるネットワークスタックに提示されたアドレスであり、RLOCは訪問時にネットワークから収集されたアドレスです。この機能は、モバイルIP（[RFC5944]および[RFC6275]）に似ています。
Whenever a device changes its RLOC, the xTR updates the RLOC of its local mapping and registers it to its Map-Server, typically with a low TTL value (1 min). To avoid the need for a home gateway, the ITR also indicates the RLOC change to all remote devices that have ongoing communications with the device that moved. The combination of both methods ensures the scalability of the system, as signaling is strictly limited to the Map-Server and to hosts with which communications are ongoing. In the mobility case, the EID-Prefix can be as small as a full /32 or /128 (IPv4 or IPv6, respectively), depending on the specific use case (e.g., subnet mobility vs. single VM/Mobile node mobility).
デバイスがRLOCを変更するたびに、XTRはローカルマッピングのRLOCを更新し、通常は低いTTL値（1分）でマップサーバーに登録します。ホームゲートウェイの必要性を回避するために、ITRはまた、移動したデバイスと継続的な通信を持っているすべてのリモートデバイスのRLOCの変更を示します。両方の方法の組み合わせにより、シグナリングはマップサーバーと通信が進行中のホストに厳密に限定されるため、システムのスケーラビリティが保証されます。モビリティの場合、特定のユースケース（例：サブネットモビリティ対シングルVM /モバイルノードモビリティなど）に応じて、Eid-Prefixはそれぞれフル /32または /128（それぞれIPv4またはIPv6）と同じくらい小さくなります。
The decoupled identity and location provided by LISP allow it to operate with other Layer 2 and Layer 3 mobility solutions.
LISPによって提供される分離されたアイデンティティと場所により、他のレイヤー2およびレイヤー3モビリティソリューションで動作することができます。
LISP also supports transporting IP multicast packets sent from the EID space. The required operational changes to the multicast protocols are documented in [RFC6831].
LISPは、EIDスペースから送信されたIPマルチキャストパケットの輸送もサポートしています。マルチキャストプロトコルに必要な運用変更は[RFC6831]に記録されています。
In such scenarios, LISP may create multicast state both at the core and at the sites (both source and receiver). When signaling is used to create multicast state at the sites, LISP routers encapsulate PIM Join/Prune messages from receiver to source sites as unicast packets. At the core, ETRs build a new PIM Join/Prune message addressed to the RLOC of the ITR servicing the source. A simplified sequence is shown below.
このようなシナリオでは、LISPはコアとサイトの両方でマルチキャスト状態を作成する場合があります（ソースとレシーバーの両方）。シグナリングを使用してサイトでマルチキャスト状態を作成する場合、LISPルーターは、ピムの結合/レシーバーからソースサイトへのメッセージをユニキャストパケットとしてカプセル化します。コアでは、ETRSがソースにサービスを提供するITRのRLOCにアドレス指定された新しいPIM結合/プルーンメッセージを作成します。単純化されたシーケンスを以下に示します。
1. An end host willing to join a multicast channel sends an IGMP report. Multicast PIM routers at the LISP site propagate PIM Join/Prune messages (S-EID, G) towards the ETR.
1. マルチキャストチャネルに参加する意思のあるエンドホストは、IGMPレポートを送信します。LISPサイトのマルチキャストPIMルーターは、PIM結合/プルーンメッセージ（S-EID、G）をETRに向けて伝播します。
2. The Join message flows to the ETR. Upon reception, the ETR builds two Join messages. The first one unicast LISP-encapsulates the original Join message towards the RLOC of the ITR servicing the source. This message creates (S-EID, G) multicast state at the source site. The second Join message contains, as a destination address, the RLOC of the ITR servicing the source (S-RLOC, G) and creates multicast state at the core.
2. 結合メッセージはETRに流れます。レセプション時に、ETRは2つの参加メッセージを構築します。最初のユニキャストLISPがソースにサービスを提供するITRサービスのRLOCに向けて元の結合メッセージをカプセル化します。このメッセージは、ソースサイトにマルチキャスト状態（S-EID、G）を作成します。2番目の結合メッセージには、宛先アドレスとして、ソース（S-RLOC、G）にサービスを提供するITRのRLOCが含まれ、コアでマルチキャスト状態を作成します。
3. Multicast data packets originated by the source (S-EID, G) flow from the source to the ITR. The ITR LISP-encapsulates the multicast packets. The outer header includes its own RLOC as the source (S-RLOC) and the original multicast group address (G) as the destination. Please note that multicast group addresses are logical and are not resolved by the Mapping System. Then, the multicast packets are transmitted through the core towards the receiving ETRs, which decapsulate the packets and forward them using the receiver site's multicast state.
3. ソース（S-EID、G）がソースからITRに流れるマルチキャストデータパケット。ITR LISPがマルチキャストパケットをカプセル化します。外側のヘッダーには、ソース（S-RLOC）として独自のRLOCが含まれており、元のマルチキャストグループアドレス（g）が宛先として含まれています。マルチキャストグループアドレスは論理的であり、マッピングシステムによって解決されないことに注意してください。次に、マルチキャストパケットは、受信ETRに向かってコアを介して送信されます。これは、パケットを脱カプセル化し、レシーバーサイトのマルチキャスト状態を使用して転送します。
Please note that the inner and outer multicast addresses are generally different, except in specific cases where the underlay provider implements tight control on the overlay. LISP specifications already support all PIM modes [RFC6831]. Additionally, LISP can also support non-PIM mechanisms in order to maintain multicast state.
アンダーレイプロバイダーがオーバーレイの厳しい制御を実装する特定の場合を除き、内側と外側のマルチキャストアドレスは一般に異なることに注意してください。LISP仕様は、すでにすべてのPIMモード[RFC6831]をサポートしています。さらに、LISPはマルチキャスト状態を維持するために非PIMメカニズムをサポートすることもできます。
When multicast sources and receivers are active at LISP sites and the core network between the sites does not provide multicast support, a signal-free mechanism can be used to create an overlay that will allow multicast traffic to flow between sites and connect the multicast trees at the different sites [RFC8378]. Registrations from the different receiver sites will be merged in the Mapping System to assemble a multicast replication list inclusive of all RLOCs that lead to receivers for a particular multicast group or multicast channel. The replication list for each specific multicast entry is maintained as a database mapping entry in the LISP Mapping System.
マルチキャストソースとレシーバーがLISPサイトでアクティブであり、サイト間のコアネットワークがマルチキャストサポートを提供しない場合、信号のないメカニズムを使用して、マルチキャストトラフィックがサイト間で流れてマルチキャストツリーを接続できるオーバーレイを作成できます。異なるサイト[RFC8378]。さまざまなレシーバーサイトからの登録は、マッピングシステムにマージされ、特定のマルチキャストグループまたはマルチキャストチャネルのレシーバーにつながるすべてのRLOCを含むマルチキャストレプリケーションリストを組み立てます。各特定のマルチキャストエントリの複製リストは、LISPマッピングシステムのデータベースマッピングエントリとして維持されます。
A LISP site can strictly impose via which ETRs the traffic must enter the LISP site network even though the path followed to reach the ETR is not under the control of the LISP site. This fine control is implemented with the mappings. When a remote site is willing to send traffic to a LISP site, it retrieves the mapping associated with the destination EID via the Mapping System. The mapping is sent directly by an authoritative ETR of the EID and is not altered by any intermediate network.
ETRに到達するためのパスがLISPサイトの制御下にない場合でも、LISPサイトがETRSを介してトラフィックがLISPサイトネットワークに入る必要があることを厳密に課すことができます。この細かい制御は、マッピングで実装されています。リモートサイトがLISPサイトにトラフィックを送信することをいとわない場合、マッピングシステムを介して宛先EIDに関連付けられたマッピングを取得します。マッピングは、EIDの権威あるETRによって直接送信され、中間ネットワークによって変更されません。
A mapping associates a list of RLOCs with an EID-Prefix. Each RLOC corresponds to an interface of an ETR (or set of ETRs) that is able to correctly forward packets to EIDs in the prefix. Each RLOC is tagged with a priority and a weight in the mapping. The priority is used to indicate which RLOCs should be preferred for sending packets (the least preferred ones being provided for backup purposes). The weight permits balancing the load between the RLOCs with the same priority, in proportion to the weight value.
マッピングは、RLOCのリストをEid-Prefixに関連付けます。各RLOCは、プレフィックス内のEidsにパケットを正しく転送できるETR（またはETRのセット）のインターフェイスに対応しています。各RLOCには、マッピングの優先度と重量がタグ付けされています。優先順位は、どのRLOCを送信するか（バックアップの目的で提供されている最小限のRLOC）を示すために使用されます。重量により、重量値に比例して、RLOC間の負荷のバランスを同じ優先順位でバランスさせることができます。
As mappings are directly issued by the authoritative ETR of the EID and are not altered when transmitted to the remote site, it offers highly flexible incoming inter-domain TE and even makes it possible for a site to support a different mapping policy for each remote site.
マッピングはEIDの権威あるETRによって直接発行され、リモートサイトに送信されたときに変更されないため、非常に柔軟な入ってくるドメインTEを提供し、各リモートサイトの別のマッピングポリシーをサポートするサイトを可能にします。。
LISP encapsulations allow transporting packets using EIDs from a given address family (e.g., IPv6) with packets from other address families (e.g., IPv4). The absence of correlation between the address families of RLOCs and EIDs makes LISP a candidate to allow, e.g., IPv6 to be deployed when all of the core network may not have IPv6 enabled.
LISPのカプセル化により、特定のアドレスファミリ（例：IPv6）からのEIDを他のアドレスファミリ（例：IPv4）からのパケットを使用して輸送することができます。RLOCSとEIDSのアドレスファミリ間に相関がないため、LISPは、すべてのコアネットワークがIPv6を有効にしていない場合に、IPv6を展開することを許可する候補になります。
For example, two IPv6-only data centers could be interconnected via the legacy IPv4 Internet. If their border routers are LISP capable, sending packets between the data centers is done without any form of translation, as the original IPv6 packets (in the EID space) will be LISP encapsulated and transmitted over the IPv4 legacy Internet via IPv4 RLOCs.
たとえば、2つのIPv6のみのデータセンターを、Legacy IPv4 Internetを介して相互接続できます。境界線ルーターがLISP対応の場合、データセンター間でパケットを送信すると、翻訳の形態なしに行われます。元のIPv6パケット（EIDスペース）は、IPv4 RLOCを介してIPv4レガシーインターネット上にカプセル化および送信されるためです。
It is common to operate several virtual networks over the same physical infrastructure. In such virtual private networks, determining to which virtual network a packet belongs is essential; tags or labels are used for that purpose. When using LISP, the distinction can be made with the 'Instance ID' field. When an ITR encapsulates a packet from a particular virtual network (e.g., known via Virtual Routing and Forwarding (VRF) or the VLAN), it tags the encapsulated packet with the Instance ID corresponding to the virtual network of the packet. When an ETR receives a packet tagged with an Instance ID, it uses the Instance ID to determine how to treat the packet.
同じ物理インフラストラクチャでいくつかの仮想ネットワークを操作することが一般的です。このような仮想プライベートネットワークでは、パケットが属する仮想ネットワークを決定することが不可欠です。タグまたはラベルはその目的に使用されます。LISPを使用する場合、「インスタンスID」フィールドで区別を作成できます。ITRが特定の仮想ネットワーク（例：仮想ルーティングと転送（VRF）またはVLANを介して既知）からパケットをカプセル化すると、パケットの仮想ネットワークに対応するインスタンスIDでカプセル化されたパケットにタグを付けます。ETRがインスタンスIDでタグ付けされたパケットを受信すると、インスタンスIDを使用してパケットの処理方法を決定します。
The main usage of LISP for virtual private networks does not introduce additional requirements on the underlying network, as long as it runs IP.
仮想プライベートネットワークのLISPの主な使用法は、IPを実行する限り、基礎となるネットワークに追加要件を導入しません。
A way to enable seamless virtual machine (VM) mobility in the data center is to conceive the data center backbone as the RLOC space and the subnet where servers are hosted as forming the EID space. A LISP router is placed at the border between the backbone and each subnet. When a VM is moved to another subnet, it can keep (temporarily) the address it had before the move so as to continue without a transport-layer connection reset. When an xTR detects a source address received on a subnet to be an address not assigned to the subnet, it registers the address to the Mapping System.
データセンターでシームレスな仮想マシン（VM）モビリティを有効にする方法は、データセンターのバックボーンをRLOCスペースとして、およびサーバーがEIDスペースを形成するものとしてホストされるサブネットを考案することです。リスプルーターは、バックボーンと各サブネットの境界に配置されます。VMが別のサブネットに移動すると、移動前に（一時的に）アドレスを保持することができます。XTRがサブネットで受信したソースアドレスを検出すると、サブネットに割り当てられていないアドレスとしてXTRが検出されると、マッピングシステムにアドレスを登録します。
To inform the other LISP routers that the machine moved and where, and then to avoid detours via the initial subnetwork, mechanisms such as the Solicit-Map-Request messages are used.
他のLISPルーターにマシンが移動した場所と場所を通知し、最初のサブネットワークを介して迂回を避けるために、Solict-Map-Requestメッセージなどのメカニズムが使用されます。
This section describes the security considerations associated with LISP.
このセクションでは、LISPに関連するセキュリティ上の考慮事項について説明します。
In a push Mapping System, the state necessary to forward packets is learned independently of the traffic itself. However, with a pull architecture, the system becomes reactive, and data plane events (e.g., the arrival of a packet with an unknown destination address) may trigger control plane events. This on-demand learning of mappings provides many advantages, as discussed above, but may also affect the way security is enforced.
プッシュマッピングシステムでは、パケットを転送するために必要な状態は、トラフィック自体とは独立して学習されます。ただし、プルアーキテクチャを使用すると、システムはリアクティブになり、データプレーンイベント（例：未知の宛先アドレスを備えたパケットの到着）は、制御プレーンのイベントをトリガーする可能性があります。上記で説明したように、マッピングのこのオンデマンド学習は多くの利点を提供しますが、セキュリティの実施方法にも影響を与える可能性があります。
Usually, the data plane is implemented in the fast path of routers to provide high-performance forwarding capabilities, while the control plane features are implemented in the slow path to offer high flexibility, and a performance gap of several orders of magnitude can be observed between the slow and fast paths. As a consequence, the way to notify the control plane of data plane events must be considered carefully so as not to overload the slow path, and rate limiting should be used as specified in [RFC9300] and [RFC9301].
通常、データプレーンはルーターの高速パスに実装されて高性能転送機能を提供しますが、コントロールプレーンの特徴は柔軟性の高いパスで実装され、数桁のパフォーマンスギャップを観察できます。ゆっくりと高速のパス。結果として、データプレーンイベントのコントロールプレーンに通知する方法は、遅いパスを過負荷にしないように慎重に考慮する必要があり、[RFC9300]および[RFC9301]で指定されているようにレート制限を使用する必要があります。
Care must also be taken not to overload the Mapping System (i.e., the control plane infrastructure), as the operations to be performed by the Mapping System may be more complex than those on the data plane. For that reason, [RFC9300] and [RFC9301] recommend rate limiting the sending of messages to the Mapping System.
また、マッピングシステムによって実行される操作がデータプレーンのものよりも複雑である可能性があるため、マッピングシステム（つまり、コントロールプレーンインフラストラクチャ）に過負荷しないように注意する必要があります。そのため、[RFC9300]と[RFC9301]は、メッセージの送信をマッピングシステムに制限するレートを推奨しています。
To improve resiliency and reduce the overall number of messages exchanged, LISP makes it possible to leak certain information, such as the reachability of Locators, directly into data plane packets. In environments that are not fully trusted, like the open Internet, control information gleaned from data plane packets must not be used or must be verified before using it.
回復力を改善し、交換されたメッセージの総数を減らすために、LISPは、ロケーターの到達可能性などの特定の情報をデータプレーンパケットに直接漏らすことができます。オープンなインターネットのように、完全に信頼されていない環境では、データプレーンパケットから収集された制御情報を使用する前に使用する必要はありません。
Mappings are the centerpiece of LISP, and all precautions must be taken to prevent malicious entities from manipulating or misusing them. Using trustable Map-Servers that strictly respect [RFC9301] and the authentication mechanism proposed by LISP-SEC [RFC9303] reduces the risk of attacks on mapping integrity. In more critical environments, secure measures may be needed. The way security is implemented for a given Mapping System strongly depends on the architecture of the Mapping System itself and the threat model assumed for the deployment. Thus, Mapping System security has to be discussed in the relevant documents proposing the Mapping System architecture.
マッピングはLISPの中心であり、悪意のあるエンティティがそれらを操作したり誤用したりするのを防ぐために、すべての予防策を講じなければなりません。[RFC9301]を厳密に尊重する信頼できるマップサーバーとLISP-SEC [RFC9303]によって提案された認証メカニズムを使用すると、マッピングの整合性に対する攻撃のリスクが減少します。より重要な環境では、安全な対策が必要になる場合があります。特定のマッピングシステムのセキュリティが実装される方法は、マッピングシステム自体のアーキテクチャと、展開のために想定される脅威モデルのアーキテクチャに大きく依存します。したがって、マッピングシステムのセキュリティは、マッピングシステムアーキテクチャを提案する関連ドキュメントで説明する必要があります。
As with any other tunneling mechanism, middleboxes on the path between an ITR (or PITR) and an ETR (or PETR) must implement mechanisms to strip the LISP encapsulation to correctly inspect the content of LISP-encapsulated packets.
他のトンネリングメカニズムと同様に、ITR（またはPITR）とETR（またはPETR）の間のパス上のミドルボックスは、LISPカプセル化されたパケットの内容を正しく検査するためにLISPカプセル化を除去するメカニズムを実装する必要があります。
Like other map-and-encap mechanisms, LISP enables triangular routing (i.e., packets of a flow cross different border routers, depending on their direction). This means that intermediate boxes may have an incomplete view of the traffic they inspect or manipulate. Moreover, LISP-encapsulated packets are routed based on the outer IP address (i.e., the RLOC) and can be delivered to an ETR that is not responsible for the destination EID of the packet or even delivered to a network element that is not an ETR. Mitigation consists of applying appropriate filtering techniques on the network elements that can potentially receive unexpected LISP-encapsulated packets.
他のマップとエンコップのメカニズムと同様に、LISPは三角形のルーティングを有効にします（つまり、フローのパケットは、方向に応じて異なる境界線ルーターを横切ります）。これは、中間ボックスが検査または操作するトラフィックの不完全なビューを持っている可能性があることを意味します。さらに、LISPにカプセル化されたパケットは、外側のIPアドレス（つまり、RLOC）に基づいてルーティングされ、パケットの宛先EIDに責任を負わないETRに配信できます。。緩和は、予期しないLISPにカプセル化されたパケットを受信できる可能性のあるネットワーク要素に適切なフィルタリング手法を適用することで構成されています。
More details about security implications of LISP are discussed in [RFC7835].
LISPのセキュリティへの影響に関する詳細については、[RFC7835]で説明します。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、DOI 10.17487/RFC1191、1990年11月、<https://www.rfc-editor.org/info/rfc1191>。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、De Groot、G。J.、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、DOI 10.17487/RFC1918、1996年2月、<https://www.rfc-editor.org/info/rfc1918>。
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000, <https://www.rfc-editor.org/info/rfc2992>.
[RFC2992] Hopps、C。、「等しいマルチパスアルゴリズムの分析」、RFC 2992、DOI 10.17487/RFC2992、2000年11月、<https://www.rfc-editor.org/info/rfc2992>
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, DOI 10.17487/RFC3963, January 2005, <https://www.rfc-editor.org/info/rfc3963>.
[RFC3963] Devarapalli、V.、Wakikawa、R.、Petrescu、A。、およびP. Thubert、「ネットワークモビリティ（NEMO）基本的なサポートプロトコル」、RFC 3963、DOI 10.17487/RFC3963、2005年1月、<HTTPS：//www.rfc-editor.org/info/rfc3963>。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、DOI 10.17487/RFC4821、2007年3月、<https://www.rfc-editor.org/info/rfc4821>。
[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>。
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, DOI 10.17487/RFC5944, November 2010, <https://www.rfc-editor.org/info/rfc5944>.
[RFC5944] Perkins、C.、ed。、「IPv4のIPモビリティサポート、改訂」、RFC 5944、DOI 10.17487/RFC5944、2010年11月、<https://www.rfc-editor.org/info/RFC5944>
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6275] Perkins、C.、ed。、Johnson、D。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 6275、DOI 10.17487/RFC6275、2011年7月、<https：//www.rfc-editor。org/info/rfc6275>。
[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>。
[RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation Protocol Internet Groper (LIG)", RFC 6835, DOI 10.17487/RFC6835, January 2013, <https://www.rfc-editor.org/info/rfc6835>.
[RFC6835] Farinacci、D。およびD. Meyer、「ロケーター/ID分離プロトコルインターネットグロパー（LIG）」、RFC 6835、DOI 10.17487/RFC6835、2013年1月、<https：//www.rfc-editor.org/情報/RFC6835>。
[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>。
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/RFC6935, April 2013, <https://www.rfc-editor.org/info/rfc6935>.
[RFC6935] Eubanks、M.、Chimento、P。、およびM. Westerlund、「トンネルパケットのIPv6およびUDPチェックサム」、RFC 6935、DOI 10.17487/RFC6935、2013年4月、<https：//www.rfc-editor。org/info/rfc6935>。
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, <https://www.rfc-editor.org/info/rfc6936>.
[RFC6936] Fairhurst、G。およびM. Westerlund、「チェックサムを備えたIPv6 UDPデータグラムの使用に関するアプリケーションステートメント」、RFC 6936、DOI 10.17487/RFC6936、2013年4月、<https://www.rfc-editor.org/info/rfc6936>。
[RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID Separation Protocol (LISP) MIB", RFC 7052, DOI 10.17487/RFC7052, October 2013, <https://www.rfc-editor.org/info/rfc7052>.
[RFC7052] Schudel、G.、Jain、A。、およびV. Moreno、「ロケーター/ID分離プロトコル（LISP）MIB」、RFC 7052、DOI 10.17487/RFC7052、2013年10月、<https：//www.rfc-editor.org/info/rfc7052>。
[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-Pascual, J., and D. Lewis, "Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations", RFC 7215, DOI 10.17487/RFC7215, April 2014, <https://www.rfc-editor.org/info/rfc7215>.
[RFC7215] Jakab、L.、Cabellos-Aparicio、A.、Coras、F.、Domingo-Pascual、J。、およびD. Lewis、「ロケーター/識別子分離プロトコル（LISP）ネットワーク要素展開に関する考慮事項」、RFC 7215、doi 10.17487/rfc7215、2014年4月、<https://www.rfc-editor.org/info/rfc7215>。
[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>。
[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>。
[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>。
[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>.
[RFC9301] Farinacci、D.、Maino、F.、Fuller、V。、およびA. Cabellos、ed。、「Locator/ID分離プロトコル（LISP）コントロールプレーン」、RFC 9301、DOI 10.17487/RFC9301、10月2022年、<https://www.rfc-editor.org/info/rfc9301>。
[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>。
[Jakab] Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D., and O. Bonaventure, "LISP-TREE: A DNS Hierarchy to Support the LISP Mapping System", IEEE Journal on Selected Areas in Communications, vol. 28, no. 8, pp. 1332-1343, DOI 10.1109/JSAC.2010.101011, October 2010, <https://ieeexplore.ieee.org/document/5586446>.
[Jakab] Jakab、L.、Cabellos-Aparicio、A.、Coras、F.、Sauce、D。、およびO. Bonaventure、「Lisp-Tree：LISPマッピングシステムをサポートするDNS階層」、IEEE Journal on SelectedのIEEEジャーナルコミュニケーションのエリア、Vol。28、いいえ。8、pp。1332-1343、doi 10.1109/jsac.2010.101011、2010年10月、<https://ieeexplore.ieee.org/document/5586446>。
[LISP-EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID Mappings Multicast Across Cooperating Systems for LISP", Work in Progress, Internet-Draft, draft-curran-lisp-emacs-00, 9 November 2007, <https://www.ietf.org/archive/id/ draft-curran-lisp-emacs-00.txt>.
[lisp-emacs] Brim、S.、Farinacci、D.、Meyer、D。、およびJ. Curran、「eid Mappings Multicast for lisp for lisp for lisp」、進行中の作業、インターネットドラフト、ドラフトカランリスプ - EMACS-00、2007年11月9日、<https://www.ietf.org/archive/id/ draft-curran-lisp-emacs-00.txt>。
[LISP-SHDHT] Cheng, L. and M. Sun, "LISP Single-Hop DHT Mapping Overlay", Work in Progress, Internet-Draft, draft-cheng-lisp-shdht-04, 15 July 2013, <https://www.ietf.org/archive/id/draft-cheng-lisp-shdht-04.txt>.
[lisp-shdht] cheng、L。and M. sun、「LISPシングルホップDHTマッピングオーバーレイ」、進行中の作業、インターネットドラフト、ドラフト-Lisp-SHDHT-04、2013年7月15日、<https：//www.ietf.org/archive/id/draft-cheng-lisp-shdht-04.txt>。
[Mathy] Mathy, L. and L. Iannone, "LISP-DHT: Towards a DHT to map identifiers onto locators", CoNEXT '08: Proceedings of the 2008 ACM CoNEXT Conference, ReArch '08 - Re-Architecting the Internet, DOI 10.1145/1544012.1544073, December 2008, <https://dl.acm.org/doi/10.1145/1544012.1544073>.
[Mathy] Mathy、L。and L. Iannone、「Lisp-DHT：DHTに向けて識別子をロケーターにマッピングする」、Conext '08：2008 ACM Conext Conferenceの議事録、Rearch '08-インターネットの再編成、doi10.1145/1544012.1544073、2008年12月、<https://dl.acm.org/doi/10.1145/1544012.1544073>。
[Quoitin] Quoitin, B., Iannone, L., de Launois, C., and O. Bonaventure, "Evaluating the Benefits of the Locator/ Identifier Separation", Proceedings of 2nd ACM/IEEE International Workshop on Mobility in the Evolving Internet Architecture, DOI 10.1145/1366919.1366926, August 2007, <https://dl.acm.org/doi/10.1145/1366919.1366926>.
[Quoitin] Quoitin、B.、Iannone、L.、De Launois、C。、およびO. Bonaventure、「ロケーター/識別子分離の利点を評価する」、進化するインターネットのモビリティに関する第2 ACM/ IEEE国際ワークショップの議事録アーキテクチャ、DOI 10.1145/1366919.1366926、2007年8月、<https://dl.acm.org/doi/10.1145/1366919.1366926>。
Appendix A. A Brief History of Location/Identity Separation
付録A. 場所/アイデンティティ分離の簡単な歴史
The LISP architecture for separation of location and identity resulted from the discussions of this topic at the Amsterdam IAB Routing and Addressing Workshop, which took place in October 2006 [RFC4984].
場所とアイデンティティを分離するためのLISPアーキテクチャは、2006年10月に開催されたアムステルダムIABルーティングとアドレス指定ワークショップでのこのトピックの議論から生じました[RFC4984]。
A small group of like-minded personnel spontaneously formed immediately after that workshop to work on an idea that came out of informal discussions at the workshop and on various mailing lists. The first Internet-Draft on LISP appeared in January 2007.
ワークショップの直後に自発的に志を同じくする人の小さなグループが、ワークショップやさまざまなメーリングリストでの非公式の議論から生まれたアイデアに取り組むために、自発的に形成されました。LISPの最初のインターネットドラフトは2007年1月に登場しました。
Trial implementations started at that time, with initial trial deployments underway since June 2007; the results of early experience have been fed back into the design in a continuous, ongoing process over several years. At this point, LISP represents a moderately mature system, having undergone a long, organic series of changes and updates.
その時点で試験の実装が開始され、2007年6月以降の最初の試用展開が進行中です。初期の経験の結果は、数年にわたって継続的で継続的なプロセスでデザインに戻ってきました。この時点で、LISPは中程度に成熟したシステムを表し、長くてオーガニックな一連の変更と更新を受けました。
LISP transitioned from an IRTF activity to an IETF WG in March 2009. After numerous revisions, the basic specifications moved to becoming RFCs at the start of 2013; work to expand, improve, and find new uses for it continues (and undoubtedly will for a long time to come). The LISP WG was rechartered in 2018 to continue work on the LISP base protocol and produce Standards Track documents.
LISPは、2009年3月にITFアクティビティからIETF WGに移行しました。多数の改訂後、基本仕様は2013年の初めにRFCになりました。それのための新しい用途を拡大し、改善し、見つけるために働き続けます（そして間違いなくこれからも長い間そうなります）。LISP WGは、LISPベースプロトコルの作業を継続し、標準トラックドキュメントを作成するために、2018年に充電されました。
LISP, as initially conceived, had a number of potential operating modes, named 'models'. Although they are not used anymore, one occasionally sees mention of them, so they are briefly described here.
LISPには当初考えられていたように、「モデル」という名前の多くの潜在的な動作モードがありました。それらはもう使用されていませんが、時々それらについて言及されるので、ここで簡単に説明します。
LISP 1: EIDs all appear in the normal routing and forwarding tables of the network (i.e., they are 'routable'). This property is used to load EID-to-RLOC mappings via bootstrapping operations. Packets are sent with the EID as the destination in the outer wrapper; when an ETR sees such a packet, it sends a Map-Reply to the source ITR, giving the full mapping.
LISP 1：Eidsはすべて、ネットワークの通常のルーティングテーブルと転送テーブルに表示されます（つまり、「ルーティング可能」です）。このプロパティは、ブートストラップ操作を介してEid-to-RLOCマッピングをロードするために使用されます。パケットは、外側のラッパーの目的地としてEidとともに送信されます。ETRがそのようなパケットを見ると、ソースITRにマップ返送を送信し、完全なマッピングを提供します。
LISP 1.5: LISP 1.5 is similar to LISP 1, but the routability of EIDs happens on a separate network.
LISP 1.5：LISP 1.5はLISP 1に似ていますが、EIDのルー上のルーチャ性は別のネットワークで発生します。
LISP 2: EIDs are not routable; EID-to-RLOC mappings are available from the DNS.
LISP 2：Eidsはルーティング可能ではありません。Eid-to-RLOCマッピングは、DNSから入手できます。
LISP 3: EIDs are not routable and have to be looked up in a new EID-to-RLOC mapping database (in the initial concept, a system using Distributed Hash Tables). Two variants were possible: a 'push' system in which all mappings were distributed to all ITRs and a 'pull' system in which ITRs load the mappings when they need them.
LISP 3：Eidsはルーティング可能ではなく、新しいEid-to-RLOCマッピングデータベース（最初の概念では、分散ハッシュテーブルを使用したシステム）で調べる必要があります。2つのバリエーションが可能でした。すべてのマッピングがすべてのITRに分散された「プッシュ」システムと、必要なときにマッピングをロードする「プル」システムです。
Acknowledgments
謝辞
This document was initiated by Noel Chiappa, and much of the core philosophy came from him. The authors acknowledge the important contributions he has made to this work and thank him for his past efforts.
この文書はノエル・チアッパによって開始され、核となる哲学の多くは彼から来ました。著者は、彼がこの仕事に対して行った重要な貢献を認め、彼の過去の努力に感謝します。
The authors would also like to thank Dino Farinacci, Fabio Maino, Luigi Iannone, Sharon Barkai, Isidoros Kouvelas, Christian Cassar, Florin Coras, Marc Binderberger, Alberto Rodriguez-Natal, Ronald Bonica, Chad Hintz, Robert Raszuk, Joel M. Halpern, Darrel Lewis, and David Black.
著者はまた、ディノ・ファリナッチ、ファビオ・マニョ、ルイジ・イアンノーネ、シャロン・バルカイ、イシドロス・コウベラス、クリスチャン・カッサー、フロリン・コーラス、マーク・バインダーバーガー、アルベルト・ロドリゲス・ナタール、ロナルド・ボニカ、チャド・ヒンツ、ロバート・ラスク、ジョエル・M・ハルパーンダレル・ルイス、デビッド・ブラック。
Authors' Addresses
著者のアドレス
Albert Cabellos Universitat Politecnica de Catalunya c/ Jordi Girona s/n 08034 Barcelona Spain Email: acabello@ac.upc.edu
Albert Cabellos Universitat Politecnica de Catalunya C/ Jordi Girona S/ N 08034バルセロナスペインメール：acabello@ac.upc.edu
Damien Saucez (editor) Inria 2004 route des Lucioles - BP 93 Sophia Antipolis France Email: damien.saucez@inria.fr
Damien Saucez（編集者）INRIA 2004 Route Des Lucioles -BP 93 Sophia Antipolis France Email：damien.saucez@inria.fr