Internet Engineering Task Force (IETF) G. Mirsky
Request for Comments: 9772 Ericsson
Category: Standards Track S. Boutros
ISSN: 2070-1721 Ciena
D. Black
Dell
S. Pallagatti
VMware
May 2025
Geneve (Generic Network Virtualization Encapsulation) is a flexible and extensible network virtualization overlay protocol designed to encapsulate network packets for transport across underlying physical networks. This document specifies the requirements and provides a framework for Operations, Administration, and Maintenance (OAM) in Geneve networks. It outlines the OAM functions necessary to monitor, diagnose, and troubleshoot Geneve overlay networks to ensure proper operation and performance. The document aims to guide the implementation of OAM mechanisms within the Geneve protocol to support network operators in maintaining reliable and efficient virtualized network environments.
Geneve（Generic Network Virtualization capsulation）は、基礎となる物理ネットワークを横切る輸送のためにネットワークパケットをカプセル化するように設計された柔軟で拡張可能なネットワーク仮想化オーバーレイプロトコルです。このドキュメントは、要件を指定し、Geneveネットワークの運用、管理、およびメンテナンス（OAM）のフレームワークを提供します。適切な動作とパフォーマンスを確保するために、Geneve Overlayネットワークを監視、診断、およびトラブルシューティングするために必要なOAM機能の概要を説明します。このドキュメントの目的は、Jeneveプロトコル内のOAMメカニズムの実装をガイドし、信頼性が高く効率的な仮想化ネットワーク環境の維持をサポートすることです。
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/rfc9772.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9772で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Conventions Used in This Document
1.1.1. Requirements Language
1.1.2. Acronyms
2. The Applicability of Active OAM Protocols in Geneve Networks
2.1. Requirements for Active OAM Protocols in Geneve Networks
2.2. Defect Detection and Troubleshooting in Geneve Network with
Active OAM
2.2.1. Echo Request and Echo Reply in Geneve Tunnel
2.3. Active OAM Encapsulation in Geneve
3. IANA Considerations
4. Security Considerations
5. References
5.1. Normative References
5.2. Informative References
Acknowledgments
Authors' Addresses
Geneve [RFC8926] is designed to support various scenarios of network virtualization. It encapsulates multiple protocols, such as Ethernet and IPv4/IPv6, and includes metadata within the Geneve message.
Geneve [RFC8926]は、ネットワーク仮想化のさまざまなシナリオをサポートするように設計されています。イーサネットやIPv4/IPv6などの複数のプロトコルをカプセル化し、GeneVeメッセージ内にメタデータを含みます。
Operations, Administration, and Maintenance (OAM) protocols provide fault management and performance monitoring functions necessary for comprehensive network operation. Active OAM protocols, as defined in [RFC7799], utilize specially constructed packets injected into the network. OAM protocols such as ICMP and ICMPv6 ([RFC0792] and [RFC4443] respectively), Bidirectional Forwarding Detection (BFD) [RFC5880], and the Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] are examples of active OAM protocols. To ensure that performance metrics or detected failures are accurately related to a particular Geneve flow, it is critical that these OAM test packets share fate, i.e., are in-band, with the overlay data packets of that monitored flow when traversing the underlay network. In this document, "in-band OAM" is interpreted as follows:
操作、管理、およびメンテナンス（OAM）プロトコルは、包括的なネットワーク操作に必要な障害管理およびパフォーマンス監視機能を提供します。[RFC7799]で定義されているアクティブなOAMプロトコルは、ネットワークに注入された特別に構築されたパケットを利用します。ICMPおよびICMPV6（[RFC0792]および[RFC443]などのOAMプロトコル、双方向転送検出（BFD）[RFC5880]、および単純な双方向活性測定プロトコル（STAMP）[RFC8762]は、アクティブオームプロトコルの結果です。パフォーマンスメトリックまたは検出された障害が特定のGeneveフローに正確に関連するようにするために、これらのOAMテストパケットが運命を共有することが重要です。このドキュメントでは、「インバンドOAM」が次のように解釈されます。
* In-band OAM is an active or hybrid OAM method, as defined in [RFC7799], that traverses the same set of links and interfaces and receives the same Quality of Service treatment as the monitored object. In this context, the monitored object refers to either the entire Geneve tunnel or a specific tenant flow within a given Geneve tunnel.
* インバンドOAMは、[RFC7799]で定義されているように、アクティブまたはハイブリッドOAMメソッドです。これは、同じリンクとインターフェイスのセットを通過し、監視対象オブジェクトと同じ品質のサービス処理を受信します。これに関連して、監視されたオブジェクトは、Geneveトンネル全体または特定のGeneveトンネル内の特定のテナントフローのいずれかを指します。
Section 2.1 lists the general requirements for active OAM protocols in the Geneve overlay network. IP encapsulation meets these requirements and is suitable for encapsulating active OAM protocols within a Geneve overlay network. Active OAM messages in a Geneve overlay network are exchanged between two Geneve tunnel endpoints; each endpoint may be the tenant-facing interface of the Network Virtualization Edge (NVE) or another device acting as a Geneve tunnel endpoint. Testing end-to-end between tenants is out of scope. For simplicity, this document uses an NVE to represent the Geneve tunnel endpoint. Refer to [RFC7365] and [RFC8014] for detailed definitions and descriptions of an NVE.
セクション2.1では、Geneve Overlay NetworkのアクティブなOAMプロトコルの一般的な要件を示します。IPカプセル化はこれらの要件を満たしており、Geneveオーバーレイネットワーク内のアクティブなOAMプロトコルのカプセル化に適しています。Geneve Overlayネットワーク内のアクティブなOAMメッセージは、2つのGeneveトンネルエンドポイント間で交換されます。各エンドポイントは、ネットワーク仮想化エッジ（NVE）のテナント向けインターフェイスまたはGeneveトンネルエンドポイントとして機能する別のデバイスである場合があります。テナント間のエンドツーエンドのテストは範囲外です。簡単にするために、このドキュメントはNVEを使用してGeneveトンネルエンドポイントを表します。NVEの詳細な定義と説明については、[RFC7365]および[RFC8014]を参照してください。
The IP encapsulation of Geneve OAM defined in this document applies to an overlay service by introducing a Management Virtual Network Identifier (VNI), which can be used in combination with various values of the Protocol Type field in the Geneve header, such as Ethertypes for IPv4 or IPv6. The analysis and definition of other types of OAM encapsulation in Geneve are outside the scope of this document.
このドキュメントで定義されているGeneve OAMのIPカプセル化は、IPv4またはIPv6の倫理など、Geneveヘッダーのプロトコルタイプフィールドのさまざまな値と組み合わせて使用できる管理仮想ネットワーク識別子（VNI）を導入することにより、オーバーレイサービスに適用されます。Geneveの他のタイプのOAMカプセル化の分析と定義は、このドキュメントの範囲外です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
Geneve:
Geneve：
Generic Network Virtualization Encapsulation
一般的なネットワーク仮想化カプセル化
NVO3:
NVO3：
Network Virtualization over Layer 3
レイヤー3上のネットワーク仮想化
OAM:
OAM:
Operations, Administration, and Maintenance
運用、管理、およびメンテナンス
VNI:
VNI:
Virtual Network Identifier
仮想ネットワーク識別子
BFD:
BFD:
Bidirectional Forwarding Detection
双方向転送検出
STAMP:
スタンプ：
Simple Two-way Active Measurement Protocol
単純な双方向アクティブ測定プロトコル
NVE:
NVE:
Network Virtualization Edge
ネットワーク仮想化エッジ
OAM protocols, whether part of fault management or performance monitoring, are intended to provide reliable information that can be used to detect a failure, identify the defect, and localize it, thus helping to identify and apply corrective actions to minimize the negative impact on service. Several OAM protocols are used to perform these functions; these protocols require demultiplexing at the receiving instance of Geneve. To improve the accuracy of the correlation between the condition experienced by the monitored Geneve tunnel and the state of the OAM protocol, the OAM encapsulation is required to comply with the following requirements:
OAMプロトコルは、障害管理またはパフォーマンスモニタリングの一部であれ、障害を検出し、欠陥を特定し、それをローカライズするために使用できる信頼できる情報を提供することを目的としているため、サービスへのマイナスの影響を最小限に抑えるために是正措置を特定して適用することができます。いくつかのOAMプロトコルを使用して、これらの機能を実行します。これらのプロトコルには、Geneveの受信インスタンスでの非gultiplexを必要とします。監視されているGeneveトンネルが経験する状態とOAMプロトコルの状態との間の相関関係の精度を改善するには、OAMカプセル化が次の要件に準拠するために必要です。
Requirement 1: Geneve OAM test packets MUST share the same fate as the data traffic of the monitored Geneve tunnel. Specifically, the OAM test packets MUST be in-band with the monitored traffic and follow the same overlay and transport paths as packets carrying data payloads in the forward direction, i.e., from the ingress toward the egress endpoint(s) of the OAM test.
要件1：Geneve OAMテストパケットは、監視されているGeneveトンネルのデータトラフィックと同じ運命を共有する必要があります。具体的には、OAMテストパケットは、監視対象のトラフィックを使用して帯域内にあり、フォワード方向にデータペイロードを運ぶパケットと同じオーバーレイとトランスポートパスに従う必要があります。
An OAM protocol MAY be employed to monitor an entire Geneve tunnel. In this case, test packets could be in-band relative to a subset of tenant flows transported over the Geneve tunnel. If the goal is to monitor the conditions experienced by the flow of a particular tenant, the test packets MUST be in-band with that specific flow within the Geneve tunnel. Both scenarios are discussed in detail in Section 2.2.
OAMプロトコルを使用して、Geneveトンネル全体を監視することができます。この場合、テストパケットは、Geneveトンネル上に輸送されるテナントフローのサブセットと比較して帯域内にある可能性があります。目標が特定のテナントの流れによって経験される条件を監視することである場合、テストパケットは、Geneveトンネル内のその特定の流れで帯域内でなければなりません。両方のシナリオについては、セクション2.2で詳しく説明します。
Requirement 2: The encapsulation of OAM control messages and data packets in the underlay network MUST be indistinguishable.
要件2：アンダーレイネットワーク内のOAM制御メッセージとデータパケットのカプセル化は、区別できない必要があります。
Requirement 3: The presence of an OAM control message in a Geneve packet MUST be unambiguously identifiable to Geneve functionality, such as at endpoints of Geneve tunnels.
要件3：Geneveパケット内のOAM制御メッセージの存在は、GeneveトンネルのエンドポイントなどのGeneve機能を明確に識別できる必要があります。
Requirement 4: OAM test packets MUST NOT be forwarded to a tenant system.
要件4：OAMテストパケットをテナントシステムに転送してはなりません。
A test packet generated by an active OAM protocol, whether for defect detection or performance measurement, MUST be in-band with the tunnel or data flow being monitored, as specified in Requirement 1. In environments where multiple paths through the domain are available, underlay transport nodes can be programmed to use characteristic information to balance the load across known paths. It is essential that test packets follow the same route -- that is, traverse the same set of nodes and links as a data packet of the monitored flow. Therefore, the following requirement supports OAM packet fate-sharing with the data flow.
欠陥検出またはパフォーマンス測定の場合でも、アクティブなOAMプロトコルによって生成されたテストパケットは、要件で指定されているように、トンネルまたはデータフローを監視する必要があります。ドメインを通る複数のパスが利用可能な環境では、既知のパス全体の負荷のバランスをとるために特徴的な情報を使用するようにプログラムできます。テストパケットは同じルートをたどることが不可欠です。つまり、監視されたフローのデータパケットと同じノードとリンクのセットを通過します。したがって、次の要件は、データフローを使用したOAMパケットの運命共有をサポートします。
Requirement 5: There MUST be a way to encode entropy information into the underlay forwarding scheme so that OAM packets take the same data-flow paths as the transit traffic flows.
要件5：OAMパケットがトランジットトラフィックが流れるのと同じデータフローパスをとるように、エントロピー情報をアンダーレイ転送スキームにエンコードする方法が必要です。
This section considers two scenarios where active OAM is used to detect and localize defects in a Geneve network. Figure 1 presents an example of a Geneve domain.
このセクションでは、Geneveネットワーク内の欠陥を検出およびローカライズするためにアクティブなOAMを使用する2つのシナリオを検討します。図1は、Geneveドメインの例を示しています。
+--------+ +--------+
| Tenant +--+ +----| Tenant |
| VNI 28 | | | | VNI 35 |
+--------+ | ................ | +--------+
| +----+ . . +----+ |
| | NVE|--. .--| NVE| |
+--| A | . . | B |---+
+----+ . . +----+
/ . .
/ . Geneve .
+--------+ / . Network .
| Tenant +--+ . .
| VNI 35 | . .
+--------+ ................
|
+----+
| NVE|
| C |
+----+
|
|
=====================
| |
+--------+ +--------+
| Tenant | | Tenant |
| VNI 28 | | VNI 35 |
+--------+ +--------+
Figure 1: An Example of a Geneve Domain
図1：Geneveドメインの例
In the first case, consider when a communication problem between Network Virtualization Edge (NVE) device A and NVE C exists. Upon investigation, the operator discovers that the forwarding in the IP underlay network is working accordingly. Still, the Geneve connection is unstable for all NVE A and NVE C tenants. Detection, troubleshooting, and localization of the problem can be done regardless of the VNI value.
最初のケースでは、ネットワーク仮想化エッジ（NVE）デバイスAとNVE Cの間の通信問題が存在する場合を検討してください。調査すると、オペレーターは、IPアンダーレイネットワークの転送がそれに応じて機能していることを発見します。それでも、Geneve接続はすべてのNVE AおよびNVE Cテナントにとって不安定です。問題の検出、トラブルシューティング、およびローカリゼーションは、VNI値に関係なく実行できます。
In the second case, traffic on VNI 35 between NVE A and NVE B has no problems, as on VNI 28 between NVE A and NVE C. However, traffic on VNI 35 between NVE A and NVE C experiences problems, for example, excessive packet loss.
2番目のケースでは、NVE AとNVE Bの間のVNI 35のトラフィックは、NVE AとNVE Cの間のVNI 28のように問題はありません。ただし、NVE AとNVE Cの間のVNI 35のトラフィックは、たとえば過剰なパケット損失などの問題を経験します。
The first case can be detected and investigated using any VNI value, whether it connects tenant systems or not; however, to conform to Requirement 4, OAM test packets SHOULD be transmitted on a VNI that doesn't have any tenants. Such a Geneve tunnel is dedicated to carrying only control and management data between the tunnel endpoints, so it is referred to as a "Geneve control channel" and that VNI is referred to as the "Management VNI". A configured VNI MAY be used to identify the control channel, but it is RECOMMENDED that the default value 1 be used as the Management VNI. Encapsulation of test packets using the Management VNI is discussed in Section 2.3.
最初のケースは、テナントシステムを接続するかどうかにかかわらず、VNI値を使用して検出および調査できます。ただし、要件4に準拠するには、OAMテストパケットをテナントを持たないVNIに送信する必要があります。このようなGeneveトンネルは、トンネルのエンドポイント間に制御データと管理データのみを運ぶことに専念するため、「Geneve Controlチャネル」と呼ばれ、VNIは「管理VNI」と呼ばれます。構成されたVNIを使用してコントロールチャネルを識別できますが、デフォルト値1を管理VNIとして使用することをお勧めします。管理VNIを使用したテストパケットのカプセル化については、セクション2.3で説明します。
The control channel of a Geneve tunnel MUST NOT carry tenant data. As no tenants are connected using the control channel, a system that supports this specification MUST NOT forward a packet received over the control channel to any tenant. A packet received by the system that supports this specification over the control channel MUST be forwarded if and only if it is sent onto the control channel of the concatenated Geneve tunnel. Else, it MUST be terminated locally. The Management VNI SHOULD be terminated on the tenant-facing side of the Geneve encapsulation/decapsulation functionality, not the DC-network-facing side (per definitions in Section 4 of [RFC8014]), so that Geneve encap/decap functionality is included in its scope. This approach causes an active OAM packet, e.g., an ICMP echo request, to be decapsulated in the same fashion as any other received Geneve packet. In this example, the resulting ICMP packet is handed to NVE's local management functionality for the processing which generates an ICMP echo reply. The ICMP echo reply is encapsulated in Geneve (as specified in Section 2.3) for forwarding it back to the NVE that sent the echo request. One advantage of this approach is that a repeated ICMP echo request/reply test could detect an intermittent problem in Geneve encap/decap hardware, which would not be tested if the Management VNI were handled as a "special case" at the DC-network-facing interface.
Geneveトンネルの制御チャネルは、テナントデータを運ばないでください。コントロールチャネルを使用してテナントが接続されていないため、この仕様をサポートするシステムは、コントロールチャネルを介して受信したパケットを任意のテナントに転送してはなりません。制御チャネル上でこの仕様をサポートするシステムが受信したパケットは、連結されたGeneveトンネルの制御チャネルに送信された場合にのみ転送する必要があります。そうでなければ、ローカルで終了する必要があります。管理VNIは、DCネットワークの向き側ではなく、Geneveカプセル化/脱カプセル化機能のテナント面で終了する必要があります（[RFC8014]のセクション4の定義ごと）。このアプローチにより、アクティブなOAMパケット、たとえばICMPエコーリクエストが、他の受信したGeneveパケットと同じ方法で脱カプセル化されます。この例では、結果のICMPパケットは、ICMPエコー応答を生成する処理のためにNVEのローカル管理機能に渡されます。ICMPエコー応答は、エコーリクエストを送信したNVEに転送するために、Geneve（セクション2.3で指定されている）にカプセル化されています。このアプローチの利点の1つは、繰り返されるICMPエコーリクエスト/返信テストが、Geneve Encap/Decapハードウェアの断続的な問題を検出できることです。これは、管理VNIがDCネットワークフェイスインターフェイスで「特別なケース」として処理された場合にテストされません。
The second case is when a test packet is transmitted using the VNI value associated with the monitored service flow. By doing that, the test packet experiences network treatment as the tenant's packets. An example of the realization of that scenario is discussed in [RFC9521].
2番目のケースは、監視対象のサービスフローに関連付けられたVNI値を使用してテストパケットが送信される場合です。それを行うことにより、テストパケットはテナントのパケットとしてネットワークトリートメントを経験します。そのシナリオの実現の例は、[RFC9521]で説明されています。
ICMP and ICMPv6 ([RFC0792] and [RFC4443] respectively), as noted above, are examples of an active OAM protocol. They provide required on-demand defect detection and failure localization. ICMP control messages immediately follow the inner IP header encapsulated in Geneve. ICMP extensions for Geneve networks use mechanisms defined in [RFC4884].
上記のように、ICMPおよびICMPV6（[RFC0792]および[RFC4443]）は、アクティブなOAMプロトコルの例です。それらは、必要なオンデマンドの欠陥検出と障害のローカリゼーションを提供します。ICMPコントロールメッセージは、Geneveにカプセル化された内部IPヘッダーに従います。Geneveネットワーク用のICMP拡張は、[RFC4884]で定義されたメカニズムを使用します。
Active OAM over a Management VNI in the Geneve network uses an IP encapsulation. Protocols such as BFD [RFC5880] and STAMP [RFC8762] use UDP transport. The destination UDP port number in the inner UDP header (Figure 2) identifies the OAM protocol. This approach is well-known and has been used, for example, in MPLS networks [RFC8029]. To use IP encapsulation for an active OAM protocol, the Protocol Type field of the Geneve header MUST be set to 0x0800 (IPv4) or 0x86DD (IPv6). [RFC9521] describes the use of IP encapsulation for BFD.
Geneve Networkの管理VNIを介したアクティブなOAMは、IPカプセル化を使用します。BFD [RFC5880]やスタンプ[RFC8762]などのプロトコルは、UDP輸送を使用します。内側のUDPヘッダーの宛先UDPポート番号（図2）は、OAMプロトコルを識別します。このアプローチはよく知られており、たとえばMPLSネットワーク[RFC8029]で使用されています。アクティブなOAMプロトコルにIPカプセル化を使用するには、GeneVeヘッダーのプロトコルタイプフィールドを0x0800（IPv4）または0x86DD（IPv6）に設定する必要があります。[RFC9521]は、BFDのIPカプセル化の使用について説明しています。
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 IPvX Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Outer UDP Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Geneve Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Inner IPvX Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Inner UDP Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Active OAM Packet ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: An Example of Geneve IP/UDP Encapsulation of an Active OAM Packet
図2：Active OAMパケットのGeneve IP/UDPカプセル化の例
Inner IP header:
インナーIPヘッダー：
Destination IP:
宛先IP：
The IP address MUST be set to the loopback address 127.0.0.1/32 for IPv4 version. For IPv6, the address MUST be selected from the Dummy IPv6 Prefix 100:0:0:1::/64 [RFC9780]. A source-only IPv6 address is used as the destination to generate an exception and a reply message to the request message received.
IPv4バージョンでは、IPアドレスをループバックアドレス127.0.0.1/32に設定する必要があります。IPv6の場合、アドレスはダミーIPv6プレフィックス100：0：0：1 ::/64 [RFC9780]から選択する必要があります。ソースのみのIPv6アドレスが宛先として使用され、例外と受信したリクエストメッセージへの返信メッセージが生成されます。
Source IP:
ソースIP：
IP address of the NVE.
NVEのIPアドレス。
TTL or Hop Limit:
TTLまたはホップ制限：
MUST be set to 255 per [RFC5082]. The receiver of an active OAM Geneve packet with IP/UDP encapsulation MUST drop packets whose TTL/Hop Limit is not 255.
[RFC5082]ごとに255に設定する必要があります。IP/UDPカプセル化を備えたアクティブなOAM Geneveパケットの受信機は、TTL/ホップ制限が255ではないパケットをドロップする必要があります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
As part of a Geneve network, active OAM inherits the security considerations discussed in [RFC8926]. Additionally, a system MUST provide control to limit the rate of Geneve OAM packets punted to the Geneve control plane for processing in order to avoid overloading that control plane.
Geneveネットワークの一部として、Active OAMは[RFC8926]で説明されているセキュリティ上の考慮事項を継承します。さらに、システムは、そのコントロールプレーンのオーバーロードを避けるために、処理のためにジュネーブコントロールプレーンにパントされたジーンブOAMパケットの速度を制限するための制御を提供する必要があります。
OAM in Geneve packets uses the General TTL Security Mechanism [RFC5082], and any packet received with an inner TTL / Hop Count other than 255 MUST be discarded.
GeneveパケットのOAMは、一般的なTTLセキュリティメカニズム[RFC5082]を使用し、255以外の内側のTTL /ホップカウントで受信したパケットを破棄する必要があります。
[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>.
[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>.
[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
"Geneve: Generic Network Virtualization Encapsulation",
RFC 8926, DOI 10.17487/RFC8926, November 2020,
<https://www.rfc-editor.org/info/rfc8926>.
[RFC9780] Mirsky, G., Mishra, G., and D. Eastlake 3rd,
"Bidirectional Forwarding Detection (BFD) for Multipoint
Networks over Point-to-Multipoint MPLS Label Switched
Paths (LSPs)", RFC 9780, DOI 10.17487/RFC9780, May 2025,
<https://www.rfc-editor.org/info/rfc9780>.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
[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>.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", RFC 4884,
DOI 10.17487/RFC4884, April 2007,
<https://www.rfc-editor.org/info/rfc4884>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
<https://www.rfc-editor.org/info/rfc5082>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[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>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[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>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
Two-Way Active Measurement Protocol", RFC 8762,
DOI 10.17487/RFC8762, March 2020,
<https://www.rfc-editor.org/info/rfc8762>.
[RFC9521] Min, X., Mirsky, G., Pallagatti, S., Tantsura, J., and S.
Aldrin, "Bidirectional Forwarding Detection (BFD) for
Generic Network Virtualization Encapsulation (Geneve)",
RFC 9521, DOI 10.17487/RFC9521, January 2024,
<https://www.rfc-editor.org/info/rfc9521>.
The authors express their appreciation to Donald E. Eastlake 3rd for his suggestions that improved the readability of the document.
著者は、文書の読みやすさを改善した彼の提案に対して、ドナルドE.イーストレイク3番目に感謝しています。
Greg Mirsky
Ericsson
Email: gregimirsky@gmail.com
Sami Boutros
Ciena
Email: sboutros@ciena.com
David Black
Dell
Email: david.black@dell.com
Santosh Pallagatti
VMware
Email: santosh.pallagatti@gmail.com