[要約] RFC 7880は、S-BFD（Seamless Bidirectional Forwarding Detection）の仕様を定義しており、ネットワークの障害検出と回復を向上させることを目的としています。S-BFDは、高速で信頼性の高いパケット検出を提供し、ネットワークの可用性を向上させるために設計されています。
Internet Engineering Task Force (IETF) C. Pignataro
Request for Comments: 7880 D. Ward
Updates: 5880 Cisco
Category: Standards Track N. Akiya
ISSN: 2070-1721 Big Switch Networks
M. Bhatia
Ionos Networks
S. Pallagatti
July 2016
Seamless Bidirectional Forwarding Detection (S-BFD)
シームレスな双方向転送検出（S-BFD）
Abstract
概要
This document defines Seamless Bidirectional Forwarding Detection (S-BFD), a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, thus providing benefits such as quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring.
このドキュメントでは、シームレスな双方向転送検出（S-BFD）を定義します。これは、ネゴシエーションの大部分を排除してBFDを使用するための簡略化されたメカニズムであり、迅速なプロビジョニングなどの利点に加えて、パス監視を開始するネットワークノードの制御と柔軟性が向上します。
This document updates RFC 5880.
このドキュメントはRFC 5880を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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 http://www.rfc-editor.org/info/rfc7880.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7880で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................4
3. Seamless BFD Overview ...........................................6
4. S-BFD Discriminators ............................................7
4.1. S-BFD Discriminator Uniqueness .............................7
4.2. Discriminator Pools ........................................7
5. Reflector BFD Session ...........................................8
6. State Variables .................................................9
6.1. New State Variables ........................................9
6.2. State Variable Initialization and Maintenance ..............9
7. S-BFD Procedures ...............................................10
7.1. Demultiplexing of S-BFD Control Packet ....................10
7.2. Responder Procedures ......................................11
7.2.1. Responder Demultiplexing ...........................11
7.2.2. Transmission of S-BFD Control Packet by
SBFDReflector ......................................11
7.2.3. Additional SBFDReflector Behaviors .................12
7.3. Initiator Procedures ......................................13
7.3.1. SBFDInitiator State Machine ........................14
7.3.2. Transmission of S-BFD Control Packet by
SBFDInitiator ......................................15
7.3.3. Additional SBFDInitiator Behaviors .................15
7.4. Diagnostic Values .........................................16
7.5. The Poll Sequence .........................................16
8. Operational Considerations .....................................16
8.1. Scaling Aspect ............................................17
8.2. Congestion Considerations .................................17
9. Co-existence with Classical BFD Sessions .......................17
10. S-BFD Echo Function ...........................................18
11. Security Considerations .......................................19
12. References ....................................................20
12.1. Normative References .....................................20
12.2. Informative References ...................................20
Appendix A. Loop Problem and Solution .............................22
Acknowledgements ..................................................23
Contributors ......................................................23
Authors' Addresses ................................................24
Bidirectional Forwarding Detection (BFD), as described in [RFC5880] and related documents, has efficiently generalized the failure detection mechanism for multiple protocols and applications. There are some improvements that can be made to better fit existing technologies. There is a possibility of evolving BFD to better fit new technologies. This document focuses on several aspects of BFD in order to further improve efficiency, expand failure detection coverage, and allow BFD usage for wider scenarios. Additional use cases are listed in [RFC7882].
[RFC5880]と関連ドキュメントで説明されている双方向転送検出（BFD）は、複数のプロトコルとアプリケーションの障害検出メカニズムを効率的に一般化しています。既存のテクノロジーによりよく適合するようにできる改善点がいくつかあります。新しいテクノロジーによりよく適合するようにBFDを進化させる可能性があります。このドキュメントでは、効率をさらに向上させ、障害検出カバレッジを拡大し、より幅広いシナリオでBFDを使用できるようにするために、BFDのいくつかの側面に焦点を当てています。追加の使用例は[RFC7882]にリストされています。
Specifically, this document defines Seamless Bidirectional Forwarding Detection (S-BFD), a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, thus providing benefits such as quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring. S-BFD enables cases benefiting from the use of core BFD technologies in a fashion that leverages existing implementations and protocol machinery while providing a rather simplified and largely stateless infrastructure for continuity testing.
具体的には、このドキュメントでは、シームレスな双方向転送検出（S-BFD）を定義しています。SFDは、ネゴシエーションの大部分を排除してBFDを使用するための簡略化されたメカニズムであり、迅速なプロビジョニングなどの利点を提供し、ネットワークノード開始パスの制御と柔軟性を改善モニタリング。 S-BFDは、既存の実装とプロトコル機構を活用する方法でコアBFDテクノロジーの使用から利益を得るケースを可能にし、継続性テストのためのかなり単純化された、ほとんどステートレスなインフラストラクチャを提供します。
One key aspect of the mechanism described in this document eliminates the time between a network node wanting to perform a continuity test and completing the continuity test. In traditional BFD terms, the initial state changes from DOWN to UP are virtually nonexistent. Removal of this "seam" (i.e., time delay) in BFD provides a smooth and continuous operational experience for applications. Therefore, "Seamless BFD" (S-BFD) has been chosen as the name for this mechanism.
このドキュメントで説明するメカニズムの重要な側面の1つは、導通テストを実行したいネットワークノードと導通テストを完了するまでの時間を排除します。従来のBFD用語では、DOWNからUPへの初期状態の変化は事実上存在しません。 BFDのこの「シーム」（つまり、時間遅延）を削除すると、アプリケーションにスムーズで継続的な運用エクスペリエンスが提供されます。そのため、このメカニズムの名前として「シームレスBFD」（S-BFD）が選択されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
The reader is expected to be familiar with the BFD [RFC5880], IP [RFC791] [RFC2460], and MPLS [RFC3031] terms and protocol constructs. The remainder of this section describes several new terms introduced by S-BFD.
読者は、BFD [RFC5880]、IP [RFC791] [RFC2460]、およびMPLS [RFC3031]の用語とプロトコル構成に精通していることが求められます。このセクションの残りの部分では、S-BFDによって導入されたいくつかの新しい用語について説明します。
o Classical BFD - BFD session types based on [RFC5880].
o クラシックBFD-[RFC5880]に基づくBFDセッションタイプ。
o S-BFD - Seamless BFD.
o S-BFD-シームレスBFD。
o S-BFD Control packet - a BFD Control packet for the S-BFD mechanism.
o S-BFD制御パケット-S-BFDメカニズム用のBFD制御パケット。
o S-BFD Echo packet - a BFD Echo packet for the S-BFD mechanism.
o S-BFDエコーパケット-S-BFDメカニズム用のBFDエコーパケット。
o S-BFD packet - a BFD Control packet or a BFD Echo packet.
o S-BFDパケット-BFD制御パケットまたはBFDエコーパケット。
o Entity - a function on a network node to which the S-BFD mechanism allows remote network nodes to perform continuity tests. An entity can be abstract (e.g., reachability) or specific (e.g., IP addresses, Router-IDs, functions).
o エンティティ-S-BFDメカニズムによってリモートネットワークノードが導通テストを実行できるネットワークノード上の機能。エンティティは抽象的（例：到達可能性）または特定的（例：IPアドレス、ルーターID、機能）にすることができます。
o SBFDInitiator - an S-BFD session on a network node that performs a continuity test to a remote entity by sending S-BFD packets.
o SBFDInitiator-S-BFDパケットを送信してリモートエンティティへの導通テストを実行するネットワークノード上のS-BFDセッション。
o SBFDReflector - an S-BFD session on a network node that listens for incoming S-BFD Control packets to local entities and generates response S-BFD Control packets.
o SBFDReflector-ローカルエンティティへの着信S-BFD制御パケットをリッスンし、応答S-BFD制御パケットを生成するネットワークノード上のS-BFDセッション。
o Reflector BFD session - synonymous with SBFDReflector.
o リフレクターBFDセッション-SBFDReflectorと同義。
o S-BFD Discriminator - a BFD Discriminator allocated for a local entity. An SBFDReflector listens for S-BFD Discriminators.
o S-BFD Discriminator-ローカルエンティティに割り当てられたBFD Discriminator。 SBFDReflectorはS-BFD弁別子をリッスンします。
o BFD Discriminator - a BFD Discriminator allocated for an SBFDInitiator.
o BFD Discriminator-SBFDInitiatorに割り当てられたBFD Discriminator。
o Initiator - a network node hosting an SBFDInitiator.
o イニシエーター-SBFDInitiatorをホストするネットワークノード。
o Responder - a network node hosting an SBFDReflector.
o レスポンダ-SBFDReflectorをホストするネットワークノード。
Figure 1 describes the relationship between S-BFD terms.
図1は、S-BFD用語間の関係を示しています。
+---------------------+ +------------------------+
| Initiator | | Responder |
| +-----------------+ | | +-----------------+ |
| | SBFDInitiator |---S-BFD Ctrl pkt----->| SBFDReflector | |
| | +-------------+ |<--S-BFD Ctrl pkt------| +-------------+ | |
| | | BFD Discrim | | | | | |S-BFD Discrim| | |
| | | | |---S-BFD Echo pkt---+ | | | | |
| | +-------------+ | | | | | +----------^--+ | |
| +-----------------+<-------------------+ +------------|----+ |
| | | | |
| | | +---v----+ |
| | | | Entity | |
| | | +--------+ |
+---------------------+ +------------------------+
Figure 1: S-BFD Terminology Relationship
図1：S-BFDの用語の関係
An S-BFD module on each network node allocates one or more S-BFD Discriminators for local entities and creates a Reflector BFD session. Allocated S-BFD Discriminators may be advertised by applications (e.g., OSPF/IS-IS). The required result is that applications on other network nodes will know about the S-BFD Discriminators allocated by a remote node to remote entities. The Reflector BFD session, upon receiving an S-BFD Control packet targeted to one of the local S-BFD Discriminator values, is to transmit a response S-BFD Control packet back to the initiator.
各ネットワークノードのS-BFDモジュールは、ローカルエンティティに1つ以上のS-BFD識別子を割り当て、Reflector BFDセッションを作成します。割り当てられたS-BFD弁別子は、アプリケーション（OSPF / IS-ISなど）によって通知される場合があります。必要な結果は、他のネットワークノード上のアプリケーションが、リモートノードによってリモートエンティティに割り当てられたS-BFD識別子を認識することです。リフレクターBFDセッションは、ローカルS-BFDディスクリミネーター値の1つをターゲットとするS-BFD制御パケットを受信すると、応答S-BFD制御パケットをイニシエーターに送信します。
Once the above setup is complete, any network node that knows about the S-BFD Discriminator allocated by a remote node to a remote entity or entities can quickly perform a continuity test to the remote entity by simply sending S-BFD Control packets with a corresponding S-BFD Discriminator value in the Your Discriminator field.
上記の設定が完了すると、リモートノードによってリモートエンティティに割り当てられたS-BFD識別子を知っているネットワークノードは、対応するS-BFD制御パケットを送信するだけで、リモートエンティティに導通テストをすばやく実行できます。 Your DiscriminatorフィールドのS-BFD Discriminator値。
This is exemplified in Figure 2.
これを図2に示します。
<------- IS-IS Network ------->
+---------+
| |
A---------B---------C---------D
^ ^
| |
System-ID System-ID
xxx yyy
BFD Discrim BFD Discrim
123 456
Figure 2: S-BFD for IS-IS Network
図2：IS-ISネットワークのS-BFD
An S-BFD module in a system with IS-IS System-ID xxx (Node A) allocates an S-BFD Discriminator 123, and IS-IS advertises the S-BFD Discriminator 123 in an IS-IS TLV. An S-BFD module in a system with IS-IS System-ID yyy (Node D) allocates an S-BFD Discriminator 456, and IS-IS advertises the S-BFD Discriminator 456 in an IS-IS TLV. A Reflector BFD session is created on both network nodes (Node A and Node D). When Node A wants to check the reachability of Node D, Node A can send an S-BFD Control packet destined to Node D with the Your Discriminator field set to 456. When the Reflector BFD session on Node D receives this S-BFD Control packet, then a response S-BFD Control packet is sent back to Node A, which allows Node A to complete the continuity test.
IS-IS System-ID xxx（ノードA）のシステムのS-BFDモジュールは、S-BFD Discriminator 123を割り当て、IS-ISはIS-IS TLVのS-BFD Discriminator 123を通知します。 IS-ISシステムID yyy（ノードD）のシステム内のS-BFDモジュールは、S-BFD弁別器456を割り当て、IS-ISはIS-IS TLVでS-BFD弁別器456をアドバタイズします。リフレクターBFDセッションが両方のネットワークノード（ノードAとノードD）で作成されます。ノードAがノードDの到達可能性を確認したい場合、ノードAはYour Discriminatorフィールドを456に設定してノードD宛てのS-BFD制御パケットを送信できます。ノードDのリフレクターBFDセッションがこのS-BFD制御パケットを受信すると、その後、応答S-BFD制御パケットがノードAに返送され、ノードAが導通テストを完了することができます。
When a node allocates multiple S-BFD Discriminators, how remote nodes determine which of the discriminators is associated with a specific entity is currently unspecified. The use of multiple S-BFD Discriminators by a single network node is therefore discouraged until a means of learning the mapping is defined.
ノードが複数のS-BFD識別子を割り当てる場合、リモートノードがどの識別子が特定のエンティティに関連付けられているかを判別する方法は、現在のところ指定されていません。したがって、マッピングを学習する手段が定義されるまで、単一のネットワークノードによる複数のS-BFD弁別子の使用は推奨されません。
One important characteristic of an S-BFD Discriminator is that it MUST be unique within an administrative domain. If multiple network nodes allocate the same S-BFD Discriminator value, then S-BFD Control packets falsely terminating on a wrong network node can result in a Reflector BFD session generating a response back because of a matching Your Discriminator value. This is clearly not desirable.
S-BFD Discriminatorの重要な特徴の1つは、管理ドメイン内で一意でなければならないことです。複数のネットワークノードが同じS-BFD Discriminator値を割り当てる場合、間違ったネットワークノードでS-BFD制御パケットが誤って終了すると、Discriminator値が一致するため、Reflector BFDセッションが応答を生成する可能性があります。これは明らかに望ましくありません。
This subsection describes a discriminator pool implementation technique to minimize S-BFD Discriminator collisions. This technique will allow an implementation to better satisfy the S-BFD Discriminator uniqueness requirement defined in Section 4.1.
このサブセクションでは、S-BFD弁別器の衝突を最小限に抑える弁別器プールの実装手法について説明します。この手法により、セクション4.1で定義されたS-BFD Discriminatorの一意性要件を実装でより適切に満たすことができます。
o An SBFDInitiator is to allocate a discriminator from the BFD Discriminator pool. If the system also supports classical BFD (i.e., implements [RFC5880]), then the BFD Discriminator pool SHOULD be shared by SBFDInitiator sessions and classical BFD sessions.
o SBFDInitiatorは、BFD Discriminatorプールから識別子を割り当てることです。システムが従来のBFDもサポートしている場合（つまり、[RFC5880]を実装している場合）、BFD Discriminatorプールは、SBFDInitiatorセッションと従来のBFDセッションで共有する必要があります（SHOULD）。
o An SBFDReflector is to allocate a discriminator from the S-BFD Discriminator pool. The S-BFD Discriminator pool SHOULD be a separate pool from the BFD Discriminator pool.
o SBFDReflectorは、S-BFD Discriminatorプールから識別子を割り当てることです。 S-BFD Discriminatorプールは、BFD Discriminatorプールとは別のプールである必要があります（SHOULD）。
The remainder of this subsection describes the reasons for the suggestions above.
このサブセクションの残りの部分では、上記の提案の理由について説明します。
Locally allocated S-BFD Discriminator values for entities that SBFDReflector sessions are listening for may be arbitrarily allocated or derived from values provided by applications. These values may be protocol IDs (e.g., System-ID, Router-ID) or network targets (e.g., IP address). To avoid derived S-BFD Discriminator values already being assigned to other BFD sessions (i.e., SBFDInitiator sessions and classical BFD sessions), it is RECOMMENDED that the discriminator pool for SBFDReflector sessions be separate from other BFD sessions.
SBFDReflectorセッションがリッスンしているエンティティにローカルに割り当てられたS-BFD Discriminator値は、アプリケーションによって提供された値から任意に割り当てられるか、派生する場合があります。これらの値は、プロトコルID（システムID、ルーターIDなど）またはネットワークターゲット（IPアドレスなど）の場合があります。派生したS-BFD Discriminator値がすでに他のBFDセッション（つまり、SBFDInitiatorセッションと従来のBFDセッション）に割り当てられていることを回避するために、SBFDReflectorセッションの識別プールを他のBFDセッションから分離することをお勧めします。
Even when following the "separate discriminator pool" approach, a collision is still possible between different S-BFD applications that may be using different values and algorithms to derive S-BFD Discriminator values. If two applications are using S-BFD for the same purpose (e.g., network reachability), then the colliding S-BFD Discriminator value can be shared. If the two applications are using S-BFD for a different purpose, then the collision must be addressed. The use of multiple S-BFD Discriminators by a single network node, however, is discouraged (see Section 3).
「個別の弁別器プール」アプローチに従う場合でも、異なる値とアルゴリズムを使用してS-BFD弁別器の値を導出している異なるS-BFDアプリケーション間で衝突が発生する可能性があります。 2つのアプリケーションが同じ目的（ネットワークの到達可能性など）でS-BFDを使用している場合、衝突するS-BFD弁別器の値を共有できます。 2つのアプリケーションが異なる目的でS-BFDを使用している場合は、衝突に対処する必要があります。ただし、単一のネットワークノードで複数のS-BFD識別子を使用することはお勧めしません（セクション3を参照）。
Each network node creates one or more Reflector BFD sessions. This Reflector BFD session is a session that transmits S-BFD Control packets in response to received S-BFD Control packets with the Your Discriminator field having S-BFD Discriminators allocated for local entities. Specifically, this Reflector BFD session has the following characteristics:
各ネットワークノードは、1つ以上のReflector BFDセッションを作成します。このリフレクターBFDセッションは、ローカルエンティティに割り当てられたS-BFD弁別子を持つYour Discriminatorフィールドを使用して、受信したS-BFD制御パケットに応答してS-BFD制御パケットを送信するセッションです。具体的には、このReflector BFDセッションには次の特性があります。
o MUST NOT transmit any S-BFD packets based on local timer expiry.
o ローカルタイマーの有効期限に基づいてS-BFDパケットを送信してはなりません。
o MUST transmit an S-BFD Control packet in response to a received S-BFD Control packet having a valid S-BFD Discriminator in the Your Discriminator field, unless prohibited by local policies (e.g., administrative, security, rate-limiter).
o ローカルポリシー（管理、セキュリティ、レートリミッターなど）で禁止されていない限り、Your Discriminatorフィールドに有効なS-BFD Discriminatorを含む受信したS-BFD制御パケットに応答して、S-BFD制御パケットを送信する必要があります。
o MUST be capable of sending only two states: UP and AdminDown.
o UPとAdminDownの2つの状態のみを送信できる必要があります。
One Reflector BFD session may be responsible for handling received S-BFD Control packets targeted to all locally allocated S-BFD Discriminators, or a few Reflector BFD sessions may each be responsible for a subset of locally allocated S-BFD Discriminators. This policy is a local matter and is outside the scope of this document.
1つのReflector BFDセッションが、ローカルに割り当てられたすべてのS-BFDディスクリミネーターをターゲットとする受信したS-BFD制御パケットの処理を担当する場合があります。このポリシーはローカルな問題であり、このドキュメントの範囲外です。
Note that incoming S-BFD Control packets may be based on IPv4, IPv6, or MPLS [RFC7881]. Note also that other options are possible and may be defined in future documents. How such S-BFD Control packets reach an appropriate Reflector BFD session is also a local matter and is outside the scope of this document.
着信S-BFD制御パケットはIPv4、IPv6、またはMPLS [RFC7881]に基づく場合があることに注意してください。他のオプションも可能であり、将来のドキュメントで定義される可能性があることにも注意してください。このようなS-BFD制御パケットが適切なReflector BFDセッションにどのように到達するかもローカルな問題であり、このドキュメントの範囲外です。
S-BFD introduces new state variables and modifies the usage of existing ones.
S-BFDは新しい状態変数を導入し、既存の変数の使用を変更します。
A new state variable is added to the base specification in support of S-BFD.
S-BFDをサポートするために、新しい仕様変数が基本仕様に追加されました。
o bfd.SessionType: This is a new state variable that describes the type of a particular session. Allowable values for S-BFD sessions are:
o bfd.SessionType：これは、特定のセッションのタイプを説明する新しい状態変数です。 S-BFDセッションの許容値は次のとおりです。
* SBFDInitiator - an S-BFD session on a network node that performs a continuity test to a target entity by sending S-BFD packets.
* SBFDInitiator-S-BFDパケットを送信することによってターゲットエンティティへの導通テストを実行するネットワークノード上のS-BFDセッション。
* SBFDReflector - an S-BFD session on a network node that listens for incoming S-BFD Control packets to local entities and generates response S-BFD Control packets.
* SBFDReflector-ローカルエンティティへの着信S-BFD制御パケットをリッスンし、応答S-BFD制御パケットを生成するネットワークノード上のS-BFDセッション。
The bfd.SessionType variable MUST be initialized to the appropriate type when an S-BFD session is created.
bfd.SessionType変数は、S-BFDセッションが作成されるときに適切なタイプに初期化される必要があります。
State variables (defined in Section 6.8.1 of [RFC5880]) need to be initialized or manipulated differently, depending on the session type.
状態変数（[RFC5880]のセクション6.8.1で定義）は、セッションのタイプに応じて、初期化または操作を変える必要があります。
o bfd.DemandMode: This variable MUST be initialized to 1 for session type SBFDInitiator and MUST be initialized to 0 for session type SBFDReflector. This is done to prevent loops (see Appendix A).
o bfd.DemandMode：この変数は、セッションタイプSBFDInitiatorの場合は1に初期化する必要があり、セッションタイプSBFDReflectorの場合は0に初期化する必要があります。これはループを防ぐために行われます（付録Aを参照）。
An S-BFD packet MUST be demultiplexed with lower-layer information (e.g., dedicated destination UDP port [RFC7881], associated Channel Type [RFC7885]). The following procedure SHOULD be executed on both initiator and reflector:
S-BFDパケットは、下位層の情報（たとえば、専用の宛先UDPポート[RFC7881]、関連するチャネルタイプ[RFC7885]）で逆多重化する必要があります。次の手順は、イニシエーターとリフレクターの両方で実行する必要があります（SHOULD）。
If the packet is an S-BFD packet
パケットがS-BFDパケットの場合
If the S-BFD packet is for an SBFDReflector
S-BFDパケットがSBFDReflector用である場合
The packet MUST be looked up to locate a corresponding SBFDReflector session based on the value from the Your Discriminator field in the table describing S-BFD Discriminators.
S-BFD Discriminatorsを説明する表のYour Discriminatorフィールドの値に基づいて、対応するSBFDReflectorセッションを見つけるためにパケットを検索する必要があります。
Else
そうしないと
The packet MUST be looked up to locate a corresponding SBFDInitiator session or classical BFD session based on the value from the Your Discriminator field in the table describing BFD Discriminators. If no match, then the received packet MUST be discarded.
BFD Discriminatorsを説明する表のYour Discriminatorフィールドの値に基づいて、対応するSBFDInitiatorセッションまたは従来のBFDセッションを見つけるためにパケットを検索する必要があります。一致しない場合は、受信したパケットを破棄する必要があります。
If the session is an SBFDInitiator session
セッションがSBFDInitiatorセッションの場合
The destination of the packet (i.e., the destination IP address) SHOULD be verified as being for itself.
パケットの宛先（つまり、宛先IPアドレス）は、それ自体のものであることを確認する必要があります。
Else
そうしないと
The packet MUST be discarded.
パケットは破棄されなければなりません。
Else
そうしないと
The procedure described in Section 6.8.6 of [RFC5880] MUST be applied.
[RFC5880]のセクション6.8.6で説明されている手順を適用する必要があります。
More details on S-BFD Control packet demultiplexing are provided in relevant S-BFD data-plane documents.
S-BFD制御パケットの逆多重化の詳細については、関連するS-BFDデータプレーンのドキュメントを参照してください。
A network node that receives S-BFD Control packets transmitted by an initiator is referred to as the responder. The responder, upon reception of S-BFD Control packets, is to verify the validity of the packets, as described in [RFC5880].
イニシエータによって送信されたS-BFD制御パケットを受信するネットワークノードは、レスポンダと呼ばれます。 [RFC5880]で説明されているように、S-BFD制御パケットを受信すると、レスポンダはパケットの有効性を検証します。
An S-BFD packet MUST be demultiplexed with lower-layer information. The following procedure SHOULD be executed by the responder:
S-BFDパケットは、下位層の情報で逆多重化されなければなりません（MUST）。次のプロシージャはレスポンダによって実行されるべきです（SHOULD）。
If the Your Discriminator field is not one of the entries allocated for local entities
Your Discriminatorフィールドがローカルエンティティに割り当てられたエントリの1つでない場合
The packet MUST be discarded.
パケットは破棄されなければなりません。
Else
そうしないと
The packet is determined to be handled by a Reflector BFD session responsible for that S-BFD Discriminator.
パケットは、そのS-BFD Discriminatorを担当するReflector BFDセッションによって処理されることが決定されています。
If allowable per local policy (e.g., administrative, security, rate-limiter)
ローカルポリシー（管理、セキュリティ、レートリミッターなど）ごとに許可される場合
The chosen Reflector BFD session SHOULD transmit a response BFD Control packet using the procedures described in Section 7.2.2.
選択されたReflector BFDセッションは、セクション7.2.2で説明されている手順を使用して、応答BFD制御パケットを送信する必要があります（SHOULD）。
The contents of S-BFD Control packets sent by an SBFDReflector MUST be set as per Section 6.8.7 of [RFC5880]. There are a few fields that need to be set differently from [RFC5880], as follows:
SBFDReflectorによって送信されるS-BFD制御パケットの内容は、[RFC5880]のセクション6.8.7に従って設定する必要があります。次のように、[RFC5880]とは異なる設定が必要なフィールドがいくつかあります。
State (Sta)
州（Sta）
Set to bfd.SessionState (either UP or AdminDown only). Clarification of Reflector BFD session state is described in Section 7.2.3.
bfd.SessionStateに設定します（UPまたはAdminDownのみ）。 Reflector BFDセッション状態の明確化については、セクション7.2.3で説明しています。
Demand (D)
需要（D）
Set to 0, to indicate that the S-BFD packet is sent by the SBFDReflector.
S-BFDパケットがSBFDReflectorによって送信されることを示すには、0に設定します。
Detect Mult
多くを検出
Value to be copied from the Detection Multiplier field of the received BFD packet.
受信したBFDパケットの検出乗数フィールドからコピーされる値。
My Discriminator
私の弁別人
Value to be copied from the Your Discriminator field of the received BFD packet.
受信したBFDパケットのYour Discriminatorフィールドからコピーされる値。
Your Discriminator
あなたの弁別者
Value to be copied from the My Discriminator field of the received BFD packet.
受信したBFDパケットのMy Discriminatorフィールドからコピーされる値。
Desired Min TX Interval
望ましい最小TX間隔
Value to be copied from the Desired Min TX Interval field of the received BFD packet.
受信したBFDパケットのDesired Min TX Intervalフィールドからコピーされる値。
Required Min RX Interval
必要な最小RX間隔
Set to bfd.RequiredMinRxInterval. Value indicating the minimum interval, in microseconds, between received S-BFD Control packets. Further details are provided in Section 7.2.3.
bfd.RequiredMinRxIntervalに設定します。受信したS-BFD制御パケット間の最小間隔をマイクロ秒単位で示す値。詳細は、7.2.3項を参照してください。
Required Min Echo RX Interval
必要な最小エコーRX間隔
If the device supports looping back S-BFD Echo packets
デバイスがS-BFDエコーパケットのループバックをサポートしている場合
Set to the minimum required S-BFD Echo packet receive interval for this session.
このセッションに必要な最小のS-BFDエコーパケット受信間隔に設定します。
Else
そうしないと
Set to 0.
0に設定します。
o S-BFD Control packets transmitted by the SBFDReflector MUST have Required Min RX Interval set to a value that expresses, in microseconds, the minimum interval between incoming S-BFD Control packets that this SBFDReflector can handle. The SBFDReflector can control how fast SBFDInitiators will be sending S-BFD Control packets to themselves by ensuring that Required Min RX Interval indicates a value based on the current load.
o SBFDReflectorによって送信されるS-BFD制御パケットは、このSBFDReflectorが処理できる着信S-BFD制御パケット間の最小間隔をマイクロ秒で表す値に設定された必須の最小RX間隔を持つ必要があります。 SBFDReflectorは、必要な最小RX間隔が現在の負荷に基づく値を示すようにすることで、SBFDInitiatorsがS-BFD制御パケットを自分自身に送信する速度を制御できます。
o When the SBFDReflector receives an S-BFD Control packet from an SBFDInitiator, then the SBFDReflector needs to determine what "state" to send in the response S-BFD Control packet. If the monitored local entity is in service, then the state MUST be set to UP. If the monitored local entity is "temporarily out of service", then the state SHOULD be set to AdminDown.
o SBFDReflectorがSBFDInitiatorからS-BFD制御パケットを受信すると、SBFDReflectorは応答S-BFD制御パケットで送信する「状態」を決定する必要があります。監視対象のローカルエンティティが稼働中の場合は、状態をUPに設定する必要があります。監視対象のローカルエンティティが「一時的にサービスを停止している」場合は、状態をAdminDownに設定する必要があります（SHOULD）。
o If an SBFDReflector receives an S-BFD Control packet with the Demand (D) bit cleared, the packet MUST be discarded (see Appendix A).
o SBFDReflectorがデマンド（D）ビットがクリアされたS-BFD制御パケットを受信した場合、パケットは破棄されなければなりません（付録Aを参照）。
S-BFD Control packets transmitted by an SBFDInitiator MUST set the Your Discriminator field to an S-BFD Discriminator corresponding to the remote entity.
SBFDInitiatorによって送信されるS-BFD制御パケットは、Your Discriminatorフィールドをリモートエンティティに対応するS-BFD Discriminatorに設定する必要があります。
Every SBFDInitiator MUST have a locally unique My Discriminator value allocated from the BFD Discriminator pool.
すべてのSBFDInitiatorには、BFD Discriminatorプールから割り当てられたローカルで一意のMy Discriminator値が必要です。
Figure 3 describes the high-level concept of continuity testing using S-BFD. R2 allocates XX as the S-BFD Discriminator for network reachability purposes and advertises XX to neighbors. Figure 3 shows R1 and R4 performing a continuity test to R2.
図3は、S-BFDを使用した導通テストの高レベルの概念を示しています。 R2は、XXをネットワーク到達可能性の目的でS-BFD識別子として割り当て、XXをネイバーにアドバタイズします。図3は、R1とR4がR2への導通テストを実行しているところを示しています。
+--- md=50/yd=XX (ping) ----+
| |
|+-- md=XX/yd=50 (pong) --+ |
|| | |
|v | v
R1 ==================== R2[*] ========= R3 ========= R4
| ^ |^
| | ||
| +-- md=60/yd=XX (ping) --+|
| |
+---- md=XX/yd=60 (pong) ---+
[*] Reflector BFD session on R2.
=== Links connecting network nodes.
--- S-BFD Control packet traversal.
Figure 3: S-BFD Continuity Test
図3：S-BFD導通テスト
An SBFDInitiator may be a "persistent" session on the initiator with a timer for S-BFD Control packet transmissions (stateful SBFDInitiator). An SBFDInitiator may also be a module, a script, or a tool on the initiator that transmits one or more S-BFD Control packets "when needed" (stateless SBFDInitiator). For stateless SBFDInitiators, a complete BFD state machine may not be applicable. For stateful SBFDInitiators, the states and the state machine described in [RFC5880] will not function due to the SBFDReflector session only sending the UP and AdminDown states (i.e., the SBFDReflector session does not send the INIT state). The following diagram provides the RECOMMENDED state machine for stateful SBFDInitiators. The notation on each arc represents the state of the SBFDInitiator (as received in the State field in the S-BFD Control packet) or indicates the expiration of the Detection Timer. See Figure 4.
SBFDInitiatorは、S-BFD制御パケット送信用のタイマー（ステートフルSBFDInitiator）を備えたイニシエーター上の「永続的」セッションである場合があります。 SBFDInitiatorは、「必要なときに」1つ以上のS-BFD制御パケットを送信するイニシエーター上のモジュール、スクリプト、またはツール（ステートレスSBFDInitiator）の場合もあります。ステートレスSBFDInitiatorsの場合、完全なBFDステートマシンは適用できない場合があります。ステートフルSBFDInitiatorsの場合、SBRFReflectorセッションはUP状態とAdminDown状態のみを送信するため（SBFDReflectorセッションはINIT状態を送信しないため）、[RFC5880]で説明されている状態と状態マシンは機能しません。次の図は、ステートフルSBFDInitiatorsに推奨されるステートマシンを示しています。各アークの表記は、SBFDInitiatorの状態（S-BFD制御パケットのStateフィールドで受信される）を表すか、検出タイマーの期限切れを示します。図4を参照してください。
+--+
ADMIN DOWN, | |
TIMER | V
+------+ UP +------+
| |-------------------->| |----+
| DOWN | | UP | | UP
| |<--------------------| |<---+
+------+ ADMIN DOWN, +------+
TIMER
Figure 4: SBFDInitiator Finite State Machine
図4：SBFDInitiator有限状態マシン
Note that the above state machine is different from the base BFD specification [RFC5880]. This is because the INIT state is no longer applicable for the SBFDInitiator. Another important difference is the transition of the state machine from the DOWN state to the UP state when a packet with an UP state setting is received by the SBFDInitiator. The definitions of the states and events have the same meanings as those defined in the base BFD specification [RFC5880].
上記のステートマシンは、ベースBFD仕様[RFC5880]とは異なることに注意してください。これは、INIT状態がSBFDInitiatorに適用されなくなったためです。別の重要な違いは、SBFDInitiatorがUP状態設定のパケットを受信したときに、状態マシンがDOWN状態からUP状態に移行することです。状態とイベントの定義は、ベースBFD仕様[RFC5880]で定義されているものと同じ意味を持っています。
The contents of S-BFD Control packets sent by an SBFDInitiator MUST be set as per Section 6.8.7 of [RFC5880]. There are a few fields that need to be set differently from [RFC5880], as follows:
SBFDInitiatorによって送信されるS-BFD制御パケットの内容は、[RFC5880]のセクション6.8.7に従って設定する必要があります。次のように、[RFC5880]とは異なる設定が必要なフィールドがいくつかあります。
Demand (D)
需要（D）
Used to indicate that the S-BFD packet originated from the SBFDInitiator. Always set to 1.
S-BFDパケットがSBFDInitiatorから発信されたことを示すために使用されます。常に1に設定します。
Your Discriminator
あなたの弁別者
Set to bfd.RemoteDiscr. bfd.RemoteDiscr is set to the Discriminator value of the remote entity. It MAY be learnt from routing protocols or configured locally.
bfd.RemoteDiscrに設定します。 bfd.RemoteDiscrは、リモートエンティティのDiscriminator値に設定されます。ルーティングプロトコルから学習することも、ローカルで構成することもできます。
Required Min RX Interval
必要な最小RX間隔
Set to 0.
0に設定します。
Required Min Echo RX Interval
必要な最小エコーRX間隔
Set to 0.
0に設定します。
o If the SBFDInitiator receives a valid S-BFD Control packet in response to a transmitted S-BFD Control packet to a remote entity, then the SBFDInitiator SHOULD conclude that the S-BFD Control packet reached the intended remote entity.
o SBFDInitiatorがリモートエンティティに送信されたS-BFD制御パケットに応答して有効なS-BFD制御パケットを受信した場合、SBFDInitiatorは、S-BFD制御パケットが目的のリモートエンティティに到達したと結論付ける必要があります。
o When an SBFDInitiator receives a response S-BFD Control packet, if the state specified is AdminDown, the SBFDInitiator MUST NOT conclude that the reachability of the corresponding remote entity is lost and MUST back off the packet transmission interval for the remote entity to an interval no faster than 1 second.
o SBFDInitiatorが応答S-BFD制御パケットを受信するとき、指定された状態がAdminDownである場合、SBFDInitiatorは対応するリモートエンティティの到達可能性が失われたと結論してはならず、リモートエンティティのパケット送信間隔を間隔no 1秒より速い。
o When a sufficient number of S-BFD packets have not arrived as they should, the SBFDInitiator SHOULD declare loss of reachability to the remote entity. The criteria for declaring loss of reachability and the action that would be triggered as a result are outside the scope of this document; the action MAY include logging an error.
o 十分な数のS-BFDパケットが到着しない場合、SBFDInitiatorはリモートエンティティへの到達不能を宣言する必要があります（SHOULD）。到達可能性の喪失を宣言する基準と、その結果としてトリガーされるアクションは、このドキュメントの範囲外です。アクションには、エラーのロギングが含まれる場合があります。
o Regarding the third bullet item, it is critical for an implementation to understand the latency to/from the Reflector BFD session on the responder. In other words, for the very first S-BFD packet transmitted by the SBFDInitiator, an implementation MUST NOT expect a response S-BFD packet to be received for a time equivalent to the sum of the latencies: initiator to responder and responder back to initiator.
o 3番目の箇条書き項目に関しては、実装者が応答側のReflector BFDセッションとの間の遅延を理解することが重要です。言い換えると、SBFDInitiatorによって送信された最初のS-BFDパケットの場合、実装は応答S-BFDパケットが待機時間の合計に相当する時間の間受信されることを期待してはなりません：イニシエータからレスポンダへ、レスポンダからイニシエータへ。
o If the SBFDInitiator receives an S-BFD Control packet with the Demand (D) bit set, the packet MUST be discarded (see Appendix A).
o SBFDInitiatorがデマンド（D）ビットが設定されたS-BFD制御パケットを受信した場合、パケットは破棄される必要があります（付録Aを参照）。
The diagnostic value in both directions MAY be set to a certain value, to attempt to communicate further information to both ends. Implementations MAY use the already-existing diagnostic values defined in Section 4.1 of [RFC5880]. However, details regarding this topic are outside the scope of this specification.
両方向の診断値を特定の値に設定して、両端にさらに情報を伝えようとする場合があります。実装では、[RFC5880]のセクション4.1で定義されている既存の診断値を使用できます。ただし、このトピックに関する詳細は、この仕様の範囲外です。
The Poll Sequence MAY be used in both directions. The Poll Sequence MUST operate in accordance with [RFC5880]. An SBFDReflector MAY use the Poll Sequence to slow down the rate at which S-BFD Control packets are generated from an SBFDInitiator. This is done by the SBFDReflector, using the procedures described in Section 7.2.3 and setting the Poll (P) bit in the reflected S-BFD Control packet. The SBFDInitiator is to then send the next S-BFD Control packet with the Final (F) bit set. If an SBFDReflector receives an S-BFD Control packet with the P bit set, then the SBFDReflector MUST respond with an S-BFD Control packet with the P bit cleared and the F bit set.
ポーリングシーケンスは両方向で使用できます。ポーリングシーケンスは、[RFC5880]に従って動作する必要があります。 SBFDReflectorは、ポーリングシーケンスを使用して、SBFDInitiatorからS-BFD制御パケットが生成される速度を遅くしてもよい（MAY）。これは、セクション7.2.3で説明されている手順を使用し、反射されたS-BFD制御パケットのポーリング（P）ビットを設定して、SBFDReflectorによって実行されます。次に、SBFDInitiatorは、Final（F）ビットが設定された次のS-BFD制御パケットを送信します。 SBFDReflectorがPビットが設定されたS-BFD制御パケットを受信した場合、SBFDReflectorは、Pビットがクリアされ、Fビットが設定されたS-BFD制御パケットで応答する必要があります。
S-BFD provides a smooth and continuous (i.e., seamless) operational experience as an Operations, Administration, and Maintenance (OAM) mechanism for connectivity checking and connection verification. This is achieved by providing a simplified mechanism with a large proportion of negotiation aspects eliminated, resulting in faster and simpler provisioning.
S-BFDは、接続性のチェックと接続の検証のための運用、管理、保守（OAM）メカニズムとして、スムーズで継続的な（つまり、シームレスな）運用エクスペリエンスを提供します。これは、ネゴシエーションの側面の大部分が排除された簡略化されたメカニズムを提供することで実現され、プロビジョニングがより高速で単純になります。
Because of this simplified mechanism, due to a misconfiguration an SBFDInitiator could send S-BFD Control packets to a target that does not exist or that is outside the S-BFD administrative domain. As explained in Section 7.3.1, an SBFDInitiator can be a persistent initiator or a "when needed" one. When an S-BFD persistent SBFDInitiator is used, a deployment SHOULD ensure that S-BFD Control packets do not propagate for an extended period of time outside of the administrative domain that uses it. Further, operational measures SHOULD be taken to determine if responses to S-BFD packets are not sent for an extended period of time and then remediate the situation. These potential concerns are largely mitigated by dynamic advertisement mechanisms for S-BFD and with automation checks before applying configurations.
この単純化されたメカニズムのため、構成の誤りにより、SBFDInitiatorは、存在しない、またはS-BFD管理ドメイン外のターゲットにS-BFD制御パケットを送信する可能性があります。セクション7.3.1で説明したように、SBFDInitiatorは永続的なイニシエータまたは「必要な場合」のイニシエータになります。 S-BFD永続SBFDInitiatorを使用する場合、展開では、S-BFD制御パケットが、それを使用する管理ドメインの外部に長時間伝播しないようにする必要があります（SHOULD）。さらに、S-BFDパケットへの応答が長期間送信されていないかどうかを判断し、状況を修正するために、運用上の対策を講じる必要があります。これらの潜在的な懸念は、S-BFDの動的アドバタイズメントメカニズムと、構成を適用する前の自動化チェックによって大幅に軽減されます。
This mechanism brings forth one noticeable difference in terms of the scaling aspect: the number of SBFDReflectors. This specification eliminates the need for egress nodes to have fully active BFD sessions when only one side desires to perform continuity tests. With the introduction of the Reflector BFD concept, egress is no longer required to create any active BFD sessions on a per-path/LSP/ function basis. Because of this, the total number of BFD sessions in a network is reduced.
このメカニズムは、スケーリングの面で1つの顕著な違い、SBFDReflectorsの数をもたらします。この仕様により、一方の側だけが導通テストを実行したい場合に、出力ノードが完全にアクティブなBFDセッションを持つ必要がなくなります。 Reflector BFDコンセプトの導入により、パス/ LSP /機能ごとにアクティブなBFDセッションを作成するために出力が不要になりました。このため、ネットワーク内のBFDセッションの総数が減少します。
When S-BFD performs failure detection, it consumes resources, including bandwidth and CPU processing. To avoid congestion, it is therefore imperative that operators correctly provision the rates at which S-BFD packets are transmitted. When BFD is used across multiple hops, a congestion control mechanism MUST be implemented, and when congestion is detected, the BFD implementation MUST reduce the amount of traffic it generates. The exact mechanism used to detect congestion is outside the scope of this specification but may include the detection of lost BFD Control packets or other means. The SBFDReflector can limit the rate at which SBFDInitiators will be sending S-BFD Control packets by utilizing Required Min RX Interval, but at the expense of detection time (i.e., detection time will increase).
S-BFDが障害検出を実行すると、帯域幅やCPU処理などのリソースを消費します。したがって、輻輳を回避するには、オペレーターがS-BFDパケットが送信されるレートを正しくプロビジョニングすることが不可欠です。 BFDが複数のホップで使用される場合、輻輳制御メカニズムを実装する必要があり、輻輳が検出された場合、BFD実装は、生成するトラフィックの量を削減する必要があります。輻輳を検出するために使用される正確なメカニズムは、この仕様の範囲外ですが、失われたBFD制御パケットまたは他の手段の検出が含まれる場合があります。 SBFDReflectorは、必要な最小RX間隔を利用して、SBFDInitiatorsがS-BFD制御パケットを送信する速度を制限できますが、検出時間を犠牲にします（つまり、検出時間が増加します）。
Demultiplexing requirements for the initial packet are described in Section 7.1. Because of this, the S-BFD mechanism can co-exist with classical BFD sessions.
最初のパケットの逆多重化要件については、7.1節で説明します。このため、S-BFDメカニズムは従来のBFDセッションと共存できます。
The concept of the S-BFD Echo function is similar to the BFD Echo function described in [RFC5880]. S-BFD Echo packets have the destination of "self"; thus, S-BFD Echo packets are self-generated and self-terminated after traversing a link/path. S-BFD Echo packets are expected to U-turn on the target node in the data plane and MUST NOT be processed by any Reflector BFD sessions on the target node.
S-BFDエコー機能の概念は、[RFC5880]で説明されているBFDエコー機能に似ています。 S-BFDエコーパケットの宛先は「自己」です。したがって、S-BFDエコーパケットは、リンク/パスを通過した後に自己生成され、自己終了します。 S-BFDエコーパケットは、データプレーンのターゲットノードでUターンすることが期待されており、ターゲットノードのReflector BFDセッションで処理してはなりません（MUST NOT）。
When using the S-BFD Echo function, it is RECOMMENDED that:
S-BFDエコー機能を使用する場合、次のことをお勧めします。
o Both S-BFD Control packets and S-BFD Echo packets be sent.
o S-BFD制御パケットとS-BFDエコーパケットの両方が送信されます。
o Both S-BFD Control packets and S-BFD Echo packets have the same semantics in the forward direction to reach the target node.
o S-BFD制御パケットとS-BFDエコーパケットはどちらも、ターゲットノードに到達するための順方向のセマンティクスが同じです。
In other words, it is not preferable to send just S-BFD Echo packets without also sending S-BFD Control packets. There are two reasons behind this suggestion:
つまり、S-BFD制御パケットを送信せずにS-BFDエコーパケットのみを送信することは好ましくありません。この提案には2つの理由があります。
o S-BFD Control packets can verify the reachability of the intended target node; this allows one to have confidence that S-BFD Echo packets are U-turning on the expected target node.
o S-BFD制御パケットは、目的のターゲットノードの到達可能性を確認できます。これにより、予想されるターゲットノードでS-BFDエコーパケットがUターンしていることを確信できます。
o S-BFD Control packets can detect when the target node is going out of service (i.e., by receiving AdminDown state).
o S-BFD制御パケットは、ターゲットノードがサービスを停止していることを（つまり、AdminDown状態を受信することで）検出できます。
S-BFD Echo packets can be spoofed and can U-turn in a transit node before reaching the expected target node. When the S-BFD Echo function is used, it is RECOMMENDED in this specification that both S-BFD Control packets and S-BFD Echo packets be sent. While the additional use of S-BFD Control packets alleviates these two concerns, some form of authentication MAY still be included.
S-BFDエコーパケットはスプーフィングされる可能性があり、予想されるターゲットノードに到達する前にトランジットノードでUターンできます。 S-BFDエコー機能を使用する場合、この仕様ではS-BFD制御パケットとS-BFDエコーパケットの両方を送信することをお勧めします。 S-BFD制御パケットをさらに使用すると、これらの2つの問題が緩和されますが、認証の形式がまだ含まれている場合があります。
The usage of the Required Min Echo RX Interval field is described in Sections 7.2.2 and 7.3.2. Because of the stateless nature of SBFDReflector sessions, a value specified in the Required Min Echo RX Interval field is not very meaningful to the SBFDReflector. Thus, it is RECOMMENDED that the Required Min Echo RX Interval field simply be set to zero by the SBFDInitiator. The SBFDReflector MAY set the Required Min Echo RX Interval field to an appropriate value to control the rate at which it wants to receive S-BFD Echo packets.
Required Min Echo RX Intervalフィールドの使用方法については、セクション7.2.2および7.3.2で説明しています。 SBFDReflectorセッションのステートレスな性質のため、[必要な最小エコー受信間隔]フィールドに指定された値は、SBFDReflectorにとってあまり意味がありません。したがって、必要な最小エコーRX間隔フィールドは、SBFDInitiatorによって単に0に設定されることが推奨されます。 SBFDReflectorは、必要な最小エコー受信間隔フィールドを適切な値に設定して、S-BFDエコーパケットを受信するレートを制御する場合があります。
The following aspects of S-BFD Echo functions are left as implementation details and are outside the scope of this document:
S-BFDエコー機能の次の側面は実装の詳細として残されており、このドキュメントの範囲外です。
o Format of the S-BFD Echo packet (e.g., data beyond UDP header).
o S-BFDエコーパケットのフォーマット（UDPヘッダーを超えるデータなど）。
o Procedures on when and how to use the S-BFD Echo function.
o S-BFDエコー機能をいつどのように使用するかの手順。
The same security considerations as those described in [RFC5880] apply to this document. Additionally, implementing the following measures will strengthen security aspects of the mechanism described by this document:
[RFC5880]で説明されているものと同じセキュリティの考慮事項がこのドキュメントに適用されます。さらに、次の対策を実施すると、このドキュメントで説明するメカニズムのセキュリティ面が強化されます。
o The SBFDInitiator MAY pick a sequence number to be set in "sequence number" in the Authentication Section, based on the configured authentication mode.
o SBFDInitiatorは、構成された認証モードに基づいて、認証セクションの「シーケンス番号」に設定されるシーケンス番号を選択してもよい（MAY）。
o The SBFDReflector MUST NOT use the crypto sequence number to make a decision about accepting the packet. This is because the SBFDReflector does not maintain S-BFD peer state and because the SBFDReflector can receive S-BFD packets from multiple SBFDInitiators. Consequently, BFD authentication can be used, but not the sequence number.
o SBFDReflectorは、パケットの受け入れに関する決定を行うために暗号シーケンス番号を使用してはなりません（MUST NOT）。これは、SBFDReflectorがS-BFDピアの状態を維持しないため、およびSBFDReflectorが複数のSBFDInitiatorからS-BFDパケットを受信できるためです。したがって、BFD認証は使用できますが、シーケンス番号は使用できません。
o The SBFDReflector MAY use the Auth Key ID in the incoming packet to verify the Authentication Data.
o SBFDReflectorは、受信データの認証キーIDを使用して、認証データを検証できます。
o The SBFDReflector MUST accept the packet if authentication is successful.
o 認証が成功した場合、SBFDReflectorはパケットを受け入れる必要があります。
o The SBFDReflector MUST compute the Authentication Data and MUST use the same sequence number that it received in the S-BFD Control packet to which it is responding.
o SBFDReflectorは認証データを計算しなければならず（MUST）、応答しているS-BFD制御パケットで受信したのと同じシーケンス番号を使用しなければなりません（MUST）。
o The SBFDInitiator SHOULD accept an S-BFD Control packet with a sequence number within the permissible range. One potential approach is the procedure explained in [BFD-GEN-AUTH].
o SBFDInitiatorは、許容範囲内のシーケンス番号を持つS-BFD制御パケットを受け入れる必要があります（SHOULD）。 1つの潜在的なアプローチは、[BFD-GEN-AUTH]で説明されている手順です。
Using the above method,
上記の方法を使用して、
o SBFDReflectors continue to remain stateless, despite using security.
o セキュリティを使用しているにもかかわらず、SBFDReflectorsは引き続きステートレスのままです。
o SBFDReflectors are not susceptible to replay attacks, as they always respond to S-BFD Control packets irrespective of the sequence number carried.
o SBFDReflectorは、伝送されるシーケンス番号に関係なく常にS-BFD制御パケットに応答するため、リプレイ攻撃の影響を受けません。
o An attacker cannot impersonate the responder, since the SBFDInitiator will only accept S-BFD Control packets that come with the sequence number that it had originally used when sending the S-BFD Control packet.
o SBFDInitiatorは、S-BFD制御パケットを送信するときに最初に使用したシーケンス番号が付いているS-BFD制御パケットのみを受け入れるため、攻撃者がレスポンダを偽装することはできません。
Additionally, the use of strong forms of authentication is strongly encouraged for S-BFD. The use of Simple Password authentication [RFC5880] potentially puts other services at risk if S-BFD packets can be intercepted and those password values are reused for other services.
さらに、S-BFDでは強力な認証形式の使用を強くお勧めします。簡易パスワード認証[RFC5880]を使用すると、S-BFDパケットが傍受され、それらのパスワード値が他のサービスに再利用される場合、他のサービスが危険にさらされる可能性があります。
Considerations related to loop problems are covered in Appendix A.
ループの問題に関する考慮事項については、付録Aで説明しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, <http://www.rfc-editor.org/info/rfc5880>.
[RFC5880] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection（BFD）」、RFC 5880、DOI 10.17487 / RFC5880、2010年6月、<http://www.rfc-editor.org/info/rfc5880>。
[BFD-GEN-AUTH] Bhatia, M., Manral, V., Zhang, D., and M. Jethanandani, "BFD Generic Cryptographic Authentication", Work in Progress, draft-ietf-bfd-generic-crypto-auth-06, April 2014.
[BFD-GEN-AUTH] Bhatia、M.、Manral、V.、Zhang、D。、およびM. Jethanandani、「BFD Generic Cryptographic Authentication」、Work in Progress、draft-ietf-bfd-generic-crypto-auth- 2014年4月6日。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC791, September 1981, <http://www.rfc-editor.org/info/rfc791>.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC791、1981年9月、<http://www.rfc-editor.org/info/rfc791>。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<http://www.rfc-editor.org/info/ rfc2460>。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <http://www.rfc-editor.org/info/rfc3031>.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocol Label Switching Architecture」、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、<http://www.rfc-editor.org/info / rfc3031>。
[RFC7881] Pignataro, C., Ward, D., and N. Akiya, "Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS", RFC 7881, DOI 10.17487/RFC7881, July 2016, <http://www.rfc-editor.org/info/rfc7881>.
[RFC7881] Pignataro、C.、Ward、D。、およびN. Akiya、「IPv4、IPv6、およびMPLSのシームレスな双方向転送検出（S-BFD）」、RFC 7881、DOI 10.17487 / RFC7881、2016年7月、<http ：//www.rfc-editor.org/info/rfc7881>。
[RFC7882] Aldrin, S., Pignataro, C., Mirsky, G., and N. Kumar, "Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases", RFC 7882, DOI 10.17487/RFC7882, July 2016, <http://www.rfc-editor.org/info/rfc7882>.
[RFC7882] Aldrin、S.、Pignataro、C.、Mirsky、G。、およびN. Kumar、「シームレスな双方向転送検出（S-BFD）の使用例」、RFC 7882、DOI 10.17487 / RFC7882、2016年7月、<http ：//www.rfc-editor.org/info/rfc7882>。
[RFC7885] Govindan, V. and C. Pignataro, "Seamless Bidirectional Forwarding Detection (S-BFD) for Virtual Circuit Connectivity Verification (VCCV)", RFC 7885, DOI 10.17487/RFC7885, July 2016, <http://www.rfc-editor.org/info/rfc7885>.
[RFC7885] Govindan、V。、およびC. Pignataro、「シームレスな双方向転送転送検出（S-BFD）の仮想回路接続検証（VCCV）」、RFC 7885、DOI 10.17487 / RFC7885、2016年7月、<http：// www。 rfc-editor.org/info/rfc7885>。
Consider a scenario where we have two nodes and both are S-BFD capable.
2つのノードがあり、どちらもS-BFD対応であるシナリオを考えてみます。
Node A (IP 2001:db8::1) ----------------- Node B (IP 2001:db8::2)
|
|
Man in the Middle (MITM)
Assume that Node A reserved a discriminator 0x01010101 for target identifier 2001:db8::1 and has a reflector session in listening mode. Similarly, Node B reserved a discriminator 0x02020202 for its target identifier 2001:db8::2 and also has a reflector session in listening mode.
ノードAがターゲット識別子2001：db8 :: 1の弁別子0x01010101を予約し、リスニングモードでリフレクターセッションを持っていると想定します。同様に、ノードBは、ターゲット識別子2001：db8 :: 2のために弁別子0x02020202を予約し、リスニングモードでリフレクターセッションも持っています。
Suppose that a MITM sends a spoofed packet with My Discriminator = 0x01010101, Your Discriminator = 0x02020202, source IP as 2001:db8::1, and destination IP as 2001:db8::2. When this packet reaches Node B, the reflector session on Node B will swap the discriminators and IP addresses of the received packet and reflect it back, since the Your Discriminator value of the received packet matches the reserved discriminator of Node B. The reflected packet that reached Node A will have My Discriminator = 0x02020202 and Your Discriminator = 0x01010101. Since the Your Discriminator value of the received packet matches the reserved discriminator of Node A, Node A will swap the discriminators and reflect the packet back to Node B. Since the reflectors must set the TTL of the reflected packets to 255, the above scenario will result in an infinite loop because of just one malicious packet injected from the MITM.
MITMがMy Discriminator = 0x01010101、Your Discriminator = 0x02020202、送信元IPが2001：db8 :: 1、宛先IPが2001：db8 :: 2のスプーフィングされたパケットを送信するとします。このパケットがノードBに到達すると、受信パケットのYour Discriminator値がノードBの予約済み識別子と一致するため、ノードBのリフレクターセッションは受信パケットの識別子とIPアドレスを交換して反映します。ノードAに到達すると、My Discriminator = 0x02020202およびYour Discriminator = 0x01010101になります。受信したパケットのYour Discriminator値がノードAの予約済み識別子と一致するため、ノードAは識別子を交換し、パケットをノードBに反映します。リフレクターは反射パケットのTTLを255に設定する必要があるため、上記のシナリオではMITMから挿入された悪意のあるパケットが1つしかないため、無限ループが発生します。
The solution is to avoid the loop problem by using the D bit (Demand mode bit). The initiator always sets the D bit, and the reflector always clears it. This way, we can determine if a received packet was a reflected packet and avoid reflecting it back.
解決策は、Dビット（デマンドモードビット）を使用してループの問題を回避することです。イニシエーターは常にDビットを設定し、リフレクターは常にそれをクリアします。このようにして、受信したパケットが反射されたパケットであったかどうかを判別し、それを反射することを回避できます。
Acknowledgements
謝辞
The authors would like to thank Jeffrey Haas, Greg Mirsky, Marc Binderberger, and Alvaro Retana for performing thorough reviews and providing a number of suggestions. The authors would also like to thank Girija Raghavendra Rao, Les Ginsberg, Srihari Raghavan, Vanitha Neelamegam, and Vengada Prasad Govindan from Cisco Systems for providing valuable comments. Finally, the authors would also like to thank John E. Drake and Pablo Frank for providing comments and suggestions.
著者は、徹底的なレビューを行い、多くの提案を提供してくれたJeffrey Haas、Greg Mirsky、Marc Binderberger、およびAlvaro Retanaに感謝します。著者は、貴重なコメントを提供してくれたCisco SystemsのGirija Raghavendra Rao、Les Ginsberg、Srihari Raghavan、Vanitha Neelamegam、およびVengada Prasad Govindanにも感謝します。最後に、著者はコメントと提案を提供してくれたJohn E. DrakeとPablo Frankにも感謝します。
Contributors
貢献者
The following are key contributors to this document:
このドキュメントの主な貢献者は次のとおりです。
Tarek Saad, Cisco Systems, Inc. Siva Sivabalan, Cisco Systems, Inc. Nagendra Kumar, Cisco Systems, Inc. Mallik Mudigonda, Cisco Systems, Inc. Sam Aldrin, Google
トレックサード、Cisco Systems、Inc. Shiva Shivabalam、Cisco Systems、Inc. Nagendra Kumar、Cisco Systems、Inc.マリック・ムディゴンダ、Cisco Systems、Inc.一部のアルドリン、グーグル
Authors' Addresses
著者のアドレス
Carlos Pignataro Cisco Systems, Inc.
Carlos Pignataro Cisco Systems、Inc.
Email: cpignata@cisco.com
Dave Ward Cisco Systems, Inc.
Dave Ward Cisco Systems、Inc.
Email: wardd@cisco.com
Nobo Akiya Big Switch Networks
Nobo Akiya Big Switch Networks
Email: nobo.akiya.dev@gmail.com
Manav Bhatia Ionos Networks
Manava Bhatia Yonos Networks
Email: manav@ionosnetworks.com
Santosh Pallagatti
サントシュパラガッティ
Email: santosh.pallagatti@gmail.com