[要約] RFC 9305は、LISPデータプレーンの拡張を通じて、マルチプロトコルのカプセル化をサポートし、新しいプロトコル機能の導入を可能にすることを目的としています。
Internet Engineering Task Force (IETF) F. Maino, Ed.
Request for Comments: 9305 Cisco
Category: Standards Track J. Lemon
ISSN: 2070-1721
P. Agarwal
Innovium
D. Lewis
M. Smith
Cisco
October 2022
Locator/ID Separation Protocol (LISP) Generic Protocol Extension
ロケーター/ID分離プロトコル（LISP）ジェネリックプロトコル拡張
Abstract
概要
This document describes extensions to the Locator/ID Separation Protocol (LISP) data plane, via changes to the LISP header, to support multiprotocol encapsulation and allow the introduction of new protocol capabilities.
このドキュメントでは、LISPヘッダーの変更を介して、ロケーター/ID分離プロトコル（LISP）データプレーンへの拡張機能について、マルチプロトコルのカプセル化をサポートし、新しいプロトコル機能の導入を可能にします。
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/rfc9305.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9305で取得できます。
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. Conventions
1.2. Definitions of Terms
2. LISP Header without Protocol Extensions
3. LISP Generic Protocol Extension (LISP-GPE)
4. Implementation and Deployment Considerations
4.1. Applicability Statement
4.2. Congestion-Control Functionality
4.3. UDP Checksum
4.3.1. UDP Zero Checksum Handling with IPv6
4.4. DSCP, ECN, TTL, and 802.1Q
5. Backward Compatibility
5.1. Detection of ETR Capabilities
6. IANA Considerations
6.1. LISP-GPE Next Protocol Registry
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
The LISP data plane is defined in [RFC9300]. It specifies an encapsulation format that carries IPv4 or IPv6 packets (henceforth jointly referred to as IP) in a LISP header and outer UDP/IP transport.
LISPデータプレーンは[RFC9300]で定義されています。LISPヘッダーと外側のUDP/IPトランスポートにIPv4またはIPv6パケット（以降、IPと共同で呼ばれる）を搭載したカプセル化形式を指定します。
The LISP data plane header does not specify the protocol being encapsulated and, therefore, is currently limited to encapsulating only IP packet payloads. Other protocols, most notably the Virtual eXtensible Local Area Network (VXLAN) protocol [RFC7348] (which defines a header format similar to LISP), are used to encapsulate Layer 2 (L2) protocols, such as Ethernet.
LISPデータプレーンヘッダーは、カプセル化されているプロトコルを指定していないため、現在、IPパケットペイロードのみをカプセル化することに限定されています。他のプロトコル、特に仮想拡張可能なローカルエリアネットワーク（VXLAN）プロトコル[RFC7348]（LISPと同様のヘッダー形式を定義）は、イーサネットなどのレイヤー2（L2）プロトコルをカプセル化するために使用されます。
This document defines an extension for the LISP header, as defined in [RFC9300], to indicate the inner protocol, enabling the encapsulation of Ethernet, IP, or any other desired protocol, all the while ensuring compatibility with existing LISP deployments.
このドキュメントでは、[RFC9300]で定義されているLISPヘッダーの拡張機能を定義し、内部プロトコルを示し、イーサネット、IP、またはその他の望ましいプロトコルのカプセル化を可能にし、その間、既存のLISP展開との互換性を確保します。
A flag in the LISP header -- the P-bit -- is used to signal the presence of the 8-bit 'Next Protocol' field. The 'Next Protocol' field, when present, uses 8 bits of the field that was allocated to the Echo-Noncing and Map-Versioning features in [RFC9300]. Those two features are no longer available when the P-bit is used. However, appropriate LISP Generic Protocol Extension (LISP-GPE) shim headers can be defined to specify capabilities that are equivalent to Echo-Noncing and/or Map-Versioning.
LISPヘッダーのフラグ - Pビット - は、8ビット「次のプロトコル」フィールドの存在を信号するために使用されます。「次のプロトコル」フィールドは、存在する場合、[RFC9300]のエコーノンシングおよびマップバージョン機能に割り当てられた8ビットのフィールドを使用します。これらの2つの機能は、Pビットを使用すると使用できなくなりました。ただし、適切なLISPジェネリックプロトコル拡張（LISP-GPE）シムヘッダーを定義して、エコーノンシングおよび/またはマップバージョンに相当する機能を指定できます。
Since all of the reserved bits of the LISP data plane header have been allocated, LISP-GPE can also be used to extend the LISP data plane header by defining Next Protocol shim headers that implement new data plane functions not supported in the LISP header. For example, the use of the Group-Based Policy (GBP) header [VXLAN-LISP] or of the In situ Operations, Administration, and Maintenance (IOAM) header [VXLAN-GPE] with LISP-GPE can be considered an extension to add support in the data plane for GBP functionalities or IOAM metadata.
LISPデータプレーンヘッダーの予約ビットはすべて割り当てられているため、LISP-GPEを使用して、LISPヘッダーでサポートされていない新しいデータプレーン機能を実装する次のプロトコルシムヘッダーを定義することにより、LISPデータプレーンヘッダーを拡張することもできます。たとえば、グループベースのポリシー（GBP）ヘッダー[VXLAN-LISP]またはIn in situ操作、管理、およびメンテナンス（IOAM）ヘッダー[VXLAN-GPE]の使用は、の拡張と見なすことができます。GBP機能またはIOAMメタデータのデータプレーンにサポートを追加します。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document uses terms already defined in [RFC9300].
このドキュメントでは、[RFC9300]で既に定義されている用語を使用しています。
As described in Section 1, the LISP header has no protocol identifier that indicates the type of payload being carried. Because of this, LISP is limited to carrying IP payloads.
セクション1で説明されているように、LISPヘッダーには、伝達されるペイロードのタイプを示すプロトコル識別子がありません。このため、LISPはIPペイロードを運ぶことに限定されています。
The LISP header [RFC9300] contains a series of flags (some defined, some reserved), a 'Nonce/Map-Version' field, and an 'Instance ID/ Locator-Status-Bits' field. The flags provide flexibility to define how the various fields are encoded. Notably, Flag bit 5 is the last reserved bit in the LISP header.
LISPヘッダー[RFC9300]には、一連のフラグ（一部は定義されたもの、いくつかの予約済み）、「非CE/マップバージョン」フィールド、および「ID/ Locator-Status-Bits」フィールドが含まれています。フラグは、さまざまなフィールドのエンコード方法を定義する柔軟性を提供します。特に、フラグビット5は、LISPヘッダーの最後の予約ビットです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|R|K|K| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID/Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: LISP Header
図1：LISPヘッダー
This document defines two changes to the LISP header in order to support multiprotocol encapsulation: the introduction of the P-bit and the definition of a 'Next Protocol' field. This document specifies the protocol behavior when the P-bit is set to 1; no changes are introduced when the P-bit is set to 0. The LISP-GPE header is shown in Figure 2 and described below.
このドキュメントでは、マルチプロトコルのカプセル化をサポートするために、LISPヘッダーの2つの変更を定義します。Pビットの導入と「次のプロトコル」フィールドの定義です。このドキュメントは、Pビットが1に設定されているときのプロトコル動作を指定します。Pビットが0に設定されている場合、変更は導入されません。LISP-GPEヘッダーを図2に示し、以下に説明します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|P|K|K| Nonce/Map-Version/Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID/Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: LISP-GPE Header
図2：LISP-GPEヘッダー
P-Bit: Flag bit 5 is defined as the Next Protocol bit. The P-bit is set to 1 to indicate the presence of the 8-bit 'Next Protocol' field.
Pビット：フラグビット5は、次のプロトコルビットとして定義されます。Pビットは1に設定されており、8ビット「次のプロトコル」フィールドの存在を示します。
If the P-bit is clear (0), the LISP header is bit-by-bit equivalent to the definition in [RFC9300].
Pビットがクリア（0）の場合、LISPヘッダーは[RFC9300]の定義に少し相当します。
When the P-bit is set to 1, bits N, E, and V, and bits 8-23 of the 'Nonce/Map-Version/Next Protocol' field MUST be set to zero on transmission and MUST be ignored on receipt. Features equivalent to those that were implemented with bits N, E, and V in [RFC9300], such as Echo-Noncing and Map-Versioning, can be implemented by defining appropriate LISP-GPE shim headers.
Pビットが1に設定されている場合、ビットN、E、V、および「NonCE/MAP-version/Next Protocol」フィールドの8-23は、送信時にゼロに設定する必要があり、受領時に無視する必要があります。[RFC9300]にビットN、E、およびVで実装された機能と同等の機能など、エコーノンシングやマップバージョンなどは、適切なLISP-GPEシムヘッダーを定義することで実装できます。
When the P-bit is set to 1, the LISP-GPE header is encoded as:
Pビットが1に設定されると、LISP-GPEヘッダーは次のようにエンコードされます。
0 x 0 0 x 1 x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|P|K|K| 0x0000 | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID/Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: LISP-GPE with P-bit Set to 1
図3：Pビットを1に設定したLISP-GPE
Next Protocol: When the P-bit is set to 1, the lower 8 bits of the first 32-bit word are used to carry a Next Protocol. This 'Next Protocol' field contains the protocol of the encapsulated payload packet.
次のプロトコル：Pビットが1に設定されると、最初の32ビットワードの下部8ビットが次のプロトコルを運ぶために使用されます。この「次のプロトコル」フィールドには、カプセル化されたペイロードパケットのプロトコルが含まれています。
This document defines the following Next Protocol values:
このドキュメントは、次のプロトコル値を定義します。
0x00: Reserved
0x00：予約済み
0x01: IPv4
0x01：IPv4
0x02: IPv6
0x02：IPv6
0x03: Ethernet
0x03：イーサネット
0x04: Network Service Header (NSH) [RFC8300]
0x04：ネットワークサービスヘッダー（NSH）[RFC8300]
0x05 to 0x7D: Unassigned
0x05〜0x7d：割り当てなし
0x7E and 0x7F: Experimentation and testing
0x7eおよび0x7f：実験とテスト
0x80 to 0xFD: Unassigned (shim headers)
0x80〜0xfd：未割り当て（シムヘッダー）
0xFE, 0xFF: Experimentation and testing (shim headers)
0xfe、0xff：実験とテスト（シムヘッダー）
The values are tracked in the IANA "LISP-GPE Next Protocol" registry, as described in Section 6.1.
値は、セクション6.1で説明されているように、IANA「LISP-GPE Next Protocol」レジストリで追跡されます。
Next Protocol values 0x7E, 0x7F, 0xFE, and 0xFF are assigned for experimentation and testing, as per [RFC3692].
[RFC3692]によると、次のプロトコル値0x7e、0x7f、0xfe、および0xffは、実験とテストに割り当てられています。
Next Protocol values from 0x80 to 0xFD are assigned to protocols encoded as generic shim headers. All shim protocols MUST use the header structure in Figure 4, which includes a 'Next Protocol' field. When shim headers are used with other protocols identified by Next Protocol values from 0x00 to 0x7F, all the shim headers MUST come first.
0x80から0xFDの次のプロトコル値は、汎用シムヘッダーとしてエンコードされたプロトコルに割り当てられます。すべてのSHIMプロトコルは、「次のプロトコル」フィールドを含む図4のヘッダー構造を使用する必要があります。シムヘッダーが0x00から0x7Fの次のプロトコル値によって識別される他のプロトコルで使用される場合、すべてのシムヘッダーが最初に来なければなりません。
Shim headers can be used to incrementally deploy new GPE features, keeping the processing of shim headers known to a given Tunnel Router (xTR) implementation in the 'fast' path (typically an Application-Specific Integrated Circuit (ASIC)) while punting the processing of the remaining new GPE features to the 'slow' path.
シムヘッダーを使用して、新しいGPE機能を段階的に展開し、「高速」パス（通常はアプリケーション固有の統合回路（ASIC））で特定のトンネルルーター（XTR）の実装に既知のシムヘッダーの処理を維持することができます。残りの新しいGPE機能の「遅い」パスへの機能。
Shim protocols MUST have the first 32 bits defined as:
シムプロトコルには、次のように定義された最初の32ビットが必要です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Protocol-Specific Fields ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Shim Header
図4：シムヘッダー
Where:
ただし：
Type: This field identifies the different messages of this protocol.
タイプ：このフィールドは、このプロトコルのさまざまなメッセージを識別します。
Length: This field indicates the length, in 4-octet units, of this protocol message, not including the first 4 octets.
長さ：このフィールドは、このプロトコルメッセージの4オクテット単位の長さを示し、最初の4オクテットは含まれません。
Reserved: The use of this field is reserved to the protocol defined in this message.
予約済み：このフィールドの使用は、このメッセージで定義されているプロトコルに予約されています。
Next Protocol: This field contains the protocol of the encapsulated payload. The values are tracked in the IANA "LISP-GPE Next Protocol" registry, as described in Section 6.1.
次のプロトコル：このフィールドには、カプセル化されたペイロードのプロトコルが含まれています。値は、セクション6.1で説明されているように、IANA「LISP-GPE Next Protocol」レジストリで追跡されます。
LISP-GPE conforms, as a UDP-based encapsulation protocol, to the UDP usage guidelines specified in [RFC8085]. The applicability of these guidelines is dependent on the underlay IP network and the nature of the encapsulated payload.
LISP-GPEは、UDPベースのカプセル化プロトコルとして、[RFC8085]で指定されたUDP使用ガイドラインに適合します。これらのガイドラインの適用性は、アンダーレイIPネットワークとカプセル化されたペイロードの性質に依存します。
[RFC8085] outlines two applicability scenarios for UDP applications: 1) the general Internet and 2) a controlled environment. A controlled environment means a single administrative domain or adjacent set of cooperating domains. A network in a controlled environment can be managed to operate under certain conditions, whereas, in the general Internet, this cannot be done. Hence, requirements for a tunnel protocol operating under a controlled environment can be less restrictive than the requirements of the general Internet.
[RFC8085]は、UDPアプリケーションの2つの適用可能性シナリオの概要を説明します。1）一般的なインターネットと2）制御された環境。制御された環境とは、単一の管理ドメインまたは隣接する協力ドメインのセットを意味します。制御された環境のネットワークは、特定の条件下で動作することができますが、一般的なインターネットでは、これはできません。したがって、制御された環境で動作するトンネルプロトコルの要件は、一般的なインターネットの要件よりも制限が少ない場合があります。
The LISP-GPE scope of applicability is the same set of use cases covered by [RFC9300] for the LISP data plane protocol. The common property of these use cases 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-GPE範囲は、LISPデータプレーンプロトコルの[RFC9300]でカバーされているユースケースのセットと同じセットです。これらのユースケースの共通の財産は、パブリックインターネットやその他の大規模なアンダーレイIPインフラストラクチャを介して通信しようとする協力エンティティの大規模なセットであり、協力エンティティのアドレス指定とトポロジーを、アンダーレイおよびインターネットトポロジ、ルーティング、およびアドレス指定とは別に維持します。
LISP-GPE is meant to be deployed in network environments operated by a single operator or adjacent set of cooperating network operators that fit with the definition of controlled environments in [RFC8085].
LISP-GPEは、[RFC8085]の制御環境の定義に適合する、単一の演算子または隣接する協力ネットワークオペレーターによって動作するネットワーク環境で展開することを目的としています。
For the purpose of this document, a Traffic-Managed Controlled Environment (TMCE), outlined in [RFC8086], is defined as an IP network that is traffic-engineered and/or otherwise managed (e.g., via the use of traffic rate limiters) to avoid congestion. Significant portions of the text in this section are based on [RFC8086].
このドキュメントの目的のために、[RFC8086]で概説されているトラフィック管理された制御環境（TMCE）は、トラフィックエンジニアリングおよび/またはその他の方法で管理されているIPネットワークとして定義されます（たとえば、トラフィックレートリミッターの使用を介して）混雑を避けるため。このセクションのテキストの重要な部分は、[RFC8086]に基づいています。
It is the responsibility of the network operators to ensure that the guidelines/requirements in this section are followed as applicable to their LISP-GPE deployments.
ネットワークオペレーターの責任は、このセクションのガイドライン/要件が、LISP-GPEの展開に適用可能に従うことを保証することです。
LISP-GPE does not provide congestion-control functionality and relies on the payload protocol traffic for congestion control. As such, LISP-GPE MUST be used with congestion-controlled traffic or within a network that is traffic managed to avoid congestion (TMCE). An operator of a traffic-managed network (TMCE) may avoid congestion by careful provisioning of their networks, rate limiting of user data traffic, and traffic engineering according to path capacity.
LISP-GPEは混雑制御機能を提供せず、うっ血制御のペイロードプロトコルトラフィックに依存しています。そのため、LISP-GPEは、混雑制御されたトラフィックで、または混雑を避けるために管理されたトラフィック（TMCE）で使用する必要があります。トラフィック管理ネットワーク（TMCE）のオペレーターは、ネットワークの慎重なプロビジョニング、ユーザーデータトラフィックのレート制限、およびパス容量に応じたトラフィックエンジニアリングにより、混雑を回避できます。
Keeping in mind the recommendation above, new encapsulated payloads, when registered with LISP-GPE, MUST be accompanied by a set of guidelines derived from Section 5 of [RFC9300]. Such new protocols should be designed for explicit congestion signals to propagate consistently from lower-layer protocols into IP. Then, the IP internetwork layer can act as a portability layer to carry congestion notifications from non-IP-aware congested nodes up to the transport layer (L4). By following the guidelines in [ENCAP-GUIDE], subnetwork designers can enable a Layer 2 protocol to participate in congestion control without dropping packets, via propagation of Explicit Congestion Notification (ECN) data [RFC3168] to receivers.
上記の推奨を念頭に置いて、LISP-GPEに登録されている場合、新しいカプセル化されたペイロードには、[RFC9300]のセクション5から派生した一連のガイドラインを添付する必要があります。このような新しいプロトコルは、より低層のプロトコルからIPに一貫して伝播するために、明示的なうっ血信号のために設計する必要があります。次に、IPインターネットワークレイヤーは、輸送層（L4）までの非IPに認識された混雑ノードから輻輳通知を運ぶための移植性レイヤーとして機能します。[Encap-Guide]のガイドラインに従うことにより、サブネットワーク設計者は、レイヤー2プロトコルが、明示的なうっ血通知（ECN）データ[RFC3168]の伝播を介して受信機へのパケットを落とすことなく、混雑制御に参加できるようにします。
For IP payloads, Section 5.3 of [RFC9300] specifies how to handle UDP checksums, encouraging implementors to consider UDP checksum usage guidelines in Section 3.4 of [RFC8085] when it is desirable to protect UDP and LISP headers against corruption.
IPペイロードの場合、[RFC9300]のセクション5.3は、UDPチェックサムを処理する方法を指定し、腐敗に対するUDPおよびLISPヘッダーを保護することが望ましい場合、[RFC8085]のセクション3.4のUDPチェックサムの使用ガイドラインを検討するよう実装者に奨励しています。
In order to protect the integrity of LISP-GPE headers, options, and payloads (for example, to avoid misdelivery of payloads to different tenant systems in the case of data corruption), the outer UDP checksum SHOULD be used with LISP-GPE when transported over IPv4. The UDP checksum provides a statistical guarantee that a payload was not corrupted in transit. These integrity checks are not strong from a coding or cryptographic perspective and are not designed to detect physical-layer errors or malicious modifications of the datagram (see Section 3.4 of [RFC8085]). In deployments where such a risk exists, an operator SHOULD use additional data integrity mechanisms, such as those offered by IPsec.
LISP-GPEヘッダー、オプション、ペイロードの整合性を保護するには（たとえば、データ腐敗の場合、異なるテナントシステムへのペイロードの誤配信を避けるため）、輸送時にLISP-GPEで外側のUDPチェックサムを使用する必要があります。オーバーIPv4。UDPチェックサムは、輸送中にペイロードが破損していないという統計的保証を提供します。これらの整合性チェックは、コーディングや暗号化の観点からは強くなく、データグラムの物理的層エラーや悪意のある変更を検出するようには設計されていません（[RFC8085]のセクション3.4を参照）。このようなリスクが存在する展開では、オペレーターはIPSECが提供するような追加のデータ整合性メカニズムを使用する必要があります。
An operator MAY choose to disable a UDP checksum and use a zero checksum if LISP-GPE packet integrity is provided by other data integrity mechanisms, such as IPsec or additional checksums, or if one of the conditions in Section 4.3.1 (a, b, or c) is met.
オペレーターは、UDPチェックサムを無効にすることを選択し、IPSECや追加チェックサムなどの他のデータ整合性メカニズムによってLISP-GPEパケットの整合性が提供されている場合、またはセクション4.3.1の条件のいずれか（a、b）（a、b）の場合、ゼロチェックサムを使用することを選択できます。、またはc）が満たされます。
By default, a UDP checksum MUST be used when LISP-GPE is transported over IPv6. A tunnel endpoint MAY be configured for use with a zero UDP checksum if additional requirements described in this section are met.
デフォルトでは、LISP-GPEがIPv6を介して輸送される場合、UDPチェックサムを使用する必要があります。このセクションで説明されている追加要件が満たされている場合、ゼロUDPチェックサムで使用するためにトンネルエンドポイントを構成することができます。
When LISP-GPE is used over IPv6, a UDP checksum is used to protect IPv6 headers, UDP headers, and LISP-GPE headers and payloads from potential data corruption. As such, by default, LISP-GPE MUST use a UDP checksum when transported over IPv6. An operator MAY choose to configure to operate with a zero UDP checksum if operating in a traffic-managed controlled environment, as stated in Section 4.1, if one of the following conditions is met:
LISP-GPEがIPv6で使用される場合、UDPチェックサムを使用して、IPv6ヘッダー、UDPヘッダー、LISP-GPEヘッダーと潜在的なデータ腐敗からペイロードを保護します。そのため、デフォルトでは、LISP-GPEはIPv6を介して輸送されるときにUDPチェックサムを使用する必要があります。オペレーターは、次の条件のいずれかが満たされている場合、セクション4.1に記載されているように、トラフィック管理された制御環境で動作する場合、ゼロUDPチェックサムで動作するように構成することを選択できます。
a. It is known that packet corruption is exceptionally unlikely (perhaps based on an operator's knowledge of equipment types in their underlay network), and the operator is willing to take the risk of undetected packet corruption.
a. パケットの腐敗は非常にありそうもないことが知られています（おそらく、アンダーレイネットワーク内の機器タイプに関するオペレーターの知識に基づいています）、オペレーターは検出されないパケット腐敗のリスクを負うことをいとわない。
b. It is determined through observational measurements (perhaps through historic or current traffic flows that use a non-zero checksum) that the level of packet corruption is tolerably low, and the operator is willing to take the risk of undetected corruption.
b. パケット腐敗のレベルが容認できるほど低く、オペレーターは検出されない腐敗のリスクを冒すことをいとわないことが、観察測定（おそらくゼロ以外のチェックサムを使用する歴史的または現在のトラフィックフローを通じて）を通じて決定されます。
c. LISP-GPE payloads are carrying applications that are tolerant of misdelivered or corrupted packets (perhaps through higher-layer checksum validation and/or reliability through retransmission).
c. LISP-GPEペイロードは、誤解または破損したパケットに耐性のあるアプリケーションを運んでいます（おそらく、再送信による高層チェックサムの検証および/または信頼性を介して）。
In addition, LISP-GPE tunnel implementations using a zero UDP checksum MUST meet the following requirements:
さらに、ゼロUDPチェックサムを使用したLISP-GPEトンネルの実装は、次の要件を満たす必要があります。
1. Use of a UDP checksum over IPv6 MUST be the default configuration for all LISP-GPE tunnels.
1. IPv6を介したUDPチェックサムの使用は、すべてのLISP-GPEトンネルのデフォルト構成でなければなりません。
2. If LISP-GPE is used with a zero UDP checksum over IPv6, then such xTR implementations MUST meet all the requirements specified in Section 4 of [RFC6936] and requirement 1 specified in Section 5 of [RFC6936].
2. LISP-GPEがIPv6を介してゼロUDPチェックサムで使用されている場合、そのようなXTR実装は[RFC6936]のセクション4で指定されたすべての要件を満たし、[RFC6936]のセクション5で指定されている要件1を満たす必要があります。
3. The Egress Tunnel Router (ETR) that decapsulates the packet SHOULD check that the source and destination IPv6 addresses are valid for the LISP-GPE tunnel that is configured to receive a zero UDP checksum and discard other packets that fail such checks.
3. パケットを脱カプセル化する出力トンネルルーター（ETR）は、ソースと宛先IPv6アドレスがゼロUDPチェックサムを受信するように構成されているLISP-GPEトンネルに対して有効であることを確認する必要があり、そのようなチェックに失敗する他のパケットを破棄することが確認されます。
4. The Ingress Tunnel Router (ITR) that encapsulates the packet MAY use different IPv6 source addresses for each LISP-GPE tunnel that uses zero UDP checksum mode in order to strengthen the decapsulator's check of the IPv6 source address (i.e., the same IPv6 source address is not to be used with more than one IPv6 destination address, irrespective of whether that destination address is a unicast or multicast address). When this is not possible, it is RECOMMENDED to use each source address for as few LISP-GPE tunnels that use a zero UDP checksum as is feasible.
4. パケットをカプセル化するIngress Tunnelルーター（ITR）は、IPv6ソースアドレスの脱カプセレーターのチェックを強化するために、ゼロUDPチェックサムモードを使用する各LISP-GPEトンネルに異なるIPv6ソースアドレスを使用する場合があります（つまり、同じIPv6ソースアドレスは、同じIPv6ソースアドレスです。その宛先アドレスがユニキャストまたはマルチキャストアドレスであるかどうかに関係なく、複数のIPv6宛先アドレスで使用しないでください。これが不可能な場合は、ゼロUDPチェックサムを使用して実行可能な限り少数のLISP-GPEトンネルに各ソースアドレスを使用することをお勧めします。
5. Measures SHOULD be taken to prevent LISP-GPE traffic over IPv6 with a zero UDP checksum from escaping into the general Internet. Examples of such measures include employing packet filters at the Proxy Egress Tunnel Router (PETR) and/or keeping logical or physical separation of the LISP network from networks in the general Internet.
5. ゼロUDPチェックサムが一般的なインターネットに逃げるのを防ぐために、IPv6を介したLISP-GPEトラフィックを防ぐための対策を講じる必要があります。このような測定の例には、プロキシエグレストンネルルーター（PETR）でパケットフィルターの使用や、一般的なインターネットのネットワークからのLISPネットワークの論理的または物理的な分離を維持することが含まれます。
The above requirements do not change the requirements specified in [RFC6935], [RFC6936], or [RFC8200].
上記の要件は、[RFC6935]、[RFC6936]、または[RFC8200]で指定された要件を変更しません。
The requirement to check the source IPv6 address in addition to the destination IPv6 address, plus the recommendation against the reuse of source IPv6 addresses among LISP-GPE tunnels, collectively provide some mitigation for the absence of UDP checksum coverage of the IPv6 header. A traffic-managed controlled environment that satisfies at least one of the three conditions listed at the beginning of this section provides additional assurance.
宛先IPv6アドレスに加えてソースIPv6アドレスを確認する要件に加えて、LISP-GPEトンネル間のソースIPv6アドレスの再利用に対する推奨事項は、IPv6ヘッダーのUDPチェックサムカバレッジがないための緩和を集合的に提供します。このセクションの冒頭にリストされている3つの条件の少なくとも1つを満たすトラフィック管理された制御環境は、追加の保証を提供します。
When encapsulating IP (including over Ethernet) packets, [RFC2983] provides guidance for mapping packets that contain Differentiated Services Code Point (DSCP) information between inner and outer IP headers. The Pipe model typically fits better with network virtualization. The DSCP value on the tunnel header is set based on a policy (which may be a fixed value, one based on the inner traffic class, or some other mechanism for grouping traffic). Some aspects of the Uniform model (which treats the inner and outer DSCP value as a single field by copying on ingress and egress) may also apply, such as the ability to remark the inner header on tunnel egress based on transit marking. However, the Uniform model is not conceptually consistent with network virtualization, which seeks to provide strong isolation between encapsulated traffic and the physical network.
IPをカプセル化する場合、[Ethernet上の）パケットを含む場合、[RFC2983]は、内側と外側のIPヘッダーの間に差別化されたサービスコードポイント（DSCP）情報を含むマッピングパケットのガイダンスを提供します。パイプモデルは通常、ネットワーク仮想化により適しています。トンネルヘッダーのDSCP値は、ポリシーに基づいて設定されます（これは固定値であり、内部交通クラスに基づいている場合、またはトラフィックをグループ化するためのその他のメカニズムに基づいています）。均一なモデルのいくつかの側面（イングレスと出口でコピーすることにより、内側と外側のDSCP値を単一のフィールドとして扱う）も適用される場合があります。たとえば、トランジットマーキングに基づいてトンネル出口に内側のヘッダーを注目する機能などです。ただし、均一なモデルは、カプセル化されたトラフィックと物理ネットワークの間に強い分離を提供しようとするネットワーク仮想化と概念的に一致していません。
[RFC6040] describes the mechanism for exposing ECN capabilities on IP tunnels and propagating congestion markers to the inner packets. This behavior MUST be followed for IP packets encapsulated in LISP-GPE.
[RFC6040]は、IPトンネルにECN機能を露出させ、輻輳マーカーを内側のパケットに伝播するメカニズムを説明しています。LISP-GPEでカプセル化されたIPパケットでは、この動作に従う必要があります。
Though the Uniform model or the Pipe model could be used for TTL (or Hop Limit in the case of IPv6) handling when tunneling IP packets, the Pipe model is more aligned with network virtualization. [RFC2003] provides guidance on handling TTL between inner IP headers and outer IP tunnels; this model is more aligned with the Pipe model and is recommended for use with LISP-GPE for network-virtualization applications.
均一モデルまたはパイプモデルは、IPパケットをトンネリングするときにTTL（またはIPv6の場合のホップ制限）に使用できますが、パイプモデルはネットワーク仮想化とより整合しています。[RFC2003]は、内側のIPヘッダーと外側のIPトンネル間のTTLの処理に関するガイダンスを提供します。このモデルは、パイプモデルとより整合しており、ネットワーク仮想化アプリケーションにLISP-GPEで使用することをお勧めします。
When a LISP-GPE router performs Ethernet encapsulation, the inner 802.1Q 3-bit Priority Code Point ('PCP') field [IEEE.802.1Q_2014] MAY be mapped from the encapsulated frame to the DSCP codepoint of the Differentiated Services ('DS') field defined in [RFC2474].
LISP-GPEルーターがイーサネットカプセル化を実行すると、内側の802.1Q 3ビット優先コードポイント（ 'PCP'）フィールド[IEEE.802.1Q_2014]は、カプセル化されたフレームから差別化されたサービスのDSCPコードポイントにマッピングできます（ 'DS'）[RFC2474]で定義されたフィールド。
When a LISP-GPE router performs Ethernet encapsulation, the inner-header 802.1Q VLAN Identifier (VID) [IEEE.802.1Q_2014] MAY be mapped to, or used to determine, the LISP 'Instance ID' (IID) field.
LISP-GPEルーターがイーサネットのカプセル化を実行すると、内部ヘッダー802.1Q VLAN識別子（VID）[IEEE.802.1Q_2014]は、LISP 'Instance ID'（IID）フィールドにマッピングまたは決定に使用される場合があります。
Refer to Section 7 for considerations about the use of integrity protection for deployments, such as the public Internet, concerned with on-path attackers.
パス攻撃者に関係するパブリックインターネットなどの展開のための整合性保護の使用に関する考慮事項については、セクション7を参照してください。
LISP-GPE uses the same UDP destination port (4341) allocated to LISP.
LISP-GPEは、LISPに割り当てられた同じUDP宛先ポート（4341）を使用します。
When encapsulating IP packets to a non-LISP-GPE-capable router, the P-bit MUST be set to 0. That is, the encapsulation format defined in this document MUST NOT be sent to a router that has not indicated that it supports this specification, because such a router would ignore the P-bit (as described in [RFC9300]) and so would misinterpret the other LISP header fields, possibly causing significant errors.
IPパケットを非リスプ-GPE対応ルーターにカプセル化する場合、Pビットは0に設定する必要があります。つまり、このドキュメントで定義されているカプセル化形式は、これをサポートすることを示すことを示すものではありません。仕様は、そのようなルーターがPビットを無視する（[RFC9300]で説明されている）ため、他のLISPヘッダーフィールドを誤って解釈し、おそらく大きなエラーを引き起こす可能性があるためです。
The discovery of xTR capabilities to support LISP-GPE is out of the scope of this document. Given that the applicability domain of LISP-GPE is a traffic-managed controlled environment, ITR/ETR (xTR) configuration mechanisms may be used for this purpose.
LISP-GPEをサポートするXTR機能の発見は、このドキュメントの範囲外です。LISP-GPEの適用可能性ドメインがトラフィック管理された制御環境であることを考えると、この目的にはITR/ETR（XTR）構成メカニズムが使用される場合があります。
IANA has created a registry called "LISP-GPE Next Protocol". These are 8-bit values. Next Protocol values in the table below are defined in this document. New values are assigned under the Specification Required policy [RFC8126]. The protocols that are being assigned values do not themselves need to be IETF Standards Track protocols.
IANAは、「LISP-GPE Next Protocol」というレジストリを作成しました。これらは8ビット値です。次のテーブルの次のプロトコル値は、このドキュメントで定義されています。新しい値は、必要なポリシー[RFC8126]に基づいて割り当てられます。値が割り当てられているプロトコル自体は、IETF標準を追跡する必要はありません。
+===============+=============================+===========+
| Next Protocol | Description | Reference |
+===============+=============================+===========+
| 0x00 | Reserved | RFC 9305 |
+---------------+-----------------------------+-----------+
| 0x01 | IPv4 | RFC 9305 |
+---------------+-----------------------------+-----------+
| 0x02 | IPv6 | RFC 9305 |
+---------------+-----------------------------+-----------+
| 0x03 | Ethernet | RFC 9305 |
+---------------+-----------------------------+-----------+
| 0x04 | NSH | RFC 9305 |
+---------------+-----------------------------+-----------+
| 0x05-0x7D | Unassigned | |
+---------------+-----------------------------+-----------+
| 0x7E-0x7F | Experimentation and testing | RFC 9305 |
+---------------+-----------------------------+-----------+
| 0x80-0xFD | Unassigned (shim headers) | |
+---------------+-----------------------------+-----------+
| 0xFE-0xFF | Experimentation and testing | RFC 9305 |
| | (shim headers) | |
+---------------+-----------------------------+-----------+
Table 1
表1
LISP-GPE security considerations are similar to the LISP security considerations and mitigation techniques documented in [RFC7835].
LISP-GPEセキュリティの考慮事項は、[RFC7835]に記録されているLISPセキュリティの考慮事項と緩和手法に似ています。
As is the case for many encapsulations that use optional extensions, LISP-GPE is subject to on-path adversaries that can make arbitrary modifications to the packet (including the P-bit) to change or remove any part of the payload, or claim to encapsulate any protocol payload type. Typical integrity protection mechanisms (such as IPsec) SHOULD be used in combination with LISP-GPE by those protocol extensions that want to protect against on-path attackers.
オプションの拡張機能を使用する多くのカプセルの場合と同様に、LISP-GPEは、パケット（Pビットを含む）に任意の変更を加えてペイロードの一部を変更または削除するか、主張することができるパス敵の対象となります。プロトコルペイロードタイプをカプセル化します。典型的な整合性保護メカニズム（IPSECなど）は、オンパス攻撃者から保護したいプロトコル拡張機能によって、LISP-GPEと組み合わせて使用する必要があります。
With LISP-GPE, issues such as data plane spoofing, flooding, and traffic redirection may depend on the particular protocol payload encapsulated.
LISP-GPEでは、データプレーンのスプーフィング、洪水、トラフィックリダイレクトなどの問題は、カプセル化された特定のプロトコルペイロードに依存する可能性があります。
[IEEE.802.1Q_2014] IEEE, "IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks", IEEE Std 802.1Q-2014, December 2014, <https://ieeexplore.ieee.org/document/6991462>.
[IEEE.802.1Q_2014] IEEE、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準 - ブリッジおよびブリッジネットワーク」、IEEE STD 802.1Q-2014、2014年12月、<https://ieeexplore.ieeee.org/document/69999162>。
[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>。
[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>
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos, Ed., "The Locator/ID Separation Protocol (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022, <https://www.rfc-editor.org/info/rfc9300>.
[RFC9300] Farinacci、D.、Fuller、V.、Meyer、D.、Lewis、D.、およびA. Cabellos、ed。、「ロケーター/ID分離プロトコル（LISP）」、RFC 9300、DOI 10.17487/RFC9300、2022年10月、<https://www.rfc-editor.org/info/rfc9300>。
[ENCAP-GUIDE] Briscoe, B. and J. Kaippallimalil, "Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP", Work in Progress, Internet-Draft, draft-ietf-tsvwg-ecn-encap-guidelines-17, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines-17>.
[Encap-Guide] Briscoe、B。and J. Kaippallimalil、「IPをカプセル化するプロトコルに混雑通知を追加するためのガイドライン」、進行中の作業、インターネットドラフト、ドラフト-TSVWG-ECN-ENCAP-GUIDERINES-17、11 112022年7月、<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines-17>。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, DOI 10.17487/RFC2003, October 1996, <https://www.rfc-editor.org/info/rfc2003>.
[RFC2003] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、DOI 10.17487/RFC2003、1996年10月、<https://www.rfc-editor.org/info/rfc2003>。
[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>。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、DOI 10.17487/RFC3168、2001年9月、<https：// www。rfc-editor.org/info/rfc3168>。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, DOI 10.17487/RFC3692, January 2004, <https://www.rfc-editor.org/info/rfc3692>.
[RFC3692] Narten、T。、「有用と見なされる実験数とテスト数の割り当て」、BCP 82、RFC 3692、DOI 10.17487/RFC3692、2004年1月、<https://www.rfc-editor.org/info/rfc3692>
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/RFC6935, April 2013, <https://www.rfc-editor.org/info/rfc6935>.
[RFC6935] Eubanks、M.、Chimento、P。、およびM. Westerlund、「トンネルパケットのIPv6およびUDPチェックサム」、RFC 6935、DOI 10.17487/RFC6935、2013年4月、<https：//www.rfc-editor。org/info/rfc6935>。
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, <https://www.rfc-editor.org/info/rfc6936>.
[RFC6936] Fairhurst、G。およびM. Westerlund、「チェックサムを備えたIPv6 UDPデータグラムの使用に関するアプリケーションステートメント」、RFC 6936、DOI 10.17487/RFC6936、2013年4月、<https://www.rfc-editor.org/info/rfc6936>。
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, <https://www.rfc-editor.org/info/rfc7348>.
[RFC7348] Mahalingam、M.、Dutt、D.、Duda、K.、Agarwal、P.、Kreeger、L.、Sridhar、T.、Bursell、M。、およびC. Wright、「仮想拡張可能なローカルエリアネットワーク（VXLAN）：仮想化されたレイヤー2ネットワークを重ねるためのフレームワーク3ネットワーク "、RFC 7348、DOI 10.17487/RFC7348、2014年8月、<https://www.rfc-editor.org/info/rfc7348>
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Threat Analysis", RFC 7835, DOI 10.17487/RFC7835, April 2016, <https://www.rfc-editor.org/info/rfc7835>.
[RFC7835] Saucez、D.、Iannone、L。、およびO. Bonaventure、「ロケーター/ID分離プロトコル（LISP）脅威分析」、RFC 7835、DOI 10.17487/RFC7835、2016年4月、<https：//ww.rfc-editor.org/info/rfc7835>。
[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>。
[RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE-in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, March 2017, <https://www.rfc-editor.org/info/rfc8086>.
[RFC8086] Yong、L.、ed。、ed。、Crabbe、E.、Xu、X.、およびT. Herbert、「Gre-in-udp capsulation」、RFC 8086、doi 10.17487/rfc8086、2017年3月、<https：//www.rfc-editor.org/info/rfc8086>。
[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>。
[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>。
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, <https://www.rfc-editor.org/info/rfc8300>.
[RFC8300] Quinn、P.、Ed。、Elzur、U.、ed。、およびC. Pignataro、ed。、「Network Service Header（NSH）」、RFC 8300、DOI 10.17487/RFC8300、2018年1月、<https：//www.rfc-editor.org/info/rfc8300>。
[VXLAN-GPE] Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., Lapukhov, P., and M. Spiegel, "VXLAN-GPE Encapsulation for In-situ OAM Data", Work in Progress, Internet-Draft, draft-brockners-ippm-ioam-vxlan-gpe-03, 4 November 2019, <https://datatracker.ietf.org/doc/html/ draft-brockners-ippm-ioam-vxlan-gpe-03>.
[Vxlan-gpe]ブロックナー、F。、バンダリ、S。、ゴビンダン、V。、ピグナタロ、C。、グレドラー、H。、レディ、J。、ユーエル、S。、ミズラヒ、T。、Kfir、A。、Gafni、B.、Lapukhov、P。、およびM. Spiegel、「in-situ oamデータのVxlan-gpeカプセル化」、進行中の作業、インターネットドラフト、ドラフトドラフト、IPPM-IOAM-VXLAN-GPE-03、2019年11月4日、<https://datatracker.ietf.org/doc/html/ draft-brockners-ippm-ioam-vxlan-gpe-03>。
[VXLAN-LISP] Lemon, J., Ed., Maino, F., Smith, M., and A. Isaac, "Group Policy Encoding with VXLAN-GPE and LISP-GPE", Work in Progress, Internet-Draft, draft-lemon-vxlan-lisp-gpe-gbp-02, 30 April 2019, <https://datatracker.ietf.org/doc/html/ draft-lemon-vxlan-lisp-gpe-gbp-02>.
[VXLAN-LISP] Lemon、J.、ed。、Maino、F.、Smith、M。、およびA. Isaac、「VXLAN-GPEおよびLISP-GPEでエンコードするグループポリシー」、Work in Progress、Internet-Draft、ドラフトレモン-vxlan-lisp-gpe-gbp-02、2019年4月30日、<https://datatracker.ietf.org/doc/html/ draft-lemon-vxlan-lisp-gpe-gbp-02>。
Acknowledgments
謝辞
A special thank you goes to Dino Farinacci for his guidance and detailed review. Thanks to Tom Herbert for the suggestion to assign codepoints for experimentations and testing.
彼の指導と詳細なレビューについて、Dino Farinacciに特別な感謝を捧げます。実験とテストのためにコードポイントを割り当てるための提案をしてくれたTom Herbertに感謝します。
Contributors
貢献者
The editor of this document would like to thank and recognize the following coauthors and contributors for their contributions. These coauthors and contributors provided invaluable concepts and content for this document's creation.
このドキュメントの編集者は、次の共著者と貢献者の貢献について感謝し、認識したいと考えています。これらの共著者と貢献者は、このドキュメントの作成に対して非常に貴重な概念とコンテンツを提供しました。
Darrel Lewis Cisco Systems, Inc.
Darrel Lewis Cisco Systems、Inc。
Fabio Maino Cisco Systems, Inc.
Fabio Maino Cisco Systems、Inc。
Paul Quinn Cisco Systems, Inc.
Paul Quinn Cisco Systems、Inc。
Michael Smith Cisco Systems, Inc.
Michael Smith Cisco Systems、Inc。
Navindra Yadav Cisco Systems, Inc.
Navindra Yadav Cisco Systems、Inc。
Larry Kreeger
ラリー・クリーガー
Jennifer Lemon Broadcom
ジェニファーレモンブロードコム
Puneet Agarwal Innovium
Puneet Agarwal Innovium
Authors' Addresses
著者のアドレス
Fabio Maino (editor) Cisco Systems San Jose, CA United States of America Email: fmaino@cisco.com
Fabio Maino（編集者）Cisco Systems San Jose、CA Neciment States of America Email：fmaino@cisco.com
Jennifer Lemon Email: jalemon@meus.us
ジェニファーレモンメール：jalemon@meus.us
Puneet Agarwal Innovium United States of America Email: puneet@acm.org
Puneet Agarwal Innovium United States of America Email：Puneet@acm.org
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
Michael Smith Cisco Systems San Jose, CA 95134 United States of America Email: michsmit@cisco.com
マイケルスミスシスコシステムサンノゼ、カリフォルニア95134アメリカ合衆国電子メール：michsmit@cisco.com