idnits 2.17.1 draft-ietf-bfd-v4v6-1hop-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 283. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 254. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 261. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 267. 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 IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'KEYWORDS' is mentioned on line 45, but not defined == Unused Reference: 'KEYWORD' is defined on line 199, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-07 == Outdated reference: A later version (-05) exists of draft-ietf-bfd-generic-04 Summary: 1 error (**), 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: July, 2008 January, 2008 8 BFD for IPv4 and IPv6 (Single Hop) 9 draft-ietf-bfd-v4v6-1hop-07.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 36 This document describes the use of the Bidirectional Forwarding 37 Detection protocol over IPv4 and IPv6 for single IP hops. Comments 38 on this draft should be directed to rtg-bfd@ietf.org. 40 Conventions used in this document 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in RFC-2119 [KEYWORDS]. 46 1. Introduction 48 One very desirable application for BFD [BFD] is to track IPv4 and 49 IPv6 connectivity between directly-connected systems. This could be 50 used to supplement the detection mechanisms in routing protocols, or 51 to monitor router-host connectivity, among other applications. 53 This document describes the particulars necessary to use BFD in this 54 environment. Interactions between BFD and other protocols and system 55 functions are described in the BFD Generic Applications document 56 [BFD-GENERIC]. 58 2. Applications and Limitations 60 This application of BFD can be used by any pair of systems 61 communicating via IPv4 and/or IPv6 across a single IP hop that can be 62 associated with an incoming interface. This includes, but is not 63 limited to, physical media, virtual circuits, and tunnels. 65 Each BFD session between a pair of systems MUST traverse a separate 66 path in both directions. 68 If BFD is to be used in conjunction with both IPv4 and IPv6 on a 69 particular link, a separate BFD session MUST be established for each 70 protocol (and thus encapsulated by that protocol) over that link. 72 3. Initialization and Demultiplexing 74 In this application, there will be only a single BFD session between 75 two systems over a given interface (logical or physical) for a 76 particular protocol. The BFD session must be bound to this 77 interface. As such, both sides of a session MUST take the "Active" 78 role (sending initial BFD Control packets with a zero value of Your 79 Discriminator) and any BFD packet from the remote machine with a zero 80 value of Your Discriminator MUST be associated with the session bound 81 to the remote system, interface, and protocol. 83 4. Encapsulation 85 4.1. BFD for IPv4 87 In the case of IPv4, BFD Control packets MUST be transmitted in UDP 88 packets with destination port 3784, within an IPv4 packet. The 89 source port MUST be in the range 49152 through 65535. The same UDP 90 source port number MUST be used for all BFD Control packets 91 associated with a particular session. The source port number SHOULD 92 be unique among all BFD sessions on the system. If more than 16384 93 BFD sessions are simultaneously active, UDP source port numbers MAY 94 be reused on multiple sessions, but the number of distinct uses of 95 the same UDP source port number SHOULD be minimized. An 96 implementation MAY use the UDP port source number to aid in 97 demultiplexing incoming BFD Control packets, but ultimately the 98 mechanisms in [BFD] MUST be used to demultiplex incoming packets to 99 the proper session. 101 BFD Echo packets MUST be transmitted in UDP packets with destination 102 UDP port 3785 in an IPv4 packet. The setting of the UDP source port 103 is outside the scope of this specification. The destination address 104 MUST be chosen in such a way as to cause the remote system to forward 105 the packet back to the local system. The source address MUST be 106 chosen in such a way as to preclude the remote system from generating 107 ICMP Redirect messages. In particular, the source address MUST NOT 108 be part of the subnet bound to the interface over which the BFD Echo 109 packet is being transmitted. 111 4.2. BFD for IPv6 113 In the case of IPv6, BFD Control packets MUST be transmitted in UDP 114 packets with destination port 3784, within an IPv6 packet. The 115 source port MUST be in the range 49152 through 65535. The same UDP 116 source port number MUST be used for all BFD Control packets 117 associated with a particular session. The source port number SHOULD 118 be unique among all BFD sessions on the system. If more than 16384 119 BFD sessions are simultaneously active, UDP source port numbers MAY 120 be reused on multiple sessions, but the number of distinct uses of 121 the same UDP source port number SHOULD be minimized. An 122 implementation MAY use the UDP port source number to aid in 123 demultiplexing incoming BFD Control packets, but ultimately the 124 mechanisms in [BFD] MUST be used to demultiplex incoming packets to 125 the proper session. 127 BFD Echo packets MUST be transmitted in UDP packets with destination 128 UDP port 3785 in an IPv6 packet. The setting of the UDP source port 129 is outside the scope of this specification. The source and 130 destination addresses MUST both be associated with the local system. 131 The destination address MUST be chosen in such a way as to cause the 132 remote system to forward the packet back to the local system. 134 5. TTL/Hop Count Issues 136 If BFD authentication is not in use on a session, all BFD Control 137 packets for the session MUST be sent with a TTL or Hop Count value of 138 255. All received BFD Control packets that are demultiplexed to the 139 session MUST be discarded if the received TTL or Hop Count is not 140 equal to 255. A discussion of this mechanism can be found in [GTSM]. 142 If BFD authentication is in use on a session, all BFD Control packets 143 MUST be sent with a TTL or Hop Count value of 255. All received BFD 144 Control packets that are demultiplexed the session MAY be discarded 145 if the received TTL or Hop Count is not equal to 255. 147 In the context of this section, "authentication in use" means that 148 the system is sending BFD control packets with the Authentication bit 149 set and with the Authentication Section included, and that all 150 unauthenticated packets demultiplexed to the session are discarded, 151 per the BFD base specification. 153 6. Addressing Issues 155 On a subnetted network, BFD Control packets MUST be transmitted with 156 source and destination addresses that are part of the subnet 157 (addressed from and to interfaces on the subnet.) 159 On an addressed but unsubnetted point-to-point link, BFD Control 160 packets MUST be transmitted with source and destination addresses 161 that match the addresses configured on that link. 163 On an unnumbered point-to-point link, the source address of a BFD 164 Control packet MUST NOT be used to identify the session. This means 165 that the initial BFD packet MUST be accepted with any source address, 166 and that subsequent BFD packets MUST be demultiplexed solely by the 167 My Discriminator field (as is always the case.) This allows the 168 source address to change if necessary. If the received source 169 address changes, the local system MUST NOT use that address as the 170 destination in outgoing BFD Control packets; rather it MUST continue 171 to use the address configured at session creation. An implementation 172 MAY notify the application that the neighbor's source address has 173 changed, so that the application might choose to change the 174 destination address or take some other action. Note that the TTL/Hop 175 Count check described in section 5 (or the use of authentication) 176 precludes the BFD packets from having come from any source other than 177 the immediate neighbor. 179 7. BFD for use with Tunnels 181 A number of mechanisms are available to tunnel IPv4 and IPv6 over 182 arbitrary topologies. If the tunnel mechanism does not decrement the 183 TTL or hop count of the network protocol carried within, the 184 mechanism described in this document may be used to provide liveness 185 detection for the tunnel. The BFD Authentication mechanism SHOULD be 186 used and is strongly encouraged. 188 Normative References 190 [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", 191 draft-ietf-bfd-base-07.txt, January, 2008. 193 [BFD-GENERIC] Katz, D., and Ward, D., "Generic Application of BFD", 194 draft-ietf-bfd-generic-04.txt, January, 2008. 196 [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism 197 (GTSM)", RFC 5082, October, 2007. 199 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 200 Requirement Levels", RFC 2119, March 1997. 202 Security Considerations 204 In this application, the use of TTL=255 on transmit and receive is 205 viewed as supplying equivalent security characteristics to other 206 protocols used in the infrastructure, as it is not trivially 207 spoofable. The security implications of this mechanism are further 208 discussed in [GTSM]. 210 The security implications of the use of BFD Authentication are 211 discussed in [BFD]. 213 The use of the TTL=255 check simultaneously with BFD Authentication 214 provides a low overhead mechanism for discarding a class of 215 unauthorized packets and may be useful in implementations in which 216 cryptographic checksum use is susceptable to denial of service 217 attacks. The use or non-use of this mechanism does not impact 218 interoperability. 220 IANA Considerations 222 This document has no actions for IANA. 224 Authors' Addresses 226 Dave Katz 227 Juniper Networks 228 1194 N. Mathilda Ave. 229 Sunnyvale, California 94089-1206 USA 230 Phone: +1-408-745-2000 231 Email: dkatz@juniper.net 233 Dave Ward 234 Cisco Systems 235 170 W. Tasman Dr. 236 San Jose, CA 95134 USA 237 Phone: +1-408-526-4000 238 Email: dward@cisco.com 240 Changes from the previous draft 242 This is a reissue of the previous version. There are only minor 243 editorial changes. 245 IPR Disclaimer 247 The IETF takes no position regarding the validity or scope of any 248 Intellectual Property Rights or other rights that might be claimed to 249 pertain to the implementation or use of the technology described in 250 this document or the extent to which any license under such rights 251 might or might not be available; nor does it represent that it has 252 made any independent effort to identify any such rights. Information 253 on the procedures with respect to rights in RFC documents can be 254 found in BCP 78 and BCP 79. 256 Copies of IPR disclosures made to the IETF Secretariat and any 257 assurances of licenses to be made available, or the result of an 258 attempt made to obtain a general license or permission for the use of 259 such proprietary rights by implementers or users of this 260 specification can be obtained from the IETF on-line IPR repository at 261 http://www.ietf.org/ipr. 263 The IETF invites any interested party to bring to its attention any 264 copyrights, patents or patent applications, or other proprietary 265 rights that may cover technology that may be required to implement 266 this standard. Please address the information to the IETF at ietf- 267 ipr@ietf.org. 269 Full Copyright Notice 271 Copyright (C) The IETF Trust (2008). 273 This document is subject to the rights, licenses and restrictions 274 contained in BCP 78, and except as set forth therein, the authors 275 retain all their rights. 277 This document and the information contained herein are provided on an 278 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 279 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 280 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 281 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 282 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 283 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 285 Acknowledgement 287 Funding for the RFC Editor function is currently provided by the 288 Internet Society. 290 This document expires in July, 2008.