RFC 5881

Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) 💖

Okay bestie, this is RFC 5881 🦋 and it's a Standards Track document, so it's an official Internet standard, no cap. D. Katz and D. Ward wrote it while they were at Juniper Networks, and it was published in June 2010 (ISSN 2070-1721). The title block doesn't list anything it obsoletes or updates, so it stands on its own 💅.

Abstract 🌸

This doc is all about using Bidirectional Forwarding Detection (BFD) over IPv4 and IPv6 for single IP hops 🌈

Status of This Memo 📜

This one is an Internet Standards Track document 🔥

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 5741 ✨

For the current status of this document, any errata, and how to send feedback on it, go to 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) as they stand on the date of publication. Please read these documents carefully, because they spell out 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 they come without warranty as described in the Simplified BSD License 🫶

---

1. Introduction ✨

Okay so one really useful thing you can do with Bidirectional Forwarding Detection (BFD) [BFD] is keep track of IPv4 and IPv6 connectivity between systems that are directly connected. This can back up the detection mechanisms in routing protocols, or be used to monitor router-to-host connectivity, plus a bunch of other stuff 🧚

This doc covers the particulars you need to use BFD in this setting. How BFD interacts with other protocols and system functions is covered in the BFD Generic Applications document [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 use of BFD works for any pair of systems that talk over IPv4 and/or IPv6 across a single IP hop that's tied to an incoming interface. That covers a lot, including (but not limited to) physical media, virtual circuits, and tunnels 🌸

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 🔥

If BFD is going to be used 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 💖

If the BFD Echo function is used, transmitted packets get immediately routed back toward the sender on the interface they were sent over. This can interact with other mechanisms running on the two systems that employ BFD. In particular, ingress filtering [BCP38] is incompatible with the way Echo packets need to be sent 😭 So 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 🙈

Implementing the Echo function also needs 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. That typically means access to APIs that bypass IP-layer functionality 🧚

Heads up: BFD is meant to be an Operations, Administration, and Maintenance (OAM) mechanism for connectivity checks and connection verification 👀

It applies to network-based services, like 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, so you 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 BFD doesn't have enough capability to do the necessary congestion detection and avoidance, and therefore it can't prevent congestion collapse 😭 Host-to-host or application-to-application deployment across the Internet will need BFD to be encapsulated within a transport that provides "TCP-friendly" [TFRC] behavior 🫶

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. So 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 ✨

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 active at the same time, UDP source port numbers MAY be reused across multiple sessions, but the number of distinct uses of the same UDP source port number SHOULD be minimized 🌈 An implementation MAY use the UDP source port number to help demultiplex incoming BFD Control packets, but ultimately the mechanisms in [BFD] MUST be used to demultiplex incoming packets to the proper session 🔑

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 spec 🦋 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. Specifically, the source address SHOULD NOT be part of the subnet bound to the interface the BFD Echo packet is being transmitted over, and it SHOULD NOT be an IPv6 link-local address, unless it's known by other means that the remote system won't send Redirects 👀

BFD Echo packets MUST be transmitted in such a way as to ensure they are received by the remote system. On multiaccess media, for example, this requires that the destination datalink address corresponds to the remote system 🔥

The above requirements may require bypassing some common IP-layer functionality, especially in host implementations 💅

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. You can read more about this mechanism in [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 that avoids unnecessary calculation that would be bad for the receiving system 💖

In this section, "authentication in use" means 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 🌈

6. Addressing Issues 🦋

Implementations MUST ensure that all BFD Control packets are transmitted over the one-hop path being protected by 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) 🫶

On a point-to-point link, the source address of a BFD Control packet MUST NOT be used to identify the session. This means the initial BFD packet MUST be accepted with any source address, and subsequent BFD packets MUST be demultiplexed solely by the Your Discriminator field (which is always the case). This lets the source address change if it needs to. If the received source address changes, the local system MUST NOT use that address as the destination in outgoing BFD Control packets. Instead, 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 the application can choose to change the destination address or take some other action 🌷 Also, the TTL/Hop Limit check described in section 5 (or the use of authentication) rules out BFD packets coming from any source other than the immediate neighbor 🔒

7. BFD for Use with Tunnels 🧚

There are a number of mechanisms for tunneling IPv4 and IPv6 over arbitrary topologies. If the tunnel mechanism does not decrement the TTL or Hop Limit of the network protocol carried inside, the mechanism described in this document may be used to provide liveness detection for the tunnel. The BFD authentication mechanism SHOULD be used, and it's strongly encouraged 🔥

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 🔒

Okay, this section is serious, so listen up 👀 In this application, using TTL=255 on transmit and receive, combined with an association to an incoming interface, is seen as giving security characteristics equivalent to other protocols used in the infrastructure, because it isn't trivially spoofable. The security implications of this mechanism are discussed further in [GTSM] 💀

The security implications of using BFD authentication are discussed in [BFD] 🔐

Using the TTL=255 check at the same time as BFD authentication gives you a low-overhead way to discard a class of unauthorized packets, and it may be useful in implementations where cryptographic checksum use is susceptible to denial-of-service attacks. Using or not using this mechanism does not impact interoperability 🫶

10. References 🌈

The reference list is coming in the next part, so stick around bestie 🦋

10.1. Normative References 📚

okay bestie, these are the docs this spec literally can't function without 😭 Here's the squad:

• [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. 🎀 this one is the reason all the capital words in this doc are serious

10.2. Informative References 🌸

these ones are the "good to know" friends, not the must-haves 🫶

• [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 🖋️

the two people who wrote this, both at Juniper Networks, same office, iconic duo 👑

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

---

that's the whole RFC, babe!! 🌈💅 go touch grass, you earned it 🍓