[要約] RFC 5880は、ネットワークデバイス間のリンク状態を監視するためのBFDプロトコルに関する仕様です。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.
これは、インターネット標準トラックドキュメントです。
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）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
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
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
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.
ネットワークは、通常はルーティングプロトコルで比較的遅い「ハロー」メカニズムを使用して、ハードウェアシグナリングがない場合に障害を検出します。既存のプロトコルで利用可能な障害（「検出時間」）を検出する時間は、1秒よりも優れています。さらに、ルーティングプロトコルHELLOSは、それらのルーティングプロトコルが使用されていない場合は役に立たず、検出のセマンティクスは微妙に異なります。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.
このドキュメントは、ベースプロトコルの詳細を指定します。一部のメカニズムの使用はアプリケーションに依存し、別の一連のアプリケーションドキュメントで指定されています。これらの問題は非常に注目されています。
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.
正確なメカニズムの多くは実装に依存しており、相互運用性に影響を与えないため、この仕様の範囲外であることに注意してください。これらの問題は非常に注意されています。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [キーワード]に記載されているように解釈されます。
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つの方向に複数のパスが存在する場合、同じペアのシステム間で確立できます。。
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方向の握手を実装します。
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セッションがいつ上下するかを示すクライアントに信号を提供します。
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は、多くの点で、よく知られているルーティングプロトコルの検出コンポーネントに似ているシンプルなハロープロトコルです。一対のシステムは、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パケットを送信および受信できる速さを推定します。これらの推定値は、異常な状況に適応するためにリアルタイムで変更できます。また、この設計により、遅いシステムを備えた共有メディア上の高速システムが、高速システム間の障害をより迅速に検出できるようにしながら、遅いシステムがその能力を最大限に活用できるようにすることができます。
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 Protocolを使用して発見された隣人にBFDセッションを確立するように要求する場合があります。
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つのモードと組み合わせて使用できる追加関数があります。
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制御パケットの送信を停止するように他のシステムに求める場合があります。遠いシステムのQuiesces。需要モードは、それぞれの方向、または同時に独立して動作する場合があります。
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エコーパケットのストリームは、他のシステムを転送パスに戻すような方法で送信されます。エコーされたデータストリームの多くのパケットが受信されない場合、セッションはダウンしていると宣言されます。エコー関数は、非同期モードまたは需要モードで使用できます。エコー関数は検出タスクを処理しているため、制御パケットの周期的な伝送速度（非同期モードの場合）が完全に排除されるか（需要モードの場合）、完全に排除される場合があります。
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 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を参照してください。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version (Vers)
バージョン（バージョン）
The version number of the protocol. This document defines protocol version 1.
プロトコルのバージョン番号。このドキュメントは、プロトコルバージョン1を定義しています。
Diagnostic (Diag)
診断（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ダウン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 -ASMINDOWN1 -DOWN 2 -INIT 3- UP UP
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制御パケットに応答しています。明確な場合、送信システムは世論調査に応答していません。
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セッションを非難するために使用される、送信システムによって生成される一意の非ゼロ差別値値。
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.
対応するリモートシステムから受け取った判別器。このフィールドは、私の差別装置の受信価値を反映しているか、その値が不明な場合はゼロです。
Desired Min TX Interval
望ましいMIN 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を参照）。値ゼロは予約されています。
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
必要なmin echo 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.
存在する認証（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タイプとAUTH LENフィールドを含みます。
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:
存在する認証（a）ビットがヘッダーに設定され、認証タイプフィールドに1（簡単なパスワード）が含まれている場合、認証セクションには次の形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Password... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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に従ってエンコードして構成する必要があります。
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:
存在する認証（a）ビットがヘッダーに設定され、認証タイプフィールドが2（キー付きMD5）または3（細心のキー付きMD5）が含まれている場合、認証セクションには次の形式があります。
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... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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および細心のキー付き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認証の場合、この値は時々増加します。細心のキー付きMD5認証の場合、この値は、セッションに送信される連続したパケットごとに増加します。これにより、リプレイ攻撃に対する保護が提供されます。
Auth Key/Digest
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キーがこのフィールドに保存され、必要に応じてゼロバイトを縮小して16バイトにパッドで埋めます。共有キーをエンコードし、セクション6.7.3に構成する必要があります。
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:
存在する認証（a）ビットがヘッダーに設定され、認証タイプフィールドに4（キー付きSHA1）または5（細心のキー付きSHA1）が含まれている場合、認証セクションには次の形式があります。
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... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Type
認証タイプ
The Authentication Type, which in this case is 4 (Keyed SHA1) or 5 (Meticulous Keyed SHA1).
この場合、4（キー付きSHA1）または5（細心のキー付きSHA1）である認証タイプ。
Auth Len
認証レン
The length of the Authentication Section, in bytes. For Keyed SHA1 and Meticulous Keyed SHA1 authentication, the length is 28.
バイト単位の認証セクションの長さ。キー付きSHA1と細心のキー付き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認証の場合、この値は時々増加します。細心のキー付きSHA1認証の場合、この値は、セッションに送信される連続したパケットごとに増加します。これにより、リプレイ攻撃に対する保護が提供されます。
Auth Key/Hash
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キーがこのフィールドに保存され、必要に応じてゼロバイトが縮を縮小して20バイトの長さにパッドで埋められます。共有キーをエンコードし、セクション6.7.4に構成する必要があります。
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.
エコーパケットがスプーフィングされる可能性があるため、何らかの形の認証を含める必要があります。
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で定義）。
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パケットの送信を開始してはなりません。少なくとも1つのシステムがアクティブな役割を担う必要があります（おそらく両方）。システムが実行する役割は、BFDの適用に固有であり、この仕様の範囲外です。
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を参照）、セッションは宣言されます。これは、発信パケットの状態（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.
セッションが宣言されると、リモートエンドが最初のシグナルがダウン（UP状態を離れることで）を最初に信号するまで戻ることができず、3方向の握手を実装します。
A session MAY be kept administratively down by entering the AdminDown state and sending an explanatory diagnostic code in the Diagnostic field.
セッションは、許可された状態に入り、診断分野で説明診断コードを送信することにより、管理上停止することができます。
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 and up）を確立するための2つと、1つはセッションを取り壊す（ダウン）。これにより、セッションの確立とセッションの分解の両方に3方向の握手が可能になります（両方のシステムがすべてのセッション状態の変更を認識していることを保証します）。セッションを無期限に倒すことができるように、第4状態（承認者）が存在します。
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.
ダウンステートとは、セッションがダウンしている（または作成されたばかり）ことを意味します。セッションは、リモートシステムが、UP以外に設定された状態フィールドにBFDコントロールパケットを送信することにより、セッションがダウンしていることに同意することを示すまで、ダウンステートに残ります。そのパケットが状態を下回る場合、セッションはinit状態に進みます。そのパケットがinit状態を示す場合、セッションはUP状態に進みます。意味的には、ダウン状態は、転送パスが利用できないことを示しており、BFDセッションの状態を監視するアプリケーションによって適切なアクションを実行する必要があることを示しています。システムは、Down Stateのセッションを無期限に保持する場合があります（単にセッション状態を前進させることを拒否します）。これは、とりわけ、運用上または管理上の理由で行うことができます。
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状態とは、リモートシステムが通信していることを意味し、ローカルシステムはセッションを持ち上げることを望んでいますが、リモートシステムはまだ実現していません。セッションは、Signaling InitまたはUp State（この場合はセッションが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.
Up Stateは、BFDセッションが正常に確立されたことを意味し、システム間の接続性が機能していることを意味します。セッションは、接続性が失敗するか、セッションが行政上に削除されるまで、UP状態のままになります。リモートシステムが状態を下回るか、検出時間が期限切れになった場合、セッションはダウン状態に進みます。
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 Stateは、転送パスの可用性に意味的な意味を持ちません。
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.
次の図は、状態マシンの概要を示します。許可された状態を含む遷移は、明確にするために削除されます（ただし、セクション6.8.6および6.8.16で完全に指定されています）。各ARCの表記は、リモートシステムの状態（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 | |<---+
+------+ +------+
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.
複数のBFDセッションが2つのシステム間で実行されている可能性があるため、受信した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差別装置フィールドに送信され、リモートエンドから送信されたパケットの識別子フィールドに反映されます。
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).
リモートエンドがローカルな判別器をエコーすると、すべての受信パケットは、差別器フィールドのみに基づいて再脱直になります（とりわけ、ソースアドレスフィールドが変更される可能性があるか、パケットが受信されるインターフェイスが変更される可能性があります。しかし、パケットはまだ適切なセッションに関連付けられます）。
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.
初期パケット（識別子がゼロである）を非難する方法はアプリケーションに依存するため、この仕様の範囲外です。
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.
セッション状態に影響を与えることなく、セッション中にシステムが識別器を変更することは許可されていることに注意してください。なぜなら、そのシステムのみが、他のシステムにそれを反映させることにより）のためにその識別器を使用しているからです。判別器の値を変更するための実装に対する意味は、この仕様の範囲外です。
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).
システムがエコー関数を使用している場合、エコーパケットによって責任検出が処理されているため、制御パケットの鎮静レート率を選択することが有利です。これは、必要なMIN 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.
それ以外の場合は、システムは、必要なMin RX間隔の最低値を宣伝する必要があり、その状況下で可能な最小エコーRX間隔を宣伝し、他のシステムに送信速度を選択する自由度を高めます。システムは、広告レートで両方のパケットのストリームを受信できるようになっているため、広告する値を選択するときに考慮する必要があることに注意してください。
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を参照）。投票シーケンスを送信するシステムが最終的なパケットを受信すると、ポーリングシーケンスが終了し、後続のBFDコントロールパケットが投票ビットをクリアした状態で送信されます。BFDコントロールパケットには、投票（P）と最終（F）ビットセットの両方が必要です。
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）を設定することにより、投票シーケンスを実行する必要があります。追加のパケットを送信しないでください。
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.
通常、シーケンス全体は各方向の単一のパケットで構成されていますが、パケットの損失または比較的長いパケットレイテンシーにより、シーケンスが終了する前に複数の投票パケットが送信される場合があります。
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つは、エコー関数の使用です。
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.
需要モードがいずれかまたは両方のシステムでアクティブである場合、投票（P）とPERTを除き、次のBFDコントロールパケットの内容が以前のパケットの内容とは異なる場合、投票シーケンスを開始する必要があります。最終（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つのシステム間で異なる可能性があるため、パスの全体的な検出時間特性はどちらのシステムでも完全にはわかっていません。特定のシステムの合計検出時間は、投票シーケンスの開始前の時間と計算された検出時間の合計です。
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つの方向のみで有効になっている場合、連続的な双方向接続検証が失われることに注意してください（需要モードから他のシステムへのシステムからの方向の接続のみが検証されます）。需要モードを要求する1つのシステムの問題を解決する一方、もう1つのシステムでは、継続的な双方向の接続性の検証がこの仕様の範囲外である必要があります。
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コントロールパケットに存在する場合があります。その一般的な形式では、認証セクションの目的は、使用中の認証タイプに基づいて必要なすべての情報を運ぶことであり、受信システムが受信パケットの有効性を決定できるようにすることです。正確なメカニズムは使用中の認証タイプに依存しますが、一般に送信システムは認証に情報を配置します
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認証をサポートする必要があります。他の形式の認証はオプションです。
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 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制御パケットの受領に基づいて認証状態を変更することはできません。
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タイプフィールドは1（簡単なパスワード）に設定する必要があります。認証レンフィールドは、適切な長さ（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文字列を受け入れる必要があり、また、16進形式の任意のバイナリ文字列の構成を許可する必要があります。他の構成方法がサポートされる場合があります。
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と一致しない場合、受信したパケットを破棄する必要があります。
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で選択されたパスワードの長さに等しくない場合は、パケットを破棄する必要があります。
If the Password field does not match the password selected by the key ID, the packet MUST be discarded.
パスワードフィールドがキーIDで選択されたパスワードと一致しない場合、パケットを破棄する必要があります。
Otherwise, the packet MUST be accepted.
それ以外の場合、パケットを受け入れる必要があります。
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および細心のキー付きMD5認証メカニズムは、他のプロトコルで使用されているメカニズムと非常に似ています。これらの認証方法では、各システムで1つ以上の秘密キー（対応するキーIDを使用）が構成されています。キーの1つは、発信BFDコントロールパケットで計算されたMD5 [MD5]ダイジェストに含まれていますが、キー自体はパケットに含まれていません。リプレイ攻撃を避けるために、各パケットにシーケンス番号も搭載されています。キー付きMD5の場合、シーケンス番号が時々増加します。細心のキー付き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の場合）、または、受信した最後のシーケンス番号よりも厳密に大きい（細心のキー付き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タイプフィールドは、2（キー付きMD5）または3（細心のキー付きMD5）に設定する必要があります。AUTH LENフィールドは24に設定する必要があります。AUTHキー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 ASCII strings, and SHOULD also allow for the configuration of any arbitrary binary string in hexadecimal form. Other configuration methods MAY be supported.
認証キー値は、最大16バイトのバイナリ文字列であり、必要に応じてゼロバイトを後続のゼロバイトでパディングしたAUTHキー/ダイジェストフィールドに配置する必要があります。相互運用性のために、キーが構成されている管理インターフェイスは、ASCII文字列を受け入れる必要があり、また、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キー/ダイジェストフィールドに保存する必要があります（パケットに入れてはならないシークレットキーを置き換えます）。
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コントロールパケットが以前に送信されたパケットとは異なるコンテンツを運ぶときにインクリメントする必要があります。bfd.xmitauthseqをいつ増えるかについての決定は、この仕様の範囲外です。以下の「セキュリティ上の考慮事項」というタイトルのセクションを参照してください。
For Meticulous Keyed MD5, bfd.XmitAuthSeq MUST be incremented in a circular fashion (when treated as an unsigned 32-bit value).
綿密なキー付き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または細心のキー付きMD5の場合は2）、受信したパケットを破棄する必要があります。
If the Auth Key ID field does not match the ID of a configured authentication key, the received packet MUST be discarded.
AUTHキーIDフィールドが設定された認証キーのIDと一致しない場合、受信したパケットを破棄する必要があります。
If the Auth Len field is not equal to 24, the packet MUST be discarded.
認証レンフィールドが24に等しくない場合、パケットを破棄する必要があります。
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*検出マルチ）を含む（署名されていない32ビットの円形数スペースとして扱われた場合）、受信したパケットを破棄する必要があります。綿密なキー付きMD5の場合、シーケンス番号がBFD.RCVAUTHSEQ 1の範囲外にある場合、BFD.RCVAUTHSEQ（3*検出マルチを検出）包括的（署名されていない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 is 0）、bfd.authseqknownは1に設定する必要があり、bfd.rcvauthseqは受信シーケンス番号フィールドの値に設定する必要があります。
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キーIDフィールドで選択した認証キーに置き換えます。BFDコントロールパケット全体のMD5ダイジェストがAUTHキー/ダイジェストフィールドの受信値に等しい場合、受信パケットを受け入れる必要があります。それ以外の場合は、（ダイジェストはAUTHキー/ダイジェストフィールドと一致しません）、受信したパケットを破棄する必要があります。
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.
キー付きSHA1と細心のキー付きSHA1認証メカニズムは、他のプロトコルで使用されているものと非常に似ています。これらの認証方法では、各システムで1つ以上の秘密キー（対応するキーIDを使用）が構成されています。キーの1つは、発信BFDコントロールパケットで計算されたSHA1 [SHA1]ハッシュに含まれていますが、キー自体はパケットに含まれていません。リプレイ攻撃を避けるために、各パケットにシーケンス番号も搭載されています。キー付きSHA1の場合、シーケンス番号が時々増加します。細心のキー付き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ハッシュ、およびシーケンス番号が受信した最後のシーケンス番号以上である場合（キー付きのSHA1ハッシュの場合）パケットを受け入れます。SHA1）、または受信した最後のシーケンス番号よりも厳密に大きい（細心のキー付きSHA1の場合）。
Transmission Using Keyed SHA1 and Meticulous Keyed SHA1 Authentication
キー付きSHA1と細心のキー付きSHA1認証を使用した送信
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タイプフィールドは、4（キー付きSHA1）または5（細心のキー付きSHA1）に設定する必要があります。AUTH LENフィールドは28に設定する必要があります。AUTHキー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バイトのバイナリ文字列であり、必要に応じてゼロバイトを縮小したAuthキー/ハッシュフィールドに配置する必要があります。相互運用性のために、キーが構成されている管理インターフェイスは、ASCII文字列を受け入れる必要があり、また、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キー/ハッシュフィールドに保存する必要があります（パケットに入れてはならないシークレットキーを置き換えます）。
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.
キー付きSHA1の場合、bfd.xmitauthseqは、符号なしの32ビット値として扱われた場合）で循環する場合があります。BFD.xmitauthSeqは、セッション状態が変更されたとき、または送信されたBFDコントロールパケットが以前に送信されたパケットとは異なるコンテンツを運ぶときにインクリメントする必要があります。bfd.xmitauthseqをいつ増えるかについての決定は、この仕様の範囲外です。以下の「セキュリティ上の考慮事項」というタイトルのセクションを参照してください。
For Meticulous Keyed SHA1, bfd.XmitAuthSeq MUST be incremented in a circular fashion (when treated as an unsigned 32-bit value).
綿密なキー付き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コントロールパケットに認証セクションが含まれていない場合、または認証タイプが正しくない場合（キー付きSHA1の場合4または細心のキー付き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キーIDフィールドが設定された認証キーのIDと一致しない場合、受信したパケットを破棄する必要があります。
If the Auth Len field is not equal to 28, the packet MUST be discarded.
認証レンフィールドが28に等しくない場合、パケットを破棄する必要があります。
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の場合、シーケンス番号フィールドを調べます。キー付きSHA1の場合、シーケンス番号がbfd.rcvauthseqの範囲の範囲外にある場合、bfd.rcvauthseq（3*検出マルチ）を含む（署名されていない32ビットの円形数スペースとして扱われた場合）、受信したパケットを破棄する必要があります。細心のキー付きSHA1の場合、シーケンス番号がBFD.RCVAUTHSEQ 1の範囲外にある場合、BFD.RCVAUTHSEQ（3*検出マルチ）包括的（署名されていない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 is 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キーIDフィールドによって選択された認証キーに置き換えます。BFDコントロールパケット全体のSHA1ハッシュがAUTHキー/ハッシュフィールドの受信値に等しい場合、受信パケットを受け入れる必要があります。それ以外の場合は、（ハッシュはAUTHキー/ハッシュフィールドと一致しません）、受信したパケットを破棄する必要があります。
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.
ローカルシステムに「需要モードがアクティブ」と言われている場合、それはBFD.DemandModeがローカルシステムで1であることを意味します（セクション6.8.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）ビットを設定）、セッションがアップ、リモートシステムは、セッションが状態にあることを示しています。
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コントロールパケットがリモートエンドから受信されたら、少なくとも1つの検出時間（セクション6.8.4を参照）に保存する必要があります（セクション6.8.4を参照）。セッション状態。これにより、セッションがフラップした場合のタイミングパラメーターが保存されます。システムは、これよりも長くセッション状態を保持する場合があります。このセッションのBFD制御パケットがリモートシステムから受信されていない場合のセッション状態の保存または破壊は、この仕様の範囲外です。
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、またはaccmindown）。セッション状態の変更がこの仕様の範囲外であるときに取られた正確なアクションは、この状態の変更（特に、アップ状態との間）がシステムの他のコンポーネントに報告されると予想されます。この変数はダウンに初期化する必要があります。
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）フィールドのリモートシステムによって最後に報告されました。この変数はダウンに初期化する必要があります。
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).
ローカルセッション状態の最新の変更の理由を指定する診断コード。これはゼロに初期化する必要があります（診断なし）。
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コントロールパケット内のリモートシステムから受信した必要なMIN RX間隔の最後の値。この変数は1に初期化する必要があります。
bfd.DemandMode
bfd.demandmode
Set to 1 if the local system wishes to use Demand mode, or 0 if not.
ローカルシステムが需要モードを使用したい場合、またはそうでない場合は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.
リモートシステムが需要モードを使用したい場合、またはそうでない場合は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を参照してください。
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.
キー付きMD5またはSHA1認証の次のシーケンス番号が受信されると予想される場合は1に設定されています。この変数はゼロに初期化する必要があります。
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倍の検出時間の間、パケットが受信されなかった後、この変数をゼロに設定する必要があります。これにより、リモートシステムが再起動すると、シーケンス番号が再同期されることが保証されます。
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を参照してください。
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が上昇している場合、上記の投票シーケンスが終了するまで使用される実際の伝送間隔は変更しないでください。これは、リモートシステムが送信間隔が増加する前に検出時間を更新することを保証するためです。
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が上昇している場合、上記の投票シーケンスが終了するまで、リモートシステムの検出時間を計算するときに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がアップしていない場合、システムは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のためにローカルシステムが送信間隔を削減します（リモートシステムは必要なMIN RX間隔で値が低下しています）、リモートシステムが需要モードではない場合、ローカルシステムはすぐに新しいインターバルを尊重する必要があります。言い換えれば、ローカルシステムは、以前のパケット伝送と次のパケット伝送の間の新しい間隔よりも長く待つことができません。この間隔が最後の伝送以来既に通過している場合（新しい間隔が大幅に短いため）、ローカルシステムは、実行可能な限りすぐに次の周期BFD制御パケットを送信する必要があります。
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.
エコー関数がアクティブな場合、システムはBFD.RequiredMinrxIntervalを1秒以上（1,000,000マイクロ秒）の値に設定する必要があります。これは、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).
投票シーケンスメカニズムは、その使用を必要とする複数のパラメーターの変更が行われ、それらの複数の変更が複数のパケットに広がっている場合、あいまいであることに注意してください（戻るファイナルのセマンティクスは不明であるため）。したがって、投票シーケンスの使用を必要とする複数の変更が行われた場合、3つの選択肢があります。1）それらは単一のBFDコントロールパケット（最終返信のセマンティクスが明確です）で通信する必要があります。別の世論調査シーケンスの開始前に、状況（少なくとも最後の投票が送信されてから少なくとも往復時間）を明確にするために、投票シーケンスが完了したため、発生した必要があります。別の投票シーケンスの開始前に投票シーケンスが完了した後、ビット *クリア *を受信する必要があります（このオプションは、需要モードがアクティブな場合は使用できません）。
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.
非同期モードでは、ローカルシステムで計算された検出時間は、リモートシステムから受信した多数の検出値の値に等しく、リモートシステムの合意された送信間隔を掛けます（BFD.requiredMinrxIntervalの大きさと最後の受信最小tx間隔）。検出マルチ値は（大まかに言えば、ジッターのために）セッションを宣言するために連続して見逃す必要があるパケットの数です。
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 to down、bfd.localdiag to 1（制御検出時間の有効期限が切れ）。
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をダウンに、bfd.localdiagを1に設定する必要があります（制御検出時間の有効期限が切れます）。
(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の規則に従って「破棄」されていない場合にのみ、検出時間の有効期限のために、パケットが受信されたと見なされていることに注意してください）。
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).
エコー関数がアクティブであり、十分な数のエコーパケットが必要なように到着していない場合、セッションはダウンしています。ローカルシステムはBFD.SESSIONSTATEをダウンに、BFD.LocalDiagを2に設定する必要があります（エコー関数は失敗しました）。
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.
エコー関数障害が検出される平均は、この仕様の範囲外です。通信障害を検出する手段は受け入れられます。
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.
長さフィールドが最小正しい正しい値よりも少ない場合（少し明確な場合は24、または少し設定されている場合は26）、パケットを破棄する必要があります。
If the Length field is greater than the payload of the encapsulating protocol, the packet MUST be discarded.
長さフィールドがカプセル化プロトコルのペイロードよりも大きい場合、パケットを破棄する必要があります。
If the Detect Mult field is zero, the packet MUST be discarded.
検出マルチフィールドがゼロの場合、パケットを破棄する必要があります。
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.
私の識別子フィールドがゼロの場合、パケットを破棄する必要があります。
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.
識別子フィールドがゼロではない場合は、このBFDパケットが関連付けられているセッションを選択するために使用する必要があります。セッションが見つからない場合は、パケットを破棄する必要があります。
If the Your Discriminator field is zero and the State field is not Down or AdminDown, the packet MUST be discarded.
識別子フィールドがゼロであり、状態フィールドがダウンまたは承認されていない場合、パケットを破棄する必要があります。
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.
識別子フィールドがゼロの場合、セッションは他のフィールドの組み合わせに基づいて選択する必要があります。おそらく、ソースアドレス指定情報、私の識別子フィールド、およびパケットが受信されたインターフェイスを含む。正確な選択方法はアプリケーション固有であるため、この仕様の範囲外です。一致するセッションが見つからない場合、新しいセッションが作成されるか、パケットが破棄される場合があります。この選択は、この仕様の範囲外です。
If the A bit is set and no authentication is in use (bfd.AuthType is zero), the packet MUST be discarded.
少し設定されており、認証が使用されていない場合（BFD.AuthTypeがゼロ）、パケットを破棄する必要があります。
If the A bit is clear and authentication is in use (bfd.AuthType is nonzero), the packet MUST be discarded.
少し明確で、認証が使用されている場合（bfd.authtypeはゼロではありません）、パケットを破棄する必要があります。
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.
少し設定されている場合、使用中の認証タイプ（bfd.authtype）に基づいて、セクション6.7のルールに基づいてパケットを認証する必要があります。これにより、パケットが破棄される場合があります。
Set bfd.RemoteDiscr to the value of My Discriminator.
bfd.remotediscrを私の差別装置の価値に設定します。
Set bfd.RemoteState to the value of the State (Sta) field.
BFD.Remotestateを状態（STA）フィールドの価値に設定します。
Set bfd.RemoteDemandMode to the value of the Demand (D) bit.
bfd.remotedemandModeを需要の値（d）ビットに設定します。
Set bfd.RemoteMinRxInterval to the value of Required Min RX Interval.
BFD.REMOTE INR間隔を必要な最小RX間隔の値に設定します。
If the Required Min Echo RX Interval field is zero, the transmission of Echo packets, if any, MUST cease.
必要なMINエコーRX間隔フィールドがゼロの場合、エコーパケットの送信がある場合は、停止する必要があります。
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.
ローカルシステムによって投票シーケンスが送信され、受信したパケットの最終ビットが設定されている場合、投票シーケンスを終了する必要があります。
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
bfd.sessionStateが承認されている場合
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
bfd.sessionstateがダウンセットでない場合、受信状態が承認された場合、bfd.localdiagに3（隣人信号セッションダウン）set bfd.sessionstateからダウンまで
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
bfd.sessionstateが下がっている場合、状態がダウンしている場合はbfd.sessionstateを開始します。
Else if bfd.SessionState is Init If received State is Init or Up Set bfd.SessionState to Up
それ以外の場合は、bfd.sessionstateがinitである場合、状態がinitまたは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
else（bfd.sessionStateがアップ）状態がダウンしている場合、bfd.localdiagに3（隣の信号セッションダウン）set bfd.sessionstateからダウンまでset
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が上昇し、bfd.remotesessionStateがアップしている場合、需要モードはリモートシステムでアクティブであり、ローカルシステムはBFD制御パケットの定期的な伝送を停止する必要があります（セクション6.8.7を参照）。
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がアップしていない場合、またはbfd.remotesessionStateがアップしていない場合、需要モードはリモートシステムでアクティブではなく、ローカルシステムは定期的な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).
ポーリング（p）ビットが設定されている場合は、Poll（p）がクリアされ、最終（f）ビットセットを使用して、BFDコントロールパケットをリモートシステムに送信します（セクション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の検出時間有効期限ルールの目的で受信されました。
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％以上でなければなりません。これは、リモートシステムで、計算された検出時間が次の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制御パケットを送信してはなりません。
A system MUST NOT periodically transmit BFD Control packets if bfd.RemoteMinRxInterval is zero.
bfd.remoteminrxIntervalがゼロの場合、システムはBFD制御パケットを定期的に送信してはなりません。
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制御パケットを定期的に送信してはなりません（bfd.remotedemandModeは1、bfd.sessionStateが増加し、bfd.remotesessionStateが増加しています）。投票シーケンスは送信されません。
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.
投票（p）ビットが1に設定されたBFDコントロールパケットが受信された場合、受信システムは、敬意を払わずに、POLL（P）BIT CLEARおよびFinal（F）BIT SETを使用してBFDコントロールパケットと最終的な（F）ビットを送信する必要があります。セッション状態を尊重せずに、また、どちらのシステムでも需要モードがアクティブであるかどうかを尊重せずに、送信タイマーまたはその他の送信制限に対して。システムは、そのようなパケットが送信されるレートを制限する場合があります。レートの制限が有効な場合、希望のminTx間隔の広告値は、レート制限関数によって課される送信パケット間の間隔以上でなければなりません。
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が上昇し、bfd.remotesessionStateがアップしない限り、システムは需要（d）ビットを設定してはなりません。
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)
診断（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に設定します。
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.
ローカルシステムがポール（p）ビットセットで受信したコントロールパケットに応答している場合、1に設定します。
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はゼロではない）、またはそうでない場合は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.demandmodeに設定されているBfd.sessionStateがアップしていて、bfd.remotesessionStateがアップしています。それ以外の場合は、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
望ましいMIN TX間隔
Set to bfd.DesiredMinTxInterval.
bfd.desiredmintxintervalに設定します。
Required Min RX Interval
必要な最小rx間隔
Set to bfd.RequiredMinRxInterval.
bfd.requiredminrxintervalに設定します。
Required Min Echo RX Interval
必要なmin echo 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.
認証が使用されている場合、セクション6.7のルールに従って含まれ、設定されています（BFD.AuthTypeはゼロではありません）。それ以外の場合、このセクションは存在しません。
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エコーパケットは、処理のために適切なセッションに反対している必要があります。不足しているエコーパケットを検出する手段を実装する必要があります。これには、受信したエコーパケットの処理が含まれる可能性が高いです。それ以外の場合、受信したエコーパケットの処理は、この仕様の範囲外です。
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エコーパケットは、bfd.sessionStateがアップしていないときに送信してはなりません。BFDエコーパケットは、リモートシステムから受信した最後のBFDコントロールパケットに、必要なMINエコーRX間隔にゼロの値を含んでいない限り、送信してはなりません。
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エコーパケット間の間隔は、次の場合を除き、必要な最小echo rx間隔でリモートシステムによって宣伝されている値よりも小さい必要があります。
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.
25％のジッターが送信速度に適用されるため、実際の間隔は広告値の75％から100％の間である可能性があります。単一のBFDエコーパケットは、通常スケジュールされたエコー伝送間隔の間に送信される場合があります。
The transmission of BFD Echo packets is otherwise outside the scope of this specification.
それ以外の場合、BFDエコーパケットの送信は、この仕様の範囲外です。
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を参照してください。
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のルールが適用されます。
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を参照してください。
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コントロールパケットで必要なMINエコーRX間隔の値をゼロまたは非ゼロに変更することにより、いつでも行うことができます。
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制御パケットの送信を開始する必要があります。
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を設定する必要があります。ダウンに。
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
セッションを有効にする場合、bfd.sessionStateを下に設定します
Else Set bfd.SessionState to AdminDown Set bfd.LocalDiag to an appropriate value Cease the transmission of BFD Echo packets
それ以外の場合、bfd.sessionStateを承認するように設定しますset bfd.localdiagは適切な値にbfdエコーパケットの送信を停止します
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.
基礎となるパスが失敗したというSignalingがBFDの外部から受信された場合、実装により、診断パスが下にあるセッションを管理上無効にする可能性があります。
Other scenarios MAY use the diagnostic Administratively 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).
BFD制御パケットは、リモートシステムが状態の変更を確実に認識できるように、承認国に移行した後、少なくとも検出時間のために送信する必要があります。BFD制御パケットは、各システムでセッション状態を維持するために、承認状態に移行した後、無期限に送信できます（以下のセクション6.8.18を参照）。
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によって監視されているパスが他のパスと連結されている場合（シリーズでエンドツーエンドに接続されている）、BFDセッション全体でそれらのパスのいずれかの障害の表示を伝播することが望ましい場合があります（Livenivesのために互換性関数を提供する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 reverse path failures (in which the concatenated path fails in the direction away from the interworking system, assuming a bidirectional link).
この目的のために2つの診断コードが定義されています。連結されたパスダウンと逆連結パスを逆にします。最初の伝播は、前方のパス障害（連結されたパスがインターワーキングシステムに向かう方向に失敗する）を伝播し、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を適切な診断コードに設定するだけで、これらの障害状態のいずれかを信号する場合があります。BFDセッションは削除されていないことに注意してください。リモートシステムで需要モードがアクティブでない場合、診断コードはBFD制御パケットの周期的な送信を介して実行されるため、他のアクションは必要ありません。リモートシステム（ローカルシステムが周期的なBFD制御パケットを送信していない）で需要モードがアクティブである場合、診断コードが送信されるようにポーリングシーケンスを開始する必要があります。BFDセッションがその後失敗した場合、診断コードは障害の原因を詳述するコードで上書きされることに注意してください。BFDセッションが状態に達すると、連結された経路障害の伝播が再開される場合、上記の手順を再度実行するのは、インターワーキングエージェント次第です。
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つは、セッションが確立されるレートを管理することです。これは、必要に応じて、セッションをダウン状態または承認状態に保持することで実行できます。
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コントロールパケットの受領なしに検出時間が経過するまでシステムが必要です。これは、システムがセッションを削除し、必要なMIN 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.
さらに、システムは、必要なMin 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ごとに）。独自のレートで送信します。
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バウンドになる可能性があります。そのため、壊滅的なシステム崩壊の可能性を回避するために、渋滞制御アルゴリズムを単一のホップ全体で使用する必要があります。そのような障害は、他の定期的なハローベースのプロトコルで繰り返し見られているからです。
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間隔およびMIN TX間隔フィールドを介したローカルおよびリモートパケット伝送速度の制御です。
Note that any mechanism that increases the transmit or receive intervals will increase the Detection Time for the session.
送信中の間隔を増加させるメカニズムは、セッションの検出時間を増加させることに注意してください。
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ミリ秒の検出時間を達成する積極的なセッションは、毎秒60パケットを生成します。ワイヤー上の各パケットの最大長は、100バイトのオーダーにあり、各方向の帯域幅消費の合計約48キロビットがあります。
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つのレジストリを定義しています。1つ目は「BFD診断コード」というタイトルです（セクション4.1を参照）。BFD診断コードレジストリの初期値を以下に示します。Expert Review [Iana-Consididerations]を通じて、さらなる割り当てが行われます。割り当ては、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
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認証タイプレジストリの初期値を以下に示します。Expert Review [Iana-Consididerations]を通じて、さらなる割り当てが行われます。割り当ては、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
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によって防止できません。
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が複数のホップまたは不安定なトンネル（一般的なルーティングカプセル化（GRE）など）にわたって実行される場合、認証セクションを利用する必要があります。
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 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.
キー付きMD5/SHA1と綿密なキー付きMD5/SHA1の両方が、より一般的なハッシュされたメッセージ認証の代わりに、ハッシュを計算する前に共有シークレットキーがデータに追加される「Secret Suffix」構造（「Append Only」とも呼ばれます）を使用します。コード（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.
両方のシステムがセッションの開始時にローカルの判別器値をランダム化する場合、使用中の認証タイプに関係なく、リプレイ攻撃がさらに軽減される場合があります。セッション中はいつでもローカルな識別器が変更される可能性があるため、このメカニズムは攻撃を軽減するのにも役立ちます。
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エコーパケットの使用のセキュリティへの影響は、それらの構造が送信システムにローカルであり、この仕様の範囲外であるため、これらのパケットの定義方法に依存します。ただし、エコーパケットは送信システムによってのみ定義および処理されるため、暗号化認証の使用は、他のシステムが実際に生存していることを保証するものではありません。攻撃者は、エコーパケットを（秘密のキーを知らずに）戻し、リンクを誤って宣言することができます。これは、BFD制御パケットに適切な間隔を使用することで軽減できます。[GTSM]はBFDエコーパケットに適用できますが、TTL/ホップカウントはパケットをエコーする過程で1減少するため、1ホップからスプーフィングが可能になります。
[GTSM] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[GTSM] Gill、V.、Heasley、J.、Meyer、D.、Savola、P.、Ed。、およびC. Pignataro、「一般化されたTTLセキュリティメカニズム（GTSM）」、RFC 5082、2007年10月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[MD5] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。
[SHA1] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[SHA1] EastLake 3rd、D。およびP. Jones、「US Secure Hash Algorithm 1（SHA1）」、RFC 3174、2001年9月。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[Iana-Consididerations] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
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になったインターネットドラフトの初期バージョンで定義されているように）は、広く展開される可能性は低いですが、一部の実装者は後方互換性メカニズムを希望する場合があります。プロトコルの定義を変更しないメカニズムが潜在的に使用される可能性があるため、相互運用性は問題ではないことに注意してください。
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.
ここで説明されている提案されたメカニズムには、1つのシステムが検出時間内にバージョン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セッションは、自動バージョンのために構成され、起動したばかりであるか、セッションが手動でクリアされた場合、「ネゴシエーションホールドダウン」を入力します。セッションは、1回の検出時間の間続くホールドダウン期間中に、州とバージョン1に承認された状態とバージョン1に設定されています。システムは通常どおりBFDコントロールパケットを送信しますが、受信したパケットは無視します。ホールドダウン時間が完了した後、状態はダウンに移行し、通常の操作が再開されます。
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およびバージョン1パケットを使用している場合隣人が州の承認者であり、バージョン1に切り替えられていることを示す受信します。バージョン0を使用し、バージョン1パケットが受信された場合、承認者以外の状態を示す場合、パケットは無視されます（仕様ごと）。
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の故障状態）。
Kireeti Kompella and Yakov Rekhter of Juniper Networks were also significant contributors to this document.
ジュニパーネットワークのKireeti KompellaとYakov Rekhterも、この文書に重要な貢献者でした。
This document was inspired by (and is intended to replace) the Protocol Liveness Protocol document, written by Kireeti Kompella.
このドキュメントは、Kireeti Kompellaによって書かれたプロトコルライデンスプロトコルドキュメントに触発されました（および置き換えることを目的としています）。
Demand mode was inspired by "A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers", by G. Huang, et al.
需要モードは、「死んだインターネットキーエクスチェンジ（IKE）ピアを検出するトラフィックベースの方法」に触発されました。
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
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
Dave Ward Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089-1206 USA
Phone: +1-408-745-2000
EMail: dward@juniper.net