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)
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.
この文書では、潜在的に非常に低いレイテンシで、インターフェースを含む二フォワーディングエンジンとの間の双方向経路の障害を検出するためのプロトコル、データリンク（単数または複数）、および程度を可能フォワーディングエンジン自体を記載します。それは独立したメディア、データ・プロトコル、およびルーティングプロトコルの動作します。
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
ネットワークは、助けるためにシグナリングを全くハードウェアが存在しない場合に障害を検出するために、通常はルーティングプロトコルでは、比較的遅い「こんにちは」のメカニズムを使用します。既存のプロトコルで利用できる障害（「検出タイムズ」）を検出するための時間は、いくつかのアプリケーションのためにあまりにも長いですし、ギガビットレートで失われた大量のデータを表し秒、よりも優れていません。さらに、これらのルーティングプロトコルが使用されていない場合、ルーティングプロトコルのhelloはない助けであり、そして検出の意味は微妙に異なっている - それらは、2つのルーティングプロトコルエンジンとの間のパスの障害を検出します。
The goal of Bidirectional Forwarding Detection (BFD) is to provide low-overhead, short-duration detection of failures in the path between adjacent forwarding engines, including the interfaces, data link(s), and, to the extent possible, the forwarding engines themselves.
双方向フォワーディング検出（BFD）の目標は、程度に、転送エンジン可能な低オーバーヘッド、インターフェース、データ・リンク（単数または複数）を含む隣接フォワーディングエンジンとの間の経路の障害の短時間の検出を提供することであり、そして自分自身。
An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of Detection Times and overhead, to avoid a proliferation of different methods.
付加的な目標は、異なる方法の増殖を回避するために、検出時間とオーバーヘッドの広い範囲で、任意のプロトコル層で、任意のメディア上ライブネス検出のために使用することができる単一のメカニズムを提供することです。
This document specifies the details of the base protocol. The use of some mechanisms are application dependent and are specified in a separate series of application documents. These issues are so noted.
このドキュメントでは、基本プロトコルの詳細を指定します。いくつかのメカニズムを使用すると、アプリケーションに依存していると申請書類の別々の直列に指定されています。これらの問題はそう指摘されています。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [KEYWORDS]で説明されるように解釈されます。
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を）パスの交換、マルチホップはもちろん、あまりにも長い間、いくつかのリターンパスがあるので（パス、および単一方向リンクをルーティング）。それらの間の複数のパスが少なくとも1つの方向に存在する場合、複数のBFDセッションは、パスのより少ない数（例えば、複数の平行な一方向リンクまたはMPLSのLSPの）他の方向に利用可能である場合でも、システムの同一の対の間に確立することができます。
The BFD state machine implements a three-way handshake, both when establishing a BFD session and when tearing it down for any reason, to ensure that both systems are aware of the state change.
BFDのステートマシンは、3ウェイハンドシェイクを実装して、両方のBFDセッションを確立するときに、両方のシステムが状態変化を認識していることを確認するために、何らかの理由でそれを解体するとき。
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.
別BFDセッションは、2つのシステム間で使用されている各通信パス及びデータプロトコルのために作成されます。
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プロトコルを用いて発見隣人に確立される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は、二つの動作選択することができるモード、ならびに二つのモードと組み合わせて使用することができる付加的な機能を有しています。
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.
第二のモードは、デマンドモードとして知られています。このモードでは、システムは、それが他のシステムへの接続を有していることを検証する独立した方法を有することが想定されます。 BFDセッションが確立されると、このようなシステムは、BFD制御パケットの短い配列が交換された場合には、システムは、明示的に接続を確認する必要性を感じているとき以外は、BFD制御パケットの送信を停止するために、他のシステムに依頼し、その後もこれまでシステムが静止します。デマンドモードは、同時に、それぞれの方向に独立して動作する、又はできます。
An adjunct to both modes is the Echo function. When the Echo function is active, a stream of BFD Echo packets is transmitted in such a way as to have the other system loop them back through its forwarding path. If a number of packets of the echoed data stream are not received, the session is declared to be down. The Echo function may be used with either Asynchronous or Demand mode. Since the Echo function is handling the task of detection, the rate of periodic transmission of Control packets may be reduced (in the case of Asynchronous mode) or eliminated completely (in the case of Demand mode).
両方のモードへの補助は、エコー機能です。エコー機能がアクティブである場合、BFDエコーパケットのストリームは、その転送路を介して他のシステムループバックそれらを有するような方法で送信されます。エコーされたデータ・ストリームのパケット数が受信されない場合、セッションはダウンが宣言されます。エコー機能は、非同期またはオンデマンドモードのいずれかで使用することができます。エコー機能は、検出のタスクを処理しているため、制御パケットの定期送信のレートは、（非同期モードの場合）減少または（オンデマンドモードの場合）完全に排除することができます。
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)
バージョン（Versの）
The version number of the protocol. This document defines protocol version 1.
プロトコルのバージョン番号。この文書は、プロトコルバージョン1を定義します。
Diagnostic (Diag)
診断（ダイアグ）
A diagnostic code specifying the local system's reason for the last change in session state. Values are:
セッション状態の最後の変更のためのローカルシステムの理由を指定する診断コード。値は次のとおりです。
0 -- No Diagnostic 1 -- Control Detection Time Expired 2 -- Echo Function Failed 3 -- Neighbor Signaled Session Down 4 -- Forwarding Plane Reset 5 -- Path Down 6 -- Concatenated Path Down 7 -- Administratively Down 8 -- Reverse Concatenated Path Down 9-31 -- Reserved for future use
0 - なし診断1 - コントロール検出時間は2期限切れ - ファンクション3失敗エコー - ダウン6パス - - フォワーディングプレーン5をリセット - ダウン連結路7 - 管理上のダウン8ネイバーセッションダウン4が信号 - 連結道を逆9-31 - 今後の使用のために予約
This field allows remote systems to determine the reason that the previous session failed, for example.
このフィールドは、例えば、リモート・システムは、前のセッションが失敗した理由を判別することができます。
State (Sta)
状態（STA）
The current BFD session state as seen by the transmitting system. Values are:
送信システムによって見られるように、現在のBFDセッション状態。値は次のとおりです。
0 -- AdminDown 1 -- Down 2 -- Init 3 -- Up
0 - AdminDown 1 - ダウン2 - 初期3 - アップ
Poll (P)
ポール（P）
If set, the transmitting system is requesting verification of connectivity, or of a parameter change, and is expecting a packet with the Final (F) bit in reply. If clear, the transmitting system is not requesting verification.
設定した場合、送信システムが接続性の、またはパラメータ変更の検証を要求し、応答の最終（F）ビットを有するパケットを期待しています。明確な場合は、送信システムは、検証を要求していません。
Final (F)
最終（F）
If set, the transmitting system is responding to a received BFD Control packet that had the Poll (P) bit set. If clear, the transmitting system is not responding to a Poll.
設定した場合、送信システムは、ポーリングビットセット（P）を有した受信BFD制御パケットに応答しています。明確な場合は、送信システムは、ポーリングに応答していません。
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
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
理想の分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
必要な分エコー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.
これは、（セクション6.8.9を参照）は、このシステムがサポートすることができる、以下の任意のジッタが送信者によって適用された受信BFDエコーパケットの間に、マイクロ秒単位で、最小間隔です。この値がゼロの場合は、送信システムは、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.
認証タイプと認証レンフィールドを含む認証部、のバイト単位の長さ、、。
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
認証キー/ダイジェスト
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
認証キー/ハッシュ
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」が「XXXフィールドが」プロトコルパケット内のフィールドに自分自身を参照するすべての参照に対して、（セクション6.8.1で定義されている）は、内部状態変数を参照することを覚えている（セクション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パケットを送信し始めてはいけませんので、リモート・システムの識別値を学習しています。少なくとも一つのシステムは、（おそらく両方）の積極的な役割を取る必要があります。システムが取る役割は、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制御パケットの送信が停止します。接続性を暗示する他の手段は、セッションを存続するために使用されています。そうするために、どちらかのシステムは、双方向接続を確認したい場合、それは（セクション6.5を参照して、「ポーリングシーケンス」）BFD制御パケットの短い交換を開始することができます。
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.
セッションがダウンと宣言されたら、それはこのように3ウェイハンドシェイクを実装し、それは（アップ状態を残すことによって）ダウンしているリモートエンド最初の信号まで戻って来ることができません。
A session MAY be kept administratively down by entering the AdminDown state and sending an explanatory diagnostic code in the Diagnostic field.
セッションは、管理上のダウンAdminDown状態に入ると診断分野において説明診断コードを送信することによって維持することができます。
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のステートマシンは非常に簡単です。 2（下）セッション（初期および最大）を確立し、セッションを切断するための1つのために：セッションは正常に進行し、それを通して3つの状態があります。これは、セッションの確立とセッションティアダウン（両方のシステムは、すべてのセッション状態の変化を認識していることを保証する）の両方のためのスリーウェイハンドシェイクを可能にします。セッションが管理無限に置くことができるように、第4の状態（AdminDown）が存在します。
Each system communicates its session state in the State (Sta) field in the BFD Control packet, and that received state, in combination with the local session state, drives the state machine.
各システムは、BFD制御パケットに状態（STA）フィールドにそのセッション状態を通信し、その受信状態が、ローカルセッション状態との組み合わせで、ステートマシンを駆動します。
Down state means that the session is down (or has just been created). A session remains in Down state until the remote system indicates that it agrees that the session is down by sending a BFD Control packet with the State field set to anything other than Up. If that packet signals Down state, the session advances to Init state; if that packet signals Init state, the session advances to Up state. Semantically, Down state indicates that the forwarding path is unavailable, and that appropriate actions should be taken by the applications monitoring the state of the BFD session. A system MAY hold a session in Down state indefinitely (by simply refusing to advance the session state). This may be done for operational or administrative reasons, among others.
ダウン状態のセッションがダウンしていることを意味します（あるいは単に作成されています）。リモートシステムは、セッションがアップ以外に設定StateフィールドでのBFD制御パケットを送信することにより、ダウンしていることに同意することを示すまで、セッションはダウン状態のままです。そのパケット信号ダウン状態ならば、セッションは状態をinitに進みます。そのパケットは、初期状態、アップ状態へのセッションの進歩を知らせる場合。意味的に、ダウン状態は、転送パスが使用できないことを示し、その適切なアクションは、BFDセッションの状態を監視するアプリケーションによって解釈されるべきです。システムは、（単にセッション状態を前進させるために拒否することによって）、無期限にダウン状態でセッションを保持してもよいです。これは、とりわけ、運用や管理上の理由のために行うことができます。
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).
初期状態では、リモート・システムが通信していることを意味し、ローカルシステムでは、セッションを起動することを望むが、リモートシステムがまだそれを実現していません。いずれかのBFD制御パケットが検出時間は、リモートシステムとの通信が失われたことを意味し、期限切れになるか（この場合、アップ状態にセッションが進行する中で）そのシグナリングされる初期またはアップ状態を受信するまでセッションは初期化状態に留まります（その場合、セッションは）ダウン状態に移行します。
Up state means that the BFD session has successfully been established, and implies that connectivity between the systems is working. The session will remain in the Up state until either connectivity fails or the session is taken down administratively. If either the remote system signals Down state or the Detection Time expires, the session advances to Down state.
状態までBFDセッションが正常に確立されたことを意味し、システム間の接続が機能していることを意味します。いずれかの接続が失敗した場合やセッションが管理上のダウン取られるまでセッションがアップ状態のままになります。リモートシステムのいずれかの状態がダウン信号や検出時間が経過すると、セッションがダウン状態に移行します。
AdminDown state means that the session is being held administratively down. This causes the remote system to enter Down state, and remain there until the local system exits AdminDown state. AdminDown state has no semantic implications for the availability of the forwarding path.
AdminDown状態はセッションが管理上のダウン開催されていることを意味します。これは、状態をダウン入力するリモートシステムを引き起こし、そしてローカルシステムがAdminDown状態を終了するまで残っています。 AdminDown状態は、転送パスの可用性のためのセマンティックな意味を持っていません。
The following diagram provides an overview of the state machine. Transitions involving AdminDown state are deleted for clarity (but are fully specified in sections 6.8.6 and 6.8.16). The notation on each arc represents the state of the remote system (as received in the State field in the BFD Control packet) or indicates the expiration of the Detection Timer.
次の図は、ステートマシンの概要を提供します。 AdminDown状態を含む遷移は、明確にするために削除されます（ただし、完全にセクション6.8.6と6.8.16で指定されています）。各円弧上の表記は、リモート・システムの状態を表す（BFD制御パケットの状態フィールドで受信されるように）または検出タイマの満了を示しています。
+--+
| | UP, ADMIN DOWN, TIMER
| V
DOWN +------+ INIT
+------------| |------------+
| | DOWN | |
| +-------->| |<--------+ |
| | +------+ | |
| | | |
| | ADMIN DOWN,| |
| |ADMIN DOWN, DOWN,| |
| |TIMER TIMER| |
V | | V
+------+ +------+
+----| | | |----+
DOWN| | INIT |--------------------->| UP | |INIT, UP
+--->| | INIT, UP | |<---+
+------+ +------+
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制御パケットに私の弁別フィールドに送信され、リモートエンドから送信されるパケットのあなたの弁別フィールドにエコーバックされます。
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).
システムは、エコー機能を使用している場合ライブネス検出エコーパケットによって処理されるので、制御パケットの落ち着いた受信レートを選択することが有利です。これは、必要な分RX Intervalフィールドを操作することによって制御することができます（セクション6.8.3を参照してください）。
If the Echo function is only being run in one direction, the system not running the Echo function will more likely wish to receive fairly rapid Control packets in order to achieve its desired Detection Time. Since BFD allows independent transmission rates in each direction, this is easily accomplished.
エコー機能は、一方向にのみ実行されている場合は、エコー機能を実行していないシステムでは、より多くの可能性がその所望の検出時間を達成するために、かなり急速な制御パケットを受信することを望むだろう。 BFDは、各方向に独立した伝送レートを可能にするので、これは容易に達成されます。
A system SHOULD otherwise advertise the lowest value of Required Min RX Interval and Required Min Echo RX Interval that it can under the circumstances, to give the other system more freedom in choosing its transmission rate. Note that a system is committing to be able to receive both streams of packets at the rate it advertises, so this should be taken into account when choosing the values to advertise.
システムは、それ以外の場合は状況下で、その伝送速度を選択する際に、他のシステムに多くの自由を与えることを必要分RX間隔と必要な分エコーRX間隔の最小値を宣伝すべきです。システムは、それがアドバタイズレートでパケットの両方のストリームを受信することができるようにコミットしているので、広告する値を選択するとき、これは考慮されるべきであることに注意してください。
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制御パケットを送信システムから成ります。他のシステムがポーリングを受信すると、直ちにそれが（セクション6.8.7を参照）を送信することができる任意の周期BFD制御パケットの独立した最終（F）ビットセットとBFD制御パケットを送信します。ポーリング・シーケンスを送信するシステムが最終有するパケットを受信すると、ポーリングシーケンスが終了し、それ以降の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つのシステム間の継続的な接続性を暗示するために使用されている必要があります。使用されるメカニズムは、両方向で同じでなければならない、そして本明細書の範囲外でありません。一つの可能なメカニズムは、リモートシステムからのトラフィックの受信です。他には、エコー機能を使用することです。
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セッション状態に影響を与えずに、（D）要求を設定またはクリアすることによって、独立して、それぞれの方向に、任意の時点でBFD制御パケット内のビットをイネーブルまたはディセーブルされます。両方のシステムが、セッションがアップ（ローカルシステムは、セッションがアップしていると考えて、リモートシステムが最後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）を除いて、前のパケットの内容とは異なることになる送信されるべき次の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.
オンデマンドモードは一方向にのみ有効になっている場合、連続双方向接続性検証が失われることに注意してください（オンデマンドモードのシステムから他のシステムへの方向のみの接続が検証されます）。他は、連続双方向接続性検証を必要とするデマンドモードを要求して一つのシステムの問題を解決することは、この明細書の範囲外です。
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.
同じ認証タイプ、および任意のキーまたは他の必要な情報が、明らかに二つのシステムで使用されなければなりません。等認証タイプ、キー交換の交渉は、全て本明細書の範囲外であり、プロトコルの外部手段によって実行されることが期待されます。
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.
一つの可能なアプローチは、一致する認証部を含む最初のパケットは、（必要な同期を提供する）を受信するまで認証が「使用中」構成が、考慮されていないような実装を構築することです。同様に、認証はオフに設定することができ、それでも認証部なしの最初のパケットを受信するまで「使用中」とみなさ。
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.
セキュリティ上のリスクを回避するためには、この方法を使用して実装が唯一の認証状態が介入のいくつかのフォームなしで最も一度変更することができるようにする必要があります（ので、認証がオンになり、繰り返し単にリモートからの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.
認証の最も簡単な（そして最も弱い）の形はシンプルなパスワード認証です。この認証方法では、（対応するキーIDを持つ）は、1つまたは複数のパスワードは、各システムで構成され、これらのパスワード/ IDペアの一方が各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制御パケットの認証部に格納する必要があります。認証タイプフィールドは1（単純なパスワード）を設定しなければなりません。認証LENフィールドは、適切な長さ（4〜19バイト）に設定しなければなりません。
The password is a binary string, and MUST be 1 to 16 bytes in length. For interoperability, the management interface by which the password is configured MUST accept ASCII strings, and SHOULD also allow for the configuration of any arbitrary binary string in hexadecimal form. Other configuration methods MAY be supported.
パスワードは、バイナリ文字列であり、長さが1〜16バイトでなければなりません。相互運用性のために、パスワードが設定されていることにより、管理インターフェイスは、ASCII文字列を受け入れなければなりません、また、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.
認証キー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.
認証レンフィールドは、キーIDが選択したパスワード、プラス3の長さと等しくない場合、パケットは捨てなければなりません。
If the Password field does not match the password selected by the key ID, the packet MUST be discarded.
[パスワード]フィールドがキーであることにより、選択したパスワードと一致しない場合、パケットは捨てなければなりません。
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認証メカニズムは、他のプロトコルで使用されるものと非常に類似しています。認証のこれらの方法では、（対応するキー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).
鍵付きMD5のために（鍵IDパケットで運ばれた選択されたキーマッチを含む構成キー、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.
認証タイプフィールドを2（キー付きMD5）又は3（細心の鍵付きMD5）に設定しなければなりません。認証レンフィールドは、認証キーIDフィールドは、現在の認証キーのIDに設定しなければならない。24に設定しなければなりません。シーケンス番号フィールドは、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
認証キーの値は、最大16バイトのバイナリ文字列であり、必要に応じてゼロバイト末尾で埋め認証キー/ダイジェストフィールドに入れなければなりません。相互運用性のため、キーが設定されていることにより、管理インターフェイスは受け入れなければなりません
ASCII strings, and SHOULD also allow for the configuration of any arbitrary binary string in hexadecimal form. Other configuration methods MAY be supported.
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制御パケット上で計算しなければなりません。得られた消化物（パケットで運ばれてはいけません秘密鍵を交換する）送信前に認証キー/ダイジェストフィールドに格納されなければなりません。
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.
（符号なし32ビット値として扱われる場合）鍵付きMD5ため、bfd.XmitAuthSeqは円形に増分することができます。ときにセッション状態変化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).
（符号なし32ビット値として扱われる場合）細心の鍵付きMD5ため、bfd.XmitAuthSeqは円形にインクリメントされなければなりません。
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.
（キー付きMD5又は細心キー付きMD5 3 2）受信されたBFD制御パケットが認証部が含まれていない、または認証タイプが正しくない場合、受信したパケットは廃棄されなければなりません。
If the Auth Key ID field does not match the ID of a configured authentication key, the received packet MUST be discarded.
認証キーIDフィールドが設定された認証キーのIDと一致しない場合は、受信したパケットを捨てなければなりません。
If the Auth Len field is not equal to 24, the packet MUST be discarded.
認証LENフィールドが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のために、シーケンス番号（符号なし32ビット円形番号空間として扱われる場合）含め、受信したパケットを廃棄しなければならないbfd.RcvAuthSeq +へbfd.RcvAuthSeqの範囲（3 *のMultを検出）の外にある場合。シーケンス番号がbfd.RcvAuthSeq +にbfd.RcvAuthSeq + 1の範囲の外にある場合、細心の鍵付きMD5（3 *のMultを検出）（符号なし32ビット円形番号空間として扱われる場合）包括受信パケットは廃棄されなければなりません。
Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1, and bfd.RcvAuthSeq MUST be set to the value of the received Sequence Number field.
そうでない場合（bfd.AuthSeqKnownは0）、bfd.AuthSeqKnownを1に設定しなければなりません、そしてbfd.RcvAuthSeqは、受信したシーケンス番号フィールドの値に設定しなければなりません。
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.
受け取った認証キーID]フィールドで選択した認証キーと認証キー/ダイジェストフィールドの内容を交換してください。全体BFD制御パケットのMD5ダイジェスト認証キー/ダイジェストフィールドの受信された値と等しい場合、受信されたパケットは受け入れなければなりません。それ以外の場合は、受信したパケットを捨てなければなりません（ダイジェストが認証キー/ダイジェストフィールドと一致していません）。
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認証メカニズムは、他のプロトコルで使用されるものと非常に類似しています。認証のこれらの方法では、（対応するキー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が設定キーのいずれか、パケットで運ば選択キーマッチを含む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.
認証タイプフィールドが4（キー付きSHA1）または5（細心のキー付きSHA1）に設定しなければなりません。認証レンフィールドは、認証キーIDフィールドは、現在の認証キーのIDに設定しなければならない。28に設定しなければなりません。シーケンス番号フィールドは、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バイトのバイナリ文字列であり、必要に応じてゼロバイト末尾で、認証キー/ハッシュフィールドにパディングを置かなければなりません。相互運用性のために、キーが設定されていることにより、管理インターフェイスは、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制御パケットにわたって計算しなければなりません。結果のハッシュは（パケットで運ばれてはいけません秘密鍵を交換する）送信前に認証キー/ハッシュフィールドに格納されなければなりません。
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.
（符号なし32ビット値として扱われる場合）キー付きSHA1ため、bfd.XmitAuthSeqは円形に増分することができます。ときにセッション状態変化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).
（符号なし32ビット値として扱われる場合）細心の鍵付きSHA1ため、bfd.XmitAuthSeqは円形にインクリメントされなければなりません。
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.
（キー付きSHA1または細心キー付きSHA1 5 4）を受信BFD制御パケットが認証部が含まれていない、または認証タイプが正しくない場合、受信したパケットは廃棄されなければなりません。
If the Auth Key ID field does not match the ID of a configured authentication key, the received packet MUST be discarded.
認証キー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のために、シーケンス番号（符号なし32ビット円形番号空間として扱われる場合）含め、受信したパケットを廃棄しなければならないbfd.RcvAuthSeq +へbfd.RcvAuthSeqの範囲（3 *のMultを検出）の外にある場合。符号なし32ビット円形番号空間として扱う場合に細心の鍵付きSHA1のために、シーケンス番号がbfd.RcvAuthSeq +にbfd.RcvAuthSeq + 1の範囲（3 *のMultを検出）包括的（の外にある場合、受信パケットは廃棄されなければなりません。
Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1, bfd.RcvAuthSeq MUST be set to the value of the received Sequence Number field, and the received packet MUST be accepted.
そうでない場合（bfd.AuthSeqKnownが0である）、bfd.AuthSeqKnownを1に設定しなければなりません、bfd.RcvAuthSeqは、受信したシーケンス番号フィールドの値に設定しなければなりません、そして受信されたパケットは受け入れなければなりません。
Replace the contents of the Auth Key/Hash field with the authentication key selected by the received Auth Key ID field. If the SHA1 hash of the entire BFD Control packet is equal to the received value of the Auth Key/Hash field, the received packet MUST be accepted. Otherwise (the hash does not match the Auth Key/Hash field), the received packet MUST be discarded.
受け取った認証キーID]フィールドで選択した認証キーと認証キー/ハッシュフィールドの内容を交換してください。全体BFD制御パケットのSHA1ハッシュは、認証キー/ハッシュフィールドの受信された値と等しい場合、受信されたパケットは受け入れなければなりません。それ以外の場合は、受信したパケットを捨てなければなりません（ハッシュは、認証キー/ハッシュ・フィールドと一致していません）。
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は、セッションがアップし、かつリモート・システムがセッション中であることをシグナリングされる（セクション6.8.1参照）は、ローカルシステム内に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.
遠隔システムが有すると言われる場合、「アクティブデマンドモードを、」それは（リモートシステムが需要を設定（D）最後のビットがBFD制御パケットを受信した）bfd.RemoteDemandModeが1であることを意味し、セッションがアップし、リモートシステムは、セッション状態のアップであることをシグナリングしています。
A minimum amount of information about a session needs to be tracked in order to achieve the elements of procedure described here. The following is a set of state variables that are helpful in describing the mechanisms of BFD. Any means of tracking this state may be used so long as the protocol behaves as described.
セッションについての情報の最小量は、ここで記載された手順の要素を達成するために追跡される必要があります。以下は、BFDのメカニズムを説明するのに役立つている状態変数の集合です。この状態を追跡する任意の手段が記載されているように、プロトコルの動作限り使用することができます。
When the text refers to initializing a state variable, this takes place only at the time that the session (and the corresponding state variables) is created. The state variables are subsequently manipulated by the state machine and are never reinitialized, even if the session fails and is reestablished.
テキストは、状態変数の初期化を参照する場合、これが唯一のセッション（および対応する状態変数）が作成された時点で行われます。状態変数は、その後、ステートマシンによって操作され、セッションが失敗し、再確立されている場合でも、再初期化されることはありません。
Once session state is created, and at least one BFD Control packet is received from the remote end, it MUST be preserved for at least one Detection Time (see section 6.8.4) subsequent to the receipt of the last BFD Control packet, regardless of the session state. This preserves timing parameters in case the session flaps. A system MAY preserve session state longer than this. The preservation or destruction of session state when no BFD Control packets for this session have been received from the remote system is outside the scope of this specification.
セッション状態が作成されると、少なくとも1つのBFD制御パケットがリモートエンドから受信され、それは関係なく、最後BFD制御パケットの受信に続いて、少なくとも1つの検出時間（セクション6.8.4を参照）のために保存されなければなりませんセッション状態。これは場合にセッションフラップをタイミング・パラメータを保持します。システムは、これより長いセッション状態を保存することができます。このセッションではBFD制御パケットがリモート・システムから受信されていないセッション状態の維持又は破壊は、本明細書の範囲外です。
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.
セッションの知覚状態（初期、上、下、またはAdminDown）。セッション状態の変更は、本明細書の範囲外である場合には、この状態変化（特に、およびアップ状態から）システムの他のコンポーネントに報告されることが期待されるが、正確なアクションが取ら。この変数は、下に初期化する必要があります。
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.
（セクション6.8.2を参照）を送信BFD制御とマイクロ秒の最小間隔は、このシステムは、現在の時点で使用したいことパケット、より少ない任意のジッタが印加されます。実際の間隔は、2つのシステム間で交渉されます。これは、セクション6.8.3で説明したルールに従って、少なくとも一つの第二（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.
必要な分RX間隔の最後の値は、BFD制御パケットにリモートシステムから受け取りました。この変数は1に初期化する必要があります。
bfd.DemandMode
bfd.DemandMode
Set to 1 if the local system wishes to use Demand mode, or 0 if not.
ローカルシステムがない場合はオンデマンドモード、または0を使用したい場合は、1に設定してください。
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を使用したい場合は、1に設定してください。これは、最後に受信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、又は0に設定されます。この変数はゼロに初期化されなければなりません。
This variable MUST be set to zero after no packets have been received on this session for at least twice the Detection Time. This ensures that the sequence number can be resynchronized if the remote system restarts.
パケットが少なくとも二回検出時間のために、このセッションで受信された後に、この変数をゼロに設定しなければなりません。これは、リモートシステムが再起動する場合は、シーケンス番号を再同期することができることを保証します。
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が起動していない場合、システムは、1秒（1,000,000マイクロ秒）以上の値にbfd.DesiredMinTxIntervalを設定しなければなりません。これは、最大ではありませんBFDセッションによって消費される帯域幅は、特に隣人はBFDを実行することはできません場合には、ごくわずかであることを保証することを意図しています。
If the local system reduces its transmit interval due to bfd.RemoteMinRxInterval being reduced (the remote system has advertised a reduced value in Required Min RX Interval), and the remote system is not in Demand mode, the local system MUST honor the new interval immediately. In other words, the local system cannot wait longer than the new interval between the previous packet transmission and the next one. If this interval has already passed since the last transmission (because the new interval is significantly shorter), the local system MUST send the next periodic BFD Control packet as soon as practicable.
ローカルシステムが原因bfd.RemoteMinRxIntervalが縮小されることに、その送信間隔を減少させた場合（リモートシステムは、必要な分RX間隔で減少した値を宣伝している）、およびリモート・システムがオンデマンド・モードではない、ローカルシステムは、すぐに新しい間隔を尊重しなければなりません。つまり、ローカルシステムは、以前のパケット送信と次の1の間の新しい間隔より長く待つことはできません。 （新しい間隔がかなり短いので）この間隔はすでに最後の送信から経過した場合は、ローカルシステムは、できる限り速やかに次回の定期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.
エコー機能がアクティブである場合、システムは、1秒（1,000,000マイクロ秒）以上の値にbfd.RequiredMinRxIntervalを設定する必要があります。これは、実際の検出機能は、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制御パケットで通信されなければならない、または2）十分な時間ポーリングシーケンスは状況を明確にするために完了したので、前に別の投票シーケンスの開始、または最終（F）と3）の追加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の合意された送信間隔を乗じのMultは、リモート・システムから受信した検出値に等しいです間隔）。検出のMult値がダウンしてセッションを宣言するために一列に見逃されなければならないパケットの数（おおよそジッタによる、話す）されます。
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が初期化または上で、セッションがダウンした場合 - ローカルシステムで設定しなければなりません1へのダウンとbfd.LocalDiagにbfd.SessionState（コントロール検出時間期限切れ）。
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.DesiredMinTxIntervalとbfd.RemoteMinRxIntervalの大きい）の合意された送信間隔を乗じbfd.DetectMult、に等しいです。 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制御パケットの送信）を開始した後に合格した場合、セッションがダウンした - ローカルシステム（コントロールの検出時間が満了）1にまでにbfd.SessionState、及びbfd.LocalDiagを設定しなければなりません。
(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).
エコー機能が有効になっていると、セッションがダウンしている彼らが必要としてエコーパケットの十分な数が到着していない場合は - ローカルシステムは、2にダウンしてbfd.LocalDiagにbfd.SessionStateを設定しなければなりません（エコー機能が失敗しました）。
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.
Lengthフィールドは、最小正しい値未満である場合（24ビットがクリアされている場合、またはビットが設定されている場合26）、パケットは廃棄されなければなりません。
If the Length field is greater than the payload of the encapsulating protocol, the packet MUST be discarded.
Lengthフィールドは、カプセル化プロトコルのペイロードよりも大きい場合、パケットは廃棄されなければなりません。
If the Detect Mult field is zero, the packet MUST be discarded.
検出のMultフィールドが0の場合、パケットは捨てなければなりません。
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.
あなたの弁別フィールドがゼロであるとStateフィールドがダウンしているかAdminDownされていない場合、パケットは捨てなければなりません。
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がゼロでない）、Aビットがクリアされ、認証が使用されている場合、パケットは廃棄されなければなりません。
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.
状態（STA）フィールドの値にbfd.RemoteStateを設定してください。
Set bfd.RemoteDemandMode to the value of the Demand (D) bit.
デマンド（D）ビットの値にbfd.RemoteDemandModeを設定します。
Set bfd.RemoteMinRxInterval to the value of Required Min RX Interval.
必要な分RX間隔の値にbfd.RemoteMinRxIntervalを設定してください。
If the Required Min Echo RX Interval field is zero, the transmission of Echo packets, if any, MUST cease.
必要な分エコーRX Intervalフィールドがゼロの場合、エコーパケットの送信は、もしあれば、中止しなければなりません。
If a Poll Sequence is being transmitted by the local system and the Final (F) bit in the received packet is set, the Poll Sequence MUST be terminated.
ポーリングシーケンスが設定されているローカルシステムと、受信したパケット中の最終（F）ビットによって送信されている場合、ポーリングシーケンスが終了しなければなりません。
Update the transmit interval as described in section 6.8.2.
セクション6.8.2に記載したように送信間隔を更新します。
Update the Detection Time as described in section 6.8.4.
セクション6.8.4で説明したように検出時間を更新します。
If bfd.SessionState is AdminDown
bfd.SessionStateはAdminDownある場合
Discard the packet
パケットを破棄
If received state is AdminDown If bfd.SessionState is not Down Set bfd.LocalDiag to 3 (Neighbor signaled session down) Set bfd.SessionState to Down
bfd.SessionStateが3に設定されbfd.LocalDiagダウンしていない場合は受信状態がAdminDownされた場合（ネイバーセッションをダウン合図）を設定し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
Else if bfd.SessionState is Init If received State is Init or Up Set bfd.SessionState to Up
そうでなければ受信状態が最大の初期化やセットアップbfd.SessionStateある場合bfd.SessionStateは初期化されている場合
Else (bfd.SessionState is Up) If received State is Down Set bfd.LocalDiag to 3 (Neighbor signaled session down) Set bfd.SessionState to Down
受信状態が3に設定bfd.LocalDiagダウンしている場合はそうで（ネイバーセッションをダウン合図）（bfd.SessionStateがアップしている）下に設定bfd.SessionState
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）ビットが設定されている場合、ポーリング（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制御パケットの定期的な送信は、他のシステムとの自己の同期を回避するために、すなわち、間隔は0〜25％のランダム値によって減少させなければならない、最大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.RemoteDemandModeがbfd.SessionStateがアップし、1であり、そしてbfd.RemoteSessionStateがアップしている）と、ポーリングシーケンスが送信されていない場合、システムは、定期的にBFD制御パケットを送信してはいけません。
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制御パケットを受信した場合、受信システムは、ポーリング（P）ビットでBFD制御パケットを送信しなければならない明確かつ最終（F）は関係なく、できる限り速やかに設定ビットセッション状態を考慮せずに送信タイマまたは他の任意の送信の制限、であり、オンデマンドモードはいずれかのシステム上でアクティブであるかどうかに関係なく。システムは、パケットが送信されるレートを制限することができます。速度制限が有効である場合、所望の最小TXインターバルのアドバタイズされた値がより大きいまたは速度制限関数によって課される送信パケットの間隔に等しくなければなりません。
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)
診断（ダイアグ）
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.
ない場合は、ローカルシステムは、ポーリングシーケンス、または0を送信している場合は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.
ない場合にローカルシステムが制御パケットに応答している場合に1にセットは、ポーリング（P）ビットのセット、または0で受信しました。
Control Plane Independent (C)
制御プレーン独立（C）
Set to 1 if the local system's BFD implementation is independent of the control plane (it can continue to function through a disruption of the control plane).
ローカルシステムのBFDの実装は、コントロールプレーンとは独立している場合は1に設定します（これは、コントロールプレーンの破壊を介して機能し続けることができます）。
Authentication Present (A)
現在の認証（A）
Set to 1 if authentication is in use on this session (bfd.AuthType is nonzero), or 0 if not.
ない場合は、認証は、このセッションで使用されている場合（bfd.AuthTypeがゼロでない）、1に設定、または0。
Demand (D)
デマンド（D）
Set to bfd.DemandMode if bfd.SessionState is Up and bfd.RemoteSessionState is Up. Otherwise, it is set to 0.
bfd.SessionStateがアップしているとbfd.RemoteSessionStateがアップしている場合bfd.DemandModeに設定します。それ以外の場合は0に設定されています。
Multipoint (M)
マルチポイント（M）
Set to 0.
0に設定します。
Detect Mult
Multを検出
Set to bfd.DetectMult.
bfd.DetectMultに設定します。
Length
長さ
Set to the appropriate length, based on the fixed header length (24) plus any Authentication Section.
固定ヘッダ長（24）に加えて、任意の認証部に基づいて、適切な長さに設定します。
My Discriminator
私の弁別
Set to bfd.LocalDiscr.
bfd.LocalDiscrに設定します。
Your Discriminator
あなたの弁別
Set to bfd.RemoteDiscr.
bfd.RemoteDiscrに設定します。
Desired Min TX Interval
理想の分TX間隔
Set to bfd.DesiredMinTxInterval.
bfd.DesiredMinTxIntervalに設定します。
Required Min RX Interval
必要な分RX間隔
Set to bfd.RequiredMinRxInterval.
bfd.RequiredMinRxIntervalに設定します。
Required Min Echo RX Interval
必要な分エコーRX間隔
Set to the minimum required Echo packet receive interval for this session. If this field is set to zero, the local system is unwilling or unable to loop back BFD Echo packets to the remote system, and the remote system will not send Echo packets.
最小限にSET ECHOパケットがこのセッションの間隔を受ける必要。このフィールドはゼロに設定されている場合は、ローカルシステムがリモートシステムへのループバックBFDエコーパケットに不本意またはできない、とリモートシステムは、エコーパケットを送信しません。
Authentication Section
認証部
Included and set according to the rules in section 6.7 if authentication is in use (bfd.AuthType is nonzero). Otherwise, this section is not present.
（bfd.AuthTypeがゼロでない）認証が使用中である場合に含まれ、セクション6.7の規則に従って設定。それ以外の場合、このセクションは存在しません。
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.SessionStateが起動していないときBFDエコーパケットを送信してはなりません。リモートシステムから受け取った最後のBFD制御パケットが必要な分、エコーRX間隔でゼロ以外の値が含まれていない限り、BFDエコーパケットを送信してはなりません。
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.SessionStateがアップすると、BFDエコーパケットが送信されることができます。送信BFDエコーパケット間の間隔は、以下を除き、必要な最小エコー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制御パケット内のゼロまたは非ゼロに必要な最小エコー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.
ローカルシステムに転送プレーンは、リモートシステムがもはやローカルフォワーディング状態に頼ることができるように、何らかの理由でリセットされない場合、ローカルシステムは、（転送プレーンリセット）4にbfd.LocalDiagを設定し、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
適切な値に設定AdminDown bfd.LocalDiagに他の設定bfd.SessionState 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.
シグナリングは基礎のパスが失敗したこと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制御パケットは、リモート・システムが状態変化を認識していることを確実にするためにAdminDown状態に遷移した後に、少なくとも検出時間のために送信されるべきです。 BFD制御パケットは、各システム（以下のセクション6.8.18を参照のこと）でセッション状態を維持するためにAdminDown状態に遷移した後に無限に送信してもよいです。
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セッションを横切るそれらのパスのうちの一つの故障の指示を伝達することが望ましいかもしれません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つの診断コードは、この目的のために定義されています。道を連結し、連結道を逆にします。最初は（連結経路がインターワーキングシステムに向かう方向に失敗した）順方向経路障害を伝播し、第二は、（連結経路が双方向リンクを仮定して、離れて連動システムからの方向に失敗した）逆経路障害を伝播します。
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セッションを防ぐために選ぶかもしれません。一つの可能な理由は、セッションが確立される速度を管理することがあるかもしれません。これは、必要に応じて、ダウンまたはAdminDown状態でセッションを保持することによって行うことができます。
There are two related mechanisms that are available to help with this task. First, a system is REQUIRED to maintain session state (including timing parameters), even when a session is down, until a Detection Time has passed without the receipt of any BFD Control packets. This means that a system may take down a session and transmit an arbitrarily large value in the Required Min RX Interval field to control the rate at which it receives packets.
この作業を支援するために利用されている二つの関連メカニズムがあります。まず、システムは、検出時間は、任意のBFD制御パケットを受信することなく経過するまでセッションが、ダウンしている場合でも、（タイミングパラメータを含む）セッション状態を維持するために必要とされます。これは、システムがセッションを降ろすと、それがパケットを受信する速度を制御するのに必要な最小RX間隔フィールドに任意の大きな値を送信してもよいことを意味します。
Additionally, a system MAY transmit a value of zero for Required Min RX Interval to indicate that the remote system should send no packets whatsoever.
さらに、システムは、リモートシステムが全くパケットを送信しないべきであることを示すために必要な分RXインターバルゼロの値を送信してもよいです。
So long as the local system continues to transmit BFD Control packets, the remote system is obligated to obey the value carried in Required Min RX Interval. If the remote system does not receive any BFD Control packets for a Detection Time, it SHOULD reset bfd.RemoteMinRxInterval to its initial value of 1 (per section 6.8.1, since it is no longer required to maintain previous session state) and then can transmit at its own rate.
だから、長いローカルシステムがBFD制御パケットを送信するために続けて、リモートシステムが必要と分RX間隔で運ばれた値に従う義務があります。リモートシステムが検出時間のために、任意のBFD制御パケットを受信しない場合、それは1の初期値にbfd.RemoteMinRxIntervalをリセットする必要があり（もはや以前のセッション状態を維持するために必要とされるのでセクション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.
「渋滞」は交通現象でなく、計算の1だけではないことに注意してください。 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のトラフィック負荷を軽減するためのメカニズムは、分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個のパケットを生成します。ワイヤ上の各パケットの最大長さは、各方向における帯域幅消費の秒当たり約48キロビットの合計、100バイト程度です。
This document defines two registries administered by IANA. The first is titled "BFD Diagnostic Codes" (see section 4.1). Initial values for the BFD Diagnostic Code registry are given below. Further assignments are to be made through Expert Review [IANA-CONSIDERATIONS]. Assignments consist of a BFD Diagnostic Code name and its associated value.
この文書は、IANAによって投与される2つのレジストリを定義します。最初は、「BFD診断コード」（セクション4.1を参照）と題されています。 BFD診断コードレジストリの初期値は以下の通りです。また、割り当ては専門家レビュー[IANA-検討事項]を介して行われるべきです。割り当ては、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.
第二のレジストリは、「BFD認証タイプ」（4.1節を参照）と題されています。 BFD認証タイプレジストリの初期値は以下の通りです。また、割り当ては専門家レビュー[IANA-検討事項]を介して行われるべきです。割り当ては、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パケットが、他には何を転送することができます）まで宣言しました。この攻撃は、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の両方ではなく、より一般的なハッシュメッセージ認証、共有秘密鍵は、ハッシュを計算する前にデータに付加されている（また、「のみ追加」と呼ばれる）「秘密のサフィックス」構造を使用しますコード（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] TTL /ホップカウントがパケットをエコーの過程で1だけデクリメントされるものの、BFDエコーパケットに適用されるので、一方が離れるホップからなりすましが可能であることができます。
[GTSM] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
【GTSM]ギル、V.、Heasley、J.、マイヤー、D.、Savola、P.、エド。、および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.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]イーストレーク第3、D.とP.ジョーンズは、 "米国は、ハッシュアルゴリズム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.、ベラー、M.、およびR.カネッティ、 "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-考察] 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]モイ、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.
（このRFCになったインターネットドラフトの初期のバージョンで定義されている）、このプロトコルのバージョン0が広く展開されている可能性は低いですが、いくつかの実装は、下位互換性メカニズムを持つことを望むかもしれません。あらゆる機構は、潜在的に、プロトコルの定義を変更しないで使用することができるので、相互運用性が問題にすべきではないことに注意してください。
The suggested mechanism described here has the property that it will converge on version 1 if both systems implement it, even if one system is upgraded from version 0 within a Detection Time. It will interoperate with a system that implements only one version (or is configured to support only one version). A system should obviously not perform this function if it is configured to or is only capable of using a single version.
ここで説明する提案メカニズムは、両方のシステムが一つのシステムが検出時間以内バージョン0からアップグレードされた場合でも、それを実装する場合、それはバージョン1に収束する性質を有しています。これは1つのバージョンのみを実装する（または1つのバージョンのみをサポートするように構成されている）システムと相互運用します。それが設定されるか、または単一のバージョンを使用することができるだけである場合、システムは、明らかに、この機能を実行するべきではありません。
A BFD session will enter a "negotiation holddown" if it is configured for automatic versioning and either has just started up, or the session has been manually cleared. The session is set to AdminDown state and version 1. During the holddown period, which lasts for one Detection Time, the system sends BFD Control packets as usual, but ignores received packets. After the holddown time is complete, the state transitions to Down and normal operation resumes.
それは自動バージョニングのために設定されており、どちらかだけで起動した、またはセッションが手動でクリアされた場合BFDセッションは「交渉のホールドダウン」と入力します。セッションは、1つの検出時間継続ホールドダウン期間の間、状態およびバージョン1をAdminDownするように設定され、システムは通常通り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).
任意のバージョン0のパケットがセッションのために受信された場合には、自動バージョンを行って、現在のバージョン1を使用している場合、システムは、ホールドダウンしていないとき、それは現在のバージョン0とバージョン1パケットを使用している場合は、バージョン0に直ちに切り替わり隣人が状態AdminDownにあるバージョン0と1つのパケットがAdminDown以外の状態を示す受信されたバージョンを使用している場合、それはバージョン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のために、故障状態のための状態下）新しいバージョンに応じてダウンしました。
Appendix B. Contributors
付録B.協力者
Kireeti Kompella and Yakov Rekhter of Juniper Networks were also significant contributors to this document.
Kireeti Kompellaとジュニパーネットワークスのヤコフ・レックターも、このドキュメントへの重要な貢献者でした。
Appendix C. Acknowledgments
付録C.謝辞
This document was inspired by (and is intended to replace) the Protocol Liveness Protocol document, written by Kireeti Kompella.
この文書では、触発された（と置き換えることを意図している）Kireeti Kompellaによって書かれたプロトコルライブネスプロトコル文書を、。
Demand mode was inspired by "A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers", by G. Huang, et al.
デマンドモードはG.黄による「検出デッドインターネット鍵交換のトラフィックベースの方法（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.
著者はまた、実質的な入力のためのマイク・シャンド、ジョン・スカダー、スチュワートブライアント、ペッカSavola、リチャード・スペンサー、およびパシEronenに感謝したいと思います。
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.
著者らはまた、上位アドレスの実装と明快さの問題では、この仕様書の著者と複数のベンダー間の電話会議をホストするためオーウェンウィーラーに感謝したいと思います。
Authors' Addresses
著者のアドレス
Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089-1206 USA
デイブ・カッツジュニパーネットワークスの1194 N.マチルダアベニュー。サニーベール、CA 94089-1206 USA
Phone: +1-408-745-2000 EMail: dkatz@juniper.net
電話：+ 1-408-745-2000 Eメール：dkatz@juniper.net
Dave Ward Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089-1206 USA
デイブ・ワードジュニパーネットワークスの1194 N.マチルダアベニュー。サニーベール、CA 94089-1206 USA
Phone: +1-408-745-2000 EMail: dward@juniper.net
電話：+ 1-408-745-2000 Eメール：dward@juniper.net