idnits 2.17.1 draft-ietf-bfd-v4v6-1hop-03.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 on line 472. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 443. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 450. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 456. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 460), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 50, but not defined == Unused Reference: 'KEYWORD' is defined on line 382, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-03 == Outdated reference: A later version (-09) exists of draft-ietf-bfd-multihop-03 ** Obsolete normative reference: RFC 3682 (ref. 'GTSM') (Obsoleted by RFC 5082) ** Obsolete normative reference: RFC 3847 (ref. 'ISIS-GRACE') (Obsoleted by RFC 5306) ** Obsolete normative reference: RFC 2740 (ref. 'OSPFv3') (Obsoleted by RFC 5340) Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 7 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: January, 2006 July, 2005 8 BFD for IPv4 and IPv6 (Single Hop) 9 draft-ietf-bfd-v4v6-1hop-03.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 Copyright Notice 36 Copyright (C) The Internet Society (2005). All Rights Reserved. 38 Abstract 40 This document describes the use of the Bidirectional Forwarding 41 Detection protocol over IPv4 and IPv6 for single IP hops. It further 42 describes the use of BFD with OSPFv2, OSPFv3, and IS-IS. Comments on 43 this draft should be directed to rtg-bfd@ietf.org. 45 Conventions used in this document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC-2119 [KEYWORDS]. 51 1. Introduction 53 One very desirable application for BFD [BFD] is to track IPv4 and 54 IPv6 connectivity between directly-connected systems. This could be 55 used to supplant the detection mechanisms in IS-IS and OSPF, or to 56 monitor router-host connectivity, among other applications. 58 This document describes the particulars necessary to use BFD in this 59 environment, and describes how BFD can be used in conjunction OSPFv2 60 [OSPFv2], OSPFv3 [OSPFv3], and IS-IS [ISIS]. 62 2. Applications and Limitations 64 This application of BFD can be used by any pair of systems 65 communicating via IPv4 and/or IPv6 across a single IP hop that can be 66 associated with an incoming interface. This includes, but is not 67 limited to, physical media, virtual circuits, and tunnels. 69 Each BFD session between a pair of systems MUST traverse a separate 70 path in both directions. 72 If BFD is to be used in conjunction with both IPv4 and IPv6 on a 73 particular link, a separate BFD session MUST be established for each 74 protocol (and thus encapsulated by that protocol) over that link. 76 3. Initialization and Demultiplexing 78 In this application, there will be only a single BFD session between 79 two systems over a given interface (logical or physical) for a 80 particular protocol. The BFD session must be bound to this 81 interface. As such, both sides of a session MUST take the "Active" 82 role (sending initial BFD Control packets with a zero value of Your 83 Discriminator) and any BFD packet from the remote machine with a zero 84 value of Your Discriminator MUST be associated with the session bound 85 to the remote system, interface, and protocol. 87 4. Encapsulation 89 4.1. BFD for IPv4 91 In the case of IPv4, BFD Control packets MUST be transmitted in UDP 92 packets with destination port 3784, within an IPv4 packet. The 93 source port MUST be in the range 49152 through 65535. The same UDP 94 source port number MUST be used for all BFD Control packets 95 associated with a particular session. The source port number SHOULD 96 be unique among all BFD sessions on the system. If more than 16384 97 BFD sessions are simultaneously active, UDP source port numbers MAY 98 be reused on multiple sessions, but the number of distinct uses of 99 the same UDP source port number SHOULD be minimized. An 100 implementation MAY use the UDP port source number to aid in 101 demultiplexing incoming BFD Control packets, but ultimately the 102 mechanisms in [BFD] MUST be used to demultiplex incoming packets to 103 the proper session. 105 BFD Echo packets MUST be transmitted in UDP packets with destination 106 UDP port 3785 in an IPv4 packet. The setting of the UDP source port 107 is outside the scope of this specification. The destination address 108 MUST be chosen in such a way as to cause the remote system to forward 109 the packet back to the local system. The source address MUST be 110 chosen in such a way as to preclude the remote system from generating 111 ICMP Redirect messages (in particular, the source address MUST NOT be 112 part of the subnet bound to the interface over which the BFD Echo 113 packet is being transmitted.) 115 4.2. BFD for IPv6 117 In the case of IPv6, BFD Control packets MUST be transmitted in UDP 118 packets with destination port 3784, within an IPv6 packet. The 119 source port MUST be in the range 49152 through 65535. The same UDP 120 source port number MUST be used for all BFD Control packets 121 associated with a particular session. The source port number SHOULD 122 be unique among all BFD sessions on the system. If more than 16384 123 BFD sessions are simultaneously active, UDP source port numbers MAY 124 be reused on multiple sessions, but the number of distinct uses of 125 the same UDP source port number SHOULD be minimized. An 126 implementation MAY use the UDP port source number to aid in 127 demultiplexing incoming BFD Control packets, but ultimately the 128 mechanisms in [BFD] MUST be used to demultiplex incoming packets to 129 the proper session. 131 BFD Echo packets MUST be transmitted in UDP packets with destination 132 UDP port 3785 in an IPv6 packet. The setting of the UDP source port 133 is outside the scope of this specification. The source and 134 destination addresses MUST both be associated with the local system. 135 The destination address MUST be chosen in such a way as to cause the 136 remote system to forward the packet back to the local system. 138 5. TTL/Hop Count Issues 140 If BFD authentication is not in use on a session, all BFD Control 141 packets for the session MUST be sent with a TTL or Hop Count value of 142 255. All received BFD Control packets that are demultiplexed to the 143 session MUST be discarded if the received TTL or Hop Count is not 144 equal to 255. A discussion of this mechanism can be found in [GTSM]. 146 If BFD authentication is in use on a session, all BFD Control packets 147 MUST be sent with a TTL or Hop Count value of 255. All received BFD 148 Control packets that are demultiplexed the session MAY be discarded 149 if the received TTL or Hop Count is not equal to 255. 151 In the context of this section, "authentication in use" means that 152 the system is sending BFD control packets with the Authentication bit 153 set and with the Authentication Section included, and that all 154 unauthenticated packets demultiplexed to the session are discarded, 155 per the BFD base specification. 157 6. Addressing Issues 159 On a subnetted network, BFD Control packets MUST be transmitted with 160 source and destination addresses that are part of the subnet 161 (addressed from and to interfaces on the subnet.) 163 On an addressed but unsubnetted point-to-point link, BFD Control 164 packets MUST be transmitted with source and destination addresses 165 that match the addresses configured on that link. 167 On an unnumbered point-to-point link, the source address of a BFD 168 Control packet MUST NOT be used to identify the session. This means 169 that the initial BFD packet MUST be accepted with any source address, 170 and that subsequent BFD packets MUST be demultiplexed solely by the 171 My Discriminator field (as is always the case.) This allows the 172 source address to change if necessary. If the received source 173 address changes, the local system MUST NOT use that address as the 174 destination in outgoing BFD Control packets; rather it MUST continue 175 to use the address configured at session creation. An implementation 176 MAY notify the application that the neighbor's source address has 177 changed, so that the application might choose to change the 178 destination address or take some other action. Note that the TTL/Hop 179 Count check described in section 5 (or the use of authentication) 180 precludes the BFD packets from having come from any source other than 181 the immediate neighbor. 183 7. BFD for use with OSPFv2, OSPFv3, and IS-IS 185 The two versions of OSPF, as well as IS-IS, all suffer from an 186 architectural limitation, namely that their Hello protocols are 187 limited in the granularity of failure their detection times. In 188 particular, OSPF has a minimum detection time of two seconds, and IS- 189 IS has a minimum detection time of one second. 191 BFD MAY be used to achieve arbitrarily small detection times for 192 these protocols by supplanting the Hello protocols used in each case. 194 It should be noted that the purpose of using BFD in this context is 195 not to replace the adjacency timeout mechanism, nor is it to 196 demonstrate that the network is fully functional for the use of the 197 routing protocol, but is simply to advise the routing protocol that 198 there are problems forwarding the data protocol for which the routing 199 protocol is calculating routes. 201 7.1. Session Establishment 203 The mechanism by which a BFD session is established in this 204 environment is outside the scope of this specification. An obvious 205 choice would be to use the discovery mechanism inherent in the Hello 206 protocols in OSPF and IS-IS to bootstrap the establishment of a BFD 207 session. 209 Any BFD sessions established to support OSPF and IS-IS across a 210 single IP hop MUST operate in accordance with the rest of this 211 document. 213 If multiple routing protocols wish to establish BFD sessions with the 214 same remote system for the same data protocol, all MUST share a 215 single BFD session. 217 7.2. Session Parameters 219 The setting of the various timing parameters and modes in this 220 application are outside the scope of this specification. 222 Note that all protocols sharing a session will operate using the same 223 parameters. The mechanism for choosing the parameters among those 224 desired by the various protocols are outside the scope of this 225 specification. 227 7.3. Interactions with OSPF and IS-IS without Graceful Restart 229 Slightly different mechanisms are used if the routing protocol 230 supports the routing of multiple data protocols, depending on whether 231 the routing protocol supports separate topologies for each data 232 protocol. With a shared topology, if one of the data protocols fails 233 (as signalled by the associated BFD session), it is necessary to 234 consider the path to have failed for all data protocols, since there 235 is otherwise no way for the routing protocol to turn away traffic for 236 the failed protocol (and such traffic would be black holed 237 indefinitely.) 239 With individual routing topologies for each data protocol, only the 240 failed data protocol needs to be rerouted around the failed path. 242 Therefore, when a BFD session transitions from Up to Down, action 243 SHOULD be taken in the routing protocol to signal the lack of 244 connectivity for the data protocol (IPv4 or IPv6) over which BFD is 245 running. If only one data protocol is being advertised in the 246 routing protocol Hello, or if multiple protocols are being advertised 247 but the protocols must share a common topology, a Hello protocol 248 timeout SHOULD be emulated for the associated OSPF neighbors and/or 249 IS-IS adjacencies. 251 If multiple data protocols are advertised in the routing protocol 252 Hello, and the routing protocol supports different topologies for 253 each data protocol, the failing data protocol SHOULD no longer be 254 advertised in Hello packets in order to signal a lack of connectivity 255 for that protocol. 257 Note that it is possible in some failure scenarios for the network to 258 be in a state such that the IGP comes up, but the BFD session cannot 259 be established, and, more particularly, data cannot be forwarded. To 260 avoid this situation, it would be beneficial to not allow the IGP to 261 establish a neighbor/adjacency. However, this would preclude the 262 operation of the IGP in an environment in which not all systems 263 support BFD. 265 Therefore, if a BFD session is not in Up state (possibly because the 266 remote system does not support BFD), it is OPTIONAL to preclude the 267 establishment of an OSPF neighbor or an IS-IS adjacency. The choice 268 of whether to do so SHOULD be controlled by means outside the scope 269 of this specification, such as configuration or other mechanisms. 271 7.4. Interactions with OSPF and IS-IS with Graceful Restart 273 The Graceful Restart functions in OSPF [OSPF-GRACE] and IS-IS [ISIS- 274 GRACE] are predicated on the existence of a separate forwarding plane 275 that does not necessarily share fate with the control plane in which 276 the routing protocols operate. In particular, the assumption is that 277 the forwarding plane can continue to function while the protocols 278 restart and sort things out. 280 BFD implementations announce via the Control Plane Independent (C) 281 bit whether or not BFD shares fate with the control plane. This 282 information is used to determine the actions to be taken in 283 conjunction with Graceful Restart. 285 If BFD does not share its fate with the control plane on either 286 system, it can be used to determine whether Graceful Restart is NOT 287 viable (the forwarding plane is not operating.) In this situation, 288 if a BFD session fails while graceful restart is taking place, and 289 BFD is independent of the control plane on the local system, and the 290 remote system has been transmitting BFD Control packets with the C 291 bit set, the graceful restart SHOULD be aborted and the topology 292 change made visible to the network as outlined in section 7.3. 294 If BFD shares its fate with the control plane on either system 295 (either the local system shares fate with the control plane, or the 296 remote system is transmitting BFD packets with the C bit set to 297 zero), it is not useful during graceful restart, as the BFD session 298 is likely to fail regardless of the state of the forwarding plane. 299 The action to take in this case depends on the capabilities of the 300 IGP. 302 7.4.1. OSPF Graceful Restart With Control Plane Fate Sharing 304 OSPF has a "planned" restart mechanism, in which the restarting 305 system notifies its neighbors that it is about to perform a restart. 306 In this situation, if a BFD session fails while the neighbor is 307 performing a graceful restart, the graceful restart SHOULD be allowed 308 to complete and the topology change should not be made visible to the 309 network as outlined in section 7.3. 311 For unplanned restarts (in which the neighbor has not notified the 312 local system of its intention to restart), the OSPF Graceful Restart 313 specification allows a Graceful Restart to take place if the system 314 restarts prior to the expiration of the OSPF neighbor relationship. 315 In this case, the BFD Detection Time is likely to expire prior to the 316 restart, and the neighbor relationship SHOULD be torn down. In the 317 unlikely event that the system restarts quickly enough, and the 318 system chooses to attempt a Graceful Restart, the graceful restart 319 SHOULD be allowed to complete and the topology change should not be 320 made visible to the network as outlined in section 7.3. 322 7.4.2. ISIS Graceful Restart With Control Plane Fate Sharing 324 ISIS Graceful Restart does not signal a "planned" restart; its 325 mechanism does not begin until after the system has restarted. If 326 the BFD session expires prior to the restart of the system, there is 327 no way for the neighbors to know that a Graceful Restart will take 328 place. 330 If a planned restart is about to place, the restarting system MAY 331 change the BFD timing parameters on a temporary basis in such a way 332 as to make the Detection Time greater than or equal to the ISIS 333 adjacency timeout. This will provide the restarting system the same 334 opportunity to enter Graceful Restart as it would have without BFD. 335 In this case, the restarted system SHOULD avoid sending any BFD 336 Control packets until there is a high likelihood that its neighbors 337 know it is performing a Graceful Restart, since the neighbors will 338 tear down their BFD sessions when those sessions restart. 340 In any case, if a BFD session fails while the neighbor is known to be 341 performing a Graceful Restart, the Graceful Restart SHOULD be allowed 342 to complete and the topology change should not be made visible to the 343 network as outlined in section 7.3. 345 If the BFD session fails, and it is not known whether the neighbor is 346 performing a Graceful Restart, the BFD session failure SHOULD be made 347 visible to the network as outlined in section 7.3. 349 7.5. OSPF Virtual Links 351 If it is desired to use BFD for failure detction of OSPF Virtual 352 Links, the mechanism described in [BFD-MULTI] MUST be used, since 353 OSPF Virtual Links may traverse an arbitrary number of hops. BFD 354 Authentication SHOULD be used and is strongly encouraged. 356 8. BFD for use with Tunnels 358 A number of mechanisms are available to tunnel IPv4 and IPv6 over 359 arbitrary topologies. If the tunnel mechanism does not decrement the 360 TTL or hop count of the network protocol carried within, the 361 mechanism described in this document may be used to provide liveness 362 detection for the tunnel. The BFD Authentication mechanism SHOULD be 363 used and is strongly encouraged. 365 Normative References 367 [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", 368 draft-ietf-bfd-base-03.txt, July, 2005. 370 [BFD-MULTI] Katz, D., and Ward, D., "BFD for Multihop Paths", draft- 371 ietf-bfd-multihop-03.txt, July, 2005. 373 [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism 374 (GTSM)", RFC 3682, February 2004. 376 [ISIS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual 377 environments", RFC 1195, December 1990. 379 [ISIS-GRACE] Shand, M., and Ginsberg, L., "Restart signaling for IS- 380 IS", RFC 3847, July 2004. 382 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", RFC 2119, March 1997. 385 [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 387 [OSPFv3] Coltun, R., et al, "OSPF for IPv6", RFC 2740, December 1999. 389 [OSPF-GRACE] Moy, J., et al, "Graceful OSPF Restart", RFC 3623, 390 November 2003. 392 Security Considerations 394 In this application, the use of TTL=255 on transmit and receive is 395 viewed as supplying equivalent security characteristics to other 396 protocols used in the infrastructure, as it is not trivially 397 spoofable. The security implications of this mechanism are further 398 discussed in [GTSM]. 400 The security implications of the use of BFD Authentication are 401 discussed in [BFD]. 403 The use of the TTL=255 check simultaneously with BFD Authentication 404 provides a low overhead mechanism for discarding a class of 405 unauthorized packets and may be useful in implementations in which 406 cryptographic checksum use is susceptable to denial of service 407 attacks. The use or non-use of this mechanism does not impact 408 interoperability. 410 IANA Considerations 412 This document has no actions for IANA. 414 Authors' Addresses 416 Dave Katz 417 Juniper Networks 418 1194 N. Mathilda Ave. 419 Sunnyvale, California 94089-1206 USA 420 Phone: +1-408-745-2000 421 Email: dkatz@juniper.net 423 Dave Ward 424 Cisco Systems 425 170 W. Tasman Dr. 426 San Jose, CA 95134 USA 427 Phone: +1-408-526-4000 428 Email: dward@cisco.com 430 Changes from the previous draft 432 All changes are editorial in nature. 434 IPR Disclaimer 436 The IETF takes no position regarding the validity or scope of any 437 Intellectual Property Rights or other rights that might be claimed to 438 pertain to the implementation or use of the technology described in 439 this document or the extent to which any license under such rights 440 might or might not be available; nor does it represent that it has 441 made any independent effort to identify any such rights. Information 442 on the procedures with respect to rights in RFC documents can be 443 found in BCP 78 and BCP 79. 445 Copies of IPR disclosures made to the IETF Secretariat and any 446 assurances of licenses to be made available, or the result of an 447 attempt made to obtain a general license or permission for the use of 448 such proprietary rights by implementers or users of this 449 specification can be obtained from the IETF on-line IPR repository at 450 http://www.ietf.org/ipr. 452 The IETF invites any interested party to bring to its attention any 453 copyrights, patents or patent applications, or other proprietary 454 rights that may cover technology that may be required to implement 455 this standard. Please address the information to the IETF at ietf- 456 ipr@ietf.org. 458 Full Copyright Notice 460 Copyright (C) The Internet Society (2005). 462 This document is subject to the rights, licenses and restrictions 463 contained in BCP 78, and except as set forth therein, the authors 464 retain all their rights. 466 This document and the information contained herein are provided on an 467 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 468 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 469 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 470 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 471 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 472 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 474 Acknowledgement 476 Funding for the RFC Editor function is currently provided by the 477 Internet Society. 479 This document expires in January, 2006.