Internet Engineering Task Force (IETF) X. Min
Request for Comments: 9521 ZTE Corp.
Category: Standards Track G. Mirsky
ISSN: 2070-1721 Ericsson
S. Pallagatti
VMware
J. Tantsura
Nvidia
S. Aldrin
Google
January 2024
This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in point-to-point Generic Network Virtualization Encapsulation (Geneve) unicast tunnels used to make up an overlay network.
このドキュメントでは、オーバーレイネットワークを構成するために使用されるポイントツーポイントジェネリックネットワーク仮想化カプセル化（Geneve）ユニキャストトンネルでの双方向転送検出（BFD）プロトコルの使用について説明します。
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/rfc9521.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9521で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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
2. Conventions Used in This Document
2.1. Abbreviations
2.2. Requirements Language
3. BFD Packet Transmission over a Geneve Tunnel
4. BFD Encapsulation with the Inner Ethernet/IP/UDP Header
4.1. Demultiplexing a BFD Packet When the Payload Is Ethernet
5. BFD Encapsulation with the Inner IP/UDP Header
5.1. Demultiplexing a BFD Packet When the Payload Is IP
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses
"Geneve: Generic Network Virtualization Encapsulation" [RFC8926] provides an encapsulation scheme that allows building an overlay network of tunnels by decoupling the address space of the attached virtual hosts from that of the network.
「Geneve：Generic Network Virtualization capsulation」[RFC8926]は、ネットワークの仮想ホストのアドレス空間を切り離すことにより、トンネルのオーバーレイネットワークを構築できるカプセル化スキームを提供します。
This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol [RFC5880] to enable monitoring the continuity of the path between two Geneve tunnel endpoints, which may be a Network Virtualization Edge (NVE) or another device acting as a Geneve tunnel endpoint. Specifically, the asynchronous mode of BFD, as defined in [RFC5880], is used to monitor a point-to-point (P2P) Geneve tunnel. The support for the BFD Echo function is outside the scope of this document. For simplicity, an NVE is used to represent the Geneve tunnel endpoint. A Tenant System (TS) is used to represent the physical or virtual device attached to a Geneve tunnel endpoint from the outside. A Virtual Access Point (VAP) is the NVE side of the interface between the NVE and the TS, and a VAP is a logical network port (virtual or physical) into a specific virtual network. For detailed definitions and descriptions of NVE, TS, and VAP, please refer to [RFC7365] and [RFC8014].
このドキュメントでは、双方向転送検出（BFD）プロトコル[RFC5880]の使用について説明して、2つのGeneveトンネルエンドポイント間のパスの連続性を監視できます。。具体的には、[RFC5880]で定義されているBFDの非同期モードを使用して、ポイントツーポイント（P2P）Geneveトンネルを監視します。BFDエコー関数のサポートは、このドキュメントの範囲外です。簡単にするために、NVEを使用してGeneveトンネルエンドポイントを表します。テナントシステム（TS）は、外部からGeneveトンネルエンドポイントに接続された物理的または仮想デバイスを表すために使用されます。仮想アクセスポイント（VAP）は、NVEとTSの間のインターフェイスのNVE側であり、VAPは特定の仮想ネットワークへの論理ネットワークポート（仮想または物理）です。NVE、TS、およびVAPの詳細な定義と説明については、[RFC7365]および[RFC8014]を参照してください。
The use cases and the deployment of BFD for Geneve are mostly consistent with what's described in Sections 1 and 3 of [RFC8971]. One exception is the usage of the Management Virtual Network Identifier (VNI), which is described in [GENEVE-OAM] and is outside the scope of this document.
ユースケースとGeneveのBFDの展開は、[RFC8971]のセクション1および3で説明されているものとほとんど一致しています。1つの例外は、[Geneve-oam]で説明されており、このドキュメントの範囲外である管理仮想ネットワーク識別子（VNI）の使用です。
As specified in Section 4.2 of [RFC8926], Geneve MUST be used with congestion controlled traffic or within a Traffic-Managed Controlled Environment (TMCE) to avoid congestion; that requirement also applies to BFD traffic. Specifically, considering the complexity and immaturity of the BFD congestion control mechanism, BFD for Geneve MUST be used within a TMCE unless BFD is really congestion controlled. As an alternative to a real congestion control, an operator of a TMCE deploying BFD for Geneve is required to provision the rates at which BFD is transmitted to avoid congestion and false failure detection.
[RFC8926]のセクション4.2で指定されているように、ジュネーブは、混雑を避けるために、混雑制御トラフィックまたは交通管理環境（TMCE）内で使用する必要があります。その要件は、BFDトラフィックにも適用されます。具体的には、BFD輻輳制御メカニズムの複雑さと未熟さを考慮すると、BFDが本当に混雑制御されていない限り、GeneVeのBFDはTMCE内で使用する必要があります。実際の輻輳制御に代わるものとして、GeneVe用のBFDを展開するTMCEのオペレーターは、輻輳や誤った故障検出を避けるためにBFDが送信されるレートを提供するために必要です。
BFD:
BFD：
Bidirectional Forwarding Detection
双方向転送検出
FCS:
FCS：
Frame Check Sequence
フレームチェックシーケンス
Geneve:
Geneve：
Generic Network Virtualization Encapsulation
一般的なネットワーク仮想化カプセル化
NVE:
nve：
Network Virtualization Edge
ネットワーク仮想化エッジ
TMCE:
TMCE：
Traffic-Managed Controlled Environment
交通管理の制御環境
TS:
TS：
Tenant System
テナントシステム
VAP:
VAP：
Virtual Access Point
仮想アクセスポイント
VNI:
VNI：
Virtual Network Identifier
仮想ネットワーク識別子
VXLAN:
vxlan：
Virtual eXtensible Local Area Network
仮想拡張可能なローカルエリアネットワーク
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
Since the Geneve data packet payload may be either an Ethernet frame or an IP packet, this document defines two formats of BFD packet encapsulation in Geneve. The BFD session is originated and terminated at the VAP of an NVE. The selection of the BFD packet encapsulation is based on how the VAP encapsulates the data packets. If the payload is IP, then BFD over IP is carried in the payload. If the payload is Ethernet, then BFD over IP over Ethernet is carried in the payload. This occurs in the same manner as BFD over IP in the IP payload case, regardless of what the Ethernet payload might normally carry.
Geneve Data Packet PayloadはイーサネットフレームまたはIPパケットのいずれかである可能性があるため、このドキュメントでは、Geneveの2つの形式のBFDパケットカプセル化を定義しています。BFDセッションは、NVEのVAPで発信され、終了します。BFDパケットカプセル化の選択は、VAPがデータパケットをカプセル化する方法に基づいています。ペイロードがIPの場合、BFD over IPがペイロード内に運ばれます。ペイロードがイーサネットの場合、イーサネット上のIP上のBFDがペイロード内に運ばれます。これは、イーサネットのペイロードが通常運ぶ可能性に関係なく、IPペイロードケースでBFD上のIPを介してBFDと同じ方法で発生します。
If the VAP that originates the BFD packets is used to encapsulate Ethernet data frames, then the BFD packets are encapsulated in Geneve as described below. The Geneve packet formats over IPv4 and IPv6 are defined in Sections 3.1 and 3.2 of [RFC8926], respectively. The outer IP/UDP and Geneve headers are encoded by the sender as defined in [RFC8926]. Note that the outer IP header and the inner IP header may not be of the same address family. In other words, an outer IPv6 header accompanied by an inner IPv4 header and an outer IPv4 header accompanied by an inner IPv6 header are both possible.
BFDパケットを発信するVAPを使用してイーサネットデータフレームをカプセル化する場合、BFDパケットは以下に説明するようにGeneVeにカプセル化されます。IPv4およびIPv6を介したGeneveパケット形式は、それぞれ[RFC8926]のセクション3.1および3.2で定義されています。[RFC8926]で定義されているように、外側IP/UDPおよびGeneVeヘッダーは送信者によってエンコードされます。外側のIPヘッダーと内側のIPヘッダーは、同じアドレスファミリではない場合があることに注意してください。言い換えれば、内側のIPv4ヘッダーを伴う外側のIPv6ヘッダーと、内側のIPv6ヘッダーを伴う外側のIPv4ヘッダーの両方が可能です。
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 IPvX Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Outer UDP Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Geneve Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Inner Ethernet Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Inner IPvX Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Inner UDP Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ BFD Control Packet ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Ethernet FCS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Geneve Encapsulation of a BFD Control Packet with the Inner Ethernet/IP/UDP Header
図1：内側イーサネット/IP/UDPヘッダーを使用したBFDコントロールパケットのGeneveカプセル化
The BFD packet MUST be carried inside the inner Ethernet frame of the Geneve packet. The inner Ethernet frame carrying the BFD Control packet has the following format:
BFDパケットは、Geneveパケットの内側イーサネットフレーム内に運ばれる必要があります。BFDコントロールパケットを運ぶ内部イーサネットフレームには、次の形式があります。
Inner Ethernet Header:
内側のイーサネットヘッダー：
Destination MAC:
宛先Mac：
Media Access Control (MAC) address of a VAP of the terminating NVE.
終了NVEのVAPのメディアアクセス制御（MAC）アドレス。
Source MAC:
ソースMac：
MAC address of a VAP of the originating NVE.
発生型NVEのVAPのMACアドレス。
Destination MAC: Media Access Control (MAC) address of a VAP of the terminating NVE. Source MAC: MAC address of a VAP of the originating NVE.
宛先MAC：終了NVEのVAPのメディアアクセス制御（MAC）アドレス。ソースMAC：元のNVEのVAPのMACアドレス。
IP Header:
IPヘッダー：
Source IP:
ソースIP：
IP address of a VAP of the originating NVE. If the VAP of the originating NVE has no IP address, then the IP address 0.0.0.0 for IPv4 or ::/128 for IPv6 MUST be used.
発信元NVEのVAPのIPアドレス。発信元NVEのVAPにIPアドレスがない場合、IPv4のIPアドレス0.0.0.0またはIPv6の場合は::/128を使用する必要があります。
Destination IP:
宛先IP：
IP address of a VAP of the terminating NVE. If the VAP of the terminating NVE has no IP address, then the IP address 127.0.0.1 for IPv4 or ::1/128 for IPv6 MUST be used.
終端nveのVAPのIPアドレス。終了NVEのVAPにIPアドレスがない場合、IPv4の場合はIPアドレス127.0.0.1またはIPv6の場合は:: 1/128を使用する必要があります。
TTL or Hop Limit:
TTLまたはホップ制限：
The TTL for IPv4 or Hop Limit for IPv6 MUST be set to 255 in accordance with [RFC5881], which specifies the IPv4/IPv6 single-hop BFD.
IPv4またはIPv6のホップ制限のTTLは、[RFC5881]に従って255に設定する必要があります。これは、IPv4/IPv6シングルホップBFDを指定します。
Source IP: IP address of a VAP of the originating NVE. If the VAP of the originating NVE has no IP address, then the IP address 0.0.0.0 for IPv4 or ::/128 for IPv6 MUST be used. Destination IP: IP address of a VAP of the terminating NVE. If the VAP of the terminating NVE has no IP address, then the IP address 127.0.0.1 for IPv4 or ::1/128 for IPv6 MUST be used. TTL or Hop Limit: The TTL for IPv4 or Hop Limit for IPv6 MUST be set to 255 in accordance with [RFC5881], which specifies the IPv4/IPv6 single-hop BFD. The fields of the UDP header and the BFD Control packet are encoded as specified in [RFC5881].
ソースIP：発信元NVEのVAPのIPアドレス。発信元NVEのVAPにIPアドレスがない場合、IPv4のIPアドレス0.0.0.0またはIPv6の場合は::/128を使用する必要があります。宛先IP：終端nveのVAPのIPアドレス。終了NVEのVAPにIPアドレスがない場合、IPv4の場合はIPアドレス127.0.0.1またはIPv6の場合は:: 1/128を使用する必要があります。TTLまたはホップ制限：IPv4のTTLまたはIPv6のホップ制限は、[RFC5881]に従って255に設定する必要があります。これは、IPv4/IPv6シングルホップBFDを指定する必要があります。UDPヘッダーとBFDコントロールパケットのフィールドは、[RFC5881]で指定されているようにエンコードされています。
When the BFD packets are encapsulated in Geneve in this way, the Geneve header defined in [RFC8926] follows the value set below.
この方法でGeneveにBFDパケットがカプセル化されると、[RFC8926]で定義されているGeneveヘッダーは、以下の値の値に従います。
* The Opt Len field MUST be set as consistent with the Geneve specification ([RFC8926]) depending on whether or not Geneve options are present in the frame. The use of Geneve options with BFD is beyond the scope of this document.
* Opt Lenフィールドは、Geneveオプションがフレームに存在するかどうかに応じて、Geneve仕様（[RFC8926]）と一致するものとして設定する必要があります。BFDを使用してGeneveオプションを使用することは、このドキュメントの範囲を超えています。
* The O bit MUST be set to 1, which indicates this packet contains a control message.
* oビットは1に設定する必要があります。これは、このパケットにコントロールメッセージが含まれていることを示します。
* The C bit MUST be set to 0, which indicates there isn't any critical option.
* Cビットは0に設定する必要があります。これは、重要なオプションがないことを示しています。
* The Protocol Type field MUST be set to 0x6558 (Ethernet frame).
* プロトコルタイプフィールドは、0x6558（イーサネットフレーム）に設定する必要があります。
* The Virtual Network Identifier (VNI) field MUST be set to the VNI number that the originating VAP is mapped to.
* 仮想ネットワーク識別子（VNI）フィールドは、発信VAPがマッピングされるVNI番号に設定する必要があります。
Once a packet is received, the NVE validates the packet as described in [RFC8926]. When the payload is Ethernet, the Protocol Type field equals 0x6558. The destination MAC address of the inner Ethernet frame matches the MAC address of a VAP, which is mapped to the same VNI as the received VNI. Then, the destination IP, the UDP destination port, and the TTL or Hop Limit of the inner IP packet MUST be validated to determine whether the received packet can be processed by BFD (i.e., the three field values of the inner IP packet MUST be in compliance with what's defined in Section 4 of this document, as well as Section 4 of [RFC5881]). If the validation fails, the received packet MUST NOT be processed by BFD.
パケットが受信されると、[RFC8926]で説明されているように、NVEはパケットを検証します。ペイロードがイーサネットの場合、プロトコルタイプフィールドは0x6558に等しくなります。インナーイーサネットフレームの宛先MACアドレスは、VAPのMACアドレスと一致します。これは、受信したVNIと同じVNIにマッピングされます。次に、宛先IP、UDP宛先ポート、および内側のIPパケットのTTLまたはホップ制限を検証して、受信したパケットをBFDで処理できるかどうかを判断する必要があります（つまり、内側のIPパケットの3つのフィールド値は必要です[RFC5881]のセクション4と同様に、このドキュメントのセクション4で定義されているものに準拠しています。検証が失敗した場合、受信したパケットをBFDで処理してはなりません。
In BFD over Geneve, a BFD session is originated and terminated at a VAP. Usually one NVE owns multiple VAPs. Since multiple BFD sessions may be running between two NVEs, there needs to be a mechanism for demultiplexing received BFD packets to the proper session. Furthermore, due to the fact that [RFC8014] allows for N-to-1 mapping between VAPs and VNIs at one NVE, multiple BFD sessions between two NVEs for the same VNI are allowed. Also, note that a BFD session can only be established between two VAPs that are mapped to the same VNI and that use the same way to encapsulate data packets.
Geneve上のBFDでは、BFDセッションが発信され、VAPで終了します。通常、1つのNVEが複数のVAPを所有しています。複数のBFDセッションが2つのNVEの間で実行されている可能性があるため、受信したBFDパケットを適切なセッションに脱却するメカニズムが必要です。さらに、[RFC8014]が1つのNVEでVAPとVNIの間のN-1-1マッピングを可能にするという事実により、同じVNIの2つのNVE間の複数のBFDセッションが許可されています。また、BFDセッションは、同じVNIにマッピングされ、データパケットをカプセル化するために同じ方法を使用する2つのVAP間でのみ確立できることに注意してください。
If the BFD packet is received with the value of the Your Discriminator field set to 0, then the BFD session SHOULD be identified using the VNI number and the inner Ethernet/IP header. The inner Ethernet/IP header stands for the source MAC, the source IP, the destination MAC, and the destination IP. An implementation MAY use the inner UDP port source number to aid in demultiplexing incoming BFD Control packets. If it fails to identify the BFD session, the incoming BFD Control packets MUST be dropped, and an exception event indicating the failure should be reported to the management.
BFDパケットが0に設定された差別フィールドの値で受信される場合、VNI番号と内側イーサネット/IPヘッダーを使用してBFDセッションを識別する必要があります。内側のイーサネット/IPヘッダーは、ソースMAC、ソースIP、宛先MAC、および宛先IPを表します。実装では、内側のUDPポートソース番号を使用して、脱却するBFDコントロールパケットの反転を支援する場合があります。BFDセッションの識別に失敗した場合、着信BFD制御パケットを削除する必要があり、障害を管理に報告する必要があることを示す例外イベントが必要です。
If the BFD packet is received with a non-zero Your Discriminator, then the BFD session MUST be demultiplexed only with the Your Discriminator as the key.
BFDパケットがゼロ以外の差別装置で受信された場合、BFDセッションは、識別器をキーとしてのみ非難する必要があります。
If the VAP that originates the BFD packets is used to encapsulate IP data packets, then the BFD packets are encapsulated in Geneve as described below. The Geneve packet formats over IPv4 and IPv6 are defined in Sections 3.1 and 3.2 of [RFC8926], respectively. The outer IP/UDP and Geneve headers are encoded by the sender as defined in [RFC8926]. Note that the outer IP header and the inner IP header may not be of the same address family. In other words, an outer IPv6 header accompanied by an inner IPv4 header and an outer IPv4 header accompanied by an inner IPv6 header are both possible.
BFDパケットを発信するVAPがIPデータパケットのカプセル化に使用される場合、BFDパケットは以下に説明するようにGeneVeにカプセル化されます。IPv4およびIPv6を介したGeneveパケット形式は、それぞれ[RFC8926]のセクション3.1および3.2で定義されています。[RFC8926]で定義されているように、外側IP/UDPおよびGeneVeヘッダーは送信者によってエンコードされます。外側のIPヘッダーと内側のIPヘッダーは、同じアドレスファミリではない場合があることに注意してください。言い換えれば、内側のIPv4ヘッダーを伴う外側のIPv6ヘッダーと、内側のIPv6ヘッダーを伴う外側のIPv4ヘッダーの両方が可能です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Ethernet Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Outer IPvX Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Outer UDP Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Geneve Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Inner IPvX Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Inner UDP Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ BFD Control Packet ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Geneve Encapsulation of a BFD Control Packet with the Inner IP/UDP Header
図2：内側のIP/UDPヘッダーを使用したBFDコントロールパケットのGeneveカプセル
The BFD packet MUST be carried inside the inner IP packet of the Geneve packet. The inner IP packet carrying the BFD Control packet has the following format:
BFDパケットは、Geneveパケットの内側のIPパケット内に持ち込む必要があります。BFDコントロールパケットを運ぶ内部IPパケットには、次の形式があります。
Inner IP Header:
インナーIPヘッダー：
Source IP:
ソースIP：
IP address of a VAP of the originating NVE.
発信元NVEのVAPのIPアドレス。
Destination IP:
宛先IP：
IP address of a VAP of the terminating NVE.
終端nveのVAPのIPアドレス。
TTL or Hop Limit:
TTLまたはホップ制限：
The TTL for IPv4 or Hop Limit for IPv6 MUST be set to 255 in accordance with [RFC5881], which specifies the IPv4/IPv6 single-hop BFD.
IPv4またはIPv6のホップ制限のTTLは、[RFC5881]に従って255に設定する必要があります。これは、IPv4/IPv6シングルホップBFDを指定します。
Source IP: IP address of a VAP of the originating NVE. Destination IP: IP address of a VAP of the terminating NVE. TTL or Hop Limit: The TTL for IPv4 or Hop Limit for IPv6 MUST be set to 255 in accordance with [RFC5881], which specifies the IPv4/IPv6 single-hop BFD. The fields of the UDP header and the BFD Control packet are encoded as specified in [RFC5881].
ソースIP：発信元NVEのVAPのIPアドレス。宛先IP：終端nveのVAPのIPアドレス。TTLまたはホップ制限：IPv4のTTLまたはIPv6のホップ制限は、[RFC5881]に従って255に設定する必要があります。これは、IPv4/IPv6シングルホップBFDを指定する必要があります。UDPヘッダーとBFDコントロールパケットのフィールドは、[RFC5881]で指定されているようにエンコードされています。
When the BFD packets are encapsulated in Geneve in this way, the Geneve header defined in [RFC8926] follows the value set below.
この方法でGeneveにBFDパケットがカプセル化されると、[RFC8926]で定義されているGeneveヘッダーは、以下の値の値に従います。
* The Opt Len field MUST be set as consistent with the Geneve specification ([RFC8926]) depending on whether or not Geneve options are present in the frame. The use of Geneve options with BFD is beyond the scope of this document.
* Opt Lenフィールドは、Geneveオプションがフレームに存在するかどうかに応じて、Geneve仕様（[RFC8926]）と一致するものとして設定する必要があります。BFDを使用してGeneveオプションを使用することは、このドキュメントの範囲を超えています。
* The O bit MUST be set to 1, which indicates this packet contains a control message.
* oビットは1に設定する必要があります。これは、このパケットにコントロールメッセージが含まれていることを示します。
* The C bit MUST be set to 0, which indicates there isn't any critical option.
* Cビットは0に設定する必要があります。これは、重要なオプションがないことを示しています。
* The Protocol Type field MUST be set to 0x0800 (IPv4) or 0x86DD (IPv6), depending on the address family of the inner IP packet.
* プロトコルタイプフィールドは、内側のIPパケットのアドレスファミリに応じて、0x0800（IPv4）または0x86DD（IPv6）に設定する必要があります。
* The Virtual Network Identifier (VNI) field MUST be set to the VNI number that the originating VAP is mapped to.
* 仮想ネットワーク識別子（VNI）フィールドは、発信VAPがマッピングされるVNI番号に設定する必要があります。
Once a packet is received, the NVE validates the packet as described in [RFC8926]. When the payload is IP, the Protocol Type field equals 0x0800 or 0x86DD. The destination IP address of the inner IP packet matches the IP address of a VAP, which is mapped to the same VNI as the received VNI. Then, the UDP destination port and the TTL or Hop Limit of the inner IP packet MUST be validated to determine whether or not the received packet can be processed by BFD (i.e., the two field values of the inner IP packet MUST be in compliance with what's defined in Section 5 of this document as well as Section 4 of [RFC5881]). If the validation fails, the received packet MUST NOT be processed by BFD.
パケットが受信されると、[RFC8926]で説明されているように、NVEはパケットを検証します。ペイロードがIPの場合、プロトコルタイプフィールドは0x0800または0x86DDに等しくなります。内側のIPパケットの宛先IPアドレスは、VAPのIPアドレスと一致します。これは、受信したVNIと同じVNIにマッピングされます。次に、UDP宛先ポートと内側のIPパケットのTTLまたはホップ制限を検証して、受信したパケットをBFDで処理できるかどうかを判断する必要があります（つまり、内側のIPパケットの2つのフィールド値は、このドキュメントのセクション5および[RFC5881]のセクション4で定義されていること。検証が失敗した場合、受信したパケットをBFDで処理してはなりません。
If the BFD packet is received with the value of the Your Discriminator field set to 0, then the BFD session SHOULD be identified using the VNI number and the inner IP header. The inner IP header stands for the source IP and the destination IP. An implementation MAY use the inner UDP port source number to aid in demultiplexing incoming BFD Control packets. If it fails to identify the BFD session, the incoming BFD Control packets MUST be dropped, and an exception event indicating the failure should be reported to the management.
BFDパケットが0に設定された差別フィールドの値で受信された場合、VNI番号と内側のIPヘッダーを使用してBFDセッションを識別する必要があります。内側のIPヘッダーは、ソースIPと宛先IPの略です。実装では、内側のUDPポートソース番号を使用して、脱却するBFDコントロールパケットの反転を支援する場合があります。BFDセッションの識別に失敗した場合、着信BFD制御パケットを削除する必要があり、障害を管理に報告する必要があることを示す例外イベントが必要です。
If the BFD packet is received with a non-zero Your Discriminator, then the BFD session MUST be demultiplexed only with the Your Discriminator as the key.
BFDパケットがゼロ以外の差別装置で受信された場合、BFDセッションは、識別器をキーとしてのみ非難する必要があります。
Security issues discussed in [RFC8926] and [RFC5880] apply to this document. Particularly, the BFD is an application that is run at the two Geneve tunnel endpoints. The IP underlay network and/or the Geneve option can provide security between the peers, which are subject to the issue of overload described below. The BFD introduces no security vulnerabilities when run in this manner. Considering Geneve does not have any inherent security mechanisms, BFD authentication as specified in [RFC5880] is RECOMMENDED to be utilized.
[RFC8926]および[RFC5880]で議論されているセキュリティの問題は、このドキュメントに適用されます。特に、BFDは、2つのGeneveトンネルエンドポイントで実行されるアプリケーションです。IP Underlayネットワークおよび/またはGeneveオプションは、以下で説明する過負荷の問題の対象となるピア間のセキュリティを提供できます。BFDは、この方法で実行されたときにセキュリティの脆弱性を導入しません。Geneveには固有のセキュリティメカニズムがないことを考慮すると、[RFC5880]で指定されているBFD認証を利用することをお勧めします。
This document supports establishing multiple BFD sessions between the same pair of NVEs. For each BFD session over a pair of VAPs residing in the same pair of NVEs, there SHOULD be a mechanism to control the maximum number of such sessions that can be active at the same time. Particularly, assuming an example that each NVE of the pair of NVEs has N VAPs using Ethernet as the payload, then there could be N squared BFD sessions running between the pair of NVEs. Considering N could be a high number, the N squared BFD sessions could result in overload of the NVE. In this case, it's recommended that N BFD sessions covering all N VAPs are run for the pair of NVEs. Generally speaking, the number of BFD sessions is supposed to be enough as long as all VAPs of the pair of NVEs are covered.
このドキュメントは、同じNVEのペア間の複数のBFDセッションの確立をサポートしています。同じNVEのペアに存在するVAPのペアにわたる各BFDセッションについて、同時にアクティブできるセッションの最大数を制御するメカニズムがあるはずです。特に、ペアの各NVEがペイロードとしてイーサネットを使用してn VAPを持っているという例を仮定すると、NVEのペア間で実行されているn二乗BFDセッションがある可能性があります。nが多数である可能性があることを考慮すると、nの四角BFDセッションはNVEの過負荷をもたらす可能性があります。この場合、すべてのN VAPをカバーするN BFDセッションがNVEのペアに対して実行されることをお勧めします。一般的に、BFDセッションの数は、NVEのペアのすべてのVAPがカバーされている限り、十分であると想定されています。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[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>.
[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>.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
DOI 10.17487/RFC5881, June 2010,
<https://www.rfc-editor.org/info/rfc5881>.
[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>.
[GENEVE-OAM]
Mirsky, G., Boutros, S., Black, D., and S. Pallagatti,
"OAM for use in GENEVE", Work in Progress, Internet-Draft,
draft-ietf-nvo3-geneve-oam-09, 6 December 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-
geneve-oam-09>.
[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>.
[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>.
[RFC8971] Pallagatti, S., Ed., Mirsky, G., Ed., Paragiri, S.,
Govindan, V., and M. Mudigonda, "Bidirectional Forwarding
Detection (BFD) for Virtual eXtensible Local Area Network
(VXLAN)", RFC 8971, DOI 10.17487/RFC8971, December 2020,
<https://www.rfc-editor.org/info/rfc8971>.
The authors would like to acknowledge Reshad Rahman, Jeffrey Haas, and Matthew Bocci for their guidance on this work.
著者は、この作業に関するガイダンスについて、Reshad Rahman、Jeffrey Haas、Matthew Bocciに感謝します。
The authors would like to acknowledge David Black for his explanation on the mapping relation between VAPs and VNIs.
著者は、VAPとVNIの間のマッピング関係に関する説明について、David Blackを認めたいと考えています。
The authors would like to acknowledge Stewart Bryant, Anoop Ghanwani, Jeffrey Haas, Reshad Rahman, Matthew Bocci, Andrew Alston, Magnus Westerlund, Paul Kyzivat, Sheng Jiang, Carl Wallace, Roman Danyliw, John Scudder, Donald Eastlake 3rd, Éric Vyncke, Zaheduzzaman Sarker, and Lars Eggert for their thorough review and very helpful comments.
著者は、スチュワート・ブライアント、アヌープ・ガンワニ、ジェフリー・ハース、レスシャド・ラーマン、マシュー・ボッチ、アンドリュー・アルストン、マグナス・ウェスターランド、ポール・キジバト、シェン・ジャン、カール・ウォレス、ローマ・ダニリウ、ジョン・スカッダー、ドナルド・イーストルーク3rd、エリック・ヴァイカマンカマン、Sarker、およびLars Eggertの徹底的なレビューと非常に役立つコメント。
Xiao Min
ZTE Corp.
Nanjing
China
Phone: +86 18061680168
Email: xiao.min2@zte.com.cn
Greg Mirsky
Ericsson
United States of America
Email: gregimirsky@gmail.com
Santosh Pallagatti
VMware
India
Email: santosh.pallagatti@gmail.com
Jeff Tantsura
Nvidia
United States of America
Email: jefftant.ietf@gmail.com
Sam Aldrin
Google
United States of America
Email: aldrin.ietf@gmail.com