RFC 5880
Bidirectional Forwarding Detection (BFD)
Bidirectional Forwarding Detection (BFD) 🎀
Bestie, this is RFC 5880, and it's all about Bidirectional Forwarding Detection (BFD) 💖. It's an IETF Standards Track doc from June 2010 (ISSN 2070-1721), written by D. Katz and D. Ward over at Juniper Networks ✨. Neither of them is credited with obsoleting or updating anything, since the title block doesn't list any RFCs there. Super clean 🧚
Abstract ✨
Okay so this doc describes a protocol for catching faults on the two-way path between two forwarding engines 🦋. That covers the interfaces, the data link(s), and, as far as it can, the forwarding engines themselves, and it can do it with potentially super low latency 🔥. The best part is that it doesn't care what media you're using, what data protocols you're running, or which routing protocols are around 💅.
Status of This Memo 🌸
This is an Internet Standards Track document, bestie 🫶
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 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, go to http://www.rfc-editor.org/info/rfc5880 💜
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, which you can find at http://trustee.ietf.org/license-info, as they were in effect on the date this document was published. Read these carefully 🙈, because they spell out your rights and restrictions for this document. Any 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 without warranty as described in the Simplified BSD License 🎀
Table of Contents 🦋
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Design ..........................................................4
3. Protocol Overview ...............................................5
3.1. Addressing and Session Establishment .......................5
3.2. Operating Modes ............................................5
4. BFD Control Packet Format .......................................7
4.1. Generic BFD Control Packet Format ..........................7
4.2. Simple Password Authentication Section Format .............11
4.3. Keyed MD5 and Meticulous Keyed MD5 Authentication
Section Format ............................................11
4.4. Keyed SHA1 and Meticulous Keyed SHA1
Authentication Section Format .............................13
5. BFD Echo Packet Format .........................................14
6. Elements of Procedure ..........................................14
6.1. Overview ..................................................14
6.2. BFD State Machine .........................................16
6.3. Demultiplexing and the Discriminator Fields ...............17
6.4. The Echo Function and Asymmetry ...........................18
6.5. The Poll Sequence .........................................19
6.6. Demand Mode ...............................................19
6.7. Authentication ............................................21
6.7.1. Enabling and Disabling Authentication ..............21
6.7.2. Simple Password Authentication .....................22
6.7.3. Keyed MD5 and Meticulous Keyed MD5 Authentication ..23
6.7.4. Keyed SHA1 and Meticulous Keyed SHA1
Authentication .....................................25
6.8. Functional Specifics ......................................27
6.8.1. State Variables ....................................27
6.8.2. Timer Negotiation ..................................30
6.8.3. Timer Manipulation .................................31
6.8.4. Calculating the Detection Time .....................32
6.8.5. Detecting Failures with the Echo Function ..........33
6.8.6. Reception of BFD Control Packets ...................33
6.8.7. Transmitting BFD Control Packets ...................36
6.8.8. Reception of BFD Echo Packets ......................39
6.8.9. Transmission of BFD Echo Packets ...................39
6.8.10. Min Rx Interval Change ............................40
6.8.11. Min Tx Interval Change ............................40
6.8.12. Detect Multiplier Change ..........................40
6.8.13. Enabling or Disabling The Echo Function ...........40
6.8.14. Enabling or Disabling Demand Mode .................40
6.8.15. Forwarding Plane Reset ............................41
6.8.16. Administrative Control ............................41
6.8.17. Concatenated Paths ................................41
6.8.18. Holding Down Sessions .............................42
7. Operational Considerations .....................................43
8. IANA Considerations ............................................44
9. Security Considerations ........................................45
10. References ....................................................46
10.1. Normative References .....................................46
10.2. Informative References ...................................47
Appendix A. Backward Compatibility (Non-Normative) ................48
Appendix B. Contributors ..........................................48
Appendix C. Acknowledgments .......................................491. Introduction ✨
Okay, so a super important thing networking gear needs is catching communication failures between neighboring systems fast, so it can switch over to other paths quickly 🏃♀️💨. Detection can be pretty speedy when data link hardware gets involved, like with Synchronous Optical Network (SONET) alarms 🚨. But some media don't give you that kind of signaling, like Ethernet 🙃, and some media can't spot certain failures in the path at all, like failing interfaces or forwarding engine components 💀.
Networks usually rely on slow "Hello" mechanisms, typically in routing protocols, to find failures when there's no hardware signaling to help out 🐢. The "Detection Times" the existing protocols can manage are no better than a second, and bestie, that's way too long for some apps and means a ton of lost data at gigabit rates 😭. On top of that, routing protocol Hellos are no help at all when those routing protocols aren't running, and detection means something a little different for them anyway, since they only detect a failure in the path between the two routing protocol engines 🧐.
So the goal of Bidirectional Forwarding Detection (BFD) is to give you low-overhead, short-duration detection of failures in the path between adjacent forwarding engines 🎯. That includes the interfaces, the data link(s), and, to the extent possible, the forwarding engines themselves 💖.
There's also a bonus goal: one single mechanism for liveness detection over any media, at any protocol layer, with a wide range of Detection Times and overhead, so we don't end up with a whole proliferation of different methods 🌈.
This document specifies the details of the base protocol 📝. Some mechanisms are application dependent, and those are specified in a separate series of application documents, and these issues are so noted 🦋.
Also, a lot of the exact mechanisms are implementation dependent and won't affect interoperability, so they're outside the scope of this spec, and those issues are so noted too 🫶.
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. Design 🎀
BFD is designed to detect failures in communication with a forwarding plane next hop 🦋. It's meant to live in some component of a system's forwarding engine, for cases where the forwarding and control engines are separated 🧚. This doesn't just tie the protocol more tightly to the forwarding plane, it also decouples it from whatever happens to the routing protocol engine, which makes it useful alongside various "graceful restart" mechanisms for those protocols 🙌. BFD may also be implemented in the control engine, though doing that may preclude the detection of some kinds of failures 🙈.
BFD runs on top of any data protocol being forwarded between two systems, like network layer, link layer, tunnels, and so on 🌸. It's always run in a unicast, point-to-point mode 💜. BFD packets ride as the payload of whatever encapsulating protocol fits the medium and network 📦. BFD may be running at multiple layers in a system at once, and the context of any particular BFD session is bound to its encapsulation 💅.
BFD can detect failures on basically any kind of path between systems: direct physical links, virtual circuits, tunnels, MPLS Label Switched Paths (LSPs), multihop routed paths, and unidirectional links (as long as there's some return path, obviously) 🌈. You can have multiple BFD sessions between the same pair of systems when there are multiple paths between them in at least one direction, even if there are fewer paths in the other direction, like multiple parallel unidirectional links or MPLS LSPs, for example 🔥.
The BFD state machine does a three-way handshake, both when a BFD session is being established and when it's torn down for any reason. That makes sure both systems know about the state change 🤝✨.
BFD can be thought of as a simple service 🧁. The service primitives it provides are to create, destroy, and modify a session, given the destination address and other parameters 📝. In return, BFD gives its clients a signal whenever the BFD session goes up or down 🎉.
3. Protocol Overview 🦋
BFD is a simple Hello protocol, and in lots of ways it's similar to the detection components of well-known routing protocols 💖. Two systems send BFD packets periodically over each path between them, and if a system stops receiving BFD packets for long enough, some component in that particular bidirectional path to the neighboring system is assumed to have failed 😱. Under some conditions, systems can negotiate not to send periodic BFD packets, which cuts down on overhead 🙌.
A path is only declared operational when two-way communication has been established between systems, though this doesn't stop you from using unidirectional links 🛣️.
A separate BFD session gets created for each communications path and data protocol in use between two systems 🧩.
Each system estimates how quickly it can send and receive BFD packets, so it can agree with its neighbor on how rapidly failure detection will happen 🤝. These estimates can be modified in real time to adapt to unusual situations 🔄. This design also lets fast systems on a shared medium with a slow system detect failures between the fast systems more quickly, while still letting the slow system participate to the best of its ability 🐢💕.
3.1. Addressing and Session Establishment 🎀
okay so a BFD session only shows up when an application actually needs one 💅 The app decides if it needs BFD and which addresses to use, because there's no discovery mechanism in BFD at all. 🙈 For example, an OSPF [OSPF] implementation can ask for a BFD session to a neighbor it found with the OSPF Hello protocol. iconic teamwork ✨
3.2. Operating Modes 🦋
BFD has two operating modes you can pick from, plus an extra function you can stack on top of either one. 🌈
The main one is called Asynchronous mode 💖 In this mode, both systems keep sending BFD Control packets to each other on a schedule. If a bunch of those packets in a row don't arrive at the other end, the session gets declared down. 💀
The second one is Demand mode 🧚 Here, each system is assumed to have its own independent way of knowing it's connected to the other side. Once the session is up, a system can tell the other one to stop sending BFD Control packets. The exception is when it wants to double-check connectivity on purpose. Then a short burst of BFD Control packets gets exchanged, and after that the far system goes quiet again. Demand mode can run in each direction on its own, or in both directions at the same time. 🫶
Then there's the Echo function, the add-on that works with both modes ✨ When Echo is active, a stream of BFD Echo packets gets sent in a way that makes the other system loop them back through its forwarding path. If a number of packets in that echoed stream don't come back, the session is declared down. Echo can be used with either Asynchronous or Demand mode. Since Echo is the one doing the detecting now, the periodic Control packets can be sent less often (in Asynchronous mode) or stopped completely (in Demand mode). 🍓
Pure Asynchronous mode has a real perk: it needs half as many packets to hit a particular Detection Time compared to the Echo function 👑 It's also the go-to when Echo can't be supported for some reason. 💅
The Echo function is special because it truly tests only the forwarding path on the remote system 😭 That can cut down round-trip jitter, which means you can go for more aggressive Detection Times. It can also catch some classes of failure that might otherwise slip past. 👀
Echo can be turned on individually in each direction 🌸 It only gets enabled in a given direction when the system that loops the Echo packets back says it's cool with it, and the system sending the Echo packets decides it wants to. Both have to say yes, bestie. 🫶
Demand mode is great when the overhead of a periodic protocol would be too much, like a system with a seriously huge number of BFD sessions 🦋 It also works nicely when Echo is being used symmetrically. The catch is that Detection Times are basically driven by the heuristics of the system implementation, and the BFD protocol doesn't actually know what they are. 🙃 Demand mode also may not be used when the path round-trip time is greater than the desired Detection Time, or the protocol will fail to work properly. ⚠️ See section 6.6 for more details.
⚠️ Heads up: if your round-trip time is bigger than your desired Detection Time, Demand mode is off the table, or the whole thing breaks. Check section 6.6 before you go there. 💔
4. BFD Control Packet Format 🧚
4.1. Generic BFD Control Packet Format 💖
BFD Control packets get sent in an encapsulation that fits the environment they're in 🌈 The specific encapsulation is outside the scope of this specification, so go check the appropriate application document for those details. 📄
Every BFD Control packet has a Mandatory Section and an optional Authentication Section. The format of the Authentication Section (if it's there at all) depends on which type of authentication is in use. 🔐
The Mandatory Section of a BFD Control packet looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| My Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Your Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Desired Min TX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Min RX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Min Echo RX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+An optional Authentication Section MAY be present 🙈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Authentication Data... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Version (Vers) 🔢
The version number of the protocol. This document defines protocol version 1. ✨
Diagnostic (Diag) 🩺
A diagnostic code that tells you the local system's reason for the last change in session state. The values are:
0 -- No Diagnostic
1 -- Control Detection Time Expired
2 -- Echo Function Failed
3 -- Neighbor Signaled Session Down
4 -- Forwarding Plane Reset
5 -- Path Down
6 -- Concatenated Path Down
7 -- Administratively Down
8 -- Reverse Concatenated Path Down
9-31 -- Reserved for future useThis field lets remote systems figure out why the previous session failed, for example 🕵️♀️
State (Sta) 🌸
The current BFD session state as seen by the transmitting system. The values are:
0 -- AdminDown
1 -- Down
2 -- Init
3 -- UpPoll (P) 🙋♀️
If set, the transmitting system is asking for verification of connectivity, or of a parameter change, and it's expecting a packet with the Final (F) bit in reply. If clear, the transmitting system is not asking for verification. 🫶
Final (F) 💌
If set, the transmitting system is replying to a received BFD Control packet that had the Poll (P) bit set. If clear, the transmitting system is not responding to a Poll. 💬
Control Plane Independent (C) 🏰
If set, the transmitting system's BFD implementation does not share fate with its control plane. In other words, BFD lives in the forwarding plane and can keep working through disruptions in the control plane 💪 If clear, the transmitting system's BFD implementation does share fate with its control plane.
The use of this bit is application dependent and is outside the scope of this specification. Check the specific application specifications for details 📚
Authentication Present (A) 🔐
If set, the Authentication Section is present and the session is to be authenticated (see section 6.7 for details). 🛡️
Demand (D) 🦋
If set, Demand mode is active in the transmitting system. That means the system wants to operate in Demand mode, knows the session is Up in both directions, and is telling the remote system to stop sending periodic BFD Control packets 🤫 If clear, Demand mode is not active in the transmitting system.
Multipoint (M) 📡
This bit is reserved for future point-to-multipoint extensions to BFD. It MUST be zero on both transmit and receipt. 🚫
Detect Mult 🔁
The detection time multiplier. The negotiated transmit interval, multiplied by this value, gives the Detection Time for the receiving system in Asynchronous mode. ⏱️
Length 📏
The length of the BFD Control packet, in bytes. 🧮
My Discriminator 🪪
A unique, nonzero discriminator value generated by the transmitting system. It's used to tell apart multiple BFD sessions between the same pair of systems 🧩
Your Discriminator 🔙
The discriminator received from the corresponding remote system. This field reflects back the received value of My Discriminator, or is zero if that value is unknown. 🪞
Desired Min TX Interval ⏩
This is the minimum interval, in microseconds, that the local system would like to use when transmitting BFD Control packets, less any jitter applied (see section 6.8.2). The value zero is reserved. 🕐
Required Min RX Interval ⏪
This is the minimum interval, in microseconds, between received BFD Control packets that this system is capable of supporting, less any jitter applied by the sender (see section 6.8.2). If this value is zero, the transmitting system does not want the remote system to send any periodic BFD Control packets. 🤐
Required Min Echo RX Interval 🪄
This is the minimum interval, in microseconds, between received BFD Echo packets that this system is capable of supporting, less any jitter applied by the sender (see section 6.8.9). If this value is zero, the transmitting system does not support the receipt of BFD Echo packets. 🙅♀️
Auth Type 🗝️
The authentication type in use, if the Authentication Present (A) bit is set. The values are:
0 - Reserved
1 - Simple Password
2 - Keyed MD5
3 - Meticulous Keyed MD5
4 - Keyed SHA1
5 - Meticulous Keyed SHA1
6-255 - Reserved for future useAuth Len 📐
The length, in bytes, of the authentication section, including the Auth Type and Auth Len fields. 🧾
4.2. Simple Password Authentication Section Format 🔑
If the Authentication Present (A) bit is set in the header, and the Authentication Type field contains 1 (Simple Password), the Authentication Section looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Password... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Auth Type 🏷️
The Authentication Type, which in this case is 1 (Simple Password). 🌟
Auth Len 📏
The length of the Authentication Section, in bytes. For Simple Password authentication, the length is equal to the password length plus three. ➕
Auth Key ID 🔢
The authentication key ID in use for this packet. This lets multiple keys be active at the same time 🗝️
Password 🤫
The simple password in use on this session. The password is a binary string, and it MUST be from 1 to 16 bytes in length. The password MUST be encoded and configured according to section 6.7.2. 🔒
4.3. Keyed MD5 and Meticulous Keyed MD5 Authentication Section Format ✨
okay bestie, real talk 💀 MD5-based authentication is strongly discouraged. it's only documented here so it still works with existing implementations 🫶
if the Authentication Present (A) bit is set in the header, and the Authentication Type field holds 2 (Keyed MD5) or 3 (Meticulous Keyed MD5), the Authentication Section looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Key/Digest... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Auth Type 🎀 The Authentication Type, which in this case is 2 (Keyed MD5) or 3 (Meticulous Keyed MD5).
Auth Len 🎀 The length of the Authentication Section, in bytes. For Keyed MD5 and Meticulous Keyed MD5 authentication, the length is 24.
Auth Key ID 🎀 The authentication key ID in use for this packet. This lets multiple keys be active at the same time, which is giving flexibility 💅
Reserved 🎀 This byte MUST be set to zero on transmit, and ignored on receipt.
Sequence Number 🎀 The sequence number for this packet. For Keyed MD5 Authentication, this value gets incremented occasionally. For Meticulous Keyed MD5 Authentication, it gets incremented for every successive packet transmitted for a session. This is the part that protects against replay attacks 🛡️✨
Auth Key/Digest 🎀 This field carries the 16-byte MD5 digest for the packet. When the digest is calculated, the shared MD5 key is stored in this field, padded to 16 bytes with trailing zero bytes if needed. The shared key MUST be encoded and configured to section 6.7.3.
4.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication Section Format 🔥
if the Authentication Present (A) bit is set in the header, and the Authentication Type field holds 4 (Keyed SHA1) or 5 (Meticulous Keyed SHA1), the Authentication Section looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Key/Hash... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Auth Type 🎀 The Authentication Type, which in this case is 4 (Keyed SHA1) or 5 (Meticulous Keyed SHA1).
Auth Len 🎀 The length of the Authentication Section, in bytes. For Keyed SHA1 and Meticulous Keyed SHA1 authentication, the length is 28.
Auth Key ID 🎀 The authentication key ID in use for this packet. This lets multiple keys be active at the same time 🫶
Reserved 🎀 This byte MUST be set to zero on transmit and ignored on receipt.
Sequence Number 🎀 The sequence number for this packet. For Keyed SHA1 Authentication, this value gets incremented occasionally. For Meticulous Keyed SHA1 Authentication, it gets incremented for each successive packet transmitted for a session. This provides protection against replay attacks, obsessed 😭
Auth Key/Hash 🎀 This field carries the 20-byte SHA1 hash for the packet. When the hash is calculated, the shared SHA1 key is stored in this field, padded to a length of 20 bytes with trailing zero bytes if needed. The shared key MUST be encoded and configured to section 6.7.4.
5. BFD Echo Packet Format 🦋
BFD Echo packets get sent in an encapsulation that fits the environment. the appropriate application documents have the specifics for particular environments, so go check those 🧚
the payload of a BFD Echo packet is a local matter, since only the sending system ever processes the content. the only requirement is that enough information is included to demultiplex the received packet to the correct BFD session after it gets looped back to the sender. everything else about the contents is outside the scope of this specification, so no drama there 💅
Some form of authentication SHOULD be included, since Echo packets may be spoofed. 🙈
6. Elements of Procedure 👑
this section covers the normative requirements of the protocol so everyone can interoperate. it's really important for implementors to enforce only the requirements listed here, because misguided pedantry has been proven by experience to hurt interoperability. not it being pedantic 🙄
quick reminder on naming: every reference of the form "bfd.Xx" points to internal state variables (defined in section 6.8.1), while every reference to "the Xxx field" points to fields in the protocol packets themselves (defined in section 4) 🍓
6.1. Overview 🌈
a system can take either an Active role or a Passive role in session initialization. a system taking the Active role MUST send BFD Control packets for a particular session, whether or not it has received any BFD packets for that session. a system taking the Passive role MUST NOT begin sending BFD packets for a particular session until it has received a BFD packet for that session, and so has learned the remote system's discriminator value. at least one system MUST take the Active role (possibly both). which role a system takes is specific to the application of BFD and is outside the scope of this specification 💜
a session begins with the periodic, slow transmission of BFD Control packets. once bidirectional communication is achieved, the BFD session becomes Up ✨
once the BFD session is Up, a system can choose to start the Echo function if it wants to and the other system signals that it will allow it. the rate of Control packet transmission is typically kept low while the Echo function is active 🌸
if the Echo function is not active, the Control packet transmission rate may be increased to whatever level is needed to hit the Detection Time requirements for the session 🔥
once the session is Up, a system may signal that it has entered Demand mode, and the remote system stops transmitting BFD Control packets. other means of implying connectivity are used to keep the session alive. if either system wants to verify bidirectional connectivity, it can start a short exchange of BFD Control packets (a "Poll Sequence"; see section 6.5) to do that 🫶
if Demand mode is not active, and no Control packets arrive within the calculated Detection Time (see section 6.8.4), the session is declared Down. this gets signaled to the remote end through the State (Sta) field in outgoing packets 💀
if enough Echo packets are lost, the session is declared Down in the same way. see section 6.8.5 🙈
if Demand mode is active and no appropriate Control packets come back in response to a Poll Sequence, the session is declared Down in the same way. see section 6.6 😭
if the session goes Down, the transmission of Echo packets (if any) stops, and Control packet transmission drops back to the slow rate 🍓
once a session has been declared Down, it can't come back up until the remote end first signals that it is down (by leaving the Up state). that's the three-way handshake doing its thing 🎀
a session MAY be kept administratively down by entering the AdminDown state and sending an explanatory diagnostic code in the Diagnostic field. ✨
6.2. BFD State Machine 🦋
okay so the BFD state machine is honestly so straightforward, bestie 💅 A session normally moves through three states: two for setting one up (Init and Up) and one for tearing it down (Down). That gives you a three-way handshake for both setup and teardown, so both systems are always aware of every session state change 🤝 There's also a fourth state, AdminDown, so a session can be put down on purpose and kept down indefinitely 🛑
Each system shares its session state in the State (Sta) field of the BFD Control packet. That received state, combined with the local session state, is what drives the state machine. It's giving teamwork 🫶
Down state means the session is down (or was just created). A session stays in Down state until the remote system says it agrees the session is down, by sending a BFD Control packet with the State field set to anything other than Up. If that packet signals Down, the session advances to Init. If it signals Init, the session advances to Up. Semantically, Down means the forwarding path is unavailable, so the applications watching the BFD session should take appropriate actions 🚨 A system MAY hold a session in Down state indefinitely (by simply refusing to advance the session state). This can be done for operational or administrative reasons, among others 🙈
Init state means the remote system is talking to us, and the local system wants to bring the session up, but the remote system doesn't realize it yet 👀 The session stays in Init state until one of two things happens. Either a BFD Control packet signaling Init or Up arrives, in which case the session advances to Up state. Or the Detection Time expires, meaning we've lost communication with the remote system, and the session advances to Down state 💔
Up state means the BFD session has successfully been established, and connectivity between the systems is working ✨ The session stays in Up state until connectivity fails or someone takes the session down administratively. If the remote system signals Down state, or the Detection Time expires, the session advances to Down state.
AdminDown state means the session is being held administratively down. This makes the remote system enter Down state and stay there until the local system exits AdminDown state. AdminDown has no semantic implications for the availability of the forwarding path, so it's not a "the path is broken" signal 🧘♀️
Here's the state machine overview. Transitions involving AdminDown are left out for clarity (but they're fully specified in sections 6.8.6 and 6.8.16). The notation on each arc is either the state of the remote system (as received in the State field of the BFD Control packet) or the expiration of the Detection Timer 📊
+--+
| | UP, ADMIN DOWN, TIMER
| V
DOWN +------+ INIT
+------------| |------------+
| | DOWN | |
| +-------->| |<--------+ |
| | +------+ | |
| | | |
| | ADMIN DOWN,| |
| |ADMIN DOWN, DOWN,| |
| |TIMER TIMER| |
V | | V
+------+ +------+
+----| | | |----+
DOWN| | INIT |--------------------->| UP | |INIT, UP
+--->| | INIT, UP | |<---+
+------+ +------+6.3. Demultiplexing and the Discriminator Fields 🗂️
Two systems can run multiple BFD sessions at the same time, so we need a way to sort received BFD packets into the right session. That's what demultiplexing is for, and it's a whole vibe 💜
Each system MUST choose an opaque discriminator value that identifies each session, and that value MUST be unique among all BFD sessions on the system. The local discriminator goes in the My Discriminator field of the BFD Control packet, and it gets echoed back in the Your Discriminator field of packets sent from the remote end 🔁
Once the remote end echoes back the local discriminator, every packet after that is demultiplexed based on the Your Discriminator field alone. That means, among other things, the source address can change, or the interface the packets arrive on can change, and they'll still land in the proper session 🦋
The way to demultiplex the initial packets (where Your Discriminator is zero) depends on the application, so it's outside the scope of this specification 🤷♀️
Also, it's totally allowed for a system to change its discriminator during a session without affecting the session state. Only that system uses its discriminator for demultiplexing (the other side just reflects it back), so it's not a big deal 💅 What changing the discriminator value means for an implementation is outside the scope of this specification.
6.4. The Echo Function and Asymmetry 🪞
The Echo function can run independently in each direction between a pair of systems. For whatever reason, a system may advertise that it's willing to receive (and loop back) Echo packets, but never want to send any. Also, the system doing the looping isn't directly told whether the other side is actually sending Echo packets 👻
When a system is using the Echo function, it's really smart to pick a sedate reception rate for Control packets, since the Echo packets are handling liveness detection now 🧘♀️ You control this by manipulating the Required Min RX Interval field (see section 6.8.3).
If the Echo function is only running in one direction, the system that isn't running it will probably want to receive pretty rapid Control packets so it can hit its desired Detection Time 🏃♀️ BFD lets each direction have its own transmission rate, so this is easy to set up ✨
A system SHOULD otherwise advertise the lowest values of Required Min RX Interval and Required Min Echo RX Interval that it can manage under the circumstances. That gives the other system more freedom to choose its transmission rate. Heads up though: a system is committing to be able to receive both streams of packets at the rate it advertises, so factor that into the values you pick 🫠
6.5. The Poll Sequence 🗳️
A Poll Sequence is an exchange of BFD Control packets used in some circumstances to make sure the remote system knows about parameter changes. It's also used in Demand mode (see section 6.6) to check that connectivity works in both directions 🔄
Here's how it goes. A system sends periodic BFD Control packets with the Poll (P) bit set. When the other system receives a Poll, it immediately transmits a BFD Control packet with the Final (F) bit set, no matter what periodic BFD Control packets it might be sending anyway (see section 6.8.7). Once the system that sent the Poll Sequence receives a packet with Final, the Poll Sequence is terminated, and any later BFD Control packets get sent with the Poll bit cleared 🎀 A BFD Control packet MUST NOT have both the Poll (P) and Final (F) bits set. That's a hard no, bestie 🚫
If periodic BFD Control packets are already being sent (because the remote system isn't in Demand mode), the Poll Sequence MUST be performed by setting the Poll (P) bit on those scheduled periodic transmissions. Additional packets MUST NOT be sent 🙅♀️
After a Poll Sequence ends, the system that requested it stops sending periodic BFD Control packets if the remote end is in Demand mode. Otherwise, it goes back to sending periodic BFD Control packets with the Poll (P) bit clear 🌸
Typically, the whole sequence is just a single packet in each direction. Packet losses or pretty long packet latencies can mean several Poll packets get sent before the sequence finally terminates 🌈
6.6. Demand Mode
Okay so Demand mode gets requested separately in each direction 💅. A system just flips the Demand (D) bit in its BFD Control packets to say "yo, I'm in Demand mode." The system that receives that bit stops sending its periodic BFD Control packets. And if both systems are in Demand mode? No periodic BFD Control packets flow in either direction at all 😭 it's giving total silence bestie.
Demand mode needs some other way to show the two systems are still connected 🦋. That mechanism doesn't have to match in both directions, and it's outside what this spec covers. Two examples are getting traffic from the remote system or using the Echo function 🌸.
When a system in Demand mode wants to double-check that connectivity works both ways, it starts a Poll Sequence (see section 6.5). If nobody answers a Poll, it keeps sending Polls until the Detection Time runs out, and then the session gets declared Down 💀. Also, if Demand mode is only on the local system, the Poll Sequence is just done by setting the Poll (P) bit in the regular periodic BFD Control packets, like section 6.5 asks for ✨.
The Detection Time in Demand mode is calculated differently than in Asynchronous mode. It's based on the local system's transmit rate, not the remote one's 🧚 That's what keeps the Poll Sequence working properly. More details are in section 6.8.4.
Heads up though: the Poll mechanism will always fail unless the negotiated Detection Time is greater than the round-trip time between the two systems 🙈. Enforcing that rule isn't this spec's job.
Demand mode MAY be turned on or off at any time, independently in each direction, by setting or clearing the Demand (D) bit. It doesn't mess with the session state either 🎀. But the Demand bit MUST NOT be set unless both systems see the session as Up. The local system has to think it's Up, and the remote system has to have last reported Up in the State (Sta) field of its BFD Control packet 💖.
When the transmitted value of the Demand (D) bit is about to change, the transmitting system MUST start a Poll Sequence together with the change so both systems know what's happening 🔥.
If Demand mode is active on either or both systems, a Poll Sequence MUST be started whenever the next BFD Control packet would have different contents from the previous one. The only exceptions are the Poll (P) and Final (F) bits 👑. That way parameter changes actually reach the remote system, and the remote system acknowledges them.
The underlying detection mechanism isn't specified and might be different on each system, so neither system will fully know the overall Detection Time for the path 🌈. A particular system's total Detection Time is the time before it starts the Poll Sequence, plus the calculated Detection Time.
Last thing: if Demand mode is enabled in only one direction, you lose continuous bidirectional connectivity verification. You only get verification for the direction from the system in Demand mode to the other system 💜. Sorting out what happens when one system wants Demand mode and the other needs continuous bidirectional verification is outside this spec ⭐.
6.7. Authentication
An optional Authentication Section MAY be present in the BFD Control packet 🎀. In its generic form, the Authentication Section carries everything needed (based on the authentication type in use) so the receiving system can tell whether the packet is valid 🔐. The exact details depend on the authentication type, but generally the transmitting system puts information in the Authentication Section that vouches for the packet's validity. The receiving system checks that section and then either accepts the packet for further processing or discards it 🫶.
The same authentication type, plus any keys or other necessary information, obviously must be in use by both systems. Negotiating the authentication type, doing key exchange, and so on are all outside this spec and are expected to happen outside the protocol 🙌.
Quick note: in the subsections below, "accept" only means the packet passed authentication. It can still get thrown out for other reasons, as covered in the general packet reception rules in section 6.8.6 🦋.
Implementations that support authentication MUST support both types of SHA1 authentication. Other forms of authentication are optional 💅.
6.7.1. Enabling and Disabling Authentication
Sometimes you want to turn authentication on or off for a session without disturbing the session state 🌸. The exact way to do that is outside this spec, but there are a few issues worth pointing out.
In a simple implementation, a BFD session will fail when authentication gets turned on or off 😭. The packet acceptance rules basically force the local and remote machines to switch in a more or less synchronized way (within the Detection Time). A packet with authentication will only be accepted if authentication is "in use," and packets without authentication only work when it isn't.
One possible approach is to configure authentication but not treat it as "in use" until the first packet with a matching authentication section arrives. That's what provides the synchronization 🧚. You can also go the other way: authentication is configured off, but still counts as "in use" until the first packet without an authentication section comes in.
To avoid security risks, implementations using this method SHOULD only allow the authentication state to be changed at most once without some form of intervention. That way, authentication can't be flipped on and off over and over just because BFD Control packets from remote systems showed up 🚨. Unless someone actually wants to enable or disable authentication, an implementation SHOULD NOT let the authentication state change based on receiving BFD Control packets 🙈.
6.7.2. Simple Password Authentication
Simple Password Authentication is the most straightforward (and weakest) form of authentication 🥺. With this method, one or more Passwords (each with a corresponding Key ID) are configured on each system, and one of those Password/ID pairs gets carried in each BFD Control packet. The receiving system accepts the packet only if its Password and Key ID match one of the Password/ID pairs configured on that system 🔑.
Transmission Using Simple Password Authentication
The currently selected password and Key ID for the session MUST be stored in the Authentication Section of each outgoing BFD Control packet. The Auth Type field MUST be set to 1 (Simple Password). The Auth Len field MUST be set to the proper length, which is 4 to 19 bytes 🎀.
The password is a binary string and MUST be 1 to 16 bytes in length. For interoperability, the management interface used to configure the password MUST accept ASCII strings. It SHOULD also let you configure any arbitrary binary string in hexadecimal form 💜. Other configuration methods MAY be supported ✨.
Reception Using Simple Password Authentication
If the received BFD Control packet doesn't contain an Authentication Section, or the Auth Type is not 1 (Simple Password), then the received packet MUST be discarded 💀.
If the Auth Key ID field doesn't match the ID of a configured password, the received packet MUST be discarded 😭.
If the Auth Len field isn't equal to the length of the password selected by the key ID, plus three, the packet MUST be discarded 🙅.
If the Password field doesn't match the password selected by the key ID, the packet MUST be discarded 🫠.
Otherwise, the packet MUST be accepted 🎉.
6.7.3. Keyed MD5 and Meticulous Keyed MD5 Authentication
okay so Keyed MD5 and Meticulous Keyed MD5 are basically the same vibe as auth in other protocols 🔐✨ Each system gets one or more secret keys, and every key has its own key ID. One of those keys gets mixed into an MD5 [MD5] digest calculated over the outgoing BFD Control packet, but the Key itself never rides along in the packet 🙈 To help dodge replay attacks, every packet also carries a sequence number. For Keyed MD5, that sequence number only gets bumped every now and then. For Meticulous Keyed MD5, it gets bumped on every single packet 💅
The receiving system accepts a packet only if the key ID matches one of its configured Keys, an MD5 digest that includes the selected key matches the one carried in the packet, and the sequence number is greater than or equal to the last sequence number received (for Keyed MD5), or strictly greater than the last sequence number received (for Meticulous Keyed MD5). 🎀
Transmission Using Keyed MD5 and Meticulous Keyed MD5 Authentication
The Auth Type field MUST be set to 2 (Keyed MD5) or 3 (Meticulous Keyed MD5). The Auth Len field MUST be set to 24. The Auth Key ID field MUST be set to the ID of the current authentication key. The Sequence Number field MUST be set to bfd.XmitAuthSeq.
The authentication key value is a binary string of up to 16 bytes, and it MUST be placed into the Auth Key/Digest field, padded with trailing zero bytes as necessary. For interoperability, the management interface by which the key is configured MUST accept ASCII strings, and SHOULD also allow for the configuration of any arbitrary binary string in hexadecimal form. Other configuration methods MAY be supported. 🍓
An MD5 digest MUST be calculated over the entire BFD Control packet. The resulting digest MUST be stored in the Auth Key/Digest field prior to transmission (replacing the secret key, which MUST NOT be carried in the packet). Secret key stays secret, bestie 🤫
For Keyed MD5, bfd.XmitAuthSeq MAY be incremented in a circular fashion (when treated as an unsigned 32-bit value). bfd.XmitAuthSeq SHOULD be incremented when the session state changes, or when the transmitted BFD Control packet carries different contents than the previously transmitted packet. The decision as to when to increment bfd.XmitAuthSeq is outside the scope of this specification. See the section titled "Security Considerations" below for a discussion. 👀
For Meticulous Keyed MD5, bfd.XmitAuthSeq MUST be incremented in a circular fashion (when treated as an unsigned 32-bit value). Every packet, no excuses 💅
Receipt Using Keyed MD5 and Meticulous Keyed MD5 Authentication
If the received BFD Control packet does not contain an Authentication Section, or the Auth Type is not correct (2 for Keyed MD5 or 3 for Meticulous Keyed MD5), then the received packet MUST be discarded. Not the right vibe, so it's gone 🗑️
If the Auth Key ID field does not match the ID of a configured authentication key, the received packet MUST be discarded.
If the Auth Len field is not equal to 24, the packet MUST be discarded.
If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For Keyed MD5, if the sequence number lies outside of the range of bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an unsigned 32-bit circular number space), the received packet MUST be discarded. For Meticulous Keyed MD5, if the sequence number lies outside of the range of bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an unsigned 32-bit circular number space) the received packet MUST be discarded. 🧐
Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1, and bfd.RcvAuthSeq MUST be set to the value of the received Sequence Number field. First contact, new vibes ✨
Replace the contents of the Auth Key/Digest field with the authentication key selected by the received Auth Key ID field. If the MD5 digest of the entire BFD Control packet is equal to the received value of the Auth Key/Digest field, the received packet MUST be accepted. Otherwise (the digest does not match the Auth Key/Digest field), the received packet MUST be discarded. The digest either matches or it's a no-go 🚫
6.7.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication
Keyed SHA1 and Meticulous Keyed SHA1 are giving very similar energy to the auth methods used in other protocols 🦋 Again, each system has one or more secret keys, each with its own key ID. One of the keys gets included in a SHA1 [SHA1] hash calculated over the outgoing BFD Control packet, but the key itself is never carried in the packet 🙈 Same replay-protection move as before: every packet carries a sequence number. Keyed SHA1 bumps it occasionally, and Meticulous Keyed SHA1 bumps it on every packet 💖
The receiving system accepts the packet if the key ID matches one of the configured keys, a SHA1 hash including the selected key matches the one carried in the packet, and the sequence number is greater than or equal to the last sequence number received (for Keyed SHA1), or strictly greater than the last sequence number received (for Meticulous Keyed SHA1). 🌸
Transmission Using Keyed SHA1 and Meticulous Keyed SHA1 Authentication
The Auth Type field MUST be set to 4 (Keyed SHA1) or 5 (Meticulous Keyed SHA1). The Auth Len field MUST be set to 28. The Auth Key ID field MUST be set to the ID of the current authentication key. The Sequence Number field MUST be set to bfd.XmitAuthSeq.
The authentication key value is a binary string of up to 20 bytes, and it MUST be placed into the Auth Key/Hash field, padding with trailing zero bytes as necessary. For interoperability, the management interface by which the key is configured MUST accept ASCII strings, and SHOULD also allow for the configuration of any arbitrary binary string in hexadecimal form. Other configuration methods MAY be supported. 🧚
A SHA1 hash MUST be calculated over the entire BFD control packet. The resulting hash MUST be stored in the Auth Key/Hash field prior to transmission (replacing the secret key, which MUST NOT be carried in the packet). Key stays hidden, always 🤐
For Keyed SHA1, bfd.XmitAuthSeq MAY be incremented in a circular fashion (when treated as an unsigned 32-bit value). bfd.XmitAuthSeq SHOULD be incremented when the session state changes, or when the transmitted BFD Control packet carries different contents than the previously transmitted packet. The decision as to when to increment bfd.XmitAuthSeq is outside the scope of this specification. See the section titled "Security Considerations" below for a discussion. 🫶
For Meticulous Keyed SHA1, bfd.XmitAuthSeq MUST be incremented in a circular fashion (when treated as an unsigned 32-bit value). Every. Single. Packet. 🔥
Receipt Using Keyed SHA1 and Meticulous Keyed SHA1 Authentication
If the received BFD Control packet does not contain an Authentication Section, or the Auth Type is not correct (4 for Keyed SHA1 or 5 for Meticulous Keyed SHA1), then the received packet MUST be discarded. Wrong type, bye 👋
If the Auth Key ID field does not match the ID of a configured authentication key, the received packet MUST be discarded.
If the Auth Len field is not equal to 28, the packet MUST be discarded.
If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For Keyed SHA1, if the sequence number lies outside of the range of bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an unsigned 32-bit circular number space), the received packet MUST be discarded. For Meticulous Keyed SHA1, if the sequence number lies outside of the range of bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an unsigned 32-bit circular number space, the received packet MUST be discarded. 🙃
Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1, bfd.RcvAuthSeq MUST be set to the value of the received Sequence Number field, and the received packet MUST be accepted. New connection, who dis? 🌈
Replace the contents of the Auth Key/Hash field with the authentication key selected by the received Auth Key ID field. If the SHA1 hash of the entire BFD Control packet is equal to the received value of the Auth Key/Hash field, the received packet MUST be accepted. Otherwise (the hash does not match the Auth Key/Hash field), the received packet MUST be discarded. Hash matches, we're in 💅
6.8. Functional Specifics
The following section of this specification is normative. The means by which this specification is achieved is outside the scope of this specification. 📜
When a system is said to have "the Echo function active" it means that the system is sending BFD Echo packets, implying that the session is Up and the other system has signaled its willingness to loop back Echo packets. 🪞✨
When the local system is said to have "Demand mode active," it means that bfd.DemandMode is 1 in the local system (see section 6.8.1), the session is Up, and the remote system is signaling that the session is in state Up. Local side is chill and waiting, iykyk 😌
When the remote system is said to have "Demand mode active," it means that bfd.RemoteDemandMode is 1 (the remote system set the Demand (D) bit in the last received BFD Control packet), the session is Up, and the remote system is signaling that the session is in state Up. Same energy, but make it the other side 🫠
6.8.1. State Variables ✨
okay so, a minimum amount of info about a session has to get tracked so we can actually do all the stuff described here 💅. This is a set of state variables that makes it way easier to explain how BFD works 🧠. You can track this state however you want, as long as the protocol behaves the way it's described 🫶.
When the text says to initialize a state variable, that only happens when the session (and its state variables) gets created 🌸. After that, the state machine keeps manipulating them and they are never reinitialized, even if the session fails and gets reestablished 🔄.
Once session state exists and at least one BFD Control packet has come in from the remote end, it MUST be kept for at least one Detection Time (see section 6.8.4) after the last BFD Control packet was received, no matter what the session state is 🔒. This keeps the timing params around in case the session flaps 🎢. A system MAY keep session state for longer than that 🦋. What happens to session state when no BFD Control packets for this session have been received from the remote system is out of scope for this spec 🙈.
All state variables here are named in the form "bfd.Xx" 🎀. Don't mix them up with the fields carried in the protocol packets, which are always spelled out to match the names in section 4 📦.
bfd.SessionState
This is the perceived state of the session (Init, Up, Down, or AdminDown) 👀. The exact action taken when the session state changes is outside the scope of this spec, but it's expected that this state change (especially to and from Up state) gets reported to other components of the system 📣. This variable MUST be initialized to Down.
bfd.RemoteSessionState
This is the session state last reported by the remote system in the State (Sta) field of the BFD Control packet 🛰️. This variable MUST be initialized to Down.
bfd.LocalDiscr
This is the local discriminator for this BFD session, which is how it gets uniquely identified 🆔. It MUST be unique across all BFD sessions on this system, and it MUST be nonzero. It SHOULD be set to a random (but still unique) value to improve security 🔐. Otherwise, the value is outside the scope of this spec.
bfd.RemoteDiscr
This is the remote discriminator for this BFD session, chosen by the remote system 🤷♀️. It's totally opaque to the local system, so don't try to read anything into it. This MUST be initialized to zero. If a period of a Detection Time passes without receiving a valid, authenticated BFD packet from the remote system, this variable MUST be set to zero 🧹.
bfd.LocalDiag
This is the diagnostic code explaining the reason for the most recent change in the local session state 📝. This MUST be initialized to zero (No Diagnostic).
bfd.DesiredMinTxInterval
This is the minimum interval, in microseconds, between transmitted BFD Control packets that this system would like to use right now, minus any jitter applied (see section 6.8.2) ⏱️. The actual interval gets negotiated between the two systems 🤝. This MUST be initialized to a value of at least one second (1,000,000 microseconds) following the rules in section 6.8.3. Setting this variable is otherwise outside the scope of this spec.
bfd.RequiredMinRxInterval
This is the minimum interval, in microseconds, between received BFD Control packets that this system requires, minus any jitter the sender applied (see section 6.8.2) 📥. Setting this variable is outside the scope of this spec. A value of zero means this system does not want to receive any periodic BFD Control packets 🙅♀️. See section 6.8.18 for details.
bfd.RemoteMinRxInterval
This is the last value of Required Min RX Interval received from the remote system in a BFD Control packet 📨. This variable MUST be initialized to 1.
bfd.DemandMode
This is set to 1 if the local system wants to use Demand mode, or 0 if not 💤.
bfd.RemoteDemandMode
This is set to 1 if the remote system wants to use Demand mode, or 0 if not 🌙. It's the value of the Demand (D) bit in the last received BFD Control packet. This variable MUST be initialized to zero.
bfd.DetectMult
This is the desired Detection Time multiplier for BFD Control packets on the local system ✖️. The negotiated Control packet transmission interval, multiplied by this variable, becomes the Detection Time for this session (as seen by the remote system) ⏰. This variable MUST be a nonzero integer, and is otherwise outside the scope of this spec. See section 6.8.4 for more info.
bfd.AuthType
This is the authentication type in use for this session, as defined in section 4.1, or zero if no authentication is in use 🔑.
bfd.RcvAuthSeq
This is a 32-bit unsigned integer holding the last sequence number for Keyed MD5 or SHA1 Authentication that was received 🔢. The initial value doesn't matter.
bfd.XmitAuthSeq
This is a 32-bit unsigned integer holding the next sequence number for Keyed MD5 or SHA1 Authentication to be transmitted ➡️. This variable MUST be initialized to a random 32-bit value 🎲.
bfd.AuthSeqKnown
This is set to 1 if the next sequence number for Keyed MD5 or SHA1 authentication expected to be received is known, or 0 if it isn't ❓. This variable MUST be initialized to zero.
This variable MUST be set to zero after no packets have been received on this session for at least twice the Detection Time 🔁. This makes sure the sequence number can resync if the remote system restarts 🔄✨.
6.8.2. Timer Negotiation ⏲️
The time values used to figure out BFD packet transmission intervals and the session Detection Time are continuously negotiated, so they can change at any time 🦋. The negotiation and the time values are independent in each direction for each session 🙌.
Each system reports in the BFD Control packet how fast it would like to transmit BFD packets, and also how fast it's prepared to receive them 📬. This lets either system unilaterally figure out the maximum packet rate (minimum interval) in both directions 💅.
See section 6.8.7 for the details of packet transmission timing and negotiation 📖.
6.8.3. Timer Manipulation 🛠️
The time values used to figure out BFD packet transmission intervals and the session Detection Time can be modified at any time without affecting the state of the session 🌈. When the timer parameters change for any reason, the requirements in this section apply 📋.
If bfd.DesiredMinTxInterval changes, or bfd.RequiredMinRxInterval changes, a Poll Sequence MUST be initiated (see section 6.5) 🗳️. If the timing is such that a system receiving a Poll Sequence wants to change the parameters described in this paragraph, the new parameter values MAY be carried in packets with the Final (F) bit set, even if the Poll Sequence hasn't been sent yet 🎁.
If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up, the actual transmission interval used MUST NOT change until the Poll Sequence described above has terminated 🛑. This makes sure the remote system updates its Detection Time before the transmission interval goes up 📈.
If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up, the previous value of bfd.RequiredMinRxInterval MUST be used when calculating the Detection Time for the remote system until the Poll Sequence described above has terminated 🕰️. This makes sure the remote system is already transmitting at the higher rate (and those packets are actually being received) before the Detection Time gets reduced 🏃♀️.
When bfd.SessionState is not Up, the system MUST set bfd.DesiredMinTxInterval to a value of not less than one second (1,000,000 microseconds) 😴. This is meant to keep the bandwidth used by BFD sessions that aren't Up negligible, especially when a neighbor might not be running BFD 🪶.
If the local system reduces its transmit interval because bfd.RemoteMinRxInterval was reduced (the remote system advertised a reduced value in Required Min RX Interval), and the remote system is not in Demand mode, the local system MUST honor the new interval immediately 🏎️. In other words, the local system can't wait longer than the new interval between the previous packet transmission and the next one ⏳. If that interval has already passed since the last transmission (because the new interval is significantly shorter), the local system MUST send the next periodic BFD Control packet as soon as practicable 💨.
When the Echo function is active, a system SHOULD set bfd.RequiredMinRxInterval to a value of not less than one second (1,000,000 microseconds) 🔇. This is meant to keep received BFD Control traffic at a negligible level, since the actual detection function is being done using BFD Echo packets 🎯.
In any case other than those explicitly called out above, timing parameter changes MUST be effected immediately (changing the transmission rate and/or the Detection Time) ⚡.
Heads up, bestie: the Poll Sequence mechanism gets ambiguous if more than one parameter change that needs it happens, and those changes are spread across multiple packets (since the semantics of the returning Final are unclear) 😬. So if multiple changes need a Poll Sequence, there are three choices:
- They MUST be communicated in a single BFD Control packet (so the semantics of the Final reply are clear) 📦.
- Sufficient time must have passed since the Poll Sequence was completed to clear up the situation (at least a round trip time since the last Poll was transmitted) before starting another Poll Sequence ⏳.
- An additional BFD Control packet with the Final (F) bit clear MUST be received after the Poll Sequence has completed before starting another Poll Sequence (this option is not available when Demand mode is active) 💌.
Ngl this part is so important, it's literally what keeps the timers from getting weird 💖🫶.
6.8.4. Calculating the Detection Time ✨
Okay bestie, so the Detection Time (aka how long you can go without getting BFD packets before the session is officially declared dead 💀) is not carried explicitly in the protocol 🙈. Instead, each side works it out on its own, using the negotiated transmit interval and the detection multiplier. And the wild part? The two directions can have different Detection Times 🦋.
The math is lowkey different in Demand mode vs Asynchronous mode, so let's go one at a time 💅.
In Asynchronous mode, the Detection Time that the local system calculates equals the Detect Mult value it received from the remote system, multiplied by the agreed transmit interval of the remote system (the greater of bfd.RequiredMinRxInterval and the last received Desired Min TX Interval). Detect Mult is, roughly speaking (jitter is a whole thing 🌊), the number of packets that can be missed in a row before the session is called down.
If Demand mode is not active, and a period of time equal to the Detection Time goes by without a BFD Control packet from the remote system, and bfd.SessionState is Init or Up, the session has gone down -- the local system MUST set bfd.SessionState to Down and bfd.LocalDiag to 1 (Control Detection Time Expired). 😭
In Demand mode, the Detection Time calculated in the local system is equal to bfd.DetectMult, multiplied by the agreed transmit interval of the local system (the greater of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval). bfd.DetectMult is (roughly speaking, due to jitter) the number of packets that have to be missed in a row to declare the session to be down. 🎀
If Demand mode is active, and a period of time equal to the Detection Time passes after the initiation of a Poll Sequence (the transmission of the first BFD Control packet with the Poll bit set), the session has gone down -- the local system MUST set bfd.SessionState to Down, and bfd.LocalDiag to 1 (Control Detection Time Expired). 💖
Quick aside: a packet only counts as "received" for Detection Time expiration if it has NOT been "discarded" according to the rules of section 6.8.6. So those discarded packets don't get to save the session 🙅♀️
6.8.5. Detecting Failures with the Echo Function 🧚
When the Echo function is active and a sufficient number of Echo packets have not arrived as they should, the session has gone down -- the local system MUST set bfd.SessionState to Down and bfd.LocalDiag to 2 (Echo Function Failed). 🌸
The means by which Echo function failures are detected is outside the scope of this specification. Any means that will detect a communication failure are acceptable. So basically, pick your detector, as long as it actually catches failures 🫶.
6.8.6. Reception of BFD Control Packets 📬
When a BFD Control packet is received, the following procedure MUST be followed, in the order specified. If the packet is discarded according to these rules, processing of the packet MUST cease at that point. Order matters here, periodt 👑.
- If the version number is not correct (1), the packet MUST be discarded.
- If the Length field is less than the minimum correct value (24 if the A bit is clear, or 26 if the A bit is set), the packet MUST be discarded.
- If the Length field is greater than the payload of the encapsulating protocol, the packet MUST be discarded.
- If the
Detect Multfield is zero, the packet MUST be discarded. - If the Multipoint (M) bit is nonzero, the packet MUST be discarded.
- If the
My Discriminatorfield is zero, the packet MUST be discarded. - If the
Your Discriminatorfield is nonzero, it MUST be used to select the session with which this BFD packet is associated. If no session is found, the packet MUST be discarded. - If the
Your Discriminatorfield is zero and the State field is not Down or AdminDown, the packet MUST be discarded. - If the
Your Discriminatorfield is zero, the session MUST be selected based on some combination of other fields, possibly including source addressing information, theMy Discriminatorfield, and the interface over which the packet was received. The exact method of selection is application specific and is thus outside the scope of this specification. If a matching session is not found, a new session MAY be created, or the packet MAY be discarded. This choice is outside the scope of this specification. 🤷♀️ - If the A bit is set and no authentication is in use (
bfd.AuthTypeis zero), the packet MUST be discarded. - If the A bit is clear and authentication is in use (
bfd.AuthTypeis nonzero), the packet MUST be discarded. - If the A bit is set, the packet MUST be authenticated under the rules of section 6.7, based on the authentication type in use (
bfd.AuthType). This may cause the packet to be discarded. - Set
bfd.RemoteDiscrto the value ofMy Discriminator. - Set
bfd.RemoteStateto the value of the State (Sta) field. - Set
bfd.RemoteDemandModeto the value of the Demand (D) bit. - Set
bfd.RemoteMinRxIntervalto the value of Required Min RX Interval. - If the Required Min Echo RX Interval field is zero, the transmission of Echo packets, if any, MUST cease.
- If a Poll Sequence is being transmitted by the local system and the Final (F) bit in the received packet is set, the Poll Sequence MUST be terminated.
- Update the transmit interval as described in section 6.8.2.
- Update the Detection Time as described in section 6.8.4.
Now for the state drama 🎭. This part is pseudo-code, so it stays exactly as written:
If bfd.SessionState is AdminDown
Discard the packet
If received state is AdminDown
If bfd.SessionState is not Down
Set bfd.LocalDiag to 3 (Neighbor signaled
session down)
Set bfd.SessionState to Down
Else
If bfd.SessionState is Down
If received State is Down
Set bfd.SessionState to Init
Else if received State is Init
Set bfd.SessionState to Up
Else if bfd.SessionState is Init
If received State is Init or Up
Set bfd.SessionState to Up
Else (bfd.SessionState is Up)
If received State is Down
Set bfd.LocalDiag to 3 (Neighbor signaled
session down)
Set bfd.SessionState to DownWrapping up the procedure, the last few steps go like this 🌈:
- Check to see if Demand mode should become active or not (see section 6.6).
- If
bfd.RemoteDemandModeis 1,bfd.SessionStateis Up, andbfd.RemoteSessionStateis Up, Demand mode is active on the remote system and the local system MUST cease the periodic transmission of BFD Control packets (see section 6.8.7). - If
bfd.RemoteDemandModeis 0, orbfd.SessionStateis not Up, orbfd.RemoteSessionStateis not Up, Demand mode is not active on the remote system and the local system MUST send periodic BFD Control packets (see section 6.8.7). - If the Poll (P) bit is set, send a BFD Control packet to the remote system with the Poll (P) bit clear, and the Final (F) bit set (see section 6.8.7).
- If the packet was not discarded, it has been received for purposes of the Detection Time expiration rules in section 6.8.4. ✨
6.8.7. Transmitting BFD Control Packets
Okay bestie, first rule: with the exceptions listed in the rest of this section, a system MUST NOT transmit BFD Control packets at an interval less than the larger of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval, minus applied jitter (see below). So the system reporting the slower rate is the one that sets the transmission rate. Main character energy, no cap 💅
The periodic transmission of BFD Control packets MUST be jittered on a per-packet basis by up to 25% 🌸. That means the interval MUST be reduced by a random value of 0 to 25%, so systems on the same subnetwork don't accidentally self-synchronize with each other 🦋. The average interval between packets ends up being roughly 12.5% less than what was negotiated ✨.
If bfd.DetectMult is equal to 1, the interval between transmitted BFD Control packets MUST be no more than 90% of the negotiated transmission interval, and MUST be no less than 75% of the negotiated transmission interval. This is so the remote system's calculated Detection Time doesn't run out before the next BFD Control packet shows up. Lowkey genius 🧚
The transmit interval MUST be recalculated whenever bfd.DesiredMinTxInterval changes, or whenever bfd.RemoteMinRxInterval changes, and it is equal to the greater of those two values. Check sections 6.8.2 and 6.8.3 for the details on transmit timers 🎀.
A system MUST NOT transmit BFD Control packets if bfd.RemoteDiscr is zero and the system is taking the Passive role 🙈.
A system MUST NOT periodically transmit BFD Control packets if bfd.RemoteMinRxInterval is zero.
A system MUST NOT periodically transmit BFD Control packets if Demand mode is active on the remote system (bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and bfd.RemoteSessionState is Up) and a Poll Sequence is not being transmitted. It's giving "only talk when spoken to" 🤫.
If a BFD Control packet is received with the Poll (P) bit set to 1, the receiving system MUST transmit a BFD Control packet with the Poll (P) bit clear and the Final (F) bit set as soon as practicable. This happens without respect to the transmission timer or any other transmission limits, without respect to the session state, and without respect to whether Demand mode is active on either system. Yes, even then 😭. A system MAY limit the rate at which such packets are transmitted. If rate limiting is in effect, the advertised value of Desired Min TX Interval MUST be greater than or equal to the interval between transmitted packets imposed by the rate limiting function 🔥.
A system MUST NOT set the Demand (D) bit unless bfd.DemandMode is 1, bfd.SessionState is Up, and bfd.RemoteSessionState is Up 💀.
A BFD Control packet SHOULD be transmitted during the interval between periodic Control packet transmissions when that packet's contents would differ from the previously transmitted packet (other than the Poll and Final bits). The point is to tell the other side about a state change faster 🌈.
The contents of transmitted BFD Control packets MUST be set as follows:
Version: Set to the current version number (1).Diagnostic (Diag): Set tobfd.LocalDiag.State (Sta): Set to the value indicated bybfd.SessionState.Poll (P): Set to 1 if the local system is sending a Poll Sequence, or 0 if not.Final (F): Set to 1 if the local system is responding to a Control packet received with the Poll (P) bit set, or 0 if not.Control Plane Independent (C): Set to 1 if the local system's BFD implementation is independent of the control plane (it can keep functioning through a disruption of the control plane) ✨.Authentication Present (A): Set to 1 if authentication is in use on this session (bfd.AuthTypeis nonzero), or 0 if not.Demand (D): Set tobfd.DemandModeifbfd.SessionStateis Up andbfd.RemoteSessionStateis Up. Otherwise, it is set to 0.Multipoint (M): Set to 0.Detect Mult: Set tobfd.DetectMult.Length: Set to the appropriate length, based on the fixed header length (24) plus any Authentication Section.My Discriminator: Set tobfd.LocalDiscr.Your Discriminator: Set tobfd.RemoteDiscr.Desired Min TX Interval: Set tobfd.DesiredMinTxInterval.Required Min RX Interval: Set tobfd.RequiredMinRxInterval.Required Min Echo RX Interval: Set to the minimum required Echo packet receive interval for this session. If this field is set to zero, the local system is unwilling or unable to loop back BFD Echo packets to the remote system, and the remote system will not send Echo packets 🙅♀️.Authentication Section: Included and set according to the rules in section 6.7 if authentication is in use (bfd.AuthTypeis nonzero). Otherwise, this section is not present.
6.8.8. Reception of BFD Echo Packets
A received BFD Echo packet MUST be demultiplexed to the appropriate session for processing. A means of detecting missing Echo packets MUST be implemented, which most likely involves processing the Echo packets that are received 🦋. Processing of received Echo packets is otherwise outside the scope of this specification, so we're leaving that one alone 💖.
6.8.9. Transmission of BFD Echo Packets
BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not Up. BFD Echo packets MUST NOT be transmitted unless the last BFD Control packet received from the remote system contains a nonzero value in Required Min Echo RX Interval 🙈.
BFD Echo packets MAY be transmitted when bfd.SessionState is Up. The interval between transmitted BFD Echo packets MUST NOT be less than the value advertised by the remote system in Required Min Echo RX Interval, except as follows:
A 25% jitter MAY be applied to the rate of transmission, so the actual interval MAY be between 75% and 100% of the advertised value. A single BFD Echo packet MAY be transmitted between normally scheduled Echo transmission intervals. Little exceptions, big vibes 🎀.
Transmission of BFD Echo packets is otherwise outside the scope of this specification 🫶.
6.8.10. Min Rx Interval Change
When you want to change the rate at which BFD Control packets arrive from the remote system, bfd.RequiredMinRxInterval can be changed at any time to any value 🍓. The new value gets transmitted in the next outgoing Control packet, and the remote system adjusts accordingly. See section 6.8.3 for further requirements.
6.8.11. Min Tx Interval Change
When you want to change the rate at which BFD Control packets are transmitted to the remote system (subject to the requirements of the neighboring system), bfd.DesiredMinTxInterval can be changed at any time to any value 🌸. The rules in section 6.8.3 apply.
6.8.12. Detect Multiplier Change
When you want to change the detect multiplier, the value of bfd.DetectMult can be changed to any nonzero value ✨. The new value gets transmitted with the next BFD Control packet, and you don't need a Poll Sequence for it. See section 6.6 for additional requirements.
6.8.13. Enabling or Disabling The Echo Function
If you want to start or stop transmitting BFD Echo packets, you MAY do that at any time (subject to the transmission requirements detailed in section 6.8.9) 🧚.
If you want to enable or disable looping back received BFD Echo packets, you MAY do that at any time by changing the value of Required Min Echo RX Interval to zero or nonzero in outgoing BFD Control packets 🔄.
6.8.14. Enabling or Disabling Demand Mode
If you want to start or stop Demand mode, you MAY do that at any time by setting bfd.DemandMode to the proper value. Demand mode will then become active under the rules described in section 6.6 👑.
If Demand mode is no longer active on the remote system, the local system MUST begin transmitting periodic BFD Control packets as described in section 6.8.7 🫠.
6.8.15. Forwarding Plane Reset
When the forwarding plane in the local system gets reset for some reason, so the remote system can no longer rely on the local forwarding state, the local system MUST set bfd.LocalDiag to 4 (Forwarding Plane Reset), and set bfd.SessionState to Down 😱.
6.8.16. Administrative Control
Sometimes it's desirable to administratively enable or disable a BFD session 💅. When that's the case, the following procedure MUST be followed:
If enabling session
Set bfd.SessionState to Down
Else
Set bfd.SessionState to AdminDown
Set bfd.LocalDiag to an appropriate value
Cease the transmission of BFD Echo packetsIf signaling is received from outside BFD that the underlying path has failed, an implementation MAY administratively disable the session with the diagnostic Path Down 🙃.
Other scenarios MAY use the diagnostic Administratively Down.
BFD Control packets SHOULD be transmitted for at least a Detection Time after transitioning to AdminDown state, so the remote system knows about the state change 🫶. BFD Control packets MAY be transmitted indefinitely after transitioning to AdminDown state to keep session state in each system (see section 6.8.18 below) 💜.
6.8.17. Concatenated Paths
If the path BFD is monitoring is concatenated with other paths (connected end-to-end in series), it may be desirable to propagate the indication of a failure of one of those paths across the BFD session 🌈. This acts as an interworking function for liveness monitoring between BFD and other technologies.
Two diagnostic codes are defined for this: Concatenated Path Down and Reverse Concatenated Path Down. The first propagates forward path failures (where the concatenated path fails in the direction toward the interworking system). The second propagates reverse path failures (where the concatenated path fails in the direction away from the interworking system, assuming a bidirectional link) 🧠.
A system MAY signal one of these failure states by simply setting bfd.LocalDiag to the appropriate diagnostic code. Note that the BFD session is not taken down ✨. If Demand mode is not active on the remote system, nothing else is necessary, since the diagnostic code rides along on the periodic transmission of BFD Control packets. If Demand mode is active on the remote system (so the local system is not transmitting periodic BFD Control packets), a Poll Sequence MUST be initiated to make sure the diagnostic code gets transmitted 🔥. Note that if the BFD session later fails, the diagnostic code gets overwritten with a code describing the cause of the failure. It's up to the interworking agent to do the above procedure again, once the BFD session reaches Up state, if the propagation of the concatenated path failure is supposed to resume 🥹.
6.8.18. Holding Down Sessions 🫧
Okay so, a system is totally allowed to MAY choose to stop a BFD session from getting established 🙅♀️. One reason might be managing how fast sessions get set up. You do this by parking the session in Down or AdminDown state, whichever fits best.
There are two related tools that help with this, bestie 🧚. First up, a system is REQUIRED to keep its session state (timing parameters included) even while the session is down, until a Detection Time passes with no BFD Control packets showing up 😭. So a system can take a session down and send a super huge number in the Required Min RX Interval field to throttle how fast packets reach it 🐢.
Also, a system MAY send a zero in Required Min RX Interval, which basically means "send me absolutely nothing" 🤐.
As long as the local system keeps sending BFD Control packets, the remote system has to obey whatever's in Required Min RX Interval 🫡. If the remote system hears nothing for a Detection Time, it SHOULD reset bfd.RemoteMinRxInterval back to its starting value of 1 (see section 6.8.1, because it's no longer on the hook to keep the old session state). After that, it can send at its own pace 🦋.
7. Operational Considerations 🎀
BFD is likely to be deployed as a critical part of network infrastructure, so you have to be careful not to cause disruption 🥺.
Obviously, anything that blocks BFD packets, like firewalls or other policy processes, will make BFD fail 💀.
Things that control packet scheduling, like policers, traffic shapers, priority queueing, and so on, can mess with BFD if the Detection Time is similar in scale to the rate that packets get scheduled to be sent or received. BFD packet delivery is time-critical compared to the size of the Detection Time, so you need to think about this during implementation and deployment, especially when really short Detection Times are being used ⏱️.
When BFD runs across multiple hops, a congestion control mechanism MUST be implemented. When congestion is detected, the BFD implementation MUST reduce how much traffic it generates 📉. The exact mechanism is outside the scope of this spec, and what it needs can vary depending on how BFD is deployed and how it interacts with other parts of the system. For example, exponential backoff may not be appropriate when routing protocols are interacting closely with BFD 🙃.
Here's the tea: "congestion" isn't only about traffic, it's also about computation 🧠. Systems with a huge number of BFD sessions and/or very short packet intervals can become CPU-bound. So a congestion control algorithm SHOULD be used even across single hops, to avoid catastrophic system collapse. Those failures have been seen over and over in other periodic Hello-based protocols, so please learn from their pain 💅.
The mechanisms for detecting congestion are outside the scope of this spec. They might include detecting lost BFD Control packets (through holes in the authentication sequence number space, or through a BFD session failure), or other means 🔍.
To reduce BFD's traffic load, you control how fast the local and remote systems transmit packets, using the Min RX Interval and Min TX Interval fields 🎛️.
Keep in mind that any mechanism that increases the transmit or receive intervals will also increase the Detection Time for the session ⚠️.
It's worth noting that a single BFD session doesn't eat much bandwidth 🍓. An aggressive session that reaches a detection time of 50 milliseconds, by using a transmit interval of 16.7 milliseconds and a detect multiplier of 3, will generate 60 packets per second. The maximum length of each packet on the wire is on the order of 100 bytes, which adds up to around 48 kilobits per second of bandwidth consumption in each direction 📊.
8. IANA Considerations 📋
This document defines two registries administered by IANA 🗂️. The first one is titled "BFD Diagnostic Codes" (see section 4.1). Initial values for the BFD Diagnostic Code registry are given below. Further assignments are to be made through Expert Review [IANA-CONSIDERATIONS]. Assignments consist of a BFD Diagnostic Code name and its associated value.
Value BFD Diagnostic Code Name
----- ------------------------
0 No Diagnostic
1 Control Detection Time Expired
2 Echo Function Failed
3 Neighbor Signaled Session Down
4 Forwarding Plane Reset
5 Path Down
6 Concatenated Path Down
7 Administratively Down
8 Reverse Concatenated Path Down
9-31 UnassignedThe second registry is titled "BFD Authentication Types" (see section 4.1). Initial values for the BFD Authentication Type registry are given below. Further assignments are to be made through Expert Review [IANA-CONSIDERATIONS]. Assignments consist of a BFD Authentication Type Code name and its associated value.
Value BFD Authentication Type Name
----- ----------------------------
0 Reserved
1 Simple Password
2 Keyed MD5
3 Meticulous Keyed MD5
4 Keyed SHA1
5 Meticulous Keyed SHA1
6-255 Unassigned9. Security Considerations 🔐
Since BFD may be tied into the stability of network infrastructure (like routing protocols), an attack on a BFD session can be really serious 😱. A link might be falsely declared down, or falsely declared up. Either way, the effect is denial of service 🚨.
An attacker who has complete control of the link between the systems can easily drop all BFD packets but forward everything else, which makes the link falsely declared down. They can also forward only the BFD packets and nothing else, which makes the link falsely declared up. BFD cannot prevent this attack 💔.
To block threats from less capable attackers, BFD specifies two mechanisms to prevent spoofing of BFD Control packets 🛡️. The Generalized TTL Security Mechanism [GTSM] uses the time to live (TTL) or Hop Count to stop off-link attackers from spoofing packets. The Authentication Section authenticates the BFD Control packets. More detail on both is below.
When a BFD session is directly connected across a single link (physical, or a secure tunnel such as IPsec), the TTL or Hop Count MUST be set to the maximum on transmit. On reception, it MUST be checked to be equal to the maximum value, and the packet dropped if this is not the case. See [GTSM] for more information on this technique 🧐. If BFD runs across multiple hops or an insecure tunnel (such as Generic Routing Encapsulation (GRE)), the Authentication Section SHOULD be utilized 🔒.
How secure the Authentication Section is depends on the authentication type used 🎭. Simple Password authentication is obviously only as secure as the secrecy of the passwords used. It should only be considered if the BFD session is guaranteed to run over infrastructure that isn't subject to packet interception. Its big perk is that it minimizes the computational effort needed for authentication 💸.
Keyed MD5 Authentication is much stronger than Simple Password Authentication, since the keys can't be figured out by intercepting packets 🔑. It is vulnerable to replay attacks between increments of the sequence number. The sequence number can be incremented as seldom (or as often) as you like, which trades off resistance to replay attacks against the computational effort needed for authentication ⚖️.
Meticulous Keyed MD5 authentication is stronger yet, because it requires the sequence number to be incremented for every packet 💪. Replay attack vulnerability is reduced because the sequence number must be incremented on every packet, the window size of acceptable packets is small, and the initial sequence number is randomized. There is still a window of attack at the beginning of the session while the sequence number is being determined. This authentication scheme requires an MD5 calculation on every packet transmitted and received 🥵.
Using SHA1 is believed to have stronger security properties than MD5 🌟. All comments about MD5 in this section also apply to SHA1.
Both Keyed MD5/SHA1 and Meticulous Keyed MD5/SHA1 use the "secret suffix" construction (also called "append only"). In this construction, the shared secret key is appended to the data before the hash is calculated. This is used instead of the more common Hashed Message Authentication Code (HMAC) construction [HMAC]. This construction is believed to be appropriate for BFD, but designers of any additional authentication mechanisms for BFD are encouraged to read [HMAC] and its references 📚.
If both systems randomize their Local Discriminator values at the beginning of a session, replay attacks may be further mitigated, no matter which authentication type is in use 🎲. Since the Local Discriminator may be changed at any time during a session, this mechanism may also help mitigate attacks.
The security implications of BFD Echo packets depend on how those packets are defined. Their structure is local to the transmitting system and outside the scope of this spec 🌀. Echo packets are defined and processed only by the transmitting system, so using cryptographic authentication doesn't guarantee the other system is actually alive. An attacker could loop the Echo packets back (without knowing any secret keys) and cause the link to be falsely declared up 🙀. A suitable interval for BFD Control packets can help mitigate this. [GTSM] could be applied to BFD Echo packets, though the TTL/Hop Count gets decremented by 1 while the packet is being echoed, so spoofing is possible from one hop away 👀.
10. References 📖
10.1. Normative References
[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.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[SHA1] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001.10.2. Informative References
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[IANA-CONSIDERATIONS]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.Appendix A. Backward Compatibility (Non-Normative) ✨
okay so version 0 of this protocol (the one from the early Internet-Draft versions that became this RFC) probably never got deployed widely 🥺 but some implementors might still want a backward compatibility mechanism, and that's totally valid bestie 💖 any mechanism is fair game as long as it doesn't change the protocol definition, so interoperability shouldn't be an issue 🫶
the suggested mechanism here is giving converge on version 1 energy 🦋 if both systems implement it, they'll end up on version 1, even if one of them got upgraded from version 0 in the middle of a Detection Time. it also interoperates with a system that only implements one version (or is configured to only support one version) 🌸 and a system should obviously not do this whole dance if it's configured for, or only capable of, a single version. no thanks 💅
here's the flow, iykyk 🧚
A BFD session enters a "negotiation holddown" if it's configured for automatic versioning and it either just started up or got manually cleared 🎀 the session gets set to AdminDown state and version 1. during the holddown, which lasts for one Detection Time, the system keeps sending BFD Control packets as usual, but it ignores anything it receives 🙈 once the holddown time is up, the state goes to Down and normal operation resumes ✨
when a system is NOT in holddown 👀 (lowercase just means I'm not yelling, promise 😭), and it's doing automatic versioning while currently using version 1, if it gets any version 0 packet for the session, it switches immediately to version 0. no waiting, no drama 🔥 if it's currently on version 0 and gets a version 1 packet saying the neighbor is in state AdminDown, it switches to version 1 💜 and if it's on version 0 and gets a version 1 packet with any other state, that packet just gets ignored (per spec) 🙃
if the version in use changes, the session goes down the way that makes sense for the new version: Down state for version 1, or Failing state for version 0 💅✨
Appendix B. Contributors 🎀
Kireeti Kompella and Yakov Rekhter of Juniper Networks were also significant contributors to this document 🫶 they basically helped build the thing, so they deserve their flowers 💐
Appendix C. Acknowledgments 🌈
this document was inspired by (and is intended to replace) the Protocol Liveness Protocol document, written by Kireeti Kompella 🦋 so she really set the vibe for this one ✨
demand mode was inspired by "A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers", by G. Huang, et al. 🧠 the idea of watching traffic instead of constantly pinging is lowkey genius 😭
the authors also want to thank Mike Shand, John Scudder, Stewart Bryant, Pekka Savola, Richard Spencer, and Pasi Eronen for their substantive input 💖 that's a whole squad of legends 👑
and the authors would also like to thank Owen Wheeler for hosting teleconferences between the authors of this specification and multiple vendors, so they could address implementation and clarity issues 🍓 literally the MVP of getting everyone on the same page 🫶
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📦 where this page comes from
- ietf: rfc5880 2010-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms