RFC5881 翻译

15年看协议时写的

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

 

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)

 

Abstract

 

This document describes the use of the Bidirectional Forwarding

Detection (BFD) protocol over IPv4 and IPv6 for single IP hops.

 

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

Copyright (c) 2010 IETF Trust and the persons identified as the document authors.                   All rights reserved.

 

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.

 

 

 

 

 

 

 

 

 

 

 

 

1. Introduction

 

介绍

 

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的重要应用是跟踪直连系统的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-GENERIC中。

 

 

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

 

2.  Applications and Limitations

 

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的路径上，它必须为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回声功能被使用，传输包会被立即返回给发送者通过他们被发送的接口。这会和其他机制产生影响。特别是入口过滤和回声报文的发送方式是相互矛盾的。支持回声功能的实现必须保证入口过滤不能在启用了 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

 

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.

 

Echo功能也要求应用程接口不可以存在于所有系统上，开启echo功能的系统必须能将包发给自己的地址。这需要绕过普通的转发换回检查，需要接入绕过IP层功能的应用接口。

 

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不能应用于应用程序到应用程序的检测，它没有能力做拥塞检测和避免因此不能阻止阻塞崩溃。主机到主机或者应用到应用的internet调度需要BFD在一个提供”TCP-friendly”[TFRC]行为的运输封装。

 

3.  Initialization and Demultiplexing

 

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会话必须被绑定到这个接口。因此会话的双方都要应用主动模式(发送第一个包的Your Discriminator为0)。任何远端机器发送的带有0值Your discriminator的包必须关联到会话所绑定的 远端系统，接口和协议上。即一个会话须和特定的远端系统，接口和协议绑定。

（注：这里应默认为BFD检测链路均为双向的，这样BFD在两个方向上通过一条链路。因为单向链接在[RFC5883]中讨论它被归类于多跳路径）

 

4.  Encapsulation

   

    封装

 

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控制报文须封装在UDP包内，目的端口号3784.源端口号49152~65535.关联一个特定会话的所有BFD控制报文必须使用相同的UDP端口。一个系统上的不同的BFD会话须有唯一的源端口号。如果超过16384个BFD会话同时运行，但是同一UDP源端口号的使用次数应该最小化(比如超出两会话则可以一个再使用49152，一个使用49153，而不是两个都使用49152)。一个实现可以使用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

 

 

 

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.

 

BFD Echo报文须封装在UDP内，目的端口号为3785。源端口号的设置不再本协议讨论范围内。目的地址必须可以让远端系统转发包到本地系统。源地址必须令远端系统地址不产生ICMP或者邻居发现重定向信息。特别是，源地址不能在传送BFD回声报文的接口绑定的子网中，也不能是IPV6 link-local address，除非有其他消息告知远端不会发送重定向。

 

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 Echo的传送方式必须保证远端能收到，例如，在多址媒介中目的数据链地址应该与远端系统一致。

 

The above requirements may require the bypassing of some common IP

layer functionality, particularly in host implementations.

 

上述要求需要特定的主机实须绕过一些普通的IP层功能。

 

 

5.  TTL/Hop Limit Issues

 

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 authentication不在一个会话上启用，所有的bfd控制报文须有值为255的TTl或Hop，所有这个会话接收的TTL Or Hop Limit不是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 authentication启用了，TTL与Hop的值必须设为255.接收到不为255的包应该被丢弃。如果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.

 

本部分中 认证被使用意味着系统发送Authentication字段被置位的控制包，认证部分包含在内而且所有被分到这个会话的无认证的包都将被丢弃，这是按照BFD基本规则的。

 

 

 

6.  Addressing Issues

 

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 Discrminator区分，这允许源地址按需要变化。当接受到的源地址变化时，本地不可以将变化后的对方源地址作为新的目的地址用在外出的BFD控制包中。要继续使用会话创建时配置的地。，一种实现可能会通告应用对方的源地址已变化，，应用决定是否变化目的地址或采取其他行动。注意TTL/Hop Limit 检查（或者认证的使用）阻止任何来自除直接邻居之外的源的BFD包。

7.  BFD for Use with Tunnels

   

    和隧道一同使用的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 Limit.本文提供的机制可为隧道提供活性检测。BFD认证应该被使用并且时被鼓励的。

 

8.  IANA Considerations

 

Ports 3784 and 3875 were assigned by IANA for use with the BFD Control and BFD Echo protocols, respectively.

 

9.  Security Considerations

   

    安全

 

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.

 

Tll=255检测同BFD认证的使用为丢弃无认证的包提供了一种低开销机制，这对于某些易受DoS攻击的密码校验和使用是很有用的。

 

10.  References

 

10.1.  Normative References

 

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

Detection", RFC 5880, June 2010.

 

[BFD-GENERIC] Katz, D. and D. Ward, "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, June 2010.

 

[GTSM]        Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.

 

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

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

 

10.2.  Informative References

 

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

 

[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

Juniper Networks

1194 N. Mathilda Ave.

Sunnyvale, CA  94089-1206

USA

 

Phone: +1-408-745-2000

EMail: dward@juniper.net