RFC 5883

Bidirectional Forwarding Detection (BFD) for Multihop Paths 🦋

Okay bestie, this is RFC 5883 📜, and it's all about running BFD over multihop paths. It's a Standards Track doc (ISSN 2070-1721) from June 2010, written by Dave Katz and Dave Ward at Juniper Networks 💜. The title block doesn't list any RFC that it obsoletes or updates, so it's standing on its own ✨.

Abstract

This doc explains how to use the Bidirectional Forwarding Detection (BFD) protocol over multihop paths, including unidirectional links 🌈.

Status of This Memo

This is an Internet Standards Track document 🎀.

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

For the current status, any errata, and how to give feedback, go to 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 ©️.

This doc 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 publication date. Please read these carefully, because they spell out your rights and restrictions 🫶. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 💅.

---

1. Introduction ✨

Okay so, BFD [BFD] gives you a way to check liveness on arbitrary paths between systems 💖. The BFD one-hop spec [BFD-1HOP] covers how to use BFD across single hops of IPv4 and IPv6 🧚.

But BFD is also super useful on arbitrary paths between systems. Those can span multiple network hops and take unpredictable routes 🗺️. Plus, two systems might have several paths between them, and those paths might overlap. This doc is all about how to use BFD in those situations 🌸.

1.1. Conventions Used in This Document

Here's the vibe check on the key words: 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. Applicability 🌷

Please note that BFD is an Operations, Administration, and Maintenance (OAM) mechanism for connectivity check and connection verification 🔍. It fits 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 😭. BFD is NOT for application-to-application failure detection across the Internet. It doesn't have the capability to do the congestion detection and avoidance needed, so it can't prevent congestion collapse 💀. For host-to-host or application-to-application deployment across the Internet, you will require BFD to be encapsulated within a transport that provides "TCP-friendly" [TFRC] behavior 🦋.

3. Issues 🎀

There are three main issues when you use BFD on multihop paths 👑.

The first one is security and spoofing. [BFD-1HOP] has a lightweight way to avoid spoofing by requiring a Time to Live (TTL)/Hop Limit of 255 on both transmit and receive, but that obviously doesn't work across multiple hops 🙈. BFD authentication is how this issue gets fixed ✨.

The second one is trickier: you have to demultiplex multiple BFD sessions between the same pair of systems to the right BFD session 🧩. The first BFD packet received for a session might carry a Your Discriminator value of zero, which makes it ambiguous which session it belongs to 🌀. Once the discriminator values have been exchanged, all the later packets get demultiplexed to the right BFD session solely by the contents of the Your Discriminator field 💜.

[BFD-1HOP] handles this by requiring that multiple sessions traverse independent physical or logical links, so the first packet gets demultiplexed based on the link it came in on 🔗. In the more general case, though, this scheme can't work, because two paths running BFD might overlap to an arbitrary degree (including the first and/or last hop) 😵‍💫.

Finally, the Echo function MUST NOT be used over multiple hops 🚫. Intermediate hops would route the packets right back to the sender, so you could never verify connectivity through the whole path 💅.

4. Demultiplexing Packets 🧚

There are a bunch of ways to solve the demultiplexing issue, and which one you use depends on your application 🍓.

4.1. Totally Arbitrary Paths

Sometimes you want BFD for liveness detection over paths where no part of the route is known (or, if it is known, it might not be stable) 🌪️. A straightforward approach 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 🫶.

In this scenario, the initial packet gets demultiplexed to the right BFD session based on the source/destination address pair when Your Discriminator is set to zero 🎯.

This approach is great for general connectivity detection between systems over routed paths, and it's also useful for OSPF Virtual Links [OSPFv2] [OSPFv3] 🌈.

4.2. Out-of-Band Discriminator Signaling

Another way to handle demultiplexing is to signal the discriminator values in each direction through an out-of-band mechanism before the BFD session gets established 📨. Once they're learned, the discriminators are sent as usual in the BFD Control packets, and no packets with Your Discriminator set to zero are ever sent 🙅‍♀️. The BFD MPLS spec [BFD-MPLS] uses this method 💜.

This is a big win because it lets other system components, which already know the paths in use, direct BFD. From the BFD implementation side, it's also really simple 😌.

The catch is that it needs at least some BFD-specific knowledge in parts of the system outside of BFD 😬.

4.3. Unidirectional Links

Unidirectional links count as multihop paths 🛣️. The return path (which should exist at some level, or the link isn't very useful) can 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 going to carry a single BFD session, you can do that with the single-hop approach 🔁.)

Either of the two methods above can be used for unidirectional links, but there's a more general solution that lives entirely inside BFD and doesn't have those limitations 🌟.

This approach is similar to the one-hop spec, since the unidirectional link is a single hop 🦋. Let's call the two systems the Unidirectional Sender and the Unidirectional Receiver 🎀. 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 👑.

In the Passive role, by definition, the Unidirectional Receiver doesn't transmit any BFD Control packets until it learns the discriminator value the other system is using (once it gets the first BFD Control packet) 👀. The Unidirectional Receiver demultiplexes that first packet to the proper BFD session based on the physical or logical link it came in on 🔗. That lets the receiver learn the remote discriminator value, and then it echoes that value back to the sender in its own (arbitrarily routed) BFD Control packet ✨. After that, every packet gets demultiplexed solely by discriminator 💖.

5. Encapsulation 📦

BFD Control packets for multihop use over IPv4 and IPv6 are encapsulated the same way [BFD-1HOP] defines, with one exception: the UDP destination port MUST have a value of 4784 🔢. That helps with demultiplexing and internal routing of incoming BFD packets 🚦.

6. Authentication 🔐

Multihop paths expose BFD to spoofing, no cap 😱. As the number of hops goes up, so does the exposure to attack 📈. Because of that, implementations of BFD SHOULD utilize cryptographic authentication over multihop paths to help mitigate denial-of-service attacks 🛡️.

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. This is serious, bestie 💀. Strong forms of authentication are 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
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA  94089-1206
USA

Phone: +1-408-745-2000
EMail: dward@juniper.net