idnits 2.17.1 draft-ietf-bfd-base-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2072. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2043. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2050. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2056. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'KEYWORDS' is mentioned on line 48, but not defined == Unused Reference: 'KEYWORD' is defined on line 1971, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3682 (ref. 'GTSM') (Obsoleted by RFC 5082) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA1' Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Katz 3 Internet Draft Juniper Networks 4 D. Ward 5 Cisco Systems 6 Expires: September, 2007 March, 2007 8 Bidirectional Forwarding Detection 9 draft-ietf-bfd-base-06.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 36 This document describes a protocol intended to detect faults in the 37 bidirectional path between two forwarding engines, including 38 interfaces, data link(s), and to the extent possible the forwarding 39 engines themselves, with potentially very low latency. It operates 40 independently of media, data protocols, and routing protocols. 41 Comments on this draft should be directed to rtg-bfd@ietf.org. 43 Conventions used in this document 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC-2119 [KEYWORDS]. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 54 3.1 Addressing and Session Establishment . . . . . . . . . . . 5 55 3.2 Operating Modes . . . . . . . . . . . . . . . . . . . . . 5 56 4. BFD Control Packet Format . . . . . . . . . . . . . . . . . . 7 57 4.1 Generic BFD Control Packet Format . . . . . . . . . . . . 7 58 4.2 Simple Password Authentication Section Format . . . . . 11 59 4.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 60 Section Format . . . . . . . . . . . . . . . . . . . . . 12 61 4.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication 62 Section Format . . . . . . . . . . . . . . . . . . . . . 13 63 5. BFD Echo Packet Format . . . . . . . . . . . . . . . . . . . 14 64 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . 15 65 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 66 6.2 BFD State Machine . . . . . . . . . . . . . . . . . . . 16 67 6.3 Demultiplexing and the Discriminator Fields . . . . . . 18 68 6.4 The Echo Function and Asymmetry . . . . . . . . . . . . 19 69 6.5 The Poll Sequence . . . . . . . . . . . . . . . . . . . 19 70 6.6 Demand Mode . . . . . . . . . . . . . . . . . . . . . . 20 71 6.7 Authentication . . . . . . . . . . . . . . . . . . . . . 21 72 6.7.1 Enabling and Disabling Authentication . . . . . . 22 73 6.7.2 Simple Password Authentication . . . . . . . . . . 22 74 6.7.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 23 75 6.7.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication 25 76 6.8 Functional Specifics . . . . . . . . . . . . . . . . . . 27 77 6.8.1 State Variables . . . . . . . . . . . . . . . . . 27 78 6.8.2 Timer Negotiation . . . . . . . . . . . . . . . . 30 79 6.8.3 Timer Manipulation . . . . . . . . . . . . . . . . 31 80 6.8.4 Calculating the Detection Time . . . . . . . . . . 32 81 6.8.5 Detecting Failures with the Echo Function . . . . 33 82 6.8.6 Reception of BFD Control Packets . . . . . . . . . 34 83 6.8.7 Transmitting BFD Control Packets . . . . . . . . . 36 84 6.8.8 Reception of BFD Echo Packets . . . . . . . . . . 39 85 6.8.9 Transmission of BFD Echo Packets . . . . . . . . . 39 86 6.8.10 Min Rx Interval Change . . . . . . . . . . . . . 40 87 6.8.11 Min Tx Interval Change . . . . . . . . . . . . . 40 88 6.8.12 Detect Multiplier Change . . . . . . . . . . . . 40 89 6.8.13 Enabling or Disabling the Echo Function . . . . . 40 90 6.8.14 Enabling or Disabling Demand Mode . . . . . . . . 41 91 6.8.15 Forwarding Plane Reset . . . . . . . . . . . . . 41 92 6.8.16 Administrative Control . . . . . . . . . . . . . 41 93 6.8.17 Concatenated Paths . . . . . . . . . . . . . . . 41 94 6.8.18 Holding Down Sessions . . . . . . . . . . . . . . 42 95 Backward Compatibility (Non-Normative) . . . . . . . . . . . . 43 96 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43 97 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 98 Security Considerations . . . . . . . . . . . . . . . . . . . . 44 99 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 45 100 Normative References . . . . . . . . . . . . . . . . . . . . . 45 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46 102 Changes from the previous draft . . . . . . . . . . . . . . . . 46 103 IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 47 105 1. Introduction 107 An increasingly important feature of networking equipment is the 108 rapid detection of communication failures between adjacent systems, 109 in order to more quickly establish alternative paths. Detection can 110 come fairly quickly in certain circumstances when data link hardware 111 comes into play (such as SONET alarms.) However, there are media 112 that do not provide this kind of signaling (such as Ethernet), and 113 some media may not detect certain kinds of failures in the path, for 114 example, failing interfaces or forwarding engine components. 116 Networks use relatively slow "Hello" mechanisms, usually in routing 117 protocols, to detect failures when there is no hardware signaling to 118 help out. The time to detect failures ("detection times") available 119 in the existing protocols are no better than a second, which is far 120 too long for some applications and represents a great deal of lost 121 data at gigabit rates. Furthermore, routing protocol Hellos are of 122 no help when those routing protocols are not in use, and the 123 semantics of detection are subtly different--they detect a failure in 124 the path between the two routing protocol engines. 126 The goal of BFD is to provide low-overhead, short-duration detection 127 of failures in the path between adjacent forwarding engines, 128 including the interfaces, data link(s), and to the extent possible 129 the forwarding engines themselves. 131 An additional goal is to provide a single mechanism that can be used 132 for liveness detection over any media, at any protocol layer, with a 133 wide range of detection times and overhead, to avoid a proliferation 134 of different methods. 136 This document specifies the details of the base protocol. The use of 137 some mechanisms are application dependent and are specified in a 138 separate series of application documents. These issues are so noted. 140 Note that many of the exact mechanisms are implementation dependent 141 and will not affect interoperability, and are thus outside the scope 142 of this specification. Those issues are so noted. 144 2. Design 146 BFD is designed to detect failures in communication with a forwarding 147 plane next hop. It is intended to be implemented in some component 148 of the forwarding engine of a system, in cases where the forwarding 149 and control engines are separated. This not only binds the protocol 150 more to the forwarding plane, but decouples the protocol from the 151 fate of the routing protocol engine, making it useful in concert with 152 various "graceful restart" mechanisms for those protocols. BFD may 153 also be implemented in the control engine, though doing so may 154 preclude the detection of some kinds of failures. 156 BFD operates on top of any data protocol being forwarded between two 157 systems. It is always run in a unicast, point-to-point mode. BFD 158 packets are carried as the payload of whatever encapsulating protocol 159 is appropriate for the medium and network. BFD may be running at 160 multiple layers in a system. The context of the operation of any 161 particular BFD session is bound to its encapsulation. 163 BFD can provide failure detection on any kind of path between 164 systems, including direct physical links, virtual circuits, tunnels, 165 MPLS LSPs, multihop routed paths, and unidirectional links (so long 166 as there is some return path, of course.) Multiple BFD sessions can 167 be established between the same pair of systems when multiple paths 168 between them are present in at least one direction, even if a lesser 169 number of paths are available in the other direction (multiple 170 parallel unidirectional links or MPLS LSPs, for example.) 172 The BFD state machine implements a three-way handshake, both when 173 establishing a BFD session and when tearing it down for any reason, 174 to ensure that both systems are aware of the state change. 176 BFD can be abstracted as a simple service. The service primitives 177 provided by BFD are to create, destroy, and modify a session, given 178 the destination address and other parameters. BFD in return provides 179 a signal to its clients indicating when the BFD session goes up or 180 down. 182 3. Protocol Overview 184 BFD is a simple hello protocol that in many respects is similar to 185 the detection components of well-known routing protocols. A pair of 186 systems transmit BFD packets periodically over each path between the 187 two systems, and if a system stops receiving BFD packets for long 188 enough, some component in that particular bidirectional path to the 189 neighboring system is assumed to have failed. Under some conditions, 190 systems may negotiate to not send periodic BFD packets in order to 191 reduce overhead. 193 A path is only declared to be operational when two-way communication 194 has been established between systems, though this does not preclude 195 the use of unidirectional links. 197 A separate BFD session is created for each communications path and 198 data protocol in use between two systems. 200 Each system estimates how quickly it can send and receive BFD packets 201 in order to come to an agreement with its neighbor about how rapidly 202 detection of failure will take place. These estimates can be 203 modified in real time in order to adapt to unusual situations. This 204 design also allows for fast systems on a shared medium with a slow 205 system to be able to more rapidly detect failures between the fast 206 systems while allowing the slow system to participate to the best of 207 its ability. 209 3.1. Addressing and Session Establishment 211 A BFD session is established based on the needs of the application 212 that will be making use of it. It is up to the application to 213 determine the need for BFD, and the addresses to use--there is no 214 discovery mechanism in BFD. For example, an OSPF [OSPF] 215 implementation may request a BFD session to be established to a 216 neighbor discovered using the OSPF Hello protocol. 218 3.2. Operating Modes 220 BFD has two operating modes which may be selected, as well as an 221 additional function that can be used in combination with the two 222 modes. 224 The primary mode is known as Asynchronous mode. In this mode, the 225 systems periodically send BFD Control packets to one another, and if 226 a number of those packets in a row are not received by the other 227 system, the session is declared to be down. 229 The second mode is known as Demand mode. In this mode, it is assumed 230 that a system has an independent way of verifying that it has 231 connectivity to the other system. Once a BFD session is established, 232 such a system may ask the other system to stop sending BFD Control 233 packets, except when the system feels the need to verify connectivity 234 explicitly, in which case a short sequence of BFD Control packets is 235 exchanged, and then the far system quiesces. Demand mode may operate 236 independently in each direction, or simultaneously. 238 An adjunct to both modes is the Echo function. When the Echo 239 function is active, a stream of BFD Echo packets is transmitted in 240 such a way as to have the other system loop them back through its 241 forwarding path. If a number of packets of the echoed data stream 242 are not received, the session is declared to be down. The Echo 243 function may be used with either Asynchronous or Demand modes. Since 244 the Echo function is handling the task of detection, the rate of 245 periodic transmission of Control packets may be reduced (in the case 246 of Asynchronous mode) or eliminated completely (in the case of Demand 247 mode.) 249 Pure asynchronous mode is advantageous in that it requires half as 250 many packets to achieve a particular detection time as does the Echo 251 function. It is also used when the Echo function cannot be supported 252 for some reason. 254 The Echo function has the advantage of truly testing only the 255 forwarding path on the remote system. This may reduce round-trip 256 jitter and thus allow more aggressive detection times, as well as 257 potentially detecting some classes of failure that might not 258 otherwise be detected. 260 The Echo function may be enabled individually in each direction. It 261 is enabled in a particular direction only when the system that loops 262 the Echo packets back signals that it will allow it, and when the 263 system that sends the Echo packets decides it wishes to. 265 Demand mode is useful in situations where the overhead of a periodic 266 protocol might prove onerous, such as a system with a very large 267 number of BFD sessions. It is also useful when the Echo function is 268 being used symmetrically. Demand mode has the disadvantage that 269 detection times are essentially driven by the heuristics of the 270 system implementation and are not known to the BFD protocol. Demand 271 mode may not be used when the path round trip time is greater than 272 the desired detection time. See section 6.6 for more details. 274 4. BFD Control Packet Format 276 4.1. Generic BFD Control Packet Format 278 BFD Control packets are sent in an encapsulation appropriate to the 279 environment. The specific encapsulation is outside of the scope of 280 this specification. See the appropriate application document for 281 encapsulation details. 283 The BFD Control packet has a Mandatory Section and an optional 284 Authentication Section. The format of the Authentication Section, if 285 present, is dependent on the type of authentication in use. 287 The Mandatory Section of a BFD Control packet has the following 288 format: 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 |Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | My Discriminator | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Your Discriminator | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Desired Min TX Interval | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Required Min RX Interval | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Required Min Echo RX Interval | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 An optional Authentication Section may be present: 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Auth Type | Auth Len | Authentication Data... | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Version (Vers) 316 The version number of the protocol. This document defines 317 protocol version 1. 319 Diagnostic (Diag) 321 A diagnostic code specifying the local system's reason for the 322 last session state change to states Down or AdminDown. Values 323 are: 325 0 -- No Diagnostic 326 1 -- Control Detection Time Expired 327 2 -- Echo Function Failed 328 3 -- Neighbor Signaled Session Down 329 4 -- Forwarding Plane Reset 330 5 -- Path Down 331 6 -- Concatenated Path Down 332 7 -- Administratively Down 333 8 -- Reverse Concatenated Path Down 334 9-31 -- Reserved for future use 336 This field allows remote systems to determine the reason that the 337 previous session failed, for example. 339 State (Sta) 341 The current BFD session state as seen by the transmitting system. 342 Values are: 344 0 -- AdminDown 345 1 -- Down 346 2 -- Init 347 3 -- Up 349 Poll (P) 351 If set, the transmitting system is requesting verification of 352 connectivity, or of a parameter change, and is expecting a packet 353 with the Final (F) bit in reply. If clear, the transmitting 354 system is not requesting verification. 356 Final (F) 358 If set, the transmitting system is responding to a received BFD 359 Control packet that had the Poll (P) bit set. If clear, the 360 transmitting system is not responding to a Poll. 362 Control Plane Independent (C) 364 If set, the transmitting system's BFD implementation does not 365 share fate with its control plane (in other words, BFD is 366 implemented in the forwarding plane and can continue to function 367 through disruptions in the control plane.) If clear, the 368 transmitting system's BFD implementation shares fate with its 369 control plane. 371 The use of this bit is application dependent and is outside the 372 scope of this specification. See specific application 373 specifications for details. 375 Authentication Present (A) 377 If set, the Authentication Section is present and the session is 378 to be authenticated. 380 Demand (D) 382 If set, Demand mode is active in the transmitting system (the 383 system wishes to operate in Demand mode, knows that the session is 384 up in both directions, and is directing the remote system to cease 385 the periodic transmission of BFD Control packets.) If clear, 386 Demand mode is not active in the transmitting system. 388 Multipoint (M) 390 This bit is reserved for future point-to-multipoint extensions to 391 BFD. It must be zero on both transmit and receipt. 393 Detect Mult 395 Detection time multiplier. The negotiated transmit interval, 396 multiplied by this value, provides the detection time for the 397 transmitting system in Asynchronous mode. 399 Length 401 Length of the BFD Control packet, in bytes. 403 My Discriminator 405 A unique, nonzero discriminator value generated by the 406 transmitting system, used to demultiplex multiple BFD sessions 407 between the same pair of systems. 409 Your Discriminator 411 The discriminator received from the corresponding remote system. 412 This field reflects back the received value of My Discriminator, 413 or is zero if that value is unknown. 415 Desired Min TX Interval 417 This is the minimum interval, in microseconds, that the local 418 system would like to use when transmitting BFD Control packets. 419 The value zero is reserved. 421 Required Min RX Interval 423 This is the minimum interval, in microseconds, between received 424 BFD Control packets that this system is capable of supporting. If 425 this value is zero, the transmitting system does not want the 426 remote system to send any periodic BFD Control packets. 428 Required Min Echo RX Interval 430 This is the minimum interval, in microseconds, between received 431 BFD Echo packets that this system is capable of supporting. If 432 this value is zero, the transmitting system does not support the 433 receipt of BFD Echo packets. 435 Auth Type 437 The authentication type in use, if the Authentication Present (A) 438 bit is set. 440 0 - Reserved 441 1 - Simple Password 442 2 - Keyed MD5 443 3 - Meticulous Keyed MD5 444 4 - Keyed SHA1 445 5 - Meticulous Keyed SHA1 446 6-255 - Reserved for future use 448 Auth Len 450 The length, in bytes, of the authentication section, including the 451 Auth Type and Auth Len fields. 453 4.2. Simple Password Authentication Section Format 455 If the Authentication Present (A) bit is set in the header, and the 456 Authentication Type field contains 1 (Simple Password), the 457 Authentication Section has the following format: 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Auth Type | Auth Len | Auth Key ID | Password... | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | ... | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 Auth Type 469 The Authentication Type, which in this case is 1 (Simple 470 Password.) 472 Auth Len 474 The length of the Authentication Section, in bytes. For Simple 475 Password authentication, the length is equal to the password 476 length plus three. 478 Auth Key ID 480 The authentication key ID in use for this packet. This allows 481 multiple keys to be active simultaneously. 483 Password 485 The simple password in use on this session. The password MUST be 486 from 1 to 16 bytes in length. 488 4.3. Keyed MD5 and Meticulous Keyed MD5 Authentication Section Format 490 If the Authentication Present (A) bit is set in the header, and the 491 Authentication Type field contains 2 (Keyed MD5) or 3 (Meticulous 492 Keyed MD5), the Authentication Section has the following format: 494 0 1 2 3 495 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 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Auth Type | Auth Len | Auth Key ID | Reserved | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Sequence Number | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Auth Key/Checksum... | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | ... | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Auth Type 508 The Authentication Type, which in this case is 2 (Keyed MD5) or 3 509 (Meticulous Keyed MD5). 511 Auth Len 513 The length of the Authentication Section, in bytes. For Keyed MD5 514 and Meticulous Keyed MD5 authentication, the length is 24. 516 Auth Key ID 518 The authentication key ID in use for this packet. This allows 519 multiple keys to be active simultaneously. 521 Reserved 523 This byte must be set to zero on transmit, and ignored on receipt. 525 Sequence Number 527 The Sequence Number for this packet. For Keyed MD5 528 Authentication, this value is incremented occasionally. For 529 Meticulous Keyed MD5 Authentication, this value is incremented for 530 each successive packet transmitted for a session. This provides 531 protection against replay attacks. 533 Auth Key/Checksum 535 This field carries the 16 byte MD5 checksum for the packet. When 536 the checksum is calculated, the shared MD5 key is stored in this 537 field. (See section 6.7.3 for details.) 539 4.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication Section Format 541 If the Authentication Present (A) bit is set in the header, and the 542 Authentication Type field contains 4 (Keyed SHA1) or 5 (Meticulous 543 Keyed SHA1), the Authentication Section has the following format: 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Auth Type | Auth Len | Auth Key ID | Reserved | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Sequence Number | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Auth Key/Checksum... | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | ... | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 Auth Type 559 The Authentication Type, which in this case is 4 (Keyed SHA1) or 5 560 (Meticulous Keyed SHA1). 562 Auth Len 564 The length of the Authentication Section, in bytes. For Keyed 565 SHA1 and Meticulous Keyed SHA1 authentication, the length is 28. 567 Auth Key ID 569 The authentication key ID in use for this packet. This allows 570 multiple keys to be active simultaneously. 572 Reserved 574 This byte must be set to zero on transmit, and ignored on receipt. 576 Sequence Number 578 The Sequence Number for this packet. For Keyed SHA1 579 Authentication, this value is incremented occasionally. For 580 Meticulous Keyed SHA1 Authentication, this value is incremented 581 for each successive packet transmitted for a session. This 582 provides protection against replay attacks. 584 Auth Key/Checksum 586 This field carries the 20 byte SHA1 checksum for the packet. When 587 the checksum is calculated, the shared SHA1 key is stored in this 588 field. (See section 6.7.4 for details.) 590 5. BFD Echo Packet Format 592 BFD Echo packets are sent in an encapsulation appropriate to the 593 environment. See the appropriate application documents for the 594 specifics of particular environments. 596 The payload of a BFD Echo packet is a local matter, since only the 597 sending system ever processes the content. The only requirement is 598 that sufficient information is included to demultiplex the received 599 packet to the correct BFD session after it is looped back to the 600 sender. The contents are otherwise outside the scope of this 601 specification. 603 6. Elements of Procedure 605 This section discusses the normative requirements of the protocol in 606 order to achieve interoperability. It is important for implementors 607 to enforce only the requirements specified in this section, as 608 misguided pedantry has been proven by experience to adversely affect 609 interoperability. 611 Remember that all references of the form "bfd.Xx" refer to internal 612 state variables (defined in section 6.8.1), whereas all references to 613 "the Xxx field" refer to fields in the protocol packets themselves 614 (defined in section 4). 616 6.1. Overview 618 A system may take either an Active role or a Passive role in session 619 initialization. A system taking the Active role MUST send BFD 620 Control packets for a particular session, regardless of whether it 621 has received any BFD packets for that session. A system taking the 622 Passive role MUST NOT begin sending BFD packets for a particular 623 session until it has received a BFD packet for that session, and thus 624 has learned the remote system's discriminator value. At least one 625 system MUST take the Active role (possibly both.) The role that a 626 system takes is specific to the application of BFD, and is outside 627 the scope of this specification. 629 A session begins with the periodic, slow transmission of BFD Control 630 packets. When bidirectional communication is achieved, the BFD 631 session comes Up. 633 Once the BFD session is Up, a system can choose to start the Echo 634 function if it desires to and the other system signals that it will 635 allow it. The rate of transmission of Control packets is typically 636 kept low when the Echo function is active. 638 If the Echo function is not active, the transmission rate of Control 639 packets may be increased to a level necessary to achieve the 640 detection time requirements for the session. 642 Once the session is up, a system may signal that it has entered 643 Demand mode, and the transmission of BFD Control packets by the 644 remote system ceases. Other means of implying connectivity are used 645 to keep the session alive. If either system wishes to verify 646 bidirectional connectivity, it can initiate a short exchange of BFD 647 Control packets (a "Poll Sequence"; see section 6.5) to do so. 649 If Demand mode is not active, and no Control packets are received in 650 the calculated detection time (see section 6.8.4), the session is 651 declared Down. This is signaled to the remote end via the State 652 (Sta) field in outgoing packets. 654 If sufficient Echo packets are lost, the session is declared down in 655 the same manner. See section 6.8.5. 657 If Demand mode is active and no appropriate Control packets are 658 received in response to a Poll Sequence, the session is declared down 659 in the same manner. See section 6.6. 661 If the session goes down, the transmission of Echo packets (if any) 662 ceases, and the transmission of Control packets goes back to the slow 663 rate. 665 Once a session has been declared down, it cannot come back up until 666 the remote end first signals that it is down (by leaving the Up 667 state), thus implementing a three-way handshake. 669 A session may be kept administratively down by entering the AdminDown 670 state and sending an explanatory diagnostic code in the Diagnostic 671 field. 673 6.2. BFD State Machine 675 The BFD state machine is quite straightforward. There are three 676 states through which a session normally proceeds, two for 677 establishing a session (Init and Up) and one for tearing down a 678 session (Down.) This allows a three-way handshake for both session 679 establishment and session teardown (assuring that both systems are 680 aware of all session state changes.) A fourth state (AdminDown) 681 exists so that a session can be administratively put down 682 indefinitely. 684 Each system communicates its session state in the State (Sta) field 685 in the BFD Control packet, and that received state in combination 686 with the local session state drives the state machine. 688 Down state means that the session is down (or has just been created.) 689 A session remains in Down state until the remote system indicates 690 that it agrees that the session is down by sending a BFD Control 691 packet with the State field set to anything other than Up. If that 692 packet signals Down state, the session advances to Init state; if 693 that packet signals Init state, the session advances to Up state. 694 Semantically, Down state indicates that the forwarding path is 695 unavailable, and that appropriate actions should be taken by the 696 applications monitoring the state of the BFD session. A system MAY 697 hold a session in Down state indefinitely (by simply refusing to 698 advance the session state.) This may be done for operational or 699 adminstrative reasons, among others. 701 Init state means that the remote system is communicating, and the 702 local system desires to bring the session up, but the remote system 703 does not yet realize it. A session will remain in Init state until 704 either a BFD Control Packet is received that is signaling Init or Up 705 state (in which case the session advances to Up state) or until the 706 detection time expires, meaning that communication with the remote 707 system has been lost (in which case the session advances to Down 708 state.) 710 Up state means that the BFD session has successfully been 711 established, and implies that connectivity between the systems is 712 working. The session will remain in the Up state until either 713 connectivity fails, or the session is taken down administratively. 714 If either the remote system signals Down state, or the detection time 715 expires, the session advances to Down state. 717 AdminDown state means that the session is being held administratively 718 down. This causes the remote system to enter Down state, and remain 719 there until the local system exits AdminDown state. AdminDown state 720 has no semantic implications for the availability of the forwarding 721 path. 723 The following diagram provides an overview of the state machine. 724 Transitions involving AdminDown state are deleted for clarity (but 725 are fully specified in section 6.8.6.) The notation on each arc 726 represents the state of the remote system (as received in the State 727 field in the BFD Control packet) or indicates the expiration of the 728 Detection Timer. 730 +--+ 731 | | UP, ADMIN DOWN, TIMER 732 | V 733 DOWN +------+ INIT 734 +------------| |------------+ 735 | | DOWN | | 736 | +-------->| |<--------+ | 737 | | +------+ | | 738 | | | | 739 | | ADMIN DOWN,| | 740 | |ADMIN DOWN, DOWN,| | 741 | |TIMER TIMER| | 742 V | | V 743 +------+ +------+ 744 +----| | | |----+ 745 DOWN| | INIT |--------------------->| UP | |INIT, UP 746 +--->| | INIT, UP | |<---+ 747 +------+ +------+ 749 6.3. Demultiplexing and the Discriminator Fields 751 Since multiple BFD sessions may be running between two systems, there 752 needs to be a mechanism for demultiplexing received BFD packets to 753 the proper session. 755 Each system MUST choose an opaque discriminator value that identifies 756 each session, and which MUST be unique among all BFD sessions on the 757 system. The local discriminator is sent in the My Discriminator 758 field in the BFD Control packet, and is echoed back in the Your 759 Discriminator field of packets sent from the remote end. 761 Once the remote end echoes back the local discriminator, all further 762 received packets are demultiplexed based on the Your Discriminator 763 field only (which means that, among other things, the source address 764 field can change or the interface over which the packets are received 765 can change, but the packets will still be associated with the proper 766 session.) 768 The method of demultiplexing the initial packets (in which Your 769 Discriminator is zero) is application-dependent, and is thus outside 770 the scope of this specification. 772 Note that it is permissible for a system to change its discriminator 773 during a session without affecting the session state, since only that 774 system uses its discriminator for demultiplexing purposes (by having 775 the other system reflect it back.) The implications on an 776 implementation for changing the discriminator value is outside the 777 scope of this specification. 779 6.4. The Echo Function and Asymmetry 781 The Echo function can be run independently in each direction between 782 a pair of systems. For whatever reason, a system may advertise that 783 it is willing to receive (and loop back) Echo packets, but may not 784 wish to ever send any. The fact that a system is sending Echo 785 packets is not directly signaled to the system looping them back. 787 When a system is using the Echo function, it is advantageous to 788 choose a sedate reception rate for Control packets, since liveness 789 detection is being handled by the Echo packets. This can be 790 controlled by manipulating the Required Min RX Interval field (see 791 section 6.8.3.) 793 If the Echo function is only being run in one direction, the system 794 not running the Echo function will more likely wish to receive fairly 795 rapid Control packets in order to achieve its desired detection time. 796 Since BFD allows independent transmission rates in each direction, 797 this is easily accomplished. 799 A system SHOULD otherwise advertise the lowest value of Required Min 800 RX Interval and Required Min Echo RX Interval that it can under the 801 circumstances, to give the other system more freedom in choosing its 802 transmission rate. Note that a system is committing to be able to 803 receive both streams of packets at the rate it advertises, so this 804 should be taken into account when choosing the values to advertise. 806 6.5. The Poll Sequence 808 A Poll Sequence is an exchange of BFD Control packets that is used in 809 some circumstances to ensure that the remote system is aware of 810 parameter changes. It is also used in Demand mode (see section 6.6) 811 to validate bidirectional connectivity. 813 A Poll Sequence consists of a system sending periodic BFD Control 814 packets with the Poll (P) bit set. When the other system receives a 815 Poll, it immediately transmits a BFD Control packet with the Final 816 (F) bit set, independent of any periodic BFD Control packets it may 817 be sending (see section 6.8.7). When the system sending the Poll 818 sequence receives a packet with Final, the Poll Sequence is 819 terminated, and any subsequent BFD Control packets are sent with the 820 Poll bit cleared. A BFD Control packet MUST NOT have both the Poll 821 (P) and Final (F) bits set. 823 If periodic BFD Control packets are already being sent (the remote 824 system is not in Demand mode), the Poll Sequence MUST be performed by 825 setting the Poll (P) bit on those scheduled periodic transmissions; 826 additional packets MUST NOT be sent. 828 After a Poll Sequence is terminated, the system requesting the Poll 829 Sequence will cease the periodic transmission of BFD Control packets 830 if the remote end is in Demand mode; otherwise it will return to the 831 periodic transmission of BFD Control packets with the Poll (P) bit 832 clear. 834 Typically, the entire sequence consists of a single packet in each 835 direction, though packet losses or relatively long packet latencies 836 may result in multiple Poll packets to be sent before the sequence 837 terminates. 839 6.6. Demand Mode 841 Demand mode is requested independently in each direction by virtue of 842 a system setting the Demand (D) bit in its BFD Control packets. The 843 Demand bit can only be set if both systems think the session is up. 844 The system receiving the Demand bit ceases the periodic transmission 845 of BFD Control packets. If both systems are operating in Demand 846 mode, no periodic BFD Control packets will flow in either direction. 848 Demand mode requires that some other mechanism is used to imply 849 continuing connectivity between the two systems. The mechanism used 850 does not have to be the same in both directions, and is outside of 851 the scope of this specification. One possible mechanism is the 852 receipt of traffic from the remote system; another is the use of the 853 Echo function. 855 When a system in Demand mode wishes to verify bidirectional 856 connectivity, it initiates a Poll Sequence (see section 6.5). If no 857 response is received to a Poll, the Poll is repeated until the 858 detection time expires, at which point the session is declared to be 859 down. Note that if Demand mode is operating only on the remote 860 system, the Poll Sequence is performed on the local system by simply 861 setting the Poll (P) bit in regular periodic BFD Control packets. 863 The detection time in Demand mode is calculated differently than in 864 Asynchronous mode; it is based on the transmit rate of the local 865 system, rather than the transmit rate of the remote system. This 866 ensures that the Poll Sequence mechanism works properly. See section 867 6.8.4 for more details. 869 Note that this mechanism requires that the detection time negotiated 870 is greater than the round trip time between the two systems, or the 871 Poll mechanism will always fail. Enforcement of this requirement is 872 outside the scope of this specification. 874 Demand mode MAY be enabled or disabled at any time, independently in 875 each direction, by setting or clearing the Demand (D) bit in the BFD 876 Control packet, without affecting the BFD session state. Note that 877 the Demand bit MUST NOT be set unless both systems perceive the 878 session to be Up (the local system thinks the session is Up, and the 879 remote system last reported Up state in the State (Sta) field of the 880 BFD Control packet.) 882 When the transmitted value of the Demand (D) bit is to be changed, 883 the transmitting system MUST initiate a Poll Sequence in conjunction 884 with changing the bit in order to ensure that both systems are aware 885 of the change. 887 If Demand mode is active on either or both systems, a Poll Sequence 888 MUST be initiated whenever the contents of the next BFD Control 889 packet to be sent would be different than the contents of the 890 previous packet, with the exception of the Poll (P) and Final (F) 891 bits. This ensures that parameter changes are transmitted to the 892 remote system and that the remote system acknowledges these changes. 894 Because the underlying detection mechanism is unspecified, and may 895 differ between the two systems, the overall detection time 896 characteristics of the path will not be fully known to either system. 897 The total detection time for a particular system is the sum of the 898 time prior to the initiation of the Poll Sequence, plus the 899 calculated detection time. 901 Note that if Demand mode is enabled in only one direction, continuous 902 bidirectional connectivity verification is lost (only connectivity in 903 the direction from the system in Demand mode to the other system will 904 be verified.) Resolving the issue of one system requesting Demand 905 mode while the other requires continuous bidirectional connectivity 906 verification is outside the scope of this specification. 908 6.7. Authentication 910 An optional Authentication Section may be present in the BFD Control 911 packet. In its generic form, the purpose of the Authentication 912 Section is to carry all necessary information, based on the 913 authentication type in use, to allow the receiving system to 914 determine the validity of the received packet. The exact mechanism 915 depends on the authentication type in use, but in general the 916 transmitting system will put information in the Authentication 917 Section that vouches for the packet's validity, and the receiving 918 system will examine the Authentication Section and either accept the 919 packet for further processing, or discard it. 921 Note that in the subsections below, to "accept" a packet means only 922 that the packet has passed authentication; it may in fact be 923 discarded for other reasons as described in the general packet 924 reception rules described in section 6.8.6. 926 Implementations supporting authentication MUST support SHA1 927 authentication. Other forms of authentication are optional. 929 6.7.1. Enabling and Disabling Authentication 931 It may be desirable to enable or disable authentication on a session 932 without disturbing the session state. The exact mechanism for doing 933 so is outside the scope of this specification. However, it is useful 934 to point out some issues in supporting this mechanism. 936 In a simple implementation, a BFD session will fail when 937 authentication is either turned on or turned off, because the packet 938 acceptance rules essentially require the local and remote machines to 939 do so in a more or less synchronized fashion (within the detection 940 time)--a packet with authentication will only be accepted if 941 authentication is "in use" (and likewise packets without 942 authentication. 944 One possible approach is to build an implementation such that 945 authentication is configured, but not considered "in use" until the 946 first packet containing a matching authentication section is received 947 (providing the necessary synchronization.) Likewise, authentication 948 could be configured off, but still considered "in use" until the 949 receipt of the first packet without the authentication section. 951 In order to avoid security risks, implementations using this method 952 should only allow the authentication state to be changed once without 953 some form of intervention (so that authentication cannot be turned on 954 and off repeatedly simply based on the receipt of BFD Control packets 955 from remote systems.) 957 6.7.2. Simple Password Authentication 959 The most straightforward (and weakest) form of authentication is 960 Simple Password Authentication. In this method of authentication, 961 one or more Passwords (with corresponding Key IDs) are configured in 962 each system and one of these Password/ID pairs is carried in each BFD 963 Control packet. The receiving system accepts the packet if the 964 Password and Key ID matches one of the Password/ID pairs configured 965 in that system. 967 Transmission Using Simple Password Authentication 969 The currently selected password and Key ID for the session MUST be 970 stored in the Authentication Section of each outgoing BFD Control 971 packet. The Auth Type field MUST be set to 1 (Simple Password.) 972 The Auth Len field MUST be set to the proper length (4 to 19 973 bytes.) 975 Reception Using Simple Password Authentication 977 If the received BFD Control packet does not contain an 978 Authentication Section, or the Auth Type is not 1 (Simple 979 Password), then the received packet MUST be discarded. 981 If the Auth Key ID field does not match the ID of a configured 982 password, the received packet MUST be discarded. 984 If the Auth Len field is not equal to the length of the password 985 selected by the Key ID, plus three, the packet MUST be discarded. 987 If the Password field does not match the password selected by the 988 Key ID, the packet MUST be discarded. 990 Otherwise, the packet MUST be accepted. 992 6.7.3. Keyed MD5 and Meticulous Keyed MD5 Authentication 994 The Keyed MD5 and Meticulous Keyed MD5 Authentication mechanisms are 995 very similar to those used in other protocols. In these methods of 996 authentication, one or more secret keys (with corresponding Key IDs) 997 are configured in each system. One of the Keys is included in an MD5 998 [MD5] checksum calculated over the outgoing BFD Control packet, but 999 the Key itself is not carried in the packet. To help avoid replay 1000 attacks, a sequence number is also carried in each packet. For Keyed 1001 MD5, the sequence number is occasionally incremented. For Meticulous 1002 Keyed MD5, the sequence number is incremented on every packet. 1004 The receiving system accepts the packet if the Key ID matches one of 1005 the configured Keys, an MD5 checksum including the selected key 1006 matches that carried in the packet, and if the sequence number is 1007 greater than or equal to the last sequence number received (for Keyed 1008 MD5), or strictly greater than the last sequence number received (for 1009 Meticulous Keyed MD5.) 1010 Transmission Using Keyed MD5 and Meticulous Keyed MD5 Authentication 1012 The Auth Type field MUST be set to 2 (Keyed MD5) or 3 (Meticulous 1013 Keyed MD5.) The Auth Len field MUST be set to 24. The Auth Key 1014 ID field MUST be set to the ID of the current authentication key. 1015 The Sequence Number field MUST be set to bfd.XmitAuthSeq. 1017 The current authentication key value MUST be placed into the Auth 1018 Key/Checksum field. An MD5 checksum MUST be calculated over the 1019 entire BFD control packet. The resulting checksum MUST be stored 1020 in the Auth Key/Checksum field prior to transmission (replacing 1021 the secret key, which MUST NOT be carried in the packet.) 1023 For Keyed MD5, bfd.XmitAuthSeq MAY be incremented in a circular 1024 fashion (when treated as an unsigned 32 bit value.) 1025 bfd.XmitAuthSeq SHOULD be incremented when the session state 1026 changes, or when the transmitted BFD Control packet carries 1027 different contents than the previously transmitted packet. The 1028 decision as to when to increment bfd.XmitAuthSeq is outside the 1029 scope of this specification. See the section entitled "Security 1030 Considerations" below for a discussion. 1032 For Meticulous Keyed MD5, bfd.XmitAuthSeq MUST be incremented in a 1033 circular fashion (when treated as an unsigned 32 bit value.) 1035 Receipt Using Keyed MD5 and Meticulous Keyed MD5 Authentication 1037 If the received BFD Control packet does not contain an 1038 Authentication Section, or the Auth Type is not correct (2 for 1039 Keyed MD5, or 3 for Meticulous Keyed MD5), then the received 1040 packet MUST be discarded. 1042 If the Auth Key ID field does not match the ID of a configured 1043 authentication key, the received packet MUST be discarded. 1045 If the Auth Len field is not equal to 24, the packet MUST be 1046 discarded. 1048 Replace the contents of the Auth Key/Checksum field with the 1049 authentication key selected by the received Auth Key ID field. If 1050 the MD5 checksum of the entire BFD Control packet is not equal to 1051 the received value of the Auth Key/Checksum field, the received 1052 packet MUST be discarded. 1054 If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For 1055 Keyed MD5, if the Sequence Number lies outside of the range of 1056 bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when 1057 treated as an unsigned 32 bit circular number space), the received 1058 packet MUST be discarded. For Meticulous Keyed MD5, if the 1059 Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to 1060 bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an 1061 unsigned 32 bit circular number space, the received packet MUST be 1062 discarded. 1064 Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1065 1, bfd.RcvAuthSeq MUST be set to the value of the received 1066 Sequence Number field, and the received packet MUST be accepted. 1068 6.7.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication 1070 The Keyed SHA1 and Meticulous Keyed SHA1 Authentication mechanisms 1071 are very similar to those used in other protocols. In these methods 1072 of authentication, one or more secret keys (with corresponding Key 1073 IDs) are configured in each system. One of the Keys is included in a 1074 SHA1 [SHA1] checksum calculated over the outgoing BFD Control packet, 1075 but the Key itself is not carried in the packet. To help avoid 1076 replay attacks, a sequence number is also carried in each packet. 1077 For Keyed SHA1, the sequence number is occasionally incremented. For 1078 Meticulous Keyed SHA1, the sequence number is incremented on every 1079 packet. 1081 The receiving system accepts the packet if the Key ID matches one of 1082 the configured Keys, a SHA1 checksum including the selected key 1083 matches that carried in the packet, and if the sequence number is 1084 greater than or equal to the last sequence number received (for Keyed 1085 SHA1), or strictly greater than the last sequence number received 1086 (for Meticulous Keyed SHA1.) 1088 Transmission Using Keyed SHA1 and Meticulous Keyed SHA1 1089 Authentication 1091 The Auth Type field MUST be set to 4 (Keyed SHA1) or 5 (Meticulous 1092 Keyed SHA1.) The Auth Len field MUST be set to 28. The Auth Key 1093 ID field MUST be set to the ID of the current authentication key. 1094 The Sequence Number field MUST be set to bfd.XmitAuthSeq. 1096 The current authentication key value MUST be placed into the Auth 1097 Key/Checksum field. A SHA1 checksum MUST be calculated over the 1098 entire BFD control packet. The resulting checksum MUST be stored 1099 in the Auth Key/Checksum field prior to transmission (replacing 1100 the secret key, which MUST NOT be carried in the packet.) 1102 For Keyed SHA1, bfd.XmitAuthSeq MAY be incremented in a circular 1103 fashion (when treated as an unsigned 32 bit value.) 1104 bfd.XmitAuthSeq SHOULD be incremented when the session state 1105 changes, or when the transmitted BFD Control packet carries 1106 different contents than the previously transmitted packet. The 1107 decision as to when to increment bfd.XmitAuthSeq is outside the 1108 scope of this specification. See the section entitled "Security 1109 Considerations" below for a discussion. 1111 For Meticulous Keyed SHA1, bfd.XmitAuthSeq MUST be incremented in 1112 a circular fashion (when treated as an unsigned 32 bit value.) 1114 Receipt Using Keyed SHA1 and Meticulous Keyed SHA1 Authentication 1116 If the received BFD Control packet does not contain an 1117 Authentication Section, or the Auth Type is not correct (4 for 1118 Keyed SHA1, or 5 for Meticulous Keyed SHA1), then the received 1119 packet MUST be discarded. 1121 If the Auth Key ID field does not match the ID of a configured 1122 authentication key, the received packet MUST be discarded. 1124 If the Auth Len field is not equal to 28, the packet MUST be 1125 discarded. 1127 Replace the contents of the Auth Key/Checksum field with the 1128 authentication key selected by the received Auth Key ID field. If 1129 the SHA1 checksum of the entire BFD Control packet is not equal to 1130 the received value of the Auth Key/Checksum field, the received 1131 packet MUST be discarded. 1133 If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For 1134 Keyed SHA1, if the Sequence Number lies outside of the range of 1135 bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when 1136 treated as an unsigned 32 bit circular number space), the received 1137 packet MUST be discarded. For Meticulous Keyed SHA1, if the 1138 Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to 1139 bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an 1140 unsigned 32 bit circular number space, the received packet MUST be 1141 discarded. 1143 Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1144 1, bfd.RcvAuthSeq MUST be set to the value of the received 1145 Sequence Number field, and the received packet MUST be accepted. 1147 6.8. Functional Specifics 1149 The following section of this specification is normative. The means 1150 by which this specification is achieved is outside the scope of this 1151 specification. 1153 When a system is said to have "the Echo function active," it means 1154 that the system is sending BFD Echo packets, implying that the 1155 session is Up and the other system has signaled its willingness to 1156 loop back Echo packets. 1158 When the local system is said to have "Demand mode active," it means 1159 that bfd.DemandMode is 1 in the local system (see section 6.8.1), the 1160 session is Up, and the remote system is signaling that the session is 1161 in state Up. 1163 When the remote system is said to have "Demand mode active," it means 1164 that bfd.RemoteDemandMode is 1 (the remote system set the Demand (D) 1165 bit in the last received BFD Control packet), the session is Up, and 1166 the remote system is signaling that the session is in state Up. 1168 6.8.1. State Variables 1170 A minimum amount of information about a session needs to be tracked 1171 in order to achieve the elements of procedure described here. The 1172 following is a set of state variables that are helpful in describing 1173 the mechanisms of BFD. Any means of tracking this state may be used 1174 so long as the protocol behaves as described. 1176 When the text refers to initializing a state variable, this takes 1177 place only at the time that the session (and the corresponding state 1178 variables) is created. The state variables are subsequently 1179 manipulated by the state machine and are never reinitialized, even if 1180 the session fails and is reestablished. 1182 Once session state is created, and at least one BFD Control packet is 1183 received from the remote end, it MUST be preserved for at least one 1184 Detection Time (see section 6.8.4) subsequent to the receipt of the 1185 last BFD Control packet, regardless of the session state. This 1186 preserves timing parameters in case the session flaps. A system MAY 1187 preserve session state longer than this. The preservation or 1188 destruction of session state when no BFD Control packets for this 1189 session have been received from the remote system is outside the 1190 scope of this specification. 1192 All state variables in this specification are of the form "bfd.Xx" 1193 and should not be confused with fields carried in the protocol 1194 packets, which are always spelled out to match the names in section 1195 4. 1197 bfd.SessionState 1199 The perceived state of the session (Init, Up, Down, or 1200 AdminDown.) The exact action taken when the session state 1201 changes is outside the scope of this specification, though it 1202 is expected that this state change (particularly to and from Up 1203 state) is reported to other components of the system. This 1204 variable MUST be initialized to Down. 1206 bfd.RemoteSessionState 1208 The session state last reported by the remote system in the 1209 State (Sta) field of the BFD Control packet. This variable 1210 MUST be initialized to Down. 1212 bfd.LocalDiscr 1214 The local discriminator for this BFD session, used to uniquely 1215 identify it. It MUST be unique across all BFD sessions on this 1216 system, and nonzero. It SHOULD be set to a random (but still 1217 unique) value to improve security. The value is otherwise 1218 outside the scope of this specification. 1220 bfd.RemoteDiscr 1222 The remote discriminator for this BFD session. This is the 1223 discriminator chosen by the remote system, and is totally 1224 opaque to the local system. This MUST be initialized to zero. 1226 bfd.LocalDiag 1228 The diagnostic code specifying the reason for the most recent 1229 local session state change to states Down or AdminDown. This 1230 MUST be initialized to zero (No Diagnostic.) 1232 bfd.DesiredMinTxInterval 1234 The minimum interval, in microseconds, between transmitted BFD 1235 Control packets that this system would like to use at the 1236 current time. The actual interval is negotiated between the 1237 two systems. This MUST be initialized to a value of at least 1238 one second (1,000,000 microseconds) according to the rules 1239 described in section 6.8.3. The setting of this variable is 1240 otherwise outside the scope of this specification. 1242 bfd.RequiredMinRxInterval 1244 The minimum interval, in microseconds, between received BFD 1245 Control packets that this system requires. The setting of this 1246 variable is outside the scope of this specification. A value 1247 of zero means that this system does not want to receive any 1248 periodic BFD Control packets. See section 6.8.18 for details. 1250 bfd.RemoteMinRxInterval 1252 The last value of Required Min RX Interval received from the 1253 remote system in a BFD Control packet. This variable MUST be 1254 initialized to 1. 1256 bfd.DemandMode 1258 Set to 1 if the local system wishes to use Demand mode, or 0 if 1259 not. 1261 bfd.RemoteDemandMode 1263 Set to 1 if the remote system wishes to use Demand mode, or 0 1264 if not. This is the value of the Demand (D) bit in the last 1265 received BFD Control packet. This variable MUST be initialized 1266 to zero. 1268 bfd.DetectMult 1270 The desired detection time multiplier for BFD Control packets. 1271 The negotiated Control packet transmission interval, multiplied 1272 by this variable, will be the detection time for this session 1273 (as seen by the remote system.) This variable MUST be a 1274 nonzero integer, and is otherwise outside the scope of this 1275 specification. See section 6.8.4 for further information. 1277 bfd.AuthType 1279 The authentication type in use for this session, as defined in 1280 section 4.1, or zero if no authentication is in use. 1282 bfd.RcvAuthSeq 1284 A 32 bit unsigned integer containing the next sequence number 1285 for keyed MD5 or SHA1 authentication expected to be received. 1286 The initial value is unimportant. 1288 bfd.XmitAuthSeq 1290 A 32 bit unsigned integer containing the next sequence number 1291 for keyed MD5 or SHA1 authentication to be transmitted. This 1292 variable MUST be initialized to a random 32 bit value. 1294 bfd.AuthSeqKnown 1296 Set to 1 if the next sequence number for keyed MD5 or SHA1 1297 authentication expected to be received is known, or 0 if it is 1298 not known. This variable MUST be initialized to zero. 1300 This variable MUST be set to zero after no packets have been 1301 received on this session for at least twice the Detection Time. 1302 This ensures that the sequence number can be resynchronized if 1303 the remote system restarts. 1305 6.8.2. Timer Negotiation 1307 The time values used to determine BFD packet transmission intervals 1308 and the session detection time are continuously negotiated, and thus 1309 may be changed at any time. The negotiation and time values are 1310 independent in each direction for each session. 1312 Each system reports in the BFD Control packet how rapidly it would 1313 like to transmit BFD packets, as well as how rapidly it is prepared 1314 to receive them. With the exceptions listed in the remainder of this 1315 section, a system MUST NOT transmit BFD Control packets at an 1316 interval less than the larger of bfd.DesiredMinTxInterval and 1317 bfd.RemoteMinRxInterval. In other words, the system reporting the 1318 slower rate determines the transmission rate. 1320 The periodic transmission of BFD Control packets SHOULD be jittered 1321 by up to 25%, that is, the interval SHOULD be reduced by a random 1322 value of 0 to 25%, in order to avoid self-synchronization. Thus, the 1323 average interval between packets may be up to 12.5% less than that 1324 negotiated. 1326 If bfd.DetectMult is equal to 1, the interval between transmitted BFD 1327 Control packets MUST be no more than 90% of the negotiated 1328 transmission interval, and MUST be no less than 75% of the negotiated 1329 transmission interval. This is to ensure that, on the remote system, 1330 the calculated DetectTime does not pass prior to the receipt of the 1331 next BFD Control packet. 1333 6.8.3. Timer Manipulation 1335 The time values used to determine BFD packet transmission intervals 1336 and the session detection time may be modified at any time without 1337 affecting the state of the session. When the timer parameters are 1338 changed for any reason, the requirements of this section apply. 1340 If either bfd.DesiredMinTxInterval is changed or 1341 bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be 1342 initiated (see section 6.5). If the timing is such that a system 1343 receiving a Poll Sequence wishes to change the parameters described 1344 in this paragraph, the new parameter values may be carried in packets 1345 with the Final (F) bit set, even if the Poll Sequence has not yet 1346 been sent. 1348 If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up, 1349 the actual transmission interval used MUST NOT change until the Poll 1350 Sequence described above has terminated. This is to ensure that the 1351 remote system updates its Detection Time before the transmission 1352 interval increases. 1354 If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up, 1355 the previous value of bfd.RequiredMinRxInterval MUST be used when 1356 calculating the detection time for the remote system until the Poll 1357 Sequence described above has terminated. This is to ensure that the 1358 remote system is transmitting packets at the higher rate (and those 1359 packets are being received) prior to the detection time being 1360 reduced. 1362 When bfd.SessionState is not Up, the system MUST set 1363 bfd.DesiredMinTxInterval to a value of not less than one second 1364 (1,000,000 microseconds.) This is intended to ensure that the 1365 bandwidth consumed by BFD sessions that are not Up is negligible, 1366 particularly in the case where a neighbor may not be running BFD. 1368 If the local system reduces its transmit interval due to 1369 bfd.RemoteMinRxInterval being reduced (the remote system has 1370 advertised a reduced value in Required Min RX Interval), and the 1371 remote system is not in Demand mode, the local system MUST honor the 1372 new interval immediately. In other words, the local system cannot 1373 wait longer than the new interval between the previous packet 1374 transmission and the next one. If this interval has already passed 1375 since the last transmission (because the new interval is 1376 significantly shorter), the local system MUST send the next periodic 1377 BFD Control packet as soon as practicable. 1379 When the Echo function is active, a system SHOULD set 1380 bfd.RequiredMinRxInterval to a value of not less than one second 1381 (1,000,000 microseconds.) This is intended to keep received BFD 1382 Control traffic at a negligible level, since the actual detection 1383 function is being performed using BFD Echo packets. 1385 In any case other than those explicitly called out above, timing 1386 parameter changes MUST be effected immediately (changing the 1387 transmission rate and/or the Detection Time), and a Poll Sequence 1388 SHOULD NOT be sent. 1390 Note that the Poll Sequence mechanism is ambiguous if more than one 1391 parameter change is made that would require its use, and those 1392 multiple changes are spread across multiple packets (since the 1393 semantics of the returning Final are unclear.) Therefore, if 1394 multiple changes are made that require the use of a Poll Sequence, 1395 there are three choices: 1) they MUST be communicated in a single 1396 BFD Control packet (so the semantics of the Final reply are clear), 1397 or 2) sufficient time must have transpired since the Poll Sequence 1398 was completed to disambiguate the situation (at least a round trip 1399 time since the last Poll was transmitted) prior to the initiation of 1400 another Poll Sequence, or 3) an additional BFD Control packet with 1401 the Final (F) bit *clear* MUST be received after the Poll Sequence 1402 has completed prior to the initiation of another Poll Sequence (this 1403 option is not available when Demand mode is active.) 1405 6.8.4. Calculating the Detection Time 1407 The Detection Time (the period of time without receiving BFD packets 1408 after which the session is determined to have failed) is not carried 1409 explicitly in the protocol. Rather, it is calculated independently 1410 in each direction by the receiving system based on the negotiated 1411 transmit interval and the detection multiplier. Note that there may 1412 be different detection times in each direction. 1414 The calculation of the Detection Time is slightly different when in 1415 Demand mode versus Asynchronous mode. 1417 In Asynchronous mode, the Detection Time calculated in the local 1418 system is equal to the value of Detect Mult received from the remote 1419 system, multiplied by the agreed transmit interval of the remote 1420 system (the greater of bfd.RequiredMinRxInterval and the last 1421 received Desired Min TX Interval.) The Detect Mult value is (roughly 1422 speaking, due to jitter) the number of packets that have to be missed 1423 in a row to declare the session to be down. 1425 If Demand mode is not active, and a period of time equal to the 1426 Detection Time passes without receiving a BFD Control packet from the 1427 remote system, and bfd.SessionState is Init or Up, the session has 1428 gone down--the local system MUST set bfd.SessionState to Down and 1429 bfd.LocalDiag to 1 (Control Detection Time Expired.) 1431 In Demand mode, the Detection Time calculated in the local system is 1432 equal to bfd.DetectMult, multiplied by the agreed transmit interval 1433 of the local system (the greater of bfd.DesiredMinTxInterval and 1434 bfd.RemoteMinRxInterval.) bfd.DetectMult is (roughly speaking, due 1435 to jitter) the number of packets that have to be missed in a row to 1436 declare the session to be down. 1438 If Demand mode is active, and a period of time equal to the Detection 1439 Time passes after the initiation of a Poll Sequence (the transmission 1440 of the first BFD Control packet with the Poll bit set), the session 1441 has gone down--the local system MUST set bfd.SessionState to Down, 1442 and bfd.LocalDiag to 1 (Control Detection Time Expired.) 1444 (Note that a packet is considered to have been received, for the 1445 purposes of Detection Time expiration, only if it has not been 1446 "discarded" according to the rules of section 6.8.6.) 1448 6.8.5. Detecting Failures with the Echo Function 1450 When the Echo function is active and a sufficient number of Echo 1451 packets have not arrived as they should, the session has gone 1452 down--the local system MUST set bfd.SessionState to Down, and 1453 bfd.LocalDiag to 2 (Echo Function Failed.) 1455 The means by which the Echo function failures are detected is outside 1456 of the scope of this specification. Any means which will detect a 1457 communication failure is acceptable. 1459 6.8.6. Reception of BFD Control Packets 1461 When a BFD Control packet is received, the following procedure MUST 1462 be followed, in the order specified. If the packet is discarded 1463 according to these rules, processing of the packet MUST cease at that 1464 point. 1466 If the version number is not correct (1), the packet MUST be 1467 discarded. 1469 If the Length field is less than the minimum correct value (24 if 1470 the A bit is clear, or 26 if the A bit is set), the packet MUST be 1471 discarded. 1473 If the Length field is greater than the payload of the 1474 encapsulating protocol, the packet MUST be discarded. 1476 If the Detect Mult field is zero, the packet MUST be discarded. 1478 If the Multipoint (M) bit is nonzero, the packet MUST be 1479 discarded. 1481 If the My Discriminator field is zero, the packet MUST be 1482 discarded. 1484 If the Your Discriminator field is nonzero, it MUST be used to 1485 select the session with which this BFD packet is associated. If 1486 no session is found, the packet MUST be discarded. 1488 If the Your Discriminator field is zero and the State field is not 1489 Down or AdminDown, the packet MUST be discarded. 1491 If the Your Discriminator field is zero, the session MUST be 1492 selected based on some combination of other fields, possibly 1493 including source addressing information, the My Discriminator 1494 field, and the interface over which the packet was received. The 1495 exact method of selection is application-specific and is thus 1496 outside the scope of this specification. If a matching session is 1497 not found, a new session may be created, or the packet may be 1498 discarded. This choice is outside the scope of this 1499 specification. 1501 If the A bit is set and no authentication is in use (bfd.AuthType 1502 is zero), the packet MUST be discarded. 1504 If the A bit is clear and authentication is in use (bfd.AuthType 1505 is nonzero), the packet MUST be discarded. 1507 If the A bit is set, the packet MUST be authenticated under the 1508 rules of section 6.7, based on the authentication type in use 1509 (bfd.AuthType.) This may cause the packet to be discarded. 1511 Set bfd.RemoteDiscr to the value of My Discriminator. 1513 Set bfd.RemoteState to the value of the State (Sta) field. 1515 Set bfd.RemoteDemandMode to the value of the Demand (D) bit. 1517 Set bfd.RemoteMinRxInterval to the value of Required Min RX 1518 Interval. 1520 If the Required Min Echo RX Interval field is zero, the 1521 transmission of Echo packets, if any, MUST cease. 1523 If a Poll Sequence is being transmitted by the local system and 1524 the Final (F) bit in the received packet is set, the Poll Sequence 1525 MUST be terminated. 1527 Update the transmit interval as described in section 6.8.2. 1529 Update the Detection Time as described in section 6.8.4. 1531 If bfd.SessionState is AdminDown 1532 Discard the packet 1534 If received state is AdminDown 1535 If bfd.SessionState is not Down 1536 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 1537 Set bfd.SessionState to Down 1539 Else 1541 If bfd.SessionState is Down 1542 If received State is Down 1543 Set bfd.SessionState to Init 1544 Else if received State is Init 1545 Set bfd.SessionState to Up 1547 Else if bfd.SessionState is Init 1548 If received State is Init or Up 1549 Set bfd.SessionState to Up 1551 Else (bfd.SessionState is Up) 1552 If received State is Down 1553 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 1554 Set bfd.SessionState to Down 1556 Check to see if Demand mode should become active or not 1557 (see section 6.6). 1559 If bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and 1560 bfd.RemoteSessionState is Up, Demand mode is active on the 1561 remote system and the local system MUST cease the periodic 1562 transmission of BFD Control packets (see section 6.8.7.) 1564 If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or 1565 bfd.RemoteSessionState is not Up, Demand mode is not active on the 1566 remote system and the local system MUST send periodic BFD Control 1567 packets (see section 6.8.7.) 1569 If the Poll (P) bit is set, send a BFD Control packet to the 1570 remote system with the Poll (P) bit clear, and the Final (F) bit 1571 set (see section 6.8.7.) 1573 If the packet was not discarded, it has been received for purposes 1574 of the Detection Time expiration rules in section 6.8.4. 1576 6.8.7. Transmitting BFD Control Packets 1578 BFD Control packets MUST be transmitted periodically at the rate 1579 determined according to section 6.8.2, except as specified in this 1580 section. 1582 The transmit interval MUST be recalculated whenever 1583 bfd.DesiredMinTxInterval changes, or whenever bfd.RemoteMinRxInterval 1584 changes, and is equal to the greater of those two values. See 1585 sections 6.8.2 and 6.8.3 for details on transmit timers. 1587 A system MUST NOT transmit BFD Control packets if bfd.RemoteDiscr is 1588 zero and the system is taking the Passive role. 1590 A system MUST NOT periodically transmit BFD Control packets if 1591 bfd.RemoteMinRxInterval is zero. 1593 A system MUST NOT periodically transmit BFD Control packets if Demand 1594 mode is active on the remote system (bfd.RemoteDemandMode is 1, 1595 bfd.SessionState is Up, and bfd.RemoteSessionState is Up) and a Poll 1596 Sequence is not being transmitted. 1598 If a BFD Control packet is received with the Poll (P) bit set to 1, 1599 the receiving system MUST transmit a BFD Control packet with the Poll 1600 (P) bit clear and the Final (F) bit set as soon as practicable, 1601 without respect to the transmission timer or any other transmission 1602 limitations, without respect to the session state, and without 1603 respect to whether Demand mode is active on either system. A system 1604 MAY limit the rate at which such packets are transmitted. If rate 1605 limiting is in effect, the advertised value of Desired Min TX 1606 Interval MUST be greater than or equal to the interval between 1607 transmitted packets imposed by the rate limiting function. 1609 A system MUST NOT set the Demand (D) bit unless bfd.DemandMode is 1, 1610 bfd.SessionState is Up, and bfd.RemoteSessionState is Up. 1612 A BFD Control packet SHOULD be transmitted during the interval 1613 between periodic Control packet transmissions when the contents of 1614 that packet would differ from that in the previously transmitted 1615 packet (other than the Poll and Final bits) in order to more rapidly 1616 communicate a change in state. 1618 The contents of transmitted BFD Control packets MUST be set as 1619 follows: 1621 Version 1623 Set to the current version number (1). 1625 Diagnostic (Diag) 1627 Set to bfd.LocalDiag. 1629 State (Sta) 1631 Set to the value indicated by bfd.SessionState. 1633 Poll (P) 1635 Set to 1 if the local system is sending a Poll Sequence, or 0 if 1636 not. 1638 Final (F) 1640 Set to 1 if the local system is responding to a Control packet 1641 received with the Poll (P) bit set, or 0 if not. 1643 Control Plane Independent (C) 1645 Set to 1 if the local system's BFD implementation is independent 1646 of the control plane (it can continue to function through a 1647 disruption of the control plane.) 1649 Authentication Present (A) 1651 Set to 1 if authentication is in use on this session (bfd.AuthType 1652 is nonzero), or 0 if not. 1654 Demand (D) 1656 Set to bfd.DemandMode if bfd.SessionState is Up and 1657 bfd.RemoteSessionState is Up. Otherwise it is set to 0. 1659 Multipoint (M) 1661 Set to 0. 1663 Detect Mult 1665 Set to bfd.DetectMult. 1667 Length 1669 Set to the appropriate length, based on the fixed header length 1670 (24) plus any Authentication Section. 1672 My Discriminator 1674 Set to bfd.LocalDiscr. 1676 Your Discriminator 1678 Set to bfd.RemoteDiscr. 1680 Desired Min TX Interval 1682 Set to bfd.DesiredMinTxInterval. 1684 Required Min RX Interval 1686 Set to bfd.RequiredMinRxInterval. 1688 Required Min Echo RX Interval 1690 Set to the minimum required Echo packet receive interval for this 1691 session. If this field is set to zero, the local system is 1692 unwilling or unable to loop back BFD Echo packets to the remote 1693 system, and the remote system will not send Echo packets. 1695 Authentication Section 1697 Included and set according to the rules in section 6.7 if 1698 authentication is in use (bfd.AuthType is nonzero.) Otherwise 1699 this section is not present. 1701 6.8.8. Reception of BFD Echo Packets 1703 A received BFD Echo packet MUST be demultiplexed to the appropriate 1704 session for processing. A means of detecting missing Echo packets 1705 MUST be implemented, which most likely involves processing of the 1706 Echo packets that are received. The processing of received Echo 1707 packets is otherwise outside the scope of this specification. 1709 6.8.9. Transmission of BFD Echo Packets 1711 BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not 1712 Up. BFD Echo packets MUST NOT be transmitted unless the last BFD 1713 Control packet received from the remote system contains a nonzero 1714 value in Required Min Echo RX Interval. 1716 BFD Echo packets MAY be transmitted when bfd.SessionState is Up. The 1717 interval between transmitted BFD Echo packets MUST NOT be less than 1718 the value advertised by the remote system in Required Min Echo RX 1719 Interval, except as follows: 1721 A 25% jitter MAY be applied to the rate of transmission, such that 1722 the actual interval MAY be between 75% and 100% of the advertised 1723 value. A single BFD Echo packet MAY be transmitted between 1724 normally scheduled Echo transmission intervals. 1726 The transmission of BFD Echo packets is otherwise outside the scope 1727 of this specification. 1729 6.8.10. Min Rx Interval Change 1731 When it is desired to change the rate at which BFD Control packets 1732 arrive from the remote system, bfd.RequiredMinRxInterval can be 1733 changed at any time to any value. The new value will be transmitted 1734 in the next outgoing Control packet, and the remote system will 1735 adjust accordingly. See section 6.8.3 for further requirements. 1737 6.8.11. Min Tx Interval Change 1739 When it is desired to change the rate at which BFD Control packets 1740 are transmitted to the remote system (subject to the requirements of 1741 the neighboring system), bfd.DesiredMinTxInterval can be changed at 1742 any time to any value. The rules in section 6.8.3 apply. 1744 6.8.12. Detect Multiplier Change 1746 When it is desired to change the detect multiplier, the value of 1747 bfd.DetectMult can be changed to any nonzero value. The new value 1748 will be transmitted with the next BFD Control packet, and the use of 1749 a Poll Sequence is not necessary. See section 6.6 for additional 1750 requirements. 1752 6.8.13. Enabling or Disabling The Echo Function 1754 If it is desired to start or stop the transmission of BFD Echo 1755 packets, this MAY be done at any time (subject to the transmission 1756 requirements detailed in section 6.8.9.) 1758 If it is desired to enable or disable the looping back of received 1759 BFD Echo packets, this MAY be done at any time by changing the value 1760 of Required Min Echo RX Interval to zero or nonzero in outgoing BFD 1761 Control packets. 1763 6.8.14. Enabling or Disabling Demand Mode 1765 If it is desired to start or stop Demand mode, this MAY be done at 1766 any time by setting bfd.DemandMode to the proper value. Demand mode 1767 will subsequently become active under the rules described in section 1768 6.6. 1770 If Demand mode is no longer active on the remote system, the local 1771 system MUST begin transmitting periodic BFD Control packets as 1772 described in section 6.8.7. 1774 6.8.15. Forwarding Plane Reset 1776 When the forwarding plane in the local system is reset for some 1777 reason, such that the remote system can no longer rely on the local 1778 forwarding state, the local system MUST set bfd.LocalDiag to 4 1779 (Forwarding Plane Reset), and set bfd.SessionState to Down. 1781 6.8.16. Administrative Control 1783 There may be circumstances where it is desirable to administratively 1784 enable or disable a BFD session. When this is desired, the following 1785 procedure MUST be followed: 1787 If enabling session 1788 Set bfd.SessionState to Down 1790 Else 1791 Set bfd.SessionState to AdminDown 1792 Set bfd.LocalDiag to an appropriate value 1793 Cease the transmission of BFD Echo packets 1795 If signaling is received from outside BFD that the underlying 1796 path has failed, an implementation MAY administratively disable 1797 the session with the diagnostic Path Down. 1799 Other scenarios MAY use the diagnostic Administratively Down. 1801 6.8.17. Concatenated Paths 1803 If the path being monitored by BFD is concatenated with other paths, 1804 it may be desirable to propagate the indication of a failure of one 1805 of those paths across the BFD session (providing an interworking 1806 function for liveness monitoring between BFD and other technologies.) 1807 Two diagnostic codes are defined for this purpose: Concatenated Path 1808 Down and Reverse Concatenated Path Down. The first propagates 1809 forward path failures (in which the concatenated path fails in the 1810 direction toward the interworking system), and the second propagates 1811 reverse path failures (in which the concatenated path fails in the 1812 direction away from the interworking system, assuming a bidirectional 1813 link.) 1815 A system MAY signal one of these failure states by simply setting 1816 bfd.LocalDiag to the appropriate diagnostic code. Note that the BFD 1817 session is not taken down. If Demand mode is not active on the 1818 remote system, no other action is necessary, as the diagnostic code 1819 will be carried via the periodic transmission of BFD Control packets. 1820 If Demand mode is active on the remote system (the local system is 1821 not transmitting periodic BFD Control packets), a Poll Sequence MUST 1822 be initiated to ensure that the diagnostic code is transmitted. Note 1823 that if the BFD session subsequently fails, the diagnostic code will 1824 be overwritten with a code detailing the cause of the failure. It is 1825 up to the interworking agent to perform the above procedure again, 1826 once the BFD session reaches Up state, if the propagation of the 1827 concatenated path failure is to resume. 1829 6.8.18. Holding Down Sessions 1831 A system may choose to prevent a BFD session from being established. 1832 One possible reason might be to manage the rate at which sessions are 1833 established. This can be done by holding the session in Down or 1834 AdminDown state, as appropriate. 1836 There are two related mechanisms that are available to help with this 1837 task. First, a system is required to maintain session state 1838 (including timing parameters), even when a session is down, until a 1839 Detection Time has passed without the receipt of any BFD Control 1840 packets. This means that a system may take down a session and 1841 transmit an arbitrarily large value in the Required Min RX Interval 1842 field to control the rate at which it receives packets. 1844 Additionally, a system may transmit a value of zero for Required Min 1845 RX Interval to indicate that the remote system should send no packets 1846 whatsoever. 1848 So long as the local system continues to transmit BFD Control 1849 packets, the remote system is obligated to obey the value carried in 1850 Required Min RX Interval. If the remote system does not receive any 1851 BFD Control packets for a Detection Time, it resets 1852 bfd.RemoteMinRxIvl to a small value and then can transmit at its own 1853 rate. 1855 Backward Compatibility (Non-Normative) 1857 Although Version 0 of this document is unlikely to have been deployed 1858 widely, some implementors may wish to have a backward compatibility 1859 mechanism. Note that any mechanism may be potentially used that does 1860 not alter the protocol definition, so interoperability should not be 1861 an issue. 1863 The suggested mechanism described here has the property that it will 1864 converge on version 1 if both systems implement it, even if one 1865 system is upgraded from version 0 within a detection time. It will 1866 interoperate with a system that implements only one version (or is 1867 configured to support only one version.) A system should obviously 1868 not perform this function if it is configured to or is only capable 1869 of using a single version. 1871 A BFD session will enter a "negotiation holddown" if it is configured 1872 for automatic versioning and either has just started up, or the 1873 session has been manually cleared. The session is set to AdminDown 1874 state and Version 1. During the holddown period, which lasts for one 1875 detection time, the system sends BFD Control packets as usual, but 1876 ignores received packets. After the holddown time is complete, the 1877 state transitions to Down and normal operation resumes. 1879 When a system is not in holddown, if it doing automatic versioning 1880 and is currently using Version 1, if any Version 0 packet is received 1881 for the session, it switches immediately to Version 0. If it is 1882 currently using Version 0 and a Version 1 packet is received that 1883 indicates that the neighbor is in state AdminDown, it switches to 1884 Version 1. If using Version 0 and a Version 1 packet is received 1885 indicating a state other than AdminDown, the packet is ignored (per 1886 spec.) 1888 If the version being used is changed, the session goes down as 1889 appropriate for the new version (Down state for Version 1 or Failing 1890 state for Version 0.) 1892 Contributors 1894 Kireeti Kompella and Yakov Rekhter of Juniper Networks were also 1895 significant contributors to this document. 1897 Acknowledgments 1899 This document was inspired by (and is intended to replace) the 1900 Protocol Liveness Protocol draft, written by Kireeti Kompella. 1902 Demand mode was inspired by draft-ietf-ipsec-dpd-03.txt, by G. Huang 1903 et al. 1905 The authors would also like to thank Mike Shand, John Scudder, 1906 Stewart Bryant, Pekka Savola, and Richard Spencer for their 1907 substantive input. 1909 Security Considerations 1911 As BFD may be tied into the stability of the network infrastructure 1912 (such as routing protocols), the effects of an attack on a BFD 1913 session may be very serious. This ultimately has denial-of-service 1914 effects, as links may be declared to be down (or falsely declared to 1915 be up.) 1917 When BFD is run over network layer protocols, a significant denial- 1918 of-service risk is created, as BFD packets may be trivial to spoof. 1919 When the session is directly connected across a single link 1920 (physical, or a secure tunnel such as IPsec), the TTL or Hop Count 1921 MUST be set to the maximum on transmit, and checked to be equal to 1922 the maximum value on reception (and the packet dropped if this is not 1923 the case.) See [GTSM] for more information on this technique. If 1924 BFD is run across multiple hops or an insecure tunnel (such as GRE), 1925 the Authentication Section SHOULD be utilized. 1927 The level of security provided by the Authentication Section varies 1928 based on the authentication type used. Simple Password 1929 authentication is obviously only as secure as the secrecy of the 1930 passwords used, and should be considered only if the BFD session is 1931 guaranteed to be run over an infrastructure not subject to packet 1932 interception. Its chief advantage is that it minimizes the 1933 computational effort required for authentication. 1935 Keyed MD5 authentication is much stronger than Simple Password 1936 authentication since the keys cannot be discerned by intercepting 1937 packets. It is vulnerable to replay attacks in between increments of 1938 the sequence number. The sequence number can be incremented as 1939 seldom (or as often) as desired, trading off resistance to replay 1940 attacks with the computational effort required for authentication. 1942 Meticulous Keyed MD5 authentication is stronger yet, as it requires 1943 the sequence number to be incremented for every packet. Replay 1944 attack vulnerability is reduced due to the requirement that the 1945 sequence number must be incremented on every packet, the window size 1946 of acceptable packets is small, and the initial sequence number is 1947 randomized. There is still a window of attack at the beginning of 1948 the session while the sequence number is being determined. This 1949 authentication scheme requires an MD5 calculation on every packet 1950 transmitted and received. 1952 Using SHA1 rather than MD5 is believed to have stronger security 1953 properties. All comments about MD5 in this section also apply to 1954 SHA1. 1956 If both systems randomize their Local Discriminator values at the 1957 beginning of a session, replay attacks may be further mitigated, 1958 regardless of the authentication type in use. Since the Local 1959 Discriminator may be changed at any time during a session, this 1960 mechanism may also help mitigate attacks. 1962 IANA Considerations 1964 This document has no actions for IANA. 1966 Normative References 1968 [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism 1969 (GTSM)", RFC 3682, February 2004. 1971 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 1972 Requirement Levels", RFC 2119, March 1997. 1974 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1975 1992. 1977 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 1979 [SHA1] "Secure Hash Standard", United States of America, National 1980 Institute of Science and Technology, Federal Information 1981 Processing Standard (FIPS) 180-1, April 1993. 1983 Authors' Addresses 1985 Dave Katz 1986 Juniper Networks 1987 1194 N. Mathilda Ave. 1988 Sunnyvale, California 94089-1206 USA 1989 Phone: +1-408-745-2000 1990 Email: dkatz@juniper.net 1992 Dave Ward 1993 Cisco Systems 1994 170 W. Tasman Dr. 1995 San Jose, CA 95134 USA 1996 Phone: +1-408-526-4000 1997 Email: dward@cisco.com 1999 Changes from the Previous Draft 2001 The most significant technical change in this draft is a rework of 2002 Demand Mode, based on bugs turned up by implementation experience. 2003 Additionally, Demand Mode can now be enabled independently in each 2004 direction. 2006 Text was added requiring that an implementation maintain session 2007 state for a detection time after the session goes down, to ensure 2008 that the remote end can still control the transmit rate of the local 2009 system even when the session isn't up. In conjunction with this, the 2010 semantics of Required Min RX Interval so that a value of zero informs 2011 the remote system that it cannot send any periodic BFD Control 2012 packets. 2014 Additional state variables were added to support Demand mode, and to 2015 simplify the text elsewhere. 2017 Text describing how to disambiguate multiple Poll Sequences in the 2018 face of multiple parameter changes was added. 2020 The pseudocode describing packet reception was reordered slightly. 2022 Text regarding the semantics of Down and AdminDown state was added. 2024 Many editorial changes were made. The most significant is to unify 2025 the concept of a Poll Sequence (so that it is independent of Demand 2026 Mode.) Explanatory text was added in a number of places based on 2027 feedback from implementors. 2029 IPR Notice 2031 The IETF has been notified of intellectual property rights claimed in 2032 regard to some or all of the specification contained in this 2033 document. For more information consult the online list of claimed 2034 rights. 2036 The IETF takes no position regarding the validity or scope of any 2037 Intellectual Property Rights or other rights that might be claimed to 2038 pertain to the implementation or use of the technology described in 2039 this document or the extent to which any license under such rights 2040 might or might not be available; nor does it represent that it has 2041 made any independent effort to identify any such rights. Information 2042 on the procedures with respect to rights in RFC documents can be 2043 found in BCP 78 and BCP 79. 2045 Copies of IPR disclosures made to the IETF Secretariat and any 2046 assurances of licenses to be made available, or the result of an 2047 attempt made to obtain a general license or permission for the use of 2048 such proprietary rights by implementers or users of this 2049 specification can be obtained from the IETF on-line IPR repository at 2050 http://www.ietf.org/ipr. 2052 The IETF invites any interested party to bring to its attention any 2053 copyrights, patents or patent applications, or other proprietary 2054 rights that may cover technology that may be required to implement 2055 this standard. Please address the information to the IETF at ietf- 2056 ipr@ietf.org. 2058 Full Copyright Notice 2060 Copyright (C) The IETF Trust (2007). 2062 This document is subject to the rights, licenses and restrictions 2063 contained in BCP 78, and except as set forth therein, the authors 2064 retain all their rights. 2066 This document and the information contained herein are provided on an 2067 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2068 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2069 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2070 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2071 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2072 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2074 Acknowledgement 2076 Funding for the RFC Editor function is currently provided by the 2077 Internet Society. 2079 This document expires in September, 2007.