Internet Engineering Task Force (IETF) D. Katz
Request for Comments: 5883 D. Ward
Category: Standards Track Juniper Networks
ISSN: 2070-1721 June 2010
Bidirectional Forwarding Detection (BFD) for Multihop Paths
Abstract
抽象
This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over multihop paths, including unidirectional links.
この文書では、単方向リンクを含むマルチホップパス上双方向フォワーディング検出（BFD）プロトコルの使用を記載しています。
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/rfc5883.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5883で取得することができます。
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ライセンスのテキストを含める必要があり、この文書から抽出されました。
The Bidirectional Forwarding Detection (BFD) protocol [BFD] defines a method for liveness detection of arbitrary paths between systems. The BFD one-hop specification [BFD-1HOP] describes how to use BFD across single hops of IPv4 and IPv6.
双方向フォワーディング検出（BFD）プロトコル[BFDは】システム間の任意の経路の生存性を検出するための方法を定義します。 BFDワンホップ仕様[BFD-1HOP]はIPv4とIPv6の単一ホップを横切るBFDを使用する方法について説明します。
BFD can also be useful on arbitrary paths between systems, which may span multiple network hops and follow unpredictable paths. Furthermore, a pair of systems may have multiple paths between them that may overlap. This document describes methods for using BFD in such scenarios.
BFDはまた、複数のネットワークホップに及ぶと予測不可能な経路をたどることができるシステムとの間の任意の経路、に有用であり得ます。さらに、システムのペアがオーバーラップすることができるそれらの間の複数のパスを有していてもよいです。この文書では、このようなシナリオでBFDを使用する方法を説明しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [KEYWORDS]で説明されるように解釈されます。
Please note that BFD is intended as an Operations, Administration, and Maintenance (OAM) mechanism for connectivity check and connection verification. It is applicable for network-based services (e.g. router-to-router, subscriber-to-gateway, LSP/circuit endpoints, and service appliance failure detection). In these scenarios it is required that the operator correctly provision the rates at which BFD is transmitted to avoid congestion (e.g link, I/O, CPU) and false failure detection. It is not applicable for application-to-application failure detection across the Internet because it does not have sufficient capability to do necessary congestion detection and avoidance and therefore cannot prevent congestion collapse. Host-to-host or application-to-application deployment across the Internet will require the encapsulation of BFD within a transport that provides "TCP-friendly" [TFRC] behavior.
BFDは、接続性チェックとの接続検証のための運用、管理、および保守（OAM）メカニズムとして意図されていることに注意してください。これは、ネットワークベースのサービス（例えば、ルーター、加入者へのゲートウェイ、LSP /回路エンドポイント、およびサービス機器故障検出）のために適用可能です。これらのシナリオでは、それが必要とされているオペレータ正しく規定BFDは、混雑を避けるために送信されるレートを（例えばリンク、I / O、CPU）と、偽の障害検出。それが必要な輻輳検出と回避を行うための十分な機能を持っていないため、輻輳崩壊を防ぐことができないので、それはインターネットを介してアプリケーション間の障害検出には適用されません。ホスト間、インターネット経由またはアプリケーション・ツー・アプリケーションの展開、「TCPフレンドリー」[TFRC]動作を提供し、トランスポート内BFDのカプセル化が必要になります。
There are three primary issues in the use of BFD for multihop paths. The first is security and spoofing; [BFD-1HOP] describes a lightweight method of avoiding spoofing by requiring a Time to Live (TTL)/Hop Limit of 255 on both transmit and receive, but this obviously does not work across multiple hops. The utilization of BFD authentication addresses this issue.
マルチホップパスのBFDの使用における3つの主要な問題があります。最初は、セキュリティとなりすましです。 [BFD-1HOPは（TTL）の生存時間を要求することによって、なりすましを回避する軽量の方法を記載している/送受信が、これは明らかに複数のホップにわたって機能しないの両方で255のホップ限界。 BFD認証の利用は、この問題を解決します。
The second, more subtle, issue is that of demultiplexing multiple BFD sessions between the same pair of systems to the proper BFD session. In particular, the first BFD packet received for a session may carry a Your Discriminator value of zero, resulting in ambiguity as to which session the packet should be associated. Once the discriminator values have been exchanged, all further packets are demultiplexed to the proper BFD session solely by the contents of the Your Discriminator field.
二、より微妙な、問題は適切なBFDセッションにシステムの同じペア間で複数のBFDセッションを逆多重化することです。具体的には、セッションのために受信された最初のBFDパケットはセッションパケットが関連付けられるべきであるよう曖昧さをもたらす、ゼロのあなたのディスクリミネータ値を有していてもよいです。弁別値が交換されたら、他の全てのパケットは、単にあなたの弁別フィールドの内容によって適切なBFDセッションに多重分離されます。
[BFD-1HOP] addresses this by requiring that multiple sessions traverse independent physical or logical links -- the first packet is demultiplexed based on the link over which it was received. In the more general case, this scheme cannot work, as two paths over which BFD is running may overlap to an arbitrary degree (including the first and/or last hop).
[BFD-1HOP]アドレス、この複数のセッションは、独立した物理的または論理的なリンクを横断することを要求することによって - 最初のパケットは、それが受信した上リンクに基づいて分離されます。より一般的な場合では、この方式は、BFDは、（第一及び/又は最終ホップを含む）を任意の程度まで重複し得る実行している上に二つの経路として、働くことができません。
Finally, the Echo function MUST NOT be used over multiple hops. Intermediate hops would route the packets back to the sender, and connectivity through the entire path would not be possible to verify.
最後に、エコー機能は、複数のホップの上に使用してはいけません。中間ホップは、送信者へのルートのパケットをバックだろう、とパス全体を通して接続が検証することはできません。
There are a number of possibilities for addressing the demultiplexing issue that may be used, depending on the application.
アプリケーションに応じて、使用することができる分離の問題に対処するための多くの可能性があります。
It may be desired to use BFD for liveness detection over paths for which no part of the route is known (or if known, may not be stable). A straightforward approach to this problem is to limit BFD deployment to a single session between a source/destination address pair. Multiple sessions between the same pair of systems must have at least one endpoint address distinct from one another.
経路のどの部分が知られていない（または既知の場合、安定ではないかもしれない）対象のパスを介しライブネス検出のためにBFDを使用することが望ましいです。この問題に対する直接的なアプローチは、送信元/宛先アドレスペア間の単一のセッションにBFDの展開を制限することです。システムの同じ対の間の複数のセッションは、互いに異なる少なくとも1つのエンドポイントアドレスを有していなければなりません。
In this scenario, the initial packet is demultiplexed to the appropriate BFD session based on the source/destination address pair when Your Discriminator is set to zero.
あなたの弁別がゼロに設定されている場合、このシナリオでは、最初のパケットは、送信元/宛先アドレスのペアに基づいて、適切なBFDセッションに分離されます。
This approach is appropriate for general connectivity detection between systems over routed paths and is also useful for OSPF Virtual Links [OSPFv2] [OSPFv3].
このアプローチは、ルーティングパス上のシステム間の一般的な接続の検出に適しているとOSPF仮想リンク【のOSPFv2] [OSPFv3の]にも有用です。
Another approach to the demultiplexing problem is to signal the discriminator values in each direction through an out-of-band mechanism prior to establishing the BFD session. Once learned, the discriminators are sent as usual in the BFD Control packets; no packets with Your Discriminator set to zero are ever sent. This method is used by the BFD MPLS specification [BFD-MPLS].
分離問題に対する別のアプローチは、BFDセッションを確立する前に、アウトオブバンド機構を介して各方向にディスクリミネータ値をシグナリングすることです。一度学んだ、弁別は、BFD制御パケットでいつものように送信されます。ゼロに設定あなたの弁別とはパケットは、これまで送信されません。この方法は、BFD MPLS仕様[BFD-MPLS]によって使用されます。
This approach is advantageous because it allows BFD to be directed by other system components that have knowledge of the paths in use, and from the perspective of BFD implementation it is very simple.
それはBFDは、使用中のパスの知識を持つ他のシステム構成要素によって指示されることを可能にし、BFDの実装の観点から、それは非常に簡単であるので、このアプローチは有利です。
The disadvantage is that it requires at least some level of BFD-specific knowledge in parts of the system outside of BFD.
欠点は、BFDの外部システムの一部でBFD固有知識の少なくともいくつかのレベルを必要とすることです。
Unidirectional links are classified as multihop paths because the return path (which should exist at some level in order to make the link useful) may be arbitrary, and the return paths for BFD sessions protecting parallel unidirectional links may overlap or even be identical. (If two unidirectional links, one in each direction, are to carry a single BFD session, this can be done using the single-hop approach.)
（リンクは便利にするためにいくつかのレベルで存在するべきである）リターンパスは任意であってもよく、平行単一方向リンクを保護BFDセッションのリターンパスが重複あるいは同一であってもよいので、単方向リンクは、マルチホップ経路として分類されます。 （2つの単方向リンクは、各方向に1が、単一のBFDセッションを搬送するようにしている場合、これは単一ホップアプローチを使用して行うことができます。）
Either of the two methods outlined earlier may be used in the unidirectional link case, but a more general solution can be found strictly within BFD and without addressing limitations.
先に概説した二つの方法のいずれかは、単方向リンクの場合に使用されてもよいが、より一般的な解決策は、厳密BFD内及び制限に対処することなく求めることができます。
The approach is similar to the one-hop specification, since the unidirectional link is a single hop. Let's define the two systems as the Unidirectional Sender and the Unidirectional Receiver. In this approach, the Unidirectional Sender MUST operate in the Active role (as defined in the base BFD specification), and the Unidirectional Receiver MUST operate in the Passive role.
単方向リンクは、単一のホップであるのでアプローチは、ワンホップ仕様と同様です。のは、単方向送信者と受信者単方向として2つのシステムを定義してみましょう。このアプローチでは、単方向送信者は、積極的な役割（ベースBFD仕様で定義されている）で動作する必要があり、一方向受信機は受動的な役割で動作しなければなりません。
In the Passive role, by definition, the Unidirectional Receiver does not transmit any BFD Control packets until it learns the discriminator value in use by the other system (upon receipt of the first BFD Control packet). The Unidirectional Receiver demultiplexes the first packet to the proper BFD session based on the physical or logical link over which it was received. This allows the receiver to learn the remote discriminator value, which it then echoes back to the sender in its own (arbitrarily routed) BFD Control packet, after which time all packets are demultiplexed solely by discriminator.
それは（最初のBFD制御パケットを受信すると）、他のシステムによって使用中のディスクリミネータ値を学習するまで、受動的な役割では、定義により、単方向受信機は、任意のBFD制御パケットを送信しません。単方向受信器は、それを受信した上で物理的または論理的なリンクに基づいて適切なBFDセッションの最初のパケットを分離します。これは、受信機は、すべてのパケットが単に弁別により分波された時間の後、それはそれ自体の中に、送信者にエコーバックリモート弁別値、（任意にルーティングされた）BFD制御パケットを、学ぶことができます。
The encapsulation of BFD Control packets for multihop application in IPv4 and IPv6 is identical to that defined in [BFD-1HOP], except that the UDP destination port MUST have a value of 4784. This can aid in the demultiplexing and internal routing of incoming BFD packets.
UDP宛先ポートが4784.の値を有しなければならないことを除いて、IPv4およびIPv6におけるマルチホップアプリケーションのためのBFD制御パケットのカプセル化は[BFD-1HOP]で定義されたものと同一であり、これは、逆多重化、着信BFDの内部ルーティングを助けることができますパケット。
By their nature, multihop paths expose BFD to spoofing. As the number of hops increases, the exposure to attack grows. As such, implementations of BFD SHOULD utilize cryptographic authentication over multihop paths to help mitigate denial-of-service attacks.
その性質上、マルチホップパスがなりすましにBFDを公開します。ホップ数が増加すると、攻撃への露出が成長します。そのため、BFDの実装は、サービス拒否攻撃を軽減するためにマルチホップの経路上の暗号化認証を利用すべきです。
Port 4784 has been assigned by IANA for use with BFD Multihop Control.
ポート4784は、BFDマルチホップコントロールで使用するためのIANAによって割り当てられています。
As the number of hops increases, BFD becomes further exposed to attack. The use of strong forms of authentication is strongly encouraged.
ホップの数が増加するように、BFDは、さらに攻撃にさらされるようになります。認証の強い形の使用が強く推奨されます。
No additional security issues are raised in this document beyond those that exist in the referenced BFD documents.
追加のセキュリティ上の問題が参照BFDの文書に存在するものを超えて、この文書で提起されていません。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", RFC 5880, June 2010.
[BFD]カッツ、D.とD.ウォード、 "双方向フォワーディング検出"、RFC 5880、2010年6月。
[BFD-1HOP] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010.
[BFD-1HOP]カッツ、D.およびD.区、 "IPv4およびIPv6（シングルホップ）のための双方向フォワーディング検出（BFD）"、RFC 5881、2010年6月。
[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月。
[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010.
[BFD-MPLS]アガルワル、R.、Kompella、K.、ナドー、T.、およびG.ツバメ、 "双方向フォワーディング検出（BFD）MPLSラベルの（LSPを）パスのスイッチ" 2010年6月、RFC 5884を。
[OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
【のOSPFv2]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[OSPFv3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
【のOSPFv3] Coltun、R.、ファーガソン、D.、モイ、J.、およびA. Lindem、 "IPv6のためのOSPF"、RFC 5340、2008年7月。
[TFRC] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008.
[TFRC]フロイド、S.、ハンドリー、M.、Padhye、J.、およびJ.ウィトマー、 "TCPフレンドリーレート制御（TFRC）：プロトコル仕様"、RFC 5348、2008年9月。
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