idnits 2.17.1 draft-ietf-bfd-v4v6-1hop-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 99 has weird spacing: '...require bypas...' -- 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.) -- The document date (January 5, 2010) is 5222 days in the past. Is this intentional? 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 57, but not defined == Unused Reference: 'KEYWORD' is defined on line 256, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-10 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 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 Intended status: Proposed Standard D. Ward 5 Juniper Networks 6 Expires: July, 2010 January 5, 2010 8 BFD for IPv4 and IPv6 (Single Hop) 9 draft-ietf-bfd-v4v6-1hop-11.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Copyright Notice 34 Copyright (c) 2009 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the BSD License. 47 Abstract 49 This document describes the use of the Bidirectional Forwarding 50 Detection protocol over IPv4 and IPv6 for single IP hops. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC-2119 [KEYWORDS]. 58 1. Introduction 60 One very desirable application for BFD [BFD] is to track IPv4 and 61 IPv6 connectivity between directly-connected systems. This could be 62 used to supplement the detection mechanisms in routing protocols, or 63 to monitor router-host connectivity, among other applications. 65 This document describes the particulars necessary to use BFD in this 66 environment. Interactions between BFD and other protocols and system 67 functions are described in the BFD Generic Applications document 68 [BFD-GENERIC]. 70 2. Applications and Limitations 72 This application of BFD can be used by any pair of systems 73 communicating via IPv4 and/or IPv6 across a single IP hop that is 74 associated with an incoming interface. This includes, but is not 75 limited to, physical media, virtual circuits, and tunnels. 77 Each BFD session between a pair of systems MUST traverse a separate 78 network-layer path in both directions. This is necessary for 79 demultiplexing to work properly, and also because (by definition) 80 multiple sessions would otherwise be protecting the same path. 82 If BFD is to be used in conjunction with both IPv4 and IPv6 on a 83 particular path, a separate BFD session MUST be established for each 84 protocol (and thus encapsulated by that protocol) over that link. 86 If the BFD Echo function is used, transmitted packets are immediately 87 routed back towards the sender on the interface over which they were 88 sent. This may interact with other mechanisms that are used on the 89 two systems that employ BFD. In particular, ingress filtering [BCP38] 90 is incompatible with the way Echo packets need to be sent. 91 Implementations that support the Echo function MUST either ensure 92 that ingress filtering is not used on an interface that employs the 93 Echo function, or need make an exception for ingress filtering Echo 94 packets. 96 An implementation of the Echo function also requires Application 97 Programming Interfaces (APIs) that may not exist on all systems. A 98 system implementing the Echo function MUST be capable of sending 99 packets to its own address, which will typically require bypassing 100 the normal forwarding lookup. This typically requires access to APIs 101 that bypass IP layer functionality. 103 Please note that BFD is intended as a connectivity check/connection 104 verification OAM mechanism. It is applicable for network-based 105 services (e.g. router-to-router, subscriber-to-gateway, LSP/circuit 106 endpoints and service appliance failure detection). In these 107 scenarios it is required that the operator correctly provision the 108 rates at which BFD is transmitted to avoid congestion (e.g link, I/O, 109 CPU) and false failure detection. It is not applicable for 110 application-to-application failure detection across the Internet 111 because it does not have sufficient capability to do necessary 112 congestion detection and avoidance and therefore cannot prevent 113 congestion collapse. Host-to-host or application-to-application 114 deployment across the Internet will require the encapsulation of BFD 115 within a transport that provides "TCP-friendly" [TFRC] behavior. 117 3. Initialization and Demultiplexing 119 In this application, there will be only a single BFD session between 120 two systems over a given interface (logical or physical) for a 121 particular protocol. The BFD session must be bound to this 122 interface. As such, both sides of a session MUST take the "Active" 123 role (sending initial BFD Control packets with a zero value of Your 124 Discriminator) and any BFD packet from the remote machine with a zero 125 value of Your Discriminator MUST be associated with the session bound 126 to the remote system, interface, and protocol. 128 4. Encapsulation 130 BFD Control packets MUST be transmitted in UDP packets with 131 destination port 3784, within an IPv4 or IPv6 packet. The source 132 port MUST be in the range 49152 through 65535. The same UDP source 133 port number MUST be used for all BFD Control packets associated with 134 a particular session. The source port number SHOULD be unique among 135 all BFD sessions on the system. If more than 16384 BFD sessions are 136 simultaneously active, UDP source port numbers MAY be reused on 137 multiple sessions, but the number of distinct uses of the same UDP 138 source port number SHOULD be minimized. An implementation MAY use 139 the UDP port source number to aid in demultiplexing incoming BFD 140 Control packets, but ultimately the mechanisms in [BFD] MUST be used 141 to demultiplex incoming packets to the proper session. 143 BFD Echo packets MUST be transmitted in UDP packets with destination 144 UDP port 3785 in an IPv4 or IPv6 packet. The setting of the UDP 145 source port is outside the scope of this specification. The 146 destination address MUST be chosen in such a way as to cause the 147 remote system to forward the packet back to the local system. The 148 source address MUST be chosen in such a way as to preclude the remote 149 system from generating ICMP or Neighbor Discovery Redirect messages. 150 In particular, the source address SHOULD NOT be part of the subnet 151 bound to the interface over which the BFD Echo packet is being 152 transmitted, and it SHOULD NOT be an IPv6 link-local address, unless 153 it is known by other means that the remote system will not send 154 Redirects. 156 BFD Echo packets MUST be transmitted in such a way as to ensure that 157 they are received by the remote system. On multiaccess media, for 158 example, this requires that the destination datalink address 159 corresponds to the remote system. 161 The above requirements may require the bypassing of some common IP 162 layer functionality, particularly in host implementations. 164 5. TTL/Hop Limit Issues 166 If BFD authentication is not in use on a session, all BFD Control 167 packets for the session MUST be sent with a TTL or Hop Limit value of 168 255. All received BFD Control packets that are demultiplexed to the 169 session MUST be discarded if the received TTL or Hop Limit is not 170 equal to 255. A discussion of this mechanism can be found in [GTSM]. 172 If BFD authentication is in use on a session, all BFD Control packets 173 MUST be sent with a TTL or Hop Limit value of 255. All received BFD 174 Control packets that are demultiplexed the session MAY be discarded 175 if the received TTL or Hop Limit is not equal to 255. If the TTL/Hop 176 Limit check is made, it MAY be done before any cryptographic 177 authentication takes place if this will avoid unnecessary calculation 178 that would be detrimental to the receiving system. 180 In the context of this section, "authentication in use" means that 181 the system is sending BFD control packets with the Authentication bit 182 set and with the Authentication Section included, and that all 183 unauthenticated packets demultiplexed to the session are discarded, 184 per the BFD base specification. 186 6. Addressing Issues 188 Implementations MUST ensure that all BFD Control packets are 189 transmitted over the one-hop path being protected by BFD. 191 On a multiaccess network, BFD Control packets MUST be transmitted 192 with source and destination addresses that are part of the subnet 193 (addressed from and to interfaces on the subnet.) 195 On a point-to-point link, the source address of a BFD Control packet 196 MUST NOT be used to identify the session. This means that the 197 initial BFD packet MUST be accepted with any source address, and that 198 subsequent BFD packets MUST be demultiplexed solely by the Your 199 Discriminator field (as is always the case.) This allows the source 200 address to change if necessary. If the received source address 201 changes, the local system MUST NOT use that address as the 202 destination in outgoing BFD Control packets; rather it MUST continue 203 to use the address configured at session creation. An implementation 204 MAY notify the application that the neighbor's source address has 205 changed, so that the application might choose to change the 206 destination address or take some other action. Note that the TTL/Hop 207 Limit check described in section 5 (or the use of authentication) 208 precludes the BFD packets from having come from any source other than 209 the immediate neighbor. 211 7. BFD for use with Tunnels 213 A number of mechanisms are available to tunnel IPv4 and IPv6 over 214 arbitrary topologies. If the tunnel mechanism does not decrement the 215 TTL or Hop Limit of the network protocol carried within, the 216 mechanism described in this document may be used to provide liveness 217 detection for the tunnel. The BFD Authentication mechanism SHOULD be 218 used and is strongly encouraged. 220 8. IANA Considerations 222 Ports 3784 and 3875 were assigned by IANA for use with this protocol. 224 9. Security Considerations 226 In this application, the use of TTL=255 on transmit and receive, 227 coupled with an association to an incoming interface, is viewed as 228 supplying equivalent security characteristics to other protocols used 229 in the infrastructure, as it is not trivially spoofable. The 230 security implications of this mechanism are further discussed in 231 [GTSM]. 233 The security implications of the use of BFD Authentication are 234 discussed in [BFD]. 236 The use of the TTL=255 check simultaneously with BFD Authentication 237 provides a low overhead mechanism for discarding a class of 238 unauthorized packets and may be useful in implementations in which 239 cryptographic checksum use is susceptible to denial of service 240 attacks. The use or non-use of this mechanism does not impact 241 interoperability. 243 10. References 245 10.1. Normative References 247 [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", 248 draft-ietf-bfd-base-10.txt, January, 2010. 250 [BFD-GENERIC] Katz, D., and Ward, D., "Generic Application of BFD", 251 draft-ietf-bfd-generic-05.txt, February, 2009. 253 [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism 254 (GTSM)", RFC 5082, October, 2007. 256 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", RFC 2119, March 1997. 259 10.2. Informative References 261 [BCP38] Ferguson, P, and Senie, D., "Network Ingress Filtering: 262 Defeating Denial of Service Attacks which employ IP Source 263 Address Spoofing", RFC 2827, May 2000. 265 [TFRC] Floyd, S., et al, "TCP Friendly Rate Control (TFRC): Protocol 266 Specification", RFC 5348, September, 2008. 268 Authors' Addresses 270 Dave Katz 271 Juniper Networks 272 1194 N. Mathilda Ave. 273 Sunnyvale, California 94089-1206 USA 274 Phone: +1-408-745-2000 275 Email: dkatz@juniper.net 277 Dave Ward 278 Juniper Networks 279 1194 N. Mathilda Ave. 280 Sunnyvale, California 94089-1206 USA 281 Phone: +1-408-745-2000 282 Email: dward@juniper.net 284 Changes from the previous draft 286 The applications section was clarified. 288 This document expires in July, 2010.