idnits 2.17.1 draft-ietf-bfd-base-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 37 longer pages, the longest (page 30) being 74 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 37 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 49, but not defined == Unused Reference: 'KEYWORD' is defined on line 1523, but no explicit reference was found in the text == Unused Reference: 'MD5' is defined on line 1526, 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') Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Katz 2 Internet Draft Juniper Networks 3 D. Ward 4 Cisco Systems 5 Expires: January, 2005 July, 2004 7 Bidirectional Forwarding Detection 8 draft-ietf-bfd-base-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 This document describes a protocol intended to detect faults in the 38 bidirectional path between two forwarding engines, including 39 interfaces, data link(s), and to the extent possible the forwarding 40 engines themselves, with potentially very low latency. It operates 41 independently of media, data protocols, and routing protocols. 42 Comments on this draft should be directed to rtg-bfd@ietf.org. 44 Conventions used in this document 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC-2119 [KEYWORDS]. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 55 3.1 Addressing and Session Establishment . . . . . . . . . . . 5 56 3.2 Operating Modes . . . . . . . . . . . . . . . . . . . . . 5 57 4. BFD Control Packet Format . . . . . . . . . . . . . . . . . . 7 58 4.1 Generic BFD Control Packet Format . . . . . . . . . . . . 7 59 4.2 Simple Password Authentication Section Format . . . . . 11 60 4.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 61 Section Format . . . . . . . . . . . . . . . . . . . . . 12 62 5. BFD Echo Packet Format . . . . . . . . . . . . . . . . . . . 13 63 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . 13 64 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 65 6.2 Demultiplexing and the Discriminator Fields . . . . . . 15 66 6.3 The Echo Function and Asymmetry . . . . . . . . . . . . 15 67 6.4 Demand Mode . . . . . . . . . . . . . . . . . . . . . . 16 68 6.5 Authentication . . . . . . . . . . . . . . . . . . . . . 17 69 6.5.1 Simple Password Authentication . . . . . . . . . . 17 70 6.5.2 Keyed MD5 and Meticulous Keyed MD5 Authentication 18 71 6.6 Functional Specifics . . . . . . . . . . . . . . . . . . 20 72 6.6.1 State Variables . . . . . . . . . . . . . . . . . 20 73 6.6.2 Timer Negotiation . . . . . . . . . . . . . . . . 23 74 6.6.3 Timer Manipulation . . . . . . . . . . . . . . . . 24 75 6.6.4 Calculating the Detection Time . . . . . . . . . . 25 76 6.6.5 Detecting Failures with the Echo Function . . . . 26 77 6.6.6 Reception of BFD Control Packets . . . . . . . . . 26 78 6.6.7 Transmitting BFD Control Packets . . . . . . . . . 28 79 6.6.8 Initiation of a Poll Sequence . . . . . . . . . . 31 80 6.6.9 Reception of BFD Echo Packets . . . . . . . . . . 31 81 6.6.10 Transmission of BFD Echo Packets . . . . . . . . 31 82 6.6.11 Min Rx Interval Change . . . . . . . . . . . . . 32 83 6.6.12 Min Tx Interval Change . . . . . . . . . . . . . 32 84 6.6.13 Detect Multiplier Change . . . . . . . . . . . . 32 85 6.6.14 Enabling or Disabling the Echo Function . . . . . 32 86 6.6.15 Enabling or Disabling Demand Mode . . . . . . . . 33 87 6.6.16 Forwarding Plane Reset . . . . . . . . . . . . . 33 88 6.6.17 Administrative Control . . . . . . . . . . . . . 33 89 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34 90 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 91 Security Considerations . . . . . . . . . . . . . . . . . . . . 34 92 Normative References . . . . . . . . . . . . . . . . . . . . . 35 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 35 94 Changes from the previous draft . . . . . . . . . . . . . . . . 36 95 IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 36 97 1. Introduction 99 An increasingly important feature of networking equipment is the 100 rapid detection of communication failures between adjacent systems, 101 in order to more quickly establish alternative paths. Currently, 102 detection can come fairly quickly in certain circumstances when data 103 link hardware comes into play (such as SONET alarms.) However, there 104 are media that do not provide this kind of signaling (such as 105 Ethernet), and some media may not detect certain kinds of failures in 106 the path, for example, failing interfaces or forwarding engine 107 components. 109 Networks use relatively slow "Hello" mechanisms, usually in routing 110 protocols, to detect failures when there is no hardware signaling to 111 help out. The time to detect failures ("detection times") available 112 in the existing protocols are no better than a second, which is far 113 too long for some applications and represents a great deal of lost 114 data at gigabit rates. Furthermore, routing protocol Hellos are of 115 no help when those routing protocols are not in use, and the 116 semantics of detection are subtly different--they detect a failure in 117 the path between the two routing protocol engines. 119 The goal of BFD is to provide low-overhead, short-duration detection 120 of failures in the path between adjacent forwarding engines, 121 including the interfaces, data link(s), and to the extent possible 122 the forwarding engines themselves. 124 An additional goal is to provide a single mechanism that can be used 125 for liveness detection over any media, at any protocol layer, with a 126 wide range of detection times and overhead, to avoid a proliferation 127 of different methods. 129 This document specifies the details of the base protocol. The use of 130 some mechanisms are application dependent, and will be specified in a 131 separate series of application documents. These issues are so noted. 133 Note that many of the exact mechanisms are implementation dependent 134 and will not affect interoperability, and are thus outside the scope 135 of this specification. Those issues are so noted. 137 2. Design 139 BFD is designed to detect failures in communication with a forwarding 140 plane next hop. It is intended to be implemented in some component 141 of the forwarding engine of a system, in cases where the forwarding 142 and control engines are separated. This not only binds the protocol 143 more to the forwarding plane, but decouples the protocol from the 144 fate of the routing protocol engine (making it useful in concert with 145 various "graceful restart" mechanisms for those protocols.) BFD may 146 also be implemented in the control engine, though doing so may 147 preclude the detection of some kinds of failures. 149 BFD operates on top of any data protocol being forwarded between two 150 systems. It is always run in a unicast, point-to-point mode. BFD 151 packets are carried as the payload of whatever encapsulating protocol 152 is appropriate for the medium and network. BFD may be running at 153 multiple layers in a system. The context of the operation of any 154 particular BFD session is bound to its encapsulation. 156 BFD can provide failure detection on any kind of path between 157 systems, including direct physical links, virtual circuits, tunnels, 158 MPLS LSPs, multihop routed paths, and unidirectional links (so long 159 as there is some return path, of course.) Multiple BFD sessions can 160 be established between the same pair of systems when multiple paths 161 between them are present in at least one direction, even if a lesser 162 number of paths are available in the other direction (multiple 163 parallel unidirectional links or MPLS LSPs, for example.) 165 The BFD state machine implements a three-way handshake, both when 166 establishing a BFD session and when tearing it down for any reason, 167 to ensure that both systems are aware of the state change. 169 BFD can be abstracted as a simple service. The service primitives 170 provided by BFD are to create, destroy, and modify a session, given 171 the destination address and other parameters. BFD in return provides 172 a signal to its clients indicating when the BFD session goes up or 173 down. 175 3. Protocol Overview 177 BFD is a simple hello protocol that in many respects is similar to 178 the detection components of well-known routing protocols. A pair of 179 systems transmit BFD packets periodically over each path between the 180 two systems, and if a system stops receiving BFD packets for long 181 enough, some component in that particular bidirectional path to the 182 neighboring system is assumed to have failed. Under some conditions, 183 systems may negotiate to not send periodic BFD packets in order to 184 reduce overhead. 186 A path is only declared to be operational when two-way communication 187 has been established between systems (though this does not preclude 188 the use of unidirectional links.) 190 A separate BFD session is created for each communications path and 191 data protocol in use between two systems. 193 Each system estimates how quickly it can send and receive BFD packets 194 in order to come to an agreement with its neighbor about how rapidly 195 detection of failure will take place. These estimates can be 196 modified in real time in order to adapt to unusual situations. This 197 design also allows for fast systems on a shared medium with a slow 198 system to be able to more rapidly detect failures between the fast 199 systems while allowing the slow system to participate to the best of 200 its ability. 202 3.1. Addressing and Session Establishment 204 A BFD session is established based on the needs of the application 205 that will be making use of it. It is up to the application to 206 determine the need for BFD, and the addresses to use--there is no 207 discovery mechanism in BFD. For example, an OSPF [OSPF] 208 implementation may request a BFD session to be established to a 209 neighbor discovered using the OSPF Hello protocol. 211 3.2. Operating Modes 213 BFD has two operating modes which may be selected, as well as an 214 additional function that can be used in combination with the two 215 modes. 217 The primary mode is known as Asynchronous mode. In this mode, the 218 systems periodically send BFD Control packets to one another, and if 219 a number of those packets in a row are not received by the other 220 system, the session is declared to be down. 222 The second mode is known as Demand mode. In this mode, it is assumed 223 that each system has an independent way of verifying that it has 224 connectivity to the other system, so once a BFD session is 225 established, the systems stop sending BFD Control packets, except 226 when either system feels the need to verify connectivity explicitly, 227 in which case a short sequence of BFD Control packets is sent, and 228 then the protocol quiesces. 230 An adjunct to both modes is the Echo function. When the Echo 231 function is active, a stream of BFD Echo packets is transmitted in 232 such a way as to have the other system loop them back through its 233 forwarding path. If a number of packets in a row of the echoed data 234 stream are not received, the session is declared to be down. The 235 Echo function may be used with either Asynchronous or Demand modes. 236 Since the Echo function is handling the task of detection, the rate 237 of periodic transmission of Control packets may be reduced (in the 238 case of Asynchronous mode) or eliminated completely (in the case of 239 Demand mode.) 241 Pure asynchronous mode is advantageous in that it requires half as 242 many packets to achieve a particular detection time as does the Echo 243 function. It is also used when the Echo function cannot be supported 244 for some reason. 246 The Echo function has the advantage of truly testing only the 247 forwarding path on the remote system, which may reduce round-trip 248 jitter and thus allow more aggressive detection times, as well as 249 potentially detecting some classes of failure that might not 250 otherwise be detected. 252 The Echo function may be enabled individually in each direction. It 253 is enabled in a particular direction only when the system that loops 254 the Echo packets back signals that it will allow it, and when the 255 system that sends the Echo packets decides it wishes to. 257 Demand mode is useful in situations where the overhead of a periodic 258 protocol might prove onerous, such as a system with a very large 259 number of BFD sessions. It is also useful when the Echo function is 260 being used symmetrically. Demand mode has the disadvantage that 261 detection times are essentially driven by the heuristics of the 262 system implementation and are not known to the BFD protocol. Demand 263 mode also may not be used when the path round trip time is greater 264 than the desired detection time. See section 6.4 for more details. 266 4. BFD Control Packet Format 268 4.1. Generic BFD Control Packet Format 270 BFD Control packets are sent in an encapsulation appropriate to the 271 environment, which is outside of the scope of this document. See the 272 appropriate application document for encapsulation details. 274 The BFD Control packet has a Mandatory Section and an optional 275 Authentication Section. The format of the Authentication Section, if 276 present, is dependent on the type of authentication in use. 278 The Mandatory Section of a BFD Control packet has the following 279 format: 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 |Vers | Diag |H|D|P|F|C|A|Rsv| Detect Mult | Length | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | My Discriminator | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Your Discriminator | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Desired Min TX Interval | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Required Min RX Interval | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Required Min Echo RX Interval | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 An optional Authentication Section may be present: 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Auth Type | Auth Len | Authentication Data... | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Version (Vers) 307 The version number of the protocol. This document defines 308 protocol version 0. 310 Diagnostic (Diag) 312 A diagnostic code specifying the local system's reason for the 313 last transition of the session from Up to some other state. 314 Values are: 316 0 -- No Diagnostic 317 1 -- Control Detection Time Expired 318 2 -- Echo Function Failed 319 3 -- Neighbor Signaled Session Down 320 4 -- Forwarding Plane Reset 321 5 -- Path Down 322 6 -- Concatenated Path Down 323 7 -- Administratively Down 324 8-31 -- Reserved for future use 326 This field allows remote systems to determine the reason that the 327 previous session failed, for example. 329 I Hear You (H) 331 This bit is set to 0 if the transmitting system either is not 332 receiving BFD packets from the remote system, or is in the process 333 of tearing down the BFD session for some reason. This bit is set 334 to 1 if the transmitting system believes it is communicating with 335 the remote system. See the Elements of Procedure below for more 336 details. 338 Demand (D) 340 If set, the transmitting system wishes to operate in Demand Mode. 341 If clear, the transmitting system does not wish to or is not 342 capable of operating in Demand Mode. 344 Poll (P) 346 If set, the transmitting system is requesting verification of 347 connectivity, or of a parameter change. If clear, the 348 transmitting system is not requesting verification. 350 Final (F) 352 If set, the transmitting system is responding to a received BFD 353 Control packet that had the Poll (P) bit set. If clear, the 354 transmitting system is not responding to a Poll. 356 Control Plane Independent (C) 358 If set, the transmitting system's BFD implementation does not 359 share fate with its control plane (in other words, BFD is 360 implemented in the forwarding plane and can continue to function 361 through disruptions in the control plane.) If clear, the 362 transmitting system's BFD implementation shares fate with its 363 control plane. 365 The use of this bit is application dependent and is outside the 366 scope of this specification. See specific application 367 specifications for details. 369 Authentication Present (A) 371 If set, the Authentication Section is present and the session is 372 to be authenticated. 374 Reserved (Rsv) 376 These bits must be zero on transmit, and ignored on receipt. 378 Detect Mult 380 Detect time multiplier. The negotiated transmit interval, 381 multiplied by this value, provides the detection time for the 382 transmitting system in Asynchronous mode. 384 Length 386 Length of the BFD Control packet, in bytes. 388 My Discriminator 390 A unique, nonzero discriminator value generated by the 391 transmitting system, used to demultiplex multiple BFD sessions 392 between the same pair of systems. 394 Your Discriminator 396 The discriminator received from the corresponding remote system. 397 This field reflects back the received value of My Discriminator, 398 or is zero if that value is unknown. 400 Desired Min TX Interval 402 This is the minimum interval, in microseconds, that the local 403 system would like to use when transmitting BFD Control packets. 405 Required Min RX Interval 407 This is the minimum interval, in microseconds, between received 408 BFD Control packets that this system is capable of supporting. 410 Required Min Echo RX Interval 412 This is the minimum interval, in microseconds, between received 413 BFD Echo packets that this system is capable of supporting. If 414 this value is zero, the transmitting system does not support the 415 receipt of BFD Echo packets. 417 Auth Type 419 The authentication type in use, if the Authentication Present (A) 420 bit is set. 422 0 - Reserved 423 1 - Simple Password 424 2 - Keyed MD5 425 3 - Meticulous Keyed MD5 426 4-255 - Reserved for future use 428 Auth Len 430 The length, in bytes, of the authentication section, including the 431 Auth Type and Auth Len fields. 433 4.2. Simple Password Authentication Section Format 435 If the Autentication Present (A) bit is set in the header, and the 436 Authentication Type field contains 1 (Simple Password), the 437 Authentication Section has the following format: 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Auth Type | Auth Len | Auth Key ID | Password... | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | ... | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 Auth Type 449 The Authentication Type, which in this case is 1 (Simple 450 Password.) 452 Auth Len 454 The length of the Authentication Section, in bytes. For Simple 455 Password authentication, the length is equal to the password 456 length plus three. 458 Auth Key ID 460 The authentication key ID in use for this packet. This allows 461 multiple keys to be active simultaneously. 463 Password 465 The simple password in use on this session. The password MUST be 466 from 1 to 16 bytes in length. 468 4.3. Keyed MD5 and Meticulous Keyed MD5 Authentication Section Format 470 If the Authentication Present (A) bit is set in the header, and the 471 Authentication Type field contains 2 (Keyed MD5) or 3 (Meticulous 472 Keyed MD5), the Authentication Section has the following format: 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Auth Type | Auth Len | Auth Key ID | Reserved | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Sequence Number | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Auth Key/Checksum... | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | ... | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Auth Type 488 The Authentication Type, which in this case is 2 (Keyed MD5) or 3 489 (Meticulous Keyed MD5). 491 Auth Len 493 The length of the Authentication Section, in bytes. For Keyed MD5 494 and Meticulous Keyed MD5 authentication, the length is 24. 496 Auth Key ID 498 The authentication key ID in use for this packet. This allows 499 multiple keys to be active simultaneously. 501 Reserved 503 This byte must be set to zero on transmit, and ignored on receipt. 505 Sequence Number 507 The Sequence Number for this packet. For Keyed MD5 508 Authentication, this value is incremented periodically. For 509 Meticulous Keyed MD5 Authentication, this value is incremented for 510 each successive packet transmitted for a session. This provides 511 protection against replay attacks. 513 Auth Key/Checksum 515 This field carries the 16 byte MD5 checksum for the packet. When 516 the checksum is calculated, the shared MD5 key is stored in this 517 field. (See section 6.5.2 for details.) 519 5. BFD Echo Packet Format 521 BFD Echo packets are sent in an encapsulation appropriate to the 522 environment. See the appropriate application document for the 523 specifics of particular environments. 525 The payload of a BFD Echo packet is a local matter, since only the 526 sending system ever processes the content. The only requirement is 527 that sufficient information is included to demultiplex the received 528 packet to the correct BFD session after it is looped back to the 529 sender. The contents are otherwise outside the scope of this 530 specification. 532 6. Elements of Procedure 534 This section discusses the normative requirements of the protocol in 535 order to achieve interoperability. It is important for implementors 536 to enforce only the requirements specified in this section, as 537 misguided pedantry has been proven by experience to adversely affect 538 interoperability. 540 Remember that all references of the form "bfd.Xx" refer to internal 541 state variables (defined in section 6.6.1), whereas all references to 542 "the Xxx field" refer to fields in the protocol packets themselves 543 (defined in section 4). 545 6.1. Overview 547 A system may take either an Active role or a Passive role in session 548 initialization. A system taking the Active role MUST send BFD 549 Control packets for a particular session, regardless of whether it 550 has received any BFD packets for that session. A system taking the 551 Passive role MUST NOT begin sending BFD packets for a particular 552 session until it has received a BFD packet for that session, and thus 553 has learned the remote system's discriminator value. At least one 554 system MUST take the Active role (possibly both.) The role that a 555 system takes is specific to the application of BFD, and is outside 556 the scope of this specification. 558 A session begins with the periodic, slow transmission of BFD Control 559 packets. When bidirectional communication is achieved (by virtue of 560 the I Hear You field being nonzero in both directions, a three way 561 handshake), the BFD session comes up. 563 Once the BFD session is Up, a system can choose to start the Echo 564 function if it desires to and the other system signals that it will 565 allow it. The rate of transmission of Control packets is typically 566 kept low when the Echo function is active. 568 If the Echo function is not active, the transmission rate of Control 569 packets may be increased to a level necessary to achieve the 570 detection time requirements for the session. 572 If both systems signal that they want to use Demand mode, the 573 transmission of BFD Control packets ceases once the session is Up. 574 Other means of implying connectivity are used to keep the session 575 alive. If one of the systems wishes to verify connectivity, it can 576 initiate a short exchange (a "Poll Sequence") of BFD Control packets 577 to verify this. 579 If Demand mode is not active, and no Control packets are received in 580 the calculated detection time (see section 6.6.4), the session is 581 declared down, and signalled to the remote end by sending a zero 582 value in the I Hear You field in outgoing packets. 584 If sufficient Echo packets are lost, the session is declared down in 585 the same manner. 587 If Demand mode is active and no appropriate Control packets are 588 received in response to a Poll Sequence, the session is declared down 589 in the same manner. 591 If the session goes down, the transmission of Echo packets (if any) 592 ceases, and the transmission of Control packets goes back to the slow 593 rate. 595 Once a session has been declared down, it cannot come back up until 596 the remote end first signals that it is down (by setting its outgoing 597 I Hear You field to zero), thus implementing a three-way handshake. 599 A session may be kept administratively down by always setting its 600 outgoing I Hear You field to zero, and sending an explanatory 601 diagnostic code in the Diagnostic field. 603 6.2. Demultiplexing and the Discriminator Fields 605 Since multiple BFD sessions may be running between two systems, there 606 needs to be a mechanism for demultiplexing received BFD packets to 607 the proper session. 609 Each system MUST choose an opaque discriminator value that identifies 610 each session, and which MUST be unique among all BFD sessions on the 611 system. The local discriminator is sent in the My Discriminator 612 field in the BFD Control packet, and is echoed back in the Your 613 Discriminator field of packets sent from the remote end. 615 Once the remote end echoes back the local discriminator, all further 616 received packets are demultiplexed based on the Your Discriminator 617 field only (which means that, among other things, the source address 618 field can change or the interface over which the packets are received 619 can change, but the packets will still be associated with the proper 620 session.) 622 The method of demultiplexing the initial packets (in which Your 623 Discriminator is zero) is application-dependent, and is thus outside 624 the scope of this specification. 626 Note that it is permissible for a system to change its discriminator 627 during a session (without affecting the session state), since only 628 that system uses its discriminator for demultiplexing purposes (by 629 having the other system reflect it back.) The implications on an 630 implementation for changing the discriminator value is outside the 631 scope of this specification. 633 6.3. The Echo Function and Asymmetry 635 The Echo function can be run independently in each direction between 636 a pair of systems. For whatever reason, a system may advertise that 637 it is willing to receive (and loop back) Echo packets, but may not 638 wish to ever send any. The fact that a system is sending Echo 639 packets is not directly signalled to the system looping them back. 641 When a system is using the Echo function, it is advantageous to 642 choose a sedate transmission rate for Control packets, since liveness 643 detection is being handled by the Echo packets. This can be 644 controlled by manipulating the Desired Min TX Interval field (see 645 section 6.6.3.) 646 If the Echo function is only being run in one direction, the system 647 not running the Echo function will more likely wish to send fairly 648 rapid Control packets in order to achieve its desired detection time. 649 Since BFD allows independent transmission rates in each direction, 650 this is easily accomplished. 652 A system SHOULD always advertise the lowest value of Required Min RX 653 Interval and Required Min Echo RX Interval that it can under the 654 circumstances, to give the other system more freedom in choosing its 655 transmission rate. Note that a system is committing to be able to 656 receive both streams of packets at the rate it advertises, so this 657 should be taken into account when choosing the values to advertise. 659 6.4. Demand Mode 661 Demand mode is negotiated by virtue of both systems setting the 662 Demand (D) bit in its BFD Control packets. Both systems must request 663 Demand mode for it to become active. 665 Demand mode requires that some other mechanism is used to imply 666 continuing connectivity between the two systems. The mechanism used 667 does not have to be the same in both directions, and is outside of 668 the scope of this specification. One possible mechanism is the 669 receipt of traffic from the remote system; another is the use of the 670 Echo function. 672 Once a BFD session comes up, if Demand mode is active, both systems 673 stop sending periodic BFD Control packets, and depend on the 674 alternative mechanism for maintaining ongoing connectivity. 676 When a system wishes to verify connectivity, it initiates a Poll 677 Sequence. It starts periodically sending BFD Control packets with 678 the Poll (P) bit set, at the negotiated transmission rate. When a 679 system receives such a packet, it immediately replies with a BFD 680 Control packet of its own, with the Poll (P) bit clear, and the Final 681 (F) bit set. The receipt of a reply to a Poll terminates the Poll 682 Sequence. If no response is received to a Poll, the Poll is repeated 683 until the detection time expires, at which point the session is 684 declared to be down. 686 The detection time in Demand mode is calculated differently than in 687 Asynchronous mode; it is based on the transmit rate of the local 688 system, rather than the transmit rate of the remote system. This 689 ensures that the Poll Sequence mechanism works properly. See section 690 6.6.8 for more details. 692 Note that this mechanism requires that the detection time negotiated 693 is greater than the round trip time between the two systems, or the 694 Poll mechanism will always fail. Enforcement of this requirement is 695 outside the scope of this specification. 697 Demand mode MAY be enabled or disabled at any time by setting or 698 clearing the Demand (D) bit in the BFD Control packet, without 699 affecting the BFD session state. 701 Because the underlying detection mechanism is unspecified, and may 702 differ between the two systems, the overall detection time 703 characteristics of the path will not be fully known to either system. 704 The total detection time for a particular system is the sum of the 705 time prior to the initiation of the Poll Sequence, plus the 706 calculated detection time. 708 6.5. Authentication 710 An optional Authentication Section may be present in the BFD Control 711 packet. In its generic form, the purpose of the Authentication 712 Section is to carry all necessary information, based on the 713 authentication type in use, to allow the receiving system to 714 determine the validity of the received packet. The exact mechanism 715 depends on the authentication type in use, but in general the 716 transmitting system will put information in the Authentication 717 Section that vouches for the packet's validity, and the receiving 718 system will examine the Authentication Section and either accept the 719 packet for further processing, or discard it. 721 Note that in the subsections below, to "accept" a packet means only 722 that the packet has passed authentication; it may in fact be 723 discarded for other reasons as described in the general packet 724 reception rules described in section 6.6.6. 726 6.5.1. Simple Password Authentication 728 The most straightforward (and weakest) form of authentication is 729 Simple Password Authentication. In this method of authentication, 730 one or more Passwords (with corresponding Key IDs) are configured in 731 each system and one of these Password/ID pairs is carried in each BFD 732 Control packet. The receiving system accepts the packet if the 733 Password and Key ID matches one of the Password/ID pairs configured 734 in that system. 736 Transmission Using Simple Password Authentication 738 The currently selected password and Key ID for the session MUST be 739 stored in the Authentication Section of each outgoing BFD Control 740 packet. The Auth Type field MUST be set to 1 (Simple Password.) 741 The Auth Len field MUST be set to the proper length (4 to 19 742 bytes.) 744 Reception Using Simple Password Authentication 746 If the received BFD Control packet does not contain an 747 Authentication Section, or the Auth Type is not 1 (Simple 748 Password), then the received packet MUST be discarded. 750 If the Auth Key ID field does not match the ID of a configured 751 password, the received packet MUST be discarded. 753 If the Auth Len field is not equal to the length of the password 754 selected by the Key ID, plus three, the packet MUST be discarded. 756 If the Password field does not match the password selected by the 757 Key ID, the packet MUST be discarded. 759 Otherwise, the packet MUST be accepted. 761 6.5.2. Keyed MD5 and Meticulous Keyed MD5 Authentication 763 The Keyed MD5 and Meticulous Keyed MD5 Authentication mechanisms are 764 very similar to those used in other protocols. In these methods of 765 authentication, one or more secret keys (with corresponding Key IDs) 766 are configured in each system. One of the Keys is included in an MD5 767 checksum calculated over the outgoing BFD Control packet, but the Key 768 itself is not carried in the packet. To help avoid replay attacks, a 769 sequence number is also carried in each packet. For Keyed MD5, the 770 sequence number is occasionally incremented. For Meticulous Keyed 771 MD5, the sequence number is incremented on every packet. 773 The receiving system accepts the packet if the Key ID matches one of 774 the configured Keys, an MD5 checksum including the selected key 775 matches that carried in the packet, and if the sequence number is 776 greater than or equal to the last sequence number received (for Keyed 777 MD5), or strictly greater than the last sequence number received (for 778 Meticulous Keyed MD5.) 779 Transmission Using Keyed MD5 and Meticulous Keyed MD5 Authentication 781 The Auth Type field MUST be set to 2 (Keyed MD5) or 3 (Meticulous 782 Keyed MD5.) The Auth Len field MUST be set to 24. The Auth Key 783 ID field MUST be set to the ID of the current authentication key. 784 The Sequence Number field MUST be set to bfd.XmitMD5Seq. 786 The current authentication key value MUST be placed into the Auth 787 Key/Checksum field. An MD5 checksum MUST be calculated over the 788 entire BFD control packet. The resulting checksum MUST be stored 789 in the Auth Key/Checksum field prior to transmission (replacing 790 the secret key, which MUST NOT be carried in the packet.) 792 For Keyed MD5, bfd.XmitMD5Seq MAY be incremented in a circular 793 fashion (when treated as an unsigned 32 bit value.) 794 bfd.XmitMD5Seq SHOULD be incremented when the session state 795 changes, or when the transmitted BFD Control packet carries 796 different contents than the previously transmitted packet. The 797 decision as to when to increment bfd.XmitMD5Seq is outside the 798 scope of this specification. See the section entitled "Security 799 Considerations" below for a discussion. 801 For Meticulous Keyed MD5, bfd.XmitMD5Seq MUST be incremented in a 802 circular fashion (when treated as an unsigned 32 bit value.) 804 Receipt Using Keyed MD5 and Meticulous Keyed MD5 Authentication 806 If the received BFD Control packet does not contain an 807 Authentication Section, or the Auth Type is not correct (2 for 808 Keyed MD5, or 3 for Meticulous Keyed MD5), then the received 809 packet MUST be discarded. 811 If the Auth Key ID field does not match the ID of a configured 812 authentication key, the received packet MUST be discarded. 814 If the Auth Len field is not equal to 24, the packet MUST be 815 discarded. 817 Replace the contents of the Auth Key/Checksum field with the 818 authentication key selected by the received Auth Key ID field. If 819 the MD5 checksum of the entire BFD Control packet is not equal to 820 the received value of the Auth Key/Checksum field, the received 821 packet MUST be discarded. 823 If bfd.MD5SeqKnown is 1, examine the Sequence Number field. For 824 Keyed MD5, if the Sequence Number lies outside of the range of 825 bfd.RcvMD5Seq to bfd.RcvMD5Seq+(3*Detect Mult) inclusive (when 826 treated as an unsigned 32 bit circular number space), the received 827 packet MUST be discarded. For Meticulous Keyed MD5, if the 828 Sequence Number lies outside of the range of bfd.RcvMD5Seq+1 to 829 bfd.RcvMD5Seq+(3*Detect Mult) inclusive (when treated as an 830 unsigned 32 bit circular number space, the received packet MUST be 831 discarded. 833 Otherwise (bfd.MD5SeqKnown is 0), bfd.MD5SeqKnown MUST be set to 834 1, bfd.RcvMD5Seq MUST be set to the value of the received Sequence 835 Number field, and the received packet MUST be accepted. 837 6.6. Functional Specifics 839 The following section of this specification is normative. The means 840 by which this specification is achieved is outside the scope of this 841 specification. 843 When a system is said to have "the Echo function active," it means 844 that the system is sending BFD Echo packets, implying that the 845 session is Up and the other system has signalled its willingness to 846 loop back Echo packets. 848 When a system is said to have "Demand mode active," it means that 849 bfd.DemandModeDesired is 1 in the local system (see State Variables 850 below), the remote system is signalling with the Demand (D) bit set, 851 and that the session is Up. 853 6.6.1. State Variables 855 A minimum amount of information about a session needs to be tracked 856 in order to achieve the elements of procedure described here. The 857 following is a set of state variables that are helpful in describing 858 the mechanisms of BFD. Any means of tracking this state may be used 859 so long as the protocol behaves as described. 861 All state variables in this specification are of the form "bfd.Xx" 862 and should not be confused with fields carried in the protocol 863 packets, which are always spelled out to match the names in section 864 4. 866 bfd.SessionState 868 The perceived state of the session (Init, Up, Failing, Down, or 869 AdminDown.) The exact action taken when the session state 870 changes is outside the scope of this specification, though it 871 is expected that this state change (particularly to and from Up 872 state) is reported to other components of the system. This 873 variable MUST be initialized to Failing. 875 bfd.LocalDiscr 877 The local discriminator for this BFD session, used to uniquely 878 identify it. It MUST be unique on this system, and nonzero. 879 It MAY be set to a random (but still unique) value to improve 880 security. The value is otherwise outside the scope of this 881 specification. 883 bfd.RemoteDiscr 885 The remote discriminator for this BFD session. This is the 886 discriminator chosen by the remote system, and is totally 887 opaque to the local system. This MUST be initialized to zero. 889 bfd.RemoteHeard 891 This variable is set to 1 if the local system is actively 892 receiving BFD packets from the remote system, and is set to 0 893 if the local system has not received BFD packets recently 894 (within the detection time) or if the local system is 895 attempting to tear down the BFD session. This MUST be 896 initialized to zero. 898 bfd.LocalDiag 900 The diagnostic code specifying the reason the local session 901 state most recently transitioned from Up to some other state. 902 This MUST be initialized to zero (No Diagnostic.) 904 bfd.DesiredMinTxInterval 906 The minimum interval, in microseconds, between transmitted BFD 907 Control packets that this system would like to use at the 908 current time. The actual interval is negotiated between the 909 two systems. This MUST be initialized to a value of at least 910 one second (1,000,000 microseconds) according to the rules 911 described in section 6.6.3. The setting of this variable is 912 otherwise outside the scope of this specification. 914 bfd.RequiredMinRxInterval 916 The minimum interval, in microseconds, between received BFD 917 Control packets that this system requires. The setting of this 918 variable is outside the scope of this specification. 920 bfd.DemandModeDesired 922 Set to 1 if the local system wishes to use Demand mode, or 0 if 923 not. 925 bfd.DetectMult 927 The desired detect time multiplier for BFD Control packets. 928 The negotiated Control packet transmission interval, multiplied 929 by this variable, will be the detection time for this session 930 (as seen by the remote system.) This variable MUST be a 931 nonzero integer, and is otherwise outside the scope of this 932 specification. See section 6.6.4 for further information. 934 bfd.AuthType 936 The authentication type in use for this session, as defined in 937 section 4.1, or zero if no authentication is in use. 939 bfd.RcvMD5Seq 941 A 32 bit unsigned integer containing the next sequence number 942 for keyed MD5 authentication expected to be received. The 943 initial value is unimportant. 945 bfd.XmitMD5Seq 947 A 32 bit unsigned integer containing the next sequence number 948 for keyed MD5 authentication to be transmitted. This variable 949 MUST be initialized to a random 32 bit value. 951 bfd.MD5SeqKnown 953 Set to 1 if the next sequence number for keyed MD5 954 authentication expected to be received is known, or 0 if it is 955 not known. This variable MUST be initialized to zero. 957 This variable MUST be set to zero after no packets have been 958 received on this session for at least twice the Detection Time. 959 This ensures that the MD5 sequence number can be resynchronized 960 if the remote system restarts. 962 6.6.2. Timer Negotiation 964 The time values used to determine BFD packet transmission intervals 965 and the session detection time are continuously negotiated, and thus 966 may be changed at any time. The negotiation and time values are 967 independent in each direction for each session. Packets are always 968 periodically transmitted in Asynchronous mode, and are periodically 969 transmitted during Poll Sequences when in Demand mode. 971 Each system reports in the BFD Control packet how rapidly it would 972 like to transmit BFD packets, as well as how rapidly it is prepared 973 to receive them. With the exceptions listed in the remainder of this 974 section, a system MUST NOT transmit BFD Control packets with an 975 interval less than the larger of bfd.DesiredMinTxInterval and the 976 received Required Min RX Interval field. In other words, the system 977 reporting the slower rate determines the transmission rate. 979 The periodic transmission of BFD Control packets SHOULD be jittered 980 by up to 25%, that is, the interval SHOULD be reduced by a random 981 value of 0 to 25%, in order to avoid self-synchronization. Thus, the 982 average interval between packets may be up to 12.5% less than that 983 negotiated. 985 If bfd.DetectMult is equal to 1, the interval between transmitted BFD 986 Control packets MUST be no more than 90% of the negotiated 987 transmission interval, and MUST be no less than 75% of the negotiated 988 transmission interval. This is to ensure that, on the remote system, 989 the calculated DetectTime does not pass prior to the receipt of the 990 next BFD Control packet. 992 An extra, single BFD Control packet SHOULD be transmitted during the 993 interval between periodic Control packet transmissions if there is a 994 state change that needs to be communicated, in order to more rapidly 995 converge. (For example, if the local system determines that the BFD 996 session has gone down, it SHOULD communicate this without waiting for 997 the next periodic transmission.) With the exception listed in the 998 next paragraph, once such an extra packet has been transmitted, a 999 system MUST NOT send another BFD Control packet until the next 1000 scheduled transmission. 1002 If a BFD Control packet is received with the Poll (P) bit set to 1, 1003 the receiving system MUST transmit a BFD Control packet with the Poll 1004 (P) bit clear and the Final (F) bit set as soon as practicable, 1005 without respect to the transmission timer or any other transmission 1006 limitations, and without respect to whether Demand mode is active. 1008 6.6.3. Timer Manipulation 1010 The time values used to determine BFD packet transmission intervals 1011 and the session detection time may be modified at any time without 1012 affecting the state of the session. When the timer parameters are 1013 changed for any reason, the requirements of this section apply. 1015 If Demand mode is active, and either bfd.DesiredMinTxInterval is 1016 changed or bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST 1017 be initiated (see section 6.6.8). 1019 If Demand mode is not active, and either bfd.DesiredMinTxInterval is 1020 changed or bfd.RequiredMinRxInterval is changed, all subsequent 1021 transmitted Control packets MUST be sent with the Poll (P) bit set 1022 until a packet is received with the Final (F) bit set. 1024 If bfd.DesiredMinTxInterval is increased, the actual transmission 1025 interval used MUST NOT change until a Control packet is received with 1026 the Final (F) bit set. This is to ensure that the remote system 1027 updates its Detect Time before the transmission interval increases. 1029 If bfd.RequiredMinRxInterval is reduced, the calculated detection 1030 time for the remote system MUST NOT change until a Control packet is 1031 received with the Final (F) bit set. This is to ensure that the 1032 remote system is transmitting packets at the higher rate (and those 1033 packets are being received) prior to the detection time being 1034 reduced. 1036 When bfd.SessionState is not Up, the system MUST set 1037 bfd.DesiredMinTxInterval to a value of not less than one second 1038 (1,000,000 microseconds.) This is intended to ensure that the 1039 bandwidth consumed by BFD sessions that are not Up is negligible, 1040 particularly in the case where a neighbor may not be running BFD. 1042 When the Echo function is active, a system SHOULD set 1043 bfd.DesiredMinTxInterval to a value of not less than one second 1044 (1,000,000 microseconds.) This is intended to keep BFD Control 1045 traffic at a negligible level, since the actual detection function is 1046 being performed using BFD Echo packets. 1048 6.6.4. Calculating the Detection Time 1050 The Detection Time (the period of time without receiving BFD packets 1051 after which the session is determined to have failed) is not carried 1052 explicitly in the protocol. Rather, it is calculated independently 1053 in each direction by the receiving system based on the negotiated 1054 transmit interval and the detection multiplier. Note that, in 1055 Asynchronous mode, there may be different detection times in each 1056 direction. 1058 The calculation of the Detection Time is slightly different when in 1059 Demand mode versus Asynchronous mode. 1061 In Asynchronous mode, the Detection Time calculated in the local 1062 system is equal to the value of Detect Mult received from the remote 1063 system, multiplied by the agreed transmit interval (the greater of 1064 bfd.RequiredMinRxInterval and the last received Desired Min TX 1065 Interval.) The Detect Mult value is (roughly speaking, due to 1066 jitter) the number of packets that have to be missed in a row to 1067 declare the session to be down. 1069 If Demand mode is not active, and a period of time equal to the 1070 Detection Time passes without receiving a BFD Control packet from the 1071 remote system, and bfd.SessionState is Init or Up, the session has 1072 gone down--the local system MUST set bfd.SessionState to Failing, 1073 bfd.RemoteHeard to zero, and bfd.LocalDiag to 1 (Control Detection 1074 Time Expired.) The timeout in Init state is to avoid a potential 1075 deadlock in which one system is in Failing state and the other is in 1076 Init state (which could happen if a packet were lost at the right 1077 time.) 1079 In Demand mode, the Detection Time calculated in the local system is 1080 equal to bfd.DetectMult, multiplied by the agreed transmit interval 1081 (the greater of bfd.RequiredMinRxInterval and the last received 1082 Desired Min TX Interval.) bfd.DetectMult is (roughly speaking, due 1083 to jitter) the number of packets that have to be missed in a row to 1084 declare the session to be down. 1086 If Demand mode is active, and a period of time equal to the Detection 1087 Time passes after the initiation of a Poll Sequence (the transmission 1088 of the first BFD Control packet with the Poll bit set), the session 1089 has gone down--the local system MUST set bfd.SessionState to Failing, 1090 bfd.RemoteHeard to zero, and bfd.LocalDiag to 1 (Control Detection 1091 Time Expired.) 1093 (Note that a packet is considered to have been received, for the 1094 purposes of Detection Time expiration, only if it has not been 1095 "discarded" according to the rules of section 6.6.6.) 1097 6.6.5. Detecting Failures with the Echo Function 1099 When the Echo function is active and a sufficient number of Echo 1100 packets have not arrived as they should, the session has gone 1101 down--the local system MUST set bfd.SessionState to Failing, 1102 bfd.RemoteHeard to zero, and bfd.LocalDiag to 2 (The Echo Function 1103 Failed.) 1105 The means by which the Echo function failures are detected is outside 1106 of the scope of this specification. Any means which will detect a 1107 communication failure is acceptable. 1109 6.6.6. Reception of BFD Control Packets 1111 When a BFD Control packet is received, the following procedure MUST 1112 be followed, in the order specified. If the packet is discarded 1113 according to these rules, processing of the packet MUST cease at that 1114 point. 1116 If the version number is not correct (0), the packet MUST be 1117 discarded. 1119 If the Length field is less than the minimum correct value (24 if 1120 the A bit is clear, or 26 if the A bit is set), the packet MUST be 1121 discarded. 1123 If the Length field is greater than the payload of the 1124 encapsulating protocol, the packet MUST be discarded. 1126 If the Detect Mult field is zero, the packet MUST be discarded. 1128 If the My Discriminator field is zero, the packet MUST be 1129 discarded. 1131 If the Your Discriminator field is nonzero, it MUST be used to 1132 select the session with which this BFD packet is associated. If 1133 no session is found, the packet MUST be discarded. 1135 If the Your Discriminator field is zero and the I Hear You field 1136 is nonzero, the packet MUST be discarded. 1138 If the Your Discriminator field is zero, the session MUST be 1139 selected based on some combination of other fields, possibly 1140 including source addressing information, the My Discriminator 1141 field, and the interface over which the packet was received. The 1142 exact method of selection is application-specific and is thus 1143 outside the scope of this specification. If a matching session is 1144 not found, a new session may be created, or the packet may be 1145 discarded. This choice is outside the scope of this 1146 specification. 1148 If the A bit is set and no authentication is in use (bfd.AuthType 1149 is zero), the packet MUST be discarded. 1151 If the A bit is clear and authentication is in use (bfd.AuthType 1152 is nonzero), the packet MUST be discarded. 1154 If the A bit is set, the packet MUST be authenticated under the 1155 rules of section 6.5, based on the authentication type in use 1156 (bfd.AuthType.) This may cause the packet to be discarded. 1158 Set bfd.RemoteDiscr to the value of My Discriminator. 1160 If the Required Min Echo RX Interval field is zero, the 1161 transmission of Echo packets, if any, MUST cease. 1163 If Demand mode is active, a Poll Sequence is being transmitted by 1164 the local system, and the Final (F) bit in the received packet is 1165 set, the Poll Sequence MUST be terminated. 1167 If Demand mode is not active, the Final (F) bit in the received 1168 packet is set, and the local system has been transmitting packets 1169 with the Poll (P) bit set, the Poll (P) bit MUST be set to zero in 1170 subsequent transmitted packets. 1172 Update the Detection Time as described in section 6.6.4. 1174 If bfd.SessionState is Down 1175 Set bfd.RemoteHeard to 1 1176 If I Hear You is zero 1177 Set bfd.SessionState to Init 1178 Else 1179 Set bfd.SessionState to Up 1181 Else if bfd.SessionState is AdminDown 1182 Discard the packet 1184 Else if bfd.SessionState is Init 1185 If I Hear You is nonzero 1186 Set bfd.SessionState to Up 1187 Else 1188 Discard the packet 1190 Else if bfd.SessionState is Up 1191 If I Hear You is zero 1192 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 1193 Set bfd.SessionState to Failing 1194 Set bfd.RemoteHeard to 0 1196 Else if bfd.SessionState is Failing 1197 If I Hear You is zero, set bfd.SessionState to Down 1199 Update the transmit interval as described in section 6.6.2. 1201 If the Demand (D) bit is set and bfd.DemandModeDesired is 1, 1202 and bfd.SessionState is Up, Demand mode is active. 1204 If the Demand (D) bit is clear or bfd.DemandModeDesired is 0, 1205 or bfd.SessionState is not Up, Demand mode is not 1206 active. 1208 If the Poll (P) bit is set, send a BFD Control packet to the 1209 remote system with the Poll (P) bit clear, and the Final (F) bit 1210 set. 1212 If the packet was not discarded, it has been received for purposes of 1213 the Detection Time expiration rules in section 6.6.4. 1215 6.6.7. Transmitting BFD Control Packets 1217 BFD Control packets MUST be transmitted periodically at the rate 1218 determined according to section 6.6.2, except as specified in this 1219 section. 1221 The transmit interval MUST be recalculated whenever 1222 bfd.DesiredMinTxInterval changes, or whenever the received Required 1223 Min RX Interval changes, and is equal to the greater of those two 1224 values. See sections 6.6.2 and 6.6.3 for details on transmit timers. 1226 A system MUST NOT transmit BFD Control packets if bfd.RemoteDiscr is 1227 zero and the system is taking the Passive role. 1229 A system MUST NOT periodically transmit BFD Control packets if Demand 1230 mode is active and a Poll Sequence is not being transmitted. 1232 A system MUST send a BFD Control packet in response to a received BFD 1233 Control Packet with the Poll (P) bit set. The packet sent in 1234 response MUST NOT have the Poll (P) bit set, and MUST have the Final 1235 (F) bit set. 1237 A single BFD Control packet SHOULD be transmitted between normally 1238 scheduled transmissions when the contents of that packet would differ 1239 from those in the previously transmitted packet (other than the Poll 1240 and Final bits) in order to more rapidly communicate a change in 1241 state. 1243 The contents of transmitted BFD Control packets MUST be set as 1244 follows: 1246 Version 1248 Set to the current version number (0). 1250 Diagnostic (Diag) 1252 Set to bfd.LocalDiag. 1254 I Hear You (H) 1256 Set to bfd.RemoteHeard. 1258 Demand (D) 1260 Set to bfd.DemandModeDesired. 1262 Poll (P) 1264 Set to 1 if the local system is sending a Poll Sequence or is 1265 required to do so according to the requirements of section 6.6.3, 1266 or 0 if not. 1268 Final (F) 1270 Set to 1 if the local system is responding to a Control packet 1271 received with the Poll (P) bit set, or 0 if not. 1273 Control Plane Independent (C) 1275 Set to 1 if the local system's BFD implementation is independent 1276 of the control plane (it can continue to function through a 1277 disruption of the control plane.) 1279 Authentication Present (A) 1281 Set to 1 if authentication is in use on this session (bfd.AuthType 1282 is nonzero), or 0 if not. 1284 Reserved (Rsvd) 1286 Set to 0. 1288 Detect Mult 1290 Set to bfd.DetectMult. 1292 Length 1294 Set to the appropriate length, based on the fixed header length 1295 (24) plus any Authentication Section. 1297 My Discriminator 1299 Set to bfd.LocalDiscr. 1301 Your Discriminator 1303 Set to bfd.RemoteDiscr. 1305 Desired Min TX Interval 1307 Set to bfd.DesiredMinTxInterval. 1309 Required Min RX Interval 1311 Set to bfd.RequiredMinRxInterval. 1313 Required Min Echo RX Interval 1315 Set to the minimum required Echo packet receive interval for this 1316 session. If this field is set to zero, the local system is 1317 unwilling or unable to loop back BFD Echo packets to the remote 1318 system, and the remote system will not send Echo packets. 1320 Authentication Section 1322 Included and set according to the rules in section 6.5 if 1323 authentication is in use (bfd.AuthType is nonzero.) Otherwise 1324 this section is not present. 1326 6.6.8. Initiation of a Poll Sequence 1328 If Demand mode is active, a Poll Sequence MUST be initiated whenever 1329 the contents of the next BFD Control packet to be sent would be 1330 different than the contents of the previous packet, with the 1331 exception of the Poll (P) and Final (F) bits. This ensures that 1332 parameter changes are transmitted to the remote system. Note that if 1333 the I Hear You (H) bit is changing to zero, the session is going down 1334 and Demand mode will no longer be active. 1336 If Demand mode is active, a Poll Sequence SHOULD be initiated 1337 whenever the system feels the need to verify connectivity with the 1338 remote system. The conditions under which this is desirable are 1339 outside the scope of this specification. 1341 If a Poll Sequence is being sent, and a new Poll Sequence is 1342 initiated due to one of the above conditions, the detection interval 1343 MUST be restarted in order to ensure that a full Poll Sequence is 1344 transmitted under the new conditions. 1346 6.6.9. Reception of BFD Echo Packets 1348 A received BFD Echo packet MUST be demultiplexed to the appropriate 1349 session for processing. A means of detecting missing Echo packets 1350 MUST be implemented, which most likely involves processing of the 1351 Echo packets that are received. The processing of received Echo 1352 packets is otherwise outside the scope of this specification. 1354 6.6.10. Transmission of BFD Echo Packets 1356 BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not 1357 Up. BFD Echo packets MUST NOT be transmitted unless the last BFD 1358 Control packet received from the remote system contains a nonzero 1359 value in Required Min Echo RX Interval. 1361 BFD Echo packets MAY be transmitted when bfd.SessionState is Up. The 1362 interval between transmitted BFD Echo packets MUST NOT be less than 1363 the value advertised by the remote system in Required Min Echo RX 1364 Interval, except as follows: 1366 A 25% jitter MAY be applied to the rate of transmission, such that 1367 the actual interval MAY be between 75% and 100% of the advertised 1368 value. A single BFD Echo packet MAY be transmitted between 1369 normally scheduled Echo transmission intervals. 1371 The transmission of BFD Echo packets is otherwise outside the scope 1372 of this specification. 1374 6.6.11. Min Rx Interval Change 1376 When it is desired to change the rate at which BFD Control packets 1377 arrive from the remote system, bfd.RequiredMinRxInterval can be 1378 changed at any time to any value. The new value will be transmitted 1379 in the next outgoing Control packet, and the remote system will 1380 adjust accordingly. See sections 6.6.3 and 6.6.8 for further 1381 requirements. 1383 6.6.12. Min Tx Interval Change 1385 When it is desired to change the rate at which BFD Control packets 1386 are transmitted to the remote system (subject to the requirements of 1387 the neighboring system), bfd.DesiredMinTxInterval can be changed at 1388 any time to any value. The rules in sections 6.6.3 and 6.6.8 apply. 1390 6.6.13. Detect Multiplier Change 1392 When it is desired to change the detect multiplier, the value of 1393 bfd.DetectMult can be changed to any nonzero value. The new value 1394 will be transmitted with the next BFD Control packet. See section 1395 6.6.8 for additional requirements. 1397 6.6.14. Enabling or Disabling The Echo Function 1399 If it is desired to start or stop the transmission of BFD Echo 1400 packets, this MAY be done at any time (subject to the transmission 1401 requirements detailed in section 6.6.10.) 1403 If it is desired to enable or disable the looping back of received 1404 BFD Echo packets, this MAY be done at any time by changing the value 1405 of Required Min RX Interval to zero or nonzero in outgoing BFD 1406 Control packets. 1408 6.6.15. Enabling or Disabling Demand Mode 1410 If it is desired to start or stop Demand mode, this MAY be done at 1411 any time by setting bfd.DemandModeDesired to the proper value. If 1412 Demand mode is no longer active, the system MUST begin transmitting 1413 periodic BFD Control packets as described in section 6.6.7. 1415 6.6.16. Forwarding Plane Reset 1417 When the forwarding plane in the local system is reset for some 1418 reason, such that the remote system can no longer rely on the local 1419 forwarding state, the local system MUST set bfd.LocalDiag to 4 1420 (Forwarding Plane Reset), set bfd.SessionState to Failing, and set 1421 bfd.RemoteHeard to zero. 1423 6.6.17. Administrative Control 1425 There may be circumstances where it is desirable to administratively 1426 enable or disable a BFD session. When this is desired, the following 1427 procedure MUST be followed: 1429 If enabling session 1430 Set bfd.SessionState to Failing 1431 Set bfd.RemoteHeard to zero 1433 Else 1434 Set bfd.SessionState to AdminDown 1435 Set bfd.RemoteHeard to zero 1436 Set bfd.LocalDiag to an appropriate value 1437 Cease the transmission of BFD Echo packets 1439 Specific diagnostic codes are provided for two scenarios. 1441 If signalling is received from outside BFD that the underlying path 1442 has failed, an implementation MAY adminstratively disable the session 1443 with the diagnostic Path Down. 1445 If the path being monitored by BFD is concatenated with other paths, 1446 it may be desirable to administratively bring down the BFD session 1447 when a concatenated path fails (as a way of propagating the 1448 failure indication.) In this case, an implementation MAY 1449 administratively disable the BFD session with the diagnostic 1450 Concatenated Path Down. 1452 Other scenarios MAY use the diagnostic Administratively Down. 1454 Contributors 1456 Kireeti Kompella and Yakov Rekhter of Juniper Networks were also 1457 significant contributors to this document. 1459 Acknowledgments 1461 This document was inspired by (and is intended to replace) the 1462 Protocol Liveness Protocol draft, written by Kireeti Kompella. 1464 Demand Mode was inspired by draft-ietf-ipsec-dpd-03.txt, by G. Huang 1465 et al. 1467 The authors would also like to thank Mike Shand, John Scudder, 1468 Stewart Bryant, and Pekka Savola for their substantive input. 1470 Security Considerations 1472 As BFD may be tied into the stability of the infrastructure (such as 1473 routing protocols), the effects of an attack on a BFD session may be 1474 very serious. This ultimately has denial-of-service effects, as 1475 links may be declared to be down (or falsely declared to be up.) 1477 When BFD is run over network layer protocols, a significant denial- 1478 of-service risk is created, as BFD packets may be trivial to spoof. 1479 When the session is directly connected across a single link 1480 (physical, or a secure tunnel such as IPsec), the TTL or Hop Count 1481 MUST be set to the maximum on transmit, and checked to be equal to 1482 the maximum value on reception (and the packet dropped if this is not 1483 the case.) See [GTSM] for mor information on this technique. If BFD 1484 is run across multiple hops or an insecure tunnel (such as GRE), the 1485 Authentication Section should be utilized. 1487 The level of security provided by the Authentication Section varies 1488 based on the authentication type used. Simple Password 1489 authentication is obviously only as secure as the secrecy of the 1490 passwords used, and should be considered only if the BFD session is 1491 guaranteed to be run over an infrastructure not subject to packet 1492 interception. Its chief advantage is that it minimizes the 1493 computational effort required for authentication. 1495 Keyed MD5 authentication is much stronger than Simple Password 1496 authentication since the keys cannot be discerned by intercepting 1497 packets. It is vulnerable to replay attacks in between increments of 1498 the sequence number. The sequence number can be incremented as 1499 seldom (or as often) as desired, trading off resistance to replay 1500 attacks with the computational effort required for authentication. 1502 Meticulous Keyed MD5 authentication is stronger yet, as it requires 1503 the sequence number to be incremented for every packet. Replay 1504 attack vulnerability is reduced due to the requirement that the 1505 sequence number must be incremented on every packet, the window size 1506 of acceptable packets is small, and the initial sequence number is 1507 randomized. There is still a window of attack at the beginning of 1508 the session while the sequence number is being determined. This 1509 authentication scheme requires an MD5 calculation on every packet 1510 transmitted and received. 1512 If both systems randomize their Local Discriminator values at the 1513 beginning of a session, replay attacks may be further mitigated, 1514 regardless of the authentication type in use. Since the Local 1515 Discriminator may be changed at any time during a session, this 1516 mechanism may also help mitigate attacks. 1518 Normative References 1520 [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism 1521 (GTSM)", RFC 3682, February 2004. 1523 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 1524 Requirement Levels", RFC 2119, March 1997. 1526 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1527 1992. 1529 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 1531 Authors' Addresses 1533 Dave Katz 1534 Juniper Networks 1535 1194 N. Mathilda Ave. 1536 Sunnyvale, California 94089-1206 USA 1537 Phone: +1-408-745-2000 1538 Email: dkatz@juniper.net 1540 Dave Ward 1541 Cisco Systems 1542 170 W. Tasman Dr. 1543 San Jose, CA 95134 USA 1544 Phone: +1-408-526-4000 1545 Email: dward@cisco.com 1547 Changes from the previous draft 1549 The primary technical change in this draft from the previous version 1550 is the addition of authentication. 1552 Otherwise, the changes in this draft from the previous version are 1553 cosmetic and/or editorial. 1555 IPR Notice 1557 The IETF has been notified of intellectual property rights claimed in 1558 regard to some or all of the specification contained in this 1559 document. For more information consult the online list of claimed 1560 rights. 1562 The IETF takes no position regarding the validity or scope of any 1563 intellectual property or other rights that might be claimed to 1564 pertain to the implementation or use of the technology described in 1565 this document or the extent to which any license under such rights 1566 might or might not be available; neither does it represent that it 1567 has made any effort to identify any such rights. Information on the 1568 IETF's procedures with respect to rights in standards-track and 1569 standards-related documentation can be found in BCP-11. Copies of 1570 claims of rights made available for publication and any assurances of 1571 licenses to be made available, or the result of an attempt made to 1572 obtain a general license or permission for the use of such 1573 proprietary rights by implementors or users of this specification can 1574 be obtained from the IETF Secretariat. 1576 The IETF invites any interested party to bring to its attention any 1577 copyrights, patents or patent applications, or other proprietary 1578 rights which may cover technology that may be required to practice 1579 this standard. Please address the information to the IETF Executive 1580 Director. 1582 Full Copyright Notice 1584 Copyright (C) The Internet Society (2004). All Rights Reserved. 1586 This document and translations of it may be copied and furnished to 1587 others, and derivative works that comment on or otherwise explain it 1588 or assist in its implementation may be prepared, copied, published 1589 and distributed, in whole or in part, without restriction of any 1590 kind, provided that the above copyright notice and this paragraph are 1591 included on all such copies and derivative works. However, this 1592 document itself may not be modified in any way, such as by removing 1593 the copyright notice or references to the Internet Society or other 1594 Internet organizations, except as needed for the purpose of 1595 developing Internet standards in which case the procedures for 1596 copyrights defined in the Internet Standards process must be 1597 followed, or as required to translate it into languages other than 1598 English. 1600 The limited permissions granted above are perpetual and will not be 1601 revoked by the Internet Society or its successors or assigns. 1603 This document and the information contained herein is provided on an 1604 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1605 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1606 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1607 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1608 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1610 Acknowledgement 1612 Funding for the RFC Editor function is currently provided by the 1613 Internet Society.