--- 1/draft-ietf-bfd-base-08.txt 2009-02-06 04:12:03.000000000 +0100 +++ 2/draft-ietf-bfd-base-09.txt 2009-02-06 04:12:03.000000000 +0100 @@ -1,113 +1,124 @@ Network Working Group D. Katz Internet Draft Juniper Networks - D. Ward +Intended status: Proposed Standard D. Ward Cisco Systems -Expires: September, 2008 March, 2008 +Expires: August, 2009 February 5, 2009 Bidirectional Forwarding Detection - draft-ietf-bfd-base-08.txt + draft-ietf-bfd-base-09.txt Status of this Memo - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html +Copyright Notice + + Copyright (c) 2009 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. + 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. - Comments on this draft should be directed to rtg-bfd@ietf.org. 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]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 - 3.1 Addressing and Session Establishment . . . . . . . . . . . 5 - 3.2 Operating Modes . . . . . . . . . . . . . . . . . . . . . 5 + 3.1 Addressing and Session Establishment . . . . . . . . . . . 6 + 3.2 Operating Modes . . . . . . . . . . . . . . . . . . . . . 6 4. BFD Control Packet Format . . . . . . . . . . . . . . . . . . 7 4.1 Generic BFD Control Packet Format . . . . . . . . . . . . 7 - 4.2 Simple Password Authentication Section Format . . . . . 11 + 4.2 Simple Password Authentication Section Format . . . . . 12 4.3 Keyed MD5 and Meticulous Keyed MD5 Authentication - Section Format . . . . . . . . . . . . . . . . . . . . . 12 - 4.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication Section Format . . . . . . . . . . . . . . . . . . . . . 13 - 5. BFD Echo Packet Format . . . . . . . . . . . . . . . . . . . 14 - 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . 15 - 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 - 6.2 BFD State Machine . . . . . . . . . . . . . . . . . . . 16 - 6.3 Demultiplexing and the Discriminator Fields . . . . . . 18 - 6.4 The Echo Function and Asymmetry . . . . . . . . . . . . 19 - 6.5 The Poll Sequence . . . . . . . . . . . . . . . . . . . 19 - 6.6 Demand Mode . . . . . . . . . . . . . . . . . . . . . . 20 - 6.7 Authentication . . . . . . . . . . . . . . . . . . . . . 21 - 6.7.1 Enabling and Disabling Authentication . . . . . . 22 - 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 . . . . . . . . . 34 - 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 . . . . . . . . 41 - 6.8.15 Forwarding Plane Reset . . . . . . . . . . . . . 41 - 6.8.16 Administrative Control . . . . . . . . . . . . . 41 - 6.8.17 Concatenated Paths . . . . . . . . . . . . . . . 42 - 6.8.18 Holding Down Sessions . . . . . . . . . . . . . . 42 - Backward Compatibility (Non-Normative) . . . . . . . . . . . . 43 - Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 44 - Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 - Security Considerations . . . . . . . . . . . . . . . . . . . . 44 - IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 45 - Normative References . . . . . . . . . . . . . . . . . . . . . 45 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46 - Changes from the previous draft . . . . . . . . . . . . . . . . 46 - IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 46 + 4.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication + Section Format . . . . . . . . . . . . . . . . . . . . . 14 + 5. BFD Echo Packet Format . . . . . . . . . . . . . . . . . . . 15 + 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . 16 + 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 16 + 6.2 BFD State Machine . . . . . . . . . . . . . . . . . . . 17 + 6.3 Demultiplexing and the Discriminator Fields . . . . . . 19 + 6.4 The Echo Function and Asymmetry . . . . . . . . . . . . 20 + 6.5 The Poll Sequence . . . . . . . . . . . . . . . . . . . 20 + 6.6 Demand Mode . . . . . . . . . . . . . . . . . . . . . . 21 + 6.7 Authentication . . . . . . . . . . . . . . . . . . . . . 22 + 6.7.1 Enabling and Disabling Authentication . . . . . . 23 + 6.7.2 Simple Password Authentication . . . . . . . . . . 24 + 6.7.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 24 + 6.7.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication 26 + 6.8 Functional Specifics . . . . . . . . . . . . . . . . . . 28 + 6.8.1 State Variables . . . . . . . . . . . . . . . . . 28 + 6.8.2 Timer Negotiation . . . . . . . . . . . . . . . . 32 + 6.8.3 Timer Manipulation . . . . . . . . . . . . . . . . 32 + 6.8.4 Calculating the Detection Time . . . . . . . . . . 34 + 6.8.5 Detecting Failures with the Echo Function . . . . 35 + 6.8.6 Reception of BFD Control Packets . . . . . . . . . 35 + 6.8.7 Transmitting BFD Control Packets . . . . . . . . . 37 + 6.8.8 Reception of BFD Echo Packets . . . . . . . . . . 40 + 6.8.9 Transmission of BFD Echo Packets . . . . . . . . . 41 + 6.8.10 Min Rx Interval Change . . . . . . . . . . . . . 41 + 6.8.11 Min Tx Interval Change . . . . . . . . . . . . . 41 + 6.8.12 Detect Multiplier Change . . . . . . . . . . . . 41 + 6.8.13 Enabling or Disabling the Echo Function . . . . . 42 + 6.8.14 Enabling or Disabling Demand Mode . . . . . . . . 42 + 6.8.15 Forwarding Plane Reset . . . . . . . . . . . . . 42 + 6.8.16 Administrative Control . . . . . . . . . . . . . 42 + 6.8.17 Concatenated Paths . . . . . . . . . . . . . . . 43 + 6.8.18 Holding Down Sessions . . . . . . . . . . . . . . 43 + 7. Operational Considerations . . . . . . . . . . . . . . . . . 44 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 45 + 9. Security Considerations . . . . . . . . . . . . . . . . . . 46 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . 47 + 10.1 Normative References . . . . . . . . . . . . . . . . . 47 + 10.2 Informative References . . . . . . . . . . . . . . . . 47 + Backward Compatibility (Non-Normative) . . . . . . . . . . . . 47 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 49 + Changes from the previous draft . . . . . . . . . . . . . . . . 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 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 @@ -146,26 +157,27 @@ 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 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 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 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.) @@ -199,20 +211,26 @@ 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. + The ability of each system to control the BFD packet transmission + rate in both directions provides a mechanism for congestion control, + particularly when BFD is used across multiple network hops. The + exact algorithm can be independent in each system without affecting + interoperability, and is outside the scope of this specification. + 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 @@ -262,21 +280,22 @@ 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 mode may not be used when the path round trip time is greater than - the desired Detection Time. See section 6.6 for more details. + 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. @@ -296,21 +315,21 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Your Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Desired Min TX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required Min RX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required Min Echo RX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - An optional Authentication Section may be present: + 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 @@ -367,34 +386,34 @@ 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. + 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. + 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 transmitting system in Asynchronous mode. Length Length of the BFD Control packet, in bytes. @@ -407,35 +426,38 @@ 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. - The value zero is reserved. + 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. If + 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. If - this value is zero, the transmitting system does not support the + 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 @@ -479,32 +501,36 @@ 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 MUST be from 1 to 16 bytes in length. 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: 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/Checksum... | + | Auth Key/Digest... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Auth Type The Authentication Type, which in this case is 2 (Keyed MD5) or 3 (Meticulous Keyed MD5). Auth Len @@ -512,50 +538,51 @@ 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. + 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/Checksum + Auth Key/Digest - This field carries the 16 byte MD5 checksum for the packet. When - the checksum is calculated, the shared MD5 key is stored in this - field. (See section 6.7.3 for details.) + 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. (See section 6.7.3 for details.) The shared key MUST be + 16 bytes in length. 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/Checksum... | + | Auth Key/Hash... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Auth Type The Authentication Type, which in this case is 4 (Keyed SHA1) or 5 (Meticulous Keyed SHA1). Auth Len @@ -563,49 +590,53 @@ 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. + 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. - Auth Key/Checksum + Auth Key/Hash - This field carries the 20 byte SHA1 checksum for the packet. When - the checksum is calculated, the shared SHA1 key is stored in this - field. (See section 6.7.4 for details.) + 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. + (See section 6.7.4 for details.) The shared key MUST be 20 bytes + in length. 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 adversely affect interoperability. Remember that all references of the form "bfd.Xx" refer to internal state variables (defined in section 6.8.1), whereas all references to @@ -658,21 +689,21 @@ 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 + A session MAY be kept administratively down by entering the AdminDown state and sending an explanatory diagnostic code in the Diagnostic field. 6.2. BFD State Machine 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 @@ -832,24 +863,23 @@ 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 - Demand bit can only be set if both systems think the session is up. - 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. + 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. When a system in Demand mode wishes to verify bidirectional connectivity, it initiates a Poll Sequence (see section 6.5). If no @@ -859,24 +889,24 @@ system, the Poll Sequence is performed by simply setting the Poll (P) bit in regular periodic BFD Control packets, as required by section 6.6. 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 this mechanism requires that the Detection Time negotiated - is greater than the round trip time between the two systems, or the - Poll mechanism will always fail. Enforcement of this requirement is - outside the scope of this specification. + 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, @@ -900,31 +930,37 @@ 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 + 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 SHA1 authentication. Other forms of authentication are optional. 6.7.1. Enabling and Disabling Authentication @@ -942,24 +978,27 @@ 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 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.) + 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. @@ -988,44 +1027,45 @@ 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] checksum calculated over the outgoing BFD Control packet, but - the Key itself is not carried in the packet. To help avoid replay + [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 checksum 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 - MD5), or strictly greater than the last sequence number received (for + the configured Keys, an MD5 digest 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 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 current authentication key value MUST be placed into the Auth - Key/Checksum field. An MD5 checksum MUST be calculated over the - entire BFD control packet. The resulting checksum MUST be stored - in the Auth Key/Checksum field prior to transmission (replacing - the secret key, which MUST NOT be carried in the packet.) + Key/Digest field. 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 entitled "Security Considerations" below for a discussion. @@ -1038,73 +1078,74 @@ 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. - Replace the contents of the Auth Key/Checksum field with the - authentication key selected by the received Auth Key ID field. If - the MD5 checksum of the entire BFD Control packet is not equal to - the received value of the Auth Key/Checksum field, the received - 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, bfd.RcvAuthSeq MUST be set to the value of the received - Sequence Number field, and the received packet MUST be accepted. + Sequence Number field. + + 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] checksum 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 + 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 checksum 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.) + 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 current authentication key value MUST be placed into the Auth - Key/Checksum field. A SHA1 checksum MUST be calculated over the - entire BFD control packet. The resulting checksum MUST be stored - in the Auth Key/Checksum field prior to transmission (replacing - the secret key, which MUST NOT be carried in the packet.) + Key/Hash field. 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.) 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 entitled "Security Considerations" below for a discussion. @@ -1117,40 +1158,41 @@ 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. - Replace the contents of the Auth Key/Checksum field with the - authentication key selected by the received Auth Key ID field. If - the SHA1 checksum of the entire BFD Control packet is not equal to - the received value of the Auth Key/Checksum field, the received - 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. + 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. @@ -1224,34 +1266,37 @@ 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.) + bfd.DesiredMinTxInterval The minimum interval, in microseconds, between transmitted BFD Control packets that this system would like to use at the - current time. 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. + 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. The setting of this + 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. @@ -1336,21 +1381,21 @@ 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 + 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, @@ -1488,21 +1533,21 @@ 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 + 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 @@ -1527,21 +1572,22 @@ 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.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 @@ -1829,103 +1876,100 @@ 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. + 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 + 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 + 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 resets bfd.RemoteMinRxIvl to a small value and then can transmit at its own rate. -Backward Compatibility (Non-Normative) - - Although Version 0 of this document 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.) +7. Operational Considerations - 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.) + BFD is likely to be deployed as a critical part of network + infrastructure. As such, care should be taken to avoid disruption. -Contributors + Obviously, any mechanism that blocks BFD packets, such as firewalls + or other policy processes, will cause BFD to fail. - Kireeti Kompella and Yakov Rekhter of Juniper Networks were also - significant contributors to this document. + 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. -Acknowledgments +8. IANA Considerations - This document was inspired by (and is intended to replace) the - Protocol Liveness Protocol draft, written by Kireeti Kompella. + This document defines two registries to be administered by IANA. The + first is entitled "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. - Demand mode was inspired by draft-ietf-ipsec-dpd-03.txt, by G. Huang - et al. + 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 Reserved - The authors would also like to thank Mike Shand, John Scudder, - Stewart Bryant, Pekka Savola, and Richard Spencer for their - substantive input. + The second registry is entitled "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. - 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. + Value BFD Diagnostic Code Name + ----- ------------------------ + 0 Reserved + 1 Simple Password + 2 Keyed MD5 + 3 Meticulous Keyed MD5 + 4 Keyed SHA1 + 5 Meticulous Keyed SHA1 + 6-255 Reserved -Security Considerations +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. This ultimately has denial-of-service effects, as links may be declared to be down (or falsely declared to be up.) When BFD is run over network layer protocols, a significant denial- of-service risk is created, as BFD packets may be trivial to spoof. When the session is directly connected across a single link @@ -1954,112 +1998,127 @@ 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 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 rather than MD5 is believed to have stronger security - properties. All comments about MD5 in this section also apply to - SHA1. + Using SHA1 is believed to have stronger security properties than MD5. + All comments about MD5 in this section also apply to SHA1. 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. -IANA Considerations - - This document has no actions for IANA. +10. References -Normative References +10.1. Normative References [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007. - [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. + [SHA1] Eastlake, D., "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, + September 2001. + +10.2. Informative References + + [IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, RFC + 2434, October 1998. + [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. - [SHA1] "Secure Hash Standard", United States of America, National - Institute of Science and Technology, Federal Information - Processing Standard (FIPS) 180-1, April 1993. +Backward Compatibility (Non-Normative) + + Although Version 0 of this document 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.) + +Contributors + + Kireeti Kompella and Yakov Rekhter of Juniper Networks were also + significant contributors to this document. + +Acknowledgments + + This document was inspired by (and is intended to replace) the + Protocol Liveness Protocol draft, written by Kireeti Kompella. + + Demand mode was inspired by draft-ietf-ipsec-dpd-03.txt, by G. Huang + et al. + + The authors would also like to thank Mike Shand, John Scudder, + Stewart Bryant, Pekka Savola, and Richard Spencer 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, California 94089-1206 USA Phone: +1-408-745-2000 Email: dkatz@juniper.net Dave Ward Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA Phone: +1-408-526-4000 Email: dward@cisco.com Changes from the Previous Draft - All changes are purely editorial in nature. - -IPR Notice - - The IETF has been notified of intellectual property rights claimed in - regard to some or all of the specification contained in this - document. For more information consult the online list of claimed - rights. - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Full Copyright Notice - - Copyright (C) The IETF Trust (2008). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. + A note was added about the availability of the timer mechanism for + congestion control. Text was added about the need for out-of-band + negotiation of authentication parameters. The sequence number check + was moved before the digest/hash calculation (this is a backward + compatible change.) An Operational Considerations section was added. + All other changes are purely editorial in nature. - This document expires in September, 2008. + This document expires in August, 2009.