[要約] RFC 8926はGeneve（Generic Network Virtualization Encapsulation）に関する技術仕様です。このプロトコルの目的は、異なるネットワーク仮想化技術間での柔軟な相互運用性を提供することにあります。利用場面としては、データセンター内のマルチテナント環境、クラウドサービスの提供、および複数のネットワーク技術を統合するシナリオが挙げられます。
Internet Engineering Task Force (IETF) J. Gross, Ed.
Request for Comments: 8926
Category: Standards Track I. Ganga, Ed.
ISSN: 2070-1721 Intel
T. Sridhar, Ed.
VMware
November 2020
Geneve: Generic Network Virtualization Encapsulation
Geneve：一般的なネットワーク仮想化カプセル化
Abstract
概要
Network virtualization involves the cooperation of devices with a wide variety of capabilities such as software and hardware tunnel endpoints, transit fabrics, and centralized control clusters. As a result of their role in tying together different elements of the system, the requirements on tunnels are influenced by all of these components. Therefore, flexibility is the most important aspect of a tunneling protocol if it is to keep pace with the evolution of technology. This document describes Geneve, an encapsulation protocol designed to recognize and accommodate these changing capabilities and needs.
ネットワーク仮想化は、ソフトウェアおよびハードウェアトンネルエンドポイント、トランジットファブリック、および集中管理クラスタなどのさまざまな機能を持つデバイスの協力を含みます。システムのさまざまな要素をまとめることにおけるそれらの役割の結果として、トンネルに関する要件はこれらすべてのコンポーネントによって影響されます。したがって、柔軟性は、テクノロジの進化とペースを維持することであれば、トンネリングプロトコルの最も重要な側面です。この文書では、これらの変更機能とニーズを認識し、対応するように設計されたカプセル化プロトコルであるGeneveについて説明します。
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/rfc8926.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc8926で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Requirements Language
1.2. Terminology
2. Design Requirements
2.1. Control Plane Independence
2.2. Data Plane Extensibility
2.2.1. Efficient Implementation
2.3. Use of Standard IP Fabrics
3. Geneve Encapsulation Details
3.1. Geneve Packet Format over IPv4
3.2. Geneve Packet Format over IPv6
3.3. UDP Header
3.4. Tunnel Header Fields
3.5. Tunnel Options
3.5.1. Options Processing
4. Implementation and Deployment Considerations
4.1. Applicability Statement
4.2. Congestion-Control Functionality
4.3. UDP Checksum
4.3.1. Zero UDP Checksum Handling with IPv6
4.4. Encapsulation of Geneve in IP
4.4.1. IP Fragmentation
4.4.2. DSCP, ECN, and TTL
4.4.3. Broadcast and Multicast
4.4.4. Unidirectional Tunnels
4.5. Constraints on Protocol Features
4.5.1. Constraints on Options
4.6. NIC Offloads
4.7. Inner VLAN Handling
5. Transition Considerations
6. Security Considerations
6.1. Data Confidentiality
6.1.1. Inter-Data Center Traffic
6.2. Data Integrity
6.3. Authentication of NVE Peers
6.4. Options Interpretation by Transit Devices
6.5. Multicast/Broadcast
6.6. Control Plane Communications
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
Networking has long featured a variety of tunneling, tagging, and other encapsulation mechanisms. However, the advent of network virtualization has caused a surge of renewed interest and a corresponding increase in the introduction of new protocols. The large number of protocols in this space -- for example, ranging all the way from VLANs [IEEE.802.1Q_2018] and MPLS [RFC3031] through the more recent VXLAN (Virtual eXtensible Local Area Network) [RFC7348] and NVGRE (Network Virtualization Using Generic Routing Encapsulation) [RFC7637] -- often leads to questions about the need for new encapsulation formats and what it is about network virtualization in particular that leads to their proliferation. Note that the list of protocols presented above is non-exhaustive.
ネットワーキングは長い間、さまざまなトンネリング、タグ付け、およびその他のカプセル化メカニズムを特徴としています。しかしながら、ネットワーク仮想化の出現により、新たな興味の急増と、新しいプロトコルの導入が対応する。このスペース内の多数のプロトコルは、例えば、最新のVXLAN（Virtual Extensible Local Area Network）[RFC7348]とNVGREを介してVLAN [IEEE.802.1Q_2018]とMPLS [RFC3031]からすべての方法を挙げています。汎用ルーティングカプセル化を使用すると、「RFC7637」 - 多くの場合、新しいカプセル化フォーマットの必要性についての質問があり、特にそれらの拡散につながるネットワーク仮想化についてのものです。上記のプロトコルのリストは網羅的ではないことに注意してください。
While many encapsulation protocols seek to simply partition the underlay network or bridge two domains, network virtualization views the transit network as providing connectivity between multiple components of a distributed system. In many ways, this system is similar to a chassis switch with the IP underlay network playing the role of the backplane and tunnel endpoints on the edge as line cards. When viewed in this light, the requirements placed on the tunneling protocol are significantly different in terms of the quantity of metadata necessary and the role of transit nodes.
多くのカプセル化プロトコルは、インダーラインネットワークまたはブリッジ2つのドメインを単純に分割しようとしているが、ネットワーク仮想化は、分散システムの複数のコンポーネント間の接続性を提供するためにトランストネットワークを表示します。多くの点で、このシステムは、IPアンダーレイネットワークがバックプレーンの役割を再生したシャーシスイッチと似ています。ラインカードとしてのエッジ上のトンネルエンドポイント。この光で見ると、トンネリングプロトコルに配置されている要件は、必要なメタデータの数量とトランジットノードの役割の点で大きく異なります。
Work such as "VL2: A Scalable and Flexible Data Center Network" [VL2] and "NVO3 Data Plane Requirements" [NVO3-DATAPLANE] have described some of the properties that the data plane must have to support network virtualization. However, one additional defining requirement is the need to carry metadata (e.g., system state) along with the packet data; example use cases of metadata are noted below. The use of some metadata is certainly not a foreign concept -- nearly all protocols used for network virtualization have at least 24 bits of identifier space as a way to partition between tenants. This is often described as overcoming the limits of 12-bit VLANs; when seen in that context or any context where it is a true tenant identifier, 16 million possible entries is a large number. However, the reality is that the metadata is not exclusively used to identify tenants, and encoding other information quickly starts to crowd the space. In fact, when compared to the tags used to exchange metadata between line cards on a chassis switch, 24-bit identifiers start to look quite small. There are nearly endless uses for this metadata, ranging from storing input port identifiers for simple security policies to sending service-based context for advanced middlebox applications that terminate and re-encapsulate Geneve traffic.
「VL2：スケーラブルで柔軟なデータセンターネットワーク「[VL2]と「NVO3データプレーン要件」などの作業[NVO3データプレーン]は、データプレーンがネットワーク仮想化をサポートしなければならないプロパティのいくつかについて説明しました。しかしながら、1つの追加の定義要件は、パケットデータと共にメタデータ（例えばシステム状態）を搬送する必要性である。メタデータの使用例は以下の通りです。いくつかのメタデータの使用は確かに外国の概念ではありません - ネットワーク仮想化に使用されるすべてのプロトコルは、テナント間を分割する方法として少なくとも24ビットの識別子スペースを持っています。これは、12ビットVLANの制限を克服するとしばしば記述されます。その文脈に見られるとき、またはそれが本当のテナント識別子である文脈で見られるとき、1600万人の可能なエントリは大きな数です。ただし、実際には、メタデータがテナントを識別するために排他的に使用されず、他の情報を求めることは迅速にスペースを調べ始めます。実際、シャーシスイッチのラインカード間のメタデータを交換するために使用されるタグと比較した場合、24ビット識別子はかなり小さいを見始めます。このメタデータにはほとんど無限の用途があり、入力ポート識別子を保存するのが簡単なセキュリティポリシーを保存して、GENEVEトラフィックを終了して再カプセル化する高度なミドルボックスアプリケーションのサービスベースのコンテキストを送信します。
Existing tunneling protocols have each attempted to solve different aspects of these new requirements only to be quickly rendered out of date by changing control plane implementations and advancements. Furthermore, software and hardware components and controllers all have different advantages and rates of evolution -- a fact that should be viewed as a benefit, not a liability or limitation. This document describes Geneve, a protocol that seeks to avoid these problems by providing a framework for tunneling for network virtualization rather than being prescriptive about the entire system.
既存のトンネリングプロトコルは、それぞれがこれらの新しい要件のさまざまな側面を解決しようとしました。制御面の実装や進歩を変更することによって、日付から迅速にレンダリングされるのにのみ述べました。さらに、ソフトウェアおよびハードウェアのコンポーネントおよびコントローラはすべて異なる利点と進化率を持っています - 責任または制限ではなく利益として見られるべき事実。このドキュメントでは、システム全体についての規範的ではなく、ネットワーク仮想化のためのトンネリングのためのフレームワークを提供することによって、これらの問題を回避することを目的としたGeneeveです。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
The Network Virtualization over Layer 3 (NVO3) Framework [RFC7365] defines many of the concepts commonly used in network virtualization. In addition, the following terms are specifically meaningful in this document:
Layer 3（NVO3）フレームワーク[RFC7365]のネットワーク仮想化[RFC7365]は、ネットワーク仮想化で一般的に使用されている多くの概念を定義しています。さらに、次の条項はこの文書に特に意味があります。
Checksum offload: An optimization implemented by many NICs (Network Interface Controllers) that enables computation and verification of upper-layer protocol checksums in hardware on transmit and receive, respectively. This typically includes IP and TCP/UDP checksums that would otherwise be computed by the protocol stack in software.
チェックサムオフロード：送信および受信時のハードウェア内の上位レイヤプロトコルチェックサムの計算と検証をそれぞれ有効にする多くのNIC（ネットワークインタフェースコントローラ）によって実装された最適化。これは通常、そうでなければソフトウェアのプロトコルスタックによって計算されるであろうIPおよびTCP / UDPチェックサムを含む。
Clos network: A technique for composing network fabrics larger than a single switch while maintaining non-blocking bandwidth across connection points. ECMP is used to divide traffic across the multiple links and switches that constitute the fabric. Sometimes termed "leaf and spine" or "fat tree" topologies.
Clos Network：接続点間でノンブロッキング帯域幅を維持しながら、単一スイッチよりも大きいネットワークファブリックを構成するための技術。ECMPは、ファブリックを構成する複数のリンクとスイッチを横切ってトラフィックを分割するために使用されます。「葉と背骨」または「FATツリー」のトポロジと呼ばれることもあります。
ECMP: Equal Cost Multipath. A routing mechanism for selecting from among multiple best next-hop paths by hashing packet headers in order to better utilize network bandwidth while avoiding reordering of packets within a flow.
ECMP：等価コストマルチパス。フロー内のパケットの並び替えを回避しながら、ネットワーク帯域幅をより適切に利用するために、パケットヘッダをハッシュすることによって複数の最良のネクストホップ経路の中から選択するためのルーティングメカニズム。
Geneve: Generic Network Virtualization Encapsulation. The tunneling protocol described in this document.
Geneve：一般的なネットワーク仮想化カプセル化この文書に記載されているトンネリングプロトコル。
LRO: Large Receive Offload. The receiver-side equivalent function of LSO, in which multiple protocol segments (primarily TCP) are coalesced into larger data units.
LRO：大きい受信オフロード。複数のプロトコルセグメント（主にTCP）がより大きなデータユニットに合体するLSOの受信側の等価機能。
LSO: Large Segmentation Offload. A function provided by many commercial NICs that allows data units larger than the MTU to be passed to the NIC to improve performance, the NIC being responsible for creating smaller segments of a size less than or equal to the MTU with correct protocol headers. When referring specifically to TCP/IP, this feature is often known as TSO (TCP Segmentation Offload).
LSO：大きなセグメンテーションオフロード。パフォーマンスを向上させるためにMTUよりも大きいデータユニットをNICに渡すことを可能にする多くのコマーシャルNICによって提供される関数は、正しいプロトコルヘッダーを持つMTU以下のサイズの小さいセグメントを作成する責任があります。特にTCP / IPを参照すると、この機能はよくTSO（TCPセグメンテーションオフロード）として知られています。
Middlebox: In the context of this document, the term "middlebox" refers to network service functions or service interposition appliances that typically implement tunnel endpoint functionality, terminating and re-encapsulating Geneve traffic.
ミドルボックス：この文書のコンテキストでは、「ミドルボックス」という用語は、通常、トンネルエンドポイント機能を実装し、GENEVEトラフィックを終了して再カプセル化するネットワークサービス機能またはサービスインターポジションアプライアンスを指します。
NIC: Network Interface Controller. Also called "Network Interface Card" or "Network Adapter". A NIC could be part of a tunnel endpoint or transit device and can either process or aid in the processing of Geneve packets.
NIC：ネットワークインタフェースコントローラ。「ネットワークインタフェースカード」または「ネットワークアダプタ」とも呼ばれます。NICは、トンネルエンドポイントまたはトランジットデバイスの一部であり得、そしてGENEVEパケットの処理をプロセスまたは援助することができます。
Transit device: A forwarding element (e.g., router or switch) along the path of the tunnel making up part of the underlay network. A transit device may be capable of understanding the Geneve packet format but does not originate or terminate Geneve packets.
トランジットデバイス：アンダーレイネットワークの一部を構成するトンネルの経路に沿った転送要素（例えば、ルータまたはスイッチ）。トランジット装置は、GENEVEパケットフォーマットを理解することができるが、GENEVEパケットを起動または終了することはできない。
Tunnel endpoint: A component performing encapsulation and decapsulation of packets, such as Ethernet frames or IP datagrams, in Geneve headers. As the ultimate consumer of any tunnel metadata, tunnel endpoints have the highest level of requirements for parsing and interpreting tunnel headers. Tunnel endpoints may consist of either software or hardware implementations or a combination of the two. Tunnel endpoints are frequently a component of a Network Virtualization Edge (NVE) but may also be found in middleboxes or other elements making up an NVO3 network.
トンネルエンドポイント：GENEVEヘッダのイーサネットフレームやIPデータグラムなどのパケットのカプセル化とカプセル化を実行するコンポーネント。トンネルメタデータの究極の消費者として、トンネルエンドポイントはトンネルヘッダの解析および解釈のための最高レベルの要件を有する。トンネルエンドポイントは、ソフトウェアまたはハードウェアの実装または2つの組み合わせで構成されている可能性があります。トンネルエンドポイントは、ネットワーク仮想化エッジ（NVE）のコンポーネントですが、ミドルボックスまたはNVO3ネットワークを構成する他の要素にもあります。
VM: Virtual Machine.
VM：仮想マシン。
Geneve is designed to support network virtualization use cases for data center environments. In these situations, tunnels are typically established to act as a backplane between the virtual switches residing in hypervisors, physical switches, or middleboxes or other appliances. An arbitrary IP network can be used as an underlay, although Clos networks composed using ECMP links are a common choice to provide consistent bisectional bandwidth across all connection points. Many of the concepts of network virtualization overlays over IP networks are described in the NVO3 Framework [RFC7365]. Figure 1 shows an example of a hypervisor, a top-of-rack switch for connectivity to physical servers, and a WAN uplink connected using Geneve tunnels over a simplified Clos network. These tunnels are used to encapsulate and forward frames from the attached components, such as VMs or physical links.
Geneveは、データセンター環境のネットワーク仮想化ユースケースをサポートするように設計されています。このような状況では、トンネルは通常、ハイパーバイザー、物理スイッチ、またはミドルボックス、または他のアプライアンスに存在する仮想スイッチ間のバックプレーンとして機能するように設定されています。任意のIPネットワークをアンダーレイとして使用することができますが、ECMPリンクを使用して構成されるClos Networkは、すべての接続ポイントにわたって一貫した二断面帯域幅を提供するための一般的な選択です。IPネットワークを介したネットワーク仮想化オーバーレイの概念の多くは、NVO3フレームワーク[RFC7365]に記載されています。図1は、ハイパーバイザの例、物理サーバへの接続のためのラックトップスイッチ、および単純化されたClosネットワーク上でGeneveトンネルを使用して接続されたWANアップリンクの例を示しています。これらのトンネルは、VMや物理リンクなどの添付のコンポーネントからフレームをカプセル化して転送するために使用されます。
+---------------------+ +-------+ +------+
| +--+ +-------+---+ | |Transit|--|Top of|==Physical
| |VM|--| | | | +------+ /|Router | | Rack |==Servers
| +--+ |Virtual|NIC|---|Top of|/ +-------+\/+------+
| +--+ |Switch | | | | Rack |\ +-------+/\+------+
| |VM|--| | | | +------+ \|Transit| |Uplink| WAN
| +--+ +-------+---+ | |Router |--| |=========>
+---------------------+ +-------+ +------+
Hypervisor
()===================================()
Switch-Switch Geneve Tunnels
Figure 1: Sample Geneve Deployment
図1：Geneveの展開のサンプル
To support the needs of network virtualization, the tunneling protocol should be able to take advantage of the differing (and evolving) capabilities of each type of device in both the underlay and overlay networks. This results in the following requirements being placed on the data plane tunneling protocol:
ネットワーク仮想化のニーズをサポートするために、トンネリングプロトコルは、アンダーレイネットワークとオーバーレイネットワークの両方で各タイプのデバイスの異なる（および進化する）機能を利用することができるはずです。これにより、データプレーントンネリングプロトコルには次の要件があります。
* The data plane is generic and extensible enough to support current and future control planes.
* データプレーンは、現在および将来の制御プレーンをサポートするのに十分な一般的で拡張可能です。
* Tunnel components are efficiently implementable in both hardware and software without restricting capabilities to the lowest common denominator.
* トンネルコンポーネントは、最も低い共通の分母に対する機能を制限することなく、ハードウェアとソフトウェアの両方で効率的に実装可能です。
* High performance over existing IP fabrics is maintained.
* 既存のIPファブリックに対する高性能が維持されています。
These requirements are described further in the following subsections.
これらの要件は、以下のサブセクションでさらに説明されています。
Although some protocols for network virtualization have included a control plane as part of the tunnel format specification (most notably, VXLAN [RFC7348] prescribed a multicast-learning-based control plane), these specifications have largely been treated as describing only the data format. The VXLAN packet format has actually seen a wide variety of control planes built on top of it.
ネットワーク仮想化のためのプロトコルの中には、トンネルフォーマット仕様の一部として制御プレーンが含まれていますが（最も特にVXLAN [RFC7348]はマルチキャスト学習ベースのコントロールプレーンを規定しています）、これらの仕様は大部分はデータフォーマットのみを記述するものとして扱われています。VXLANパケットフォーマットは、実際にはその上に構築された多種多様な制御プレーンを見ています。
There is a clear advantage in settling on a data format: most of the protocols are only superficially different and there is little advantage in duplicating effort. However, the same cannot be said of control planes, which are diverse in very fundamental ways. The case for standardization is also less clear given the wide variety in requirements, goals, and deployment scenarios.
データフォーマットに解決するためには明確な利点があります。ほとんどのプロトコルは表面的に異なるしかありません。しかしながら、同じことは、非常に基本的な方法で多様なコントロールプレーンについて言及することはできません。標準化のためのケースもまた、要件、目標、および展開シナリオの多様にさまざまな種類が与えられます。
As a result of this reality, Geneve is a pure tunnel format specification that is capable of fulfilling the needs of many control planes by explicitly not selecting any one of them. This simultaneously promotes a shared data format and reduces the chance of obsolescence by future control plane enhancements.
この現実の結果として、Geneeveは、それらのいずれかを明示的に選択しないことによって、多くの制御プレーンのニーズを満たすことができる純粋なトンネルフォーマット仕様です。これは同時に共有データフォーマットを促進し、将来の制御プレーンの機能強化による陳腐化の可能性を低減します。
Achieving the level of flexibility needed to support current and future control planes effectively requires an options infrastructure to allow new metadata types to be defined, deployed, and either finalized or retired. Options also allow for differentiation of products by encouraging independent development in each vendor's core specialty, leading to an overall faster pace of advancement. By far, the most common mechanism for implementing options is the Type-Length-Value (TLV) format.
現在および将来の管理計画をサポートするのに必要な柔軟性のレベルを達成することは、新しいメタデータ型を定義、展開、および退会することを可能にするためにオプションインフラストラクチャを効果的に必要とします。オプションはまた、各ベンダーの中核専門における独立した開発を奨励することによって製品の差別化を可能にし、全体的な進歩のペースをもたらします。これまでに、オプションを実装するための最も一般的なメカニズムはType-Length-Value（TLV）形式です。
It should be noted that, while options can be used to support non-wirespeed control packets, they are equally important in data packets as well for segregating and directing forwarding. (For instance, the examples given before regarding input-port-based security policies and terminating/re-encapsulating service interposition both require tags to be placed on data packets.) Therefore, while it would be desirable to limit the extensibility to only control packets for the purposes of simplifying the datapath, that would not satisfy the design requirements.
なお、オプションを使用しないようにオプションを使用することができますが、データパケットでも同様に、転送と転送を指示するために同様に重要です。（たとえば、入力ポートベースのセキュリティポリシーに関して与えられた例は、サービス介入の終了/再カプセル化されているサービス介入の両方で、データパケットに配置されるタグを必要とします。したがって、制御パケットのみに拡張性を制限することが望ましいデータパスを単純化する目的で、それは設計要件を満たさないでしょう。
There is often a conflict between software flexibility and hardware performance that is difficult to resolve. For a given set of functionality, it is obviously desirable to maximize performance. However, that does not mean new features that cannot be run at a desired speed today should be disallowed. Therefore, for a protocol to be considered efficiently implementable, it is expected to have a set of common capabilities that can be reasonably handled across platforms as well as a graceful mechanism to handle more advanced features in the appropriate situations.
解決するのが難しいソフトウェアの柔軟性とハードウェアのパフォーマンスとの間には、しばしば矛盾があります。特定の機能セットの場合、パフォーマンスを最大化することは明らかに望ましいです。ただし、今日の希望の速度で実行できない新機能を意味するわけではありません。したがって、プロトコルが効率的に実装可能であると見なされるためには、適切な状況でより高度な機能を処理するための優雅なメカニズムと同様に、プラットフォーム間で合理的に処理される可能性がある一連の共通の機能を持つことが期待されています。
The use of a variable-length header and options in a protocol often raises questions about whether the protocol is truly efficiently implementable in hardware. To answer this question in the context of Geneve, it is important to first divide "hardware" into two categories: tunnel endpoints and transit devices.
プロトコル内の可変長ヘッダおよびオプションの使用は、プロトコルがハードウェアで本当に効率的に実装可能かどうかについての質問を提起することが多い。Geneveのコンテキストでこの質問に答えるには、「ハードウェア」を2つのカテゴリに分割することが重要です。トンネルエンドポイントとトランジットデバイス。
Tunnel endpoints must be able to parse the variable-length header, including any options, and take action. Since these devices are actively participating in the protocol, they are the most affected by Geneve. However, as tunnel endpoints are the ultimate consumers of the data, transmitters can tailor their output to the capabilities of the recipient.
トンネルエンドポイントは、オプションを含め、可変長ヘッダーを変更してアクションを実行できなければなりません。これらの装置は積極的にプロトコルに参加しているので、それらはGeneveの中で最も影響を受ける。しかしながら、トンネルエンドポイントがデータの最終的な消費者であるので、送信機はそれらの出力を受信者の機能に調整することができる。
Transit devices may be able to interpret the options; however, as non-terminating devices, transit devices do not originate or terminate the Geneve packet. Hence, they MUST NOT modify Geneve headers and MUST NOT insert or delete options, as that is the responsibility of tunnel endpoints. Options, if present in the packet, MUST only be generated and terminated by tunnel endpoints. The participation of transit devices in interpreting options is OPTIONAL.
トランジットデバイスはオプションを解釈できる可能性があります。ただし、非停止デバイスとして、トランジットデバイスはGENEVEパケットを起動または終了しません。したがって、それらはGENEVEヘッダを変更してはならず、それがトンネルエンドポイントの責任であるため、オプションを挿入または削除しないでください。パケットに存在する場合は、トンネルエンドポイントでのみ発生して終了する必要があります。解釈オプションにおけるトランジットデバイスの参加はオプションです。
Further, either tunnel endpoints or transit devices MAY use offload capabilities of NICs, such as checksum offload, to improve the performance of Geneve packet processing. The presence of a Geneve variable-length header should not prevent the tunnel endpoints and transit devices from using such offload capabilities.
さらに、トンネルエンドポイントまたはトランジットデバイスのいずれかは、CheckSum OffloadなどのNICのオフロード機能を使用して、GENEVEパケット処理のパフォーマンスを向上させることができます。GENEVE可変長ヘッダーの存在は、トンネルエンドポイントおよびトランジットデバイスがそのようなオフロード機能を使用するのを妨げるべきではありません。
IP has clearly cemented its place as the dominant transport mechanism, and many techniques have evolved over time to make it robust, efficient, and inexpensive. As a result, it is natural to use IP fabrics as a transit network for Geneve. Fortunately, the use of IP encapsulation and addressing is enough to achieve the primary goal of delivering packets to the correct point in the network through standard switching and routing.
IPは、支配的な輸送機構としてのその場所を明確に接合し、そしてそれを堅牢で効率的でそして安価にするために多くの技術が時間の経過とともに進化してきた。その結果、GENEVE用のトランジットネットワークとしてIPファブリックを使用することは自然です。幸いなことに、IPカプセル化とアドレス指定の使用は、標準的な切り替えおよびルーティングを通じてネットワーク内の正しい点にパケットを配信するという主な目標を達成するのに十分です。
In addition, nearly all underlay fabrics are designed to exploit parallelism in traffic to spread load across multiple links without introducing reordering in individual flows. These ECMP techniques typically involve parsing and hashing the addresses and port numbers from the packet to select an outgoing link. However, the use of tunnels often results in poor ECMP performance, as without additional knowledge of the protocol, the encapsulated traffic is hidden from the fabric by design, and only tunnel endpoint addresses are available for hashing.
さらに、ほとんどすべてのアンダーレイファブリックは、個々のフローに並べ替えを導入することなく、複数のリンクにわたって負荷を広げるためにトラフィック内の並列処理を利用するように設計されています。これらのECMP技術は通常、送信リンクを選択するためにパケットからアドレスとポート番号を解析およびハッシュすることを含みます。しかしながら、トンネルの使用は、プロトコルの追加の知識がないように、ECMP性能が低下することが多いので、カプセル化されたトラフィックは設計によってファブリックから隠され、ハッシュにはトンネルエンドポイントアドレスのみが利用可能である。
Since it is desirable for Geneve to perform well on these existing fabrics, it is necessary for entropy from encapsulated packets to be exposed in the tunnel header. The most common technique for this is to use the UDP source port, which is discussed further in Section 3.3.
Geneeveがこれらの既存の布地でうまく実行するのが望ましいので、カプセル化されたパケットからのエントロピーがトンネルヘッダーで露出されるのが必要です。これに最も一般的なテクニックは、UDPソースポートを使用することです。これについては、セクション3.3でさらに説明します。
The Geneve packet format consists of a compact tunnel header encapsulated in UDP over either IPv4 or IPv6. A small fixed tunnel header provides control information plus a base level of functionality and interoperability with a focus on simplicity. This header is then followed by a set of variable-length options to allow for future innovation. Finally, the payload consists of a protocol data unit of the indicated type, such as an Ethernet frame. Sections 3.1 and 3.2 illustrate the Geneve packet format transported (for example) over Ethernet along with an Ethernet payload.
Geneveパケットフォーマットは、IPv4またはIPv6のどちらかでUDPにカプセル化されたコンパクトなトンネルヘッダーで構成されています。小型の固定トンネルヘッダは、制御情報とベースレベルの機能性と相互運用性との間の焦点との相互運用性を提供します。その後、このヘッダの後に、将来の革新を可能にするための一連の可変長オプションが続きます。最後に、ペイロードは、イーサネットフレームのような示された型のプロトコルデータ単位で構成されています。セクション3.1および3.2は、イーサネットペイロードと共にイーサネットを介して転送されたGENEVEパケットフォーマットを示している。
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
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
Outer Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address | Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Optional Ethertype=C-Tag 802.1Q| Outer VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = 0x0800 IPv4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer IPv4 Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live |Protocol=17 UDP| Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer UDP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port = xxxx | Dest Port = 6081 Geneve |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Geneve Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| Opt Len |O|C| Rsvd. | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Virtual Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Variable-Length Options ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inner Ethernet Header (example payload):
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Destination MAC Address | Inner Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Optional Ethertype=C-Tag 802.1Q| Inner VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype of Original Payload | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Original Ethernet Payload |
| |
~ (Note that the original Ethernet frame's preamble, start ~
| frame delimiter (SFD), and frame check sequence (FCS) are not |
| included, and the Ethernet payload need not be 4-byte aligned)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame Check Sequence:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Frame Check Sequence (FCS) for Outer Ethernet Frame |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Geneve Packet Format over IPv4
図2：IPv4上のGeneveパケットフォーマット
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
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
Outer Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address | Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Optional Ethertype=C-Tag 802.1Q| Outer VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = 0x86DD IPv6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer IPv6 Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | NxtHdr=17 UDP | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Outer Source IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Outer Destination IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer UDP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port = xxxx | Dest Port = 6081 Geneve |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Geneve Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| Opt Len |O|C| Rsvd. | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Virtual Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Variable-Length Options ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inner Ethernet Header (example payload):
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Destination MAC Address | Inner Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Optional Ethertype=C-Tag 802.1Q| Inner VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype of Original Payload | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Original Ethernet Payload |
| |
~ (Note that the original Ethernet frame's preamble, start ~
| frame delimiter (SFD), and frame check sequence (FCS) are not |
| included, and the Ethernet payload need not be 4-byte aligned)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame Check Sequence:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Frame Check Sequence (FCS) for Outer Ethernet Frame |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Geneve Packet Format over IPv6
図3：IPv6上のGeneveパケットフォーマット
The use of an encapsulating UDP [RFC0768] header follows the connectionless semantics of Ethernet and IP in addition to providing entropy to routers performing ECMP. Therefore, header fields are interpreted as follows:
カプセル化UDP [RFC0768]ヘッダーの使用は、ECMPを実行するルーターへのエントロピーを提供することに加えて、イーサネットおよびIPのコネクションのないセマンティクスに従います。したがって、ヘッダーフィールドは次のように解釈されます。
Source Port: A source port selected by the originating tunnel endpoint. This source port SHOULD be the same for all packets belonging to a single encapsulated flow to prevent reordering due to the use of different paths. To encourage an even distribution of flows across multiple links, the source port SHOULD be calculated using a hash of the encapsulated packet headers using, for example, a traditional 5-tuple. Since the port represents a flow identifier rather than a true UDP connection, the entire 16-bit range MAY be used to maximize entropy. In addition to setting the source port, for IPv6, the flow label MAY also be used for providing entropy. For an example of using the IPv6 flow label for tunnel use cases, see [RFC6438].
ソースポート：発信トンネルエンドポイントによって選択された送信元ポート。この送信元ポートは、異なるパスの使用による並べ替えを防ぐために、単一のカプセル化フローに属するすべてのパケットについて同じである必要があります。複数のリンクにわたるフローの偶数分布を促進するために、ソースポートは、例えば従来の5タプルを使用してカプセル化されたパケットヘッダーのハッシュを使用して計算されるべきです。ポートは真のUDP接続ではなくフロー識別子を表しているため、エントロピーを最大化するために16ビット範囲全体を使用できます。送信元ポートをIPv6の設定に加えて、エントロピーを提供するためにフローラベルを使用することもできます。トンネルユースケースのIPv6フローラベルを使用する例については、[RFC6438]を参照してください。
If Geneve traffic is shared with other UDP listeners on the same IP address, tunnel endpoints SHOULD implement a mechanism to ensure ICMP return traffic arising from network errors is directed to the correct listener. The definition of such a mechanism is beyond the scope of this document.
同じIPアドレスでGeneveトラフィックが他のUDPリスナーと共有されている場合、トンネルエンドポイントはネットワークエラーから発生するICMPの戻りトラフィックが正しいリスナーに向けられていることを確認するためのメカニズムを実装する必要があります。そのようなメカニズムの定義はこの文書の範囲を超えています。
Dest Port: IANA has assigned port 6081 as the fixed well-known destination port for Geneve. Although the well-known value should be used by default, it is RECOMMENDED that implementations make this configurable. The chosen port is used for identification of Geneve packets and MUST NOT be reversed for different ends of a connection as is done with TCP. It is the responsibility of the control plane to manage any reconfiguration of the assigned port and its interpretation by respective devices. The definition of the control plane is beyond the scope of this document.
DESTポート：IANAは、GENEVE用の固定の有名な宛先ポートとしてポート6081を割り当てました。既知の値はデフォルトで使用する必要がありますが、実装はこれを設定可能にすることをお勧めします。選択されたポートは、GENEVEパケットの識別に使用され、TCPで行われるように接続のさまざまな端に対して逆にしてはいけません。割り当てられたポートの再構成とそれぞれのデバイスによるその解釈を管理するのは、制御プレーンの責任です。コントロールプレーンの定義はこの文書の範囲を超えています。
UDP Length: The length of the UDP packet including the UDP header.
UDPの長さ：UDPヘッダーを含むUDPパケットの長さ。
UDP Checksum: In order to protect the Geneve header, options, and payload from potential data corruption, the UDP checksum SHOULD be generated as specified in [RFC0768] and [RFC1122] when Geneve is encapsulated in IPv4. To protect the IP header, Geneve header, options, and payload from potential data corruption, the UDP checksum MUST be generated by default as specified in [RFC0768] and [RFC8200] when Geneve is encapsulated in IPv6, except under certain conditions, which are outlined in the next paragraph. Upon receiving such packets with a non-zero UDP checksum, the receiving tunnel endpoints MUST validate the checksum. If the checksum is not correct, the packet MUST be dropped; otherwise, the packet MUST be accepted for decapsulation.
UDPチェックサム：潜在的なデータ破損からGENEVEヘッダ、オプション、およびペイロードを保護するために、GENEVEがIPv4でカプセル化されている場合は、[RFC0768]および[RFC1122]で指定されているUDPチェックサムを生成する必要があります。潜在的なデータ破損からIPヘッダー、GENEVEヘッダー、オプション、およびペイロードを保護するためには、[RFC0768]と[RFC8200]で指定されている場合は、[RFC0768]と[RFC8200]では、特定の条件下ではIPv6にカプセル化されている場合は、UDPチェックサムを生成する必要があります。次の段落で概説されています。ゼロ以外のUDPチェックサムを持つパケットを受信すると、受信トンネルエンドポイントはチェックサムを検証する必要があります。チェックサムが正しくない場合は、パケットをドロップする必要があります。それ以外の場合、パケットはカプセル化のために受け入れる必要があります。
Under certain conditions, the UDP checksum MAY be set to zero on transmit for packets encapsulated in both IPv4 and IPv6 [RFC8200]. See Section 4.3 for additional requirements that apply when using zero UDP checksum with IPv4 and IPv6. Disabling the use of UDP checksums is an operational consideration that should take into account the risks and effects of packet corruption.
特定の条件下では、UDPチェックサムは、IPv4とIPv6 [RFC8200]の両方でカプセル化されたパケットの送信時にゼロに設定されます。IPv4およびIPv6を使用してゼロUDPチェックサムを使用するときに適用される追加要件については、セクション4.3を参照してください。UDPチェックサムの使用を無効にすることは、パケット破損のリスクと効果を考慮に入れるべきである運用上の考慮事項です。
Ver (2 bits): The current version number is 0. Packets received by a tunnel endpoint with an unknown version MUST be dropped. Transit devices interpreting Geneve packets with an unknown version number MUST treat them as UDP packets with an unknown payload.
Ver（2ビット）：現在のバージョン番号は0です。未知のバージョンでトンネルエンドポイントで受信されたパケットはドロップされなければなりません。トランジットデバイス未知のバージョン番号を持つGENEVEパケットを解釈して、未知のペイロードを持つUDPパケットとしてそれらを扱う必要があります。
Opt Len (6 bits): The length of the option fields, expressed in 4-byte multiples, not including the 8-byte fixed tunnel header. This results in a minimum total Geneve header size of 8 bytes and a maximum of 260 bytes. The start of the payload headers can be found using this offset from the end of the base Geneve header.
OPT LEN（6ビット）：8バイトの固定トンネルヘッダーを含まない4バイトの倍数で表されるオプションフィールドの長さ。これにより、最低8バイト、最大260バイトの最小総GENEVEヘッダサイズが得られます。ペイロードヘッダーの開始は、このオフセットをBase Geneveヘッダーの末尾から使用して見つけることができます。
Transit devices MUST maintain consistent forwarding behavior irrespective of the value of 'Opt Len', including ECMP link selection.
輸送装置は、ECMPリンク選択を含む「Opt Len」の値に関係なく、一貫した転送動作を維持しなければならない。
O (1 bit): Control packet. This packet contains a control message. Control messages are sent between tunnel endpoints. Tunnel endpoints MUST NOT forward the payload, and transit devices MUST NOT attempt to interpret it. Since control messages are less frequent, it is RECOMMENDED that tunnel endpoints direct these packets to a high-priority control queue (for example, to direct the packet to a general purpose CPU from a forwarding Application-Specific Integrated Circuit (ASIC) or to separate out control traffic on a NIC). Transit devices MUST NOT alter forwarding behavior on the basis of this bit, such as ECMP link selection.
O（1ビット）：制御パケット。このパケットには制御メッセージが含まれています。制御メッセージはトンネルエンドポイント間で送信されます。トンネルエンドポイントはペイロードを転送してはならず、トランジットデバイスはそれを解釈しようとしてはいけません。制御メッセージはそれほど頻繁ではないので、トンネルエンドポイントはこれらのパケットを高優先度の高い制御キューに向けることをお勧めします（たとえば、転送アプリケーション固有の集積回路（ASIC）または分離にパケットを汎用のCPUに向けることができます。NIC上のトラフィックを制御する。Transitデバイスは、ECMPリンクの選択など、このビットに基づいて転送動作を変更してはいけません。
C (1 bit): Critical options present. One or more options has the critical bit set (see Section 3.5). If this bit is set, then tunnel endpoints MUST parse the options list to interpret any critical options. On tunnel endpoints where option parsing is not supported, the packet MUST be dropped on the basis of the 'C' bit in the base header. If the bit is not set, tunnel endpoints MAY strip all options using 'Opt Len' and forward the decapsulated packet. Transit devices MUST NOT drop packets on the basis of this bit.
C（1ビット）：重要なオプションが存在します。1つ以上のオプションには、クリティカルビットセットがあります（セクション3.5を参照）。このビットが設定されている場合は、Tunnel Endpointsは、重要なオプションを解釈するためにオプションリストを解析する必要があります。オプション解析がサポートされていないトンネルエンドポイントでは、ベースヘッダーの「C」ビットに基づいてパケットをドロップする必要があります。ビットが設定されていない場合、トンネルエンドポイントは 'opt len'を使用してすべてのオプションを削除し、カプセル化されたパケットを転送することがあります。トランジットデバイスは、このビットに基づいてパケットをドロップしてはいけません。
Rsvd. (6 bits): Reserved field, which MUST be zero on transmission and MUST be ignored on receipt.
RSVD（6ビット）：送信時にゼロでなければならず、受信時に無視する必要があります。
Protocol Type (16 bits): The type of protocol data unit appearing after the Geneve header. This follows the Ethertype [ETYPES] convention, with Ethernet itself being represented by the value 0x6558.
プロトコルタイプ（16ビット）：GENEVEヘッダの後に表示されるプロトコルデータユニットの種類。これはEtherType [Etypes]規則に従い、イーサネット自体が値0x6558で表されます。
Virtual Network Identifier (VNI) (24 bits): An identifier for a unique element of a virtual network. In many situations, this may represent an L2 segment; however, the control plane defines the forwarding semantics of decapsulated packets. The VNI MAY be used as part of ECMP forwarding decisions or MAY be used as a mechanism to distinguish between overlapping address spaces contained in the encapsulated packet when load balancing across CPUs.
仮想ネットワーク識別子（VNI）（24ビット）：仮想ネットワークの固有要素の識別子。多くの状況では、これはL2セグメントを表すことができます。ただし、制御面はカプセル化されたパケットの転送セマンティクスを定義します。VNIは、ECMP転送決定の一部として使用されてもよく、またはCPU間の負荷分散時にカプセル化されたパケットに含まれる重複アドレス空間を区別するためのメカニズムとして使用されてもよい。
Reserved (8 bits): Reserved field, which MUST be zero on transmission and ignored on receipt.
予約済み（8ビット）：予約フィールド。送信時にゼロでなければならず、受信時に無視されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Class | Type |R|R|R| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Variable-Length Option Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Geneve Option
図4：GENEVEオプション
The base Geneve header is followed by zero or more options in Type-Length-Value format. Each option consists of a 4-byte option header and a variable amount of option data interpreted according to the type.
Base Geneveヘッダーの後には、タイプ長値形式で0個以上のオプションが続きます。各オプションは、4バイトのオプションヘッダーと、タイプに従って解釈される可変量のオプションデータで構成されています。
Option Class (16 bits): Namespace for the 'Type' field. IANA has created a "Geneve Option Class" registry to allocate identifiers for organizations, technologies, and vendors that have an interest in creating types for options. Each organization may allocate types independently to allow experimentation and rapid innovation. It is expected that, over time, certain options will become well known, and a given implementation may use option types from a variety of sources. In addition, IANA has reserved specific ranges for allocation by IETF Review and for Experimental Use (see Section 7).
オプションクラス（16ビット）： 'Type'フィールドの名前空間。IANAは、オプションのタイプの作成に興味を持っている組織、テクノロジ、およびベンダーの識別子を割り当てるための「Geneve Option Class」レジストリを作成しました。各組織は、実験と迅速な革新を可能にするために独立して型を割り当てることができます。時間の経過とともに、特定のオプションがよく知られ、特定の実装がさまざまなソースからオプションタイプを使用することが予想されます。さらに、IANAはIETFレビューによる割り当てのための特定の範囲を予約し、実験的な使用のために（セクション7を参照）。
Type (8 bits): Type indicating the format of the data contained in this option. Options are primarily designed to encourage future extensibility and innovation, and standardized forms of these options will be defined in separate documents.
タイプ（8ビット）：このオプションに含まれているデータの形式を示すタイプ。オプションは主に将来の拡張性とイノベーションを促進するように設計されており、これらのオプションの標準化された形式は別々の文書で定義されます。
The high-order bit of the option type indicates that this is a critical option. If the receiving tunnel endpoint does not recognize the option and this bit is set, then the packet MUST be dropped. If this bit is set in any option, then the 'C' bit in the Geneve base header MUST also be set. Transit devices MUST NOT drop packets on the basis of this bit. The following figure shows the location of the 'C' bit in the 'Type' field:
オプションタイプの高次ビットは、これが重要なオプションであることを示します。受信トンネルエンドポイントがオプションを認識しない場合、このビットが設定されている場合は、パケットをドロップする必要があります。このビットが任意のオプションで設定されている場合は、Geneve Baseヘッダーの 'C'ビットも設定する必要があります。トランジットデバイスは、このビットに基づいてパケットをドロップしてはいけません。次の図は、 'Type'フィールドの 'C'ビットの場所を示しています。
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
|C| Type |
+-+-+-+-+-+-+-+-+
Figure 5: 'C' Bit in the 'Type' Field
図5： 'Type'フィールドの 'c'ビット
The requirement to drop a packet with an unknown option with the 'C' bit set applies to the entire tunnel endpoint system and not a particular component of the implementation. For example, in a system comprised of a forwarding ASIC and a general purpose CPU, this does not mean that the packet must be dropped in the ASIC. An implementation may send the packet to the CPU using a rate-limited control channel for slow-path exception handling.
「C」ビットセットを使用して、未知のオプションを使用してパケットをドロップする要件は、トンネルエンドポイントシステム全体に適用され、実装の特定のコンポーネントは適用されません。例えば、転送ASICおよび汎用CPUからなるシステムでは、これはパケットがASICでドロップされなければならないという意味ではありません。実装は、スローラス例外処理のためにレート制限制御チャネルを使用してパケットをCPUに送信することができる。
R (3 bits): Option control flags reserved for future use. These bits MUST be zero on transmission and MUST be ignored on receipt.
R（3ビット）：将来の使用のために予約されているオプション制御フラグ。これらのビットは送信時にゼロでなければならず、受信時に無視されなければなりません。
Length (5 bits): Length of the option, expressed in 4-byte multiples, excluding the option header. The total length of each option may be between 4 and 128 bytes. A value of 0 in the 'Length' field implies an option with only an option header and no option data. Packets in which the total length of all options is not equal to the 'Opt Len' in the base header are invalid and MUST be silently dropped if received by a tunnel endpoint that processes the options.
長さ（5ビット）：オプションヘッダーを除く、4バイトの倍数で表されるオプションの長さ。各オプションの全長は4から128バイトの間であり得る。'Length'フィールドの値0の値は、オプションヘッダーとオプションデータなしのオプションを意味します。すべてのオプションの全長が基本ヘッダーの 'Opt Len'と等しくないパケットは無効であり、オプションを処理するトンネルエンドポイントによって受信された場合は黙ってドロップされなければなりません。
Variable-Length Option Data: Option data interpreted according to 'Type'.
可変長オプションデータ：オプションデータは「タイプ」に従って解釈されます。
Geneve options are intended to be originated and processed by tunnel endpoints. However, options MAY be interpreted by transit devices along the tunnel path. Transit devices not interpreting Geneve headers (which may or may not include options) MUST handle Geneve packets as any other UDP packet and maintain consistent forwarding behavior.
GeneVeオプションは、トンネルエンドポイントによって発信され、処理されることを意図しています。ただし、オプションはトンネルパスに沿ってトランジットデバイスによって解釈される可能性があります。Geneveヘッダー（オプションが含まれている場合や含めることができない場合があります）のトランジットデバイスは、他のUDPパケットとしてGENEVEパケットを処理し、一貫した転送動作を維持する必要があります。
In tunnel endpoints, the generation and interpretation of options is determined by the control plane, which is beyond the scope of this document. However, to ensure interoperability between heterogeneous devices, some requirements are imposed on options and the devices that process them:
トンネルエンドポイントでは、オプションの生成と解釈はコントロールプレーンによって決まります。これはこの文書の範囲を超えています。しかしながら、異種デバイス間の相互運用性を確保するために、いくつかの要件はオプションとそれらを処理するデバイスに課されます。
* Receiving tunnel endpoints MUST drop packets containing unknown options with the 'C' bit set in the option type. Conversely, transit devices MUST NOT drop packets as a result of encountering unknown options, including those with the 'C' bit set.
* 受信トンネルエンドポイントは、オプションタイプに設定されている 'C'ビットを含む未知のオプションを含むパケットを削除する必要があります。逆に、「C」ビットセットを持つものを含む、未知のオプションが発生した結果として、トランストイトデバイスはパケットをドロップしてはいけません。
* The contents of the options and their ordering MUST NOT be modified by transit devices.
* オプションとその順序の内容は、トランジットデバイスによって変更されてはなりません。
* If a tunnel endpoint receives a Geneve packet with an 'Opt Len' (the total length of all options) that exceeds the options-processing capability of the tunnel endpoint, then the tunnel endpoint MUST drop such packets. An implementation may raise an exception to the control plane in such an event. It is the responsibility of the control plane to ensure the communicating peer tunnel endpoints have the processing capability to handle the total length of options. The definition of the control plane is beyond the scope of this document.
* トンネルエンドポイントが「OPT LEN」（すべてのオプションの合計長）でTunnelエンドポイントのオプション処理機能を超えるGENEVEパケットを受信した場合、トンネルエンドポイントはそのようなパケットを削除する必要があります。そのようなイベントでは、実装はコントロールプレーンに例外を発生させることができる。通信ピアトトンネルエンドポイントがオプションの全長を処理するための処理機能を確実にすることは、コントロールプレーンの責任です。コントロールプレーンの定義はこの文書の範囲を超えています。
When designing a Geneve option, it is important to consider how the option will evolve in the future. Once an option is defined, it is reasonable to expect that implementations may come to depend on a specific behavior. As a result, the scope of any future changes must be carefully described upfront.
GENEVEオプションを設計するときは、将来オプションがどのように進化するかを検討することが重要です。オプションが定義されると、実装が特定の動作に依存する可能性があることを期待するのは合理的です。その結果、将来の変更の範囲は慎重に前述している必要があります。
Architecturally, options are intended to be self descriptive and independent. This enables parallelism in options processing and reduces implementation complexity. However, the control plane may impose certain ordering restrictions, as described in Section 4.5.1.
アーキテクチャでは、オプションは自己記述的で独立していることを意図しています。これにより、オプション処理の並列処理を可能にし、実装の複雑さを軽減します。しかしながら、コントロールプレーンは、セクション4.5.1で説明されているように、特定の順序制限を課すことがあります。
Unexpectedly significant interoperability issues may result from changing the length of an option that was defined to be a certain size. A particular option is specified to have either a fixed length, which is constant, or a variable length, which may change over time or for different use cases. This property is part of the definition of the option and is conveyed by the 'Type'. For fixed-length options, some implementations may choose to ignore the 'Length' field in the option header and instead parse based on the well-known length associated with the type. In this case, redefining the length will impact not only the parsing of the option in question but also any options that follow. Therefore, options that are defined to be a fixed length in size MUST NOT be redefined to a different length. Instead, a new 'Type' should be allocated. Actual definition of the option type is beyond the scope of this document. The option type and its interpretation should be defined by the entity that owns the option class.
予期せぬ重大な相互運用性の問題は、特定のサイズであると定義されているオプションの長さを変更することに起因する可能性があります。特定のオプションは、一定の固定長、または可変長のいずれかを持つように指定されています。このプロパティはオプションの定義の一部であり、 'type'によって伝えられます。固定長オプションの場合、一部の実装は、オプションヘッダーの「Length」フィールドを無視し、代わりにタイプに関連付けられている既知の長さに基づいて解析を選択することができます。この場合、長さを再定義すると、問題のオプションの解析だけでなく、以下のオプションも影響します。したがって、サイズの固定長さと定義されているオプションは、異なる長さに再定義されてはいけません。代わりに、新しい「タイプ」を割り当てる必要があります。オプションタイプの実際の定義はこの文書の範囲を超えています。オプションの種類とその解釈は、オプションクラスを所有するエンティティによって定義されるべきです。
Options may be processed by NIC hardware utilizing offloads (e.g., LSO and LRO) as described in Section 4.6. Careful consideration should be given to how the offload capabilities outlined in Section 4.6 impact an option's design.
オプションは、セクション4.6に記載されているように、オフロード（例えば、LSOおよびLRO）を利用してNICハードウェアによって処理され得る。セクション4.6で概説されているオフロード機能がオプションの設計に影響を与える方法を慎重に検討する必要があります。
Geneve is a UDP-based network virtualization overlay encapsulation protocol designed to establish tunnels between NVEs over an existing IP network. It is intended for use in public or private data center environments, for deploying multi-tenant overlay networks over an existing IP underlay network.
Geneveは、既存のIPネットワーク上でNVES間のトンネルを確立するように設計されたUDPベースのネットワーク仮想化オーバーレイカプセル化プロトコルです。それは、既存のIPアンダーレイネットワーク上でマルチテナントオーバーレイネットワークを展開するために、公共またはプライベートデータセンター環境での使用を目的としています。
As a UDP-based protocol, Geneve adheres to the UDP usage guidelines as specified in [RFC8085]. The applicability of these guidelines is dependent on the underlay IP network and the nature of the Geneve payload protocol (for example, TCP/IP, IP/Ethernet).
UDPベースのプロトコルとして、GENEVEは[RFC8085]で指定されているUDP使用ガイドラインに準拠しています。これらのガイドラインの適用性は、アンダーレイIPネットワークとGeneve Payload Protocolの性質に依存しています（たとえば、TCP / IP、IP / Ethernetなど）。
Geneve is intended to be deployed in a data center network environment operated by a single operator or an adjacent set of cooperating network operators that fits with the definition of controlled environments in [RFC8085]. 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 tunneling protocol operating under a controlled environment can be less restrictive than the requirements of the general Internet.
Geneveは、単一のオペレータまたは[RFC8085]の制御環境の定義に適合する隣接するネットワーク演算子の隣接するネットワーク演算子のセットで運用されるデータセンターネットワーク環境に展開されることを目的としています。制御された環境のネットワークは特定の条件下で動作することができますが、一般的なインターネットではこれはできません。したがって、制御された環境下で動作するトンネリングプロトコルの要件は、一般的なインターネットの要件よりも制限的ではありません。
For the purpose of this document, a traffic-managed controlled environment (TMCE) is defined as an IP network that is traffic engineered and/or otherwise managed (e.g., via use of traffic rate limiters) to avoid congestion. The concept of a TMCE is outlined in [RFC8086]. Significant portions of the text in Section 4.1 through Section 4.3 are based on [RFC8086] as applicable to Geneve.
この文書の目的のために、トラフィック管理制御環境（TMCE）は、輻輳を避けるために、トラフィックの操作および/またはその他の方法で管理されている（例えば、トラフィックレートリミッタの使用を介して）IPネットワークとして定義される。TMCEの概念は[RFC8086]に概説されています。セクション4.1からセクション4.3のテキストの重要な部分は、Geneveに適用されるように[RFC8086]に基づいています。
It is the responsibility of the operator to ensure that the guidelines/requirements in this section are followed as applicable to their Geneve deployment(s).
これは、このセクションのガイドライン/要件に従っていることを確実にして、それらのGeneve展開に適用されるようにするのはオペレータの責任です。
Geneve does not natively provide congestion-control functionality and relies on the payload protocol traffic for congestion control. As such, Geneve MUST be used with congestion-controlled traffic or within a TMCE to avoid congestion. An operator of a TMCE may avoid congestion through careful provisioning of their networks, rate-limiting user data traffic, and managing traffic engineering according to path capacity.
Geneveは輻輳制御機能をネイティブに提供しておらず、輻輳制御のためのペイロードプロトコルトラフィックに依存しています。そのように、輻輳を回避するために、Geneeveは輻輳制御トラフィックとともにまたはTMCE内で使用されなければなりません。TMCEのオペレータは、パス容量に応じて、ネットワーク、レート制限ユーザーデータトラフィック、およびトラフィックエンジニアリングの管理を慎重にプロビジョニングすることによって輻輳を回避することがあります。
The outer UDP checksum SHOULD be used with Geneve when transported over IPv4; this is to provide integrity for the Geneve headers, options, and payload in case of data corruption (for example, to avoid misdelivery of the payload to different tenant systems). 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 modification 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 (see Section 6.2).
IPv4を介して輸送されたときに、外部UDPチェックサムをGeneveと共に使用する必要があります。これは、データ破損の場合にGeneveヘッダー、オプション、およびペイロードの整合性を提供することです（たとえば、ペイロードのペイロードが異なるテナントシステムへの誤配信を避けるため）。UDPチェックサムは、輸送中にペイロードが破損していなかったという統計的保証を提供します。これらの完全性チェックは、コーディングまたは暗号的な観点から強くはなく、データグラムの物理層のエラーや悪意のある変更を検出するようには設計されていません（[RFC8085]のセクション3.4を参照）。そのようなリスクが存在する展開では、オペレータはIPsecが提供するものなどの追加のデータ整合性メカニズムを使用する必要があります（セクション6.2を参照）。
An operator MAY choose to disable UDP checksums and use zero UDP checksum if Geneve packet integrity is provided by other data integrity mechanisms, such as IPsec or additional checksums, or if one of the conditions (a, b, or c) in Section 4.3.1 is met.
演算子は、IPSecや追加のチェックサムなどの他のデータ整合性メカニズムによって、またはセクション4.3の条件（A、B、またはC）のいずれかで、UDPチェックサムを無効にすることを選択できます。1が満たされています。
By default, UDP checksums MUST be used when Geneve is transported over IPv6. A tunnel endpoint MAY be configured for use with zero UDP checksum if additional requirements in Section 4.3.1 are met.
デフォルトでは、GeneeveがIPv6を介して転送されたときにUDPチェックサムを使用する必要があります。セクション4.3.1の追加要件が満たされている場合、ゼロUDPチェックサムで使用するためにトンネルエンドポイントを設定できます。
When Geneve is used over IPv6, the UDP checksum is used to protect IPv6 headers, UDP headers, and Geneve headers, options, and payload from potential data corruption. As such, by default, Geneve MUST use UDP checksums when transported over IPv6. An operator MAY choose to configure zero UDP checksum if operating in a TMCE as stated in Section 4.1 if one of the following conditions is met.
GeneveがIPv6を介して使用されている場合、UDPチェックサムは、IPv6ヘッダー、UDPヘッダー、およびGENEVEヘッダー、オプション、およびペイロードを潜在的なデータ破損から保護するために使用されます。そのため、デフォルトでは、GeneeveはIPv6を介して転送されたときにUDPチェックサムを使用する必要があります。次のいずれかの条件が満たされている場合は、セクション4.1に記載されている場合は、セクション4.1に記載されている場合は、セクション4.1に記載されている場合は、オペレータがゼロUDPチェックサムを設定することを選択できます。
a. It is known that packet corruption is exceptionally unlikely (perhaps based on knowledge of equipment types in their underlay network) and the operator is willing to risk undetected packet corruption.
a. パケットの破損は非常に重要ではあり得ない（おそらく彼らのアンダーレイネットワークにおける機器の種類の知識に基づいて）、そしてオペレータは未検出のパケット破損を危険にさらすことを望んでいることが知られています。
b. It is judged through observational measurements (perhaps through historic or current traffic flows that use non-zero checksum) that the level of packet corruption is tolerably low and is where the operator is willing to risk undetected corruption.
b. それは、パケットの破損のレベルが許容できるほど低く、オペレータが検出されない破損の危険性があると思われる場所である観察測定を通して判断されます。
c. The Geneve payload is carrying applications that are tolerant of misdelivered or corrupted packets (perhaps through higher-layer checksum validation and/or reliability through retransmission).
c. Geneve Payloadは、誤解されたまたは破損したパケット（おそらくより高い層のチェックサム検証および/または再送信による信頼性を介して）を履行しているアプリケーションを運んでいます。
In addition, Geneve tunnel implementations using zero UDP checksum MUST meet the following requirements:
さらに、ゼロUDPチェックサムを使用したGeneeve Tunnel実装は、次の要件を満たす必要があります。
1. Use of UDP checksum over IPv6 MUST be the default configuration for all Geneve tunnels.
1. IPv6を介したUDPチェックサムの使用は、すべてのGeneve Tunnelsのデフォルト設定でなければなりません。
2. If Geneve is used with zero UDP checksum over IPv6, then such a tunnel endpoint implementation MUST meet all the requirements specified in Section 4 of [RFC6936] and requirement 1 as specified in Section 5 of [RFC6936] since it is relevant to Geneve.
2. GeneveがIPv6を介してゼロUDPチェックサムで使用されている場合、そのようなトンネルエンドポイント実装は[RFC6936]のセクション4で指定されたすべての要件と[RFC6936]のセクション5で指定されている要件1に関連しています。
3. The Geneve tunnel endpoint that decapsulates the tunnel SHOULD check that the source and destination IPv6 addresses are valid for the Geneve tunnel that is configured to receive zero UDP checksum and discard other packets for which such a check fails.
3. トンネルをカプセル化するGeneeve Tunnelエンドポイントは、ゼロUDPチェックサムを受信し、そのようなチェックが失敗した他のパケットを破棄するように構成されているGeneveトンネルに対して、送信元と宛先のIPv6アドレスが有効であることを確認する必要があります。
4. The Geneve tunnel endpoint that encapsulates the tunnel MAY use different IPv6 source addresses for each Geneve 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 Geneve tunnels that use zero UDP checksum as is feasible.
4. トンネルをカプセル化するGeneeve Tunnel Endpointは、デカプセルのデカプセルのIPv6の電源アドレスのチェックを強化するために（つまり、同じIPv6の送信元アドレスを使用しないようにすることはできません）ゼロUDPチェックサムモードを使用する各GENEVEトンネルに対して異なるIPv6送信元アドレスを使用することがあります。その宛先アドレスがユニキャストアドレスかマルチキャストアドレスであるかどうかにかかわらず、複数のIPv6宛先アドレス。これが不可能な場合は、実行可能なUDPチェックサムを使用するGENEVE TUNNELの場合は、各ソースアドレスを使用することをお勧めします。
Note that for requirements 3 and 4, the receiving tunnel endpoint can apply these checks only if it has out-of-band knowledge that the encapsulating tunnel endpoint is applying the indicated behavior. One possibility to obtain this out-of-band knowledge is through signaling by the control plane. The definition of the control plane is beyond the scope of this document.
要件3および4の場合、受信トンネルエンドポイントは、カプセル化トンネルエンドポイントが示された動作を適用しているという帯域外の知識がある場合にのみ、受信トンネルエンドポイントを適用できます。この帯域外の知識を得ることは、制御平面によるシグナリングによるものである。コントロールプレーンの定義はこの文書の範囲を超えています。
5. Measures SHOULD be taken to prevent Geneve traffic over IPv6 with zero UDP checksum from escaping into the general Internet. Examples of such measures include employing packet filters at the gateways or edge of the Geneve network and/or keeping logical or physical separation of the Geneve network from networks carrying general Internet traffic.
5. UDPチェックサムが一般的なインターネットにエスケープされたIPv6を介してGeneveトラフィックを防ぐための対策を講じる必要があります。そのような措置の例は、Geneveネットワークのゲートウェイまたはエッジでパケットフィルタを採用すること、および/または一般的なインターネットトラフィックを運ぶネットワークからのGENEVEネットワークの論理的または物理的分離を維持することを含む。
The above requirements do not change the requirements specified in either [RFC8200] or [RFC6936].
上記の要件は、[RFC8200]または[RFC6936]のいずれかで指定された要件を変更しません。
The use of the source IPv6 address in addition to the destination IPv6 address, plus the recommendation against reuse of source IPv6 addresses among Geneve 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アドレスを使用すると、Geneeveトンネル間のソースIPv6アドレスの再利用に対する推奨事項は、IPv6ヘッダーのUDPチェックサムカバレッジの欠如に集約的に軽減を提供します。このセクションの先頭にリストされている3つの条件のうちの少なくとも1つを満たすトラフィック管理制御環境では、追加の保証があります。
As an IP-based tunneling protocol, Geneve shares many properties and techniques with existing protocols. The application of some of these are described in further detail, although, in general, most concepts applicable to the IP layer or to IP tunnels generally also function in the context of Geneve.
IPベースのトンネリングプロトコルとして、GENEVEは既存のプロトコルとの多くのプロパティとテクニックを共有しています。これらのいくつかの適用はさらに詳細に記載されているが、一般に、IP層またはIPトンネルに適用可能なほとんどの概念は一般にGeneeveの文脈においても機能する。
It is RECOMMENDED that Path MTU Discovery (see [RFC1191] and [RFC8201]) be used to prevent or minimize fragmentation. The use of Path MTU Discovery on the transit network provides the encapsulating tunnel endpoint with soft-state information about the link that it may use to prevent or minimize fragmentation depending on its role in the virtualized network. The NVE can maintain this state (the MTU size of the tunnel link(s) associated with the tunnel endpoint), so if a tenant system sends large packets that, when encapsulated, exceed the MTU size of the tunnel link, the tunnel endpoint can discard such packets and send exception messages to the tenant system(s). If the tunnel endpoint is associated with a routing or forwarding function and/or has the capability to send ICMP messages, the encapsulating tunnel endpoint MAY send ICMP fragmentation needed [RFC0792] or Packet Too Big [RFC4443] messages to the tenant system(s). When determining the MTU size of a tunnel link, the maximum length of options MUST be assumed as options may vary on a per-packet basis. Recommendations and guidance for handling fragmentation in similar overlay encapsulation services like Pseudowire Emulation Edge-to-Edge (PWE3) are provided in Section 5.3 of [RFC3985].
フラグメンテーションを防止または最小化するために、Path MTU検出（[RFC1191]および[RFC8201]参照）を使用することをお勧めします。トランジットネットワーク上のパスMTUディスカバリの使用は、仮想化ネットワーク内のその役割に応じて断片化を防止または最小化するために使用することができるリンクに関するソフトステート情報を含むカプセル化トンネルエンドポイントを提供します。 NVEは、この状態（トンネルエンドポイントに関連付けられているトンネルリンクのMTUサイズ）を維持することができるので、テナントシステムがカプセル化されたときにトンネルのリンクのMTUサイズを超える大きなパケットを送信することができる場合、トンネルエンドポイントはそのようなパケットを破棄し、テナントシステムに例外メッセージを送信します。トンネルエンドポイントがルーティングまたは転送関数に関連付けられている場合、および/またはICMPメッセージを送信する機能がある場合、カプセル化トンネルエンドポイントは、[RFC0792]またはパケットが[RFC4443]メッセージをテナントシステムに送信する必要があるICMPフラグメンテーションを送信することがあります。 。トンネルリンクのMTUサイズを決定するときは、オプションがパケットごとに異なる場合があると想定する必要があります。疑似回線のエミュレーションのような断片化の推奨事項とガイダンス疑似回線エミュレーションエッジからエッジへのエッジからエッジ（PWE3）は、[RFC3985]のセクション5.3に提供されています。
Note that some implementations may not be capable of supporting fragmentation or other less common features of the IP header, such as options and extension headers. Some of the issues associated with MTU size and fragmentation in IP tunneling and use of ICMP messages are outlined in Section 4.2 of [INTAREA-TUNNELS].
いくつかの実装は、オプションや拡張ヘッダーなどのIPヘッダーの断片化または他の一般的な機能をサポートすることができない可能性があります。IPトンネリングのMTUサイズと断片化に関連するいくつかの問題とICMPメッセージの使用は、[Intarea-Tunnels]のセクション4.2で概説されています。
When encapsulating IP (including over Ethernet) packets in Geneve, there are several considerations for propagating Differentiated Services Code Point (DSCP) and Explicit Congestion Notification (ECN) bits from the inner header to the tunnel on transmission and the reverse on reception.
Geneve内のIP（イーサネット（オーバーイーサネットを含む）パケットをカプセル化するときは、差別化されたサービスコードポイント（DSCP）と明示的な輻輳通知（ECN）ビットをインナーヘッダーから送信時のトンネルに伝播し、受信時の逆の考慮事項があります。
[RFC2983] provides guidance for mapping DSCP between inner and outer IP headers. Network virtualization is typically more closely aligned with the Pipe model described, where 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). Aspects of the Uniform model (which treats the inner and outer DSCP values as a single field by copying on ingress and egress) may also apply, such as the ability to re-mark 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.
[RFC2983]内部IPヘッダーと外側の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 Geneve.
[RFC6040] IPトンネル上のECN機能を露出させ、内部パケットへの輻輳マーカーを伝播するためのメカニズムを説明しています。Geneeveでカプセル化されているIPパケットのこの動作に従う必要があります。
Though either the Uniform or Pipe models could be used for handling TTL (or Hop Limit in case of IPv6) when tunneling IP packets, the Pipe model is more consistent with network virtualization. [RFC2003] provides guidance on handling TTL between inner IP header and outer IP tunnels; this model is similar to the Pipe model and is RECOMMENDED for use with Geneve for network virtualization applications.
IPパケットをトンネリングするときにTTL（またはIPv6の場合のホップリミット）の処理には、ユニフォームまたはパイプモデルを使用できますが、パイプモデルはネットワーク仮想化と一致しています。[RFC2003]内部IPヘッダーと外側のIPトンネルの間のTTLの処理に関するガイダンスを提供します。このモデルはパイプモデルと似ており、ネットワーク仮想化アプリケーション用のGeneveでの使用に推奨されています。
Geneve tunnels may either be point-to-point unicast between two tunnel endpoints or utilize broadcast or multicast addressing. It is not required that inner and outer addressing match in this respect. For example, in physical networks that do not support multicast, encapsulated multicast traffic may be replicated into multiple unicast tunnels or forwarded by policy to a unicast location (possibly to be replicated there).
Geneve Tunnelsは、2つのトンネルエンドポイント間のポイントツーポイントユニキャスト、またはブロードキャストまたはマルチキャストアドレッシングを利用することができます。この点で内側および外側のアドレス指定が一致する必要はありません。たとえば、マルチキャストをサポートしていない物理ネットワークでは、カプセル化されたマルチキャストトラフィックは複数のユニキャストトンネルに複製されたり、ポリシーによってポリシーの場所に転送されたりすることができます（おそらくそこにはそこに複製される）。
With physical networks that do support multicast, it may be desirable to use this capability to take advantage of hardware replication for encapsulated packets. In this case, multicast addresses may be allocated in the physical network corresponding to tenants, encapsulated multicast groups, or some other factor. The allocation of these groups is a component of the control plane and, therefore, is beyond the scope of this document.
マルチキャストをサポートする物理ネットワークでは、カプセル化されたパケットのハードウェアレプリケーションを利用するためにこの機能を使用することが望ましい場合があります。この場合、マルチキャストアドレスは、テナント、カプセル化されたマルチキャストグループ、または他の要因に対応する物理ネットワークに割り当てられてもよい。これらのグループの割り当てはコントロールプレーンの構成要素であり、したがって、この文書の範囲を超えています。
When physical multicast is in use, devices with heterogeneous capabilities may be present in the same group. Some options may only be interpretable by a subset of the devices in the group. Other devices can safely ignore such options unless the 'C' bit is set to mark the unknown option as critical. The requirements outlined in Section 3.4 apply for critical options.
物理的マルチキャストが使用されている場合、異種能力を持つ装置が同じグループ内に存在する可能性があります。一部のオプションは、グループ内のデバイスのサブセットによってのみ解釈可能であるかもしれません。「C」ビットが不明なオプションを重要としてマークするように設定されていない限り、他のデバイスは安全にそのようなオプションを無視することができます。セクション3.4で概説されている要件は、重要なオプションを申請します。
In addition, [RFC8293] provides examples of various mechanisms that can be used for multicast handling in network virtualization overlay networks.
また、[RFC8293]は、ネットワーク仮想化オーバーレイネットワークにおけるマルチキャスト処理に使用できるさまざまなメカニズムの例を示しています。
Generally speaking, a Geneve tunnel is a unidirectional concept. IP is not a connection-oriented protocol, and it is possible for two tunnel endpoints to communicate with each other using different paths or to have one side not transmit anything at all. As Geneve is an IP-based protocol, the tunnel layer inherits these same characteristics.
一般的に言って、ジュニェベトンネルは一方向の概念です。IPは接続指向プロトコルではなく、2つのトンネルエンドポイントが異なるパスを使用して互いに通信すること、または片側がまったく送信しないことが可能です。GeneveがIPベースのプロトコルであるため、トンネルレイヤはこれらの同じ特性を継承します。
It is possible for a tunnel to encapsulate a protocol, such as TCP, that is connection oriented and maintains session state at that layer. In addition, implementations MAY model Geneve tunnels as connected, bidirectional links, for example, to provide the abstraction of a virtual port. In both of these cases, bidirectionality of the tunnel is handled at a higher layer and does not affect the operation of Geneve itself.
トンネルがTCPなどのプロトコルをカプセル化することは可能です。つまり、接続指向で、そのレイヤでセッション状態を維持します。さらに、実装は、例えば、仮想ポートの抽象化を提供するために、接続された双方向リンクとしてGeneveトンネルをモデル化することができる。これらの場合のどちらの場合も、トンネルの双方向性がより高い層で処理され、Geneeve自体の操作には影響しません。
Geneve is intended to be flexible for use with a wide range of current and future applications. As a result, certain constraints may be placed on the use of metadata or other aspects of the protocol in order to optimize for a particular use case. For example, some applications may limit the types of options that are supported or enforce a maximum number or length of options. Other applications may only handle certain encapsulated payload types, such as Ethernet or IP. These optimizations can be implemented either globally (throughout the system) or locally (for example, restricted to certain classes of devices or network paths).
Geneveは、幅広い電流と将来のアプリケーションでの使用に柔軟性があることを目的としています。結果として、特定のユースケースを最適化するために、メタデータまたはプロトコルの他の側面の使用に特定の制約を配置することができる。たとえば、アプリケーションによっては、サポートされているオプションの種類を制限することも、最大数または最大数のオプションを制限することができます。他のアプリケーションは、イーサネットまたはIPなどの特定のカプセル化ペイロードタイプのみを処理できます。これらの最適化は、グローバルに（システム全体にわたって）またはローカルで実装できます（たとえば、特定のクラスのデバイスまたはネットワークパスに制限されています）。
These constraints may be communicated to tunnel endpoints either explicitly through a control plane or implicitly by the nature of the application. As Geneve is defined as a data plane protocol that is control plane agnostic, definition of such mechanisms is beyond the scope of this document.
これらの制約は、コントロールプレーンを介して、またはアプリケーションの性質によって暗黙的には、トンネルエンドポイントに伝達されてもよい。Geneveが制御プレーンの不具合のデータプレーンプロトコルとして定義されているため、そのようなメカニズムの定義はこの文書の範囲を超えています。
While Geneve options are flexible, a control plane may restrict the number of option TLVs as well as the order and size of the TLVs between tunnel endpoints to make it simpler for a data plane implementation in software or hardware to handle (see [NVO3-ENCAP]). For example, there may be some critical information, such as a secure hash, that must be processed in a certain order to provide the lowest latency, or there may be other scenarios where the options must be processed in a given order due to protocol semantics.
Geneeveオプションが柔軟である間、コントロールプレーンは、ソフトウェアまたはハードウェアでのデータプレーンの実装では、トンネルエンドポイント間のTLVの数とサイズと同様にオプションTLVの数を制限して、それを処理することができます（[NVO3-ENCAP]を参照）。]）。たとえば、安全なハッシュなど、一部の重要な情報がある場合があります。これは、最小の待ち時間を提供するために特定の順序で処理されなければならない、あるいはプロトコルセマンティクスのために特定の順序でオプションを処理する必要がある他のシナリオがある場合があります。。
A control plane may negotiate a subset of option TLVs and certain TLV ordering; it may also limit the total number of option TLVs present in the packet, for example, to accommodate hardware capable of processing fewer options. Hence, a control plane needs to have the ability to describe the supported TLV subset and its ordering to the tunnel endpoints. In the absence of a control plane, alternative configuration mechanisms may be used for this purpose. Such mechanisms are beyond the scope of this document.
コントロールプレーンは、オプションTLVのサブセットと特定のTLV順序をネゴシエートすることができます。それはまた、例えば、より少ないオプションを処理することができるハードウェアに対応するために、パケット内に存在するオプションTLVの総数を制限することもできる。したがって、制御面は、サポートされているTLVサブセットとその順序付けをトンネルエンドポイントに記述する機能を持つ必要があります。制御面がない場合、この目的のために代替構成機構を使用することができる。そのようなメカニズムはこの文書の範囲を超えています。
Modern NICs currently provide a variety of offloads to enable the efficient processing of packets. The implementation of many of these offloads requires only that the encapsulated packet be easily parsed (for example, checksum offload). However, optimizations such as LSO and LRO involve some processing of the options themselves since they must be replicated/merged across multiple packets. In these situations, it is desirable not to require changes to the offload logic to handle the introduction of new options. To enable this, some constraints are placed on the definitions of options to allow for simple processing rules:
現代のNICは現在、パケットの効率的な処理を可能にするためのさまざまなオフロードを提供しています。これらのオフロードの多くの実装では、カプセル化されたパケットが簡単に解析されることだけが必要です（たとえば、チェックサムオフロードなど）。ただし、LSOやLOのような最適化は、複数のパケットにわたって複製/マージされなければならないため、オプション自体の何らかの処理を伴います。このような状況では、新しいオプションの導入を処理するためにオフロードロジックの変更を必要としないことが望ましいです。これを有効にするために、簡単な処理ルールを許可するオプションの定義にいくつかの制約が配置されます。
* When performing LSO, a NIC MUST replicate the entire Geneve header and all options, including those unknown to the device, onto each resulting segment unless an option allows an exception. Conversely, when performing LRO, a NIC may assume that a binary comparison of the options (including unknown options) is sufficient to ensure equality and MAY merge packets with equal Geneve headers.
* LSOを実行するとき、NICは、オプションが例外を許可されていない限り、GeneVeヘッダー全体とデバイスに不明のものを含むすべてのオプションを含むすべてのオプションをそれぞれの各セグメントに複製する必要があります。逆に、LROを実行するとき、NICは、オプションのバイナリ比較（未知のオプションを含む）が平等を確実にするのに十分であり、同じGeneveヘッダーを持つパケットをマージすることができると仮定することができる。
* Options MUST NOT be reordered during the course of offload processing, including when merging packets for the purpose of LRO.
* LROの目的のためにパケットをマージするときなど、オフロード処理の過程でオプションを並べ替えないでください。
* NICs performing offloads MUST NOT drop packets with unknown options, including those marked as critical, unless explicitly configured to do so.
* オフロードを実行するNICSは、明示的に設定されていない限り、不明なものを含む、不明なオプションを使用してパケットを削除しないでください。
There is no requirement that a given implementation of Geneve employ the offloads listed as examples above. However, as these offloads are currently widely deployed in commercially available NICs, the rules described here are intended to enable efficient handling of current and future options across a variety of devices.
Geneveの特定の実装が上記の例としてリストされているオフロードを使用する必要はありません。しかしながら、これらのオフロードが現在市販のNICで広く展開されているので、ここで説明されている規則は、さまざまな装置にわたる現在および将来のオプションを効率的に処理することを可能にすることを目的としている。
Geneve is capable of encapsulating a wide range of protocols; therefore, a given implementation is likely to support only a small subset of the possibilities. However, as Ethernet is expected to be widely deployed, it is useful to describe the behavior of VLANs inside encapsulated Ethernet frames.
Geneveは広範囲のプロトコルをカプセル化することができます。したがって、特定の実装は可能性の小さなサブセットしかサポートしない可能性があります。ただし、イーサネットが広く展開されることが予想されるので、カプセル化されたイーサネットフレーム内のVLANの動作を説明するのに役立ちます。
As with any protocol, support for inner VLAN headers is OPTIONAL. In many cases, the use of encapsulated VLANs may be disallowed due to security or implementation considerations. However, in other cases, the trunking of VLAN frames across a Geneve tunnel can prove useful. As a result, the processing of inner VLAN tags upon ingress or egress from a tunnel endpoint is based upon the configuration of the tunnel endpoint and/or control plane and is not explicitly defined as part of the data format.
任意のプロトコルと同様に、内部VLANヘッダーのサポートはオプションです。多くの場合、セキュリティまたは実装の考慮のためにカプセル化されたVLANを使用することは許可されている可能性があります。しかしながら、他の場合には、Geneeveトンネルを横切るVLANフレームのトランキングは有用であることが証明され得る。結果として、トンネルエンドポイントからの入力または出力時の内部VLANタグの処理は、トンネルエンドポイントおよび/または制御プレーンの構成に基づいており、データフォーマットの一部として明示的に定義されていない。
Viewed exclusively from the data plane, Geneve is compatible with existing IP networks as it appears to most devices as UDP packets. However, as there are already a number of tunneling protocols deployed in network virtualization environments, there is a practical question of transition and coexistence.
データプレーンからのみ表示され、Geneveは、ほとんどのデバイスとしてUDPパケットとして表示されるため、既存のIPネットワークと互換性があります。ただし、ネットワーク仮想化環境では、すでに多数のトンネリングプロトコルが展開されているため、移行と共存の実用的な問題があります。
Since Geneve builds on the base data plane functionality provided by the most common protocols used for network virtualization (VXLAN and NVGRE), it should be straightforward to port an existing control plane to run on top of it with minimal effort. With both the old and new packet formats supporting the same set of capabilities, there is no need for a hard transition; tunnel endpoints directly communicating with each other can use any common protocol, which may be different even within a single overall system. As transit devices are primarily forwarding packets on the basis of the IP header, all protocols appear to be similar, and these devices do not introduce additional interoperability concerns.
Geneeveは、ネットワーク仮想化（VXLANとNVGRE）に使用される最も一般的なプロトコルによって提供されるベースデータプレーン機能を構築するので、既存のコントロールプレーンが最小限の努力でそれの上に実行されるように直接的であるべきです。同じ機能セットをサポートする古いパケットフォーマットの両方を使用すると、ハードトランジションは必要ありません。トンネルエンドポイントが互いに直接通信することは、単一のシステム全体でさえも異なる可能性がある一般的なプロトコルを使用できます。トランジット装置がIPヘッダに基づいてパケットを主に転送するので、すべてのプロトコルが類似しているように見え、これらのデバイスは追加の相互運用性の懸念を導入しません。
To assist with this transition, it is strongly suggested that implementations support simultaneous operation of both Geneve and existing tunneling protocols, as it is expected to be common for a single node to communicate with a mixture of other nodes. Eventually, older protocols may be phased out as they are no longer in use.
この遷移を支援するために、実装は、単一のノードと他のノードの混合と通信することが一般的であると予想されるように、実装がGENEVEと既存のトンネリングプロトコルの両方の同時動作をサポートすることが強く示唆されています。最終的には、古いプロトコルは使用されていないので段階的に段階的な場合があります。
As it is encapsulated within a UDP/IP packet, Geneve does not have any inherent security mechanisms. As a result, an attacker with access to the underlay network transporting the IP packets has the ability to snoop on, alter, or inject packets. Compromised tunnel endpoints or transit devices may also spoof identifiers in the tunnel header to gain access to networks owned by other tenants.
UDP / IPパケット内にカプセル化されると、GENEVEには固有のセキュリティメカニズムがありません。その結果、IPパケットを転送するアンダーレイネットワークへのアクセスを持つ攻撃者は、パケットをスヌープ、変更、または挿入することができます。侵入したトンネルエンドポイントまたはトランジットデバイスはまた、トンネルヘッダ内の識別子が他のテナントが所有するネットワークへのアクセスを得ることができる。
Within a particular security domain, such as a data center operated by a single service provider, the most common and highest-performing security mechanism is isolation of trusted components. Tunnel traffic can be carried over a separate VLAN and filtered at any untrusted boundaries.
単一のサービスプロバイダによって運営されているデータセンターなどの特定のセキュリティドメイン内では、最も一般的で最高のセキュリティメカニズムが信頼できるコンポーネントの分離です。トンネルトラフィックは別のVLANを介して伝送され、信頼されていない境界でフィルタリングできます。
When crossing an untrusted link, such as the general Internet, VPN technologies such as IPsec [RFC4301] should be used to provide authentication and/or encryption of the IP packets formed as part of Geneve encapsulation (see Section 6.1.1).
一般的なインターネットなどの信頼されていないリンクを交差させる場合、IPSec [RFC4301]などのVPNテクノロジを使用して、Geneveカプセル化の一部として形成されたIPパケットの認証および/または暗号化を提供する必要があります（セクション6.1.1を参照）。
Geneve does not otherwise affect the security of the encapsulated packets. As per the guidelines of BCP 72 [RFC3552], the following sections describe potential security risks that may be applicable to Geneve deployments and approaches to mitigate such risks. It is also noted that not all such risks are applicable to all Geneve deployment scenarios, i.e., only a subset may be applicable to certain deployments. An operator has to make an assessment based on their network environment, determine the risks that are applicable to their specific environment, and use appropriate mitigation approaches as applicable.
Geneveはそれ以外の場合はカプセル化されたパケットのセキュリティに影響しません。BCP 72 [RFC3552]のガイドラインに従って、次のセクションでは、Geneveの展開やそのリスクを軽減するためのアプローチに適用可能な潜在的なセキュリティリスクについて説明します。また、そのようなリスクのすべてがすべてのGeneve展開シナリオに適用可能ではない、すなわちサブセットのみが特定の展開に適用可能であり得ることもまた留意されたい。オペレータは、ネットワーク環境に基づいて評価を行わなければならず、それらの特定の環境に適用可能なリスクを決定し、適切な緩和アプローチを適切な場合に使用します。
Geneve is a network virtualization overlay encapsulation protocol designed to establish tunnels between NVEs over an existing IP network. It can be used to deploy multi-tenant overlay networks over an existing IP underlay network in a public or private data center. The overlay service is typically provided by a service provider, such as a cloud service provider or a private data center operator. This may or not may be the same provider as an underlay service provider. Due to the nature of multi-tenancy in such environments, a tenant system may expect data confidentiality to ensure its packet data is not tampered with (i.e., active attack) in transit or is a target of unauthorized monitoring (i.e., passive attack), for example, by other tenant systems or underlay service provider. A compromised network node or a transit device within a data center may passively monitor Geneve packet data between NVEs or route traffic for further inspection. A tenant may expect the overlay service provider to provide data confidentiality as part of the service, or a tenant may bring its own data confidentiality mechanisms like IPsec or TLS to protect the data end to end between its tenant systems. The overlay provider is expected to provide cryptographic protection in cases where the underlay provider is not the same as the overlay provider to ensure the payload is not exposed to the underlay.
Geneveは、既存のIPネットワーク上でNVES間のトンネルを確立するように設計されたネットワーク仮想化オーバーレイカプセル化プロトコルです。公共のデータセンターまたはプライベートデータセンターの既存のIPアンダーレイネットワークを介してマルチテナントオーバーレイネットワークを展開するために使用できます。オーバーレイサービスは通常、クラウドサービスプロバイダまたはプライベートデータセンターオペレータなどのサービスプロバイダによって提供される。これは、アンダーレイサービスプロバイダと同じプロバイダーである場合があります。このような環境でのマルチテナントの性質上、テナントシステムはデータの機密性を期待して、そのパケットデータが輸送中の（すなわち、アクティブな攻撃）、または不正な監視の対象（すなわち、受動的攻撃）を確実にすることを確実にすることができます。たとえば、他のテナントシステムやアンダーレイサービスプロバイダによって。データセンター内の侵入されたネットワークノードまたはトランジット装置は、さらなる検査のためにNVESまたは経路トラフィック間でGENEVEパケットデータを受動的に監視することができる。テナントは、オーバーレイサービスプロバイダがサービスの一部としてデータ機密性を提供することを期待しているか、またはテナントがIPSecまたはTLSのような独自のデータ機密性メカニズムを、データ端をそのテナントシステム間で終了するように保護することができる。オーバーレイプロバイダは、アンダーレイプロバイダがオーバーレイプロバイダと同じではない場合には、ペイロードがアンダーレイにさらされないようにする場合には暗号保護を提供することが予想されます。
If an operator determines data confidentiality is necessary in their environment based on their risk analysis -- for example, in multi-tenant environments -- then an encryption mechanism SHOULD be used to encrypt the tenant data end to end between the NVEs. The NVEs may use existing well-established encryption mechanisms, such as IPsec, DTLS, etc.
例えばマルチテナント環境では、リスク分析に基づいて環境でデータ機密性が必要である場合、暗号化メカニズムを使用して、テナントデータ端をNVES間の端に暗号化するために使用する必要があります。NVEは、IPSec、DTLSなどの既存の常に確立された暗号化メカニズムを使用することができます。
A tenant system in a customer premises (private data center) may want to connect to tenant systems on their tenant overlay network in a public cloud data center, or a tenant may want to have its tenant systems located in multiple geographically separated data centers for high availability. Geneve data traffic between tenant systems across such separated networks should be protected from threats when traversing public networks. Any Geneve overlay data leaving the data center network beyond the operator's security domain SHOULD be secured by encryption mechanisms, such as IPsec or other VPN technologies, to protect the communications between the NVEs when they are geographically separated over untrusted network links. Specification of data protection mechanisms employed between data centers is beyond the scope of this document.
顧客施設（プライベートデータセンター）のテナントシステム（プライベートデータセンター）は、パブリッククラウドデータセンターのテナントオーバーレイネットワーク上のテナントシステムに接続したい場合があります。また、テナントは、高さのために複数の地理的に分離されたデータセンターにあるテナントシステムを持っていることがあります。可用性。このような区切りのネットワーク間のテナントシステム間のGeneveデータトラフィックは、公衆ネットワークを通過するときに脅威から保護されるべきです。データセンターネットワークを介してオペレータのセキュリティドメインを超えて残したGENEVEオーバーレイデータは、NVES間の通信を信頼できないネットワークリンクを介して地理的に区切って保護するために、IPSecや他のVPNテクノロジなどの暗号化メカニズムによって保護されるべきです。データセンター間で採用されているデータ保護メカニズムの指定はこの文書の範囲を超えています。
The principles described in Section 4 regarding controlled environments still apply to the geographically separated data center usage outlined in this section.
管理環境に関するセクション4で説明されている原則は、このセクションで概説されている地理的に分離されたデータセンターの使用法に依然として適用されています。
Geneve encapsulation is used between NVEs to establish overlay tunnels over an existing IP underlay network. In a multi-tenant data center, a rogue or compromised tenant system may try to launch a passive attack, such as monitoring the traffic of other tenants, or an active attack, such as trying to inject unauthorized Geneve encapsulated traffic such as spoofing, replay, etc., into the network. To prevent such attacks, an NVE MUST NOT propagate Geneve packets beyond the NVE to tenant systems and SHOULD employ packet-filtering mechanisms so as not to forward unauthorized traffic between tenant systems in different tenant networks. An NVE MUST NOT interpret Geneve packets from tenant systems other than as frames to be encapsulated.
Geneveカプセル化は、既存のIPアンダーレイネットワーク上のオーバーレイトンネルを確立するためにNVES間で使用されます。マルチテナントデータセンターでは、不正または侵害されたテナントシステムは、他のテナントのトラフィックを監視するなど、スプーフィング、再生などの不正なジュニーカプセル化されたトラフィックを注入することを試みるなど、受動的な攻撃を開始することができます。など、ネットワーク内に。そのような攻撃を防ぐために、NVEはNVEをテナントシステムに向けてGENEVE PACKETを伝播してはならず、異なるテナントネットワーク内のテナントシステム間の不正トラフィックを転送しないようにパケットフィルタリングメカニズムを使用する必要があります。NVEは、カプセル化されるフレーム以外のテナントシステムからGENEVEパケットを解釈してはいけません。
A compromised network node or a transit device within a data center may launch an active attack trying to tamper with the Geneve packet data between NVEs. Malicious tampering of Geneve header fields may cause the packet from one tenant to be forwarded to a different tenant network. If an operator determines there is a possibility of such a threat in their environment, the operator may choose to employ data integrity mechanisms between NVEs. In order to prevent such risks, a data integrity mechanism SHOULD be used in such environments to protect the integrity of Geneve packets, including packet headers, options, and payload on communications between NVE pairs. A cryptographic data protection mechanism, such as IPsec, may be used to provide data integrity protection. A data center operator may choose to deploy any other data integrity mechanisms as applicable and supported in their underlay networks, although non-cryptographic mechanisms may not protect the Geneve portion of the packet from tampering.
データセンター内の侵入されたネットワークノードまたはトランジット装置は、NVES間のGeneveパケットデータを改ざんしようとしているアクティブな攻撃を起動することができる。 Geneveヘッダーフィールドの悪意のある改ざんは、あるテナントからのパケットを別のテナントネットワークに転送させることがあります。オペレータがそのような環境にそのような脅威がある可能性があると判断した場合、オペレータはNVS間でデータの整合性メカニズムを使用することを選択することができる。そのようなリスクを防ぐために、データの整合性メカニズムは、パケットヘッダー、オプション、およびNVEペア間の通信にペイロードを含むGENEVEパケットの整合性を保護するために、そのような環境で使用されるべきです。 IPsecなどの暗号化データ保護メカニズムを使用して、データの整合性保護を提供できます。データセンターオペレータは、非暗号化されていないメカニズムがパケットのGeneVe部分を改ざんから保護しない可能性があるが、該当する他のデータ整合性メカニズムをそれらのアンダーラインネットワークで展開することを選択することができる。
A rogue network device or a compromised NVE in a data center environment might be able to spoof Geneve packets as if it came from a legitimate NVE. In order to mitigate such a risk, an operator SHOULD use an authentication mechanism, such as IPsec, to ensure that the Geneve packet originated from the intended NVE peer in environments where the operator determines spoofing or rogue devices are potential threats. Other simpler source checks, such as ingress filtering for VLAN/MAC/IP addresses, reverse path forwarding checks, etc., may be used in certain trusted environments to ensure Geneve packets originated from the intended NVE peer.
データセンター環境における不正なネットワークデバイスまたは侵害されたNVEは、まるで正当なNVEから来たかのようにGeneeVEパケットを偽装できる可能性があります。このようなリスクを軽減するために、オペレータはIPSecなどの認証メカニズムを使用して、オペレータがスプーフィングまたは不正なデバイスが潜在的な脅威であると判断した環境でGeneveパケットが意図されたNVEピアから発生したことを確認する必要があります。VLAN / MAC / IPアドレスの入力フィルタリング、リバースパス転送チェックなどの他のより単純なソースチェックは、特定の信頼できる環境で使用されて、意図されたNVEピアから発生したGENEVE PACKETを確実にすることができます。
Options, if present in the packet, are generated and terminated by tunnel endpoints. As indicated in Section 2.2.1, transit devices may interpret the options. However, if the packet is protected by encryption from tunnel endpoint to tunnel endpoint (for example, through IPsec), transit devices will not have visibility into the Geneve header or options in the packet. In such cases, transit devices MUST handle Geneve packets as any other IP packet and maintain consistent forwarding behavior. In cases where options are interpreted by transit devices, the operator MUST ensure that transit devices are trusted and not compromised. The definition of a mechanism to ensure this trust is beyond the scope of this document.
パケットに存在する場合は、トンネルエンドポイントによって生成され、終了します。セクション2.2.1に示されているように、トランジットデバイスはオプションを解釈することがあります。ただし、パケットがトンネルエンドポイントからトンネルエンドポイントへの暗号化によって（たとえば、IPSecを介して）保護されている場合、トランジットデバイスはGeneveヘッダーまたはパケット内のオプションに表示されません。そのような場合、Transitデバイスは他のIPパケットとしてGENEVEパケットを処理し、一貫した転送動作を維持する必要があります。オプションがTransitデバイスによって解釈される場合、オペレータはトランジットデバイスが信頼されていて侵害されないようにする必要があります。この信頼を確実にするためのメカニズムの定義は、この文書の範囲を超えています。
In typical data center networks where IP multicasting is not supported in the underlay network, multicasting may be supported using multiple unicast tunnels. The same security requirements as described in the above sections can be used to protect Geneve communications between NVE peers. If IP multicasting is supported in the underlay network and the operator chooses to use it for multicast traffic among tunnel endpoints, then the operator in such environments may use data protection mechanisms, such as IPsec with multicast extensions [RFC5374], to protect multicast traffic among Geneve NVE groups.
IPマルチキャストがアンダーラインネットワークでサポートされていない典型的なデータセンターネットワークでは、マルチキャストは複数のユニキャストトンネルを使用してサポートされてもよい。上記のセクションで説明したのと同じセキュリティ要件を使用して、NVEピア間のGeneve通信を保護することができます。アンダーラインネットワークでIPマルチキャストがサポートされており、オペレータがトンネルエンドポイントの間でマルチキャストトラフィックのマルチキャストトラフィックの使用を選択した場合、そのような環境のオペレータは、マルチキャストトラフィックを保護するために、Multicast Extensions [RFC5374]などのIPsecなどのデータ保護メカニズムを使用することがあります。ジュネーブNVEグループ。
A Network Virtualization Authority (NVA) as outlined in [RFC8014] may be used as a control plane for configuring and managing the Geneve NVEs. The data center operator is expected to use security mechanisms to protect the communications between the NVA and NVEs and to use authentication mechanisms to detect any rogue or compromised NVEs within their administrative domain. Data protection mechanisms for control plane communication or authentication mechanisms between the NVA and NVEs are beyond the scope of this document.
[RFC8014]で概説されているネットワーク仮想化局（NVA）は、GENEVE NVESを構成し管理するためのコントロールプレーンとして使用できます。データセンター演算子は、セキュリティメカニズムを使用して、NVAとNVAとの間の通信を保護し、認証メカニズムを使用して、その管理ドメイン内の不正または侵入されたNVESを検出することが期待されています。Control Plane通信またはNVAとNVE間の認証メカニズムのためのデータ保護メカニズムは、この文書の範囲を超えています。
IANA has allocated UDP port 6081 in the "Service Name and Transport Protocol Port Number Registry" [IANA-SN] as the well-known destination port for Geneve:
IANAは、GENEVEの有名な宛先ポートとして、「サービス名とトランスポートプロトコルポート番号レジストリ」[IANA-SN]にUDPポート6081を割り当てました。
Service Name: geneve
Transport Protocol(s): UDP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: Generic Network Virtualization Encapsulation (Geneve)
Reference: [RFC8926]
Port Number: 6081
In addition, IANA has created a new subregistry titled "Geneve Option Class" for option classes. This registry has been placed under a new "Network Virtualization Overlay (NVO3)" heading in the IANA protocol registries [IANA-PR]. The "Geneve Option Class" registry consists of 16-bit hexadecimal values along with descriptive strings, assignee/ contact information, and references. The registration rules for the new registry are (as defined by [RFC8126]):
さらに、IANAはオプションクラスの「Geneve Option Class」というタイトルの新しいサブレジストを作成しました。このレジストリは、IANAプロトコルレジストリでの新しい「ネットワーク仮想化オーバーレイ（NVO3）」の下に配置されています[IANA-PR]。"Geneve Option Class"レジストリは、説明文字列、担当者/連絡先情報、および参照とともに、16ビットの16進値で構成されています。新しいレジストリの登録規則は（[RFC8126]で定義されている）です。
+===============+=========================+
| Range | Registration Procedures |
+===============+=========================+
| 0x0000-0x00FF | IETF Review |
+---------------+-------------------------+
| 0x0100-0xFEFF | First Come First Served |
+---------------+-------------------------+
| 0xFF00-0xFFFF | Experimental Use |
+---------------+-------------------------+
Table 1: Geneve Option Class Registry Ranges
表1：GENEVEオプションクラスレジストリ範囲
[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.、 "User Datagram Protocol"、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<https://www.rfc-editor.org/info/rfc768>。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.
[RFC0792] Postel、J.、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、DOI 10.17487 / RFC0792、1981年9月、<https：//www.rfc-editor.org/info/rfc792>。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden、R.、ED。、「インターネットホストの要求 - 通信層の要求」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<https：//www.rfc-editor.org/info/RFC1122>。
[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.Theering、 "Path Mtu Discovery"、RFC 1191、DOI 10.17487 / RFC1191、1990年11月、<https：//www.rfc-editor.org/info/rfc1191>。
[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カプセル化」、RFC 2003、DOI 10.17487 / RFC2003、1996年10月、<https：//www.rfc-editor.org/info/rfc2003>。
[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、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.
[RFC4443] Conta、A.、Theering、S.およびM.Gupta、Internet Protocol Version 6（IPv6）仕様のICMPv6（ICMPv6）、STD 89、RFC 4443、DOI 10.17487 /RFC4443、2006年3月、<https://www.rfc-editor.org/info/rfc4443>。
[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>。
[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>。
[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. Rekhter, "Framework for Data Center (DC) Network Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 2014, <https://www.rfc-editor.org/info/rfc7365>.
[RFC7365] Lasserre、M.、Balus、F.、Morin、T.、Bitar、N.、Y.Rekhter、 "データセンターのフレームワーク（DC）ネットワーク仮想化"、RFC 7365、DOI 10.17487 / RFC7365、2014年10月<https：//www.rfc-editor.org/info/rfc7365>。
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8085] eggert、L.、Fairhurst、G.、およびG.Shepherd、 "UDP使用ガイドライン"、BCP 145、RFC 8085、DOI 10.17487 / RFC8085、2017年3月、<https：//www.rfc-editor.org/ info / rfc8085>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.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] The'th、S.およびR.hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https：//www.rfc-editor.org/ info / rfc8200>。
[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.、Theer、S.、Mogul、J.、およびR. Hinden、Ed。、「IPバージョン6のためのパスMTUディスカバリー」、STD 87、RFC 8201、DOI 10.17487 / RFC8201、2017年7月、<https://www.rfc-editor.org/info/rfc8201>。
[ETYPES] IANA, "IEEE 802 Numbers", <https://www.iana.org/assignments/ieee-802-numbers>.
[ETYPES] IANA、「IEEE 802番号」、<https：//www.iana.org/assignments/ieee-802-numbers>。
[IANA-PR] IANA, "Protocol Registries", <https://www.iana.org/protocols>.
[IANA-PR] IANA、「プロトコルレジストリ」、<https://www.iana.org/protocols>。
[IANA-SN] IANA, "Service Name and Transport Protocol Port Number Registry", <https://www.iana.org/assignments/service-names-port-numbers>.
[IANA-SN] IANA、「サービス名とトランスポートプロトコルポート番号レジストリ」、<https://www.iana.org/assignments/service-names-port-numbers>。
[IEEE.802.1Q_2018] IEEE, "IEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks", DOI 10.1109/IEEESTD.2018.8403927, IEEE 802.1Q-2018, July 2018, <http://ieeexplore.ieee.org/servlet/ opac?punumber=8403925>.
[IEEE.802.1Q_2018] IEEE、「地元と首都圏ネットワークのIEEE規格 - ブリッジとブリッジネットワーク」、DOI 10.1109 / IEEEESTD.2018.8403927、2018年7月、<http://ieeexplore.ieee。ORG / Servlet / Opac？Purumber = 8403925>。
[INTAREA-TUNNELS] Touch, J. and M. Townsley, "IP Tunnels in the Internet Architecture", Work in Progress, Internet-Draft, draft-ietf-intarea-tunnels-10, 12 September 2019, <https://tools.ietf.org/html/draft-ietf-intarea-tunnels-10>.
[Intarea-Tunnels] Touch、J.およびM. Townsley、「インターネットアーキテクチャのIPトンネル」、進行中の作業、インターネットドラフト、Draft-IETF-Intarea-Tunnels-10,12,12、<https：//tools.ietf.org/html/draft-ietf-intarea-tunnels-10>>。
[NVO3-DATAPLANE] Bitar, N., Lasserre, M., Balus, F., Morin, T., Jin, L., and B. Khasnabish, "NVO3 Data Plane Requirements", Work in Progress, Internet-Draft, draft-ietf-nvo3-dataplane-requirements-03, 15 April 2014, <https://tools.ietf.org/html/draft-ietf-nvo3-dataplane-requirements-03>.
[NVO3データプレーン]ビットー、N.、Lasserre、M.、Flus、F.、Morin、T.、Jin、L.、B. Khasnabish、 "NVO3データプレーン要件"、進行中の作業、インターネットドラフト、draft-ietf-nvo3-dataplane-resustry-03,15 4月15日、<https：//tools.ietf.org/html/draft-ietf-nvo3-dataplane-requireless-03>。
[NVO3-ENCAP] Boutros, S., "NVO3 Encapsulation Considerations", Work in Progress, Internet-Draft, draft-ietf-nvo3-encap-05, 17 February 2020, <https://tools.ietf.org/html/draft-ietf-nvo3-encap-05>.
[NVO3-Encap] Boutros、S.、 "NVO3カプセル化に関する考慮事項"、進行中の作業、インターネットドラフト、ドラフト-IETF-NVO3-ENCAP-05,2020、<https：//tools.ietf.org/html/ draft-ietf-nvo3-encap-05>。
[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.、「差別化サービスとトンネル」、RFC 2983、DOI 10.17487 / RFC2983、2000年10月、<https://www.rfc-editor.org/info/rfc2983>。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC3031]ローゼン、E.、Viswanathan、A.およびR.Callon、 "Multiprotocol Label Switche Architecture"、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、<https：//www.rfc-editor.org/info/ RFC3031>。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.
[RFC3552] Rescorla、E.およびB.Korver、「セキュリティ上のRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、DOI 10.17487 / RFC3552、2003年7月、<https：//www.rfc-editor.org/情報/ RFC3552>。
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, <https://www.rfc-editor.org/info/rfc3985>.
[RFC3985]ブライアント、S。、ED。P. Pate、Ed。、「疑似ワイヤーエミュレーションエッジツーエッジ（PWE3）アーキテクチャ」、RFC 3985、DOI 10.17487 / RFC3985、2005年3月、<https：//www.rfc-editor.org/info/rfc3985>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S.およびK.SEO、「インターネットプロトコルのためのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<https：//www.rfc-editor.org/info/rfc4301>。
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008, <https://www.rfc-editor.org/info/rfc5374>.
[RFC5374] Weis、B.、Gross、G、およびD. Ignjatic、「インターネットプロトコルのセキュリティアーキテクチャへのマルチキャスト拡張」、RFC 5374、DOI 10.17487 / RFC5374、2008年11月、<https：//www.rfc-editor.org/info/rfc5374>。
[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：//www.rfc-editor.org/info/rfc6438>
[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.ライト「仮想拡張ローカルエリアネットワーク（VXLAN）：Layer 3ネットワーク上の仮想化レイヤ2ネットワークを重ねるフレームワーク「RFC 7348、DOI 10.17487 / RFC7348、2014年8月、<https：//www.rfc-editor.org/info/rfc7348>。
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network Virtualization Using Generic Routing Encapsulation", RFC 7637, DOI 10.17487/RFC7637, September 2015, <https://www.rfc-editor.org/info/rfc7637>.
[RFC7637] Garg、P.、ED。Y。、「NVGRE：汎用ルーティングカプセル化を使用したネットワーク仮想化」、RFC 7637、DOI 10.17487 / RFC7637、2015年9月、<https：//www.rfc-editor.org/info/rfc7637>。
[RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. Narten, "An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3)", RFC 8014, DOI 10.17487/RFC8014, December 2016, <https://www.rfc-editor.org/info/rfc8014>.
[RFC8014]ブラック、D.、Hudson、J.、Kreeger、L.、Lasserre、M.、およびT.Narten、「層3（Layer 3（NVO3）上のデータセンターネットワーク仮想化のためのアーキテクチャ（NVO3）」、RFC 8014、DOI 10.17487/ RFC8014、2016年12月、<https：//www.rfc-editor.org/info/rfc8014>。
[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。、Crabbe、E.、Xu、X.、およびT.Herbert、「Gre-In-UDPカプセル化」、RFC 8086、DOI 10.17487 / RFC8086、2017年3月、<https：//www.rfc-editor.org/info/rfc8086>。
[RFC8293] Ghanwani, A., Dunbar, L., McBride, M., Bannai, V., and R. Krishnan, "A Framework for Multicast in Network Virtualization over Layer 3", RFC 8293, DOI 10.17487/RFC8293, January 2018, <https://www.rfc-editor.org/info/rfc8293>.
[RFC8293]ガンワニ、A.、Dunbar、L.、McBride、M.、Bannai、V. R. Krishnan、「層3上のネットワーク仮想化におけるマルチキャストのためのフレームワーク」、RFC 8293、DOI 10.17487 / RFC8293、1月2018年、<https：//www.rfc-editor.org/info/rfc8293>。
[VL2] "VL2: A Scalable and Flexible Data Center Network", ACM SIGCOMM Computer Communication Review, DOI 10.1145/1594977.1592576, August 2009, <https://dl.acm.org/doi/10.1145/1594977.1592576>.
[VL2] "VL2：スケーラブルで柔軟なデータセンターネットワーク"、ACM SIGCOMM Computer Compulting Review、DOI 10.1145 / 1594977.1592576、<https：//dl.acm.org/doi/10.1145/1594977.1592577>。
Acknowledgements
謝辞
The authors wish to acknowledge Puneet Agarwal, David Black, Sami Boutros, Scott Bradner, Martín Casado, Alissa Cooper, Roman Danyliw, Bruce Davie, Anoop Ghanwani, Benjamin Kaduk, Suresh Krishnan, Mirja Kühlewind, Barry Leiba, Daniel Migault, Greg Mirksy, Tal Mizrahi, Kathleen Moriarty, Magnus Nyström, Adam Roach, Sabrina Tanamal, Dave Thaler, Éric Vyncke, Magnus Westerlund, and many other members of the NVO3 Working Group for their reviews, comments, and suggestions.
著者らは、PuleTo Agarwal、David Black、Sami Boutros、Scott Bradner、MartínSasado、Alissa Cooper、Roman DanyLiw、Bruce Davie、Anoop Ghanwani、Benjamin Kakuk、Surry Leiba、Daniel Migault、Greg Migauth、Tal Mizrahi、Kathleen Moriarty、Magnus Nystrom、Adam Roach、Sabrina Tanamal、Dave Thaler、Eric Vyncke、Magnus Westerlund、およびその他の多くのメンバーのレビュー、コメント、および提案のための他の多くのメンバー。
The authors would like to thank Sam Aldrin, Alia Atlas, Matthew Bocci, Benson Schliesser, and Martin Vigoureux for their guidance throughout the process.
著者らは、サンプアルドリ、アリアアトラス、マシューボッキ、ベンソンシュリーザー、そしてマーティン・ビジーユー氏に、プロセス全体を通して彼らのガイダンスを感謝したいと思います。
Contributors
貢献者
The following individuals were authors of an earlier version of this document and made significant contributions:
次の個人は、この文書の以前のバージョンの著者であり、重要な貢献をしました。
Pankaj Garg Microsoft Corporation 1 Microsoft Way Redmond, WA 98052 United States of America
Pankaj Garg Microsoft Corporation 1 Microsoft Way Redmond、WA 98052アメリカ合衆国
Email: pankajg@microsoft.com
Chris Wright Red Hat Inc. 1801 Varsity Drive Raleigh, NC 27606 United States of America
Chris Wright Red Hat Inc. 1801 Varsity Drive Raleigh、NC 27606アメリカ合衆国
Email: chrisw@redhat.com
Kenneth Duda Arista Networks 5453 Great America Parkway Santa Clara, CA 95054 United States of America
Kenneth Duda Arista Networks 5453 Great America Parkwayサンタクララ、CA 95054アメリカ合衆国
Email: kduda@arista.com
Dinesh G. Dutt Independent
Dinesh G. Dutt Independent
Email: didutt@gmail.com
Jon Hudson Independent
Jon Hudson Independent
Email: jon.hudson@gmail.com
Ariel Hendel Facebook, Inc. 1 Hacker Way Menlo Park, CA 94025 United States of America
Ariel Hendel Facebook、Inc。1ハッカーウェイMenlo Park、CA 94025アメリカ合衆国
Email: ahendel@fb.com
Authors' Addresses
著者の住所
Jesse Gross (editor)
Jesse Gross（編集）
Email: jesse@kernel.org
Ilango Ganga (editor) Intel Corporation 2200 Mission College Blvd. Santa Clara, CA 95054 United States of America
Ilango Ganga（編集）Intel Corporation 2200 Mission College Blvd.サンタクララ、CA 95054アメリカ合衆国
Email: ilango.s.ganga@intel.com
T. Sridhar (editor) VMware, Inc. 3401 Hillview Ave. Palo Alto, CA 94304 United States of America
T.Sridhar（編集）VMware、Inc。3401 HillView Ave Palo Alto、CA 94304アメリカ
Email: tsridhar@utexas.edu