[要約] RFC 9300 は、Locator/ID Separation Protocol (LISP) のデータプレーンプロトコルを定義し、EIDとRLOCの2つの名前空間を使用してコントロールとデータを分離し、オーバーレイネットワークを作成することを可能にします。
Internet Engineering Task Force (IETF) D. Farinacci
Request for Comments: 9300 lispers.net
Obsoletes: 6830 V. Fuller
Category: Standards Track vaf.net Internet Consulting
ISSN: 2070-1721 D. Meyer
1-4-5.net
D. Lewis
Cisco Systems
A. Cabellos, Ed.
Universitat Politecnica de Catalunya
October 2022
The Locator/ID Separation Protocol (LISP)
ロケーター/ID分離プロトコル（LISP）
Abstract
概要
This document describes the data plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces: Endpoint Identifiers (EIDs), which identify end hosts; and Routing Locators (RLOCs), which identify network attachment points. With this, LISP effectively separates control from data and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache.
このドキュメントでは、ロケーター/ID分離プロトコル（LISP）のデータプレーンプロトコルについて説明します。LISPは、エンドホストを識別するエンドポイント識別子（EIDS）の2つの名前空間を定義します。ルーティングロケーター（RLOC）は、ネットワーク添付のポイントを識別します。これにより、LISPはコントロールをデータから効果的に分離し、ルーターがオーバーレイネットワークを作成できるようにします。LISP対応ルーターは、ローカルマップキャッシュに保存されているEid-to-RLOCマッピングに従ってカプセル化されたパケットを交換します。
LISP requires no change to either host protocol stacks or underlay routers and offers Traffic Engineering (TE), multihoming, and mobility, among other features.
LISPは、ホストプロトコルスタックまたはアンダーレイルーターのいずれにも変更を必要とせず、トラフィックエンジニアリング（TE）、マルチホーム、モビリティなどを提供します。
This document obsoletes RFC 6830.
このドキュメントは、RFC 6830を廃止します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9300.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9300で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
1.1. Scope of Applicability
2. Requirements Notation
3. Definitions of Terms
4. Basic Overview
4.1. Deployment on the Public Internet
4.2. Packet Flow Sequence
5. LISP Encapsulation Details
5.1. LISP IPv4-in-IPv4 Header Format
5.2. LISP IPv6-in-IPv6 Header Format
5.3. Tunnel Header Field Descriptions
6. LISP EID-to-RLOC Map-Cache
7. Dealing with Large Encapsulated Packets
7.1. A Stateless Solution to MTU Handling
7.2. A Stateful Solution to MTU Handling
8. Using Virtualization and Segmentation with LISP
9. Routing Locator Selection
10. Routing Locator Reachability
10.1. Echo-Nonce Algorithm
11. EID Reachability within a LISP Site
12. Routing Locator Hashing
13. Changing the Contents of EID-to-RLOC Mappings
13.1. Locator-Status-Bits
13.2. Database Map-Versioning
14. Multicast Considerations
15. Router Performance Considerations
16. Security Considerations
17. Network Management Considerations
18. Changes since RFC 6830
19. IANA Considerations
19.1. LISP UDP Port Numbers
20. References
20.1. Normative References
20.2. Informative References
Acknowledgments
Authors' Addresses
This document describes the Locator/ID Separation Protocol (LISP). LISP is an encapsulation protocol built around the fundamental idea of separating the topological location of a network attachment point from the node's identity [CHIAPPA]. As a result, LISP creates two namespaces: Endpoint Identifiers (EIDs), which are used to identify end hosts (e.g., nodes or Virtual Machines); and routable Routing Locators (RLOCs), which are used to identify network attachment points. LISP then defines functions for mapping between the two namespaces and for encapsulating traffic originated by devices using non-routable EIDs for transport across a network infrastructure that routes and forwards using RLOCs. LISP encapsulation uses a dynamic form of tunneling where no static provisioning is required or necessary.
このドキュメントでは、ロケーター/ID分離プロトコル（LISP）について説明します。LISPは、ネットワークアタッチメントポイントのトポロジカル位置をノードのID [Chiappa]から分離するという基本的なアイデアを中心に構築されたカプセル化プロトコルです。その結果、LISPは2つの名前空間を作成します。エンドポイント識別子（EIDS）は、エンドホスト（ノードや仮想マシンなど）を識別するために使用されます。ネットワーク添付のポイントを識別するために使用されるルーティング可能なルーティングロケーター（RLOC）。次に、LISPは、2つの名前空間間のマッピングと、RLOCを使用してルーティングと転送を行うネットワークインフラストラクチャを介したトランスポートのために、不可能なEIDを使用してデバイスから発信されるトラフィックをカプセル化するための関数を定義します。LISPカプセル化は、静的プロビジョニングが不要または不要な動的形式のトンネルを使用します。
LISP is an overlay protocol that separates control from data; this document specifies the data plane as well as how LISP-capable routers (Tunnel Routers) exchange packets by encapsulating them to the appropriate location. Tunnel Routers are equipped with a cache, called the Map-Cache, that contains EID-to-RLOC mappings. The Map-Cache is populated using the LISP control plane protocol [RFC9301].
LISPは、コントロールをデータから分離するオーバーレイプロトコルです。このドキュメントは、データプレーンと、適切な場所にカプセル化することにより、LISP対応ルーター（トンネルルーター）交換パケットを指定します。トンネルルーターには、Eid-to-Rlocマッピングが含まれるMap-Cacheと呼ばれるキャッシュが装備されています。マップキャッシュは、LISPコントロールプレーンプロトコル[RFC9301]を使用して入力されます。
LISP does not require changes to either the host protocol stack or underlay routers. By separating the EID from the RLOC space, LISP offers native Traffic Engineering (TE), multihoming, and mobility, among other features.
LISPでは、ホストプロトコルスタックまたはアンダーレイルーターのいずれの変更を必要としません。EIDをRLOCスペースから分離することにより、LISPはネイティブトラフィックエンジニアリング（TE）、マルチホーム、モビリティなどを提供します。
Creation of LISP was initially motivated by discussions during the IAB-sponsored Routing and Addressing Workshop held in Amsterdam in October 2006 (see [RFC4984]).
LISPの作成は、2006年10月にアムステルダムで開催されたIABが後援するルーティングおよびアドレス指定ワークショップ中の議論によって当初動機付けられました（[RFC4984を参照]）。
This document specifies the LISP data plane encapsulation and other LISP forwarding node functionality while [RFC9301] specifies the LISP control plane. LISP deployment guidelines can be found in [RFC7215], and [RFC6835] describes considerations for network operational management. Finally, [RFC9299] describes the LISP architecture.
このドキュメントは、LISPデータプレーンのカプセル化とその他のLISP転送ノード機能を指定し、[RFC9301]はLISPコントロールプレーンを指定します。LISPの展開ガイドラインは[RFC7215]に記載されており、[RFC6835]はネットワーク運用管理の考慮事項を説明しています。最後に、[RFC9299]はLISPアーキテクチャについて説明します。
This document obsoletes RFC 6830.
このドキュメントは、RFC 6830を廃止します。
LISP was originally developed to address the Internet-wide route scaling problem [RFC4984]. While there are a number of approaches of interest for that problem, as LISP has been developed and refined, a large number of other ways to use LISP have been found and are being implemented. As such, the design and development of LISP have changed so as to focus on these use cases. The common property of these uses is a large set of cooperating entities seeking to communicate over the public Internet or other large underlay IP infrastructures while keeping the addressing and topology of the cooperating entities separate from the underlay and Internet topology, routing, and addressing.
LISPはもともと、インターネット全体のルートスケーリング問題に対処するために開発されました[RFC4984]。LISPが開発され、洗練されているため、その問題には多くの関心のあるアプローチがありますが、LISPを使用する他の多くの方法が見つかり、実装されています。そのため、LISPの設計と開発は、これらのユースケースに焦点を当てるように変更されました。これらの用途の共通の特性は、パブリックインターネットやその他の大規模なアンダーレイIPインフラストラクチャを介して通信しようとする協力エンティティの大規模なセットであり、協力エンティティのアドレス指定とトポロジーを、アンダーレイおよびインターネットトポロジ、ルーティング、およびアドレス指定とは別に維持します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Address Family Identifier (AFI): "AFI" is a term used to describe an address encoding in a packet. An address family is an address format found in data plane packet headers, for example, an IPv4 address or an IPv6 address. See [AFN], [RFC2453], [RFC2677], and [RFC4760] for details. An AFI value of 0 used in this specification indicates an unspecified encoded address where the length of the address is 0 octets following the 16-bit AFI value of 0.
アドレスファミリ識別子（AFI）：「AFI」は、パケットでエンコードするアドレスを記述するために使用される用語です。アドレスファミリは、IPv4アドレスやIPv6アドレスなど、データプレーンパケットヘッダーにあるアドレス形式です。詳細については、[AFN]、[RFC2453]、[RFC2677]、および[RFC4760]を参照してください。この仕様で使用される0のAFI値は、16ビットAFI値0に続くアドレスの長さが0オクテットである不特定のエンコードアドレスを示します。
Anycast Address: "Anycast address" refers to the same IPv4 or IPv6 address configured and used on multiple systems at the same time. An EID or RLOC can be an anycast address in each of their own address spaces.
AnyCastアドレス：「AnyCastアドレス」とは、複数のシステムで同時に設定され、同じIPv4またはIPv6アドレスを同時に使用します。EIDまたはRLOCは、独自のアドレススペースのそれぞれのAnycastアドレスにすることができます。
Client-side: "Client-side" is a term used in this document to indicate a connection initiation attempt by an end-system represented by an EID.
クライアント側：「クライアントサイド」は、このドキュメントで使用されている用語で、EIDが表す最終システムによる接続開始の試みを示します。
Egress Tunnel Router (ETR): An ETR is a router that accepts an IP packet where the destination address in the "outer" IP header is one of its own RLOCs. The router strips the "outer" header and forwards the packet based on the next IP header found. In general, an ETR receives LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the other side. ETR functionality does not have to be limited to a router device. A server host can be the endpoint of a LISP tunnel as well.
出力トンネルルーター（ETR）：ETRは、「外側」IPヘッダーの宛先アドレスが独自のRLOCの1つであるIPパケットを受け入れるルーターです。ルーターは「外側」ヘッダーをストリップし、見つかった次のIPヘッダーに基づいてパケットを転送します。一般に、ETRは、片側のインターネットからリスプカプセル化されたIPパケットを受け取り、反対側のサイトエンドシステムに脱カプセル化IPパケットを送信します。ETR機能は、ルーターデバイスに制限する必要はありません。サーバーホストは、LISPトンネルのエンドポイントでもあります。
EID-to-RLOC Database: The EID-to-RLOC Database is a distributed database that contains all known EID-Prefix-to-RLOC mappings. Each potential ETR typically contains a small piece of the database: the EID-to-RLOC mappings for the EID-Prefixes "behind" the router. These map to one of the router's own IP addresses that are routable on the underlay. Note that there MAY be transient conditions when the EID-Prefix for the LISP site and Locator-Set for each EID-Prefix may not be the same on all ETRs. This has no negative implications, since a partial set of Locators can be used.
EID-to-RLOCデータベース：EID-to-RLOCデータベースは、既知のすべてのEid-Prefix-to-RLOCマッピングを含む分散データベースです。通常、各潜在的なETRには、データベースの小さな部分が含まれています。これは、ルーターの「後ろ」のeid-prefixesのeid-to-rlocマッピングです。これらのマップは、アンダーレイでルーティング可能なルーター自身のIPアドレスの1つにマップします。各EID-PrefixのLISPサイトとロケーターセットのEid-PrefixがすべてのETRで同じではない場合がある場合、一時的な条件がある場合があることに注意してください。部分的なロケーターのセットを使用できるため、これにはマイナスの意味はありません。
EID-to-RLOC Map-Cache: The EID-to-RLOC Map-Cache is a generally short-lived, on-demand table in an Ingress Tunnel Router (ITR) that stores, tracks, and is responsible for timing out and otherwise validating EID-to-RLOC mappings. This cache is distinct from the full "database" of EID-to-RLOC mappings; it is dynamic, local to the ITR(s), and relatively small, while the database is distributed, relatively static, and much more widely scoped to LISP nodes.
Eid-to-rlocマップキャッシュ：Eid-to-rlocマップキャッシュは、侵入トンネルルーター（ITR）の一般的な短命のオンデマンドテーブルで、タイミングを上げ、追跡し、責任を負います。Eid-to-RLOCマッピングの検証。このキャッシュは、Eid-to-RLOCマッピングの完全な「データベース」とは異なります。それは動的で、ITRにローカルであり、比較的小さいですが、データベースは分散され、比較的静的であり、LISPノードに対してはるかに広くスコープされています。
EID-Prefix: An EID-Prefix is a power-of-two block of EIDs that are allocated to a site by an address allocation authority. EID-Prefixes are associated with a set of RLOC addresses. EID-Prefix allocations can be broken up into smaller blocks when an RLOC-Set is to be associated with the larger EID-Prefix block.
Eid-Prefix：Eid-Prefixは、住所配分局によってサイトに割り当てられたEidsの2つのパワーブロックです。Eid-Prefixesは、RLOCアドレスのセットに関連付けられています。rloc-setがより大きなeid-prefixブロックに関連付けられる場合、eid-prefixの割り当ては小さなブロックに分割できます。
End-System: An end-system is an IPv4 or IPv6 device that originates packets with a single IPv4 or IPv6 header. The end-system supplies an EID value for the destination address field of the IP header when communicating outside of its routing domain. An end-system can be a host computer, a switch or router device, or any network appliance.
エンドシステム：エンドシステムは、単一のIPv4またはIPv6ヘッダーでパケットを発信するIPv4またはIPv6デバイスです。最終システムは、ルーティングドメインの外側で通信する際に、IPヘッダーの宛先アドレスフィールドにEID値を提供します。エンドシステムは、ホストコンピューター、スイッチまたはルーターデバイス、または任意のネットワークアプライアンスです。
Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for IPv6) value that identifies a host. EIDs are generally only found in the source and destination address fields of the first (innermost) LISP header of a packet. The host obtains a destination EID through a Domain Name System (DNS) [RFC1034] lookup or Session Initiation Protocol (SIP) [RFC3261] exchange. This behavior does not change when LISP is in use. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID used on the public Internet MUST have the same properties as any other IP address used in that manner; this means, among other things, that it MUST be unique. An EID is allocated to a host from an EID-Prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. Note that EID blocks MAY be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site MAY have site-local structure (subnetting) for routing within the site; this structure is not visible to the underlay routing system. In theory, the bit string that represents an EID for one device can represent an RLOC for a different device. When discussing other Locator/ID separation proposals, any references to an EID in this document will refer to a LISP EID.
Endpoint ID（EID）：EIDは、ホストを識別する32ビット（IPv4の場合）または128ビット（IPv6の場合）値です。 Eidsは、通常、パケットの最初の（最も内側）LISPヘッダーのソースおよび宛先アドレスフィールドにのみ見られます。ホストは、ドメイン名システム（DNS）[RFC1034]ルックアップまたはセッション開始プロトコル（SIP）[RFC3261] Exchangeを介して宛先EIDを取得します。 LISPが使用されている場合、この動作は変わりません。ソースEIDは、ホストの「ローカル」IPアドレスを設定するために使用される既存のメカニズムを介して取得されます。パブリックインターネットで使用されるEIDには、その方法で使用される他のIPアドレスと同じプロパティが必要です。これは、とりわけ、それが一意でなければならないことを意味します。 EIDは、ホストが位置するサイトに関連付けられたEid-Prefixブロックからホストに割り当てられます。 EIDは、ホストが他のホストを参照するために使用できます。マッピングデータベースのスケーリングを容易にするために、EIDブロックはネットワークトポロジとは無関係に階層的に割り当てられる場合があることに注意してください。さらに、サイトに割り当てられたEIDブロックには、サイト内のルーティングのためのサイトローカル構造（サブネット）がある場合があります。この構造は、アンダーレイルーティングシステムには見えません。理論的には、1つのデバイスのEIDを表すビット文字列は、別のデバイスのRLOCを表すことができます。他のロケーター/ID分離提案について議論する場合、このドキュメントのEIDへの参照は、Lisp Eidを参照します。
Ingress Tunnel Router (ITR): An ITR is a router that resides in a LISP site. Packets sent by sources inside of the LISP site to destinations outside of the site are candidates for encapsulation by the ITR. The ITR treats the IP destination address as an EID and performs an EID-to-RLOC mapping lookup. The router then prepends an "outer" IP header with one of its routable RLOCs (in the RLOC space) in the source address field and the result of the mapping lookup in the destination address field. Note that this destination RLOC may be an intermediate, proxy device that has better knowledge of the EID-to-RLOC mapping closer to the destination EID. In general, an ITR receives IP packets from site end-systems on one side and sends LISP-encapsulated IP packets toward the Internet on the other side.
イングレストンネルルーター（ITR）：ITRは、LISPサイトにあるルーターです。LISPサイト内のソースからサイトの外側の目的地に送信されるパケットは、ITRによるカプセル化の候補です。ITRは、IP宛先アドレスをEIDとして扱い、Eid-to-RLOCマッピングルックアップを実行します。次に、ルーターは、ソースアドレスフィールドにルーティング可能なRLOC（RLOCスペース）の1つと、宛先アドレスフィールドのマッピングルックアップの結果を備えた「外側」IPヘッダーを準備します。この宛先RLOCは、宛先EIDに近いEIDからRLOCへのマッピングの知識をよりよく持っている中間のプロキシデバイスである可能性があることに注意してください。一般に、ITRは、片側のサイトエンドシステムからIPパケットを受信し、反対側のインターネットにリスプでカプセル化されたIPパケットを送信します。
LISP Header: "LISP header" is a term used in this document to refer to the outer IPv4 or IPv6 header, a UDP header, and a LISP-specific 8-octet header, all of which follow the UDP header. An ITR prepends LISP headers on packets, and an ETR strips them.
LISPヘッダー：「LISPヘッダー」は、このドキュメントで使用されている用語であり、外側のIPv4またはIPv6ヘッダー、UDPヘッダー、およびLISP固有の8-OCTETヘッダーを参照しています。これらはすべてUDPヘッダーに従います。ITRは、パケットにLISPヘッダーをプリケンドし、ETRがそれらをストリップします。
LISP Router: A LISP router is a router that performs the functions of any or all of the following: ITRs, ETRs, Re-encapsulating Tunneling Routers (RTRs), Proxy-ITRs (PITRs), or Proxy-ETRs (PETRs).
LISPルーター：LISPルーターは、以下のいずれかまたはすべての関数を実行するルーターです。ITR、ETRS、トンネルルーター（RTR）、プロキシ-ITR（PITR）、またはプロキシエートル（PETRS）の再エンコーシング。
LISP Site: A LISP site is a set of routers in an edge network that are under a single technical administration. LISP routers that reside in the edge network are the demarcation points to separate the edge network from the core network.
LISPサイト：LISPサイトは、単一の技術管理下にあるエッジネットワークのルーターのセットです。エッジネットワークに存在するLISPルーターは、エッジネットワークをコアネットワークから分離する境界点です。
Locator-Status-Bits (LSBs): Locator-Status-Bits are present in the LISP header. They are used by ITRs to inform ETRs about the up/ down status of all ETRs at the local site. These bits are used as a hint to convey up/down router status and not path reachability status. The LSBs can be verified by use of one of the Locator reachability algorithms described in Section 10. An ETR MUST rate limit the action it takes when it detects changes in the Locator-Status-Bits.
Locator-Status-Bits（LSB）：LISPヘッダーにはロケーターステータスビットが存在します。ITRは、ローカルサイトでのすべてのETRのアップ/ダウンステータスについてETRに通知するために使用されます。これらのビットは、パスの到達可能性ステータスではなく、ルーターのステータスを上下に伝えるためのヒントとして使用されます。LSBは、セクション10で説明されているロケーターReachabilityアルゴリズムの1つを使用することにより検証できます。ETRは、ロケーター-Statusビットの変更を検出したときに取るアクションを制限する必要があります。
Proxy-ETR (PETR): A PETR is defined and described in [RFC6832]. A PETR acts like an ETR but does so on behalf of LISP sites that send packets to destinations at non-LISP sites.
Proxy-ERT（PETR）：PETRは[RFC6832]で定義され、説明されています。PETRはETRのように機能しますが、非リスプサイトの宛先にパケットを送信するLISPサイトを代表して行います。
Proxy-ITR (PITR): A PITR is defined and described in [RFC6832]. A PITR acts like an ITR but does so on behalf of non-LISP sites that send packets to destinations at LISP sites.
Proxy-ITR（PITR）：PITRは[RFC6832]で定義され、説明されています。PITRはITRのように機能しますが、LISPサイトの宛先にパケットを送信する非リスプサイトを代表して行います。
Recursive Tunneling: Recursive Tunneling occurs when a packet has more than one LISP IP header. Additional layers of tunneling MAY be employed to implement Traffic Engineering or other rerouting as needed. When this is done, an additional "outer" LISP header is added, and the original RLOCs are preserved in the "inner" header.
再帰トンネル：再帰トンネリングは、パケットに複数のLISP IPヘッダーがある場合に発生します。必要に応じて、トラフィックエンジニアリングまたはその他の再ルーティングを実装するために、トンネルの追加層を使用することができます。これが完了すると、追加の「外側」LISPヘッダーが追加され、元のRLOCが「内側」ヘッダーに保存されます。
Re-encapsulating Tunneling Router (RTR): An RTR acts like an ETR to remove a LISP header, then acts as an ITR to prepend a new LISP header. This is known as Re-encapsulating Tunneling. Doing this allows a packet to be rerouted by the RTR without adding the overhead of additional tunnel headers. When using multiple mapping database systems, care must be taken to not create re-encapsulation loops through misconfiguration.
トンネルルーター（RTR）の再カプセル化：RTRはETRのように動作してLISPヘッダーを削除し、新しいLISPヘッダーを準備するITRとして機能します。これは、トンネリングの再エンコーシングとして知られています。これを行うことで、追加のトンネルヘッダーのオーバーヘッドを追加せずに、RTRによってパケットを再ルーティングできます。複数のマッピングデータベースシステムを使用する場合、誤った設定を介して再エンカプセル化ループを作成しないように注意する必要があります。
Route-Returnability: Route-returnability is an assumption that the underlying routing system will deliver packets to the destination. When combined with a nonce that is provided by a sender and returned by a receiver, this limits off-path data insertion. A route-returnability check is verified when a message is sent with a nonce, another message is returned with the same nonce, and the destination of the original message appears as the source of the returned message.
ルート回復可能性：ルート回復可能性は、基礎となるルーティングシステムが宛先にパケットを配信するという仮定です。送信者によって提供され、受信機によって返されるNonCEと組み合わせると、これはオフパスデータ挿入を制限します。Route-Returnability Checkは、メッセージがnonceで送信され、別のメッセージが同じnonceで返され、元のメッセージの宛先が返されたメッセージのソースとして表示されると確認されます。
Routing Locator (RLOC): An RLOC is an IPv4 address [RFC0791] or IPv6 address [RFC8200] of an Egress Tunnel Router (ETR). An RLOC is the output of an EID-to-RLOC mapping lookup. An EID maps to zero or more RLOCs. Typically, RLOCs are numbered from blocks that are assigned to a site at each point to which it attaches to the underlay network, where the topology is defined by the connectivity of provider networks. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site.
ルーティングロケーター（RLOC）：RLOCは、出口トンネルルーター（ETR）のIPv4アドレス[RFC0791]またはIPv6アドレス[RFC8200]です。RLOCは、Eid-to-RLOCマッピングルックアップの出力です。eidはゼロ以上のRLOCにマップします。通常、RLOCは、トポロジーがプロバイダーネットワークの接続によって定義されているアンダーレイネットワークに付着する各ポイントのサイトに割り当てられたブロックから番号が付けられています。複数のRLOCは、同じETRデバイスまたはサイトの複数のETRデバイスに割り当てることができます。
Server-side: "Server-side" is a term used in this document to indicate that a connection initiation attempt is being accepted for a destination EID.
サーバー側：「サーバー側」は、このドキュメントで使用される用語であり、宛先EIDに対して接続開始の試みが受け入れられていることを示します。
xTR: An xTR is a reference to an ITR or ETR when direction of data flow is not part of the context description. "xTR" refers to the router that is the tunnel endpoint and is used synonymously with the term "Tunnel Router". For example, "An xTR can be located at the Customer Edge (CE) router" indicates both ITR and ETR functionality at the CE router.
XTR：XTRは、データフローの方向がコンテキストの説明の一部ではない場合のITRまたはETRへの参照です。「XTR」とは、トンネルエンドポイントであるルーターを指し、「トンネルルーター」という用語と同義語で使用されます。たとえば、「XTRは顧客エッジ（CE）ルーターに配置できます」は、CEルーターのITR機能とETR機能の両方を示します。
One key concept of LISP is that end-systems operate the same way when LISP is not in use as well as when LISP is in use. The IP addresses that hosts use for tracking sockets and connections, and for sending and receiving packets, do not change. In LISP terminology, these IP addresses are called Endpoint Identifiers (EIDs).
LISPの重要な概念の1つは、LISPが使用されていない場合とLISPが使用されている場合と同じように動作することです。ホストをホストするIPアドレスは、ソケットと接続を追跡し、パケットの送信と受信に使用しても変更されません。LISP用語では、これらのIPアドレスはエンドポイント識別子（EIDS）と呼ばれます。
Routers continue to forward packets based on IP destination addresses. When a packet is LISP encapsulated, these addresses are referred to as RLOCs. Most routers along a path between two hosts will not change; they continue to perform routing/forwarding lookups on the destination addresses. For routers between the source host and the ITR as well as routers from the ETR to the destination host, the destination address is an EID. For the routers between the ITR and the ETR, the destination address is an RLOC.
ルーターは、IP宛先アドレスに基づいてパケットを転送し続けます。パケットがLISPカプセル化されている場合、これらのアドレスはRLOCと呼ばれます。2つのホスト間のパスに沿ったほとんどのルーターは変更されません。彼らは、宛先アドレスでルーティング/転送ルックアップを引き続き実行します。ソースホストとITR間のルーター、およびETRから宛先ホストまでのルーターの場合、宛先アドレスはEIDです。ITRとETRの間のルーターの場合、宛先アドレスはRLOCです。
Another key LISP concept is the "Tunnel Router". A Tunnel Router prepends LISP headers on host-originated packets and strips them prior to final delivery to their destination. The IP addresses in this "outer header" are RLOCs. During end-to-end packet exchange between two Internet hosts, an ITR prepends a new LISP header to each packet, and an ETR strips the new header. The ITR performs EID-to-RLOC lookups to determine the routing path to the ETR, which has the RLOC as one of its IP addresses.
もう1つの重要なLISPコンセプトは、「トンネルルーター」です。トンネルルーターは、宿主造影パケットにLISPヘッダーをプリケンドし、目的地に最終配達する前にそれらを取り除きます。この「外側のヘッダー」のIPアドレスはRLOCです。2つのインターネットホスト間のエンドツーエンドのパケット交換中、ITRは各パケットに新しいLISPヘッダーをプリケンドし、ETRが新しいヘッダーをストリップします。ITRは、EIDからRLOCのルックアップを実行して、IPアドレスの1つとしてRLOCを持つETRへのルーティングパスを決定します。
Some basic rules governing LISP are:
LISPを管理するいくつかの基本的なルールは次のとおりです。
* End-systems only send to addresses that are EIDs. EIDs are typically IP addresses assigned to hosts (other types of EIDs are supported by LISP; see [RFC8060] for further information). End-systems don't know that addresses are EIDs versus RLOCs but assume that packets get to their intended destinations. In a system where LISP is deployed, LISP routers intercept EID-addressed packets and assist in delivering them across the network core where EIDs cannot be routed. The procedure a host uses to send IP packets does not change.
* エンドシステムは、Eidsである住所にのみ送信します。EIDは通常、ホストに割り当てられたIPアドレスです（他のタイプのEIDはLISPによってサポートされています。詳細については[RFC8060]を参照）。エンドシステムは、アドレスがeids対rlocsであることを知らないが、パケットが意図した宛先に到達すると想定している。LISPが展開されているシステムでは、LISPルーターがEIDにアドレスしたパケットをインターセプトし、Eidsをルーティングできないネットワークコア全体でそれらを配信するのを支援します。ホストがIPパケットを送信するために使用する手順は変更されません。
* LISP routers prepend and strip outer headers with RLOC addresses. See Section 4.2 for details.
* LISPルーターは、RLOCアドレスを備えた外側のヘッダーをプレーニングおよびストリップします。詳細については、セクション4.2を参照してください。
* RLOCs are always IP addresses assigned to routers, preferably topologically oriented addresses from provider Classless Inter-Domain Routing (CIDR) blocks.
* RLOCは、常にルーターに割り当てられたIPアドレス、できればプロバイダーのクラスレスインタードメインルーティング（CIDR）ブロックからのトポロジカル指向のアドレスです。
* When a router originates packets, it MAY use as a source address either an EID or RLOC. When acting as a host (e.g., when terminating a transport session such as Secure Shell (SSH), TELNET, or the Simple Network Management Protocol (SNMP)), it MAY use an EID that is explicitly assigned for that purpose. An EID that identifies the router as a host MUST NOT be used as an RLOC; an EID is only routable within the scope of a site. A typical BGP configuration might demonstrate this "hybrid" EID/RLOC usage where a router could use its "host-like" EID to terminate internal BGP (iBGP) sessions to other routers in a site while at the same time using RLOCs to terminate external BGP (eBGP) sessions to routers outside the site.
* ルーターがパケットを発信する場合、EIDまたはRLOCのいずれかのソースアドレスとして使用できます。ホストとして機能する場合（たとえば、Secure Shell（SSH）、Telnet、Simple Network Management Protocol（SNMP）などのトランスポートセッションを終了する場合、その目的のために明示的に割り当てられるEIDを使用する場合があります。ルーターをホストとして識別するEIDは、RLOCとして使用してはなりません。EIDは、サイトの範囲内でのみルーティング可能です。典型的なBGP構成は、ルーターが「ホストのような」EIDを使用して内部BGP（IBGP）セッションをサイト内の他のルーターに終了すると同時にRLOCを使用して外部を終了できるこの「ハイブリッド」EID/RLOC使用量を実証する可能性があります。サイト外のルーターへのBGP（EBGP）セッション。
* Packets with EIDs in them are not expected to be delivered end to end in the absence of an EID-to-RLOC mapping operation. They are expected to be used locally for intra-site communication or to be encapsulated for inter-site communication.
* Eidsが入ったパケットは、Eid-to-RLOCマッピング操作がない場合、端から端まで配信されることは期待されていません。それらは、サイト内通信のためにローカルに使用されるか、サイト間通信のためにカプセル化されることが期待されています。
* EIDs MAY also be structured (subnetted) in a manner suitable for local routing within an Autonomous System (AS).
* Eidsは、自律システム内のローカルルーティングに適した方法で構造化（サブネット）することもできます（AS）。
An additional LISP header MAY be prepended to packets by a TE-ITR when rerouting of the path for a packet is desired. A potential use case for this would be an ISP router that needs to perform Traffic Engineering for packets flowing through its network. In such a situation, termed "Recursive Tunneling", an ISP transit acts as an additional ITR, and the destination RLOC it uses for the new prepended header would be either a TE-ETR within the ISP (along an intra-ISP traffic-engineered path) or a TE-ETR within another ISP (an inter-ISP traffic-engineered path, where an agreement to build such a path exists).
パケットのパスの再ルーティングが必要な場合、追加のLISPヘッダーをTE-ITRによってパケットに準備することができます。これの潜在的なユースケースは、ネットワークを流れるパケットのトラフィックエンジニアリングを実行する必要があるISPルーターです。このような状況では、「再帰トンネリング」と呼ばれる場合、ISPトランジットは追加のITRとして機能し、新しいプリデンドヘッダーに使用する宛先RLOCはISP内のTE-ETRです（INTRA ISPトラフィックエンジニアリングに沿っていますパス）または別のISP内のTE-ERT（そのようなパスを構築する合意が存在するISP間のトラフィックエンジニアリングパス）。
In order to avoid excessive packet overhead as well as possible encapsulation loops, it is RECOMMENDED that a maximum of two LISP headers can be prepended to a packet. For initial LISP deployments, it is assumed that two headers is sufficient, where the first prepended header is used at a site for separation of location and identity and the second prepended header is used inside a service provider for Traffic Engineering purposes.
過度のパケットオーバーヘッドと可能なカプセル化ループを避けるために、最大2つのLISPヘッダーをパケットに準備することをお勧めします。初期のLISP展開の場合、2つのヘッダーで十分であり、最初の準備されたヘッダーが場所とアイデンティティを分離するためにサイトで使用され、2番目のプリプドヘッダーはトラフィックエンジニアリングのためにサービスプロバイダー内で使用されます。
Tunnel Routers can be placed fairly flexibly in a multi-AS topology. For example, the ITR for a particular end-to-end packet exchange might be the first-hop or default router within a site for the source host. Similarly, the ETR might be the last-hop router directly connected to the destination host. As another example, perhaps for a VPN service outsourced to an ISP by a site, the ITR could be the site's border router at the service provider attachment point. Mixing and matching of site-operated, ISP-operated, and other Tunnel Routers is allowed for maximum flexibility.
トンネルルーターは、マルチASトポロジーにかなり柔軟に配置できます。たとえば、特定のエンドツーエンドパケット交換のITRは、ソースホストのサイト内の最初のホップまたはデフォルトのルーターである可能性があります。同様に、ETRは、宛先ホストに直接接続された最後のホップルーターである可能性があります。別の例として、おそらくサイトによってISPに外部委託されたVPNサービスの場合、ITRはサービスプロバイダーの添付資料のサイトのボーダールーターになる可能性があります。サイト操作、ISP操作、およびその他のトンネルルーターの混合とマッチングは、最大限の柔軟性を得ることができます。
Several of the mechanisms in this document are intended for deployment in controlled, trusted environments and are insecure for use over the public Internet. In particular, on the public Internet, xTRs:
このドキュメントのメカニズムのいくつかは、制御された信頼できる環境での展開を目的としており、パブリックインターネットでの使用は安全ではありません。特に、パブリックインターネットでは、Xtrs：
* MUST set the N-, L-, E-, and V-bits in the LISP header (Section 5.1) to zero.
* LISPヘッダー（セクション5.1）のn、l-、e-、およびvビットをゼロに設定する必要があります。
* MUST NOT use Locator-Status-Bits and Echo-Nonce, as described in Section 10, for RLOC reachability. Instead, they MUST rely solely on control plane methods.
* セクション10で説明されているように、RLOCの到達可能性については、ロケーターステータスビットとエコーノンスを使用しないでください。代わりに、制御プレーンの方法だけに依存する必要があります。
* MUST NOT use gleaning or Locator-Status-Bits and Map-Versioning, as described in Section 13, to update the EID-to-RLOC mappings. Instead, they MUST rely solely on control plane methods.
* セクション13で説明されているように、GleaningまたはLocator-Statusビットとマップバージョンを使用して、Eid-to-RLOCマッピングを更新してはなりません。代わりに、制御プレーンの方法だけに依存する必要があります。
This section provides an example of the unicast packet flow, also including control plane information as specified in [RFC9301]. The example also assumes the following conditions:
このセクションでは、[RFC9301]で指定されている制御プレーン情報も含め、ユニキャストパケットフローの例を示します。この例では、次の条件も想定しています。
* Source host "host1.abc.example.com" is sending a packet to "host2.xyz.example.com", exactly as it would if the site was not using LISP.
* ソースホスト「host1.abc.example.com」は、サイトがLISPを使用していない場合とまったく同じ「host2.xyz.example.com」にパケットを送信しています。
* Each site is multihomed, so each Tunnel Router has an address (RLOC) assigned from the service provider address block for each provider to which that particular Tunnel Router is attached.
* 各サイトはマルチホームであるため、各トンネルルーターには、特定のトンネルルーターが取り付けられている各プロバイダーのサービスプロバイダーアドレスブロックから割り当てられたアドレス（RLOC）があります。
* The ITR(s) and ETR(s) are directly connected to the source and destination, respectively, but the source and destination can be located anywhere in the LISP site.
* ITR（S）とETRはそれぞれソースと宛先に直接接続されていますが、ソースと宛先はLISPサイトのどこにでも配置できます。
* A Map-Request is sent for an external destination when the destination is not found in the forwarding table or matches a default route. Map-Requests are sent to the mapping database system by using the LISP control plane protocol documented in [RFC9301].
* 宛先が転送テーブルに見つからない場合、またはデフォルトのルートと一致する場合、外部宛先のためにマップリクエストが送信されます。[RFC9301]でドキュメントされたLISPコントロールプレーンプロトコルを使用して、マップリケストはマッピングデータベースシステムに送信されます。
* Map-Replies are sent on the underlying routing system topology, using the control plane protocol [RFC9301].
* マップレプリーは、コントロールプレーンプロトコル[RFC9301]を使用して、基礎となるルーティングシステムトポロジに送信されます。
Client host1.abc.example.com wants to communicate with server host2.xyz.example.com:
クライアントhost1.abc.example.comは、サーバーhost2.xyz.example.comと通信したいと考えています。
1. host1.abc.example.com wants to open a TCP connection to host2.xyz.example.com. It does a DNS lookup on host2.xyz.example.com. An A/AAAA record is returned. This address is the destination EID. The locally assigned address of host1.abc.example.com is used as the source EID. An IPv4 or IPv6 packet is built and forwarded through the LISP site as a normal IP packet until it reaches a LISP ITR.
1. host1.abc.example.comは、host2.xyz.example.comへのTCP接続を開きたいと考えています。host2.xyz.example.comでDNS検索を行います。A/AAAAレコードが返されます。このアドレスは宛先EIDです。host1.abc.example.comのローカルに割り当てられたアドレスは、ソースEIDとして使用されます。IPv4またはIPv6パケットは、LISP ITRに達するまで、通常のIPパケットとしてLISPサイトを介して構築および転送されます。
2. The LISP ITR must be able to map the destination EID to an RLOC of one of the ETRs at the destination site. A method for doing this is to send a LISP Map-Request, as specified in [RFC9301].
2. LISP ITRは、宛先EIDを宛先サイトのETRの1つのRLOCにマッピングできる必要があります。これを行う方法は、[RFC9301]で指定されているように、LISP Map-Requestを送信することです。
3. The Mapping System helps forward the Map-Request to the corresponding ETR. When the Map-Request arrives at one of the ETRs at the destination site, it will process the packet as a control message.
3. マッピングシステムは、MAP-Requestを対応するETRに転送するのに役立ちます。Map-Requestが宛先サイトのETRの1つに到着すると、パケットをコントロールメッセージとして処理します。
4. The ETR looks at the destination EID of the Map-Request and matches it against the prefixes in the ETR's configured EID-to-RLOC mapping database. This is the list of EID-Prefixes the ETR is supporting for the site it resides in. If there is no match, the Map-Request is dropped. Otherwise, a LISP Map-Reply is returned to the ITR.
4. ETRは、Map-Requestの宛先Eidを調べ、ETRの構成されたEid-to-RLOCマッピングデータベースのプレフィックスと一致します。これは、ETRが存在するサイトをサポートしているEID-Prefixesのリストです。一致しない場合、Map-Requestが削除されます。それ以外の場合は、LISPマップの繰り返しがITRに返されます。
5. The ITR receives the Map-Reply message, parses the message, and stores the mapping information from the packet. This information is stored in the ITR's EID-to-RLOC Map-Cache. Note that the Map-Cache is an on-demand cache. An ITR will manage its Map-Cache in such a way that optimizes for its resource constraints.
5. ITRは、マップ対応メッセージを受信し、メッセージを解析し、マッピング情報をパケットから保存します。この情報は、ITRのEid-to-RLOCマップキャッシュに保存されています。マップキャッシュはオンデマンドキャッシュであることに注意してください。ITRは、リソースの制約を最適化するようにマップキャッシュを管理します。
6. Subsequent packets from host1.abc.example.com to host2.xyz.example.com will have a LISP header prepended by the ITR using the appropriate RLOC as the LISP header destination address learned from the ETR. Note that the packet MAY be sent to a different ETR than the one that returned the Map-Reply due to the source site's hashing policy or the destination site's Locator-Set policy.
6. Host1.abc.example.comからHost2.xyz.example.comへの後続のパケットには、ETRから学習したLISPヘッダー宛先のアドレスとして適切なRLOCを使用して、ITRがLISPヘッダーを準備します。パケットは、ソースサイトのハッシュポリシーまたは宛先サイトのロケーターセットポリシーのために、マップ応答を返したものとは異なるETRに送信される場合があることに注意してください。
7. The ETR receives these packets directly (since the destination address is one of its assigned IP addresses), checks the validity of the addresses, strips the LISP header, and forwards packets to the attached destination host.
7. ETRはこれらのパケットを直接受信し（宛先アドレスは割り当てられたIPアドレスの1つであるため）、アドレスの有効性をチェックし、LISPヘッダーをストリップし、接続された宛先ホストにパケットを転送します。
8. In order to defer the need for a mapping lookup in the reverse direction, it is OPTIONAL for an ETR to create a cache entry that maps the source EID (inner-header source IP address) to the source RLOC (outer-header source IP address) in a received LISP packet. Such a cache entry is termed a "glean mapping" and only contains a single RLOC for the EID in question. More complete information about additional RLOCs SHOULD be verified by sending a LISP Map-Request for that EID. Both the ITR and the ETR MAY also influence the decision the other makes in selecting an RLOC.
8. 逆方向のマッピングルックアップの必要性を延期するために、ETRがソースEID（インナーヘッダーソースIPアドレス）をソースRLOC（アウターヘッダーソースIPアドレスにマッピングするキャッシュエントリを作成することがオプションです。）受信したLISPパケット。このようなキャッシュエントリは「グリーンマッピング」と呼ばれ、問題のEIDには単一のRLOCのみが含まれています。追加のRLOCに関するより完全な情報は、そのEIDにLISPマップリケストを送信して検証する必要があります。ITRとETRの両方が、RLOCを選択する際に他の決定に与える決定にも影響を与える可能性があります。
Since additional tunnel headers are prepended, the packet becomes larger and can exceed the MTU of any link traversed from the ITR to the ETR. It is RECOMMENDED in IPv4 that packets do not get fragmented as they are encapsulated by the ITR. Instead, the packet is dropped and an ICMPv4 Unreachable / Fragmentation Needed message is returned to the source.
追加のトンネルヘッダーが準備されているため、パケットが大きくなり、ITRからETRに移動したリンクのMTUを超える可能性があります。IPv4では、ITRによってカプセル化されているため、パケットが断片化されないことが推奨されます。代わりに、パケットがドロップされ、ICMPV4の到達不可能 /断片化が必要なメッセージがソースに返されます。
In the case when fragmentation is needed, it is RECOMMENDED that implementations provide support for one of the proposed fragmentation and reassembly schemes. Two existing schemes are detailed in Section 7.
断片化が必要な場合、実装は提案された断片化と再組み立てスキームの1つをサポートすることをお勧めします。2つの既存のスキームについては、セクション7で詳しく説明しています。
Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner header is in IPv4 packet format and the outer header is in IPv6 packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header is in IPv6 packet format and the outer header is in IPv4 packet format). The next sub-sections illustrate packet formats for the homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4 combinations MUST be supported. Additional types of EIDs are defined in [RFC8060].
IPv4またはIPv6アドレスはEIDSまたはRLOCのいずれかである可能性があるため、LISPアーキテクチャはIPv6 RLOC（内側ヘッダーがIPv4パケット形式であり、外側ヘッダーがIPv6パケット形式である）またはIPv4 RLOCSを持つIPv6 EID（ここで、IPv6パケット形式）を持つIPv4 Eidsをサポートします。インナーヘッダーはIPv6パケット形式で、外側ヘッダーはIPv4パケット形式です）。次のサブセクションは、均一なケース（IPv4-in-IPV4およびIPv6-in-IPV6）のパケット形式を示していますが、4つの組み合わせはすべてサポートする必要があります。追加のタイプのEIDは[RFC8060]で定義されています。
As LISP uses UDP encapsulation to carry traffic between xTRs across the Internet, implementors should be aware of the provisions of [RFC8085], especially those given in its Section 3.1.11 on congestion control for UDP tunneling.
LISPはUDPカプセル化を使用してインターネット上のXTR間のトラフィックを運ぶため、実装者は[RFC8085]の規定、特にUDPトンネルの混雑制御に関するセクション3.1.11に記載されている規定に注意する必要があります。
Implementors are encouraged to consider UDP checksum usage guidelines in Section 3.4 of [RFC8085] when it is desirable to protect UDP and LISP headers against corruption.
実装者は、腐敗からUDPおよびLISPヘッダーを保護することが望ましい場合、[RFC8085]のセクション3.4のUDPチェックサムの使用ガイドラインを考慮することをお勧めします。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| IHL | DSCP |ECN| Total Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identification |Flags| Fragment Offset |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OH | Time to Live | Protocol = 17 | Header Checksum |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source Routing Locator |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Destination Routing Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4341 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L |N|L|E|V|I|R|K|K| Nonce/Map-Version |
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | Instance ID/Locator-Status-Bits |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| IHL | DSCP |ECN| Total Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identification |Flags| Fragment Offset |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IH | Time to Live | Protocol | Header Checksum |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source EID |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Destination EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IHL = IP-Header-Length
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| DSCP |ECN| Flow Label |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Payload Length | Next Header=17| Hop Limit |
v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
O + +
u | |
t + Source Routing Locator +
e | |
r + +
| |
H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
d | |
r + +
| |
^ + Destination Routing Locator +
| | |
\ + +
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4341 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L |N|L|E|V|I|R|K|K| Nonce/Map-Version |
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | Instance ID/Locator-Status-Bits |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| DSCP |ECN| Flow Label |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Payload Length | Next Header | Hop Limit |
v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
I + +
n | |
n + Source EID +
e | |
r + +
| |
H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
d | |
r + +
| |
^ + Destination EID +
\ | |
\ + +
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inner Header (IH): The inner header is the header on the datagram received from the originating host [RFC0791] [RFC8200] [RFC2474]. The source and destination IP addresses are EIDs.
インナーヘッダー（IH）：インナーヘッダーは、発信元ホスト[RFC0791] [RFC8200] [RFC2474]から受信したデータグラムのヘッダーです。ソースと宛先のIPアドレスはEidsです。
Outer Header (OH): The outer header is a new header prepended by an ITR. The address fields contain RLOCs obtained from the ingress router's EID-to-RLOC Map-Cache. The IP protocol number is "UDP (17)" from [RFC0768]. The setting of the Don't Fragment (DF) bit 'Flags' field is according to rules listed in Sections 7.1 and 7.2.
外側のヘッダー（OH）：外側のヘッダーは、ITRによって準備された新しいヘッダーです。アドレスフィールドには、IngressルーターのEid-to-RLOCマップキャッシュから得られたRLOCが含まれています。IPプロトコル番号は[RFC0768]の「UDP（17）」です。DONT FRAGMENT（DF）ビット「フラグ」フィールドの設定は、セクション7.1および7.2に記載されているルールに従っています。
UDP Header: The UDP header contains an ITR-selected source port when encapsulating a packet. See Section 12 for details on the hash algorithm used to select a source port based on the 5-tuple of the inner header. The destination port MUST be set to the well-known IANA-assigned port value 4341.
UDPヘッダー：UDPヘッダーには、パケットをカプセル化するときにITR選択されたソースポートが含まれています。内側ヘッダーの5タプルに基づいてソースポートを選択するために使用されるハッシュアルゴリズムの詳細については、セクション12を参照してください。宛先ポートは、よく知られているIANAが割り当てられたポート値4341に設定する必要があります。
UDP Checksum: The 'UDP Checksum' field SHOULD be transmitted as zero by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation [RFC6935] [RFC6936]. When a packet with a zero UDP checksum is received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification and the verification fails, the packet MUST be silently dropped. If the ETR either chooses not to perform the verification or performs the verification successfully, the packet MUST be accepted for decapsulation. The handling of UDP zero checksums over IPv6 for all tunneling protocols, including LISP, is subject to the applicability statement in [RFC6936].
UDPチェックサム：「UDPチェックサム」フィールドは、IPv4 [RFC0768]またはIPv6カプセル化[RFC6935] [RFC6936]のいずれかのITRによってゼロとして送信する必要があります。ゼロUDPチェックサムを備えたパケットがETRによって受信される場合、ETRは脱カプセル化のパケットを受け入れる必要があります。ITRがUDPチェックサムのゼロ以外の値を送信する場合、このフィールドで正しく計算された値を送信する必要があります。ETRがゼロ以外のUDPチェックサムを備えたパケットを受信すると、チェックサム値を確認することを選択できます。そのような検証を実行することを選択し、検証が失敗する場合、パケットは静かに削除する必要があります。ETRが検証を実行しないことを選択するか、検証を正常に実行することを選択した場合、脱カプセル化のためにパケットを受け入れる必要があります。LISPを含むすべてのトンネルプロトコルのIPv6を介したUDPゼロチェックサムの処理は、[RFC6936]の適用声明の対象となります。
UDP Length: The 'UDP Length' field is set for an IPv4-encapsulated packet to be the sum of the inner-header IPv4 Total Length plus the UDP and LISP header lengths. For an IPv6-encapsulated packet, the 'UDP Length' field is the sum of the inner-header IPv6 Payload Length, the size of the IPv6 header (40 octets), and the size of the UDP and LISP headers.
UDPの長さ：「UDP長」フィールドは、IPv4でカプセル化されたパケットに設定されており、内部ヘッダーIPv4の合計とUDPおよびLISPヘッダーの長さの合計です。IPv6でカプセル化されたパケットの場合、「UDPの長さ」フィールドは、内部ヘッダーIPv6ペイロード長、IPv6ヘッダーのサイズ（40オクテット）、UDPおよびLISPヘッダーのサイズの合計です。
N: The N-bit is the nonce-present bit. When this bit is set to 1, the low-order 24 bits of the first 32 bits of the LISP header contain a nonce. See Section 10.1 for details. Both N- and V-bits MUST NOT be set in the same packet. If they are, a decapsulating ETR MUST treat the 'Nonce/Map-Version' field as having a nonce value present.
n：n-bitは非存在のビットです。このビットが1に設定されている場合、LISPヘッダーの最初の32ビットの低次の24ビットにはnonceが含まれています。詳細については、セクション10.1を参照してください。NビットとVビットの両方を同じパケットに設定してはなりません。もしそうなら、脱カプセンシングETRは、「ノンセ/マップバージョン」フィールドを非CE値が存在するものとして扱う必要があります。
L: The L-bit is the 'Locator-Status-Bits' field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32 bits of the LISP header are in use.
L：Lビットは、「ロケーターステータスビット」フィールドが有効になっているビットです。このビットが1に設定されると、LISPヘッダーの2番目の32ビットのロケーターステータスビットが使用されています。
x 1 x x 0 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|R|K|K| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E: The E-bit is the Echo-Nonce-request bit. This bit MUST be ignored and has no meaning when the N-bit is set to 0. When the N-bit is set to 1 and this bit is set to 1, an ITR is requesting that the nonce value in the 'Nonce' field be echoed back in LISP-encapsulated packets when the ITR is also an ETR. See Section 10.1 for details.
E：eビットはエコーノンセレクエストビットです。このビットは無視する必要があり、nビットが0に設定されている場合、意味はありません。n-bitが1に設定され、このビットが1に設定されている場合、ITRは「nonce」フィールドの非CE値を要求しています。ITRもETRである場合、リスプカプセル化されたパケットに反映されます。詳細については、セクション10.1を参照してください。
V: The V-bit is the Map-Version present bit. When this bit is set to 1, the N-bit MUST be 0. Refer to [RFC9302] for more details on Database Map-Versioning. This bit indicates that the LISP header is encoded in this case as:
V：Vビットは、マップバージョンの存在ビットです。このビットが1に設定されている場合、N-BITは0でなければなりません。データベースマップバージョンの詳細については、[RFC9302]を参照してください。このビットは、この場合、LISPヘッダーが次のようにエンコードされていることを示しています。
0 x 0 1 x x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|R|K|K| Source Map-Version | Dest Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID/Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I: The I-bit is the Instance ID bit. See Section 8 for more details. When this bit is set to 1, the 'Locator-Status-Bits' field is reduced to 8 bits and the high-order 24 bits are used as an Instance ID. If the L-bit is set to 0, then the low-order 8 bits are transmitted as zero and ignored on receipt. The format of the LISP header would look like this:
I：iビットはインスタンスIDビットです。詳細については、セクション8を参照してください。このビットが1に設定されると、「ロケーターステータスビット」フィールドが8ビットに縮小され、高次の24ビットがインスタンスIDとして使用されます。Lビットが0に設定されている場合、低次の8ビットはゼロとして送信され、受領時に無視されます。LISPヘッダーの形式は次のようになります。
x x x x 1 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|R|K|K| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID | LSBs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R: The R-bit is a reserved and unassigned bit for future use. It MUST be set to 0 on transmit and MUST be ignored on receipt.
R：Rビットは、将来の使用のために予約済みで割り当てられていないビットです。送信時に0に設定する必要があり、受領時に無視する必要があります。
KK: The KK-bits are a 2-bit field used when encapsulated packets are encrypted. The field is set to 00 when the packet is not encrypted. See [RFC8061] for further information.
KK：KKビットは、カプセル化されたパケットが暗号化されたときに使用される2ビットフィールドです。パケットが暗号化されていない場合、フィールドは00に設定されます。詳細については、[RFC8061]を参照してください。
LISP Nonce: The LISP 'Nonce' field is a 24-bit value that is randomly generated by an ITR when the N-bit is set to 1. Nonce generation algorithms are an implementation matter but are required to generate different nonces when sending to different RLOCs. The nonce is also used when the E-bit is set to request the nonce value to be echoed by the other side when packets are returned. When the E-bit is clear but the N-bit is set, a remote ITR is either echoing a previously requested Echo-Nonce or providing a random nonce. See Section 10.1 for more details. Finally, when both the N- and V-bits are not set (N=0, V=0), then both the 'Nonce' and 'Map-Version' fields are set to 0 and ignored on receipt.
LISP nonce：lisp 'nonce'フィールドは、n-bitが1に設定されているときにITRによってランダムに生成される24ビット値です。非ce生成アルゴリズムは実装の問題ですが、異なる非seを生成するには異なる非seを生成する必要があります。rlocs。ebitが設定されている場合には、パケットが返されると、ebitがノンセ値を反対側でエコーするように設定するように設定されている場合にも使用されます。eビットが明確であるがnビットが設定されている場合、リモートITRは、以前に要求されたエコーノンセをエコーするか、ランダムなnonceを提供します。詳細については、セクション10.1を参照してください。最後に、nビットとvビットの両方が設定されていない場合（n = 0、v = 0）、「nonce」と「map-version」フィールドの両方が0に設定され、受信時に無視されます。
LISP Locator-Status-Bits (LSBs): When the L-bit is also set, the 'Locator-Status-Bits' field in the LISP header is set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator-Status-Bits are numbered from 0 to n-1 from the least significant bit of the field. The field is 32 bits when the I-bit is set to 0 and is 8 bits when the I-bit is set to 1. When a Locator-Status-Bit is set to 1, the ITR is indicating to the ETR that the RLOC associated with the bit ordinal has up status. See Section 10 for details on how an ITR can determine the status of the ETRs at the same site. When a site has multiple EID-Prefixes that result in multiple mappings (where each could have a different Locator-Set), the Locator-Status-Bits setting in an encapsulated packet MUST reflect the mapping for the EID-Prefix that the inner-header source EID address matches (longest-match). If the LSB for an anycast Locator is set to 1, then there is at least one RLOC with that address, and the ETR is considered 'up'.
LISP Locator-Status-Bits（LSBS）：Lビットも設定されている場合、LISPヘッダーの「ロケーターステータスビット」フィールドはITRによって設定され、LocatorsのUp/Downステータスを示します。ソースサイトで。 MAP-REPLYの各RLOCには、0からN-1の順序値が割り当てられます（マッピングエントリにn rlocがある場合）。ロケーターステータスビットには、フィールドの最も有意なビットから0からn-1の番号が付けられています。 iビットが0に設定されている場合、フィールドは32ビットで、iビットが1に設定されている場合は8ビットです。ロケーター-Statusビットが1に設定されている場合、ITRはRLOCであることをETRに示しています。ビット序数に関連付けられているのは、ステータスがアップしています。 ITRが同じサイトでETRのステータスを決定する方法の詳細については、セクション10を参照してください。サイトに複数のEID-PREFIXSがある場合、複数のマッピング（それぞれに異なるロケーターセットがある可能性がある場合）を作成する場合、カプセル化されたパケットのロケーター-STATUSビット設定は、内側のヘッダーであるEID-Prefixのマッピングを反映する必要があります。ソースEIDアドレスマッチ（最長試合）。 AnycastロケーターのLSBが1に設定されている場合、そのアドレスには少なくとも1つのRLOCがあり、ETRは「UP」と見なされます。
When doing ITR/PITR encapsulation:
ITR/PITRカプセル化を行うとき：
* The outer-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the inner-header 'Time to Live' field.
* アウターヘッドの「ライブ」フィールド（またはIPv6の場合は「ホップ制限」フィールド）は、内部ヘッダー「ライブ」フィールドからコピーする必要があります。
* The outer-header IPv4 'Differentiated Services Code Point (DSCP)' field (or 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the inner-header IPv4 'DSCP' field (or 'Traffic Class' field, in the case of IPv6) to the outer header. Guidelines for this can be found in [RFC2983].
* アウターヘッドIPv4 '差別化されたサービスコードポイント（DSCP）'フィールド（またはIPv6の場合は「トラフィッククラス」フィールド）は、内部ヘッダーIPv4 'DSCP'フィールド（または「トラフィッククラス」フィールドからコピーする必要があります。IPv6の場合）外側ヘッダーへ。これのガイドラインは[RFC2983]に記載されています。
* The IPv4 'Explicit Congestion Notification (ECN)' field and bits 6 and 7 of the IPv6 'Traffic Class' field require special treatment in order to avoid discarding indications of congestion as specified in [RFC6040].
* [RFC6040]で指定されているように、輻輳の兆候を破棄することを避けるために、IPv6 'トラフィッククラス'フィールドのIPv4 '明示的な混雑通知（ECN）'フィールドとビット6および7は、特別な処理を必要とします。
When doing ETR/PETR decapsulation:
ETR/PETR脱カプセル化を行うとき：
* The inner-header IPv4 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) MUST be copied from the outer-header 'Time to Live'/'Hop Limit' field when the Time to Live / Hop Limit value of the outer header is less than the Time to Live / Hop Limit value of the inner header. Failing to perform this check can cause the Time to Live / Hop Limit of the inner header to increment across encapsulation/decapsulation cycles. This check is also performed when doing initial encapsulation, when a packet comes to an ITR or PITR destined for a LISP site.
* 内部ヘッダーIPv4「ライブの時間」フィールド（またはIPv6の場合は「ホップリミット」フィールド）は、アウターヘッダーの「ライブ」 /「ホップリミット」フィールドからコピーする必要があります /ライブ /「ホップ制限」フィールド /外側ヘッダーのホップ制限値は、内側ヘッダーのライブ /ホップ制限値値までの時間よりも短いです。このチェックを実行しないと、内側ヘッダーのライブ /ホップ制限がカプセル化 /脱カプセル化サイクル全体で増加する可能性があります。このチェックは、最初のカプセル化を行うときにも実行されます。パケットがLISPサイトに宛てられているITRまたはPITRに届くときに実行されます。
* The outer-header IPv4 'Differentiated Services Code Point (DSCP)' field (or 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the outer-header 'IPv4 DSCP' field (or 'Traffic Class' field, in the case of IPv6) to the inner header. Guidelines for this can be found in [RFC2983].
* アウターヘッドIPv4 '差別化されたサービスコードポイント（DSCP）'フィールド（またはIPv6の場合は「トラフィッククラス」フィールド）は、アウターヘッダー「IPv4 DSCP」フィールド（または「トラフィッククラス」フィールド（または「トラフィッククラス」フィールド）からコピーする必要があります。IPv6の場合）内側ヘッダーへ。これのガイドラインは[RFC2983]に記載されています。
* The IPv4 'Explicit Congestion Notification (ECN)' field and bits 6 and 7 of the IPv6 'Traffic Class' field require special treatment in order to avoid discarding indications of congestion as specified in [RFC6040]. Note that implementations exist that copy the 'ECN' field from the outer header to the inner header, even though [RFC6040] does not recommend this behavior. It is RECOMMENDED that implementations change to support the behavior discussed in [RFC6040].
* [RFC6040]で指定されているように、輻輳の兆候を破棄することを避けるために、IPv6 'トラフィッククラス'フィールドのIPv4 '明示的な混雑通知（ECN）'フィールドとビット6および7は、特別な処理を必要とします。[RFC6040]はこの動作を推奨していない場合でも、「ECN」フィールドを外側ヘッダーから内側のヘッダーにコピーする実装が存在することに注意してください。[RFC6040]で議論された動作をサポートするために、実装を変更することをお勧めします。
Note that if an ETR/PETR is also an ITR/PITR and chooses to re-encapsulate after decapsulating, the net effect of this is that the new outer header will carry the same Time to Live as the old outer header minus 1.
ETR/PETRもITR/PITRでもある場合、脱カプセンシング後に再エンカプセル化することを選択した場合、これの正味の効果は、新しい外側ヘッダーが古い外側ヘッダーマイナス1と同じ時間を運ぶことであることに注意してください。
Copying the Time to Live serves two purposes: first, it preserves the distance the host intended the packet to travel; second, and more importantly, it provides for suppression of looping packets in the event there is a loop of concatenated tunnels due to misconfiguration.
The Time To Liveのコピーは2つの目的を果たします。まず、ホストがパケットを移動することを意図した距離を保持します。第二に、そしてさらに重要なことに、それは、誤った構成のために連結されたトンネルのループがある場合にループパケットの抑制を提供します。
Some xTRs, PETRs, and PITRs perform re-encapsulation operations and need to treat ECN functions in a special way. Because the re-encapsulation operation is a sequence of two operations, namely a decapsulation followed by an encapsulation, the ECN bits MUST be treated as described above for these two operations.
一部のXTR、PETR、およびPITRSは、再エンカプセル化操作を実行し、ECN機能を特別な方法で扱う必要があります。再カプセル化操作は2つの操作のシーケンスであるため、つまり、カプセル化に続くカプセル化が続くため、ECNビットは、これら2つの操作について上記のように扱う必要があります。
The LISP data plane protocol is not backwards compatible with [RFC6830] and does not have explicit support for introducing future protocol changes (e.g., an explicit version field). However, the LISP control plane [RFC9301] allows an ETR to register data plane capabilities by means of new LISP Canonical Address Format (LCAF) types [RFC8060]. In this way, an ITR can be made aware of the data plane capabilities of an ETR and encapsulate accordingly. The specification of the new LCAF types, the new LCAF mechanisms, and their use are out of the scope of this document.
LISPデータプレーンプロトコルは、[RFC6830]との逆方向に互換性がなく、将来のプロトコルの変更を導入するための明示的なサポートがありません（例：明示的なバージョンフィールド）。ただし、LISPコントロールプレーン[RFC9301]により、ETRは新しいLISP Canonicalアドレス形式（LCAF）タイプ[RFC8060]を使用してデータプレーン機能を登録できます。このようにして、ITRはETRのデータプレーン機能を認識し、それに応じてカプセル化することができます。新しいLCAFタイプの仕様、新しいLCAFメカニズム、およびそれらの使用は、このドキュメントの範囲外です。
ITRs and PITRs maintain an on-demand cache, referred to as the LISP EID-to-RLOC Map-Cache, that contains mappings from EID-Prefixes to Locator-Sets. The cache is used to encapsulate packets from the EID space to the corresponding RLOC network attachment point.
ITRとPITRは、EID-PREFIXSからロケーターセットまでのマッピングを含むLISP EID-to-RLOCマップキャッシュと呼ばれるオンデマンドキャッシュを維持しています。キャッシュは、EIDスペースから対応するRLOCネットワークアタッチメントポイントまでのパケットをカプセル化するために使用されます。
When an ITR/PITR receives a packet from inside of the LISP site to destinations outside of the site, a longest-prefix match lookup of the EID is done to the Map-Cache.
ITR/PITRがLISPサイトの内部からサイトの外側の目的地までパケットを受け取ると、EIDの最も長いプレフィックスの一致ルックアップがマップキャッシュに対して行われます。
When the lookup succeeds, the Locator-Set retrieved from the Map-Cache is used to send the packet to the EID's topological location.
ルックアップが成功すると、マップキャッシュから取得されたロケーターセットを使用して、パケットをEidのトポロジカル位置に送信します。
If the lookup fails, the ITR/PITR needs to retrieve the mapping using the LISP control plane protocol [RFC9301]. While the mapping is being retrieved, the ITR/PITR can either drop or buffer the packets. This document does not have specific recommendations about the action to be taken. It is up to the deployer to consider whether or not it is desirable to buffer packets and deploy a LISP implementation that offers the desired behavior. Once the mapping is resolved, it is then stored in the local Map-Cache to forward subsequent packets addressed to the same EID-Prefix.
ルックアップが失敗した場合、ITR/PITRは、LISPコントロールプレーンプロトコル[RFC9301]を使用してマッピングを取得する必要があります。マッピングが取得されている間、ITR/PITRはパケットをドロップまたはバッファすることができます。このドキュメントには、実行するアクションに関する具体的な推奨事項はありません。展開者は、パケットをバッファすることが望ましいかどうかを検討し、望ましい動作を提供するLISP実装を展開することが望ましいかどうかを検討することです。マッピングが解決されると、ローカルマップキャッシュに保存され、同じEid-Prefixにアドレス指定された後続のパケットを転送します。
The Map-Cache is a local cache of mappings; entries are expired based on the associated Time to Live. In addition, entries can be updated with more current information; see Section 13 for further information on this. Finally, the Map-Cache also contains reachability information about EIDs and RLOCs and uses LISP reachability information mechanisms to determine the reachability of RLOCs; see Section 10 for the specific mechanisms.
マップキャッシュは、マッピングのローカルキャッシュです。エントリは、関連する時間に基づいて期限切れになります。さらに、より多くの現在の情報でエントリを更新できます。これの詳細については、セクション13を参照してください。最後に、マップキャッシュには、EIDとRLOCに関する到達可能性情報も含まれており、rlocsの到達可能性を決定するためにLISP Reachability情報メカニズムを使用します。特定のメカニズムについては、セクション10を参照してください。
This section proposes two mechanisms to deal with packets that exceed the Path MTU (PMTU) between the ITR and ETR.
このセクションでは、ITRとETRの間のパスMTU（PMTU）を超えるパケットを処理する2つのメカニズムを提案します。
It is left to the implementor to decide if the stateless or stateful mechanism SHOULD be implemented. Both or neither can be used, since it is a local decision in the ITR regarding how to deal with MTU issues, and sites can interoperate with differing mechanisms.
ステートレスまたはステートフルなメカニズムを実装すべきかどうかを決定するのは、実装者に任されています。MTUの問題に対処する方法に関するITRのローカルな決定であり、サイトは異なるメカニズムと相互運用できるため、両方を使用することもできません。
Both stateless and stateful mechanisms also apply to Re-encapsulating and Recursive Tunneling, so any actions below referring to an ITR also apply to a TE-ITR.
StatelessとStatefulの両方のメカニズムは、再エンコーシングと再帰トンネリングにも適用されるため、ITRを参照する以下のアクションはTE-ITRにも適用されます。
An ITR stateless solution to handle MTU issues is described as follows:
MTUの問題を処理するためのITRステートレスソリューションは、次のように説明されています。
1. Define H to be the size, in octets, of the outer header an ITR prepends to a packet. This includes the UDP and LISP header lengths.
1. hをオクテットのサイズであると定義します。外側ヘッダーのITRはパケットにプリプエンドします。これには、UDPおよびLISPヘッダーの長さが含まれます。
2. Define L to be the size, in octets, of the maximum-sized packet an ITR can send to an ETR without the need for the ITR or any intermediate routers to fragment the packet. The network administrator of the LISP deployment has to determine what the suitable value of L is, so as to make sure that no MTU issues arise.
2. lをオクテット内のサイズである最大サイズのパケットのサイズと定義します。ITRは、ITRまたは中間ルーターがパケットを断片化する必要なくETRに送信できます。LISP展開のネットワーク管理者は、MTUの問題が発生しないことを確認するために、Lの適切な値が何であるかを決定する必要があります。
3. Define an architectural constant S for the maximum size of a packet, in octets, an ITR MUST receive from the source so the effective MTU can be met. That is, L = S + H.
3. パケットの最大サイズのアーキテクチャ定数sを定義します。オクテットでは、ITRがソースから受信する必要があり、効果的なMTUを満たすことができます。つまり、L = SH。
When an ITR receives a packet from a site-facing interface and adds H octets worth of encapsulation to yield a packet size greater than L octets (meaning the received packet size was greater than S octets from the source), it resolves the MTU issue by first splitting the original packet into 2 equal-sized fragments. A LISP header is then prepended to each fragment. The size of the encapsulated fragments is then (S/2 + H), which is less than the ITR's estimate of the PMTU between the ITR and its correspondent ETR.
ITRがサイト向けインターフェイスからパケットを受信し、Hオクテット相当のカプセル化を追加して、Lオクテットより大きいパケットサイズを生成すると（受信したパケットサイズはソースからSオクテットよりも大きいことを意味します）、MTUの問題を解決します。最初に元のパケットを2つの等サイズのフラグメントに分割します。次に、リスプヘッダーが各フラグメントに加えられます。カプセル化されたフラグメントのサイズは（S/2 h）であり、これはITRとその特派員ETRの間のPMTUのITRの推定よりも少ないです。
When an ETR receives encapsulated fragments, it treats them as two individually encapsulated packets. It strips the LISP headers and then forwards each fragment to the destination host of the destination site. The two fragments are reassembled at the destination host into the single IP datagram that was originated by the source host. Note that reassembly can happen at the ETR if the encapsulated packet was fragmented at or after the ITR.
ETRがカプセル化されたフラグメントを受信すると、それらを2つの個別にカプセル化されたパケットとして扱います。LISPヘッダーをストリップし、各フラグメントを宛先サイトの宛先ホストに転送します。2つのフラグメントは、宛先ホストでソースホストによって発信された単一のIPデータグラムに再組み立てされています。カプセル化されたパケットがITRまたは後に断片化された場合、ETRで再組み立てが発生する可能性があることに注意してください。
This behavior MUST be implemented by the ITR only when the source host originates a packet with the 'DF' field of the IP header set to 0. When the 'DF' field of the IP header is set to 1 or the packet is an IPv6 packet originated by the source host, the ITR will drop the packet when the size (adding in the size of the encapsulation header) is greater than L and send an ICMPv4 Unreachable / Fragmentation Needed or ICMPv6 Packet Too Big (PTB) message to the source with a value of S, where S is (L - H).
この動作は、IPヘッダーの「DF」フィールドが0に設定されたパケットを発信する場合にのみ、ITRによって実装する必要があります。IPヘッダーの「DF」フィールドが1に設定されている場合、またはパケットがIPv6である場合ソースホストが発信するパケットは、ITRがサイズ（カプセル化ヘッダーのサイズを追加）がLより大きくなるとパケットをドロップし、ICMP4の到達不可能 /断片化が必要 / ICMPv6パケットが大きすぎる（PTB）メッセージを送信します。sの値で、ここでsは（l -h）です。
When the outer-header encapsulation uses an IPv4 header, an implementation SHOULD set the DF bit to 1 so ETR fragment reassembly can be avoided. An implementation MAY set the DF bit in such headers to 0 if it has good reason to believe there are unresolvable PMTU issues between the sending ITR and the receiving ETR.
アウターヘッドのカプセル化がIPv4ヘッダーを使用する場合、実装はDFビットを1に設定する必要があるため、ETRフラグメントの再組み立ては回避できます。実装は、送信ITRと受信ETRの間に解決できないPMTUの問題があると信じる正当な理由がある場合、そのようなヘッダーのDFビットを0に設定する場合があります。
It is RECOMMENDED that L be defined as 1500. Additional information about in-network MTU and fragmentation issues can be found in [RFC4459].
Lを1500として定義することをお勧めします。ネットワーク内のMTUおよび断片化の問題に関する追加情報は、[RFC4459]に記載されています。
An ITR stateful solution to handle MTU issues is described as follows:
MTUの問題を処理するITRステートフルなソリューションは、次のように説明されています。
1. The ITR will keep state of the effective MTU for each Locator per Map-Cache entry. The effective MTU is what the core network can deliver along the path between the ITR and ETR.
1. ITRは、マップキャッシュエントリごとに各ロケーターの有効なMTUの状態を保持します。効果的なMTUは、コアネットワークがITRとETRの間のパスに沿って配信できるものです。
2. When an IPv4-encapsulated packet with the DF bit set to 1 exceeds what the core network can deliver, one of the intermediate routers on the path will send an ICMPv4 Unreachable / Fragmentation Needed message to the ITR. The ITR will parse the ICMP message to determine which Locator is affected by the effective MTU change and then record the new effective MTU value in the Map-Cache entry.
2. DFビットが1に設定されたIPv4エンコープフォルドパケットがコアネットワークが提供できるものを超えると、パス上の中間ルーターの1つがITRにICMPV4の到達可能 /断片化に必要なメッセージを送信します。ITRは、ICMPメッセージを解析して、有効なMTU変更の影響を受けるロケーターを決定し、マップキャッシュエントリに新しい有効なMTU値を記録します。
3. When a packet is received by the ITR from a source inside of the site and the size of the packet is greater than the effective MTU stored with the Map-Cache entry associated with the destination EID the packet is for, the ITR will send an ICMPv4 Unreachable / Fragmentation Needed message back to the source. The packet size advertised by the ITR in the ICMP message is the effective MTU minus the LISP encapsulation length.
3. パケットがサイト内のソースからITRによって受信され、パケットのサイズがパケットの宛先EIDに関連付けられたマップキャッシュエントリに保存されている有効なMTUよりも大きい場合、ITRはICMPv4を送信します到達不可能 /断片化には、ソースにメッセージが必要でした。ICMPメッセージでITRによって宣伝されているパケットサイズは、LISPカプセル化の長さを差し引いた有効なMTUからです。
Even though this mechanism is stateful, it has advantages over the stateless IP fragmentation mechanism, by not involving the destination host with reassembly of ITR fragmented packets.
このメカニズムはステートフルですが、ITR断片化されたパケットの再組み立てを宛先ホストに関与しないことにより、ステートレスIP断片化メカニズムよりも利点があります。
Please note that using ICMP packets for PMTU discovery, as described in [RFC1191] and [RFC8201], can result in suboptimal behavior in the presence of ICMP packet losses or off-path attackers that spoof ICMP. Possible mitigations include ITRs and ETRs cooperating on MTU probe packets [RFC4821] [RFC8899] or ITRs storing the beginning of large packets to verify that they match the echoed packet in an ICMP Fragmentation Needed / PTB message.
[RFC1191]および[RFC8201]に記載されているように、PMTU発見にICMPパケットを使用すると、ICMPパケット損失またはICMPを引き起こすパス攻撃者の存在下で最適でない挙動をもたらす可能性があることに注意してください。可能な緩和には、MTUプローブパケット[RFC4821] [RFC8899]に協力するITRとETRSが含まれます。または、大きなパケットの開始を保存して、ICMPフラグメンテーションが必要な / PTBメッセージでエコーされたパケットと一致することを確認します。
There are several cases where segregation is needed at the EID level. For instance, this is the case for deployments containing overlapping addresses, traffic isolation policies, or multi-tenant virtualization. For these and other scenarios where segregation is needed, Instance IDs are used.
EIDレベルで分離が必要ないくつかのケースがあります。たとえば、これは、オーバーラップアドレス、トラフィック分離ポリシー、またはマルチテナント仮想化を含む展開の場合です。分離が必要なこれらおよびその他のシナリオには、インスタンスIDが使用されます。
An Instance ID can be carried in a LISP-encapsulated packet. An ITR that prepends a LISP header will copy a 24-bit value used by the LISP router to uniquely identify the address space. The value is copied to the 'Instance ID' field of the LISP header, and the I-bit is set to 1.
インスタンスIDは、LISPにカプセル化されたパケットで携帯できます。LISPヘッダーをプリケンドするITRは、LISPルーターが使用する24ビット値をコピーして、アドレススペースを一意に識別します。値は、LISPヘッダーの「インスタンスID」フィールドにコピーされ、iビットは1に設定されます。
When an ETR decapsulates a packet, the Instance ID from the LISP header is used as a table identifier to locate the forwarding table to use for the inner destination EID lookup.
ETRがパケットを脱カプセル化すると、LISPヘッダーからのインスタンスIDがテーブル識別子として使用され、内側の宛先EIDルックアップに使用する転送テーブルを見つけます。
For example, an 802.1Q VLAN tag or VPN identifier could be used as a 24-bit Instance ID. See [LISP-VPN] for details regarding LISP VPN use cases. Please note that the Instance ID is not protected; an on-path attacker can modify the tags and, for instance, allow communications between logically isolated VLANs.
たとえば、802.1Q VLANタグまたはVPN識別子を24ビットインスタンスIDとして使用できます。LISP VPNユースケースに関する詳細については、[LISP-VPN]を参照してください。インスタンスIDは保護されていないことに注意してください。パス上の攻撃者は、タグを変更し、たとえば、論理的に分離されたVLAN間の通信を許可します。
Participants within a LISP deployment must agree on the meaning of Instance ID values. The source and destination EIDs MUST belong to the same Instance ID.
LISP展開内の参加者は、インスタンスID値の意味に同意する必要があります。ソースおよび宛先Eidsは、同じインスタンスIDに属している必要があります。
The Instance ID SHOULD NOT be used with overlapping IPv6 EID addresses.
インスタンスIDは、IPv6 EIDアドレスが重複する際に使用しないでください。
The Map-Cache contains the state used by ITRs and PITRs to encapsulate packets. When an ITR/PITR receives a packet from inside the LISP site to a destination outside of the site, a longest-prefix match lookup of the EID is done to the Map-Cache (see Section 6). The lookup returns a single Locator-Set containing a list of RLOCs corresponding to the EID's topological location. Each RLOC in the Locator-Set is associated with a Priority and Weight; this information is used to select the RLOC to encapsulate.
マップキャッシュには、パケットをカプセル化するためにITRとPITRが使用する状態が含まれています。ITR/PITRがLISPサイト内からサイトの外側の宛先までパケットを受け取ると、EIDの最長の試合検索がマップキャッシュに対して行われます（セクション6を参照）。ルックアップは、EIDのトポロジカル位置に対応するRLOCのリストを含む単一のロケーターセットを返します。ロケーターセットの各RLOCは、優先度と重量に関連付けられています。この情報は、カプセル化するRLOCを選択するために使用されます。
The RLOC with the lowest Priority is selected. An RLOC with Priority 255 means that it MUST NOT be used for forwarding. When multiple RLOCs have the same Priority, then the Weight states how to load-balance traffic among them. The value of the Weight represents the relative weight of the total packets that match the mapping entry.
優先度が最も低いRLOCが選択されています。Priority 255のRLOCは、転送に使用してはならないことを意味します。複数のRLOCが同じ優先順位を持っている場合、重量はそれらの間にトラフィックを積み込む方法を述べます。重みの値は、マッピングエントリと一致する合計パケットの相対重量を表します。
The following are different scenarios for choosing RLOCs and the controls that are available:
以下は、RLOCと利用可能なコントロールを選択するためのさまざまなシナリオです。
* The server-side returns one RLOC. The client-side can only use one RLOC. The server-side has complete control of the selection.
* サーバー側は1つのRLOCを返します。クライアント側は1つのRLOCのみを使用できます。サーバー側は選択を完全に制御します。
* The server-side returns a list of RLOCs where a subset of the list has the same best Priority. The client can only use the subset list according to the weighting assigned by the server-side. In this case, the server-side controls both the subset list and load splitting across its members. The client-side can use RLOCs outside of the subset list if it determines that the subset list is unreachable (unless RLOCs are set to a Priority of 255). Some sharing of control exists: the server-side determines the destination RLOC list and load distribution while the client-side has the option of using alternatives to this list if RLOCs in the list are unreachable.
* サーバー側は、リストのサブセットが同じ最優先事項を持っているRLOCのリストを返します。クライアントは、サーバー側によって割り当てられた重み付けに従ってサブセットリストのみを使用できます。この場合、サーバー側はメンバー間のサブセットリストと負荷分割の両方を制御します。クライアント側は、サブセットリストが到達不能であると判断した場合、サブセットリストの外側のRLOCを使用できます（RLOCが255の優先度に設定されていない限り）。コントロールの共有が存在します。サーバー側は、宛先RLOCリストと負荷分布を決定しますが、クライアント側には、リスト内のRLOCが到達できない場合、このリストの代替案を使用するオプションがあります。
* The server-side sets a Weight of zero for the RLOC subset list. In this case, the client-side can choose how the traffic load is spread across the subset list. See Section 12 for details on load-sharing mechanisms. Control is shared by the server-side determining the list and the client-side determining load distribution. Again, the client can use alternative RLOCs if the server-provided list of RLOCs is unreachable.
* サーバー側は、RLOCサブセットリストにゼロの重みを設定します。この場合、クライアント側は、サブセットリスト全体にトラフィック負荷がどのように広がるかを選択できます。ロードシェアリングメカニズムの詳細については、セクション12を参照してください。コントロールは、リストを決定するサーバー側とクライアント側の決定荷重分布によって共有されます。繰り返しますが、RLOCのサーバーが提供するリストが到達できない場合、クライアントは代替RLOCを使用できます。
* Either side (more likely the server-side ETR) decides to "glean" the RLOCs. For example, if the server-side ETR gleans RLOCs, then the client-side ITR gives the server-side ETR responsibility for bidirectional RLOC reachability and preferability. Server-side ETR gleaning of the client-side ITR RLOC is done by caching the inner-header source EID and the outer-header source RLOC of received packets. The client-side ITR controls how traffic is returned and can, as an alternative, use an outer-header source RLOC, which then can be added to the list the server-side ETR uses to return traffic. Since no Priority or Weights are provided using this method, the server-side ETR MUST assume that each client-side ITR RLOC uses the same best Priority with a Weight of zero. In addition, since EID-Prefix encoding cannot be conveyed in data packets, the EID-to-RLOC Map-Cache on Tunnel Routers can grow very large. Gleaning has several important considerations. A "gleaned" Map-Cache entry is only stored and used for a RECOMMENDED period of 3 seconds, pending verification. Verification MUST be performed by sending a Map-Request to the source EID (the inner-header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the Map-Cache entry for the "gleaned" EID and is stored and used for the time indicated in the 'Time to Live' field of a received Map-Reply. When a verified Map-Cache entry is stored, data gleaning no longer occurs for subsequent packets that have a source EID that matches the EID-Prefix of the verified entry. This "gleaning" mechanism MUST NOT be used over the public Internet and SHOULD only be used in trusted and closed deployments. Refer to Section 16 for security issues regarding this mechanism.
* どちらの側（おそらくサーバー側のETR）がRLOCを「収集」することを決定します。たとえば、サーバー側のETRがRLOCをつかむと、クライアント側のITRは、双方向のRLOCリーチビリティと優先性に対するサーバー側のETRの責任を与えます。クライアント側のサーバー側のETR Gleaningは、Inner-HeaderソースEidと受信したパケットの外部ヘッダーソースRLOCをキャッシュすることにより行われます。クライアント側のITRは、トラフィックの返品方法を制御し、代替として外部ヘッダーソースRLOCを使用することができます。これを使用して、サーバー側のETRが使用してトラフィックを返すことができます。この方法を使用して優先度または重みが提供されていないため、サーバー側のETRは、各クライアント側ITR RLOCがゼロの重量で同じ最優先事項を使用すると想定する必要があります。さらに、Eid-Prefixエンコードはデータパケットで伝達できないため、トンネルルーターのEid-to-RLOCマップキャッシュは非常に大きくなる可能性があります。 Gleaningにはいくつかの重要な考慮事項があります。 「収集された」マップキャッシュエントリは保存され、3秒の推奨期間にのみ使用され、検証が保留されます。受信したカプセル化されたパケットのソースEID（インナーヘッダーIPソースアドレス）にMAP-Requestを送信することにより、検証を実行する必要があります。この「マップリケストの検証」への返信は、「収集された」EIDのマップキャッシュエントリを完全に埋めるために使用され、受信したマップ繰り返しの「生きる時間」フィールドに示されている時間に保存および使用されます。検証済みのマップキャッシュエントリが保存されると、検証済みのエントリのEid-Prefixに一致するソースEIDを持つ後続のパケットに対して、データグリーニングは発生しなくなります。この「グリーニング」メカニズムは、パブリックインターネットで使用されるべきではなく、信頼できる展開および閉鎖展開でのみ使用する必要があります。このメカニズムに関するセキュリティの問題については、セクション16を参照してください。
RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit [RFC9301] for the Locator record is set to 1. When the R-bit is set to 0, an ITR or PITR MUST NOT encapsulate to the RLOC. Neither the information contained in a Map-Reply nor that stored in the mapping database system provides reachability information for RLOCs. Note that reachability is not part of the Mapping System and is determined using one or more of the RLOC reachability algorithms described in the next section.
EID-to-RLOCマップの繰り返しメッセージに表示されるRLOCは、ロケーターレコードのRビット[RFC9301]が1に設定されている場合、RITが0に設定されている場合、ITRまたはPITRが設定されると想定されています。RLOCにカプセル化しないでください。マップ応答に含まれる情報も、マッピングデータベースシステムに保存されている情報も、RLOCのリーチビリティ情報を提供しません。到達可能性はマッピングシステムの一部ではなく、次のセクションで説明したRLOCリーチ可能性アルゴリズムの1つ以上を使用して決定されることに注意してください。
Several data plane mechanisms for determining RLOC reachability are currently defined. Please note that additional reachability mechanisms based on the control plane are defined in [RFC9301].
現在、RLOCの到達可能性を決定するためのいくつかのデータプレーンメカニズムが定義されています。コントロールプレーンに基づく追加の到達可能性メカニズムは[RFC9301]で定義されていることに注意してください。
1. An ETR MAY examine the Locator-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC.
1. ETRは、ITRから受信したカプセル化されたデータパケットのLISPヘッダーのロケーターステータスビットを調べることができます。ETRがITRとしても機能し、元のITRサイトに戻るトラフィックがある場合、このステータス情報を使用してRLOCを選択するのに役立ちます。
2. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely to be reachable. Please note that in some scenarios the RLOC from the outer header can be a spoofable field.
2. ETRがITRからカプセル化されたパケットを受信すると、パケットの外側ヘッダーからソースRLOCが到達可能になる可能性があります。いくつかのシナリオでは、外側のヘッダーからのRLOCがスプーフィング可能なフィールドになる可能性があることに注意してください。
3. An ITR/ETR pair can use the Echo-Noncing Locator reachability algorithms described in this section.
3. ITR/ETRペアは、このセクションで説明するエコーノンシングロケーターReachability Algorithmsを使用できます。
When determining Locator up/down reachability by examining the Locator-Status-Bits from the LISP-encapsulated data packet, an ETR will receive an up-to-date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows:
LISPにカプセル化されたデータパケットからロケーターステータスビットを調べることにより、ロケーターの上下に到達可能性を決定すると、ETRは、サイトのすべてのETRの到達可能性についてITRをカプセル化する最新のステータスを受け取ります。ソースサイトのCEベースのITRは、次のようにサイトIGPを使用して、相互に到達可能性を決定できます。
* Under normal circumstances, each ITR will advertise a default route into the site IGP.
* 通常の状況では、各ITRはデフォルトルートをサイトIGPに宣伝します。
* If an ITR fails or if the upstream link to its Provider Edge fails, its default route will either time out or be withdrawn.
* ITRが失敗した場合、またはプロバイダーEDGEへの上流のリンクが失敗した場合、そのデフォルトルートはタイムアウトまたは撤回されます。
Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator-Status-Bits it sets for them.
したがって、それぞれのITRは、他の人が起源とするデフォルトルートの存在または不足を観察して、それらが設定したロケーターステータスビットを決定することができます。
When ITRs at the site are not deployed in CE routers, the IGP can still be used to determine the reachability of Locators, provided they are injected into the IGP. This is typically done when a /32 address is configured on a loopback interface.
サイトのITRがCEルーターに展開されていない場合、IGPを使用して、IGPに注入された場合、ロケーターの到達可能性を決定できます。これは通常、a /32アドレスがループバックインターフェイスで構成されている場合に行われます。
RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Locator-Status-Bits in a LISP-encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the 'Locator-Status-Bits' field for the packets they encapsulate.
MAP-ReplyにリストされているRLOCには、序数0〜N-1で番号が付けられています。LISPにカプセル化されたパケットのロケーターステータスビットは、最小のビットから始まる0からN-1の番号が付けられています。たとえば、MAP-Replyの3番目の位置にリストされているRLOCが下がり（順序2）、サイトのすべてのITRが「ロケーターステータスビット」の3番目の最小有意ビット（xxxx x0xx）をクリアします。カプセル化するパケットのフィールド。
When an xTR decides to use Locator-Status-Bits to affect reachability information, it acts as follows: ETRs decapsulating a packet will check for any change in the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the ETR, if also acting as an ITR, will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Locator-Status-Bit returns to a value of 1. Locator-Status-Bits are associated with a Locator-Set per EID-Prefix. Therefore, when a Locator becomes unreachable, the Locator-Status-Bit that corresponds to that Locator's position in the list returned by the last Map-Reply will be set to zero for that particular EID-Prefix.
XTRがLocator-Statusビットを使用して到達可能性情報に影響を与えることを決定した場合、次のように機能します。ETRパケットを脱カプセル化すると、「ロケーターステータスビット」フィールドの変更が確認されます。ビットが1から0になると、ETRは、ITRとしても機能する場合、パケットをカプセル化することを控えて、ダウンとして示されています。対応するLocator-Status-Bitが1の値に戻る場合にのみ、そのRLOCを使用して再開します。Locator-Statusビットは、Eid-Prefixあたりのロケーターセットに関連付けられています。したがって、ロケーターが到達不能になると、最後のマップ応答によって返されるリスト内のロケーターの位置に対応するロケーターステータスビットは、その特定のEid-Prefixでゼロに設定されます。
Locator-Status-Bits MUST NOT be used over the public Internet and SHOULD only be used in trusted and closed deployments. In addition, Locator-Status-Bits SHOULD be coupled with Map-Versioning [RFC9302] to prevent race conditions where Locator-Status-Bits are interpreted as referring to different RLOCs than intended. Refer to Section 16 for security issues regarding this mechanism.
ロケーターステータスビットは、パブリックインターネットを介して使用してはなりません。信頼できる展開および閉鎖展開でのみ使用する必要があります。さらに、ロケータースタッツビットは、ロケーターステータスビットが意図されているのとは異なるRLOCを参照すると解釈されるレース条件を防ぐために、マップバージョン[RFC9302]と組み合わせて結合する必要があります。このメカニズムに関するセキュリティの問題については、セクション16を参照してください。
If an ITR encapsulates a packet to an ETR and the packet is received and decapsulated by the ETR, it is implied, but not confirmed by the ITR, that the ETR's RLOC is reachable. In most cases, the ETR can also reach the ITR but cannot assume this to be true, due to the possibility of path asymmetry. In the presence of unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD NOT use the lack of return traffic as an indication that the ETR is unreachable. Instead, it MUST use an alternate mechanism to determine reachability.
ITRがETRにパケットをカプセル化し、パケットがETRによって受信され、脱カプセル化されている場合、ETRのRLOCに到達可能であることを暗示しますが、ITRによって確認されていません。ほとんどの場合、ETRはITRに到達することもできますが、パスの非対称性の可能性があるため、これが真であると仮定することはできません。ITRからETRへの単方向のトラフィックフローが存在する場合、ITRは、ETRが到達不可能であることを示すために、リターントラフィックの不足を使用してはなりません。代わりに、到達可能性を決定するために代替メカニズムを使用する必要があります。
The security considerations of Section 16 related to data plane reachability apply to the data plane RLOC reachability mechanisms described in this section.
データプレーンの到達可能性に関連するセクション16のセキュリティ上の考慮事項は、このセクションで説明するデータプレーンRLOCリーチビリティメカニズムに適用されます。
When data flows bidirectionally between Locators from different sites, a data plane mechanism called "nonce echoing" can be used to determine reachability between an ITR and ETR. When an ITR wants to solicit a nonce echo, it sets the N- and E-bits and places a 24-bit nonce [RFC4086] in the LISP header of the next encapsulated data packet.
データが異なるサイトからのロケーター間で双方向に流れる場合、「非CEエコー」と呼ばれるデータプレーンメカニズムを使用して、ITRとETRの間の到達可能性を決定できます。ITRがノンセエコーを求めたい場合、次のカプセル化されたデータパケットのLISPヘッダーにn bitとeビットを設定し、24ビットのnonce [rfc4086]を配置します。
When this packet is received by the ETR, the encapsulated packet is forwarded as normal. When the ETR is an xTR (co-located as an ITR), it then sends a data packet to the ITR (when it is an xTR co-located as an ETR) and includes the nonce received earlier with the N-bit set and E-bit cleared. The ITR sees this "echoed nonce" and knows that the path to and from the ETR is up.
このパケットがETRによって受信されると、カプセル化されたパケットは通常のように転送されます。ETRがXTR（ITRとして共同住宅）の場合、ITRにデータパケットを送信し（ETRとして共同住宅されている場合）、N-BITセットで以前に受信したNONCEを含み、eビットがクリアされました。ITRは、この「エコーされたノンセ」を見て、ETRとの間の道が上がっていることを知っています。
The ITR will set the E-bit and N-bit for every packet it sends while in the Echo-Nonce-request state. The time the ITR waits to process the echoed nonce before it determines that the path is unreachable is variable and is a choice left for the implementation.
ITRは、Echo-Nonce-Request状態で送信されるすべてのパケットにeビットとnビットを設定します。ITRがパスが到達不能であると判断する前に、エコーしたノンセを処理するのを待つ時間は、実装のために残された選択であると判断します。
If the ITR is receiving packets from the ETR but does not see the nonce echoed while being in the Echo-Nonce-request state, then the path to the ETR is unreachable. This decision MAY be overridden by other Locator reachability algorithms. Once the ITR determines that the path to the ETR is down, it can switch to another Locator for that EID-Prefix.
ITRがETRからパケットを受信しているが、エコーノンセレクエスト状態にある間に非CEが反響しない場合、ETRへのパスは到達できません。この決定は、他のロケーターReachabilityアルゴリズムによってオーバーライドされる場合があります。ITRがETRへのパスがダウンしていると判断すると、そのeid-prefixの別のロケーターに切り替えることができます。
Note that "ITR" and "ETR" are relative terms here. Both devices MUST be implementing both ITR and ETR functionality for the Echo-Nonce mechanism to operate.
ここでは、「ITR」と「ETR」が相対的な用語であることに注意してください。両方のデバイスは、Echo-Nonceメカニズムを動作させるためにITR機能とETR機能の両方を実装している必要があります。
The ITR and ETR MAY both go into the Echo-Nonce-request state at the same time. The number of packets sent or the time during which Echo-Nonce request packets are sent is an implementation-specific setting. In this case, an xTR receiving the Echo-Nonce request packets will suspend the Echo-Nonce state and set up an 'Echo-Nonce-request-state' timer. After the 'Echo-Nonce-request-state' timer expires, it will resume the Echo-Nonce state.
ITRとETRはどちらも同時にエコーノンセレクエスト状態に入る可能性があります。送信されるパケットの数またはエコーノンセリクエストパケットが送信される時間は、実装固有の設定です。この場合、Echo-Nonceリクエストパケットを受信するXTRは、Echo-Nonce状態を停止し、「Echo-Nonce-Request-State」タイマーを設定します。「Echo-Nonce-Request-State」タイマーが期限切れになった後、Echo-Nonce状態を再開します。
This mechanism does not completely solve the forward path reachability problem, as traffic may be unidirectional. That is, the ETR receiving traffic at a site MAY not be the same device as an ITR that transmits traffic from that site, or the site-to-site traffic is unidirectional so there is no ITR returning traffic.
このメカニズムは、トラフィックが一方向である可能性があるため、フォワードパスの到達可能性の問題を完全に解決するものではありません。つまり、サイトでトラフィックを受信するETRは、そのサイトからトラフィックを送信するITRと同じデバイスではない場合があります。または、サイトからサイトへのトラフィックが単方向であるため、トラフィックを返すITRはありません。
The Echo-Nonce algorithm is bilateral. That is, if one side sets the E-bit and the other side is not enabled for Echo-Noncing, then the echoing of the nonce does not occur and the requesting side may erroneously consider the Locator unreachable. An ITR SHOULD set the E-bit in an encapsulated data packet when it knows the ETR is enabled for Echo-Noncing. This is conveyed by the E-bit in the Map-Reply message.
エコーノンセアルゴリズムは二国間です。つまり、一方がeビットを設定し、反対側がエコーノンシングのために有効になっていない場合、ノンセのエコーは発生せず、要求側はロケーターを誤って到達できないと誤って考慮することがあります。ETRがエコーノンシングに有効になっていることがわかっている場合、ITRはカプセル化されたデータパケットにeビットを設定する必要があります。これは、Map-Replyメッセージのeビットによって伝えられます。
Many implementations default to not advertising that they are Echo-Nonce capable in Map-Reply messages, and so RLOC-Probing tends to be used for RLOC reachability.
多くの実装は、マップリピュリーメッセージでエコーノンスが能力を持っていることを宣伝しないことを義務付けているため、RLOCプロビングはRLOCの到達可能性に使用される傾向があります。
The Echo-Nonce mechanism MUST NOT be used over the public Internet and MUST only be used in trusted and closed deployments. Refer to Section 16 for security issues regarding this mechanism.
エコーノンセメカニズムは、パブリックインターネットを介して使用する必要はなく、信頼できる展開および閉鎖展開でのみ使用する必要があります。このメカニズムに関するセキュリティの問題については、セクション16を参照してください。
A site MAY be multihomed using two or more ETRs. The hosts and infrastructure within a site will be addressed using one or more EID-Prefixes that are mapped to the RLOCs of the relevant ETRs in the Mapping System. One possible failure mode is for an ETR to lose reachability to one or more of the EID-Prefixes within its own site. When this occurs when the ETR sends Map-Replies, it can clear the R-bit associated with its own Locator. And when the ETR is also an ITR, it can clear its Locator-Status-Bit in the encapsulation data header.
サイトは、2つ以上のETRを使用してマルチホームされている場合があります。サイト内のホストとインフラストラクチャは、マッピングシステムの関連するETRのRLOCにマッピングされた1つ以上のEID-PREFIXを使用してアドレス指定されます。可能な障害モードの1つは、ETRが独自のサイト内の1つ以上のEid-Prefixesの到達可能性を失うことです。これがETRがマップレプリーを送信するときに発生すると、独自のロケーターに関連付けられたRビットをクリアできます。また、ETRがITRである場合、カプセル化データヘッダーのロケーターステータスビットをクリアできます。
It is recognized that there are no simple solutions to the site partitioning problem because it is hard to know which part of the EID-Prefix range is partitioned and which Locators can reach any sub-ranges of the EID-Prefixes. Note that this is not a new problem introduced by the LISP architecture. At the time of this writing, this problem exists when a multihomed site uses BGP to advertise its reachability upstream.
Eid-Prefix範囲のどの部分が分割され、どのロケーターがEid-Prefixesのサブレンジに到達できるかを知るのが困難であるため、サイトの分割問題に対する簡単な解決策はないことが認識されています。これは、LISPアーキテクチャによって導入された新しい問題ではないことに注意してください。この執筆時点で、この問題は、マルチホームサイトがBGPを使用して上流の到達可能性を宣伝するときに存在します。
When an ETR provides an EID-to-RLOC mapping in a Map-Reply message that is stored in the Map-Cache of a requesting ITR, the Locator-Set for the EID-Prefix MAY contain different Priority and Weight values for each Routing Locator Address. When more than one best Priority Locator exists, the ITR can decide how to load-share traffic against the corresponding Locators.
ETRがリクエストITRのマップキャッシュに保存されているMAP-REPLYメッセージにEID-TO-RLOCマッピングを提供する場合、EID-PREFIXのロケーターセットには、各ルーティングロケーターの異なる優先度と重量値が含まれる場合があります。住所。複数の優先度ロケーターが存在する場合、ITRは対応するロケーターに対するトラフィックをロードする方法を決定できます。
The following hash algorithm MAY be used by an ITR to select a Locator for a packet destined to an EID for the EID-to-RLOC mapping:
次のハッシュアルゴリズムは、EIDからRLOCマッピングのEIDに導かれるパケットのロケーターを選択するためにITRによって使用できます。
1. Either a source and destination address hash or the commonly used 5-tuple hash can be used. The commonly used 5-tuple hash includes the source and destination addresses; source and destination TCP, UDP, or Stream Control Transmission Protocol (SCTP) port numbers; and the IP protocol number field or IPv6 next-protocol fields of a packet that a host originates from within a LISP site. When a packet is not a TCP, UDP, or SCTP packet, the source and destination addresses only from the header are used to compute the hash.
1. ソースと宛先アドレスのハッシュまたは一般的に使用される5タプルハッシュのいずれかを使用できます。一般的に使用される5タプルのハッシュには、ソースアドレスと宛先アドレスが含まれます。ソースおよび宛先TCP、UDP、またはストリーム制御伝送プロトコル（SCTP）ポート番号。IPプロトコル番号フィールドまたはIPv6ホストがLISPサイト内から発生するパケットの次のプロトコルフィールド。パケットがTCP、UDP、またはSCTPパケットではない場合、ヘッダーからのみソースと宛先アドレスがハッシュを計算するために使用されます。
2. Take the hash value and divide it by the number of Locators stored in the Locator-Set for the EID-to-RLOC mapping.
2. ハッシュ値を取り、EID-to-RLOCマッピングのロケーターセットに保存されているロケーターの数でそれを分割します。
3. The remainder will yield a value of 0 to "number of Locators minus 1". Use the remainder to select the Locator in the Locator-Set.
3. 残りは0から「ロケーター数を引いた数」から0の値を生成します。残りを使用して、ロケーターセットのロケーターを選択します。
The specific hash algorithm the ITR uses for load-sharing is out of scope for this document and does not prevent interoperability.
ITRが負荷共有に使用する特定のハッシュアルゴリズムは、このドキュメントの範囲外であり、相互運用性を妨げません。
The source port SHOULD be the same for all packets belonging to the same flow. Also note that when a packet is LISP encapsulated, the source port number in the outer UDP header needs to be set. Selecting a hashed value allows core routers that are attached to Link Aggregation Groups (LAGs) to load-split the encapsulated packets across member links of such LAGs. Otherwise, core routers would see a single flow, since packets have a source address of the ITR, for packets that are originated by different EIDs at the source site. A suggested setting for the source port number computed by an ITR is a 5-tuple hash function on the inner header, as described above. The source port SHOULD be the same for all packets belonging to the same flow.
ソースポートは、同じフローに属するすべてのパケットで同じでなければなりません。また、パケットがLISPカプセル化されている場合、外側のUDPヘッダーのソースポート番号を設定する必要があることに注意してください。ハッシュ値を選択すると、リンク集約グループ（LAG）に取り付けられたコアルーターが、そのようなラグのメンバーリンクにカプセル化されたパケットをロードすることができます。それ以外の場合、パケットにはソースサイトの異なるEIDが発信するパケットのソースアドレスがあるため、コアルーターには単一のフローが表示されます。ITRによって計算されたソースポート番号の提案された設定は、上記のように内側ヘッダーの5タプルハッシュ関数です。ソースポートは、同じフローに属するすべてのパケットで同じでなければなりません。
Many core router implementations use a 5-tuple hash to decide how to balance packet load across members of a LAG. The 5-tuple hash includes the source and destination addresses of the packet and the source and destination ports when the protocol number in the packet is TCP or UDP. For this reason, UDP encoding is used for LISP encapsulation. In this scenario, when the outer header is IPv6, the flow label MAY also be set following the procedures specified in [RFC6438]. When the inner header is IPv6 and the flow label is not zero, it MAY be used to compute the hash.
多くのコアルーターの実装は、5タプルのハッシュを使用して、ラグのメンバー間でパケット負荷のバランスをとる方法を決定します。5タプルのハッシュには、パケットのプロトコル番号がTCPまたはUDPの場合、パケットのソースと宛先アドレスとソースおよび宛先ポートが含まれます。このため、UDPエンコードはLISPカプセル化に使用されます。このシナリオでは、外側のヘッダーがIPv6の場合、[RFC6438]で指定された手順に従ってフローラベルを設定することもできます。内側のヘッダーがIPv6であり、フローラベルがゼロでない場合、ハッシュを計算するために使用できます。
Since the LISP architecture uses a caching scheme to retrieve and store EID-to-RLOC mappings, the only way an ITR can get a more up-to-date mapping is to re-request the mapping. However, the ITRs do not know when the mappings change, and the ETRs do not keep track of which ITRs requested their mappings. For scalability reasons, it is desirable to maintain this approach, but implementors need to provide a way for ETRs to change their mappings and inform the sites that are currently communicating with the ETR site using such mappings.
LISPアーキテクチャはキャッシングスキームを使用してEid-to-RLOCマッピングを取得および保存するため、ITRがより最新のマッピングを取得できる唯一の方法は、マッピングを再クロックすることです。ただし、ITRはマッピングがいつ変更されるかを知りません。ETRは、ITRがマッピングを要求したものを追跡しません。スケーラビリティの理由から、このアプローチを維持することが望ましいですが、実装者はETRがマッピングを変更し、現在そのようなマッピングを使用してETRサイトと通信しているサイトに通知する方法を提供する必要があります。
This section defines two data plane mechanism for updating EID-to-RLOC mappings. Additionally, the Solicit-Map-Request (SMR) control plane updating mechanism is specified in [RFC9301].
このセクションでは、EIDからRLOCへのマッピングを更新するための2つのデータプレーンメカニズムを定義します。さらに、[RFC9301]では、Solicit-Map-Request（SMR）制御プレーンの更新メカニズムが指定されています。
Locator-Status-Bits (LSBs) can also be used to keep track of the Locator status (up or down) when EID-to-RLOC mappings are changing. When LSBs are used in a LISP deployment, all LISP Tunnel Routers MUST implement both ITR and ETR capabilities (therefore, all Tunnel Routers are effectively xTRs). In this section, the term "source xTR" is used to refer to the xTR setting the LSB and "destination xTR" is used to refer to the xTR receiving the LSB. The procedure is as follows:
Locator-Status-Bits（LSB）を使用して、Eid-to-RLOCマッピングが変更されているときにロケーターのステータス（上下）を追跡することもできます。LSBをLISP展開で使用する場合、すべてのLISPトンネルルーターがITR機能とETR機能の両方を実装する必要があります（したがって、すべてのトンネルルーターは効果的にXTRです）。このセクションでは、「ソースXTR」という用語は、LSBを設定するXTRを参照するために使用され、「宛先XTR」はLSBを受信するXTRを参照するために使用されます。手順は次のとおりです。
1. When a Locator record is added or removed from the Locator-Set, the source xTR will signal this by sending an SMR control plane message [RFC9301] to the destination xTR. At this point, the source xTR MUST NOT use the LSB field, when the L-bit is 0, since the destination xTR site has outdated information. The source xTR will set up a 'use-LSB' timer.
1. ロケーターレコードがロケーターセットから追加または削除された場合、ソースXTRは、SMRコントロールプレーンメッセージ[RFC9301]を宛先XTRに送信することにより、これに合図します。この時点で、宛先XTRサイトには時代遅れの情報があるため、LITが0の場合、ソースXTRはLSBフィールドを使用してはなりません。ソースXTRは、「us-lsb」タイマーを設定します。
2. As defined in [RFC9301], upon reception of the SMR message, the destination xTR will retrieve the updated EID-to-RLOC mappings by sending a Map-Request.
2. [RFC9301]で定義されているように、SMRメッセージが受信されると、宛先XTRは、Map-Requestを送信することにより、更新されたEid-to-RLOCマッピングを取得します。
3. When the 'use-LSB' timer expires, the source xTR can use the LSB again with the destination xTR to signal the Locator status (up or down). The specific value for the 'use-LSB' timer depends on the LISP deployment; the 'use-LSB' timer needs to be large enough for the destination xTR to retrieve the updated EID-to-RLOC mappings. A RECOMMENDED value for the 'use-LSB' timer is 5 minutes.
3. 「use-lsb」タイマーの有効期限が切れると、ソースxtrは宛先xtrでLSBを再度使用して、ロケーターのステータス（上下）を信号することができます。「us-lsb」タイマーの特定の値は、LISPの展開に依存します。「use-lsb」タイマーは、宛先xtrが更新されたeid-to-rlocマッピングを取得するのに十分な大きさである必要があります。「us-lsb」タイマーの推奨値は5分です。
When there is unidirectional packet flow between an ITR and ETR, and the EID-to-RLOC mappings change on the ETR, it needs to inform the ITR so encapsulation to a removed Locator can stop and can instead be started to a new Locator in the Locator-Set.
ITRとETRの間に一方向のパケットの流れがあり、ETRでEIDからRLOCへのマッピングが変化する場合、ITRに通知する必要があるため、削除されたロケーターへのカプセル化が停止し、代わりに新しいロケーターに開始できます。ロケーターセット。
An ETR can send Map-Reply messages carrying a Map-Version Number [RFC9302] in an EID-Record. This is known as the Destination Map-Version Number. ITRs include the Destination Map-Version Number in packets they encapsulate to the site.
ETRは、Map-version番号[RFC9302]をeid-Recordで伝達するマップ応答メッセージを送信できます。これは、宛先マップバージョン番号として知られています。ITRには、サイトにカプセル化するパケットに宛先マップバージョン番号が含まれています。
An ITR, when it encapsulates packets to ETRs, can convey its own Map-Version Number. This is known as the Source Map-Version Number.
ITRは、パケットをETRにカプセル化すると、独自のマップバージョン数を伝えることができます。これは、ソースマップバージョン番号として知られています。
When presented in EID-Records of Map-Register messages [RFC9301], a Map-Version Number is a good way for the Map-Server [RFC9301] to assure that all ETRs for a site registering to it are synchronized according to the Map-Version Number.
Map-Registerメッセージ[RFC9301]のEid-Recordsで提示されると、Map-Server [RFC9301]がマップ革新数が良い方法です。バージョンナンバー。
See [RFC9302] for a more detailed analysis and description of Database Map-Versioning.
データベースマップバージョンのより詳細な分析と説明については、[RFC9302]を参照してください。
A multicast group address, as defined in the original Internet architecture, is an identifier of a grouping of topologically independent receiver host locations. The address encoding itself does not determine the location of the receiver(s). The multicast routing protocol and the network-based state the protocol creates determine where the receivers are located.
元のインターネットアーキテクチャで定義されているマルチキャストグループアドレスは、トポロジカルに独立したレシーバーホストの場所のグループ化の識別子です。エンコード自体は、受信機の位置を決定しません。マルチキャストルーティングプロトコルとネットワークベースの状態プロトコルは、受信機がどこにあるかを決定します。
In the context of LISP, a multicast group address is both an EID and an RLOC. Therefore, no specific semantic or action needs to be taken for a destination address, as it would appear in an IP header. Therefore, a group address that appears in an inner IP header built by a source host will be used as the destination EID. The outer IP header (the destination RLOC address), prepended by a LISP router, can use the same group address as the destination RLOC, use a multicast or unicast RLOC obtained from a Mapping System lookup, or use other means to determine the group address mapping.
LISPのコンテキストでは、マルチキャストグループアドレスはEIDとRLOCの両方です。したがって、IPヘッダーに表示されるため、宛先アドレスに対して特定のセマンティックまたはアクションを実行する必要はありません。したがって、ソースホストによって構築された内部IPヘッダーに表示されるグループアドレスは、宛先EIDとして使用されます。LISPルーターで準備された外側IPヘッダー（宛先RLOCアドレス）は、宛先RLOCと同じグループアドレスを使用したり、マッピングシステムの検索から取得したマルチキャストまたはユニキャストRLOCを使用したり、他の手段を使用してグループアドレスを決定したりできます。マッピング。
With respect to the source RLOC address, the ITR prepends its own IP address as the source address of the outer IP header, just like it would if the destination EID was a unicast address. This source RLOC address, like any other RLOC address, MUST be routable on the underlay.
ソースRLOCアドレスに関して、ITRは、宛先EIDがユニキャストアドレスである場合と同じように、外部IPヘッダーのソースアドレスとして独自のIPアドレスをプレーニングします。このソースRLOCアドレスは、他のRLOCアドレスと同様に、アンダーレイでルーティング可能でなければなりません。
There are two approaches for LISP-Multicast [RFC6831]: one that uses native multicast routing in the underlay with no support from the Mapping System and another that uses only unicast routing in the underlay with support from the Mapping System. See [RFC6831] and [RFC8378], respectively, for details. Details for LISP-Multicast and interworking with non-LISP sites are described in [RFC6831] and [RFC6832], respectively.
Lisp-Multicast [RFC6831]には2つのアプローチがあります。1つは、マッピングシステムからのサポートなしで、アンダーレイでネイティブマルチキャストルーティングを使用し、マッピングシステムからサポートしてアンダーレイでユニキャストルーティングのみを使用するものです。詳細については、それぞれ[RFC6831]と[RFC8378]を参照してください。LISP-Multicastの詳細と非LISPサイトとの相互作用は、それぞれ[RFC6831]および[RFC6832]で説明されています。
LISP is designed to be very "hardware based and forwarding friendly". A few implementation techniques can be used to incrementally implement LISP:
LISPは、非常に「ハードウェアベースで転送に優しい」ように設計されています。いくつかの実装手法を使用して、LISPを段階的に実装できます。
* When a tunnel-encapsulated packet is received by an ETR, the outer destination address may not be the address of the router. This makes it challenging for the control plane to get packets from the hardware. This may be mitigated by creating special Forwarding Information Base (FIB) entries for the EID-Prefixes of EIDs served by the ETR (those for which the router provides an RLOC translation). These FIB entries are marked with a flag indicating that control plane processing SHOULD be performed. The forwarding logic of testing for particular IP protocol number values is not necessary. There are a few proven cases where no changes to existing deployed hardware were needed to support the LISP data plane.
* トンネルにカプセル化されたパケットがETRによって受信されると、外側の宛先アドレスがルーターのアドレスではない場合があります。これにより、制御プレーンがハードウェアからパケットを取得することが困難になります。これは、ETRが提供するEIDのEID-Prefixesの特別な転送情報ベース（FIB）エントリ（ルーターがRLOC翻訳を提供するもの）を作成することで緩和される場合があります。これらのFIBエントリには、コントロールプレーン処理を実行する必要があることを示すフラグが付いています。特定のIPプロトコル数値のテストの転送ロジックは必要ありません。LISPデータプレーンをサポートするために既存の展開ハードウェアに変更が必要であることが証明されたいくつかのケースがあります。
* On an ITR, prepending a new IP header consists of adding more octets to a Message Authentication Code (MAC) rewrite string and prepending the string as part of the outgoing encapsulation procedure. Routers that support Generic Routing Encapsulation (GRE) tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already support this action.
* ITRでは、新しいIPヘッダーの準備は、メッセージ認証コード（MAC）にさらにオクテットを追加し、文字列を書き換え、発信カプセル化手順の一部として文字列を準備することで構成されます。ジェネリックルーティングカプセル化（GRE）トンネル[RFC2784]または6to4トンネリング[RFC3056]をサポートするルーターは、すでにこのアクションをサポートする可能性があります。
* A packet's source address or the interface on which the packet was received can be used to select Virtual Routing and Forwarding (VRF). The VRF system's routing table can be used to find EID-to-RLOC mappings.
* パケットのソースアドレスまたはパケットが受信されたインターフェイスを使用して、仮想ルーティングと転送（VRF）を選択できます。VRFシステムのルーティングテーブルを使用して、Eid-to-RLOCマッピングを見つけることができます。
For performance issues related to Map-Cache management, see Section 16.
マップキャッシュ管理に関連するパフォーマンスの問題については、セクション16を参照してください。
In what follows, we highlight security considerations that apply when LISP is deployed in environments such as those specified in Section 1.1.
以下では、セクション1.1で指定されているような環境にLISPが展開されているときに適用されるセキュリティ上の考慮事項を強調します。
The optional gleaning mechanism is offered to directly obtain a mapping from the LISP-encapsulated packets. Specifically, an xTR can learn the EID-to-RLOC mapping by inspecting the source RLOC and source EID of an encapsulated packet and insert this new mapping into its Map-Cache. An off-path attacker can spoof the source EID address to divert the traffic sent to the victim's spoofed EID. If the attacker spoofs the source RLOC, it can mount a DoS attack by redirecting traffic to the spoofed victim's RLOC, potentially overloading it.
オプションのグリーニングメカニズムは、LISPにカプセル化されたパケットからマッピングを直接取得するために提供されます。具体的には、XTRは、カプセル化されたパケットのソースRLOCとソースEIDを検査し、この新しいマッピングをマップキャッシュに挿入することにより、Eid-to-RLOCマッピングを学習できます。オフパスの攻撃者は、Source Eidアドレスを吹き飛ばして、被害者のスプーフィングされたEidに送信されたトラフィックを転用できます。攻撃者がソースRLOCをスプーフィングする場合、スプーフィングされた被害者のRLOCへのトラフィックをリダイレクトし、潜在的に過負荷にすることにより、DOS攻撃を実施できます。
The LISP data plane defines several mechanisms to monitor RLOC data plane reachability; in this context, Locator-Status-Bits, nonce-present bits, and Echo-Nonce bits of the LISP encapsulation header can be manipulated by an attacker to mount a DoS attack. An off-path attacker able to spoof the RLOC and/or nonce of a victim's xTR can manipulate such mechanisms to declare false information about the RLOC's reachability status.
LISPデータプレーンは、RLOCデータプレーンの到達可能性を監視するためのいくつかのメカニズムを定義します。これに関連して、LISPカプセル化ヘッダーのロケーターステータスビット、ノンセプレゼントビット、およびエコーノンセビットは、DOS攻撃を実施するために攻撃者によって操作できます。被害者のXTRのRLOCおよび/またはNonCEをスプーフィングできるオフパス攻撃者は、そのようなメカニズムを操作して、RLOCの到達可能性ステータスに関する誤った情報を宣言することができます。
An example of such attacks is when an off-path attacker can exploit the Echo-Nonce mechanism by sending data packets to an ITR with a random nonce from an ETR's spoofed RLOC. Note that the attacker only has a small window of time within which to guess a valid nonce that the ITR is requesting to be echoed. The goal is to convince the ITR that the ETR's RLOC is reachable even when it may not be reachable. If the attack is successful, the ITR believes the wrong reachability status of the ETR's RLOC until RLOC-Probing detects the correct status. This time frame is on the order of tens of seconds. This specific attack can be mitigated by preventing RLOC spoofing in the network by deploying Unicast Reverse Path Forwarding (uRPF) per BCP 84 [RFC8704]. In order to exploit this vulnerability, the off-path attacker must also send Echo-Nonce packets at a high rate. If the nonces have never been requested by the ITR, it can protect itself from erroneous reachability attacks.
このような攻撃の例は、Pathオフパスの攻撃者が、ETRのスプーフィングされたRLOCからランダムなNonCEを使用してデータパケットをITRに送信することにより、エコーノンセメカニズムを悪用できる場合です。攻撃者は、ITRがエコーすることを要求している有効なノンセを推測するための小さな時間しかないことに注意してください。目標は、ETRのRLOCが到達できない場合でも到達可能であることをITRに納得させることです。攻撃が成功した場合、ITRは、RLOCプロビングが正しいステータスを検出するまで、ETRのRLOCの間違った到達可能性ステータスを信じています。この時間枠は数十秒の順序です。この特定の攻撃は、BCP 84 [RFC8704]ごとにユニキャストリバースパス転送（URPF）を展開することにより、ネットワーク内のRLOCスプーフィングを防ぐことにより緩和できます。この脆弱性を活用するために、オフパス攻撃者はエコーノンスパケットを高い割合で送信する必要があります。ITRからNoncesが要求されたことがない場合、誤った到達可能性攻撃から身を守ることができます。
A LISP-specific uRPF check is also possible. When decapsulating, an ETR can check that the source EID and RLOC are valid EID-to-RLOC mappings by checking the Mapping System.
LISP固有のURPFチェックも可能です。脱カプセル化する場合、ETRは、ソースEIDとRLOCがマッピングシステムをチェックすることにより有効なEIDからRLOCマッピングであることを確認できます。
Map-Versioning is a data plane mechanism used to signal to a peering xTR that a local EID-to-RLOC mapping has been updated so that the peering xTR uses a LISP control plane signaling message to retrieve a fresh mapping. This can be used by an attacker to forge the 'Map-Version' field of a LISP-encapsulated header and force an excessive amount of signaling between xTRs that may overload them. Further security considerations on Map-Versioning can be found in [RFC9302].
マップバージョンは、ピアリングXTRに信号を送信するために使用されるデータプレーンメカニズムであり、ローカルEIDからRLOCへのマッピングが更新されているため、ピアリングXTRがLISPコントロールプレーンのシグナリングメッセージを使用して新しいマッピングを取得します。これは、攻撃者がLISPにカプセル化されたヘッダーの「マップバージョン」フィールドを偽造し、それらを過負荷にする可能性のあるXTR間で過度の量のシグナル伝達を強制するために使用できます。マップバージョンに関するさらなるセキュリティ上の考慮事項は、[RFC9302]に記載されています。
Locator-Status-Bits, the Echo-Nonce mechanism, and Map-Versioning MUST NOT be used over the public Internet and SHOULD only be used in trusted and closed deployments. In addition, Locator-Status-Bits SHOULD be coupled with Map-Versioning to prevent race conditions where Locator-Status-Bits are interpreted as referring to different RLOCs than intended.
ロケーターステータスビット、エコーノンセメカニズム、およびマップバージョンは、パブリックインターネットで使用してはならず、信頼できる展開および閉鎖展開でのみ使用する必要があります。さらに、ロケーターステータスビットが、ロケーターステータスビットが意図しているのとは異なるRLOCを参照すると解釈されるレース条件を防ぐために、ロケーターステータスビットをマップバージョンと結合する必要があります。
LISP implementations and deployments that permit outer header fragments of IPv6 LISP-encapsulated packets as a means of dealing with MTU issues should also use implementation techniques in ETRs to prevent this from being a DoS attack vector. Limits on the number of fragments awaiting reassembly at an ETR, RTR, or PETR, and the rate of admitting such fragments, may be used.
MTUの問題に対処する手段としてIPv6 LISPにカプセル化されたパケットの外側ヘッダーフラグメントを許可するLISP実装と展開も、ETRの実装手法を使用して、これがDOS攻撃ベクトルであることを防ぐ必要があります。ETR、RTR、またはPETRで再組み立てを待つフラグメントの数の制限、およびそのようなフラグメントを認める速度を使用することができます。
Considerations for network management tools exist so the LISP protocol suite can be operationally managed. These mechanisms can be found in [RFC7052] and [RFC6835].
ネットワーク管理ツールの考慮事項が存在するため、LISPプロトコルスイートを運用上管理できるようにします。これらのメカニズムは、[RFC7052]および[RFC6835]に記載されています。
For implementation considerations, the following changes have been made to this document since [RFC6830] was published:
実装に関する考慮事項のために、[RFC6830]が公開されて以来、次の変更がこのドキュメントに行われました。
* It is no longer mandated that a maximum number of 2 LISP headers be prepended to a packet. If there is an application need for more than 2 LISP headers, an implementation can support more. However, it is RECOMMENDED that a maximum of 2 LISP headers can be prepended to a packet.
* 最大2つのLISPヘッダーがパケットに加入されることはもはや義務付けられていません。2つ以上のLISPヘッダーが必要なアプリケーションが必要な場合、実装はさらにサポートできます。ただし、最大2つのLISPヘッダーをパケットに準備することをお勧めします。
* The 3 reserved flag bits in the LISP header have been allocated for [RFC8061]. The low-order 2 bits of the 3-bit field (now named the KK-bits) are used as a key identifier. The 1 remaining bit is still documented as reserved and unassigned.
* LISPヘッダーの3つの予約されたフラグビットは、[RFC8061]に割り当てられています。3ビットフィールドの低次の2ビット（現在はKKビットと名付けられています）は、キー識別子として使用されます。残りのビットは、まだ予約されていないと記録されています。
* Data plane gleaning for creating Map-Cache entries has been made optional. Any ITR implementations that depend on or assume that the remote ETR is gleaning should not do so. This does not create any interoperability problems, since the control plane Map-Cache population procedures are unilateral and are the typical method for populating the Map-Cache.
* マップキャッシュエントリを作成するためのデータプレーングリーニングはオプションになりました。リモートETRがGLEANENINGに依存または想定されるITR実装は、そうするべきではありません。コントロールプレーンのマップキャッシュ母集団手順は一方的であり、マップキャッシュに登録するための典型的な方法であるため、これは相互運用性の問題を引き起こしません。
* Most of the changes to this document, which reduce its length, are due to moving the LISP control plane messaging and procedures to [RFC9301].
* このドキュメントの長さを短縮するこのドキュメントのほとんどの変更は、LISPコントロールプレーンのメッセージングと手順を[RFC9301]に移動することによるものです。
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to this data plane LISP specification, in accordance with BCP 26 [RFC8126].
このセクションでは、BCP 26 [RFC8126]に従って、このデータプレーンLISP仕様に関連する値の登録に関するインターネットが割り当てられた数字当局（IANA）にガイダンスを提供します。
IANA has allocated UDP port number 4341 for the LISP data plane. IANA has updated the description for UDP port 4341 as follows:
IANAは、LISPデータプレーンにUDPポート番号4341を割り当てました。IANAは、次のようにUDPポート4341の説明を更新しました。
+==============+=============+===========+=============+===========+
| Service Name | Port Number | Transport | Description | Reference |
| | | Protocol | | |
+==============+=============+===========+=============+===========+
| lisp-data | 4341 | udp | LISP Data | RFC 9300 |
| | | | Packets | |
+--------------+-------------+-----------+-------------+-----------+
Table 1
表1
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.
[RFC0768] POSTEL、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、DOI 10.17487/RFC0768、1980年8月、<https://www.rfc-editor.org/info/rfc768>。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.
[RFC0791] POSTEL、J。、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487/RFC0791、1981年9月、<https://www.rfc-editor.org/info/rfc791>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの分化サービスフィールド（DSフィールド）の定義」、RFC 2474、DOI 10.17487/RFC2474、1998年12月、<https://www.rfc-editor.org/info/rfc2474>。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, DOI 10.17487/RFC2983, October 2000, <https://www.rfc-editor.org/info/rfc2983>.
[RFC2983] Black、D。、「Dishireated Services and Tunnels」、RFC 2983、DOI 10.17487/RFC2983、2000年10月、<https://www.rfc-editor.org/info/rfc2983>。
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <https://www.rfc-editor.org/info/rfc6040>.
[RFC6040] Briscoe、B。、「明示的な混雑通知のトンネル」、RFC 6040、DOI 10.17487/RFC6040、2010年11月、<https://www.rfc-editor.org/info/rfc6040>
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, <https://www.rfc-editor.org/info/rfc6438>.
[RFC6438] Carpenter、B。およびS. Amante、「トンネルの等しいコストマルチパスルーティングとリンク集約にIPv6フローラベルを使用」、RFC 6438、DOI 10.17487/RFC6438、2011年11月、<https：//ww.rfc-editor.org/info/rfc6438>。
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, <https://www.rfc-editor.org/info/rfc6830>.
[RFC6830] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「ロケーター/ID分離プロトコル（LISP）」、RFC 6830、DOI 10.17487/RFC6830、2013年1月、<https：/<https：//www.rfc-editor.org/info/rfc6830>。
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, DOI 10.17487/RFC6831, January 2013, <https://www.rfc-editor.org/info/rfc6831>.
[RFC6831] Farinacci、D.、Meyer、D.、Zwiebel、J。、およびS. Venaas、「マルチキャスト環境のロケーター/ID分離プロトコル（LISP）」、RFC 6831、DOI 10.17487/RFC6831、2013年1月、<<<<https://www.rfc-editor.org/info/rfc6831>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126] Cotton、M.、Leiba、B。、およびT. Narten、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487/RFC8126、2017年6月、<https：// wwwwwwwwwwwwwwwwwwww.rfc-editor.org/info/rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487/RFC8200、2017年7月、<https://www.rfc-editor.org/info/rfc8200>。
[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>。
[RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Forwarding", BCP 84, RFC 8704, DOI 10.17487/RFC8704, February 2020, <https://www.rfc-editor.org/info/rfc8704>.
[RFC8704] Sriram、K.、Montgomery、D。、およびJ. Haas、「Enhinced Figtible-Path Unicast Reverse Path Forwarding」、BCP 84、RFC 8704、DOI 10.17487/RFC8704、2月2020、<https：// www。rfc-editor.org/info/rfc8704>。
[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>。
[AFN] IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers>.
[AFN] IANA、「Family Numbers」、<http://www.iana.org/assignments/address-family-numbers>。
[CHIAPPA] Chiappa, J., "Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture", 1999, <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>.
[Chiappa] Chiappa、J。、「エンドポイントとエンドポイント名：インターネットアーキテクチャの提案された強化」、1999、<http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>。
[LISP-VPN] Moreno, V. and D. Farinacci, "LISP Virtual Private Networks (VPNs)", Work in Progress, Internet-Draft, draft-ietf-lisp-vpn-10, 3 October 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-vpn-10>.
[lisp-vpn]モレノ、V。およびD.ファリナッチ、「LISP仮想プライベートネットワーク（VPNS）」、進行中の作業、インターネットドラフト、ドラフト-ITF-LISP-VPN-10、2022年10月3日、<https：/ <https：//datatracker.ietf.org/doc/html/draft-ietf-lisp-vpn-10>。
[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>.
[RFC1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、DOI 10.17487/RFC1034、1987年11月、<https://www.rfc-editor.org/info/rfc1034>
[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>。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, DOI 10.17487/RFC2453, November 1998, <https://www.rfc-editor.org/info/rfc2453>.
[RFC2453] Malkin、G。、「RIPバージョン2」、STD 56、RFC 2453、DOI 10.17487/RFC2453、1998年11月、<https://www.rfc-editor.org/info/rfc253>。
[RFC2677] Greene, M., Cucchiara, J., and J. Luciani, "Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP)", RFC 2677, DOI 10.17487/RFC2677, August 1999, <https://www.rfc-editor.org/info/rfc2677>.
[RFC2677] Greene、M.、Cucchiara、J。、およびJ. Luciani、「NBMA Next Hop Resolution Protocol（NHRP）の管理オブジェクトの定義」、RFC 2677、DOI 10.17487/RFC2677、1999年8月、<HTTPS：//www.rfc-editor.org/info/rfc2677>。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, <https://www.rfc-editor.org/info/rfc2784>.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D.、およびP. Traina、「Generic Routing capsulation（GRE）」、RFC 2784、DOI 10.17487/RFC2784、2000年3月、<https：//www.rfc-editor.org/info/rfc2784>。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 2001, <https://www.rfc-editor.org/info/rfc3056>.
[RFC3056]カーペンター、B。およびK.ムーア、「IPv4クラウドを介したIPv6ドメインの接続」、RFC 3056、DOI 10.17487/RFC3056、2001年2月、<https://www.rfc-editor.org/info/rfc3056>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、DOI 10.17487/RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4086] EastLake 3rd、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、DOI 10.17487/RFC4086、2005年6月、<https：//www.rfc-editor.org/info/rfc4086>。
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April 2006, <https://www.rfc-editor.org/info/rfc4459>.
[RFC4459] Savola、P。、「ネットワーク内トンネリングに関するMTUおよび断片化の問題」、RFC 4459、DOI 10.17487/RFC4459、2006年4月、<https://www.rfc-editor.org/info/rfc4459>。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.
[RFC4760] Bates、T.、Chandra、R.、Katz、D。、およびY. Rekhter、「BGP-4のマルチプロトコル拡張」、RFC 4760、DOI 10.17487/RFC4760、2007年1月、<https：// www。rfc-editor.org/info/rfc4760>。
[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>。
[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>。
[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、「Tunneled Packetsの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>。
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, February 2017, <https://www.rfc-editor.org/info/rfc8060>.
[RFC8060] Farinacci、D.、Meyer、D。、およびJ. Snijders、「Lisp Canonical Address Format（LCAF）」、RFC 8060、DOI 10.17487/RFC8060、2017年2月、<https：//ww.rfc-editor。org/info/rfc8060>。
[RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality", RFC 8061, DOI 10.17487/RFC8061, February 2017, <https://www.rfc-editor.org/info/rfc8061>.
[RFC8061] Farinacci、D。およびB. Weis、「ロケーター/ID分離プロトコル（LISP）データプレーン機密性」、RFC 8061、DOI 10.17487/RFC8061、2017年2月、<https：//www.rfc-editor.org/info/rfc8061>。
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8085] Eggert、L.、Fairhurst、G.、およびG. Shepherd、「UDP使用ガイドライン」、BCP 145、RFC 8085、DOI 10.17487/RFC8085、2017年3月、<https://www.rfc-editor.org/info/rfc8085>。
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.
[RFC8201] McCann、J.、Deering、S.、Mogul、J.、およびR. Hinden、ed。、「IPバージョン6のPath MTU Discovery」、STD 87、RFC 8201、DOI 10.17487/RFC8201、2017年7月、<https://www.rfc-editor.org/info/rfc8201>。
[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, "Packetization Layer Path MTU Discovery for Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, September 2020, <https://www.rfc-editor.org/info/rfc8899>.
[RFC8899] Fairhurst、G.、Jones、T.、Tüxen、M.、Rüngeler、I。、およびT.Völker、「Datagram Transports for Datagram TransportsのPacketization Layer Path Mtu Discovery」、DOI 10.17487/RFC8899、2020年9月、2020年9月、<https://www.rfc-editor.org/info/rfc8899>。
[RFC9299] Cabellos, A. and D. Saucez, Ed., "An Architectural Introduction to the Locator/ID Separation Protocol (LISP)", RFC 9299, DOI 10.17487/RFC9299, October 2022, <https://www.rfc-editor.org/info/rfc9299>.
[RFC9299] Cabellos、A。and D. Sauce、ed。、「ロケーター/ID分離プロトコル（LISP）の建築紹介」、RFC 9299、DOI 10.17487/RFC9299、2022年10月、<https：//ww.rfc-editor.org/info/rfc9299>。
Acknowledgments
謝辞
An initial thank you goes to Dave Oran for planting the seeds for the initial ideas for LISP. His consultation continues to provide value to the LISP authors.
最初の感謝は、LISPの最初のアイデアのために種を植えてくれたDave Oranにお願いします。彼の相談は、LISPの著者に価値を提供し続けています。
A special and appreciative thank you goes to Noel Chiappa for providing architectural impetus over the past decades on separation of location and identity, as well as detailed reviews of the LISP architecture and documents, coupled with enthusiasm for making LISP a practical and incremental transition for the Internet.
特別で感謝の気持ちは、ロケーションとアイデンティティの分離と、LISPアーキテクチャと文書の詳細なレビューについて、過去数十年にわたって建築上の衝動を提供してくれたNoel Chiappaに感謝します。インターネット。
The original authors would like to gratefully acknowledge many people who have contributed discussions and ideas to the making of this proposal. They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller, Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston, David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina Ermagan, Fabio Maino, Victor Moreno, Chris White, Clarence Filsfils, Alia Atlas, Florin Coras, and Alberto Rodriguez.
元の著者は、この提案の作成に議論やアイデアを提供した多くの人々に感謝して認めたいと思います。スコット・ブリム、アンドリュー・パルタン、ジョン・ズウィーベル、ジェイソン・シラー、リクシア・チャン、ドリアン・キム、ピーター・シェーンメーカー、ヴィジェイ・ギル、ジェフ・ヒューストン、デビッド・コンラッド、マーク・ハンドリー、ロン・ボニカ、テッド・シーリー、マーク・タウンズリー、クリス・マロー、ブリアン・ウェイス、デイブ・マクグリュー、ピーター・ロスバーグ、デイブ・ターラー、エリオット・リア、シェーン・アマンテ、ヴェド・カフル、オリビエ・ボナヴェントゥール、ルイジ・イアンノーネ、ロビン・ウィットル、ブライアン・カーペンター、ジョエル・ハルパーン、テリー・マンダーソン、ロジャー・ジョルゲンセン、ラン・アトキンソン、スティグ・ヴァン・ビアジット・ヴァン・ベイジュナス、イルジッチ・ヴァン・ベイジュナス祝福、ダナ・ブレア、ビル・リンチ、マーク・ウールワード、ダミアン・ソース、ダミアン・レザマ、アッティラ・デ・グルート、パンタップ・ラヒリ、デビッド・ブラック、ロケ・ガグリアーノ、イシドル・コウベラス、ジェスパー・スクリバー、フレッド・テンプリン、マーガレット・ワッサーン、サム・ハートマン、マイケル・マークリング、ペドロ・マルクス、Jari Arkko、Gregg Schudel、Srinivas Subramanian、Amit Jain、Xu Xiaohu、Dhirendra Trivedi、Yakov Rekhter、John Scudder、John Drake、Dimitri Papadimitriou、Ross Callon、Selina heimlich、Vina emagan、vavio mimagan、jobjdersホワイト、クラレンス・フィルSfils、Alia Atlas、Florin Coras、およびAlberto Rodriguez。
This work originated in the Routing Research Group (RRG) of the IRTF. An individual submission was converted into the IETF LISP Working Group document that became this RFC.
この作業は、IRTFのルーティング研究グループ（RRG）で発生しました。個別の提出物は、このRFCになったIETF LISPワーキンググループドキュメントに変換されました。
The LISP Working Group would like to give a special thanks to Jari Arkko, the Internet Area AD at the time that the set of LISP documents was being prepared for IESG Last Call, for his meticulous reviews and detailed commentaries on the 7 Working Group Last Call documents progressing toward Standards Track RFCs.
LISPワーキンググループは、LISPドキュメントのセットがIESGの最後のコールのために準備されていたときのインターネットエリア広告であるJari Arkkoに特別な感謝を捧げたいと思います。標準に向かって進行するドキュメントはRFCを追跡します。
The current authors would like to give a sincere thank you to the people who helped put LISP on the Standards Track in the IETF. They include Joel Halpern, Luigi Iannone, Deborah Brungard, Fabio Maino, Scott Bradner, Kyle Rose, Takeshi Takahashi, Sarah Banks, Pete Resnick, Colin Perkins, Mirja Kühlewind, Francis Dupont, Benjamin Kaduk, Eric Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper, Suresh Krishnan, Alberto Rodriguez-Natal, Vina Ermagan, Mohamed Boucadair, Brian Trammell, Sabrina Tanamal, and John Drake. The contributions they offered greatly added to the security, scale, and robustness of the LISP architecture and protocols.
現在の著者は、IETFの標準トラックにLISPを置くのを手伝ってくれた人々に心から感謝したいと思います。ジョエル・ハルパーン、ルイジ・イアンノーネ、デボラ・ブランガード、ファビオ・マニョ、スコット・ブラッドナー、カイル・ローズ、タカハシ、サラ・バンクス、ピート・レストニック、コリン・パーキンス、ミルジャ・キュルウィンド、フランシス・デュポン、ベンジャミン・カドゥク、エリック・レスカルラ、アルヴァロ・レクサイ、アリッサ・クーパー、スレシュ・クリシュナン、アルベルト・ロドリゲス・ナタール、ヴィナ・エルマガン、モハメド・ブーカデア、ブライアン・トラメル、サブリナ・タナマル、ジョン・ドレイク。彼らが提供した貢献は、LISPアーキテクチャとプロトコルのセキュリティ、規模、堅牢性に大きく追加されました。
Authors' Addresses
著者のアドレス
Dino Farinacci lispers.net San Jose, CA United States of America Email: farinacci@gmail.com
Dino Farinacci lispers.netサンノゼ、カリフォルニア州統一されたアメリカ電子メール：farinacci@gmail.com
Vince Fuller vaf.net Internet Consulting Email: vince.fuller@gmail.com
Vince Fuller vaf.netインターネットコンサルティングメール：vince.fuller@gmail.com
Dave Meyer 1-4-5.net Email: dmm@1-4-5.net
Dave Meyer 1-4-5.netメール：dmm@1-4-5.net
Darrel Lewis Cisco Systems San Jose, CA United States of America Email: darlewis@cisco.com
Darrel Lewis Cisco Systems San Jose、CA Neciment States of America Email：darlewis@cisco.com
Albert Cabellos (editor) Universitat Politecnica de Catalunya c/ Jordi Girona s/n 08034 Barcelona Spain Email: acabello@ac.upc.edu
Albert Cabellos（編集者）Politecnica de Catalunya C/ Jordi Girona S/ N 08034バルセロナスペインメール：acabello@ac.upc.edu