idnits 2.17.1 draft-ietf-bfd-v4v6-1hop-01.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 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 413. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 405), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- ** 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.) 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 356, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-01 == Outdated reference: A later version (-09) exists of draft-ietf-bfd-multihop-01 ** 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: 13 errors (**), 0 flaws (~~), 6 warnings (==), 4 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: August, 2005 February, 2005 8 BFD for IPv4 and IPv6 (Single Hop) 9 draft-ietf-bfd-v4v6-1hop-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 or will be disclosed, and any of which I become aware will be 16 disclosed, in accordance with RFC 3668. 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, all BFD Control packets for 141 sessions operating according to this specification MUST be sent with 142 a TTL or Hop Count value of 255. All received BFD Control packets 143 that are demultiplexed to sessions operating according to this 144 specification MUST be discarded if the received TTL or Hop Count is 145 not equal to 255. A discussion of this mechanism can be found in 146 [GTSM]. 148 If BFD authentication is in use, any value of TTL/Hop Count MAY be 149 used in transmitted packets, and received packets MUST NOT be 150 discarded based on the received TTL/Hop Count. 152 6. Addressing Issues 154 On a subnetted network, BFD Control packets MUST be transmitted with 155 source and destination addresses that are part of the subnet 156 (addressed from and to interfaces on the subnet.) 158 On an addressed but unsubnetted point-to-point link, BFD Control 159 packets MUST be transmitted with source and destination addresses 160 that match the addresses configured on that link. 162 On an unnumbered point-to-point link, the source address of a BFD 163 Control packet MUST NOT be used to identify the session. This means 164 that the initial BFD packet MUST be accepted with any source address, 165 and that subsequent BFD packets MUST be demultiplexed solely by the 166 My Discriminator field (as is always the case.) This allows the 167 source address to change if necessary. Note that the TTL/Hop Count 168 check described in section 5 precludes the BFD packets from having 169 come from any source other than the immediate neighbor. 171 7. BFD for use with OSPFv2, OSPFv3, and IS-IS 173 The two versions of OSPF, as well as IS-IS, all suffer from an 174 architectural limitation, namely that their Hello protocols are 175 limited in the granularity of failure their detection times. In 176 particular, OSPF has a minimum detection time of two seconds, and IS- 177 IS has a minimum detection time of one second. 179 BFD MAY be used to achieve arbitrarily small detection times for 180 these protocols by supplanting the Hello protocols used in each case. 182 It should be noted that the purpose of using BFD in this context is 183 not to replace the adjacency timeout mechanism, nor is it to 184 demonstrate that the network is fully functional for the use of the 185 routing protocol, but is simply to advise the routing protocol that 186 there are problems forwarding the data protocol for which the routing 187 protocol is calculating routes. 189 7.1. Session Establishment 191 The mechanism by which a BFD session is established in this 192 environment is outside the scope of this specification. An obvious 193 choice would be to use the discovery mechanism inherent in the Hello 194 protocols in OSPF and IS-IS to bootstrap the establishment of a BFD 195 session. 197 Any BFD sessions established to support OSPF and IS-IS across a 198 single IP hop MUST operate in accordance with the rest of this 199 document. 201 If multiple routing protocols wish to establish BFD sessions with the 202 same remote system for the same data protocol, all MUST share a 203 single BFD session. 205 7.2. Session Parameters 207 The setting of the various timing parameters and modes in this 208 application are outside the scope of this specification. 210 Note that all protocols sharing a session will operate using the same 211 parameters. The mechanism for choosing the parameters among those 212 desired by the various protocols are outside the scope of this 213 specification. 215 7.3. Interactions with OSPF and IS-IS without Graceful Restart 217 When a BFD session transitions from Up to Failing, action SHOULD be 218 taken in the routing protocol to signal the lack of connectivity for 219 the data protocol (IPv4 or IPv6) over which BFD is running. If only 220 one data protocol is being advertised in the routing protocol Hello, 221 or if multiple protocols are being advertised but the protocols must 222 share a common topology, a Hello protocol timeout SHOULD be emulated 223 for the associated OSPF neighbors and/or IS-IS adjacencies. 225 If multiple data protocols are advertised in the routing protocol 226 Hello, and the routing protocol supports different topologies for 227 each data protocol, the failing data protocol SHOULD no longer be 228 advertised in Hello packets in order to signal a lack of connectivity 229 for that protocol. 231 Note that it is possible in some failure scenarios for the network to 232 be in a state such that the IGP comes up, but the BFD session cannot 233 be established, and, more particularly, data cannot be forwarded. To 234 avoid this situation, it would be beneficial to not allow the IGP to 235 establish a neighbor/adjacency. However, this would preclude the 236 operation of the IGP in an environment in which not all systems 237 support BFD. 239 Therefore, if a BFD session is not in Up state (possibly because the 240 remote system does not support BFD), it is OPTIONAL to preclude the 241 establishment of an OSPF neighbor or an IS-IS adjacency. The choice 242 of whether to do so SHOULD be controlled by means outside the scope 243 of this specification, such as configuration or other mechanisms. 245 7.4. Interactions with OSPF and IS-IS with Graceful Restart 247 The Graceful Restart functions in OSPF [OSPF-GRACE] and IS-IS [ISIS- 248 GRACE] are predicated on the existence of a separate forwarding plane 249 that does not necessarily share fate with the control plane in which 250 the routing protocols operate. In particular, the assumption is that 251 the forwarding plane can continue to function while the protocols 252 restart and sort things out. 254 BFD implementations announce via the Control Plane Independent (C) 255 bit whether or not BFD shares fate with the control plane. This 256 information is used to determine the actions to be taken in 257 conjunction with Graceful Restart. 259 If BFD does not share its fate with the control plane on either 260 system, it can be used to determine whether Graceful Restart is NOT 261 viable (the forwarding plane is not operating.) In this situation, 262 if a BFD session fails while graceful restart is taking place, and 263 BFD is independent of the control plane on the local system, and the 264 remote system has been transmitting BFD Control packets with the C 265 bit set, the graceful restart SHOULD be aborted and the topology 266 change made visible to the network as outlined in section 7.3. 268 If BFD shares its fate with the control plane on either system 269 (either the local system shares fate with the control plane, or the 270 remote system is transmitting BFD packets with the C bit set to 271 zero), it is not useful during graceful restart, as the BFD session 272 is likely to fail regardless of the state of the forwarding plane. 273 The action to take in this case depends on the capabilities of the 274 IGP. 276 7.4.1. OSPF Graceful Restart With Control Plane Fate Sharing 278 OSPF has a "planned" restart mechanism, in which the restarting 279 system notifies its neighbors that it is about to perform a restart. 280 In this situation, if a BFD session fails while the neighbor is 281 performing a graceful restart, the graceful restart SHOULD be allowed 282 to complete and the topology change should not be made visible to the 283 network as outlined in section 7.3. 285 For unplanned restarts (in which the neighbor has not notified the 286 local system of its intention to restart), the OSPF Graceful Restart 287 specification allows a Graceful Restart to take place if the system 288 restarts prior to the expiration of the OSPF neighbor relationship. 289 In this case, the BFD Detection Time is likely to expire prior to the 290 restart, and the neighbor relationship SHOULD be torn down. In the 291 unlikely event that the system restarts quickly enough, and the 292 system chooses to attempt a Graceful Restart, the graceful restart 293 SHOULD be allowed to complete and the topology change should not be 294 made visible to the network as outlined in section 7.3. 296 7.4.2. ISIS Graceful Restart With Control Plane Fate Sharing 298 ISIS Graceful Restart does not signal a "planned" restart; its 299 mechanism does not begin until after the system has restarted. If 300 the BFD session expires prior to the restart of the system, there is 301 no way for the neighbors to know that a Graceful Restart will take 302 place. 304 If a planned restart is about to place, the restarting system MAY 305 change the BFD timing parameters on a temporary basis in such a way 306 as to make the Detection Time greater than or equal to the ISIS 307 adjacency timeout. This will provide the restarting system the same 308 opportunity to enter Graceful Restart as it would have without BFD. 309 In this case, the restarted system SHOULD avoid sending any BFD 310 Control packets until there is a high likelihood that its neighbors 311 know it is performing a Graceful Restart, since the neighbors will 312 tear down their BFD sessions when those sessions restart. 314 In any case, if a BFD session fails while the neighbor is known to be 315 performing a Graceful Restart, the Graceful Restart SHOULD be allowed 316 to complete and the topology change should not be made visible to the 317 network as outlined in section 7.3. 319 If the BFD session fails, and it is not known whether the neighbor is 320 performing a Graceful Restart, the BFD session failure SHOULD be made 321 visible to the network as outlined in section 7.3. 323 7.5. OSPF Virtual Links 325 If it is desired to use BFD for failure detction of OSPF Virtual 326 Links, the mechanism described in [BFD-MULTI] MUST be used, since 327 OSPF Virtual Links may traverse an arbitrary number of hops. BFD 328 Authentication SHOULD be used and is strongly encouraged. 330 8. BFD for use with Tunnels 332 A number of mechanisms are available to tunnel IPv4 and IPv6 over 333 arbitrary topologies. If the tunnel mechanism does not decrement the 334 TTL or hop count of the network protocol carried within, the 335 mechanism described in this document may be used to provide liveness 336 detection for the tunnel. The BFD Authentication mechanism SHOULD be 337 used and is strongly encouraged. 339 Normative References 341 [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", 342 draft-ietf-bfd-base-01.txt, February, 2005. 344 [BFD-MULTI] Katz, D., and Ward, D., "BFD for Multihop Paths", draft- 345 ietf-bfd-multihop-01.txt, February, 2005. 347 [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism 348 (GTSM)", RFC 3682, February 2004. 350 [ISIS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual 351 environments", RFC 1195, December 1990. 353 [ISIS-GRACE] Shand, M., and Ginsberg, L., "Restart signaling for IS- 354 IS", RFC 3847, July 2004. 356 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", RFC 2119, March 1997. 359 [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 361 [OSPFv3] Coltun, R., et al, "OSPF for IPv6", RFC 2740, December 1999. 363 [OSPF-GRACE] Moy, J., et al, "Graceful OSPF Restart", RFC 3623, 364 November 2003. 366 Security Considerations 368 In this application, the use of TTL=255 on transmit and receive is 369 viewed as supplying equivalent security characteristics to other 370 protocols used in the infrastructure, as it is not trivially 371 spoofable. The security implications of this mechanism are further 372 discussed in the GTSM specification. 374 The security implications of the use of BFD Authentication are 375 discussed in the base BFD specification. 377 Authors' Addresses 379 Dave Katz 380 Juniper Networks 381 1194 N. Mathilda Ave. 382 Sunnyvale, California 94089-1206 USA 383 Phone: +1-408-745-2000 384 Email: dkatz@juniper.net 386 Dave Ward 387 Cisco Systems 388 170 W. Tasman Dr. 389 San Jose, CA 95134 USA 390 Phone: +1-408-526-4000 391 Email: dward@cisco.com 393 Changes from the previous draft 395 The only significant changes to this version are the option of not 396 using the TTL=255 hack when authentication is in use, the option of 397 suppressing ISIS and OSPF neighbors while the BFD session is down, 398 and further explication of the interactions with Graceful Restart. 399 All other changes are editorial in nature. 401 Full Copyright Notice 403 Copyright (C) The Internet Society (2005). This document is subject 404 to the rights, licenses and restrictions contained in BCP 78, and 405 except as set forth therein, the authors retain all their rights. 407 This document and the information contained herein are provided on an 408 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 409 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 410 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 411 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 412 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 413 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 415 Acknowledgement 417 Funding for the RFC Editor function is currently provided by the 418 Internet Society. 420 This document expires in August, 2005.