diff options
Diffstat (limited to 'doc/rfc/rfc5880.txt')
| -rw-r--r-- | doc/rfc/rfc5880.txt | 2747 |
1 files changed, 2747 insertions, 0 deletions
diff --git a/doc/rfc/rfc5880.txt b/doc/rfc/rfc5880.txt new file mode 100644 index 0000000..76b2b7c --- /dev/null +++ b/doc/rfc/rfc5880.txt @@ -0,0 +1,2747 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Katz +Request for Comments: 5880 D. Ward +Category: Standards Track Juniper Networks +ISSN: 2070-1721 June 2010 + + + Bidirectional Forwarding Detection (BFD) + +Abstract + + This document describes a protocol intended to detect faults in the + bidirectional path between two forwarding engines, including + interfaces, data link(s), and to the extent possible the forwarding + engines themselves, with potentially very low latency. It operates + independently of media, data protocols, and routing protocols. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/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 + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + +Katz & Ward Standards Track [Page 1] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + +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 + + + +Katz & Ward Standards Track [Page 2] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + 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 .......................................49 + +1. Introduction + + An increasingly important feature of networking equipment is the + rapid detection of communication failures between adjacent systems, + in order to more quickly establish alternative paths. Detection can + come fairly quickly in certain circumstances when data link hardware + comes into play (such as Synchronous Optical Network (SONET) alarms). + However, there are media that do not provide this kind of signaling + (such as Ethernet), and some media may not detect certain kinds of + failures in the path, for example, failing interfaces or forwarding + engine components. + + Networks use relatively slow "Hello" mechanisms, usually in routing + protocols, to detect failures when there is no hardware signaling to + help out. The time to detect failures ("Detection Times") available + in the existing protocols are no better than a second, which is far + too long for some applications and represents a great deal of lost + data at gigabit rates. Furthermore, routing protocol Hellos are of + no help when those routing protocols are not in use, and the + semantics of detection are subtly different -- they detect a failure + in the path between the two routing protocol engines. + + The goal of Bidirectional Forwarding Detection (BFD) is to provide + low-overhead, short-duration detection of failures in the path + between adjacent forwarding engines, including the interfaces, data + link(s), and, to the extent possible, the forwarding engines + themselves. + + An additional goal is to provide a single mechanism that can be used + for liveness detection over any media, at any protocol layer, with a + wide range of Detection Times and overhead, to avoid a proliferation + of different methods. + + This document specifies the details of the base protocol. The use of + some mechanisms are application dependent and are specified in a + separate series of application documents. These issues are so noted. + + + + + +Katz & Ward Standards Track [Page 3] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + Note that many of the exact mechanisms are implementation dependent + and will not affect interoperability, and are thus outside the scope + of this specification. Those issues are so noted. + +1.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [KEYWORDS]. + +2. Design + + BFD is designed to detect failures in communication with a forwarding + plane next hop. It is intended to be implemented in some component + of the forwarding engine of a system, in cases where the forwarding + and control engines are separated. This not only binds the protocol + more to the forwarding plane, but decouples the protocol from the + fate of the routing protocol engine, making it useful in concert with + various "graceful restart" mechanisms for those protocols. BFD may + also be implemented in the control engine, though doing so may + preclude the detection of some kinds of failures. + + BFD operates on top of any data protocol (network layer, link layer, + tunnels, etc.) being forwarded between two systems. It is always + run in a unicast, point-to-point mode. BFD packets are carried as + the payload of whatever encapsulating protocol is appropriate for the + medium and network. BFD may be running at multiple layers in a + system. The context of the operation of any particular BFD session + is bound to its encapsulation. + + BFD can provide failure detection on any kind of path between + systems, including direct physical links, virtual circuits, tunnels, + MPLS Label Switched Paths (LSPs), multihop routed paths, and + unidirectional links (so long as there is some return path, of + course). Multiple BFD sessions can be established between the same + pair of systems when multiple paths between them are present in at + least one direction, even if a lesser number of paths are available + in the other direction (multiple parallel unidirectional links or + MPLS LSPs, for example). + + The BFD state machine implements a three-way handshake, both when + establishing a BFD session and when tearing it down for any reason, + to ensure that both systems are aware of the state change. + + + + + + + + +Katz & Ward Standards Track [Page 4] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + BFD can be abstracted as a simple service. The service primitives + provided by BFD are to create, destroy, and modify a session, given + the destination address and other parameters. BFD in return provides + a signal to its clients indicating when the BFD session goes up or + down. + +3. Protocol Overview + + BFD is a simple Hello protocol that, in many respects, is similar to + the detection components of well-known routing protocols. A pair of + systems transmit BFD packets periodically over each path between the + two systems, 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 may negotiate not to send periodic BFD packets in order to + reduce overhead. + + A path is only declared to be operational when two-way communication + has been established between systems, though this does not preclude + the use of unidirectional links. + + A separate BFD session is 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 + in order to come to an agreement with its neighbor about how rapidly + detection of failure will take place. These estimates can be + modified in real time in order to adapt to unusual situations. This + design also allows for fast systems on a shared medium with a slow + system to be able to more rapidly detect failures between the fast + systems while allowing the slow system to participate to the best of + its ability. + +3.1. Addressing and Session Establishment + + A BFD session is established based on the needs of the application + that will be making use of it. It is up to the application to + determine the need for BFD, and the addresses to use -- there is no + discovery mechanism in BFD. For example, an OSPF [OSPF] + implementation may request a BFD session to be established to a + neighbor discovered using the OSPF Hello protocol. + +3.2. Operating Modes + + BFD has two operating modes that may be selected, as well as an + additional function that can be used in combination with the two + modes. + + + + +Katz & Ward Standards Track [Page 5] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + The primary mode is known as Asynchronous mode. In this mode, the + systems periodically send BFD Control packets to one another, and if + a number of those packets in a row are not received by the other + system, the session is declared to be down. + + The second mode is known as Demand mode. In this mode, it is assumed + that a system has an independent way of verifying that it has + connectivity to the other system. Once a BFD session is established, + such a system may ask the other system to stop sending BFD Control + packets, except when the system feels the need to verify connectivity + explicitly, in which case a short sequence of BFD Control packets is + exchanged, and then the far system quiesces. Demand mode may operate + independently in each direction, or simultaneously. + + An adjunct to both modes is the Echo function. When the Echo + function is active, a stream of BFD Echo packets is transmitted in + such a way as to have the other system loop them back through its + forwarding path. If a number of packets of the echoed data stream + are not received, the session is declared to be down. The Echo + function may be used with either Asynchronous or Demand mode. Since + the Echo function is handling the task of detection, the rate of + periodic transmission of Control packets may be reduced (in the case + of Asynchronous mode) or eliminated completely (in the case of Demand + mode). + + Pure Asynchronous mode is advantageous in that it requires half as + many packets to achieve a particular Detection Time as does the Echo + function. It is also used when the Echo function cannot be supported + for some reason. + + The Echo function has the advantage of truly testing only the + forwarding path on the remote system. This may reduce round-trip + jitter and thus allow more aggressive Detection Times, as well as + potentially detecting some classes of failure that might not + otherwise be detected. + + The Echo function may be enabled individually in each direction. It + is enabled in a particular direction only when the system that loops + the Echo packets back signals that it will allow it, and when the + system that sends the Echo packets decides it wishes to. + + Demand mode is useful in situations where the overhead of a periodic + protocol might prove onerous, such as a system with a very large + number of BFD sessions. It is also useful when the Echo function is + being used symmetrically. Demand mode has the disadvantage that + Detection Times are essentially driven by the heuristics of the + system implementation and are not known to the BFD protocol. Demand + + + + +Katz & Ward Standards Track [Page 6] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + mode 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. + +4. BFD Control Packet Format + +4.1. Generic BFD Control Packet Format + + BFD Control packets are sent in an encapsulation appropriate to the + environment. The specific encapsulation is outside of the scope of + this specification. See the appropriate application document for + encapsulation details. + + The BFD Control packet has a Mandatory Section and an optional + Authentication Section. The format of the Authentication Section, if + present, is dependent on the type of authentication in use. + + The Mandatory Section of a BFD Control packet has the following + format: + + 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. + + + +Katz & Ward Standards Track [Page 7] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + Diagnostic (Diag) + + A diagnostic code specifying the local system's reason for the + last change in session state. 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 use + + This field allows remote systems to determine the reason that the + previous session failed, for example. + + State (Sta) + + The current BFD session state as seen by the transmitting system. + Values are: + + 0 -- AdminDown + 1 -- Down + 2 -- Init + 3 -- Up + + Poll (P) + + If set, the transmitting system is requesting verification of + connectivity, or of a parameter change, and is expecting a packet + with the Final (F) bit in reply. If clear, the transmitting + system is not requesting verification. + + Final (F) + + If set, the transmitting system is responding to a received BFD + Control packet that had the Poll (P) bit set. If clear, the + transmitting system is not responding to a Poll. + + + + + + + + + + +Katz & Ward Standards Track [Page 8] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + Control Plane Independent (C) + + If set, the transmitting system's BFD implementation does not + share fate with its control plane (in other words, BFD is + implemented in the forwarding plane and can continue to function + through disruptions in the control plane). If clear, the + transmitting system's BFD implementation shares fate with its + control plane. + + The use of this bit is application dependent and is outside the + scope of this specification. See 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 (the + system wishes to operate in Demand mode, knows that the session is + Up in both directions, and is directing the remote system to cease + the periodic transmission of 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 + + Detection time multiplier. The negotiated transmit interval, + multiplied by this value, provides the Detection Time for the + receiving system in Asynchronous mode. + + Length + + Length of the BFD Control packet, in bytes. + + My Discriminator + + A unique, nonzero discriminator value generated by the + transmitting system, used to demultiplex multiple BFD sessions + between the same pair of systems. + + + + + +Katz & Ward Standards Track [Page 9] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + 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. + + 0 - Reserved + 1 - Simple Password + 2 - Keyed MD5 + 3 - Meticulous Keyed MD5 + 4 - Keyed SHA1 + 5 - Meticulous Keyed SHA1 + 6-255 - Reserved for future use + + Auth Len + + The length, in bytes, of the authentication section, including the + Auth Type and Auth Len fields. + + + + + +Katz & Ward Standards Track [Page 10] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + +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 has the following format: + + 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 allows + multiple keys to be active simultaneously. + + Password + + The simple password in use on this session. The password is a + binary string, and 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 + + The use of MD5-based authentication is strongly discouraged. + However, it is documented here for compatibility with existing + implementations. + + If the Authentication Present (A) bit is set in the header, and the + Authentication Type field contains 2 (Keyed MD5) or 3 (Meticulous + Keyed MD5), the Authentication Section has the following format: + + + + + +Katz & Ward Standards Track [Page 11] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + 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 allows + multiple keys to be active simultaneously. + + 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 is incremented occasionally. For + Meticulous Keyed MD5 Authentication, this value is incremented for + each successive packet transmitted for a session. This provides + protection 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. + + + + + + +Katz & Ward Standards Track [Page 12] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + +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 contains 4 (Keyed SHA1) or 5 (Meticulous + Keyed SHA1), the Authentication Section has the following format: + + 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 allows + multiple keys to be active simultaneously. + + 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 is incremented occasionally. For + Meticulous Keyed SHA1 Authentication, this value is incremented + for each successive packet transmitted for a session. This + provides protection against replay attacks. + + + + + + + +Katz & Ward Standards Track [Page 13] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + 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 are sent in an encapsulation appropriate to the + environment. See the appropriate application documents for the + specifics of particular environments. + + 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 sufficient information is included to demultiplex the received + packet to the correct BFD session after it is looped back to the + sender. The contents are otherwise outside the scope of this + specification. + + Some form of authentication SHOULD be included, since Echo packets + may be spoofed. + +6. Elements of Procedure + + This section discusses the normative requirements of the protocol in + order to achieve interoperability. It is important for implementors + to enforce only the requirements specified in this section, as + misguided pedantry has been proven by experience to affect + interoperability adversely. + + Remember that all references of the form "bfd.Xx" refer to internal + state variables (defined in section 6.8.1), whereas all references to + "the Xxx field" refer to fields in the protocol packets themselves + (defined in section 4). + +6.1. Overview + + A system may 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, regardless of whether 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 thus + has learned the remote system's discriminator value. At least one + system MUST take the Active role (possibly both). The role that a + system takes is specific to the application of BFD, and is outside + the scope of this specification. + + + +Katz & Ward Standards Track [Page 14] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + A session begins with the periodic, slow transmission of BFD Control + packets. When 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 desires and the other system signals that it will + allow it. The rate of transmission of Control packets is typically + kept low when the Echo function is active. + + If the Echo function is not active, the transmission rate of Control + packets may be increased to a level necessary to achieve the + Detection Time requirements for the session. + + Once the session is Up, a system may signal that it has entered + Demand mode, and the transmission of BFD Control packets by the + remote system ceases. Other means of implying connectivity are used + to keep the session alive. If either system wishes to verify + bidirectional connectivity, it can initiate a short exchange of BFD + Control packets (a "Poll Sequence"; see section 6.5) to do so. + + If Demand mode is not active, and no Control packets are received in + the calculated Detection Time (see section 6.8.4), the session is + declared Down. This is signaled to the remote end via the State + (Sta) field in outgoing packets. + + If sufficient Echo packets are lost, the session is declared Down in + the same manner. See section 6.8.5. + + If Demand mode is active and no appropriate Control packets are + received in response to a Poll Sequence, the session is declared Down + in the same manner. See section 6.6. + + If the session goes Down, the transmission of Echo packets (if any) + ceases, and the transmission of Control packets goes back to the slow + rate. + + Once a session has been declared Down, it cannot come back up until + the remote end first signals that it is down (by leaving the Up + state), thus implementing a three-way handshake. + + A session MAY be kept administratively down by entering the AdminDown + state and sending an explanatory diagnostic code in the Diagnostic + field. + + + + + + + + +Katz & Ward Standards Track [Page 15] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + +6.2. BFD State Machine + + The BFD state machine is quite straightforward. There are three + states through which a session normally proceeds: two for + establishing a session (Init and Up) and one for tearing down a + session (Down). This allows a three-way handshake for both session + establishment and session teardown (assuring that both systems are + aware of all session state changes). A fourth state (AdminDown) + exists so that a session can be administratively put down + indefinitely. + + Each system communicates its session state in the State (Sta) field + in the BFD Control packet, and that received state, in combination + with the local session state, drives the state machine. + + Down state means that the session is down (or has just been created). + A session remains in Down state until the remote system indicates + that it agrees that 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 state, the session advances to Init state; if + that packet signals Init state, the session advances to Up state. + Semantically, Down state indicates that the forwarding path is + unavailable, and that appropriate actions should be taken by the + applications monitoring the state of the BFD session. A system MAY + hold a session in Down state indefinitely (by simply refusing to + advance the session state). This may be done for operational or + administrative reasons, among others. + + Init state means that the remote system is communicating, and the + local system desires to bring the session up, but the remote system + does not yet realize it. A session will remain in Init state until + either a BFD Control Packet is received that is signaling Init or Up + state (in which case the session advances to Up state) or the + Detection Time expires, meaning that communication with the remote + system has been lost (in which case the session advances to Down + state). + + Up state means that the BFD session has successfully been + established, and implies that connectivity between the systems is + working. The session will remain in the Up state until either + connectivity fails or the session is taken down administratively. If + either the remote system signals Down state or the Detection Time + expires, the session advances to Down state. + + + + + + + + +Katz & Ward Standards Track [Page 16] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + AdminDown state means that the session is being held administratively + down. This causes the remote system to enter Down state, and remain + there until the local system exits AdminDown state. AdminDown state + has no semantic implications for the availability of the forwarding + path. + + The following diagram provides an overview of the state machine. + Transitions involving AdminDown state are deleted for clarity (but + are fully specified in sections 6.8.6 and 6.8.16). The notation on + each arc represents the state of the remote system (as received in + the State field in the BFD Control packet) or indicates 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 + + Since multiple BFD sessions may be running between two systems, there + needs to be a mechanism for demultiplexing received BFD packets to + the proper session. + + Each system MUST choose an opaque discriminator value that identifies + each session, and which MUST be unique among all BFD sessions on the + system. The local discriminator is sent in the My Discriminator + field in the BFD Control packet, and is echoed back in the Your + Discriminator field of packets sent from the remote end. + + + + + + + + +Katz & Ward Standards Track [Page 17] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + Once the remote end echoes back the local discriminator, all further + received packets are demultiplexed based on the Your Discriminator + field only (which means that, among other things, the source address + field can change or the interface over which the packets are received + can change, but the packets will still be associated with the proper + session). + + The method of demultiplexing the initial packets (in which Your + Discriminator is zero) is application dependent, and is thus outside + the scope of this specification. + + Note that it is permissible for a system to change its discriminator + during a session without affecting the session state, since only that + system uses its discriminator for demultiplexing purposes (by having + the other system reflect it back). The implications on an + implementation for changing the discriminator value is outside the + scope of this specification. + +6.4. The Echo Function and Asymmetry + + The Echo function can be run independently in each direction between + a pair of systems. For whatever reason, a system may advertise that + it is willing to receive (and loop back) Echo packets, but may not + wish to ever send any. The fact that a system is sending Echo + packets is not directly signaled to the system looping them back. + + When a system is using the Echo function, it is advantageous to + choose a sedate reception rate for Control packets, since liveness + detection is being handled by the Echo packets. This can be + controlled by manipulating the Required Min RX Interval field (see + section 6.8.3). + + If the Echo function is only being run in one direction, the system + not running the Echo function will more likely wish to receive fairly + rapid Control packets in order to achieve its desired Detection Time. + Since BFD allows independent transmission rates in each direction, + this is easily accomplished. + + A system SHOULD otherwise advertise the lowest value of Required Min + RX Interval and Required Min Echo RX Interval that it can under the + circumstances, to give the other system more freedom in choosing its + transmission rate. Note that a system is committing to be able to + receive both streams of packets at the rate it advertises, so this + should be taken into account when choosing the values to advertise. + + + + + + + +Katz & Ward Standards Track [Page 18] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + +6.5. The Poll Sequence + + A Poll Sequence is an exchange of BFD Control packets that is used in + some circumstances to ensure that the remote system is aware of + parameter changes. It is also used in Demand mode (see section 6.6) + to validate bidirectional connectivity. + + A Poll Sequence consists of a system sending 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, independent of any periodic BFD Control packets it may + be sending (see section 6.8.7). When the system sending the Poll + sequence receives a packet with Final, the Poll Sequence is + terminated, and any subsequent BFD Control packets are sent with the + Poll bit cleared. A BFD Control packet MUST NOT have both the Poll + (P) and Final (F) bits set. + + If periodic BFD Control packets are already being sent (the remote + system is not 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 is terminated, the system requesting the Poll + Sequence will cease the periodic transmission of BFD Control packets + if the remote end is in Demand mode; otherwise, it will return to the + periodic transmission of BFD Control packets with the Poll (P) bit + clear. + + Typically, the entire sequence consists of a single packet in each + direction, though packet losses or relatively long packet latencies + may result in multiple Poll packets to be sent before the sequence + terminates. + +6.6. Demand Mode + + Demand mode is requested independently in each direction by virtue of + a system setting the Demand (D) bit in its BFD Control packets. The + system receiving the Demand bit ceases the periodic transmission of + BFD Control packets. If both systems are operating in Demand mode, + no periodic BFD Control packets will flow in either direction. + + Demand mode requires that some other mechanism is used to imply + continuing connectivity between the two systems. The mechanism used + does not have to be the same in both directions, and is outside of + the scope of this specification. One possible mechanism is the + receipt of traffic from the remote system; another is the use of the + Echo function. + + + + +Katz & Ward Standards Track [Page 19] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + When a system in Demand mode wishes to verify bidirectional + connectivity, it initiates a Poll Sequence (see section 6.5). If no + response is received to a Poll, the Poll is repeated until the + Detection Time expires, at which point the session is declared to be + Down. Note that if Demand mode is operating only on the local + system, the Poll Sequence is performed by simply setting the Poll (P) + bit in regular periodic BFD Control packets, as required by section + 6.5. + + The Detection Time in Demand mode is calculated differently than in + Asynchronous mode; it is based on the transmit rate of the local + system, rather than the transmit rate of the remote system. This + ensures that the Poll Sequence mechanism works properly. See section + 6.8.4 for more details. + + Note that the Poll mechanism will always fail unless the negotiated + Detection Time is greater than the round-trip time between the two + systems. Enforcement of this constraint is outside the scope of this + specification. + + Demand mode MAY be enabled or disabled at any time, independently in + each direction, by setting or clearing the Demand (D) bit in the BFD + Control packet, without affecting the BFD session state. Note that + the Demand bit MUST NOT be set unless both systems perceive the + session to be Up (the local system thinks the session is Up, and the + remote system last reported Up state in the State (Sta) field of the + BFD Control packet). + + When the transmitted value of the Demand (D) bit is to be changed, + the transmitting system MUST initiate a Poll Sequence in conjunction + with changing the bit in order to ensure that both systems are aware + of the change. + + If Demand mode is active on either or both systems, a Poll Sequence + MUST be initiated whenever the contents of the next BFD Control + packet to be sent would be different than the contents of the + previous packet, with the exception of the Poll (P) and Final (F) + bits. This ensures that parameter changes are transmitted to the + remote system and that the remote system acknowledges these changes. + + Because the underlying detection mechanism is unspecified, and may + differ between the two systems, the overall Detection Time + characteristics of the path will not be fully known to either system. + The total Detection Time for a particular system is the sum of the + time prior to the initiation of the Poll Sequence, plus the + calculated Detection Time. + + + + + +Katz & Ward Standards Track [Page 20] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + Note that if Demand mode is enabled in only one direction, continuous + bidirectional connectivity verification is lost (only connectivity in + the direction from the system in Demand mode to the other system will + be verified). Resolving the issue of one system requesting Demand + mode while the other requires continuous bidirectional connectivity + verification is outside the scope of this specification. + +6.7. Authentication + + An optional Authentication Section MAY be present in the BFD Control + packet. In its generic form, the purpose of the Authentication + Section is to carry all necessary information, based on the + authentication type in use, to allow the receiving system to + determine the validity of the received packet. The exact mechanism + depends on the authentication type in use, but in general the + transmitting system will put information in the Authentication + + Section that vouches for the packet's validity, and the receiving + system will examine the Authentication Section and either accept the + packet for further processing or discard it. + + The same authentication type, and any keys or other necessary + information, obviously must be in use by the two systems. The + negotiation of authentication type, key exchange, etc., are all + outside the scope of this specification and are expected to be + performed by means outside of the protocol. + + Note that in the subsections below, to "accept" a packet means only + that the packet has passed authentication; it may in fact be + discarded for other reasons as described in the general packet + reception rules described in section 6.8.6. + + Implementations supporting authentication MUST support both types of + SHA1 authentication. Other forms of authentication are optional. + +6.7.1. Enabling and Disabling Authentication + + It may be desirable to enable or disable authentication on a session + without disturbing the session state. The exact mechanism for doing + so is outside the scope of this specification. However, it is useful + to point out some issues in supporting this mechanism. + + In a simple implementation, a BFD session will fail when + authentication is either turned on or turned off, because the packet + acceptance rules essentially require the local and remote machines to + + + + + + +Katz & Ward Standards Track [Page 21] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + do so in a more or less synchronized fashion (within the Detection + Time) -- a packet with authentication will only be accepted if + authentication is "in use" (and likewise packets without + authentication). + + One possible approach is to build an implementation such that + authentication is configured, but not considered "in use" until the + first packet containing a matching authentication section is received + (providing the necessary synchronization). Likewise, authentication + could be configured off, but still considered "in use" until the + receipt of the first packet without the authentication section. + + In order 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 (so that authentication cannot be + turned on and off repeatedly simply based on the receipt of BFD + Control packets from remote systems). Unless it is desired to enable + or disable authentication, an implementation SHOULD NOT allow the + authentication state to change based on the receipt of BFD Control + packets. + +6.7.2. Simple Password Authentication + + The most straightforward (and weakest) form of authentication is + Simple Password Authentication. In this method of authentication, + one or more Passwords (with corresponding Key IDs) are configured in + each system and one of these Password/ID pairs is carried in each BFD + Control packet. The receiving system accepts the packet if the + Password and Key ID matches one of the Password/ID pairs configured + in 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 (4 to 19 + bytes). + + The password is a binary string, and MUST be 1 to 16 bytes in + length. For interoperability, the management interface by which + the password 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. + + + + + + + +Katz & Ward Standards Track [Page 22] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + Reception Using Simple Password Authentication + + If the received BFD Control packet does not 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 does not match the ID of a configured + password, the received packet MUST be discarded. + + If the Auth Len field is not equal to the length of the password + selected by the key ID, plus three, the packet MUST be discarded. + + If the Password field does not 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 + + The Keyed MD5 and Meticulous Keyed MD5 Authentication mechanisms are + very similar to those used in other protocols. In these methods of + authentication, one or more secret keys (with corresponding key IDs) + are configured in each system. One of the keys is included in an MD5 + [MD5] digest calculated over the outgoing BFD Control packet, but the + Key itself is not carried in the packet. To help avoid replay + attacks, a sequence number is also carried in each packet. For Keyed + MD5, the sequence number is occasionally incremented. For Meticulous + Keyed MD5, the sequence number is incremented on every packet. + + The receiving system accepts the packet if the key ID matches one of + the configured Keys, an MD5 digest including the selected key matches + that 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 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 + + + + +Katz & Ward Standards Track [Page 23] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + 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). + + 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). + + 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. + + 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. + + + + +Katz & Ward Standards Track [Page 24] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + 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. + +6.7.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication + + The Keyed SHA1 and Meticulous Keyed SHA1 Authentication mechanisms + are very similar to those used in other protocols. In these methods + of authentication, one or more secret keys (with corresponding key + IDs) are configured in each system. One of the keys is included in a + SHA1 [SHA1] hash calculated over the outgoing BFD Control packet, but + the key itself is not carried in the packet. To help avoid replay + attacks, a sequence number is also carried in each packet. For Keyed + SHA1, the sequence number is occasionally incremented. For + Meticulous Keyed SHA1, the sequence number is incremented 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 + that carried in the packet, and if 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 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). + + + + +Katz & Ward Standards Track [Page 25] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + 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). + + 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. + + 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. + + 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. + + + + + + +Katz & Ward Standards Track [Page 26] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + +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. + + 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. + +6.8.1. State Variables + + A minimum amount of information about a session needs to be tracked + in order to achieve the elements of procedure described here. The + following is a set of state variables that are helpful in describing + the mechanisms of BFD. Any means of tracking this state may be used + so long as the protocol behaves as described. + + When the text refers to initializing a state variable, this takes + place only at the time that the session (and the corresponding state + variables) is created. The state variables are subsequently + manipulated by the state machine and are never reinitialized, even if + the session fails and is reestablished. + + Once session state is created, and at least one BFD Control packet is + received from the remote end, it MUST be preserved for at least one + Detection Time (see section 6.8.4) subsequent to the receipt of the + last BFD Control packet, regardless of the session state. This + preserves timing parameters in case the session flaps. A system MAY + preserve session state longer than this. The preservation or + destruction of session state when no BFD Control packets for this + session have been received from the remote system is outside the + scope of this specification. + + + + + + + +Katz & Ward Standards Track [Page 27] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + All state variables in this specification are of the form "bfd.Xx" + and should not be confused with fields carried in the protocol + packets, which are always spelled out to match the names in section + 4. + + bfd.SessionState + + 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 specification, though it is expected that this + state change (particularly, to and from Up state) is reported to + other components of the system. This variable MUST be initialized + to Down. + + bfd.RemoteSessionState + + 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 + + The local discriminator for this BFD session, used to uniquely + identify it. It MUST be unique across all BFD sessions on this + system, and nonzero. It SHOULD be set to a random (but still + unique) value to improve security. The value is otherwise outside + the scope of this specification. + + bfd.RemoteDiscr + + The remote discriminator for this BFD session. This is the + discriminator chosen by the remote system, and is totally opaque + to the local system. This MUST be initialized to zero. If a + period of a Detection Time passes without the receipt of a valid, + authenticated BFD packet from the remote system, this variable + MUST be set to zero. + + bfd.LocalDiag + + The diagnostic code specifying the reason for the most recent + change in the local session state. This MUST be initialized to + zero (No Diagnostic). + + + + + + + + + +Katz & Ward Standards Track [Page 28] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + bfd.DesiredMinTxInterval + + The minimum interval, in microseconds, between transmitted BFD + Control packets that this system would like to use at the current + time, less any jitter applied (see section 6.8.2). The actual + interval is negotiated between the two systems. This MUST be + initialized to a value of at least one second (1,000,000 + microseconds) according to the rules described in section 6.8.3. + The setting of this variable is otherwise outside the scope of + this specification. + + bfd.RequiredMinRxInterval + + The minimum interval, in microseconds, between received BFD + Control packets that this system requires, less any jitter applied + by the sender (see section 6.8.2). The setting of this variable + is outside the scope of this specification. A value of zero means + that this system does not want to receive any periodic BFD Control + packets. See section 6.8.18 for details. + + bfd.RemoteMinRxInterval + + 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 + + Set to 1 if the local system wishes to use Demand mode, or 0 if + not. + + bfd.RemoteDemandMode + + Set to 1 if the remote system wishes to use Demand mode, or 0 if + not. This is the value of the Demand (D) bit in the last received + BFD Control packet. This variable MUST be initialized to zero. + + bfd.DetectMult + + The desired Detection Time multiplier for BFD Control packets on + the local system. The negotiated Control packet transmission + interval, multiplied by this variable, will be 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 specification. See section 6.8.4 for further information. + + + + + + +Katz & Ward Standards Track [Page 29] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + bfd.AuthType + + The authentication type in use for this session, as defined in + section 4.1, or zero if no authentication is in use. + + bfd.RcvAuthSeq + + A 32-bit unsigned integer containing the last sequence number for + Keyed MD5 or SHA1 Authentication that was received. The initial + value is unimportant. + + bfd.XmitAuthSeq + + A 32-bit unsigned integer containing 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 + + Set to 1 if the next sequence number for Keyed MD5 or SHA1 + authentication expected to be received is known, or 0 if it is not + known. 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 ensures that the sequence number can be resynchronized if the + remote system restarts. + +6.8.2. Timer Negotiation + + The time values used to determine BFD packet transmission intervals + and the session Detection Time are continuously negotiated, and thus + may be changed at any time. The negotiation and time values are + independent in each direction for each session. + + Each system reports in the BFD Control packet how rapidly it would + like to transmit BFD packets, as well as how rapidly it is prepared + to receive them. This allows either system to unilaterally determine + the maximum packet rate (minimum interval) in both directions. + + See section 6.8.7 for the details of packet transmission timing and + negotiation. + + + + + + + + + +Katz & Ward Standards Track [Page 30] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + +6.8.3. Timer Manipulation + + The time values used to determine BFD packet transmission intervals + and the session Detection Time may be modified at any time without + affecting the state of the session. When the timer parameters are + changed for any reason, the requirements of this section apply. + + If either bfd.DesiredMinTxInterval is changed or + bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be + initiated (see section 6.5). If the timing is such that a system + receiving a Poll Sequence wishes 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 has not yet + been sent. + + 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 is to ensure that the + remote system updates its Detection Time before the transmission + interval increases. + + 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 is to ensure that the + remote system is transmitting packets at the higher rate (and those + packets are being received) prior to the Detection Time being + 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 intended to ensure that the + bandwidth consumed by BFD sessions that are not Up is negligible, + particularly in the case where a neighbor may not be running BFD. + + If the local system reduces its transmit interval due to + bfd.RemoteMinRxInterval being reduced (the remote system has + 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 cannot + wait longer than the new interval between the previous packet + transmission and the next one. If this 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. + + + + + + +Katz & Ward Standards Track [Page 31] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + 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 intended to keep received BFD + Control traffic at a negligible level, since the actual detection + function is being performed 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). + + Note that the Poll Sequence mechanism is ambiguous if more than one + parameter change is made that would require its use, and those + multiple changes are spread across multiple packets (since the + semantics of the returning Final are unclear). Therefore, if + multiple changes are made that require the use of a Poll Sequence, + there are three choices: 1) they MUST be communicated in a single BFD + Control packet (so the semantics of the Final reply are clear), or 2) + sufficient time must have transpired since the Poll Sequence was + completed to disambiguate the situation (at least a round trip time + since the last Poll was transmitted) prior to the initiation of + another Poll Sequence, or 3) an additional BFD Control packet with + the Final (F) bit *clear* MUST be received after the Poll Sequence + has completed prior to the initiation of another Poll Sequence (this + option is not available when Demand mode is active). + +6.8.4. Calculating the Detection Time + + The Detection Time (the period of time without receiving BFD packets + after which the session is determined to have failed) is not carried + explicitly in the protocol. Rather, it is calculated independently + in each direction by the receiving system based on the negotiated + transmit interval and the detection multiplier. Note that there may + be different Detection Times in each direction. + + The calculation of the Detection Time is slightly different when in + Demand mode versus Asynchronous mode. + + In Asynchronous mode, the Detection Time calculated in the local + system is equal to the value of Detect Mult 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). The Detect Mult value 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. + + + + + + + +Katz & Ward Standards Track [Page 32] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + If Demand mode is not active, and a period of time equal to the + Detection Time passes without receiving 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). + + (Note that a packet is considered to have been received, for the + purposes of Detection Time expiration, only if it has not been + "discarded" according to the rules of section 6.8.6). + +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 the Echo function failures are detected is outside + of the scope of this specification. Any means that will detect a + communication failure are acceptable. + +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. + + 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. + + + + +Katz & Ward Standards Track [Page 33] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + If the Length field is greater than the payload of the + encapsulating protocol, the packet MUST be discarded. + + If the Detect Mult field is zero, the packet MUST be discarded. + + If the Multipoint (M) bit is nonzero, the packet MUST be + discarded. + + If the My Discriminator field is zero, the packet MUST be + discarded. + + If the Your Discriminator field 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 Discriminator field is zero and the State field is not + Down or AdminDown, the packet MUST be discarded. + + If the Your Discriminator field is zero, the session MUST be + selected based on some combination of other fields, possibly + including source addressing information, the My Discriminator + field, 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.AuthType + is zero), the packet MUST be discarded. + + If the A bit is clear and authentication is in use (bfd.AuthType + is 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.RemoteDiscr to the value of My Discriminator. + + Set bfd.RemoteState to the value of the State (Sta) field. + + Set bfd.RemoteDemandMode to the value of the Demand (D) bit. + + Set bfd.RemoteMinRxInterval to the value of Required Min RX + Interval. + + + + + +Katz & Ward Standards Track [Page 34] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + 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. + + 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 Down + + Check to see if Demand mode should become active or not (see + section 6.6). + + If bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and + bfd.RemoteSessionState is 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). + + + + + +Katz & Ward Standards Track [Page 35] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or + bfd.RemoteSessionState is 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 + + With the exceptions listed in the remainder of this section, a system + MUST NOT transmit BFD Control packets at an interval less than the + larger of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval, less + applied jitter (see below). In other words, the system reporting the + slower rate determines the transmission rate. + + The periodic transmission of BFD Control packets MUST be jittered on + a per-packet basis by up to 25%, that is, the interval MUST be + reduced by a random value of 0 to 25%, in order to avoid self- + synchronization with other systems on the same subnetwork. Thus, the + average interval between packets will be roughly 12.5% less than that + 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 to ensure that, on the remote system, + the calculated Detection Time does not pass prior to the receipt of + the next BFD Control packet. + + The transmit interval MUST be recalculated whenever + bfd.DesiredMinTxInterval changes, or whenever bfd.RemoteMinRxInterval + changes, and is equal to the greater of those two values. See + sections 6.8.2 and 6.8.3 for 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. + + + + + + + +Katz & Ward Standards Track [Page 36] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + 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. + + 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, + without respect to the transmission timer or any other transmission + limitations, without respect to the session state, and without + respect to whether Demand mode is active on either system. 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 the contents of + that packet would differ from that in the previously transmitted + packet (other than the Poll and Final bits) in order to more rapidly + communicate a change in state. + + The contents of transmitted BFD Control packets MUST be set as + follows: + + Version + + Set to the current version number (1). + + Diagnostic (Diag) + + Set to bfd.LocalDiag. + + State (Sta) + + Set to the value indicated by bfd.SessionState. + + Poll (P) + + Set to 1 if the local system is sending a Poll Sequence, or 0 if + not. + + + + + + + +Katz & Ward Standards Track [Page 37] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + 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 continue to function through a + disruption of the control plane). + + Authentication Present (A) + + Set to 1 if authentication is in use on this session (bfd.AuthType + is nonzero), or 0 if not. + + Demand (D) + + Set to bfd.DemandMode if bfd.SessionState is Up and + bfd.RemoteSessionState is Up. Otherwise, it is set to 0. + + Multipoint (M) + + Set to 0. + + Detect Mult + + Set to bfd.DetectMult. + + Length + + Set to the appropriate length, based on the fixed header length + (24) plus any Authentication Section. + + My Discriminator + + Set to bfd.LocalDiscr. + + Your Discriminator + + Set to bfd.RemoteDiscr. + + Desired Min TX Interval + + Set to bfd.DesiredMinTxInterval. + + + + + + +Katz & Ward Standards Track [Page 38] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + Required Min RX Interval + + Set to bfd.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.AuthType is 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 of the + Echo packets that are received. The processing of received Echo + packets is otherwise outside the scope of this specification. + +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, such that + 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. + + The transmission of BFD Echo packets is otherwise outside the scope + of this specification. + + + + + + + +Katz & Ward Standards Track [Page 39] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + +6.8.10. Min Rx Interval Change + + When it is desired 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 will be transmitted + in the next outgoing Control packet, and the remote system will + adjust accordingly. See section 6.8.3 for further requirements. + +6.8.11. Min Tx Interval Change + + When it is desired 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 it is desired to change the detect multiplier, the value of + bfd.DetectMult can be changed to any nonzero value. The new value + will be transmitted with the next BFD Control packet, and the use of + a Poll Sequence is not necessary. See section 6.6 for additional + requirements. + +6.8.13. Enabling or Disabling The Echo Function + + If it is desired to start or stop the transmission of BFD Echo + packets, this MAY be done at any time (subject to the transmission + requirements detailed in section 6.8.9). + + If it is desired to enable or disable the looping back of received + BFD Echo packets, this MAY be done 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 it is desired to start or stop Demand mode, this MAY be done at + any time by setting bfd.DemandMode to the proper value. Demand mode + will subsequently 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. + + + + + + + +Katz & Ward Standards Track [Page 40] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + +6.8.15. Forwarding Plane Reset + + When the forwarding plane in the local system is reset for some + reason, such that 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 + + There may be circumstances where it is desirable to administratively + enable or disable a BFD session. When this is desired, 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 packets + + If 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 in order to ensure that + the remote system is aware of the state change. BFD Control packets + MAY be transmitted indefinitely after transitioning to AdminDown + state in order to maintain session state in each system (see section + 6.8.18 below). + +6.8.17. Concatenated Paths + + If the path being monitored by BFD 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 (providing an interworking function for liveness monitoring + between BFD and other technologies). + + Two diagnostic codes are defined for this purpose: Concatenated Path + Down and Reverse Concatenated Path Down. The first propagates + forward path failures (in which the concatenated path fails in the + direction toward the interworking system), and the second propagates + + + + + +Katz & Ward Standards Track [Page 41] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + reverse path failures (in which 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, no other action is necessary, as the diagnostic code + will be carried via the periodic transmission of BFD Control packets. + If Demand mode is active on the remote system (the local system is + not transmitting periodic BFD Control packets), a Poll Sequence MUST + be initiated to ensure that the diagnostic code is transmitted. Note + that if the BFD session subsequently fails, the diagnostic code will + be overwritten with a code detailing the cause of the failure. It is + up to the interworking agent to perform the above procedure again, + once the BFD session reaches Up state, if the propagation of the + concatenated path failure is to resume. + +6.8.18. Holding Down Sessions + + A system MAY choose to prevent a BFD session from being established. + One possible reason might be to manage the rate at which sessions are + established. This can be done by holding the session in Down or + AdminDown state, as appropriate. + + There are two related mechanisms that are available to help with this + task. First, a system is REQUIRED to maintain session state + (including timing parameters), even when a session is down, until a + Detection Time has passed without the receipt of any BFD Control + packets. This means that a system may take down a session and + transmit an arbitrarily large value in the Required Min RX Interval + field to control the rate at which it receives packets. + + Additionally, a system MAY transmit a value of zero for Required Min + RX Interval to indicate that the remote system should send no packets + whatsoever. + + So long as the local system continues to transmit BFD Control + packets, the remote system is obligated to obey the value carried in + Required Min RX Interval. If the remote system does not receive any + BFD Control packets for a Detection Time, it SHOULD reset + bfd.RemoteMinRxInterval to its initial value of 1 (per section 6.8.1, + since it is no longer required to maintain previous session state) + and then can transmit at its own rate. + + + + + + + +Katz & Ward Standards Track [Page 42] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + +7. Operational Considerations + + BFD is likely to be deployed as a critical part of network + infrastructure. As such, care should be taken to avoid disruption. + + Obviously, any mechanism that blocks BFD packets, such as firewalls + or other policy processes, will cause BFD to fail. + + Mechanisms that control packet scheduling, such as policers, traffic + shapers, priority queueing, etc., have the potential of impacting BFD + operations if the Detection Time is similar in scale to the scheduled + packet transmit or receive rate. The delivery of BFD packets is + time-critical, relative to the magnitude of the Detection Time, so + this may need to be taken into account in implementation and + deployment, particularly when very short Detection Times are to be + used. + + When BFD is used across multiple hops, a congestion control mechanism + MUST be implemented, and when congestion is detected, the BFD + implementation MUST reduce the amount of traffic it generates. The + exact mechanism used is outside the scope of this specification, and + the requirements of this mechanism may differ depending on how BFD is + deployed, and how it interacts with other parts of the system (for + example, exponential backoff may not be appropriate in cases where + routing protocols are interacting closely with BFD). + + Note that "congestion" is not only a traffic phenomenon, but also a + computational one. It is possible for systems with a large number of + BFD sessions and/or very short packet intervals to become CPU-bound. + As such, a congestion control algorithm SHOULD be used even across + single hops in order to avoid the possibility of catastrophic system + collapse, as such failures have been seen repeatedly in other + periodic Hello-based protocols. + + The mechanisms for detecting congestion are outside the scope of this + specification, but may include the detection of lost BFD Control + packets (by virtue of holes in the authentication sequence number + space, or by BFD session failure) or other means. + + The mechanisms for reducing BFD's traffic load are the control of the + local and remote packet transmission rate via the Min RX Interval and + Min TX Interval fields. + + Note that any mechanism that increases the transmit or receive + intervals will increase the Detection Time for the session. + + + + + + +Katz & Ward Standards Track [Page 43] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + It is worth noting that a single BFD session does not consume a large + amount of bandwidth. An aggressive session that achieves 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, for a total of around 48 kilobits per second of + bandwidth consumption in each direction. + +8. IANA Considerations + + This document defines two registries administered by IANA. The first + 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 Unassigned + + The 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 Unassigned + + + + + + +Katz & Ward Standards Track [Page 44] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + +9. Security Considerations + + As BFD may be tied into the stability of the network infrastructure + (such as routing protocols), the effects of an attack on a BFD + session may be very serious: a link may be falsely declared to be + down, or falsely declared to be up; in either case, the effect is + denial of service. + + An attacker who is in complete control of the link between the + systems can easily drop all BFD packets but forward everything else + (causing the link to be falsely declared down), or forward only the + BFD packets but nothing else (causing the link to be falsely declared + up). This attack cannot be prevented by BFD. + + To mitigate 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 prevent off-link attackers from spoofing packets. + The Authentication Section authenticates the BFD Control packets. + These mechanisms are described in more detail 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, and checked to be equal to + the maximum value on reception (and the packet dropped if this is not + the case). See [GTSM] for more information on this technique. If + BFD is run across multiple hops or an insecure tunnel (such as + Generic Routing Encapsulation (GRE)), the Authentication Section + SHOULD be utilized. + + The level of security provided by the Authentication Section varies + based on the authentication type used. Simple Password + authentication is obviously only as secure as the secrecy of the + passwords used, and should be considered only if the BFD session is + guaranteed to be run over an infrastructure not subject to packet + interception. Its chief advantage is that it minimizes the + computational effort required for authentication. + + Keyed MD5 Authentication is much stronger than Simple Password + Authentication since the keys cannot be discerned by intercepting + packets. It is vulnerable to replay attacks in between increments of + the sequence number. The sequence number can be incremented as + seldom (or as often) as desired, trading off resistance to replay + attacks with the computational effort required for authentication. + + Meticulous Keyed MD5 authentication is stronger yet, as it requires + the sequence number to be incremented for every packet. Replay + attack vulnerability is reduced due to the requirement that the + + + +Katz & Ward Standards Track [Page 45] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + 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 which the shared + secret key is appended to the data before calculating the hash, + 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, + regardless of the authentication type 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 the use of BFD Echo packets are + dependent on how those packets are defined, since their structure is + local to the transmitting system and outside the scope of this + specification. However, since Echo packets are defined and processed + only by the transmitting system, the use of cryptographic + authentication does not guarantee that 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 to be up. + This can be mitigated by using a suitable interval for BFD Control + packets. [GTSM] could be applied to BFD Echo packets, though the + TTL/Hop Count will be decremented by 1 in the course of echoing the + packet, 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. + + + + +Katz & Ward Standards Track [Page 46] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Katz & Ward Standards Track [Page 47] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + +Appendix A. Backward Compatibility (Non-Normative) + + Although version 0 of this protocol (as defined in early versions of + the Internet-Draft that became this RFC) is unlikely to have been + deployed widely, some implementors may wish to have a backward + compatibility mechanism. Note that any mechanism may be potentially + used that does not alter the protocol definition, so interoperability + should not be an issue. + + The suggested mechanism described here has the property that it will + converge on version 1 if both systems implement it, even if one + system is upgraded from version 0 within a Detection Time. It will + interoperate with a system that implements only one version (or is + configured to support only one version). A system should obviously + not perform this function if it is configured to or is only capable + of using a single version. + + A BFD session will enter a "negotiation holddown" if it is configured + for automatic versioning and either has just started up, or the + session has been manually cleared. The session is set to AdminDown + state and version 1. During the holddown period, which lasts for one + Detection Time, the system sends BFD Control packets as usual, but + ignores received packets. After the holddown time is complete, the + state transitions to Down and normal operation resumes. + + When a system is not in holddown, if it doing automatic versioning + and is currently using version 1, if any version 0 packet is received + for the session, it switches immediately to version 0. If it is + currently using version 0 and a version 1 packet is received that + indicates that the neighbor is in state AdminDown, it switches to + version 1. If using version 0 and a version 1 packet is received + indicating a state other than AdminDown, the packet is ignored (per + spec). + + If the version being used is changed, the session goes down as + appropriate 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. + + + + + + + + + +Katz & Ward Standards Track [Page 48] + +RFC 5880 Bidirectional Forwarding Detection June 2010 + + +Appendix C. Acknowledgments + + This document was inspired by (and is intended to replace) the + Protocol Liveness Protocol document, written by Kireeti Kompella. + + Demand mode was inspired by "A Traffic-Based Method of Detecting Dead + Internet Key Exchange (IKE) Peers", by G. Huang, et al. + + The authors would also like to thank Mike Shand, John Scudder, + Stewart Bryant, Pekka Savola, Richard Spencer, and Pasi Eronen for + their substantive input. + + The authors would also like to thank Owen Wheeler for hosting + teleconferences between the authors of this specification and + multiple vendors in order address implementation and clarity issues. + +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 + + + + + + + + + + + + + + + +Katz & Ward Standards Track [Page 49] + |