RFC5883 翻译-CSDN博客

黑色为原文，紫色为翻译，蓝色为我添加的内容

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.

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. Copyright Notice

版权

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.

Introduction

介绍

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-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的方法。

1.1. Conventions Used in This Document

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].

Applicability

适用性

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的）和错误的故障探测。它不适用于因特网上应用到应用的故障探测，因为它没有足够的能力来做必要的阻塞发现和保护，因此不能阻止阻塞崩溃。因特网上主机到主机或者应用到应用的部署需要BFD封装在提供TCP友好的运输机中。

Issues

要点问题

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的使用有三个主要问题。第一个是安全和欺骗；[BFD-1HOP]描述了一种避免欺骗的轻负荷方法，就是要求收发报文的(TTL)/Hop Limit 设为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.

第二个，更微妙的问题是如何将同一对系统上多重会话的分用到适当会话上。尤其是对于一个会话，第一个被接收的报文的Your discriminatory是0，导致不能明确这个包应该关联到哪个会话上。一旦discriminator值被改变，所有未来的包仅依靠Your Discriminator字段的内容来分到合适的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会话）来解决这个问题，第一个包根据它被接收的链路来分用。更一般的情况下这种方法不能奏效，运载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.

最后一个问题，回声功能不能用于多跳。中间跳路由会使这个包返回到它的发送者，完整路径上的连通性将不能被验证。

Demultiplexing Packets

分发包（分配）

There are a number of possibilities for addressing the demultiplexing issue that may be used, depending on the application.

依据（本文的）这种应用，有很多方法可以用来解决分用问题。

4.1. Totally Arbitrary Paths

完全任意路径

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会话。一对系统上任意两个会话至少有一端地址不同。。

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.

在这种场景中当Your Discriminator为0时，根据源/目的地址对来分用会话。

This approach is appropriate for general connectivity detection between systems over routed paths and is also useful for OSPF Virtual Links [OSPFv2] [OSPFv3].

这种方法适用于一般通过路由路径的系统间的连接性探测，也可以用于OSPFV虚拟链路 [OSPFv2] [OSPFv3]。

4.2. Out-of-Band Discriminator Signaling

带外Discriminator信号

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].

另一种解决分发问题的方法是通过带外机制在每个方向上发送discriminator值来建立BFD会话。一旦学习完，discriminators在通常的BFD控制包中被发送；没有Your Discriminator设为0的包被发送。这种方法被用于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-特定知识。

4.3. Unidirectional Links

单向链接

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保护的平行单向路径的返回路径可能是重叠或完全相同的（即，多条单向路径的返回路径可以重叠或者相同）。（如果两个单向路径在两个方向上各一个，它们运行一个BFD会话，这种情况可以用单跳方法。）

注：用BFD检测单向路径的连通性必须为其配一个返回路径，因为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.

上面两种方法（4.1与 4.2的方法）都可以用于单向链路情况，但是有更一般的办法，它完全在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.

由于单向链接是单跳的，这种方法和单跳BFD相似。我们定义两个系统作为单向发送者和单向接收者。在这种方法中，单向发送者必须运行在主动模式（在基础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控制包直到它学习了（根据第一个接收的包）另一个系统使用的discriminator值。被动接受者根据它接收包的物理或者逻辑链路分发这个包到适配的BFD会话上。这允许接收者学习远端的discriminator值，并在所有的包仅根据discriminator被分发完后，将它放在自己（任意路由的）BFD控制包中回传给发送者。

Encapsulation

封装

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.

IPv4和IPv6的多跳应用的BFD控制报文封装和[BFD-1HOP]中定义的一样，除了UDP目的端口必须为4784.这可以帮助对进来的BFD包进行分发和路由选择。

Authentication

认证

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实现应该在多跳路径上使用密码认证来帮助减轻QOS（拒绝服务）攻击

7. IANA Considerations

Port 4784 has been assigned by IANA for use with BFD Multihop

Control.

8. Security Considerations

As the number of hops increases, BFD becomes further exposed to attack. The use of strong forms of authentication is strongly encouraged.

No additional security issues are raised in this document beyond those that exist in the referenced BFD documents.

9. References

9.1. Normative References

[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding

Detection", RFC 5880, June 2010.

[BFD-1HOP] Katz, D. and D. Ward, "Bidirectional Forwarding Detection

(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June

2010.

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate

Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2. Informative References

[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.

[OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [OSPFv3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF

for IPv6", RFC 5340, July 2008.

[TFRC] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC

5348, September 2008. Authors’ Addresses

Dave Katz

Juniper Networks

1194 N. Mathilda Ave.

Sunnyvale, CA 94089-1206

USA

Phone: +1-408-745-2000

EMail: dkatz@juniper.net

Dave Ward