Internet Engineering Task Force (IETF) D. Katz
Request for Comments: 5881 D. Ward
Category: Standards Track Juniper Networks
ISSN: 2070-1721 June 2010
Internet Engineering Task Force (IETF) D. Katz
Request for Comments: 5881 D. Ward
Category: Standards Track Juniper Networks
ISSN: 2070-1721 June 2010
Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)
IPv4和IPv6的双向转发检测（BFD）（单跳）
Abstract
摘要
This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over IPv4 and IPv6 for single IP hops.
本文档描述了在IPv4和IPv6上对单个IP跃点使用双向转发检测（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/rfc5881.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5881.
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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
One very desirable application for Bidirectional Forwarding Detection (BFD) [BFD] is to track IPv4 and IPv6 connectivity between directly connected systems. This could be used to supplement the detection mechanisms in routing protocols or to monitor router-host connectivity, among other applications.
双向转发检测（BFD）[BFD]的一个非常理想的应用是跟踪直接连接系统之间的IPv4和IPv6连接。这可用于补充路由协议中的检测机制，或监控路由器主机连接，以及其他应用程序。
This document describes the particulars necessary to use BFD in this environment. Interactions between BFD and other protocols and system functions are described in the BFD Generic Applications document [BFD-GENERIC].
本文档描述了在此环境中使用BFD所需的详细信息。BFD与其他协议和系统功能之间的交互在BFD通用应用文件[BFD-Generic]中进行了描述。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[关键词]中所述进行解释。
This application of BFD can be used by any pair of systems communicating via IPv4 and/or IPv6 across a single IP hop that is associated with an incoming interface. This includes, but is not limited to, physical media, virtual circuits, and tunnels.
BFD的此应用程序可由通过IPv4和/或IPv6跨与传入接口关联的单个IP跃点进行通信的任何系统对使用。这包括但不限于物理介质、虚拟电路和隧道。
Each BFD session between a pair of systems MUST traverse a separate network-layer path in both directions. This is necessary for demultiplexing to work properly, and also because (by definition) multiple sessions would otherwise be protecting the same path.
一对系统之间的每个BFD会话必须在两个方向上通过单独的网络层路径。这对于解复用正常工作是必要的，而且（根据定义）多个会话将保护同一路径。
If BFD is to be used in conjunction with both IPv4 and IPv6 on a particular path, a separate BFD session MUST be established for each protocol (and thus encapsulated by that protocol) over that link.
如果BFD要与特定路径上的IPv4和IPv6一起使用，则必须为该链路上的每个协议（并因此由该协议封装）建立单独的BFD会话。
If the BFD Echo function is used, transmitted packets are immediately routed back towards the sender on the interface over which they were sent. This may interact with other mechanisms that are used on the two systems that employ BFD. In particular, ingress filtering [BCP38] is incompatible with the way Echo packets need to be sent. Implementations that support the Echo function MUST ensure that ingress filtering is not used on an interface that employs the Echo function or make an exception for ingress filtering Echo packets.
如果使用BFD回波功能，发送的数据包将立即路由回发送接口上的发送方。这可能与采用BFD的两个系统上使用的其他机制相互作用。特别是，入口过滤[BCP38]与需要发送回显数据包的方式不兼容。支持Echo函数的实现必须确保在使用Echo函数的接口上不使用入口过滤，或对入口过滤Echo数据包进行例外。
An implementation of the Echo function also requires Application Programming Interfaces (APIs) that may not exist on all systems. A system implementing the Echo function MUST be capable of sending
Echo功能的实现还需要应用程序编程接口（API），但并非所有系统上都存在这些接口。实现回声功能的系统必须能够发送
packets to its own address, which will typically require bypassing the normal forwarding lookup. This typically requires access to APIs that bypass IP-layer functionality.
将数据包发送到其自己的地址，这通常需要绕过正常的转发查找。这通常需要访问绕过IP层功能的API。
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）和错误故障检测。它不适用于跨Internet的应用程序对应用程序故障检测，因为它没有足够的能力进行必要的拥塞检测和避免，因此无法防止拥塞崩溃。跨Internet的主机到主机或应用程序到应用程序部署将需要在提供“TCP友好”[TFRC]行为的传输中封装BFD。
In this application, there will be only a single BFD session between two systems over a given interface (logical or physical) for a particular protocol. The BFD session must be bound to this interface. As such, both sides of a session MUST take the "Active" role (sending initial BFD Control packets with a zero value of Your Discriminator), and any BFD packet from the remote machine with a zero value of Your Discriminator MUST be associated with the session bound to the remote system, interface, and protocol.
在此应用程序中，对于特定协议，在给定接口（逻辑或物理）上，两个系统之间只有一个BFD会话。BFD会话必须绑定到此接口。因此，会话的双方都必须扮演“主动”角色（发送初始BFD控制数据包时，鉴别器的值为零），并且来自远程计算机且鉴别器的值为零的任何BFD数据包必须与绑定到远程系统、接口和协议的会话相关联。
BFD Control packets MUST be transmitted in UDP packets with destination port 3784, within an IPv4 or IPv6 packet. The source port MUST be in the range 49152 through 65535. The same UDP source port number MUST be used for all BFD Control packets associated with a particular session. The source port number SHOULD be unique among all BFD sessions on the system. If more than 16384 BFD sessions are simultaneously active, UDP source port numbers MAY be reused on multiple sessions, but the number of distinct uses of the same UDP source port number SHOULD be minimized. An implementation MAY use the UDP port source number to aid in demultiplexing incoming BFD Control packets, but ultimately the mechanisms in [BFD] MUST be used to demultiplex incoming packets to the proper session.
BFD控制数据包必须在IPv4或IPv6数据包内，以目标端口为3784的UDP数据包的形式传输。源端口必须在49152到65535之间。与特定会话关联的所有BFD控制数据包必须使用相同的UDP源端口号。源端口号在系统上的所有BFD会话中应是唯一的。如果超过16384个BFD会话同时处于活动状态，UDP源端口号可以在多个会话上重复使用，但应尽量减少相同UDP源端口号的不同使用次数。实现可以使用UDP端口源号来帮助解复用传入BFD控制数据包，但最终必须使用[BFD]中的机制将传入数据包解复用到适当的会话。
BFD Echo packets MUST be transmitted in UDP packets with destination UDP port 3785 in an IPv4 or IPv6 packet. The setting of the UDP source port is outside the scope of this specification. The
BFD回送数据包必须在IPv4或IPv6数据包中使用目标UDP端口3785的UDP数据包中传输。UDP源端口的设置不在本规范的范围内。这个
destination address MUST be chosen in such a way as to cause the remote system to forward the packet back to the local system. The source address MUST be chosen in such a way as to preclude the remote system from generating ICMP or Neighbor Discovery Redirect messages. In particular, the source address SHOULD NOT be part of the subnet bound to the interface over which the BFD Echo packet is being transmitted, and it SHOULD NOT be an IPv6 link-local address, unless it is known by other means that the remote system will not send Redirects.
目的地地址的选择必须使远程系统将数据包转发回本地系统。选择源地址时，必须避免远程系统生成ICMP或邻居发现重定向消息。特别是，源地址不应是绑定到正在传输BFD回波数据包的接口的子网的一部分，也不应是IPv6链路本地地址，除非通过其他方式知道远程系统不会发送重定向。
BFD Echo packets MUST be transmitted in such a way as to ensure that they are received by the remote system. On multiaccess media, for example, this requires that the destination datalink address corresponds to the remote system.
BFD回波数据包的传输方式必须确保远程系统接收到它们。例如，在多址介质上，这要求目标数据链路地址对应于远程系统。
The above requirements may require the bypassing of some common IP layer functionality, particularly in host implementations.
上述要求可能需要绕过某些常见的IP层功能，特别是在主机实现中。
If BFD authentication is not in use on a session, all BFD Control packets for the session MUST be sent with a Time to Live (TTL) or Hop Limit value of 255. All received BFD Control packets that are demultiplexed to the session MUST be discarded if the received TTL or Hop Limit is not equal to 255. A discussion of this mechanism can be found in [GTSM].
如果会话上未使用BFD身份验证，则该会话的所有BFD控制数据包必须以生存时间（TTL）或跃点限制值255发送。如果接收到的TTL或跃点限制不等于255，则必须丢弃所有接收到的解复用到会话的BFD控制数据包。关于这一机制的讨论见[GTSM]。
If BFD authentication is in use on a session, all BFD Control packets MUST be sent with a TTL or Hop Limit value of 255. All received BFD Control packets that are demultiplexed to the session MAY be discarded if the received TTL or Hop Limit is not equal to 255. If the TTL/Hop Limit check is made, it MAY be done before any cryptographic authentication takes place if this will avoid unnecessary calculation that would be detrimental to the receiving system.
如果会话上正在使用BFD身份验证，则发送所有BFD控制数据包时必须使用TTL或跃点限制值255。如果接收到的TTL或跃点限制不等于255，则所有接收到的解复用到会话的BFD控制数据包都可能被丢弃。如果进行了TTL/Hop限制检查，则可以在进行任何加密身份验证之前进行检查，前提是这将避免对接收系统有害的不必要计算。
In the context of this section, "authentication in use" means that the system is sending BFD Control packets with the Authentication bit set and with the Authentication Section included and that all unauthenticated packets demultiplexed to the session are discarded, per the BFD base specification.
在本节的上下文中，“使用中的身份验证”表示系统正在发送设置了身份验证位且包含身份验证部分的BFD控制数据包，并且根据BFD基本规范，将丢弃所有解复用到会话的未经身份验证数据包。
Implementations MUST ensure that all BFD Control packets are transmitted over the one-hop path being protected by BFD.
实现必须确保所有BFD控制数据包通过BFD保护的一跳路径传输。
On a multiaccess network, BFD Control packets MUST be transmitted with source and destination addresses that are part of the subnet (addressed from and to interfaces on the subnet).
在多址网络上，BFD控制数据包必须使用作为子网一部分的源地址和目标地址（从子网上的接口和到子网上的接口寻址）进行传输。
On a point-to-point link, the source address of a BFD Control packet MUST NOT be used to identify the session. This means that the initial BFD packet MUST be accepted with any source address, and that subsequent BFD packets MUST be demultiplexed solely by the Your Discriminator field (as is always the case). This allows the source address to change if necessary. If the received source address changes, the local system MUST NOT use that address as the destination in outgoing BFD Control packets; rather, it MUST continue to use the address configured at session creation. An implementation MAY notify the application that the neighbor's source address has changed, so that the application might choose to change the destination address or take some other action. Note that the TTL/Hop Limit check described in section 5 (or the use of authentication) precludes the BFD packets from having come from any source other than the immediate neighbor.
在点对点链路上，BFD控制数据包的源地址不得用于标识会话。这意味着必须使用任何源地址接受初始BFD数据包，并且后续BFD数据包必须仅由Your Discriminator字段解复用（通常情况下）。这允许在必要时更改源地址。如果接收到的源地址发生变化，本地系统不得将该地址用作传出BFD控制数据包中的目的地；相反，它必须继续使用会话创建时配置的地址。实现可以通知应用程序邻居的源地址已更改，以便应用程序可以选择更改目标地址或采取其他操作。注意，第5节中描述的TTL/Hop限制检查（或认证的使用）阻止BFD分组来自除直接邻居之外的任何源。
A number of mechanisms are available to tunnel IPv4 and IPv6 over arbitrary topologies. If the tunnel mechanism does not decrement the TTL or Hop Limit of the network protocol carried within, the mechanism described in this document may be used to provide liveness detection for the tunnel. The BFD authentication mechanism SHOULD be used and is strongly encouraged.
有许多机制可用于通过任意拓扑对IPv4和IPv6进行隧道传输。如果隧道机制没有降低其中携带的网络协议的TTL或Hop限制，则可以使用本文档中描述的机制为隧道提供活动性检测。应使用BFD身份验证机制，并强烈鼓励使用该机制。
Ports 3784 and 3875 were assigned by IANA for use with the BFD Control and BFD Echo protocols, respectively.
IANA分配了3784和3875端口，分别用于BFD控制和BFD回波协议。
In this application, the use of TTL=255 on transmit and receive, coupled with an association to an incoming interface, is viewed as supplying equivalent security characteristics to other protocols used in the infrastructure, as it is not trivially spoofable. The security implications of this mechanism are further discussed in [GTSM].
在该应用程序中，在发送和接收时使用TTL=255，再加上与传入接口的关联，被视为为为基础设施中使用的其他协议提供了等效的安全特性，因为这并非无稽之谈。[GTSM]中进一步讨论了该机制的安全含义。
The security implications of the use of BFD authentication are discussed in [BFD].
[BFD]中讨论了使用BFD身份验证的安全含义。
The use of the TTL=255 check simultaneously with BFD authentication provides a low overhead mechanism for discarding a class of unauthorized packets and may be useful in implementations in which cryptographic checksum use is susceptible to denial-of-service attacks. The use or non-use of this mechanism does not impact interoperability.
TTL=255检查与BFD身份验证同时使用，为丢弃一类未经授权的数据包提供了一种低开销机制，并且在加密校验和使用容易受到拒绝服务攻击的实现中可能很有用。使用或不使用此机制不会影响互操作性。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", RFC 5880, June 2010.
[BFD]Katz，D.和D.Ward，“双向转发检测”，RFC 58802010年6月。
[BFD-GENERIC] Katz, D. and D. Ward, "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, June 2010.
[BFD-通用]Katz，D.和D.Ward，“双向转发检测（BFD）的通用应用”，RFC 58822010年6月。
[GTSM] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[GTSM]Gill，V.，Heasley，J.，Meyer，D.，Savola，P.，Ed.，和C.Pignataro，“广义TTL安全机制（GTSM）”，RFC 5082，2007年10月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[BCP38]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[TFRC] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008.
[TFRC]Floyd，S.，Handley，M.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 5348，2008年9月。
Authors' Addresses
作者地址
Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089-1206 USA
Dave Katz Juniper Networks美国加利福尼亚州桑尼维尔市马蒂尔达大道北1194号，邮编94089-1206
Phone: +1-408-745-2000
EMail: dkatz@juniper.net
Phone: +1-408-745-2000
EMail: dkatz@juniper.net
Dave Ward Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089-1206 USA
Dave Ward Juniper Networks美国加利福尼亚州桑尼维尔马蒂尔达大道北1194号，邮编94089-1206
Phone: +1-408-745-2000
EMail: dward@juniper.net
Phone: +1-408-745-2000
EMail: dward@juniper.net