双方向フォワーディング検出（BFD）
英文を機械翻訳で日本語訳としています。日本語訳が正しくないことが考えられますので原文をメインとし、参考程度にご利用ください。
日本語訳
Internet Engineering Task Force (IETF) D. Katz
Request for Comments: 5880 D. Ward
Category: Standards Track Juniper Networks
ISSN: 2070-1721 June 2010
Bidirectional Forwarding Detection (BFD)
双方向転送検出（BFD）
Abstract
概要
This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols.
このドキュメントでは、インターフェイス、データリンク、および転送エンジン自体を含む2つの転送エンジン間の双方向パスの障害を検出することを目的としたプロトコルについて説明します。 メディア、データプロトコル、およびルーティングプロトコルから独立して動作します。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。 これは、IETFコミュニティのコンセンサスを表しています。 これは公開レビューを受けており、Internet Engineering Steering Group（IESG）による公開が承認されています。 インターネット標準の詳細については、RFC 5741のセクション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/rfc5880.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc5880で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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に記載されているように保証なしで提供されます。
Katz & Ward Standards Track [Page 1] RFC 5880 Bidirectional Forwarding Detection June 2010 Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Design ..........................................................4
3. Protocol Overview ...............................................5
3.1. Addressing and Session Establishment .......................5
3.2. Operating Modes ............................................5
4. BFD Control Packet Format .......................................7
4.1. Generic BFD Control Packet Format ..........................7
4.2. Simple Password Authentication Section Format .............11
4.3. Keyed MD5 and Meticulous Keyed MD5 Authentication
Section Format ............................................11
4.4. Keyed SHA1 and Meticulous Keyed SHA1
Authentication Section Format .............................13
5. BFD Echo Packet Format .........................................14
6. Elements of Procedure ..........................................14
6.1. Overview ..................................................14
6.2. BFD State Machine .........................................16
6.3. Demultiplexing and the Discriminator Fields ...............17
6.4. The Echo Function and Asymmetry ...........................18
6.5. The Poll Sequence .........................................19
6.6. Demand Mode ...............................................19
6.7. Authentication ............................................21
6.7.1. Enabling and Disabling Authentication ..............21
6.7.2. Simple Password Authentication .....................22
6.7.3. Keyed MD5 and Meticulous Keyed MD5 Authentication ..23
6.7.4. Keyed SHA1 and Meticulous Keyed SHA1
Authentication .....................................25
6.8. Functional Specifics ......................................27
6.8.1. State Variables ....................................27
6.8.2. Timer Negotiation ..................................30
6.8.3. Timer Manipulation .................................31
6.8.4. Calculating the Detection Time .....................32
6.8.5. Detecting Failures with the Echo Function ..........33
6.8.6. Reception of BFD Control Packets ...................33
6.8.7. Transmitting BFD Control Packets ...................36
6.8.8. Reception of BFD Echo Packets ......................39
6.8.9. Transmission of BFD Echo Packets ...................39
6.8.10. Min Rx Interval Change ............................40
6.8.11. Min Tx Interval Change ............................40
6.8.12. Detect Multiplier Change ..........................40
6.8.13. Enabling or Disabling The Echo Function ...........40
6.8.14. Enabling or Disabling Demand Mode .................40
6.8.15. Forwarding Plane Reset ............................41
6.8.16. Administrative Control ............................41
6.8.17. Concatenated Paths ................................41
6.8.18. Holding Down Sessions .............................42
Katz & Ward Standards Track [Page 2]
RFC 5880 Bidirectional Forwarding Detection June 2010
7. Operational Considerations .....................................43
8. IANA Considerations ............................................44
9. Security Considerations ........................................45
10. References ....................................................46
10.1. Normative References .....................................46
10.2. Informative References ...................................47
Appendix A. Backward Compatibility (Non-Normative) ................48
Appendix B. Contributors ..........................................48
Appendix C. Acknowledgments .......................................49
1.はじめに............................................... ..... 3
1.1.このドキュメントで使用されている規則........................4
2.設計.............................................................4
3.プロトコルの概要.............................................. .5
3.1.アドレッシングとセッションの確立....................... 5
3.2.動作モード............................................ 5
4. BFD制御パケットのフォーマット...................................7
4.1.汎用BFD制御パケットフォーマット.......................... 7
4.2.単純なパスワード認証セクションの形式............. 11
4.3.キー付きMD5および細かいキー付きMD5認証
セクション形式............................................ 11
4.4.キー付きSHA1および細かいキー付きSHA1
認証セクションの形式............................. 13
5. BFDエコーパケットのフォーマット.................................14
6.手順の要素........................................ 14
6.1.概要........................................................14
6.2. BFDステートマシン..........................................16
6.3.逆多重化と識別フィールド............... 17
6.4.エコー機能と非対称性........................... 18
6.5.ポーリングシーケンス........................................19
6.6.デマンドモード..............................................19
6.7.認証............................................ 21
6.7.1.認証の有効化と無効化.............. 21
6.7.2.単純なパスワード認証..................... 22
6.7.3.鍵付きMD5および細かい鍵付きMD5認証..23
6.7.4.キー付きSHA1および細かいキー付きSHA1
認証................................................25
6.8.機能の詳細................................................ 27
6.8.1.状態変数.................................... 27
6.8.2.タイマー交渉.................................. 30
6.8.3.タイマー操作................................. 31
6.8.4.検出時間の計算..................... 32
6.8.5.エコー機能での障害の検出.......... 33
6.8.6. BFD制御パケットの受信................... 33
6.8.7. BFD制御パケットの送信................... 36
6.8.8. BFDエコーパケットの受信...................... 39
6.8.9. BFDエコーパケットの送信................... 39
6.8.10.最小Rx間隔の変更............................ 40
6.8.11.最小送信間隔の変更............................ 40
6.8.12.乗数の変化を検出.......................... 40
6.8.13.エコー機能の有効化または無効化........... 40
6.8.14.デマンドモードの有効化または無効化..................40
6.8.15.フォワーディングプレーンリセット....................41
6.8.16.行政管理............................ 41
6.8.17.連結パス................................ 41
6.8.18.セッションの開催............................. 42
7.運用上の考慮事項..................................... 43
8. IANAの考慮事項............................................ 44
9.セキュリティに関する考慮事項.....................................45
10.参考資料........................................................46
10.1規範的な参考文献..................................... 46
10.2有益な参照..................................................47
付録A.下位互換性（非規定）................ 48
付録B.貢献者.......................................... 48
付録C.謝辞....................................... 49
1. Introduction
1.はじめに
An increasingly important feature of networking equipment is the rapid detection of communication failures between adjacent systems, in order to more quickly establish alternative paths. Detection can come fairly quickly in certain circumstances when data link hardware comes into play (such as Synchronous Optical Network (SONET) alarms). However, there are media that do not provide this kind of signaling (such as Ethernet), and some media may not detect certain kinds of failures in the path, for example, failing interfaces or forwarding engine components.
ネットワーキング機器のますます重要な機能は、代替パスをより迅速に確立するために、隣接するシステム間の通信障害を迅速に検出することです。 データリンクハードウェアが機能する特定の状況（同期光ネットワーク（SONET）アラームなど）では、検出はかなり迅速に行われます。 ただし、この種のシグナリングを提供しないメディア（イーサネットなど）があり、一部のメディアは、パスの特定の種類の障害（インターフェイスの障害や転送エンジンコンポーネントなど）を検出できない場合があります。
Networks use relatively slow "Hello" mechanisms, usually in routing
protocols, to detect failures when there is no hardware signaling to
help out. The time to detect failures ("Detection Times") available
in the existing protocols are no better than a second, which is far
too long for some applications and represents a great deal of lost
data at gigabit rates. Furthermore, routing protocol Hellos are of
no help when those routing protocols are not in use, and the
semantics of detection are subtly different -- they detect a failure
in the path between the two routing protocol engines.
ネットワークは、通常はルーティングプロトコルで比較的遅い「Hello」メカニズムを使用して、役立つハードウェアシグナリングがない場合に障害を検出します。 既存のプロトコルで利用可能な障害を検出する時間（「検出時間」）は1秒以下であり、これは一部のアプリケーションにとっては長すぎ、ギガビットレートでの大量のデータ損失を表しています。 さらに、これらのルーティングプロトコルが使用されていない場合、ルーティングプロトコルのHelloは役に立ちません。検出のセマンティクスは微妙に異なり、2つのルーティングプロトコルエンジン間のパスの障害を検出します。
The goal of Bidirectional Forwarding Detection (BFD) is to provide low-overhead, short-duration detection of failures in the path between adjacent forwarding engines, including the interfaces, data link(s), and, to the extent possible, the forwarding engines themselves.
双方向フォワーディング検出（BFD）の目的は、隣接するフォワーディングエンジン（インターフェイス、データリンク、および可能な限りフォワーディングエンジンを含む）間のパスの障害を、オーバーヘッドが少なく、短時間で検出できるようにすることです。 自分自身。
An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of Detection Times and overhead, to avoid a proliferation of different methods.
追加の目標は、さまざまな方法の急増を回避するために、さまざまな検出時間とオーバーヘッドを備えた、あらゆるメディア、あらゆるプロトコルレイヤーの活性検出に使用できる単一のメカニズムを提供することです。
This document specifies the details of the base protocol. The use of some mechanisms are application dependent and are specified in a separate series of application documents. These issues are so noted.
このドキュメントでは、基本プロトコルの詳細を説明しています。 一部のメカニズムの使用はアプリケーションに依存しており、別の一連のアプリケーションドキュメントで指定されています。 これらの問題はそのように記載されています。
Katz & Ward Standards Track [Page 3] RFC 5880 Bidirectional Forwarding Detection June 2010 Note that many of the exact mechanisms are implementation dependent and will not affect interoperability, and are thus outside the scope of this specification. Those issues are so noted.
正確なメカニズムの多くは実装依存であり、相互運用性に影響しないため、この仕様の範囲外であることに注意してください。 それらの問題はそのように記されています。
1.1. Conventions Used in This Document
1.1。 このドキュメントで使用される規則
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 [KEYWORDS].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [KEYWORDS]で説明されているように解釈されます。
2. Design
2.デザイン
BFD is designed to detect failures in communication with a forwarding plane next hop. It is intended to be implemented in some component of the forwarding engine of a system, in cases where the forwarding and control engines are separated. This not only binds the protocol more to the forwarding plane, but decouples the protocol from the fate of the routing protocol engine, making it useful in concert with various "graceful restart" mechanisms for those protocols. BFD may also be implemented in the control engine, though doing so may preclude the detection of some kinds of failures.
BFDは、転送プレーンのネクストホップとの通信の障害を検出するように設計されています。 これは、転送エンジンと制御エンジンが分離されている場合に、システムの転送エンジンのコンポーネントに実装することを目的としています。 これは、プロトコルをフォワーディングプレーンにバインドするだけでなく、プロトコルをルーティングプロトコルエンジンの運命から切り離し、これらのプロトコルのさまざまな「グレースフルリスタート」メカニズムと連携して使用できるようにします。 制御エンジンにBFDを実装することもできますが、そうすると、ある種の障害を検出できなくなる場合があります。
BFD operates on top of any data protocol (network layer, link layer, tunnels, etc.) being forwarded between two systems. It is always run in a unicast, point-to-point mode. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. BFD may be running at multiple layers in a system. The context of the operation of any particular BFD session is bound to its encapsulation.
BFDは、2つのシステム間で転送されるデータプロトコル（ネットワーク層、リンク層、トンネルなど）の上で動作します。 常にユニキャストのポイントツーポイントモードで実行されます。 BFDパケットは、メディアとネットワークに適したカプセル化プロトコルのペイロードとして運ばれます。 BFDはシステムの複数のレイヤーで実行されている可能性があります。 特定のBFDセッションの操作のコンテキストは、そのカプセル化にバインドされています。
BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS Label Switched Paths (LSPs), multihop routed paths, and unidirectional links (so long as there is some return path, of course). Multiple BFD sessions can be established between the same pair of systems when multiple paths between them are present in at least one direction, even if a lesser number of paths are available in the other direction (multiple parallel unidirectional links or MPLS LSPs, for example).
BFDは、直接物理リンク、仮想回線、トンネル、MPLSラベルスイッチドパス（LSP）、マルチホップルーテッドパス、および単方向リンク（もちろん、戻りパスがある限り）を含む、システム間のあらゆる種類のパスで障害検出を提供できます。 ）。 複数のBFDセッションは、同じシステムのペア間で複数のパスが少なくとも1つの方向に存在する場合、他の方向で利用できるパスの数が少ない場合でも（複数の並列単方向リンクまたはMPLS LSPなど）、確立できます。 。
The BFD state machine implements a three-way handshake, both when establishing a BFD session and when tearing it down for any reason, to ensure that both systems are aware of the state change.
BFDステートマシンは、BFDセッションを確立するときと何らかの理由でそれを破棄するときの両方で、3ウェイハンドシェイクを実装して、両方のシステムが状態の変化を確実に認識できるようにします。
Katz & Ward Standards Track [Page 4] RFC 5880 Bidirectional Forwarding Detection June 2010 BFD can be abstracted as a simple service. The service primitives provided by BFD are to create, destroy, and modify a session, given the destination address and other parameters. BFD in return provides a signal to its clients indicating when the BFD session goes up or down.
BFDは単純なサービスとして抽象化できます。 BFDによって提供されるサービスプリミティブは、宛先アドレスとその他のパラメータを指定して、セッションを作成、破棄、および変更することです。 代わりにBFDは、BFDセッションがいつアップまたはダウンするかを示す信号をクライアントに提供します。
3. Protocol Overview
3.プロトコルの概要
BFD is a simple Hello protocol that, in many respects, is similar to the detection components of well-known routing protocols. A pair of systems transmit BFD packets periodically over each path between the two systems, and if a system stops receiving BFD packets for long enough, some component in that particular bidirectional path to the neighboring system is assumed to have failed. Under some conditions, systems may negotiate not to send periodic BFD packets in order to reduce overhead.
BFDは単純なHelloプロトコルであり、多くの点で、よく知られているルーティングプロトコルの検出コンポーネントに似ています。 システムのペアは、2つのシステム間の各パスを介して定期的にBFDパケットを送信します。システムが十分長い時間BFDパケットの受信を停止した場合、隣接するシステムへのその特定の双方向パスの一部のコンポーネントに障害が発生したと見なされます。 状況によっては、オーバーヘッドを減らすために、システムが定期的なBFDパケットを送信しないようにネゴシエートする場合があります。
A path is only declared to be operational when two-way communication has been established between systems, though this does not preclude the use of unidirectional links.
パスは、システム間で双方向通信が確立されている場合にのみ動作可能であると宣言されますが、これは単方向リンクの使用を妨げるものではありません。
A separate BFD session is created for each communications path and data protocol in use between two systems.
2つのシステム間で使用される通信パスとデータプロトコルごとに、個別のBFDセッションが作成されます。
Each system estimates how quickly it can send and receive BFD packets in order to come to an agreement with its neighbor about how rapidly detection of failure will take place. These estimates can be modified in real time in order to adapt to unusual situations. This design also allows for fast systems on a shared medium with a slow system to be able to more rapidly detect failures between the fast systems while allowing the slow system to participate to the best of its ability.
各システムは、障害の検出がどれだけ迅速に行われるかについてネイバーと合意に達するために、BFDパケットを送受信できる速度を推定します。 これらの推定値は、異常な状況に適応するためにリアルタイムで変更できます。 この設計により、低速システムを含む共有メディア上の高速システムでも、高速システム間の障害をより迅速に検出しながら、低速システムが最大限の能力を発揮できるようになります。
3.1. Addressing and Session Establishment
3.1。 アドレッシングとセッションの確立
A BFD session is established based on the needs of the application that will be making use of it. It is up to the application to determine the need for BFD, and the addresses to use -- there is no discovery mechanism in BFD. For example, an OSPF [OSPF] implementation may request a BFD session to be established to a neighbor discovered using the OSPF Hello protocol.
BFDセッションは、それを利用するアプリケーションのニーズに基づいて確立されます。 BFDの必要性と使用するアドレスを決定するのはアプリケーション次第です。BFDには検出メカニズムはありません。 たとえば、OSPF [OSPF]実装は、OSPF Helloプロトコルを使用して発見されたネイバーに対して確立されるBFDセッションを要求する場合があります。
3.2. Operating Modes
3.2。 動作モード
BFD has two operating modes that may be selected, as well as an additional function that can be used in combination with the two modes.
BFDには、選択可能な2つの動作モードと、2つのモードと組み合わせて使用できる追加機能があります。
Katz & Ward Standards Track [Page 5] RFC 5880 Bidirectional Forwarding Detection June 2010 The primary mode is known as Asynchronous mode. In this mode, the systems periodically send BFD Control packets to one another, and if a number of those packets in a row are not received by the other system, the session is declared to be down.
プライマリモードは非同期モードと呼ばれます。 このモードでは、システムは定期的にBFD制御パケットを相互に送信し、それらのパケットが連続して他のシステムによって受信されない場合、セッションはダウンしていると宣言されます。
The second mode is known as Demand mode. In this mode, it is assumed that a system has an independent way of verifying that it has connectivity to the other system. Once a BFD session is established, such a system may ask the other system to stop sending BFD Control packets, except when the system feels the need to verify connectivity explicitly, in which case a short sequence of BFD Control packets is exchanged, and then the far system quiesces. Demand mode may operate independently in each direction, or simultaneously.
2番目のモードは、デマンドモードと呼ばれます。 このモードでは、システムに他のシステムへの接続があることを確認する独立した方法があると想定されます。 BFDセッションが確立されると、システムが接続を明示的に確認する必要があると感じた場合を除いて、そのようなシステムは他のシステムにBFD制御パケットの送信の停止を要求する場合があります。その場合、BFD制御パケットの短いシーケンスが交換され、 これまでのシステムの休止。 デマンドモードは、各方向で独立して、または同時に動作します。
An adjunct to both modes is the Echo function. When the Echo function is active, a stream of BFD Echo packets is transmitted in such a way as to have the other system loop them back through its forwarding path. If a number of packets of the echoed data stream are not received, the session is declared to be down. The Echo function may be used with either Asynchronous or Demand mode. Since the Echo function is handling the task of detection, the rate of periodic transmission of Control packets may be reduced (in the case of Asynchronous mode) or eliminated completely (in the case of Demand mode).
両方のモードの補助は、エコー機能です。 エコー機能がアクティブな場合、BFDエコーパケットのストリームは、他のシステムが転送パスを介してループバックするように送信されます。 エコーされたデータストリームのいくつかのパケットが受信されない場合、セッションはダウンしていると宣言されます。 エコー機能は、非同期モードまたはデマンドモードで使用できます。 Echo機能が検出のタスクを処理しているため、制御パケットの定期的な送信速度が低下する（非同期モードの場合）か、完全に排除される（デマンドモードの場合）。
Pure Asynchronous mode is advantageous in that it requires half as many packets to achieve a particular Detection Time as does the Echo function. It is also used when the Echo function cannot be supported for some reason.
純粋な非同期モードは、エコー機能の場合と比較して、特定の検出時間を達成するために必要なパケット数が半分になるという点で有利です。 また、何らかの理由でエコー機能がサポートできない場合にも使用されます。
The Echo function has the advantage of truly testing only the forwarding path on the remote system. This may reduce round-trip jitter and thus allow more aggressive Detection Times, as well as potentially detecting some classes of failure that might not otherwise be detected.
エコー機能には、リモートシステムの転送パスのみを実際にテストできるという利点があります。 これにより、ラウンドトリップジッタが減少し、より積極的な検出時間が可能になるだけでなく、他の方法では検出されない可能性のある障害のクラスが検出される可能性があります。
The Echo function may be enabled individually in each direction. It is enabled in a particular direction only when the system that loops the Echo packets back signals that it will allow it, and when the system that sends the Echo packets decides it wishes to.
エコー機能は、各方向で個別に有効にできます。 エコーパケットをループするシステムがそれを許可する信号を返し、エコーパケットを送信するシステムが希望することを決定した場合にのみ、特定の方向で有効になります。
Demand mode is useful in situations where the overhead of a periodic protocol might prove onerous, such as a system with a very large number of BFD sessions. It is also useful when the Echo function is being used symmetrically. Demand mode has the disadvantage that Detection Times are essentially driven by the heuristics of the system implementation and are not known to the BFD protocol. Demand Katz & Ward Standards Track [Page 6] RFC 5880 Bidirectional Forwarding Detection June 2010 mode may not be used when the path round-trip time is greater than the desired Detection Time, or the protocol will fail to work properly. See section 6.6 for more details.
デマンドモードは、BFDセッションの数が非常に多いシステムなど、定期的なプロトコルのオーバーヘッドが煩わしい場合に役立ちます。 また、エコー機能が対称的に使用されている場合にも役立ちます。 デマンドモードには、検出時間が本質的にシステム実装のヒューリスティックによって駆動され、BFDプロトコルには認識されないという欠点があります。 パスのラウンドトリップ時間が目的の検出時間よりも長い場合、デマンドモードは使用できません。そうしないと、プロトコルが正しく機能しなくなります。 詳細については、セクション6.6を参照してください。
4. BFD Control Packet Format
4. BFD制御パケットの形式
4.1. Generic BFD Control Packet Format
4.1。 一般的なBFD制御パケット形式
BFD Control packets are sent in an encapsulation appropriate to the environment. The specific encapsulation is outside of the scope of this specification. See the appropriate application document for encapsulation details.
BFD制御パケットは、環境に適したカプセル化で送信されます。 特定のカプセル化は、この仕様の範囲外です。 カプセル化の詳細については、適切なアプリケーションドキュメントを参照してください。
The BFD Control packet has a Mandatory Section and an optional Authentication Section. The format of the Authentication Section, if present, is dependent on the type of authentication in use.
BFD制御パケットには、必須セクションとオプションの認証セクションがあります。 存在する場合、認証セクションのフォーマットは、使用中の認証のタイプによって異なります。
The Mandatory Section of a BFD Control packet has the following format:
BFD制御パケットの必須セクションの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| My Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Your Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Desired Min TX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Min RX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Min Echo RX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers | Diag |Sta|P|F|C|A|D|M| マルチを検出 | 長さ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 私の弁別 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| あなたの弁別 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 望ましい最小TX間隔 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 必要な最小RX間隔 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 必要な最小エコーRX間隔 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An optional Authentication Section MAY be present:
オプションの認証セクションが存在してもよい：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Authentication Data... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 認証タイプ | 認証長 | 認証データ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version (Vers)
バージョン（Vers）
The version number of the protocol. This document defines
protocol version 1.
プロトコルのバージョン番号。 このドキュメントでは、プロトコルバージョン1を定義しています。
Katz & Ward Standards Track [Page 7] RFC 5880 Bidirectional Forwarding Detection June 2010 Diagnostic (Diag)
診断（診断）
A diagnostic code specifying the local system's reason for the
last change in session state. Values are:
セッション状態の最後の変更に対するローカルシステムの理由を指定する診断コード。 値は次のとおりです。
0 -- No Diagnostic
1 -- Control Detection Time Expired
2 -- Echo Function Failed
3 -- Neighbor Signaled Session Down
4 -- Forwarding Plane Reset
5 -- Path Down
6 -- Concatenated Path Down
7 -- Administratively Down
8 -- Reverse Concatenated Path Down
9-31 -- Reserved for future use
0 -- 診断なし
1 -- 期限切れのコントロール検出時間
2 -- エコー機能が失敗しました
3 -- ネイバーシグナリングセッションダウン
4 -- 転送プレーンのリセット
5 -- パスダウン
6 -- 連結パスダウン
7 -- 管理上ダウン
8 -- 逆連結パスダウン
9-31 -- 将来の使用のために予約済み
This field allows remote systems to determine the reason that the
previous session failed, for example.
このフィールドにより、リモートシステムは、たとえば、前のセッションが失敗した理由を判別できます。
State (Sta)
状態（STA）
The current BFD session state as seen by the transmitting system.
Values are:
送信システムから見た現在のBFDセッション状態。 値は次のとおりです。
0 -- AdminDown
1 -- Down
2 -- Init
3 -- Up
0 -- AdminDown
1 -- ダウン
2 -- 初期化
3 -- アップ
Poll (P)
ポーリング（P）
If set, the transmitting system is requesting verification of
connectivity, or of a parameter change, and is expecting a packet
with the Final (F) bit in reply. If clear, the transmitting
system is not requesting verification.
設定されている場合、送信側システムは接続性の検証またはパラメーターの変更を要求しており、最終（F）ビットが含まれたパケットが返されることを期待しています。 クリアの場合、送信側システムは検証を要求していません。
Final (F)
最終（F）
If set, the transmitting system is responding to a received BFD
Control packet that had the Poll (P) bit set. If clear, the
transmitting system is not responding to a Poll.
設定されている場合、送信システムは、ポーリング（P）ビットが設定されている受信BFD制御パケットに応答しています。 クリアされている場合、送信システムはポーリングに応答していません。
Katz & Ward Standards Track [Page 8] RFC 5880 Bidirectional Forwarding Detection June 2010 Control Plane Independent (C)
独立したコントロールプレーン（C）
If set, the transmitting system's BFD implementation does not
share fate with its control plane (in other words, BFD is
implemented in the forwarding plane and can continue to function
through disruptions in the control plane). If clear, the
transmitting system's BFD implementation shares fate with its
control plane.
設定されている場合、送信システムのBFD実装はそのコントロールプレーンと運命を共有しません（つまり、BFDはフォワーディングプレーンに実装され、コントロールプレーンの中断を通じて機能し続けることができます）。 明確な場合、送信システムのBFD実装は、そのコントロールプレーンと運命を共有します。
The use of this bit is application dependent and is outside the
scope of this specification. See specific application
specifications for details.
このビットの使用はアプリケーションに依存し、この仕様の範囲外です。 詳細については、特定のアプリケーション仕様を参照してください。
Authentication Present (A)
認証あり（A）
If set, the Authentication Section is present and the session is
to be authenticated (see section 6.7 for details).
設定されている場合、認証セクションが存在し、セッションが認証されます（詳細については、セクション6.7を参照してください）。
Demand (D)
需要（D）
If set, Demand mode is active in the transmitting system (the
system wishes to operate in Demand mode, knows that the session is
Up in both directions, and is directing the remote system to cease
the periodic transmission of BFD Control packets). If clear,
Demand mode is not active in the transmitting system.
設定されている場合、送信モードでデマンドモードがアクティブになります（システムはデマンドモードでの動作を希望し、セッションが両方向でアップであることを認識し、リモートシステムにBFD制御パケットの定期的な送信を中止するよう指示しています）。 オフの場合、送信システムでデマンドモードはアクティブではありません。
Multipoint (M)
マルチポイント（M）
This bit is reserved for future point-to-multipoint extensions to
BFD. It MUST be zero on both transmit and receipt.
このビットは、BFDに対する将来のポイントツーマルチポイント拡張のために予約されています。 送信と受信の両方でゼロでなければなりません。
Detect Mult
マルチを検出
Detection time multiplier. The negotiated transmit interval,
multiplied by this value, provides the Detection Time for the
receiving system in Asynchronous mode.
検出時間の乗数。 ネゴシエートされた送信間隔にこの値を掛けると、非同期モードの受信システムの検出時間になります。
Length
長さ
Length of the BFD Control packet, in bytes.
BFD制御パケットの長さ（バイト単位）。
My Discriminator
私の弁別
A unique, nonzero discriminator value generated by the
transmitting system, used to demultiplex multiple BFD sessions
between the same pair of systems.
同じペアのシステム間で複数のBFDセッションを逆多重化するために使用される、送信システムによって生成された一意のゼロ以外の識別子値。
Katz & Ward Standards Track [Page 9] RFC 5880 Bidirectional Forwarding Detection June 2010 Your Discriminator
あなたの弁別
The discriminator received from the corresponding remote system.
This field reflects back the received value of My Discriminator,
or is zero if that value is unknown.
対応するリモートシステムから受信した弁別子。 このフィールドは、受信したMy Discriminatorの値を反映するか、その値が不明な場合はゼロです。
Desired Min TX Interval
望ましい最小TX間隔
This is the minimum interval, in microseconds, that the local
system would like to use when transmitting BFD Control packets,
less any jitter applied (see section 6.8.2). The value zero is
reserved.
これは、ローカルシステムがBFD制御パケットを送信するときに使用する最小の間隔（マイクロ秒単位）であり、適用されるジッターを差し引いたものです（セクション6.8.2を参照）。 値0は予約されています。
Required Min RX Interval
必要な最小RX間隔
This is the minimum interval, in microseconds, between received
BFD Control packets that this system is capable of supporting,
less any jitter applied by the sender (see section 6.8.2). If
this value is zero, the transmitting system does not want the
remote system to send any periodic BFD Control packets.
これは、このシステムがサポートできる受信BFD制御パケット間の最小間隔（マイクロ秒単位）であり、送信者によって適用されるジッターが少なくなります（セクション6.8.2を参照）。 この値がゼロの場合、送信側システムは、リモートシステムが定期的なBFD制御パケットを送信しないようにします。
Required Min Echo RX Interval
必要な最小エコーRX間隔
This is the minimum interval, in microseconds, between received
BFD Echo packets that this system is capable of supporting, less
any jitter applied by the sender (see section 6.8.9). If this
value is zero, the transmitting system does not support the
receipt of BFD Echo packets.
これは、このシステムがサポートできる受信BFDエコーパケット間の最小間隔（マイクロ秒単位）であり、送信者によって適用されるジッターが少なくなります（セクション6.8.9を参照）。 この値がゼロの場合、送信システムはBFDエコーパケットの受信をサポートしていません。
Auth Type
認証タイプ
The authentication type in use, if the Authentication Present (A)
bit is set.
Authentication Present（A）ビットが設定されている場合、使用中の認証タイプ。
0 - Reserved
1 - Simple Password
2 - Keyed MD5
3 - Meticulous Keyed MD5
4 - Keyed SHA1
5 - Meticulous Keyed SHA1
6-255 - Reserved for future use
0 - 予約済み
1 - 単純なパスワード
2 - キー付きMD5
3 - 綿密なキー付きMD5
4 - キー付きSHA1
5 - 綿密なキー付きSHA1
6-255 - 将来の使用のために予約済み
Auth Len
認証長
The length, in bytes, of the authentication section, including the
Auth Type and Auth Len fields.
Auth TypeおよびAuth Lenフィールドを含む、認証セクションの長さ（バイト単位）。
Katz & Ward Standards Track [Page 10] RFC 5880 Bidirectional Forwarding Detection June 2010 4.2. Simple Password Authentication Section Format
4.2。 単純なパスワード認証セクションの形式
If the Authentication Present (A) bit is set in the header, and the Authentication Type field contains 1 (Simple Password), the Authentication Section has the following format:
ヘッダーにAuthentication Present（A）ビットが設定されていて、Authentication Typeフィールドに1（Simple Password）が含まれている場合、Authenticationセクションの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Password... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 認証タイプ | 認証長 | 認証キーID | パスワード... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Type
認証タイプ
The Authentication Type, which in this case is 1 (Simple
Password).
認証タイプ。この場合は1（単純なパスワード）です。
Auth Len
認証長
The length of the Authentication Section, in bytes. For Simple
Password authentication, the length is equal to the password
length plus three.
認証セクションの長さ（バイト単位）。 シンプルパスワード認証の場合、長さはパスワードの長さに3を加えたものに等しくなります。
Auth Key ID
認証キーID
The authentication key ID in use for this packet. This allows
multiple keys to be active simultaneously.
このパケットに使用されている認証キーID。 これにより、複数のキーを同時にアクティブにすることができます。
Password
パスワード
The simple password in use on this session. The password is a
binary string, and MUST be from 1 to 16 bytes in length. The
password MUST be encoded and configured according to section
6.7.2.
このセッションで使用されている単純なパスワード。 パスワードはバイナリ文字列で、長さは1〜16バイトでなければなりません。 パスワードはセクション6.7.2に従ってエンコードおよび設定する必要があります。
4.3. Keyed MD5 and Meticulous Keyed MD5 Authentication Section Format
4.3。 キー付きMD5および細かいキー付きMD5認証セクションの形式
The use of MD5-based authentication is strongly discouraged. However, it is documented here for compatibility with existing implementations.
MD5ベースの認証の使用は強くお勧めしません。 ただし、既存の実装との互換性のためにここに記載されています。
If the Authentication Present (A) bit is set in the header, and the Authentication Type field contains 2 (Keyed MD5) or 3 (Meticulous Keyed MD5), the Authentication Section has the following format:
ヘッダーにAuthentication Present（A）ビットが設定されていて、Authentication Typeフィールドに2（Keyed MD5）または3（Meticulous Keyed MD5）が含まれている場合、Authenticationセクションの形式は次のとおりです。
Katz & Ward Standards Track [Page 11]
RFC 5880 Bidirectional Forwarding Detection June 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Key/Digest... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 認証タイプ | 認証長 | 認証キーID | 予約済み |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| シーケンス番号 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 認証キー/ダイジェスト... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Type
認証タイプ
The Authentication Type, which in this case is 2 (Keyed MD5) or 3
(Meticulous Keyed MD5).
認証タイプ。この場合は2（キー付きMD5）または3（細かいキー付きMD5）です。
Auth Len
認証長
The length of the Authentication Section, in bytes. For Keyed MD5
and Meticulous Keyed MD5 authentication, the length is 24.
認証セクションの長さ（バイト単位）。 キー付きMD5およびMeticulousキー付きMD5認証の場合、長さは24です。
Auth Key ID
認証キーID
The authentication key ID in use for this packet. This allows
multiple keys to be active simultaneously.
このパケットに使用されている認証キーID。 これにより、複数のキーを同時にアクティブにすることができます。
Reserved
予約済み
This byte MUST be set to zero on transmit, and ignored on receipt.
このバイトは送信時にゼロに設定されなければならず、受信時に無視されなければなりません。
Sequence Number
シーケンス番号
The sequence number for this packet. For Keyed MD5
Authentication, this value is incremented occasionally. For
Meticulous Keyed MD5 Authentication, this value is incremented for
each successive packet transmitted for a session. This provides
protection against replay attacks.
このパケットのシーケンス番号。 キー付きMD5認証の場合、この値は時々増加します。 Meticulous Keyed MD5認証の場合、この値は、セッションで送信される連続するパケットごとに増分されます。 これにより、リプレイ攻撃に対する保護が提供されます。
Auth Key/Digest
認証キー/ダイジェスト
This field carries the 16-byte MD5 digest for the packet. When
the digest is calculated, the shared MD5 key is stored in this
field, padded to 16 bytes with trailing zero bytes if needed. The
shared key MUST be encoded and configured to section 6.7.3.
このフィールドには、パケットの16バイトのMD5ダイジェストが含まれます。 ダイジェストが計算されると、共有MD5キーがこのフィールドに格納され、必要に応じて後続の0バイトで16バイトに埋め込まれます。 共有キーはセクション6.7.3にエンコードおよび設定する必要があります。
Katz & Ward Standards Track [Page 12] RFC 5880 Bidirectional Forwarding Detection June 2010 4.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication Section Format
4.4。 キー付きSHA1および細かいキー付きSHA1認証セクションの形式
If the Authentication Present (A) bit is set in the header, and the Authentication Type field contains 4 (Keyed SHA1) or 5 (Meticulous Keyed SHA1), the Authentication Section has the following format:
ヘッダーにAuthentication Present（A）ビットが設定されていて、Authentication Typeフィールドに4（Keyed SHA1）または5（Meticulous Keyed SHA1）が含まれている場合、Authenticationセクションの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Key/Hash... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 認証タイプ | 認証長 | 認証キーID | 予約済み |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| シーケンス番号 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 認証キー/ハッシュ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Type
認証タイプ
The Authentication Type, which in this case is 4 (Keyed SHA1) or 5
(Meticulous Keyed SHA1).
認証タイプ。この場合は4（Keyed SHA1）または5（Meticulous Keyed SHA1）です。
Auth Len
認証長
The length of the Authentication Section, in bytes. For Keyed
SHA1 and Meticulous Keyed SHA1 authentication, the length is 28.
認証セクションの長さ（バイト単位）。 Keyed SHA1およびMeticulous Keyed SHA1認証の場合、長さは28です。
Auth Key ID
認証キーID
The authentication key ID in use for this packet. This allows
multiple keys to be active simultaneously.
このパケットに使用されている認証キーID。 これにより、複数のキーを同時にアクティブにすることができます。
Reserved
予約済み
This byte MUST be set to zero on transmit and ignored on receipt.
このバイトは送信時にゼロに設定されなければならず、受信時に無視されなければなりません。
Sequence Number
シーケンス番号
The sequence number for this packet. For Keyed SHA1
Authentication, this value is incremented occasionally. For
Meticulous Keyed SHA1 Authentication, this value is incremented
for each successive packet transmitted for a session. This
provides protection against replay attacks.
このパケットのシーケンス番号。 キー付きSHA1認証の場合、この値は時々増加します。 Meticulous Keyed SHA1認証の場合、この値は、セッションで送信される連続するパケットごとに増分されます。 これにより、リプレイ攻撃に対する保護が提供されます。
Katz & Ward Standards Track [Page 13] RFC 5880 Bidirectional Forwarding Detection June 2010 Auth Key/Hash
認証キー/ハッシュ
This field carries the 20-byte SHA1 hash for the packet. When the
hash is calculated, the shared SHA1 key is stored in this field,
padded to a length of 20 bytes with trailing zero bytes if needed.
The shared key MUST be encoded and configured to section 6.7.4.
このフィールドには、パケットの20バイトのSHA1ハッシュが含まれます。 ハッシュが計算されると、共有SHA1キーがこのフィールドに格納され、必要に応じて、後続の0バイトで20バイトの長さに埋め込まれます。 共有鍵はセクション6.7.4にエンコードおよび設定する必要があります。
5. BFD Echo Packet Format
5. BFDエコーパケットフォーマット
BFD Echo packets are sent in an encapsulation appropriate to the environment. See the appropriate application documents for the specifics of particular environments.
BFDエコーパケットは、環境に適したカプセル化で送信されます。 特定の環境の詳細については、該当するアプリケーションのドキュメントを参照してください。
The payload of a BFD Echo packet is a local matter, since only the sending system ever processes the content. The only requirement is that sufficient information is included to demultiplex the received packet to the correct BFD session after it is looped back to the sender. The contents are otherwise outside the scope of this specification.
送信システムのみがコンテンツを処理するため、BFDエコーパケットのペイロードはローカルな問題です。 唯一の要件は、受信したパケットが送信者にループバックされた後、正しいBFDセッションに受信パケットを逆多重化するために十分な情報が含まれていることです。 それ以外の場合、内容はこの仕様の範囲外です。
Some form of authentication SHOULD be included, since Echo packets may be spoofed.
エコーパケットはスプーフィングされる可能性があるため、何らかの認証形式を含める必要があります。
6. Elements of Procedure
6.手順の要素
This section discusses the normative requirements of the protocol in order to achieve interoperability. It is important for implementors to enforce only the requirements specified in this section, as misguided pedantry has been proven by experience to affect interoperability adversely.
このセクションでは、相互運用性を実現するためのプロトコルの標準要件について説明します。 誤解されたペダントリーは相互運用性に悪影響を与えることが経験によって証明されているため、実装者はこのセクションで指定された要件のみを実施することが重要です。
Remember that all references of the form "bfd.Xx" refer to internal state variables (defined in section 6.8.1), whereas all references to "the Xxx field" refer to fields in the protocol packets themselves (defined in section 4).
「bfd.Xx」という形式のすべての参照は内部状態変数（セクション6.8.1で定義）を参照するのに対し、「Xxxフィールド」へのすべての参照はプロトコルパケット自体（セクション4で定義）のフィールドを参照することに注意してください。
6.1. Overview
6.1。 概観
A system may take either an Active role or a Passive role in session initialization. A system taking the Active role MUST send BFD Control packets for a particular session, regardless of whether it has received any BFD packets for that session. A system taking the Passive role MUST NOT begin sending BFD packets for a particular session until it has received a BFD packet for that session, and thus has learned the remote system's discriminator value. At least one system MUST take the Active role (possibly both). The role that a system takes is specific to the application of BFD, and is outside the scope of this specification.
システムは、セッションの初期化でアクティブロールまたはパッシブロールのいずれかをとります。 アクティブな役割を担うシステムは、そのセッションのBFDパケットを受信したかどうかに関係なく、特定のセッションのBFD制御パケットを送信する必要があります。 パッシブの役割を担うシステムは、そのセッションのBFDパケットを受信し、リモートシステムの識別値を学習するまで、特定のセッションのBFDパケットの送信を開始してはなりません（MUST NOT）。 少なくとも1つのシステムがアクティブな役割（おそらく両方）を取る必要があります。 システムが果たす役割はBFDのアプリケーションに固有であり、この仕様の範囲外です。
Katz & Ward Standards Track [Page 14] RFC 5880 Bidirectional Forwarding Detection June 2010 A session begins with the periodic, slow transmission of BFD Control packets. When bidirectional communication is achieved, the BFD session becomes Up.
セッションは、BFD制御パケットの定期的で遅い伝送で始まります。 双方向通信が確立されると、BFDセッションがアップになります。
Once the BFD session is Up, a system can choose to start the Echo function if it desires and the other system signals that it will allow it. The rate of transmission of Control packets is typically kept low when the Echo function is active.
BFDセッションが起動すると、システムは、必要に応じてエコー機能を開始することを選択でき、他のシステムはそれを許可することを通知します。 エコー機能がアクティブな場合、制御パケットの伝送速度は通常低く抑えられます。
If the Echo function is not active, the transmission rate of Control packets may be increased to a level necessary to achieve the Detection Time requirements for the session.
エコー機能がアクティブでない場合、制御パケットの伝送速度は、セッションの検出時間要件を達成するために必要なレベルまで増加する可能性があります。
Once the session is Up, a system may signal that it has entered Demand mode, and the transmission of BFD Control packets by the remote system ceases. Other means of implying connectivity are used to keep the session alive. If either system wishes to verify bidirectional connectivity, it can initiate a short exchange of BFD Control packets (a "Poll Sequence"; see section 6.5) to do so.
セッションが起動すると、システムはデマンドモードに入ったことを通知し、リモートシステムによるBFD制御パケットの送信を停止します。 接続を暗示する他の方法は、セッションを存続させるために使用されます。 いずれかのシステムが双方向接続を確認したい場合は、BFD制御パケットの短い交換（「ポーリングシーケンス」;セクション6.5を参照）を開始して確認できます。
If Demand mode is not active, and no Control packets are received in the calculated Detection Time (see section 6.8.4), the session is declared Down. This is signaled to the remote end via the State (Sta) field in outgoing packets.
デマンドモードがアクティブでなく、計算された検出時間（セクション6.8.4を参照）で制御パケットが受信されない場合、セッションはダウンと宣言されます。 これは、発信パケットのState（Sta）フィールドを介してリモートエンドに通知されます。
If sufficient Echo packets are lost, the session is declared Down in the same manner. See section 6.8.5.
十分なエコーパケットが失われた場合、セッションは同じ方法でダウンと宣言されます。 セクション6.8.5を参照してください。
If Demand mode is active and no appropriate Control packets are received in response to a Poll Sequence, the session is declared Down in the same manner. See section 6.6.
デマンドモードがアクティブで、ポーリングシーケンスに応答して適切な制御パケットが受信されない場合、セッションは同じ方法でダウンと宣言されます。 セクション6.6を参照してください。
If the session goes Down, the transmission of Echo packets (if any) ceases, and the transmission of Control packets goes back to the slow rate.
セッションがダウンすると、エコーパケット（存在する場合）の送信が停止し、制御パケットの送信が低速に戻ります。
Once a session has been declared Down, it cannot come back up until the remote end first signals that it is down (by leaving the Up state), thus implementing a three-way handshake.
セッションがダウンと宣言されると、リモートエンドが最初に（アップ状態を離れることによって）ダウンしていることを通知するまで、セッションをアップに戻すことはできません。これにより、3ウェイハンドシェイクが実装されます。
A session MAY be kept administratively down by entering the AdminDown state and sending an explanatory diagnostic code in the Diagnostic field.
AdminDown状態に入り、Diagnosticフィールドに説明的な診断コードを送信することにより、セッションを管理上停止したままにすることができます。
Katz & Ward Standards Track [Page 15] RFC 5880 Bidirectional Forwarding Detection June 2010 6.2. BFD State Machine
6.2。 BFDステートマシン
The BFD state machine is quite straightforward. There are three states through which a session normally proceeds: two for establishing a session (Init and Up) and one for tearing down a session (Down). This allows a three-way handshake for both session establishment and session teardown (assuring that both systems are aware of all session state changes). A fourth state (AdminDown) exists so that a session can be administratively put down indefinitely.
BFDステートマシンは非常に単純です。 セッションが通常進む3つの状態があります。2つはセッションの確立（InitおよびUp）で、もう1つはセッションの切断（Down）です。 これにより、セッション確立とセッションティアダウンの両方に3ウェイハンドシェイクが可能になります（両方のシステムがすべてのセッション状態の変化を認識していることを保証します）。 4番目の状態（AdminDown）が存在するため、セッションを管理上無期限に停止できます。
Each system communicates its session state in the State (Sta) field in the BFD Control packet, and that received state, in combination with the local session state, drives the state machine.
各システムは、BFD制御パケットの状態（Sta）フィールドでそのセッション状態を伝達し、その受信状態は、ローカルセッション状態と組み合わせて、状態マシンを駆動します。
Down state means that the session is down (or has just been created). A session remains in Down state until the remote system indicates that it agrees that the session is down by sending a BFD Control packet with the State field set to anything other than Up. If that packet signals Down state, the session advances to Init state; if that packet signals Init state, the session advances to Up state. Semantically, Down state indicates that the forwarding path is unavailable, and that appropriate actions should be taken by the applications monitoring the state of the BFD session. A system MAY hold a session in Down state indefinitely (by simply refusing to advance the session state). This may be done for operational or administrative reasons, among others.
ダウン状態は、セッションがダウンしている（または作成された直後）ことを意味します。 リモートシステムが、状態フィールドがアップ以外に設定されたBFD制御パケットを送信してセッションがダウンしていることに同意するまで、セッションはダウン状態のままです。 そのパケットがダウン状態を示す場合、セッションは初期状態に進みます。 そのパケットがInit状態を示す場合、セッションはUp状態に進みます。 意味的には、ダウン状態は、転送パスが利用できないこと、およびBFDセッションの状態を監視するアプリケーションが適切なアクションを実行する必要があることを示します。 システムは、セッションを無期限に（単にセッション状態の進行を拒否することにより）ダウン状態に保持できます（MAY）。 これは、特に運用上または管理上の理由で行われる場合があります。
Init state means that the remote system is communicating, and the local system desires to bring the session up, but the remote system does not yet realize it. A session will remain in Init state until either a BFD Control Packet is received that is signaling Init or Up state (in which case the session advances to Up state) or the Detection Time expires, meaning that communication with the remote system has been lost (in which case the session advances to Down state).
Init状態は、リモートシステムが通信していて、ローカルシステムがセッションを起動することを望んでいるが、リモートシステムがまだそれを認識していないことを意味します。 セッションは、InitまたはUp状態（セッションがUp状態に進む場合）を通知しているBFD制御パケットが受信されるか、検出時間が経過するまで、Init状態のままです。つまり、リモートシステムとの通信が失われます（ その場合、セッションはダウン状態に進みます）。
Up state means that the BFD session has successfully been established, and implies that connectivity between the systems is working. The session will remain in the Up state until either connectivity fails or the session is taken down administratively. If either the remote system signals Down state or the Detection Time expires, the session advances to Down state.
アップ状態は、BFDセッションが正常に確立されたことを意味し、システム間の接続が機能していることを意味します。 接続が失敗するか、セッションが管理上停止されるまで、セッションはUp状態のままです。 リモートシステムがダウン状態を通知するか、検出時間が期限切れになると、セッションはダウン状態に進みます。
Katz & Ward Standards Track [Page 16] RFC 5880 Bidirectional Forwarding Detection June 2010 AdminDown state means that the session is being held administratively down. This causes the remote system to enter Down state, and remain there until the local system exits AdminDown state. AdminDown state has no semantic implications for the availability of the forwarding path.
AdminDown状態は、セッションが管理上停止されていることを意味します。 これにより、リモートシステムはダウン状態になり、ローカルシステムがAdminDown状態を終了するまでそのままになります。 AdminDown状態は、転送パスの可用性に意味上の影響を与えません。
The following diagram provides an overview of the state machine. Transitions involving AdminDown state are deleted for clarity (but are fully specified in sections 6.8.6 and 6.8.16). The notation on each arc represents the state of the remote system (as received in the State field in the BFD Control packet) or indicates the expiration of the Detection Timer.
次の図は、ステートマシンの概要を示しています。 AdminDown状態を含む遷移は、明確にするために削除されています（ただし、セクション6.8.6および6.8.16で完全に指定されています）。 各アークの表記は、リモートシステムの状態（BFD制御パケットの状態フィールドで受信される）を表すか、検出タイマーの期限切れを示します。
+--+
| | UP, ADMIN DOWN, TIMER
| V
DOWN +------+ INIT
+------------| |------------+
| | DOWN | |
| +-------->| |<--------+ |
| | +------+ | |
| | | |
| | ADMIN DOWN,| |
| |ADMIN DOWN, DOWN,| |
| |TIMER TIMER| |
V | | V
+------+ +------+
+----| | | |----+
DOWN| | INIT |--------------------->| UP | |INIT, UP
+--->| | INIT, UP | |<---+
+------+ +------+
6.3. Demultiplexing and the Discriminator Fields
6.3。 逆多重化と弁別子フィールド
Since multiple BFD sessions may be running between two systems, there needs to be a mechanism for demultiplexing received BFD packets to the proper session.
2つのシステム間で複数のBFDセッションが実行されている可能性があるため、受信したBFDパケットを適切なセッションに逆多重化するメカニズムが必要です。
Each system MUST choose an opaque discriminator value that identifies each session, and which MUST be unique among all BFD sessions on the system. The local discriminator is sent in the My Discriminator field in the BFD Control packet, and is echoed back in the Your Discriminator field of packets sent from the remote end.
各システムは、各セッションを識別する不透明な識別子値を選択する必要があり、システム上のすべてのBFDセッション間で一意である必要があります。 ローカルの弁別子は、BFD制御パケットのMy Discriminatorフィールドで送信され、リモートエンドから送信されたパケットのYour Discriminatorフィールドにエコーバックされます。
Katz & Ward Standards Track [Page 17] RFC 5880 Bidirectional Forwarding Detection June 2010 Once the remote end echoes back the local discriminator, all further received packets are demultiplexed based on the Your Discriminator field only (which means that, among other things, the source address field can change or the interface over which the packets are received can change, but the packets will still be associated with the proper session).
リモートエンドがローカルの弁別子をエコーバックすると、それ以降に受信されるすべてのパケットはYour Discriminatorフィールドのみに基づいて逆多重化されます（つまり、特に、送信元アドレスフィールドが変更されるか、パケットが受信されるインターフェイスが変更される可能性があります）。 ただし、パケットは引き続き適切なセッションに関連付けられます）。
The method of demultiplexing the initial packets (in which Your Discriminator is zero) is application dependent, and is thus outside the scope of this specification.
最初のパケット（Discriminatorがゼロ）を逆多重化する方法はアプリケーションに依存するため、この仕様の範囲外です。
Note that it is permissible for a system to change its discriminator during a session without affecting the session state, since only that system uses its discriminator for demultiplexing purposes (by having the other system reflect it back). The implications on an implementation for changing the discriminator value is outside the scope of this specification.
システムがディスクリミネーターを逆多重化の目的で使用するため（他のシステムにそれを反映させることにより）、システムがセッション中にセッションの状態に影響を与えずにそのディスクリミネーターを変更することが許容されることに注意してください。 識別子の値を変更するための実装への影響は、この仕様の範囲外です。
6.4. The Echo Function and Asymmetry
6.4。 エコー関数と非対称性
The Echo function can be run independently in each direction between a pair of systems. For whatever reason, a system may advertise that it is willing to receive (and loop back) Echo packets, but may not wish to ever send any. The fact that a system is sending Echo packets is not directly signaled to the system looping them back.
エコー機能は、システムのペア間の各方向で独立して実行できます。 何らかの理由で、システムはエコーパケットを受信（およびループバック）する意思があることを通知しますが、送信を望まない場合があります。 システムがエコーパケットを送信しているという事実は、それらをループバックするシステムに直接通知されません。
When a system is using the Echo function, it is advantageous to choose a sedate reception rate for Control packets, since liveness detection is being handled by the Echo packets. This can be controlled by manipulating the Required Min RX Interval field (see section 6.8.3).
システムがエコー機能を使用している場合、活性検出はエコーパケットによって処理されるため、制御パケットの落ち着いた受信レートを選択すると効果的です。 これは、必要な最小RX間隔フィールドを操作することで制御できます（セクション6.8.3を参照）。
If the Echo function is only being run in one direction, the system not running the Echo function will more likely wish to receive fairly rapid Control packets in order to achieve its desired Detection Time. Since BFD allows independent transmission rates in each direction, this is easily accomplished.
エコー機能が一方向でのみ実行されている場合、エコー機能を実行していないシステムは、希望する検出時間を実現するために、かなり高速の制御パケットを受信する可能性が高くなります。 BFDは各方向で独立した伝送速度を許可するため、これは簡単に実行できます。
A system SHOULD otherwise advertise the lowest value of Required Min RX Interval and Required Min Echo RX Interval that it can under the circumstances, to give the other system more freedom in choosing its transmission rate. Note that a system is committing to be able to receive both streams of packets at the rate it advertises, so this should be taken into account when choosing the values to advertise.
それ以外の場合、システムは必要な最小RX間隔と必要な最小エコーRX間隔の最低値をアドバタイズして、他のシステムがより高い伝送速度を選択できるようにする必要があります。 システムは、アドバタイズするレートでパケットの両方のストリームを受信できるようにコミットしていることに注意してください。そのため、アドバタイズする値を選択するときに、これを考慮する必要があります。
Katz & Ward Standards Track [Page 18] RFC 5880 Bidirectional Forwarding Detection June 2010 6.5. The Poll Sequence
6.5。 ポーリングシーケンス
A Poll Sequence is an exchange of BFD Control packets that is used in some circumstances to ensure that the remote system is aware of parameter changes. It is also used in Demand mode (see section 6.6) to validate bidirectional connectivity.
ポーリングシーケンスはBFD制御パケットの交換であり、状況によっては、リモートシステムがパラメータの変更を認識していることを確認するために使用されます。 また、双方向接続を検証するために、デマンドモード（セクション6.6を参照）でも使用されます。
A Poll Sequence consists of a system sending periodic BFD Control packets with the Poll (P) bit set. When the other system receives a Poll, it immediately transmits a BFD Control packet with the Final (F) bit set, independent of any periodic BFD Control packets it may be sending (see section 6.8.7). When the system sending the Poll sequence receives a packet with Final, the Poll Sequence is terminated, and any subsequent BFD Control packets are sent with the Poll bit cleared. A BFD Control packet MUST NOT have both the Poll (P) and Final (F) bits set.
ポーリングシーケンスは、ポーリング（P）ビットが設定されたBFD制御パケットを定期的に送信するシステムで構成されます。 他のシステムがポーリングを受信すると、送信している定期的なBFD制御パケットとは無関係に、最終（F）ビットが設定されたBFD制御パケットを直ちに送信します（セクション6.8.7を参照）。 Pollシーケンスを送信するシステムがFinalでパケットを受信すると、Pollシーケンスは終了し、後続のBFD制御パケットはPollビットがクリアされた状態で送信されます。 BFD制御パケットには、ポーリング（P）ビットと最終（F）ビットの両方を設定してはなりません（MUST NOT）。
If periodic BFD Control packets are already being sent (the remote system is not in Demand mode), the Poll Sequence MUST be performed by setting the Poll (P) bit on those scheduled periodic transmissions; additional packets MUST NOT be sent.
定期的なBFD制御パケットが既に送信されている場合（リモートシステムがデマンドモードではない場合）、スケジュールされた定期的な送信でポーリング（P）ビットを設定して、ポーリングシーケンスを実行する必要があります。 追加のパケットを送信してはならない（MUST NOT）。
After a Poll Sequence is terminated, the system requesting the Poll Sequence will cease the periodic transmission of BFD Control packets if the remote end is in Demand mode; otherwise, it will return to the periodic transmission of BFD Control packets with the Poll (P) bit clear.
ポーリングシーケンスが終了すると、リモートエンドがデマンドモードの場合、ポーリングシーケンスを要求するシステムはBFD制御パケットの定期的な送信を停止します。 それ以外の場合は、ポーリング（P）ビットがクリアされたBFD制御パケットの定期的な送信に戻ります。
Typically, the entire sequence consists of a single packet in each direction, though packet losses or relatively long packet latencies may result in multiple Poll packets to be sent before the sequence terminates.
通常、シーケンス全体は各方向の単一パケットで構成されますが、パケット損失または比較的長いパケット遅延により、シーケンスが終了する前に複数のポーリングパケットが送信される場合があります。
6.6. Demand Mode
6.6。 デマンドモード
Demand mode is requested independently in each direction by virtue of a system setting the Demand (D) bit in its BFD Control packets. The system receiving the Demand bit ceases the periodic transmission of BFD Control packets. If both systems are operating in Demand mode, no periodic BFD Control packets will flow in either direction.
デマンドモードは、BFD制御パケットのデマンド（D）ビットをシステムが設定することにより、各方向で独立して要求されます。 デマンドビットを受信したシステムは、BFD制御パケットの定期的な送信を停止します。 両方のシステムがデマンドモードで動作している場合、定期的なBFD制御パケットはどちらの方向にも流れません。
Demand mode requires that some other mechanism is used to imply continuing connectivity between the two systems. The mechanism used does not have to be the same in both directions, and is outside of the scope of this specification. One possible mechanism is the receipt of traffic from the remote system; another is the use of the Echo function.
デマンドモードでは、2つのシステム間の継続的な接続を意味する他のメカニズムを使用する必要があります。 使用されるメカニズムは両方向で同じである必要はなく、この仕様の範囲外です。 考えられるメカニズムの1つは、リモートシステムからのトラフィックの受信です。 もう1つは、エコー関数の使用です。
Katz & Ward Standards Track [Page 19] RFC 5880 Bidirectional Forwarding Detection June 2010 When a system in Demand mode wishes to verify bidirectional connectivity, it initiates a Poll Sequence (see section 6.5). If no response is received to a Poll, the Poll is repeated until the Detection Time expires, at which point the session is declared to be Down. Note that if Demand mode is operating only on the local system, the Poll Sequence is performed by simply setting the Poll (P) bit in regular periodic BFD Control packets, as required by section 6.5.
デマンドモードのシステムが双方向接続を確認する場合、システムはポーリングシーケンスを開始します（セクション6.5を参照）。 ポーリングに対する応答が受信されない場合は、検出時間が経過するまでポーリングが繰り返されます。この時間が経過すると、セッションはダウンしていると宣言されます。 デマンドモードがローカルシステムでのみ動作している場合、セクション6.5で要求されているように、定期的なBFD制御パケットのポーリング（P）ビットを設定するだけでポーリングシーケンスが実行されることに注意してください。
The Detection Time in Demand mode is calculated differently than in Asynchronous mode; it is based on the transmit rate of the local system, rather than the transmit rate of the remote system. This ensures that the Poll Sequence mechanism works properly. See section 6.8.4 for more details.
デマンドモードでの検出時間の計算方法は、非同期モードとは異なります。 これは、リモートシステムの送信速度ではなく、ローカルシステムの送信速度に基づいています。 これにより、ポーリングシーケンスメカニズムが適切に機能します。 詳細については、セクション6.8.4を参照してください。
Note that the Poll mechanism will always fail unless the negotiated Detection Time is greater than the round-trip time between the two systems. Enforcement of this constraint is outside the scope of this specification.
ネゴシエートされた検出時間が2つのシステム間の往復時間を超えない限り、ポーリングメカニズムは常に失敗することに注意してください。 この制約の実施は、この仕様の範囲外です。
Demand mode MAY be enabled or disabled at any time, independently in each direction, by setting or clearing the Demand (D) bit in the BFD Control packet, without affecting the BFD session state. Note that the Demand bit MUST NOT be set unless both systems perceive the session to be Up (the local system thinks the session is Up, and the remote system last reported Up state in the State (Sta) field of the BFD Control packet).
デマンドモードは、BFDセッションステートに影響を与えることなく、BFD制御パケットのデマンド（D）ビットを設定またはクリアすることにより、いつでも、各方向で独立して有効または無効にできます。 両方のシステムがセッションがアップであると認識しない限り、デマンドビットを設定してはならないことに注意してください（ローカルシステムはセッションがアップであると見なし、リモートシステムはBFD制御パケットの状態（Sta）フィールドでアップ状態を最後に報告しました）。
When the transmitted value of the Demand (D) bit is to be changed, the transmitting system MUST initiate a Poll Sequence in conjunction with changing the bit in order to ensure that both systems are aware of the change.
デマンド（D）ビットの送信値を変更する場合、送信システムは、両方のシステムが変更を認識していることを確認するために、ビットの変更と共にポーリングシーケンスを開始する必要があります。
If Demand mode is active on either or both systems, a Poll Sequence MUST be initiated whenever the contents of the next BFD Control packet to be sent would be different than the contents of the previous packet, with the exception of the Poll (P) and Final (F) bits. This ensures that parameter changes are transmitted to the remote system and that the remote system acknowledges these changes.
いずれかのシステムまたは両方のシステムでデマンドモードがアクティブな場合、送信される次のBFD制御パケットの内容が前のパケットの内容と異なる場合は常に、ポーリングシーケンスを開始する必要があります。ただし、ポーリング（P）および 最終（F）ビット。 これにより、パラメーターの変更がリモートシステムに送信され、リモートシステムがこれらの変更を確認することが保証されます。
Because the underlying detection mechanism is unspecified, and may differ between the two systems, the overall Detection Time characteristics of the path will not be fully known to either system. The total Detection Time for a particular system is the sum of the time prior to the initiation of the Poll Sequence, plus the calculated Detection Time.
根本的な検出メカニズムは指定されておらず、2つのシステム間で異なる可能性があるため、パスの全体的な検出時間特性はどちらのシステムでも完全には認識されません。 特定のシステムの総検出時間は、ポーリングシーケンスの開始前の時間と、計算された検出時間の合計です。
Katz & Ward Standards Track [Page 20] RFC 5880 Bidirectional Forwarding Detection June 2010 Note that if Demand mode is enabled in only one direction, continuous bidirectional connectivity verification is lost (only connectivity in the direction from the system in Demand mode to the other system will be verified). Resolving the issue of one system requesting Demand mode while the other requires continuous bidirectional connectivity verification is outside the scope of this specification.
デマンドモードが一方向でのみ有効になっている場合、継続的な双方向接続の検証は失われます（デマンドモードのシステムから他のシステムへの方向の接続のみが検証されます）。 1つのシステムがデマンドモードを要求する一方で、他のシステムが継続的な双方向接続の検証を必要とするという問題の解決は、この仕様の範囲外です。
6.7. Authentication
6.7。 認証
An optional Authentication Section MAY be present in the BFD Control packet. In its generic form, the purpose of the Authentication Section is to carry all necessary information, based on the authentication type in use, to allow the receiving system to determine the validity of the received packet. The exact mechanism depends on the authentication type in use, but in general the transmitting system will put information in the Authentication
オプションの認証セクションがBFD制御パケットに存在してもよい（MAY）。 一般的な形式では、認証セクションの目的は、使用中の認証タイプに基づいて必要なすべての情報を伝達し、受信システムが受信パケットの有効性を判断できるようにすることです。 正確なメカニズムは、使用している認証タイプによって異なりますが、一般に、送信システムは認証に情報を入れます。
Section that vouches for the packet's validity, and the receiving system will examine the Authentication Section and either accept the packet for further processing or discard it.
パケットの有効性を保証するセクション。受信システムは認証セクションを検査し、さらに処理するためにパケットを受け入れるか、または破棄します。
The same authentication type, and any keys or other necessary information, obviously must be in use by the two systems. The negotiation of authentication type, key exchange, etc., are all outside the scope of this specification and are expected to be performed by means outside of the protocol.
同じ認証タイプ、およびキーまたはその他の必要な情報は、明らかに2つのシステムで使用されている必要があります。 認証タイプのネゴシエーション、鍵交換などはすべてこの仕様の範囲外であり、プロトコルの外部の手段によって実行されることが期待されています。
Note that in the subsections below, to "accept" a packet means only that the packet has passed authentication; it may in fact be discarded for other reasons as described in the general packet reception rules described in section 6.8.6.
以下のサブセクションで、パケットを「受け入れる」とは、パケットが認証を通過したことだけを意味することに注意してください。 セクション6.8.6で説明されている一般的なパケット受信規則で説明されているように、実際には他の理由で破棄される場合があります。
Implementations supporting authentication MUST support both types of SHA1 authentication. Other forms of authentication are optional.
認証をサポートする実装は、両方のタイプのSHA1認証をサポートする必要があります。 他の認証形式はオプションです。
6.7.1. Enabling and Disabling Authentication
6.7.1。 認証の有効化と無効化
It may be desirable to enable or disable authentication on a session without disturbing the session state. The exact mechanism for doing so is outside the scope of this specification. However, it is useful to point out some issues in supporting this mechanism.
セッションの状態を乱すことなく、セッションの認証を有効または無効にすることが望ましい場合があります。 そのための正確なメカニズムは、この仕様の範囲外です。 ただし、このメカニズムのサポートに関するいくつかの問題を指摘しておくと役立ちます。
In a simple implementation, a BFD session will fail when authentication is either turned on or turned off, because the packet acceptance rules essentially require the local and remote machines to Katz & Ward Standards Track [Page 21] RFC 5880 Bidirectional Forwarding Detection June 2010 do so in a more or less synchronized fashion (within the Detection Time) -- a packet with authentication will only be accepted if authentication is "in use" (and likewise packets without authentication).
単純な実装では、認証がオンまたはオフのいずれかである場合、BFDセッションは失敗します。これは、パケット受け入れルールが基本的にローカルマシンとリモートマシンに多かれ少なかれ同期された方法で（検出時間内に）行う必要があるためです。 認証付きのパケットは、認証が「使用中」の場合にのみ受け入れられます（同様に、認証なしのパケット）。
One possible approach is to build an implementation such that authentication is configured, but not considered "in use" until the first packet containing a matching authentication section is received (providing the necessary synchronization). Likewise, authentication could be configured off, but still considered "in use" until the receipt of the first packet without the authentication section.
可能なアプローチの1つは、認証が構成されているが、一致する認証セクションを含む最初のパケットが受信されるまで（必要な同期が提供されるまで）「使用中」とは見なされない実装を構築することです。 同様に、認証をオフに構成することもできますが、認証セクションのない最初のパケットを受信するまで、「使用中」と見なされます。
In order to avoid security risks, implementations using this method SHOULD only allow the authentication state to be changed at most once without some form of intervention (so that authentication cannot be turned on and off repeatedly simply based on the receipt of BFD Control packets from remote systems). Unless it is desired to enable or disable authentication, an implementation SHOULD NOT allow the authentication state to change based on the receipt of BFD Control packets.
セキュリティリスクを回避するために、このメソッドを使用する実装では、なんらかの形での介入なしに認証状態を最大で1回だけ変更できるようにする必要があります（リモートからのBFD制御パケットの受信に基づいて認証を繰り返しオンおよびオフにできないようにするため） システム）。 認証を有効または無効にする必要がない限り、実装は、BFD制御パケットの受信に基づいて認証状態を変更することを許可してはなりません（SHOULD NOT）。
6.7.2. Simple Password Authentication
6.7.2。 単純なパスワード認証
The most straightforward (and weakest) form of authentication is Simple Password Authentication. In this method of authentication, one or more Passwords (with corresponding Key IDs) are configured in each system and one of these Password/ID pairs is carried in each BFD Control packet. The receiving system accepts the packet if the Password and Key ID matches one of the Password/ID pairs configured in that system.
最も簡単な（そして最も弱い）認証形式は、単純なパスワード認証です。 この認証方法では、1つ以上のパスワード（対応するキーIDを含む）が各システムで構成され、これらのパスワード/ IDペアの1つが各BFD制御パケットで運ばれます。 受信システムは、パスワードとキーIDがそのシステムで構成されているパスワード/ IDペアの1つと一致する場合、パケットを受け入れます。
Transmission Using Simple Password Authentication
単純なパスワード認証を使用した送信
The currently selected password and Key ID for the session MUST be
stored in the Authentication Section of each outgoing BFD Control
packet. The Auth Type field MUST be set to 1 (Simple Password).
The Auth Len field MUST be set to the proper length (4 to 19
bytes).
セッションで現在選択されているパスワードとキーIDは、各発信BFD制御パケットの認証セクションに保存する必要があります。 Auth Typeフィールドは1（シンプルパスワード）に設定する必要があります。 Auth Lenフィールドは適切な長さに設定する必要があります（4〜19バイト）。
The password is a binary string, and MUST be 1 to 16 bytes in
length. For interoperability, the management interface by which
the password is configured MUST accept ASCII strings, and SHOULD
also allow for the configuration of any arbitrary binary string in
hexadecimal form. Other configuration methods MAY be supported.
パスワードはバイナリ文字列で、長さは1〜16バイトにする必要があります。 相互運用性のために、パスワードを構成する管理インターフェースはASCII文字列を受け入れる必要があり、SHOULDはまた、16進形式の任意のバイナリ文字列の構成を許可する必要があります。 他の構成方法がサポートされる場合があります。
Katz & Ward Standards Track [Page 22] RFC 5880 Bidirectional Forwarding Detection June 2010 Reception Using Simple Password Authentication
簡易パスワード認証による受付
If the received BFD Control packet does not contain an
Authentication Section, or the Auth Type is not 1 (Simple
Password), then the received packet MUST be discarded.
受信したBFD制御パケットに認証セクションが含まれていない場合、または認証タイプが1（単純なパスワード）でない場合は、受信したパケットを破棄する必要があります。
If the Auth Key ID field does not match the ID of a configured
password, the received packet MUST be discarded.
Auth Key IDフィールドが設定されたパスワードのIDと一致しない場合、受信されたパケットは破棄されなければなりません（MUST）。
If the Auth Len field is not equal to the length of the password
selected by the key ID, plus three, the packet MUST be discarded.
Auth LenフィールドがキーIDで選択されたパスワードの長さに3を加えたものと等しくない場合、パケットは破棄されなければなりません（MUST）。
If the Password field does not match the password selected by the
key ID, the packet MUST be discarded.
PasswordフィールドがキーIDで選択されたパスワードと一致しない場合、パケットは破棄されなければなりません（MUST）。
Otherwise, the packet MUST be accepted.
それ以外の場合は、パケットを受け入れる必要があります。
6.7.3. Keyed MD5 and Meticulous Keyed MD5 Authentication
6.7.3。 キー付きMD5および細かいキー付きMD5認証
The Keyed MD5 and Meticulous Keyed MD5 Authentication mechanisms are very similar to those used in other protocols. In these methods of authentication, one or more secret keys (with corresponding key IDs) are configured in each system. One of the keys is included in an MD5 [MD5] digest calculated over the outgoing BFD Control packet, but the Key itself is not carried in the packet. To help avoid replay attacks, a sequence number is also carried in each packet. For Keyed MD5, the sequence number is occasionally incremented. For Meticulous Keyed MD5, the sequence number is incremented on every packet.
キー付きMD5およびMeticulousキー付きMD5認証メカニズムは、他のプロトコルで使用されるものと非常によく似ています。 これらの認証方法では、各システムで1つ以上の秘密鍵（対応する鍵IDを含む）が構成されます。 キーの1つは、発信BFD制御パケットで計算されたMD5 [MD5]ダイジェストに含まれていますが、キー自体はパケットに含まれていません。 リプレイ攻撃を回避するために、各パケットにはシーケンス番号も含まれています。 キー付きMD5の場合、シーケンス番号は時々増加します。 Meticulous Keyed MD5の場合、シーケンス番号はパケットごとに増分されます。
The receiving system accepts the packet if the key ID matches one of the configured Keys, an MD5 digest including the selected key matches that carried in the packet, and the sequence number is greater than or equal to the last sequence number received (for Keyed MD5), or strictly greater than the last sequence number received (for Meticulous Keyed MD5).
受信システムは、キーIDが構成済みのキーの1つと一致し、選択したキーを含むMD5ダイジェストがパケットで運ばれたものと一致し、シーケンス番号が最後に受信したシーケンス番号以上である場合にパケットを受け入れます（キー付きMD5の場合） ）、または最後に受信したシーケンス番号よりも完全に大きい（Meticulous Keyed MD5の場合）。
Transmission Using Keyed MD5 and Meticulous Keyed MD5 Authentication
キー付きMD5および細心の注意を払ったキー付きMD5認証を使用した送信
The Auth Type field MUST be set to 2 (Keyed MD5) or 3 (Meticulous
Keyed MD5). The Auth Len field MUST be set to 24. The Auth Key
ID field MUST be set to the ID of the current authentication key.
The Sequence Number field MUST be set to bfd.XmitAuthSeq.
Auth Typeフィールドは2（Keyed MD5）または3（Meticulous Keyed MD5）に設定する必要があります。 Auth Lenフィールドは24に設定する必要があります。 Auth Key IDフィールドは、現在の認証キーのIDに設定する必要があります。 シーケンス番号フィールドはbfd.XmitAuthSeqに設定する必要があります。
The authentication key value is a binary string of up to 16 bytes,
and MUST be placed into the Auth Key/Digest field, padded with
trailing zero bytes as necessary. For interoperability, the
management interface by which the key is configured MUST accept
Katz & Ward Standards Track [Page 23]
RFC 5880 Bidirectional Forwarding Detection June 2010
ASCII strings, and SHOULD also allow for the configuration of any
arbitrary binary string in hexadecimal form. Other configuration
methods MAY be supported.
認証キーの値は最大16バイトのバイナリ文字列であり、必要に応じて末尾の0バイトを埋め込んだ認証キー/ダイジェストフィールドに配置する必要があります。 相互運用性のために、キーを構成する管理インターフェースはASCII文字列を受け入れる必要があり、SHOULDはまた、16進形式の任意のバイナリ文字列の構成を許可する必要があります。 他の構成方法がサポートされる場合があります。
An MD5 digest MUST be calculated over the entire BFD Control
packet. The resulting digest MUST be stored in the Auth
Key/Digest field prior to transmission (replacing the secret key,
which MUST NOT be carried in the packet).
MD5ダイジェストは、BFD制御パケット全体で計算する必要があります。 結果のダイジェストは、送信前にAuth Key / Digestフィールドに格納する必要があります（パケットで運ぶことのできない秘密鍵を置き換える必要があります）。
For Keyed MD5, bfd.XmitAuthSeq MAY be incremented in a circular
fashion (when treated as an unsigned 32-bit value).
bfd.XmitAuthSeq SHOULD be incremented when the session state
changes, or when the transmitted BFD Control packet carries
different contents than the previously transmitted packet. The
decision as to when to increment bfd.XmitAuthSeq is outside the
scope of this specification. See the section titled "Security
Considerations" below for a discussion.
キー付きMD5の場合、bfd.XmitAuthSeqは循環方式でインクリメントされる場合があります（符号なし32ビット値として扱われる場合）。 bfd.XmitAuthSeqは、セッション状態が変化したとき、または送信されたBFD制御パケットが以前に送信されたパケットとは異なる内容を運ぶときにインクリメントされる必要があります（SHOULD）。 bfd.XmitAuthSeqをいつインクリメントするかに関する決定は、この仕様の範囲外です。 説明については、以下の「セキュリティに関する考慮事項」というタイトルのセクションを参照してください。
For Meticulous Keyed MD5, bfd.XmitAuthSeq MUST be incremented in a
circular fashion (when treated as an unsigned 32-bit value).
Meticulous Keyed MD5の場合、bfd.XmitAuthSeqは循環方式でインクリメントされる必要があります（符号なし32ビット値として扱われる場合）。
Receipt Using Keyed MD5 and Meticulous Keyed MD5 Authentication
キー付きMD5および細心の注意を払ったキー付きMD5認証を使用した領収書
If the received BFD Control packet does not contain an
Authentication Section, or the Auth Type is not correct (2 for
Keyed MD5 or 3 for Meticulous Keyed MD5), then the received packet
MUST be discarded.
受信したBFD制御パケットに認証セクションが含まれていない場合、または認証タイプが正しくない場合（キー付きMD5の場合は2、Meticulousキー付きMD5の場合は3）、受信したパケットを破棄する必要があります。
If the Auth Key ID field does not match the ID of a configured
authentication key, the received packet MUST be discarded.
Auth Key IDフィールドが設定された認証キーのIDと一致しない場合、受信したパケットは破棄されなければなりません（MUST）。
If the Auth Len field is not equal to 24, the packet MUST be
discarded.
Auth Lenフィールドが24でない場合、パケットは破棄されなければなりません（MUST）。
If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For
Keyed MD5, if the sequence number lies outside of the range of
bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when
treated as an unsigned 32-bit circular number space), the received
packet MUST be discarded. For Meticulous Keyed MD5, if the
sequence number lies outside of the range of bfd.RcvAuthSeq+1 to
bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an
unsigned 32-bit circular number space) the received packet MUST be
discarded.
bfd.AuthSeqKnownが1の場合、[シーケンス番号]フィールドを調べます。 キー付きMD5の場合、シーケンス番号がbfd.RcvAuthSeqからbfd.RcvAuthSeq +（3 * Detect Mult）の範囲外（符号なし32ビット循環番号スペースとして扱われる場合）の外にある場合、受信パケットは破棄されなければなりません（MUST）。 Meticulous Keyed MD5の場合、シーケンス番号がbfd.RcvAuthSeq + 1からbfd.RcvAuthSeq +（3 * Detect Mult）の範囲外の場合（符号なし32ビット循環番号スペースとして扱われる場合）、受信したパケットは破棄する必要があります 。
Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to
1, and bfd.RcvAuthSeq MUST be set to the value of the received
Sequence Number field.
それ以外の場合（bfd.AuthSeqKnownは0）、bfd.AuthSeqKnownは1に設定する必要があり、bfd.RcvAuthSeqは受信したシーケンス番号フィールドの値に設定する必要があります。
Katz & Ward Standards Track [Page 24]
RFC 5880 Bidirectional Forwarding Detection June 2010
Replace the contents of the Auth Key/Digest field with the
authentication key selected by the received Auth Key ID field. If
the MD5 digest of the entire BFD Control packet is equal to the
received value of the Auth Key/Digest field, the received packet
MUST be accepted. Otherwise (the digest does not match the Auth
Key/Digest field), the received packet MUST be discarded.
[Auth Key / Digest]フィールドの内容を、受信した[Auth Key ID]フィールドで選択された認証キーに置き換えます。 BFD制御パケット全体のMD5ダイジェストが、Auth Key / Digestフィールドの受信値と等しい場合、受信パケットを受け入れる必要があります。 それ以外の場合（ダイジェストが認証キー/ダイジェストフィールドと一致しない場合）、受信したパケットは破棄する必要があります。
6.7.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication
6.7.4。 鍵付きSHA1および細心の注意を払った鍵付きSHA1認証
The Keyed SHA1 and Meticulous Keyed SHA1 Authentication mechanisms are very similar to those used in other protocols. In these methods of authentication, one or more secret keys (with corresponding key IDs) are configured in each system. One of the keys is included in a SHA1 [SHA1] hash calculated over the outgoing BFD Control packet, but the key itself is not carried in the packet. To help avoid replay attacks, a sequence number is also carried in each packet. For Keyed SHA1, the sequence number is occasionally incremented. For Meticulous Keyed SHA1, the sequence number is incremented on every packet.
Keyed SHA1およびMeticulous Keyed SHA1認証メカニズムは、他のプロトコルで使用されるものと非常に似ています。 これらの認証方法では、各システムで1つ以上の秘密鍵（対応する鍵IDを含む）が構成されます。 キーの1つは、発信BFD制御パケットで計算されたSHA1 [SHA1]ハッシュに含まれていますが、キー自体はパケットに含まれていません。 リプレイ攻撃を回避するために、各パケットにはシーケンス番号も含まれています。 キー付きSHA1の場合、シーケンス番号は時々増加します。 Meticulous Keyed SHA1の場合、シーケンス番号はすべてのパケットで増分されます。
The receiving system accepts the packet if the key ID matches one of the configured keys, a SHA1 hash including the selected key matches that carried in the packet, and if the sequence number is greater than or equal to the last sequence number received (for Keyed SHA1), or strictly greater than the last sequence number received (for Meticulous Keyed SHA1).
受信システムは、キーIDが構成済みのキーの1つと一致し、選択したキーを含むSHA1ハッシュがパケットで運ばれたものと一致し、シーケンス番号が最後に受信したシーケンス番号以上である場合にパケットを受け入れます（Keyedの場合 SHA1）、または受信した最後のシーケンス番号よりも完全に大きい（Meticulous Keyed SHA1の場合）。
Transmission Using Keyed SHA1 and Meticulous Keyed SHA1
キー付きSHA1と細心の注意を払ったキー付きSHA1を使用した送信
Authentication
認証
The Auth Type field MUST be set to 4 (Keyed SHA1) or 5 (Meticulous
Keyed SHA1). The Auth Len field MUST be set to 28. The Auth Key
ID field MUST be set to the ID of the current authentication key.
The Sequence Number field MUST be set to bfd.XmitAuthSeq.
Auth Typeフィールドは4（Keyed SHA1）または5（Meticulous Keyed SHA1）に設定する必要があります。 Auth Lenフィールドは28に設定する必要があります。 Auth Key IDフィールドは、現在の認証キーのIDに設定する必要があります。 シーケンス番号フィールドはbfd.XmitAuthSeqに設定する必要があります。
The authentication key value is a binary string of up to 20 bytes,
and MUST be placed into the Auth Key/Hash field, padding with
trailing zero bytes as necessary. For interoperability, the
management interface by which the key is configured MUST accept
ASCII strings, and SHOULD also allow for the configuration of any
arbitrary binary string in hexadecimal form. Other configuration
methods MAY be supported.
認証キーの値は最大20バイトのバイナリ文字列であり、必要に応じて末尾に0バイトを埋め込んで、認証キー/ハッシュフィールドに配置する必要があります。 相互運用性のために、キーを構成する管理インターフェースはASCII文字列を受け入れる必要があり、SHOULDはまた、16進形式の任意のバイナリ文字列の構成を許可する必要があります。 他の構成方法がサポートされる場合があります。
A SHA1 hash MUST be calculated over the entire BFD control packet.
The resulting hash MUST be stored in the Auth Key/Hash field prior
to transmission (replacing the secret key, which MUST NOT be
carried in the packet).
SHA1ハッシュは、BFD制御パケット全体で計算する必要があります。 結果のハッシュは、送信の前にAuth Key / Hashフィールドに格納する必要があります（パケットで搬送してはならない秘密鍵を置き換える必要があります）。
Katz & Ward Standards Track [Page 25]
RFC 5880 Bidirectional Forwarding Detection June 2010
For Keyed SHA1, bfd.XmitAuthSeq MAY be incremented in a circular
fashion (when treated as an unsigned 32-bit value).
bfd.XmitAuthSeq SHOULD be incremented when the session state
changes, or when the transmitted BFD Control packet carries
different contents than the previously transmitted packet. The
decision as to when to increment bfd.XmitAuthSeq is outside the
scope of this specification. See the section titled "Security
Considerations" below for a discussion.
Keyed SHA1の場合、bfd.XmitAuthSeqは循環方式でインクリメントされる場合があります（符号なし32ビット値として扱われる場合）。 bfd.XmitAuthSeqは、セッション状態が変化したとき、または送信されたBFD制御パケットが以前に送信されたパケットとは異なる内容を運ぶときにインクリメントされる必要があります（SHOULD）。 bfd.XmitAuthSeqをいつインクリメントするかに関する決定は、この仕様の範囲外です。 説明については、以下の「セキュリティに関する考慮事項」というタイトルのセクションを参照してください。
For Meticulous Keyed SHA1, bfd.XmitAuthSeq MUST be incremented in
a circular fashion (when treated as an unsigned 32-bit value).
Meticulous Keyed SHA1の場合、bfd.XmitAuthSeqは循環方式でインクリメントされる必要があります（符号なし32ビット値として扱われる場合）。
Receipt Using Keyed SHA1 and Meticulous Keyed SHA1 Authentication
キー付きSHA1および細心の注意を払ったキー付きSHA1認証を使用した領収書
If the received BFD Control packet does not contain an
Authentication Section, or the Auth Type is not correct (4 for
Keyed SHA1 or 5 for Meticulous Keyed SHA1), then the received
packet MUST be discarded.
受信したBFD制御パケットに認証セクションが含まれていない場合、または認証タイプが正しくない場合（Keyed SHA1の場合は4、Meticulous Keyed SHA1の場合は5）、受信したパケットを破棄する必要があります。
If the Auth Key ID field does not match the ID of a configured
authentication key, the received packet MUST be discarded.
Auth Key IDフィールドが設定された認証キーのIDと一致しない場合、受信したパケットは破棄されなければなりません（MUST）。
If the Auth Len field is not equal to 28, the packet MUST be
discarded.
Auth Lenフィールドが28でない場合、パケットは破棄されなければなりません（MUST）。
If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For
Keyed SHA1, if the sequence number lies outside of the range of
bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when
treated as an unsigned 32-bit circular number space), the received
packet MUST be discarded. For Meticulous Keyed SHA1, if the
sequence number lies outside of the range of bfd.RcvAuthSeq+1 to
bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an
unsigned 32-bit circular number space, the received packet MUST be
discarded.
bfd.AuthSeqKnownが1の場合、[シーケンス番号]フィールドを調べます。 Keyed SHA1の場合、シーケンス番号がbfd.RcvAuthSeqからbfd.RcvAuthSeq +（3 * Detect Mult）の範囲外（符号なし32ビット循環番号スペースとして扱われる場合）の外にある場合、受信したパケットは破棄する必要があります。 Meticulous Keyed SHA1の場合、シーケンス番号がbfd.RcvAuthSeq + 1からbfd.RcvAuthSeq +（3 * Detect Mult）の範囲外にある場合（符号なし32ビット循環番号スペースとして扱われる場合）、受信したパケットは破棄する必要があります 。
Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to
1, bfd.RcvAuthSeq MUST be set to the value of the received
Sequence Number field, and the received packet MUST be accepted.
それ以外の場合（bfd.AuthSeqKnownは0）、bfd.AuthSeqKnownを1に設定する必要があり、bfd.RcvAuthSeqを受信したシーケンス番号フィールドの値に設定する必要があり、受信したパケットを受け入れる必要があります。
Replace the contents of the Auth Key/Hash field with the
authentication key selected by the received Auth Key ID field. If
the SHA1 hash of the entire BFD Control packet is equal to the
received value of the Auth Key/Hash field, the received packet
MUST be accepted. Otherwise (the hash does not match the Auth
Key/Hash field), the received packet MUST be discarded.
[Auth Key / Hash]フィールドの内容を、受信した[Auth Key ID]フィールドで選択された認証キーに置き換えます。 BFD制御パケット全体のSHA1ハッシュがAuth Key / Hashフィールドの受信値と等しい場合、受信パケットは受け入れられなければなりません（MUST）。 それ以外の場合（ハッシュがAuth Key / Hashフィールドと一致しない場合）、受信したパケットは破棄する必要があります。
Katz & Ward Standards Track [Page 26] RFC 5880 Bidirectional Forwarding Detection June 2010 6.8. Functional Specifics
6.8。 機能仕様
The following section of this specification is normative. The means by which this specification is achieved is outside the scope of this specification.
この仕様の次のセクションは規範的です。 この仕様が達成される手段は、この仕様の範囲外です。
When a system is said to have "the Echo function active" it means that the system is sending BFD Echo packets, implying that the session is Up and the other system has signaled its willingness to loop back Echo packets.
システムが「エコー機能がアクティブ」であるとは、システムがBFDエコーパケットを送信していることを意味します。これは、セッションがアップしていて、他のシステムがエコーパケットをループバックする意思があることを示していることを意味します。
When the local system is said to have "Demand mode active," it means that bfd.DemandMode is 1 in the local system (see section 6.8.1), the session is Up, and the remote system is signaling that the session is in state Up.
ローカルシステムが「デマンドモードがアクティブ」であると言われる場合、それはローカルシステム（セクション6.8.1を参照）でbfd.DemandModeが1であり、セッションがアップであり、リモートシステムがセッションが 状態アップ。
When the remote system is said to have "Demand mode active," it means that bfd.RemoteDemandMode is 1 (the remote system set the Demand (D) bit in the last received BFD Control packet), the session is Up, and the remote system is signaling that the session is in state Up.
リモートシステムが「デマンドモードがアクティブ」であると言われる場合、bfd.RemoteDemandModeが1（リモートシステムが最後に受信したBFD制御パケットのデマンド（D）ビットを設定）であり、セッションがアップであり、リモート システムはセッションがアップ状態であることを通知しています。
6.8.1. State Variables
6.8.1。 状態変数
A minimum amount of information about a session needs to be tracked in order to achieve the elements of procedure described here. The following is a set of state variables that are helpful in describing the mechanisms of BFD. Any means of tracking this state may be used so long as the protocol behaves as described.
ここで説明する手順の要素を実現するには、セッションに関する最小限の情報を追跡する必要があります。 以下は、BFDのメカニズムの説明に役立つ状態変数のセットです。 プロトコルが記述されたように動作する限り、この状態を追跡する任意の手段を使用できます。
When the text refers to initializing a state variable, this takes place only at the time that the session (and the corresponding state variables) is created. The state variables are subsequently manipulated by the state machine and are never reinitialized, even if the session fails and is reestablished.
テキストが状態変数の初期化を参照している場合、これは、セッション（および対応する状態変数）が作成されたときにのみ行われます。 その後、状態変数は状態マシンによって操作され、セッションが失敗して再確立された場合でも、再初期化されることはありません。
Once session state is created, and at least one BFD Control packet is received from the remote end, it MUST be preserved for at least one Detection Time (see section 6.8.4) subsequent to the receipt of the last BFD Control packet, regardless of the session state. This preserves timing parameters in case the session flaps. A system MAY preserve session state longer than this. The preservation or destruction of session state when no BFD Control packets for this session have been received from the remote system is outside the scope of this specification.
セッション状態が作成され、リモートエンドから少なくとも1つのBFD制御パケットが受信されると、それに関係なく、最後のBFD制御パケットの受信後、少なくとも1つの検出時間（セクション6.8.4を参照）保持する必要があります。 セッション状態。 これにより、セッションがフラップした場合のタイミングパラメータが保持されます。 システムは、これより長くセッション状態を保持できます。 このセッションのBFD制御パケットがリモートシステムから受信されていない場合のセッション状態の保持または破棄は、この仕様の範囲外です。
Katz & Ward Standards Track [Page 27] RFC 5880 Bidirectional Forwarding Detection June 2010 All state variables in this specification are of the form "bfd.Xx" and should not be confused with fields carried in the protocol packets, which are always spelled out to match the names in section 4.
この仕様のすべての状態変数は「bfd.Xx」の形式であり、セクション4の名前と一致するように常にスペルアウトされるプロトコルパケットで運ばれるフィールドと混同しないでください。
bfd.SessionState
bfd.SessionState
The perceived state of the session (Init, Up, Down, or AdminDown).
The exact action taken when the session state changes is outside
the scope of this specification, though it is expected that this
state change (particularly, to and from Up state) is reported to
other components of the system. This variable MUST be initialized
to Down.
セッションの認識された状態（Init、Up、Down、またはAdminDown）。 セッションの状態が変化したときに行われる正確なアクションは、この仕様の範囲外ですが、この状態の変化（特に、アップ状態との間）は、システムの他のコンポーネントに報告されることが予想されます。 この変数はDownに初期化する必要があります。
bfd.RemoteSessionState
bfd.RemoteSessionState
The session state last reported by the remote system in the State
(Sta) field of the BFD Control packet. This variable MUST be
initialized to Down.
BFD制御パケットの状態（Sta）フィールドでリモートシステムによって最後に報告されたセッション状態。 この変数はDownに初期化する必要があります。
bfd.LocalDiscr
bfd.LocalDiscr
The local discriminator for this BFD session, used to uniquely
identify it. It MUST be unique across all BFD sessions on this
system, and nonzero. It SHOULD be set to a random (but still
unique) value to improve security. The value is otherwise outside
the scope of this specification.
このBFDセッションのローカル識別子。一意に識別するために使用されます。 これは、このシステムのすべてのBFDセッション全体で一意でなければならず、ゼロ以外でなければなりません。 セキュリティを向上させるために、ランダムな値（ただし、一意の値）に設定する必要があります。 それ以外の場合、値はこの仕様の範囲外です。
bfd.RemoteDiscr
bfd.RemoteDiscr
The remote discriminator for this BFD session. This is the
discriminator chosen by the remote system, and is totally opaque
to the local system. This MUST be initialized to zero. If a
period of a Detection Time passes without the receipt of a valid,
authenticated BFD packet from the remote system, this variable
MUST be set to zero.
このBFDセッションのリモート識別子。 これは、リモートシステムによって選択された弁別子であり、ローカルシステムに対して完全に不透明です。 これはゼロに初期化する必要があります。 リモートシステムから有効な認証済みBFDパケットを受信せずに検出時間の期間が経過した場合、この変数はゼロに設定する必要があります。
bfd.LocalDiag
bfd.LocalDiag
The diagnostic code specifying the reason for the most recent
change in the local session state. This MUST be initialized to
zero (No Diagnostic).
ローカルセッション状態の最新の変更の理由を指定する診断コード。 これはゼロに初期化する必要があります（診断なし）。
Katz & Ward Standards Track [Page 28] RFC 5880 Bidirectional Forwarding Detection June 2010 bfd.DesiredMinTxInterval
bfd.DesiredMinTxInterval
The minimum interval, in microseconds, between transmitted BFD
Control packets that this system would like to use at the current
time, less any jitter applied (see section 6.8.2). The actual
interval is negotiated between the two systems. This MUST be
initialized to a value of at least one second (1,000,000
microseconds) according to the rules described in section 6.8.3.
The setting of this variable is otherwise outside the scope of
this specification.
このシステムが現在使用したい送信されたBFD制御パケット間の最小間隔（マイクロ秒単位）で、適用されたジッターを差し引いたものです（セクション6.8.2を参照）。 実際の間隔は、2つのシステム間でネゴシエートされます。 これは、セクション6.8.3で説明されている規則に従って、少なくとも1秒（1,000,000マイクロ秒）の値に初期化する必要があります。 それ以外の場合、この変数の設定は、この仕様の範囲外です。
bfd.RequiredMinRxInterval
bfd.RequiredMinRxInterval
The minimum interval, in microseconds, between received BFD
Control packets that this system requires, less any jitter applied
by the sender (see section 6.8.2). The setting of this variable
is outside the scope of this specification. A value of zero means
that this system does not want to receive any periodic BFD Control
packets. See section 6.8.18 for details.
このシステムが必要とする、受信したBFD制御パケット間の最小間隔（マイクロ秒単位）は、送信者によって適用されるジッターを減らします（セクション6.8.2を参照）。 この変数の設定は、この仕様の範囲外です。 値がゼロの場合、このシステムは定期的なBFD制御パケットを受信したくないことを意味します。 詳細については、セクション6.8.18を参照してください。
bfd.RemoteMinRxInterval
bfd.RemoteMinRxInterval
The last value of Required Min RX Interval received from the
remote system in a BFD Control packet. This variable MUST be
initialized to 1.
BFD制御パケットでリモートシステムから受信した必要な最小RX間隔の最後の値。 この変数は1に初期化する必要があります。
bfd.DemandMode
bfd.DemandMode
Set to 1 if the local system wishes to use Demand mode, or 0 if
not.
ローカルシステムがデマンドモードを使用する場合は1に設定し、使用しない場合は0に設定します。
bfd.RemoteDemandMode
bfd.RemoteDemandMode
Set to 1 if the remote system wishes to use Demand mode, or 0 if
not. This is the value of the Demand (D) bit in the last received
BFD Control packet. This variable MUST be initialized to zero.
リモートシステムがデマンドモードを使用する場合は1に設定し、使用しない場合は0に設定します。 これは、最後に受信したBFD制御パケットのデマンド（D）ビットの値です。 この変数はゼロに初期化する必要があります。
bfd.DetectMult
bfd.DetectMult
The desired Detection Time multiplier for BFD Control packets on
the local system. The negotiated Control packet transmission
interval, multiplied by this variable, will be the Detection Time
for this session (as seen by the remote system). This variable
MUST be a nonzero integer, and is otherwise outside the scope of
this specification. See section 6.8.4 for further information.
ローカルシステムのBFD制御パケットに必要な検出時間乗数。 ネゴシエートされた制御パケットの送信間隔にこの変数を掛けると、このセッションの検出時間になります（リモートシステムから見た場合）。 この変数はゼロ以外の整数でなければならず、そうでなければ、この仕様の範囲外です。 詳細については、セクション6.8.4を参照してください。
Katz & Ward Standards Track [Page 29] RFC 5880 Bidirectional Forwarding Detection June 2010 bfd.AuthType
bfd.AuthType
The authentication type in use for this session, as defined in
section 4.1, or zero if no authentication is in use.
セクション4.1で定義されている、このセッションで使用されている認証タイプ。認証が使用されていない場合はゼロ。
bfd.RcvAuthSeq
bfd.RcvAuthSeq
A 32-bit unsigned integer containing the last sequence number for
Keyed MD5 or SHA1 Authentication that was received. The initial
value is unimportant.
受信したキー付きMD5またはSHA1認証の最後のシーケンス番号を含む32ビットの符号なし整数。 初期値は重要ではありません。
bfd.XmitAuthSeq
bfd.XmitAuthSeq
A 32-bit unsigned integer containing the next sequence number for
Keyed MD5 or SHA1 Authentication to be transmitted. This variable
MUST be initialized to a random 32-bit value.
送信されるキー付きMD5またはSHA1認証の次のシーケンス番号を含む32ビットの符号なし整数。 この変数は、ランダムな32ビット値に初期化する必要があります。
bfd.AuthSeqKnown
bfd.AuthSeqKnown
Set to 1 if the next sequence number for Keyed MD5 or SHA1
authentication expected to be received is known, or 0 if it is not
known. This variable MUST be initialized to zero.
受信が予想されるKeyed MD5またはSHA1認証の次のシーケンス番号がわかっている場合は1に設定し、わかっていない場合は0に設定します。 この変数はゼロに初期化する必要があります。
This variable MUST be set to zero after no packets have been
received on this session for at least twice the Detection Time.
This ensures that the sequence number can be resynchronized if the
remote system restarts.
検出時間の2倍以上、このセッションでパケットが受信されなかった場合、この変数をゼロに設定する必要があります。 これにより、リモートシステムが再起動した場合にシーケンス番号を再同期できます。
6.8.2. Timer Negotiation
6.8.2。 タイマー交渉
The time values used to determine BFD packet transmission intervals and the session Detection Time are continuously negotiated, and thus may be changed at any time. The negotiation and time values are independent in each direction for each session.
BFDパケットの送信間隔とセッション検出時間を決定するために使用される時間値は継続的にネゴシエートされるため、いつでも変更できます。 ネゴシエーションと時間の値は、各セッションの各方向で独立しています。
Each system reports in the BFD Control packet how rapidly it would like to transmit BFD packets, as well as how rapidly it is prepared to receive them. This allows either system to unilaterally determine the maximum packet rate (minimum interval) in both directions.
各システムは、BFD制御パケットで、BFDパケットの送信速度と受信準備の速度をレポートします。 これにより、どちらのシステムでも、片方向で両方向の最大パケットレート（最小間隔）を決定できます。
See section 6.8.7 for the details of packet transmission timing and negotiation.
パケット送信タイミングとネゴシエーションの詳細については、セクション6.8.7を参照してください。
Katz & Ward Standards Track [Page 30] RFC 5880 Bidirectional Forwarding Detection June 2010 6.8.3. Timer Manipulation
6.8.3。 タイマー操作
The time values used to determine BFD packet transmission intervals and the session Detection Time may be modified at any time without affecting the state of the session. When the timer parameters are changed for any reason, the requirements of this section apply.
BFDパケット送信間隔とセッション検出時間を決定するために使用される時間値は、セッションの状態に影響を与えることなく、いつでも変更できます。 タイマーパラメータが何らかの理由で変更された場合、このセクションの要件が適用されます。
If either bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be initiated (see section 6.5). If the timing is such that a system receiving a Poll Sequence wishes to change the parameters described in this paragraph, the new parameter values MAY be carried in packets with the Final (F) bit set, even if the Poll Sequence has not yet been sent.
bfd.DesiredMinTxIntervalが変更された場合、またはbfd.RequiredMinRxIntervalが変更された場合は、ポーリングシーケンスを開始する必要があります（セクション6.5を参照）。 ポーリングシーケンスを受信するシステムがこの段落で説明されているパラメーターを変更したいようなタイミングである場合、ポーリングシーケンスがまだ送信されていなくても、新しいパラメーター値は最終（F）ビットが設定されたパケットで搬送される場合があります。 。
If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up, the actual transmission interval used MUST NOT change until the Poll Sequence described above has terminated. This is to ensure that the remote system updates its Detection Time before the transmission interval increases.
bfd.DesiredMinTxIntervalが増加し、bfd.SessionStateがUpの場合、使用される実際の送信間隔は、上記のポーリングシーケンスが終了するまで変更してはなりません（MUST NOT）。 これは、送信間隔が長くなる前に、リモートシステムが検出時間を更新するようにするためです。
If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up, the previous value of bfd.RequiredMinRxInterval MUST be used when calculating the Detection Time for the remote system until the Poll Sequence described above has terminated. This is to ensure that the remote system is transmitting packets at the higher rate (and those packets are being received) prior to the Detection Time being reduced.
bfd.RequiredMinRxIntervalが削減され、bfd.SessionStateがUpの場合、上記のポーリングシーケンスが終了するまで、リモートシステムの検出時間を計算するときに、bfd.RequiredMinRxIntervalの以前の値を使用する必要があります。 これは、検出時間を短縮する前に、リモートシステムがより高いレートでパケットを送信している（そしてそれらのパケットが受信されている）ことを確認するためです。
When bfd.SessionState is not Up, the system MUST set bfd.DesiredMinTxInterval to a value of not less than one second (1,000,000 microseconds). This is intended to ensure that the bandwidth consumed by BFD sessions that are not Up is negligible, particularly in the case where a neighbor may not be running BFD.
bfd.SessionStateがUpでない場合、システムはbfd.DesiredMinTxIntervalを1秒（1,000,000マイクロ秒）以上の値に設定する必要があります。 これは、特にネイバーがBFDを実行していない可能性がある場合に、稼働していないBFDセッションによって消費される帯域幅を無視できるようにすることを目的としています。
If the local system reduces its transmit interval due to bfd.RemoteMinRxInterval being reduced (the remote system has advertised a reduced value in Required Min RX Interval), and the remote system is not in Demand mode, the local system MUST honor the new interval immediately. In other words, the local system cannot wait longer than the new interval between the previous packet transmission and the next one. If this interval has already passed since the last transmission (because the new interval is significantly shorter), the local system MUST send the next periodic BFD Control packet as soon as practicable.
bfd.RemoteMinRxIntervalが減少したためにローカルシステムが送信間隔を短縮し（リモートシステムが必要な最小RX間隔で減少した値をアドバタイズした）、リモートシステムがデマンドモードでない場合、ローカルシステムは新しい間隔をただちに遵守する必要があります。 。 つまり、ローカルシステムは、前のパケット送信と次のパケット送信の間の新しい間隔よりも長く待つことはできません。 最後の送信からこの間隔が既に経過している場合（新しい間隔が大幅に短いため）、ローカルシステムは、できるだけ早く次の定期的なBFD制御パケットを送信する必要があります。
Katz & Ward Standards Track [Page 31] RFC 5880 Bidirectional Forwarding Detection June 2010 When the Echo function is active, a system SHOULD set bfd.RequiredMinRxInterval to a value of not less than one second (1,000,000 microseconds). This is intended to keep received BFD Control traffic at a negligible level, since the actual detection function is being performed using BFD Echo packets.
Echo機能がアクティブな場合、システムはbfd.RequiredMinRxIntervalを1秒（1,000,000マイクロ秒）以上の値に設定する必要があります（SHOULD）。 これは、実際の検出機能がBFDエコーパケットを使用して実行されているため、受信したBFD制御トラフィックを無視できるレベルに保つことを目的としています。
In any case other than those explicitly called out above, timing parameter changes MUST be effected immediately (changing the transmission rate and/or the Detection Time).
上記で明示的に呼び出されたもの以外の場合は、タイミングパラメータの変更を直ちに行う必要があります（送信レートや検出時間の変更）。
Note that the Poll Sequence mechanism is ambiguous if more than one parameter change is made that would require its use, and those multiple changes are spread across multiple packets (since the semantics of the returning Final are unclear). Therefore, if multiple changes are made that require the use of a Poll Sequence, there are three choices: 1) they MUST be communicated in a single BFD Control packet (so the semantics of the Final reply are clear), or 2) sufficient time must have transpired since the Poll Sequence was completed to disambiguate the situation (at least a round trip time since the last Poll was transmitted) prior to the initiation of another Poll Sequence, or 3) an additional BFD Control packet with the Final (F) bit *clear* MUST be received after the Poll Sequence has completed prior to the initiation of another Poll Sequence (this option is not available when Demand mode is active).
使用を必要とする複数のパラメーター変更が行われた場合、ポーリングシーケンスメカニズムはあいまいであり、それらの複数の変更は複数のパケットに分散されます（返されるFinalのセマンティクスが不明であるため）。 したがって、ポーリングシーケンスの使用を必要とする複数の変更が行われた場合、3つの選択肢があります。1）それらは単一のBFD制御パケットで通信する必要がある（そのため、最終応答のセマンティクスは明確です）、または2）十分な時間 別のポーリングシーケンスの開始前に、状況を明確にするために、ポーリングシーケンスが完了してから（少なくとも最後のポーリングが送信されてからの往復時間）、または3）最終（B）を含む追加のBFD制御パケットが発生した 別のポーリングシーケンスの開始前にポーリングシーケンスが完了した後、ビット*クリア*を受信する必要があります（このオプションは、デマンドモードがアクティブな場合は使用できません）。
6.8.4. Calculating the Detection Time
6.8.4。 検出時間の計算
The Detection Time (the period of time without receiving BFD packets after which the session is determined to have failed) is not carried explicitly in the protocol. Rather, it is calculated independently in each direction by the receiving system based on the negotiated transmit interval and the detection multiplier. Note that there may be different Detection Times in each direction.
検出時間（セッションが失敗したと判断されてからBFDパケットを受信しない期間）は、プロトコルで明示的に伝えられません。 むしろ、ネゴシエートされた送信間隔と検出乗数に基づいて、受信システムによって各方向で独立して計算されます。 各方向で異なる検出時間が存在する場合があることに注意してください。
The calculation of the Detection Time is slightly different when in Demand mode versus Asynchronous mode.
検出モードの計算は、デマンドモードと非同期モードでは若干異なります。
In Asynchronous mode, the Detection Time calculated in the local system is equal to the value of Detect Mult received from the remote system, multiplied by the agreed transmit interval of the remote system (the greater of bfd.RequiredMinRxInterval and the last received Desired Min TX Interval). The Detect Mult value is (roughly speaking, due to jitter) the number of packets that have to be missed in a row to declare the session to be down.
非同期モードでは、ローカルシステムで計算された検出時間は、リモートシステムから受信されたDetect Multの値に、リモートシステムの合意された送信間隔を乗算した値に等しくなります（bfd.RequiredMinRxIntervalと最後に受信されたDesired Min TXの大きい方） 間隔）。 Detect Multの値は、（大まかに言って、ジッターのため）、セッションがダウンしていることを宣言するために連続して見逃す必要があるパケットの数です。
Katz & Ward Standards Track [Page 32] RFC 5880 Bidirectional Forwarding Detection June 2010 If Demand mode is not active, and a period of time equal to the Detection Time passes without receiving a BFD Control packet from the remote system, and bfd.SessionState is Init or Up, the session has gone down -- the local system MUST set bfd.SessionState to Down and bfd.LocalDiag to 1 (Control Detection Time Expired).
デマンドモードがアクティブではなく、リモートシステムからBFD制御パケットを受信せずに検出時間と等しい期間が経過し、bfd.SessionStateがInitまたはUpである場合、セッションはダウンしています-ローカルシステムは設定する必要があります bfd.SessionStateをDownに、bfd.LocalDiagを1に（Control Detection Time Expired）。
In Demand mode, the Detection Time calculated in the local system is equal to bfd.DetectMult, multiplied by the agreed transmit interval of the local system (the greater of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval). bfd.DetectMult is (roughly speaking, due to jitter) the number of packets that have to be missed in a row to declare the session to be down.
デマンドモードでは、ローカルシステムで計算される検出時間は、bfd.DetectMultに、ローカルシステムの合意された送信間隔（bfd.DesiredMinTxIntervalとbfd.RemoteMinRxIntervalの大きい方）を掛けたものに等しくなります。 bfd.DetectMultは（大まかに言って、ジッターのため）、セッションがダウンしていることを宣言するために連続して失われる必要があるパケットの数です。
If Demand mode is active, and a period of time equal to the Detection Time passes after the initiation of a Poll Sequence (the transmission of the first BFD Control packet with the Poll bit set), the session has gone down -- the local system MUST set bfd.SessionState to Down, and bfd.LocalDiag to 1 (Control Detection Time Expired).
デマンドモードがアクティブで、ポーリングシーケンス（ポーリングビットが設定された最初のBFD制御パケットの送信）の開始後、検出時間に等しい時間が経過した場合、セッションはダウンしています-ローカルシステム bfd.SessionStateをDownに、bfd.LocalDiagを1（Control Detection Time Expired）に設定する必要があります。
(Note that a packet is considered to have been received, for the purposes of Detection Time expiration, only if it has not been "discarded" according to the rules of section 6.8.6).
（パケットは、セクション6.8.6のルールに従って「破棄」されていない場合にのみ、検出時間の有効期限のために受信されたと見なされることに注意してください）。
6.8.5. Detecting Failures with the Echo Function
6.8.5。 Echo関数を使用した障害の検出
When the Echo function is active and a sufficient number of Echo packets have not arrived as they should, the session has gone down -- the local system MUST set bfd.SessionState to Down and bfd.LocalDiag to 2 (Echo Function Failed).
Echo機能がアクティブで、十分な数のEchoパケットが到着しない場合、セッションはダウンしています-ローカルシステムはbfd.SessionStateをDownに、bfd.LocalDiagを2（Echo Function Failed）に設定する必要があります。
The means by which the Echo function failures are detected is outside of the scope of this specification. Any means that will detect a communication failure are acceptable.
Echo機能の障害を検出する手段は、この仕様の範囲外です。 通信障害を検出する手段はすべて受け入れられます。
6.8.6. Reception of BFD Control Packets
6.8.6。 BFD制御パケットの受信
When a BFD Control packet is received, the following procedure MUST be followed, in the order specified. If the packet is discarded according to these rules, processing of the packet MUST cease at that point.
BFD制御パケットが受信されると、指定された順序で、次の手順に従う必要があります。 パケットがこれらのルールに従って破棄された場合、パケットの処理はその時点で停止する必要があります。
If the version number is not correct (1), the packet MUST be
discarded.
バージョン番号が正しくない場合（1）、パケットは破棄する必要があります。
If the Length field is less than the minimum correct value (24 if
the A bit is clear, or 26 if the A bit is set), the packet MUST be
discarded.
長さフィールドが最小の正しい値（Aビットがクリアされている場合は24、Aビットが設定されている場合は26）より小さい場合、パケットは廃棄されなければなりません（MUST）。
Katz & Ward Standards Track [Page 33]
RFC 5880 Bidirectional Forwarding Detection June 2010
If the Length field is greater than the payload of the
encapsulating protocol, the packet MUST be discarded.
長さフィールドがカプセル化プロトコルのペイロードより大きい場合、パケットは破棄されなければなりません（MUST）。
If the Detect Mult field is zero, the packet MUST be discarded.
マルチ検出フィールドがゼロの場合、パケットは破棄されなければなりません（MUST）。
If the Multipoint (M) bit is nonzero, the packet MUST be
discarded.
マルチポイント（M）ビットがゼロ以外の場合は、パケットを破棄する必要があります。
If the My Discriminator field is zero, the packet MUST be
discarded.
My Discriminatorフィールドがゼロの場合、パケットは破棄されなければなりません（MUST）。
If the Your Discriminator field is nonzero, it MUST be used to
select the session with which this BFD packet is associated. If
no session is found, the packet MUST be discarded.
Your Discriminatorフィールドがゼロ以外の場合、このフィールドを使用して、このBFDパケットが関連付けられているセッションを選択する必要があります。 セッションが見つからない場合は、パケットを破棄する必要があります。
If the Your Discriminator field is zero and the State field is not
Down or AdminDown, the packet MUST be discarded.
Your Discriminatorフィールドがゼロで、StateフィールドがDownまたはAdminDownでない場合、パケットは破棄されなければなりません（MUST）。
If the Your Discriminator field is zero, the session MUST be
selected based on some combination of other fields, possibly
including source addressing information, the My Discriminator
field, and the interface over which the packet was received. The
exact method of selection is application specific and is thus
outside the scope of this specification. If a matching session is
not found, a new session MAY be created, or the packet MAY be
discarded. This choice is outside the scope of this
specification.
Your Discriminatorフィールドがゼロの場合、送信元アドレス指定情報、My Discriminatorフィールド、およびパケットが受信されたインターフェースを含む可能性のある他のフィールドのいくつかの組み合わせに基づいて、セッションを選択する必要があります。 正確な選択方法はアプリケーション固有であるため、この仕様の範囲外です。 一致するセッションが見つからない場合は、新しいセッションが作成されるか、パケットが破棄される場合があります。 この選択は、この仕様の範囲外です。
If the A bit is set and no authentication is in use (bfd.AuthType
is zero), the packet MUST be discarded.
Aビットが設定されていて、認証が使用されていない場合（bfd.AuthTypeはゼロ）、パケットは破棄されなければなりません（MUST）。
If the A bit is clear and authentication is in use (bfd.AuthType
is nonzero), the packet MUST be discarded.
Aビットがクリアされ、認証が使用されている場合（bfd.AuthTypeがゼロ以外）、パケットは破棄されなければなりません（MUST）。
If the A bit is set, the packet MUST be authenticated under the
rules of section 6.7, based on the authentication type in use
(bfd.AuthType). This may cause the packet to be discarded.
Aビットが設定されている場合、パケットは、使用されている認証タイプ（bfd.AuthType）に基づいて、セクション6.7のルールの下で認証される必要があります。 これにより、パケットが破棄される場合があります。
Set bfd.RemoteDiscr to the value of My Discriminator.
bfd.RemoteDiscrをMy Discriminatorの値に設定します。
Set bfd.RemoteState to the value of the State (Sta) field.
bfd.RemoteStateをState（Sta）フィールドの値に設定します。
Set bfd.RemoteDemandMode to the value of the Demand (D) bit.
bfd.RemoteDemandModeをDemand（D）ビットの値に設定します。
Set bfd.RemoteMinRxInterval to the value of Required Min RX
Interval.
bfd.RemoteMinRxIntervalをRequired Min RX Intervalの値に設定します。
Katz & Ward Standards Track [Page 34]
RFC 5880 Bidirectional Forwarding Detection June 2010
If the Required Min Echo RX Interval field is zero, the
transmission of Echo packets, if any, MUST cease.
Required Min Echo RX Intervalフィールドがゼロの場合、エコーパケットの送信は、もしあれば、中止する必要があります。
If a Poll Sequence is being transmitted by the local system and
the Final (F) bit in the received packet is set, the Poll Sequence
MUST be terminated.
ポーリングシーケンスがローカルシステムによって送信されており、受信したパケットの最終（F）ビットが設定されている場合、ポーリングシーケンスを終了する必要があります。
Update the transmit interval as described in section 6.8.2.
セクション6.8.2の説明に従って、送信間隔を更新します。
Update the Detection Time as described in section 6.8.4.
セクション6.8.4の説明に従って、検出時間を更新します。
If bfd.SessionState is AdminDown
Discard the packet
If received state is AdminDown
If bfd.SessionState is not Down
Set bfd.LocalDiag to 3 (Neighbor signaled
session down)
Set bfd.SessionState to Down
Else
If bfd.SessionState is Down
If received State is Down
Set bfd.SessionState to Init
Else if received State is Init
Set bfd.SessionState to Up
Else if bfd.SessionState is Init
If received State is Init or Up
Set bfd.SessionState to Up
Else (bfd.SessionState is Up)
If received State is Down
Set bfd.LocalDiag to 3 (Neighbor signaled
session down)
Set bfd.SessionState to Down
Check to see if Demand mode should become active or not (see
section 6.6).
デマンドモードをアクティブにする必要があるかどうかを確認します（セクション6.6を参照）。
If bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and
bfd.RemoteSessionState is Up, Demand mode is active on the remote
system and the local system MUST cease the periodic transmission
of BFD Control packets (see section 6.8.7).
bfd.RemoteDemandModeが1、bfd.SessionStateがUp、bfd.RemoteSessionStateがUpの場合、リモートシステムでデマンドモードがアクティブになり、ローカルシステムはBFD制御パケットの定期的な送信を停止する必要があります（セクション6.8.7を参照）。
Katz & Ward Standards Track [Page 35]
RFC 5880 Bidirectional Forwarding Detection June 2010
If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or
bfd.RemoteSessionState is not Up, Demand mode is not active on the
remote system and the local system MUST send periodic BFD Control
packets (see section 6.8.7).
bfd.RemoteDemandModeが0、bfd.SessionStateがUp、またはbfd.RemoteSessionStateがUpでない場合、リモートシステムでデマンドモードはアクティブではなく、ローカルシステムは定期的なBFD制御パケットを送信する必要があります（セクション6.8.7を参照）。
If the Poll (P) bit is set, send a BFD Control packet to the
remote system with the Poll (P) bit clear, and the Final (F) bit
set (see section 6.8.7).
Poll（P）ビットが設定されている場合、BFD制御パケットをPoll（P）ビットをクリアし、Final（F）ビットを設定してリモートシステムに送信します（セクション6.8.7を参照）。
If the packet was not discarded, it has been received for purposes
of the Detection Time expiration rules in section 6.8.4.
パケットが破棄されなかった場合、セクション6.8.4の検出時間の有効期限規則の目的で受信されています。
6.8.7. Transmitting BFD Control Packets
6.8.7。 BFD制御パケットの送信
With the exceptions listed in the remainder of this section, a system MUST NOT transmit BFD Control packets at an interval less than the larger of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval, less applied jitter (see below). In other words, the system reporting the slower rate determines the transmission rate.
このセクションの残りの部分にリストされている例外を除いて、システムは、bfd.DesiredMinTxIntervalおよびbfd.RemoteMinRxIntervalの大きい方より短い間隔でBFD制御パケットを送信してはなりません。 言い換えると、より遅いレートを報告するシステムが伝送レートを決定します。
The periodic transmission of BFD Control packets MUST be jittered on a per-packet basis by up to 25%, that is, the interval MUST be reduced by a random value of 0 to 25%, in order to avoid self- synchronization with other systems on the same subnetwork. Thus, the average interval between packets will be roughly 12.5% less than that negotiated.
他のシステムとの自己同期を回避するために、BFD制御パケットの定期的な送信には、パケットごとに最大25％のジッタを与える必要があります。つまり、間隔を0〜25％のランダムな値だけ減らす必要があります。 同じサブネットワーク上。 したがって、パケット間の平均間隔は、ネゴシエートされたものよりも約12.5％短くなります。
If bfd.DetectMult is equal to 1, the interval between transmitted BFD Control packets MUST be no more than 90% of the negotiated transmission interval, and MUST be no less than 75% of the negotiated transmission interval. This is to ensure that, on the remote system, the calculated Detection Time does not pass prior to the receipt of the next BFD Control packet.
bfd.DetectMultが1に等しい場合、送信されるBFD制御パケットの間隔は、交渉された送信間隔の90％以下でなければならず、交渉された送信間隔の75％以上でなければなりません（MUST）。 これは、リモートシステムで、次のBFD制御パケットを受信する前に、計算された検出時間が経過しないようにするためです。
The transmit interval MUST be recalculated whenever bfd.DesiredMinTxInterval changes, or whenever bfd.RemoteMinRxInterval changes, and is equal to the greater of those two values. See sections 6.8.2 and 6.8.3 for details on transmit timers.
送信間隔は、bfd.DesiredMinTxIntervalが変更されるたび、またはbfd.RemoteMinRxIntervalが変更されるたびに再計算する必要があり、これら2つの値の大きい方に等しくなります。 送信タイマーの詳細については、セクション6.8.2および6.8.3を参照してください。
A system MUST NOT transmit BFD Control packets if bfd.RemoteDiscr is zero and the system is taking the Passive role.
bfd.RemoteDiscrがゼロで、システムがパッシブの役割を果たしている場合、システムはBFD制御パケットを送信してはならない（MUST NOT）。
A system MUST NOT periodically transmit BFD Control packets if bfd.RemoteMinRxInterval is zero.
bfd.RemoteMinRxIntervalがゼロの場合、システムはBFD制御パケットを定期的に送信してはなりません（MUST NOT）。
Katz & Ward Standards Track [Page 36] RFC 5880 Bidirectional Forwarding Detection June 2010 A system MUST NOT periodically transmit BFD Control packets if Demand mode is active on the remote system (bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and bfd.RemoteSessionState is Up) and a Poll Sequence is not being transmitted.
リモートシステムでデマンドモードがアクティブであり（bfd.RemoteDemandModeが1、bfd.SessionStateがUp、bfd.RemoteSessionStateがUp）、ポーリングシーケンスが送信されていない場合、システムは定期的にBFD制御パケットを送信してはならない（MUST NOT）。
If a BFD Control packet is received with the Poll (P) bit set to 1, the receiving system MUST transmit a BFD Control packet with the Poll (P) bit clear and the Final (F) bit set as soon as practicable, without respect to the transmission timer or any other transmission limitations, without respect to the session state, and without respect to whether Demand mode is active on either system. A system MAY limit the rate at which such packets are transmitted. If rate limiting is in effect, the advertised value of Desired Min TX Interval MUST be greater than or equal to the interval between transmitted packets imposed by the rate limiting function.
Poll（P）ビットが1に設定されたBFD制御パケットが受信された場合、受信システムは、Poll（P）ビットがクリアされ、Final（F）ビットが設定されたBFD制御パケットを、関係なく、できるだけ早く送信しなければなりません（MUST）。 セッション状態に関係なく、またいずれかのシステムでデマンドモードがアクティブであるかどうかに関係なく、送信タイマーまたはその他の送信制限。 システムは、そのようなパケットが送信される速度を制限してもよい（MAY）。 レート制限が有効な場合、Desired Min TX Intervalのアドバタイズされた値は、レート制限機能によって課された送信パケット間の間隔以上でなければなりません（MUST）。
A system MUST NOT set the Demand (D) bit unless bfd.DemandMode is 1, bfd.SessionState is Up, and bfd.RemoteSessionState is Up.
bfd.DemandModeが1、bfd.SessionStateがUp、bfd.RemoteSessionStateがUpでない限り、システムはデマンド（D）ビットを設定してはならない（MUST NOT）。
A BFD Control packet SHOULD be transmitted during the interval between periodic Control packet transmissions when the contents of that packet would differ from that in the previously transmitted packet (other than the Poll and Final bits) in order to more rapidly communicate a change in state.
BFD制御パケットは、状態の変化をより迅速に伝えるために、そのパケットの内容が以前に送信されたパケット（ポーリングおよび最終ビット以外）と異なる場合に、定期的な制御パケット送信の間隔中に送信する必要があります。
The contents of transmitted BFD Control packets MUST be set as follows:
送信されるBFD制御パケットの内容は、次のように設定する必要があります。
Version
バージョン
Set to the current version number (1).
現在のバージョン番号（1）に設定します。
Diagnostic (Diag)
診断（診断）
Set to bfd.LocalDiag.
bfd.LocalDiagに設定します。
State (Sta)
状態（STA）
Set to the value indicated by bfd.SessionState.
bfd.SessionStateで示される値に設定します。
Poll (P)
ポーリング（P）
Set to 1 if the local system is sending a Poll Sequence, or 0 if
not.
ローカルシステムがポーリングシーケンスを送信する場合は1に設定し、送信しない場合は0に設定します。
Katz & Ward Standards Track [Page 37] RFC 5880 Bidirectional Forwarding Detection June 2010 Final (F)
最終（F）
Set to 1 if the local system is responding to a Control packet
received with the Poll (P) bit set, or 0 if not.
ローカルシステムがPoll（P）ビットセットで受信した制御パケットに応答している場合は1に設定し、そうでない場合は0に設定します。
Control Plane Independent (C)
独立したコントロールプレーン（C）
Set to 1 if the local system's BFD implementation is independent
of the control plane (it can continue to function through a
disruption of the control plane).
ローカルシステムのBFD実装がコントロールプレーンから独立している場合は、1に設定します（コントロールプレーンの中断によって機能を継続できます）。
Authentication Present (A)
認証あり（A）
Set to 1 if authentication is in use on this session (bfd.AuthType
is nonzero), or 0 if not.
このセッションで認証が使用されている場合（bfd.AuthTypeがゼロ以外）は1に設定し、そうでない場合は0に設定します。
Demand (D)
需要（D）
Set to bfd.DemandMode if bfd.SessionState is Up and
bfd.RemoteSessionState is Up. Otherwise, it is set to 0.
bfd.SessionStateがUpでbfd.RemoteSessionStateがUpの場合、bfd.DemandModeに設定します。 それ以外の場合は、0に設定されます。
Multipoint (M)
マルチポイント（M）
Set to 0.
0に設定します。
Detect Mult
マルチを検出
Set to bfd.DetectMult.
bfd.DetectMultに設定します。
Length
長さ
Set to the appropriate length, based on the fixed header length
(24) plus any Authentication Section.
固定ヘッダー長（24）と認証セクションに基づいて、適切な長さに設定します。
My Discriminator
私の弁別
Set to bfd.LocalDiscr.
bfd.LocalDiscrに設定します。
Your Discriminator
あなたの弁別
Set to bfd.RemoteDiscr.
bfd.RemoteDiscrに設定します。
Desired Min TX Interval
望ましい最小TX間隔
Set to bfd.DesiredMinTxInterval.
bfd.DesiredMinTxIntervalに設定します。
Katz & Ward Standards Track [Page 38] RFC 5880 Bidirectional Forwarding Detection June 2010 Required Min RX Interval
必要な最小RX間隔
Set to bfd.RequiredMinRxInterval.
bfd.RequiredMinRxIntervalに設定します。
Required Min Echo RX Interval
必要な最小エコーRX間隔
Set to the minimum required Echo packet receive interval for this
session. If this field is set to zero, the local system is
unwilling or unable to loop back BFD Echo packets to the remote
system, and the remote system will not send Echo packets.
このセッションに必要な最小エコーパケット受信間隔に設定します。 このフィールドがゼロに設定されている場合、ローカルシステムはBFDエコーパケットをリモートシステムにループバックすることを望まないか、またはできないため、リモートシステムはエコーパケットを送信しません。
Authentication Section
認証セクション
Included and set according to the rules in section 6.7 if
authentication is in use (bfd.AuthType is nonzero). Otherwise,
this section is not present.
認証が使用されている場合（bfd.AuthTypeがゼロ以外）、セクション6.7のルールに従って含まれ、設定されます。 それ以外の場合、このセクションはありません。
6.8.8. Reception of BFD Echo Packets
6.8.8。 BFDエコーパケットの受信
A received BFD Echo packet MUST be demultiplexed to the appropriate session for processing. A means of detecting missing Echo packets MUST be implemented, which most likely involves processing of the Echo packets that are received. The processing of received Echo packets is otherwise outside the scope of this specification.
受信したBFDエコーパケットは、処理のために適切なセッションに逆多重化する必要があります。 欠落しているエコーパケットを検出する手段を実装する必要があります。これには、受信したエコーパケットの処理が含まれる可能性が最も高くなります。 それ以外の場合、受信したエコーパケットの処理は、この仕様の範囲外です。
6.8.9. Transmission of BFD Echo Packets
6.8.9。 BFDエコーパケットの送信
BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not Up. BFD Echo packets MUST NOT be transmitted unless the last BFD Control packet received from the remote system contains a nonzero value in Required Min Echo RX Interval.
bfd.SessionStateがUpでない場合、BFDエコーパケットを送信してはなりません（MUST NOT）。 BFDエコーパケットは、リモートシステムから受信した最後のBFD制御パケットの必須最小エコーRX間隔にゼロ以外の値が含まれていない限り、送信してはなりません（MUST NOT）。
BFD Echo packets MAY be transmitted when bfd.SessionState is Up. The interval between transmitted BFD Echo packets MUST NOT be less than the value advertised by the remote system in Required Min Echo RX Interval, except as follows:
BFDエコーパケットは、bfd.SessionStateがアップのときに送信される場合があります。 送信されたBFDエコーパケット間の間隔は、次の場合を除いて、必要な最小エコー受信間隔でリモートシステムによってアドバタイズされた値よりも小さくしてはなりません（MUST NOT）。
A 25% jitter MAY be applied to the rate of transmission, such that
the actual interval MAY be between 75% and 100% of the advertised
value. A single BFD Echo packet MAY be transmitted between
normally scheduled Echo transmission intervals.
実際の間隔がアドバタイズされた値の75％から100％の間になるように、25％のジッタが送信レートに適用される場合があります。 単一のBFDエコーパケットは、通常スケジュールされたエコー送信間隔の間に送信される場合があります。
The transmission of BFD Echo packets is otherwise outside the scope of this specification.
それ以外の場合、BFDエコーパケットの送信は、この仕様の範囲外です。
Katz & Ward Standards Track [Page 39] RFC 5880 Bidirectional Forwarding Detection June 2010 6.8.10. Min Rx Interval Change
6.8.10。 最小受信間隔変更
When it is desired to change the rate at which BFD Control packets arrive from the remote system, bfd.RequiredMinRxInterval can be changed at any time to any value. The new value will be transmitted in the next outgoing Control packet, and the remote system will adjust accordingly. See section 6.8.3 for further requirements.
BFD制御パケットがリモートシステムから到着するレートを変更する必要がある場合、bfd.RequiredMinRxIntervalをいつでも任意の値に変更できます。 新しい値は次の発信制御パケットで送信され、リモートシステムはそれに応じて調整します。 詳細な要件については、セクション6.8.3を参照してください。
6.8.11. Min Tx Interval Change
6.8.11。 最小送信間隔の変更
When it is desired to change the rate at which BFD Control packets are transmitted to the remote system (subject to the requirements of the neighboring system), bfd.DesiredMinTxInterval can be changed at any time to any value. The rules in section 6.8.3 apply.
BFD制御パケットがリモートシステムに送信されるレートを変更する必要がある場合（隣接システムの要件に従う）、bfd.DesiredMinTxIntervalをいつでも任意の値に変更できます。 セクション6.8.3のルールが適用されます。
6.8.12. Detect Multiplier Change
6.8.12。 乗数の変化を検出
When it is desired to change the detect multiplier, the value of bfd.DetectMult can be changed to any nonzero value. The new value will be transmitted with the next BFD Control packet, and the use of a Poll Sequence is not necessary. See section 6.6 for additional requirements.
検出乗数を変更する必要がある場合は、bfd.DetectMultの値をゼロ以外の値に変更できます。 新しい値は次のBFD制御パケットで送信され、ポーリングシーケンスを使用する必要はありません。 その他の要件については、セクション6.6を参照してください。
6.8.13. Enabling or Disabling The Echo Function
6.8.13。 エコー機能の有効化または無効化
If it is desired to start or stop the transmission of BFD Echo packets, this MAY be done at any time (subject to the transmission requirements detailed in section 6.8.9).
BFDエコーパケットの送信を開始または停止することが望まれる場合、これはいつでも実行できます（セクション6.8.9に詳述されている送信要件に従う必要があります）。
If it is desired to enable or disable the looping back of received BFD Echo packets, this MAY be done at any time by changing the value of Required Min Echo RX Interval to zero or nonzero in outgoing BFD Control packets.
受信したBFDエコーパケットのループバックを有効または無効にする必要がある場合は、発信BFD制御パケットで必要な最小エコー受信間隔の値をゼロまたはゼロ以外に変更することで、いつでもこれを実行できます。
6.8.14. Enabling or Disabling Demand Mode
6.8.14。 デマンドモードの有効化または無効化
If it is desired to start or stop Demand mode, this MAY be done at any time by setting bfd.DemandMode to the proper value. Demand mode will subsequently become active under the rules described in section 6.6.
デマンドモードを開始または停止する必要がある場合は、bfd.DemandModeを適切な値に設定することにより、いつでもこれを実行できます。 デマンドモードは、セクション6.6で説明されているルールの下でアクティブになります。
If Demand mode is no longer active on the remote system, the local system MUST begin transmitting periodic BFD Control packets as described in section 6.8.7.
リモートシステムでデマンドモードがアクティブでなくなった場合、ローカルシステムは、セクション6.8.7で説明されているように、定期的なBFD制御パケットの送信を開始する必要があります。
Katz & Ward Standards Track [Page 40] RFC 5880 Bidirectional Forwarding Detection June 2010 6.8.15. Forwarding Plane Reset
6.8.15。 転送プレーンのリセット
When the forwarding plane in the local system is reset for some reason, such that the remote system can no longer rely on the local forwarding state, the local system MUST set bfd.LocalDiag to 4 (Forwarding Plane Reset), and set bfd.SessionState to Down.
ローカルシステムの転送プレーンが何らかの理由でリセットされ、リモートシステムがローカル転送状態に依存できなくなった場合、ローカルシステムはbfd.LocalDiagを4（転送プレーンリセット）に設定し、bfd.SessionStateを設定する必要があります。 ダウンへ。
6.8.16. Administrative Control
6.8.16。 管理コントロール
There may be circumstances where it is desirable to administratively enable or disable a BFD session. When this is desired, the following procedure MUST be followed:
BFDセッションを管理上有効または無効にすることが望ましい場合があります。 これが必要な場合は、次の手順に従う必要があります。
If enabling session
Set bfd.SessionState to Down
Else
Set bfd.SessionState to AdminDown
Set bfd.LocalDiag to an appropriate value
Cease the transmission of BFD Echo packets
If signaling is received from outside BFD that the underlying path
has failed, an implementation MAY administratively disable the
session with the diagnostic Path Down.
基礎となるパスに障害が発生したというシグナリングがBFDの外部から受信された場合、実装は、診断パスがダウンしているセッションを管理上無効化できます。
Other scenarios MAY use the diagnostic Administratively Down.
他のシナリオでは、Diagnosticsly Downの診断を使用できます。
BFD Control packets SHOULD be transmitted for at least a Detection Time after transitioning to AdminDown state in order to ensure that the remote system is aware of the state change. BFD Control packets MAY be transmitted indefinitely after transitioning to AdminDown state in order to maintain session state in each system (see section 6.8.18 below).
リモートシステムが状態の変化を認識していることを確認するために、AdminDown状態に移行した後、BFD制御パケットを少なくとも検出時間の間送信する必要があります。 各システムでセッション状態を維持するために、AdminDown状態に移行した後、BFD制御パケットを無期限に送信できます（下記のセクション6.8.18を参照）。
6.8.17. Concatenated Paths
6.8.17。 連結パス
If the path being monitored by BFD is concatenated with other paths (connected end-to-end in series), it may be desirable to propagate the indication of a failure of one of those paths across the BFD session (providing an interworking function for liveness monitoring between BFD and other technologies).
BFDによって監視されているパスが他のパスと連結されている（エンドツーエンドで直列に接続されている）場合、それらのパスの1つの障害の表示をBFDセッション全体に伝搬することが望ましい場合があります（活性のためにインターワーキング機能を提供） BFDと他のテクノロジー間のモニタリング）。
Two diagnostic codes are defined for this purpose: Concatenated Path Down and Reverse Concatenated Path Down. The first propagates forward path failures (in which the concatenated path fails in the direction toward the interworking system), and the second propagates Katz & Ward Standards Track [Page 41] RFC 5880 Bidirectional Forwarding Detection June 2010 reverse path failures (in which the concatenated path fails in the direction away from the interworking system, assuming a bidirectional link).
この目的で2つの診断コードが定義されています。連結パスダウンと逆連結パスダウンです。 1つ目はフォワードパスの障害を伝搬し（連結パスがインターワーキングシステムに向かう方向に失敗する）、2つ目はリバースパスの障害を伝搬します（連結パスがインターワーキングシステムから離れる方向に失敗し、双方向リンクであると想定します）。 。
A system MAY signal one of these failure states by simply setting bfd.LocalDiag to the appropriate diagnostic code. Note that the BFD session is not taken down. If Demand mode is not active on the remote system, no other action is necessary, as the diagnostic code will be carried via the periodic transmission of BFD Control packets. If Demand mode is active on the remote system (the local system is not transmitting periodic BFD Control packets), a Poll Sequence MUST be initiated to ensure that the diagnostic code is transmitted. Note that if the BFD session subsequently fails, the diagnostic code will be overwritten with a code detailing the cause of the failure. It is up to the interworking agent to perform the above procedure again, once the BFD session reaches Up state, if the propagation of the concatenated path failure is to resume.
システムは、bfd.LocalDiagを適切な診断コードに設定するだけで、これらの障害状態の1つを通知できます（MAY）。 BFDセッションは停止されないことに注意してください。 リモートシステムでデマンドモードがアクティブでない場合、診断コードはBFD制御パケットの定期的な送信を介して送信されるため、他のアクションは必要ありません。 リモートシステムでデマンドモードがアクティブな場合（ローカルシステムが定期的なBFD制御パケットを送信していない場合）、診断コードが確実に送信されるように、ポーリングシーケンスを開始する必要があります。 その後BFDセッションが失敗すると、診断コードは失敗の原因を詳述するコードで上書きされることに注意してください。 連結パス障害の伝播が再開する場合、BFDセッションがUp状態に到達すると、上記の手順を再度実行するのはインターワーキングエージェント次第です。
6.8.18. Holding Down Sessions
6.8.18。 セッションを押し続ける
A system MAY choose to prevent a BFD session from being established. One possible reason might be to manage the rate at which sessions are established. This can be done by holding the session in Down or AdminDown state, as appropriate.
システムは、BFDセッションが確立されないようにすることを選択できます。 考えられる理由の1つは、セッションが確立されるレートを管理することです。 これは、必要に応じて、セッションをDownまたはAdminDown状態に保持することで実行できます。
There are two related mechanisms that are available to help with this task. First, a system is REQUIRED to maintain session state (including timing parameters), even when a session is down, until a Detection Time has passed without the receipt of any BFD Control packets. This means that a system may take down a session and transmit an arbitrarily large value in the Required Min RX Interval field to control the rate at which it receives packets.
このタスクを支援するために利用できる2つの関連するメカニズムがあります。 まず、システムは、セッションがダウンしている場合でも、BFD制御パケットを受信せずに検出時間が経過するまで、セッション状態（タイミングパラメーターを含む）を維持する必要があります。 これは、システムがセッションを停止し、必要な最小RX間隔フィールドで任意の大きな値を送信して、パケットを受信するレートを制御する可能性があることを意味します。
Additionally, a system MAY transmit a value of zero for Required Min RX Interval to indicate that the remote system should send no packets whatsoever.
さらに、システムは必要な最小RX間隔にゼロの値を送信して、リモートシステムがパケットを送信しないようにする必要があります。
So long as the local system continues to transmit BFD Control packets, the remote system is obligated to obey the value carried in Required Min RX Interval. If the remote system does not receive any BFD Control packets for a Detection Time, it SHOULD reset bfd.RemoteMinRxInterval to its initial value of 1 (per section 6.8.1, since it is no longer required to maintain previous session state) and then can transmit at its own rate.
ローカルシステムがBFD制御パケットを送信し続ける限り、リモートシステムは必須最小RX間隔で伝送される値に従う義務があります。 リモートシステムが検出時間の間BFD制御パケットを受信しない場合、bfd.RemoteMinRxIntervalを初期値1にリセットする必要があります（セクション6.8.1に従って、以前のセッション状態を維持する必要がなくなったため）。 独自のレートで送信します。
Katz & Ward Standards Track [Page 42] RFC 5880 Bidirectional Forwarding Detection June 2010 7. Operational Considerations
7.運用上の考慮事項
BFD is likely to be deployed as a critical part of network infrastructure. As such, care should be taken to avoid disruption.
BFDは、ネットワークインフラストラクチャの重要な部分として展開される可能性があります。 したがって、混乱を避けるために注意が必要です。
Obviously, any mechanism that blocks BFD packets, such as firewalls or other policy processes, will cause BFD to fail.
明らかに、ファイアウォールや他のポリシープロセスなど、BFDパケットをブロックするメカニズムは、BFDの失敗の原因になります。
Mechanisms that control packet scheduling, such as policers, traffic shapers, priority queueing, etc., have the potential of impacting BFD operations if the Detection Time is similar in scale to the scheduled packet transmit or receive rate. The delivery of BFD packets is time-critical, relative to the magnitude of the Detection Time, so this may need to be taken into account in implementation and deployment, particularly when very short Detection Times are to be used.
ポリサー、トラフィックシェーパー、プライオリティキューイングなどのパケットスケジューリングを制御するメカニズムは、検出時間のスケールがスケジュールされたパケットの送信または受信レートと同じである場合、BFD操作に影響を与える可能性があります。 BFDパケットの配信は、検出時間の大きさに対して時間的に重要であるため、特に非常に短い検出時間を使用する場合は、実装と展開でこれを考慮する必要がある場合があります。
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 is outside the scope of this specification, and the requirements of this mechanism may differ depending on how BFD is deployed, and how it interacts with other parts of the system (for example, exponential backoff may not be appropriate in cases where routing protocols are interacting closely with BFD).
BFDが複数のホップで使用される場合、輻輳制御メカニズムを実装する必要があり、輻輳が検出された場合、BFD実装は生成するトラフィックの量を削減する必要があります。 使用される正確なメカニズムはこの仕様の範囲外であり、このメカニズムの要件は、BFDの展開方法、およびシステムの他の部分との相互作用方法によって異なる場合があります（たとえば、指数バックオフは、 ルーティングプロトコルはBFDと密接に相互作用しています）。
Note that "congestion" is not only a traffic phenomenon, but also a computational one. It is possible for systems with a large number of BFD sessions and/or very short packet intervals to become CPU-bound. As such, a congestion control algorithm SHOULD be used even across single hops in order to avoid the possibility of catastrophic system collapse, as such failures have been seen repeatedly in other periodic Hello-based protocols.
「輻輳」は交通現象だけでなく、計算上の現象でもあることに注意してください。 多数のBFDセッションや非常に短いパケット間隔を持つシステムがCPUバウンドになる可能性があります。 したがって、他の定期的なHelloベースのプロトコルでこのような障害が繰り返し見られるため、壊滅的なシステムの崩壊の可能性を回避するために、輻輳制御アルゴリズムはシングルホップでも使用する必要があります（SHOULD）。
The mechanisms for detecting congestion are outside the scope of this specification, but may include the detection of lost BFD Control packets (by virtue of holes in the authentication sequence number space, or by BFD session failure) or other means.
輻輳を検出するメカニズムはこの仕様の範囲外ですが、（認証シーケンス番号スペースのホールによる、またはBFDセッションの失敗による）失われたBFD制御パケットの検出または他の手段が含まれる場合があります。
The mechanisms for reducing BFD's traffic load are the control of the local and remote packet transmission rate via the Min RX Interval and Min TX Interval fields.
BFDのトラフィック負荷を軽減するメカニズムは、Min RX IntervalフィールドとMin TX Intervalフィールドを介したローカルおよびリモートのパケット送信レートの制御です。
Note that any mechanism that increases the transmit or receive intervals will increase the Detection Time for the session.
送信または受信の間隔を長くするメカニズムを使用すると、セッションの検出時間が長くなることに注意してください。
Katz & Ward Standards Track [Page 43] RFC 5880 Bidirectional Forwarding Detection June 2010 It is worth noting that a single BFD session does not consume a large amount of bandwidth. An aggressive session that achieves a detection time of 50 milliseconds, by using a transmit interval of 16.7 milliseconds and a detect multiplier of 3, will generate 60 packets per second. The maximum length of each packet on the wire is on the order of 100 bytes, for a total of around 48 kilobits per second of bandwidth consumption in each direction.
単一のBFDセッションが大量の帯域幅を消費しないことは注目に値します。 16.7ミリ秒の送信間隔と3の検出乗数を使用して50ミリ秒の検出時間を達成するアグレッシブセッションは、1秒あたり60パケットを生成します。 ワイヤ上の各パケットの最大長は100バイトのオーダーであり、各方向で合計で約48キロビット/秒の帯域幅が消費されます。
8. IANA Considerations
8. IANAに関する考慮事項
This document defines two registries administered by IANA. The first is titled "BFD Diagnostic Codes" (see section 4.1). Initial values for the BFD Diagnostic Code registry are given below. Further assignments are to be made through Expert Review [IANA-CONSIDERATIONS]. Assignments consist of a BFD Diagnostic Code name and its associated value.
このドキュメントでは、IANAが管理する2つのレジストリを定義しています。 最初のタイトルは「BFD診断コード」です（セクション4.1を参照）。 BFD診断コードレジストリの初期値を以下に示します。 エキスパートレビュー[IANA-CONSIDERATIONS]を通じて、さらに割り当てが行われます。 割り当ては、BFD診断コード名とそれに関連付けられた値で構成されます。
Value BFD Diagnostic Code Name
----- ------------------------
0 No Diagnostic
1 Control Detection Time Expired
2 Echo Function Failed
3 Neighbor Signaled Session Down
4 Forwarding Plane Reset
5 Path Down
6 Concatenated Path Down
7 Administratively Down
8 Reverse Concatenated Path Down
9-31 Unassigned
値 BFD診断コード名
----- ------------------------
0 診断なし
1 期限切れのコントロール検出時間
2 エコー機能が失敗しました
3 ネイバーシグナリングセッションダウン
4 転送プレーンのリセット
5 パスダウン
6 連結パスダウン
7 管理上ダウン
8 逆連結パスダウン
9-31 未割り当て
The second registry is titled "BFD Authentication Types" (see section 4.1). Initial values for the BFD Authentication Type registry are given below. Further assignments are to be made through Expert Review [IANA-CONSIDERATIONS]. Assignments consist of a BFD Authentication Type Code name and its associated value.
2番目のレジストリのタイトルは「BFD認証タイプ」です（セクション4.1を参照）。 BFD認証タイプレジストリの初期値を以下に示します。 エキスパートレビュー[IANA-CONSIDERATIONS]を通じて、さらに割り当てが行われます。 割り当ては、BFD認証タイプコード名とそれに関連付けられた値で構成されます。
Value BFD Authentication Type Name
----- ----------------------------
0 Reserved
1 Simple Password
2 Keyed MD5
3 Meticulous Keyed MD5
4 Keyed SHA1
5 Meticulous Keyed SHA1
6-255 Unassigned
値 BFD認証タイプ名
----- ----------------------------
0 予約済み
1 単純なパスワード
2 キー付きMD5
3 綿密なキー付きMD5
4 キー付きSHA1
5 綿密なキー付きSHA1
6-255 Unassigned
Katz & Ward Standards Track [Page 44] RFC 5880 Bidirectional Forwarding Detection June 2010 9. Security Considerations
9.セキュリティに関する考慮事項
As BFD may be tied into the stability of the network infrastructure (such as routing protocols), the effects of an attack on a BFD session may be very serious: a link may be falsely declared to be down, or falsely declared to be up; in either case, the effect is denial of service.
BFDはネットワークインフラストラクチャ（ルーティングプロトコルなど）の安定性に結び付けられている可能性があるため、BFDセッションへの攻撃の影響は非常に深刻である可能性があります。 どちらの場合も、結果はサービス拒否です。
An attacker who is in complete control of the link between the systems can easily drop all BFD packets but forward everything else (causing the link to be falsely declared down), or forward only the BFD packets but nothing else (causing the link to be falsely declared up). This attack cannot be prevented by BFD.
システム間のリンクを完全に制御している攻撃者は、すべてのBFDパケットを簡単にドロップして他のすべてを転送する（リンクが誤ってダウンしていると宣言される）か、BFDパケットのみを転送し、それ以外は何も転送しない（リンクが誤っている） 宣言された）。 この攻撃はBFDで防止できません。
To mitigate threats from less capable attackers, BFD specifies two mechanisms to prevent spoofing of BFD Control packets. The Generalized TTL Security Mechanism [GTSM] uses the time to live (TTL) or Hop Count to prevent off-link attackers from spoofing packets. The Authentication Section authenticates the BFD Control packets. These mechanisms are described in more detail below.
能力の低い攻撃者からの脅威を軽減するために、BFDはBFD制御パケットのスプーフィングを防止する2つのメカニズムを指定しています。 一般化されたTTLセキュリティメカニズム[GTSM]は、存続時間（TTL）またはホップカウントを使用して、オフリンク攻撃者がパケットをスプーフィングするのを防ぎます。 認証セクションは、BFD制御パケットを認証します。 これらのメカニズムについては、以下で詳しく説明します。
When a BFD session is directly connected across a single link (physical, or a secure tunnel such as IPsec), the TTL or Hop Count MUST be set to the maximum on transmit, and checked to be equal to the maximum value on reception (and the packet dropped if this is not the case). See [GTSM] for more information on this technique. If BFD is run across multiple hops or an insecure tunnel (such as Generic Routing Encapsulation (GRE)), the Authentication Section SHOULD be utilized.
BFDセッションが単一のリンク（物理、またはIPsecなどの安全なトンネル）を介して直接接続されている場合、TTLまたはホップカウントは送信時に最大値に設定され、受信時に最大値と等しいことを確認する必要があります（および そうでない場合、パケットはドロップされます）。 この手法の詳細については、[GTSM]を参照してください。 BFDが複数のホップまたは安全でないトンネル（Generic Routing Encapsulation（GRE）など）で実行されている場合は、認証セクションを使用する必要があります（SHOULD）。
The level of security provided by the Authentication Section varies based on the authentication type used. Simple Password authentication is obviously only as secure as the secrecy of the passwords used, and should be considered only if the BFD session is guaranteed to be run over an infrastructure not subject to packet interception. Its chief advantage is that it minimizes the computational effort required for authentication.
認証セクションによって提供されるセキュリティのレベルは、使用される認証タイプによって異なります。 単純なパスワード認証は、使用されるパスワードの機密性と同じくらい安全であることは明らかであり、BFDセッションがパケット傍受の影響を受けないインフラストラクチャ上で実行されることが保証されている場合にのみ検討する必要があります。 その主な利点は、認証に必要な計算の労力を最小限に抑えることです。
Keyed MD5 Authentication is much stronger than Simple Password Authentication since the keys cannot be discerned by intercepting packets. It is vulnerable to replay attacks in between increments of the sequence number. The sequence number can be incremented as seldom (or as often) as desired, trading off resistance to replay attacks with the computational effort required for authentication.
キー付きMD5認証は、パケットを傍受してもキーを識別できないため、シンプルパスワード認証よりもはるかに強力です。 シーケンス番号の増分の間で攻撃をリプレイすることに対して脆弱です。 シーケンス番号は、めったに（または頻繁に）必要に応じて増やすことができ、認証に必要な計算労力でリプレイ攻撃への抵抗をトレードオフします。
Meticulous Keyed MD5 authentication is stronger yet, as it requires the sequence number to be incremented for every packet. Replay attack vulnerability is reduced due to the requirement that the Katz & Ward Standards Track [Page 45] RFC 5880 Bidirectional Forwarding Detection June 2010 sequence number must be incremented on every packet, the window size of acceptable packets is small, and the initial sequence number is randomized. There is still a window of attack at the beginning of the session while the sequence number is being determined. This authentication scheme requires an MD5 calculation on every packet transmitted and received.
パケットごとにシーケンス番号をインクリメントする必要があるため、細心の注意を払ったキー付きMD5認証はさらに強力です。 リプレイ攻撃の脆弱性は、すべてのパケットでシーケンス番号をインクリメントする必要があり、許容可能なパケットのウィンドウサイズが小さく、初期シーケンス番号がランダム化されるため、軽減されます。 シーケンス番号が決定されている間、セッションの開始時にまだ攻撃のウィンドウがあります。 この認証方式では、送受信されるすべてのパケットでMD5計算が必要です。
Using SHA1 is believed to have stronger security properties than MD5. All comments about MD5 in this section also apply to SHA1.
SHA1の使用には、MD5よりも強力なセキュリティプロパティがあると考えられています。 このセクションのMD5に関するすべてのコメントは、SHA1にも適用されます。
Both Keyed MD5/SHA1 and Meticulous Keyed MD5/SHA1 use the "secret suffix" construction (also called "append only") in which the shared secret key is appended to the data before calculating the hash, instead of the more common Hashed Message Authentication Code (HMAC) construction [HMAC]. This construction is believed to be appropriate for BFD, but designers of any additional authentication mechanisms for BFD are encouraged to read [HMAC] and its references.
Keyed MD5 / SHA1とMeticulous Keyed MD5 / SHA1はどちらも「シークレットサフィックス」構造（「追加のみ」とも呼ばれます）を使用し、一般的なハッシュメッセージ認証ではなく、共有シークレットキーがハッシュを計算する前にデータに追加されます。 コード（HMAC）構築[HMAC]。 この構成はBFDに適していると考えられていますが、BFDの追加の認証メカニズムの設計者は、[HMAC]とそのリファレンスを読むことをお勧めします。
If both systems randomize their Local Discriminator values at the beginning of a session, replay attacks may be further mitigated, regardless of the authentication type in use. Since the Local Discriminator may be changed at any time during a session, this mechanism may also help mitigate attacks.
両方のシステムがセッションの開始時にLocal Discriminator値をランダム化すると、使用中の認証タイプに関係なく、リプレイ攻撃がさらに軽減される可能性があります。 ローカルディスクリミネーターはセッション中いつでも変更できるため、このメカニズムは攻撃の緩和にも役立ちます。
The security implications of the use of BFD Echo packets are dependent on how those packets are defined, since their structure is local to the transmitting system and outside the scope of this specification. However, since Echo packets are defined and processed only by the transmitting system, the use of cryptographic authentication does not guarantee that the other system is actually alive; an attacker could loop the Echo packets back (without knowing any secret keys) and cause the link to be falsely declared to be up. This can be mitigated by using a suitable interval for BFD Control packets. [GTSM] could be applied to BFD Echo packets, though the TTL/Hop Count will be decremented by 1 in the course of echoing the packet, so spoofing is possible from one hop away.
BFDエコーパケットの使用によるセキュリティへの影響は、それらのパケットの構造が送信システムにローカルであり、この仕様の範囲外であるため、それらのパケットの定義方法に依存します。 ただし、エコーパケットは送信システムでのみ定義および処理されるため、暗号化認証を使用しても、他のシステムが実際に動作していることは保証されません。 攻撃者は（秘密鍵を知らなくても）Echoパケットをループバックして、リンクがアップしていると誤って宣言する可能性があります。 これは、BFD制御パケットに適切な間隔を使用することで軽減できます。 [GTSM]はBFDエコーパケットに適用できますが、パケットをエコーする過程でTTL /ホップカウントが1ずつ減るため、1ホップ先からスプーフィングが可能になります。
10. References
10.リファレンス
10.1. Normative References
10.1 規範的な参考文献
[GTSM] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Katz & Ward Standards Track [Page 46]
RFC 5880 Bidirectional Forwarding Detection June 2010
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[SHA1] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001.
10.2. Informative References
10.2 参考情報
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[IANA-CONSIDERATIONS]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
Katz & Ward Standards Track [Page 47]
RFC 5880 Bidirectional Forwarding Detection June 2010
Appendix A. Backward Compatibility (Non-Normative)
付録A.下位互換性（非規定）
Although version 0 of this protocol (as defined in early versions of the Internet-Draft that became this RFC) is unlikely to have been deployed widely, some implementors may wish to have a backward compatibility mechanism. Note that any mechanism may be potentially used that does not alter the protocol definition, so interoperability should not be an issue.
このプロトコルのバージョン0（このRFCとなったInternet-Draftの初期バージョンで定義されている）は広く展開されている可能性は低いですが、一部の実装者は下位互換性メカニズムを必要とする場合があります。 プロトコル定義を変更しないメカニズムが使用される可能性があるため、相互運用性は問題になりません。
The suggested mechanism described here has the property that it will converge on version 1 if both systems implement it, even if one system is upgraded from version 0 within a Detection Time. It will interoperate with a system that implements only one version (or is configured to support only one version). A system should obviously not perform this function if it is configured to or is only capable of using a single version.
ここで説明する推奨メカニズムには、一方のシステムが検出時間内にバージョン0からアップグレードされた場合でも、両方のシステムが実装する場合、バージョン1に収束するという特性があります。 1つのバージョンのみを実装する（または1つのバージョンのみをサポートするように構成されている）システムと相互運用します。 システムが単一のバージョンを使用するように構成されているか、それを使用できる場合は、明らかにこの機能を実行しないでください。
A BFD session will enter a "negotiation holddown" if it is configured for automatic versioning and either has just started up, or the session has been manually cleared. The session is set to AdminDown state and version 1. During the holddown period, which lasts for one Detection Time, the system sends BFD Control packets as usual, but ignores received packets. After the holddown time is complete, the state transitions to Down and normal operation resumes.
BFDセッションは、自動バージョン管理用に設定されていて、起動直後か、セッションが手動でクリアされている場合、「ネゴシエーションホールドダウン」に入ります。 セッションはAdminDown状態およびバージョン1に設定されています。 1検出時間続くホールドダウン期間中、システムは通常どおりBFD制御パケットを送信しますが、受信したパケットは無視します。 ホールドダウン時間が完了すると、状態はDownに遷移し、通常の動作が再開されます。
When a system is not in holddown, if it doing automatic versioning and is currently using version 1, if any version 0 packet is received for the session, it switches immediately to version 0. If it is currently using version 0 and a version 1 packet is received that indicates that the neighbor is in state AdminDown, it switches to version 1. If using version 0 and a version 1 packet is received indicating a state other than AdminDown, the packet is ignored (per spec).
システムがホールドダウン状態にないときに、自動バージョン管理を行っており、現在バージョン1を使用している場合、セッションでバージョン0パケットを受信すると、すぐにバージョン0に切り替わります。 現在バージョン0を使用していて、ネイバーがAdminDown状態であることを示すバージョン1パケットを受信した場合、バージョン1に切り替えます。 バージョン0とバージョン1のパケットを受信して、AdminDown以外の状態を示している場合、そのパケットは無視されます（仕様どおり）。
If the version being used is changed, the session goes down as appropriate for the new version (Down state for version 1 or Failing state for version 0).
使用されているバージョンが変更されると、セッションは新しいバージョンに応じてダウンします（バージョン1のダウン状態またはバージョン0の障害状態）。
Appendix B. Contributors
付録B.貢献者
Kireeti Kompella and Yakov Rekhter of Juniper Networks were also significant contributors to this document.
ジュニパーネットワークスのKireeti KompellaとYakov Rekhterも、このドキュメントに大きく貢献しました。
Katz & Ward Standards Track [Page 48] RFC 5880 Bidirectional Forwarding Detection June 2010 Appendix C. Acknowledgments
付録C.謝辞
This document was inspired by (and is intended to replace) the Protocol Liveness Protocol document, written by Kireeti Kompella.
この文書は、Kireeti Kompellaによって書かれたProtocol Liveness Protocol文書に触発された（そしてそれを置き換えることを目的としています）。
Demand mode was inspired by "A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers", by G. Huang, et al.
デマンドモードは、Gによる「死んだインターネットキーエクスチェンジ（IKE）ピアを検出するトラフィックベースの方法」に触発されました。 Huang、et al。
The authors would also like to thank Mike Shand, John Scudder, Stewart Bryant, Pekka Savola, Richard Spencer, and Pasi Eronen for their substantive input.
著者はまた、マイク・シャンド、ジョン・スカダー、スチュワート・ブライアント、ペッカ・サヴォラ、リチャード・スペンサー、パシ・エロネンに実質的な情報を提供してくれたことに感謝したいと思います。
The authors would also like to thank Owen Wheeler for hosting teleconferences between the authors of this specification and multiple vendors in order address implementation and clarity issues.
また、実装と明確さの問題に対処するために、この仕様の作成者と複数のベンダー間の電話会議を主催してくれたOwen Wheelerにも感謝します。
Authors' Addresses Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089-1206 USA Phone: +1-408-745-2000 EMail: dkatz@juniper.net Dave Ward Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089-1206 USA Phone: +1-408-745-2000 EMail: dward@juniper.net Katz & Ward Standards Track [Page 49]