idnits 2.17.1 draft-tsou-softwire-bfd-ds-lite-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 1, 2013) is 4102 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- No information found for draft-ietf-pcp-base-29 - is the name correct? -- No information found for draft-vinokour-bfd-dhcp - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Tsou, Ed. 3 Internet-Draft Huawei Technologies (USA) 4 Intended status: Informational B. Li 5 Expires: August 5, 2013 C. Zhou 6 Huawei Technologies 7 J. Schoenwaelder 8 Jacobs University Bremen 9 R. Penno 10 Cisco Systems, Inc. 11 M. Boucadair 12 France Telecom 13 February 1, 2013 15 DS-Lite Failure Detection and Failover 16 draft-tsou-softwire-bfd-ds-lite-04 18 Abstract 20 In DS-Lite, the tunnel is stateless, not associated with any state 21 information, and no failure detection and failover mechanism is 22 available. This makes it difficult to manage and diagnose if there 23 is a problem. This draft analyzes the applicability of some of the 24 possible solutions. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 5, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3.1. Bidirectional Forwarding Detection (BFD) . . . . . . . . . 4 64 3.1.1. DS-Lite Scenario . . . . . . . . . . . . . . . . . . . 4 65 3.1.2. Parameters for BFD . . . . . . . . . . . . . . . . . . 4 66 3.1.3. Elements of Procedure . . . . . . . . . . . . . . . . . 5 67 3.1.4. Implementation Considerations . . . . . . . . . . . . . 5 68 3.2. Port Control Protocol (PCP) . . . . . . . . . . . . . . . . 6 69 3.3. Internet Control Message Protocol (ICMP) . . . . . . . . . 6 70 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 5. Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 In DS-Lite [RFC6333], the IPv4-in-IPv6 DS-Lite tunnel is stateless, 82 no status information about the tunnel is available, and no keep- 83 alive mechanism is available. It is difficult to know whether the 84 tunnel is up or down; and if there is a link problem, the Basic 85 Bridging BroadBand (B4) element can not automatically switch to 86 another Address Family Transition Router (AFTR) so as to continue the 87 network service automatically, without the involvement of operators. 88 This lack of failure detection and failover creates problems for 89 network operation and maintenance. 91 Possible solutions for failure detection include the usage of 92 Bidirectional Forwarding Detection (BFD), the Port Control Protocol 93 (PCP), and the Internet Control Message Protocol (ICMP). The 94 properties of these solutions are discussed in this document and 95 guidelines are provided how to implement failure detection and 96 automatic failover. 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 2. Terminology 104 AFTR: Address Family Transition Router. 106 B4: Basic Bridging BroadBand. 108 BBF: BroadBand Forum. 110 BFD: Bidirectional Forwarding Detection. 112 CPE: Customer Premise Equipment (i.e., the DS-Lite B4). 114 FQDN: Fully Qualified Domain Name. 116 PCP: Port Control Protocol. 118 ICMP: Internet Control Message Protocol. 120 3. Solutions 121 3.1. Bidirectional Forwarding Detection (BFD) 123 Bidirectional Forwarding Detection [RFC5880] (BFD) is a mechanism 124 intended to detect faults in a bidirectional path. It is usually 125 used in conjunction with applications like OSPF, IS-IS, for fast 126 fault recovery and fast re-route [RFC5882]. BFD is being made 127 mandatory for keep-alive for subscriber sessions, including DS-Lite, 128 by the BroadBand Forum (BBF) [WT-146]. 130 BFD can be used in DS-Lite, by creating a BFD session between the B4 131 element and the AFTR to provide tunnel status information. If a 132 fault is detected, the B4 element can try to create a DS-Lite tunnel 133 with another AFTR and terminate the existing one, so as to continue 134 network service. 136 [I-D.vinokour-bfd-dhcp] proposes using a DHCP option to distribute 137 BFD parameters to B4 elements. But in case of DS-Lite, some of the 138 key BFD parameters are already available (e.g., peer IP address), and 139 other parameters can be negotiated by BFD signaling or statically 140 configured, so that no extra DHCP option(s) need to be defined. 142 3.1.1. DS-Lite Scenario 144 In DS-Lite [RFC6333], the BFD packet SHOULD be sent through an IPv4- 145 in-IPv6 tunnel, as shown in Figure 1. The IPv4 addresses of the B4 146 element and the AFTR SHOULD be the endpoints of a BFD session. 148 +--------------+ +--------------+ 149 +------+ | | +------+ | | 150 | |-----+--------------+-----| | | | 151 | CPE | IPv6 Tunnel | AFTR |-----| IPv4 Network | 152 | (B4) |-----+--------------+-----| | | | 153 +------+ | IPv6 Network | +------+ | | 154 192.0.2.2 +--------------+ 192.0.2.1 +--------------+ 156 Figure 1: DS-Lite Scenario 158 3.1.2. Parameters for BFD 160 In order to set up a BFD session, the following parameters are 161 needed, as shown in Section 4.1 of [RFC5880]: 163 o Peer IP address 165 o My Discriminator 167 o Your Discriminator 168 o Desired Min TX Interval 170 o Required Min RX Interval 172 o Required Min Echo RX Interval 174 In DS-Lite [RFC6334], the B4's WAN-side IPv4 address is the well- 175 known address 192.0.2.2, and the AFTR's well-known IPv4 address is 176 192.0.2.1, as defined in section 5.7 of [RFC6333]. The B4 element 177 needs to create an IPv6 tunnel to an AFTR so as to get network 178 connectivity to the AFTR, and send IPv4 BFD packets through the 179 tunnel to manage it. 181 The other parameters listed above can be negotiated by BFD signaling, 182 and initial values can be configured on B4 elements and AFTRs. 184 3.1.3. Elements of Procedure 186 When a B4 element gets online, it will be assigned an IPv6 prefix or 187 address, and also the FQDN of the AFTR, as defined in [RFC6334]. The 188 B4 element will create an IPv6 tunnel to the AFTR with which the B4 189 element can initiate a BFD session to the AFTR. BFD packets will be 190 sent through the DS-Lite tunnel. As defined in section 4 of 191 [RFC5881], BFD control packets MUST be sent in UDP packets with 192 destination port 3784, and BFD echo packets MUST be sent in UDP 193 packets with destination port 3785. 195 When sending out the first BFD packet, the B4 element can generate a 196 unique local discriminator, and set the remote discriminator to zero. 197 When the AFTR receives the first BFD packet from a B4 element, the 198 AFTR will also generate a corresponding local discriminator, and put 199 it in the response packet to the B4 element. This will finish the 200 discriminator negotiation in the B4 to AFTR direction, without any 201 manual configuration. 203 When an AFTR receives the first packet from a B4 element, the AFTR 204 will get the IPv6 address and discriminator of the B4 element, so 205 that the AFTR can initiate the BFD session in the other direction and 206 a similar discriminator negotiation can be carried out. 208 3.1.4. Implementation Considerations 210 BFD is usually used for quick fault detection, at a very small time 211 scale, e.g. milliseconds. But in DS-Lite, it may not be necessary to 212 detect faults in such a short time. On the other hand, an AFTR may 213 need to support tens of thousands of B4 elements, which means an AFTR 214 will need to support the same number of BFD sessions. In order to 215 meet performance requirements on an AFTR, it may be necessary to 216 configure the time period between BFD packet transmissions to a 217 longer time, e.g., 10s or 30s. 219 3.2. Port Control Protocol (PCP) 221 PCP [I-D.ietf-pcp-base-29] is a NAT traversal tool. It can also be 222 used for network connectivity test if PCP is supported in the 223 network. A common use case of PCP is to create a pinhole so that 224 external users can visit the servers located behind a NAT. The 225 lifetime of the pinhole mapping is usually long, e.g., hours, and the 226 lifetime will be refreshed periodically by the client before it is 227 expired. For the purpose of network connectivity tests, a B4 element 228 can create a mapping in the CGN via PCP, with a short life time, 229 e.g., 10s of seconds, and keep on refreshing the mapping before it 230 expires. If any refresh requests fail, the B4 element knows that 231 something is wrong with the link or the PCP server or the CGN. 233 In order to detect the network connectivity of the DS-Lite tunnel, 234 the encapsulation mode MUST be used for PCP: PCP packets are sent 235 through the DS-Lite tunnel. 237 3.3. Internet Control Message Protocol (ICMP) 239 The Echo (Request) and Echo Response messages of the Internet Control 240 Message Protocol (ICMP) [RFC0792] [RFC4443] can be used to determine 241 whether remote nodes are reachable. In case of DS-Lite, a B4 element 242 can send Echo (Request) packets to the AFTR periodically. If the B4 243 element does not receive a certain number (e.g., 3) of Echo Response 244 packets in a certain timeout period, then the B4 element decides that 245 a fault has been detected. 247 In order to test the connectivity of DS-Lite tunnel, Echo (Request) 248 packets MUST be sent using ICMPv4, rather than ICMPv6. 250 4. Discussion 252 The solutions can be compared based on the failure detection time, 253 the overhead on the wire, and the scalability on the AFTR. Lets 254 consider an AFTR that needs to support 10000-30000 subscribers. If 255 every subscriber sends a probe packet every 30 seconds, this creates 256 a load of 1-3 probe packets per millisecond and a failure detection 257 delay in minutes (since multiple probe packets may need to fail in 258 order to detect a failure). Shorter detection times significantly 259 increase the load on AFTRs. 261 BFD has a simple and fixed packet format, which is easy to implement 262 by logic devices (e.g., ASIC, FPGA). This allows line cards to 263 process BFD packets very efficiently in hardware. 265 PCP is a control protocol typically implemented in software. As 266 such, processing a large number of PCP requests in order to detect 267 failures is relatively expensive. On the other hand, PCP can detect 268 the failure of more components of the DS-Lite system. Besides 269 failures of the link and the routing, it also covers certain NAT 270 functions. 272 Since ICMP is an integral part of any IP implementation, the usage of 273 ICMP messages to detect tunnel failures does not require any special 274 implementation efforts on the B4 elements. However, on AFTRs that 275 process ICMP messages in software (slow path) rather than in 276 hardware, the usage of ICMP messages might lead to scalability 277 issues. 279 5. Failover 281 The FQDN of the AFTR is sent to the B4 element via a DHCP option, as 282 defined in [RFC6334]. Multiple IP addresses can be configured for 283 the FQDN of an AFTR on the DNS server. If a B4 element detects a 284 failure on the link to the AFTR, the B4 element MUST terminate the 285 current DS-Lite tunnel, choose another AFTR address in the list, and 286 create a tunnel to the new AFTR. If necessary, the B4 element SHOULD 287 re-configure the connectivity test tool accordingly and restart the 288 test procedures. 290 Anycasts may also be used for failover. But there is an ICMP-error- 291 message problem with anycast, that is, when a packet is sent from the 292 AFTR to a B4 element, if one of the routers along the path generates 293 an ICMP error message, e.g., Packet Too Big (PTB), then the error 294 message may not be sent back to the source AFTR but to another AFTR. 296 6. IANA Considerations 298 This memo includes no request to IANA. 300 7. Security Considerations 302 In the DS-Lite [RFC6333] application, the B4 element may not be 303 directly connected to the AFTR; there may be other routers between 304 them. In such a deployment, there are potential spoofing problems, 305 as described in [RFC5883]. Hence cryptographic authentication SHOULD 306 be used with BFD as described in [RFC5880] if security is concerned. 308 8. References 310 8.1. Normative References 312 [I-D.ietf-pcp-base-29] 313 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 314 Selkirk, "Port Control Protocol (PCP) (work in progress)", 315 Nov. 2012. 317 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 318 RFC 792, September 1981. 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, March 1997. 323 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 324 Message Protocol (ICMPv6) for the Internet Protocol 325 Version 6 (IPv6) Specification", RFC 4443, March 2006. 327 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 328 (BFD)", RFC 5880, June 2010. 330 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 331 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 332 June 2010. 334 [RFC5882] Katz, D. and D. Ward, "Generic Application of 335 Bidirectional Forwarding Detection (BFD)", RFC 5882, 336 June 2010. 338 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 339 (BFD) for Multihop Paths", RFC 5883, June 2010. 341 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 342 Stack Lite Broadband Deployments Following IPv4 343 Exhaustion", RFC 6333, August 2011. 345 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 346 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 347 RFC 6334, August 2011. 349 [WT-146] Kavanagh, A., Klamm, F., Boucadair, W., and R. Dec, "WT- 350 146 Subscriber Sessions (work in progress)", Apr 2012. 352 8.2. Informative References 354 [I-D.vinokour-bfd-dhcp] 355 Vinokour, V., "Configuring BFD with DHCP and Other 356 Musings", May 2008. 358 Authors' Addresses 360 Tina Tsou (editor) 361 Huawei Technologies (USA) 362 2330 Central Expressway 363 Santa Clara CA 95050 364 USA 366 Phone: +1 408 330 4424 367 Email: tina.tsou.zouting@huawei.com 369 Brandon Li 370 Huawei Technologies 371 M6, No. 156, Beiqing Road, Haidian District 372 Beijing 100094 373 China 375 Phone: 376 Email: brandon.lijian@huawei.com 378 Cathy Zhou 379 Huawei Technologies 380 China 382 Phone: 383 Email: cathy.zhou@huawei.com 385 Juergen Schoenwaelder 386 Jacobs University Bremen 387 Campus Ring 1 388 Bremen 28759 389 Germany 391 Phone: 392 Email: j.schoenwaelder@jacobs-university.de 393 Reinaldo Penno 394 Cisco Systems, Inc. 395 170 West Tasman Drivee 396 San Jose, California 95134 397 USA 399 Phone: 400 Email: repenno@cisco.com 402 Mohamed Boucadair 403 France Telecom 404 Rennes,35000 405 France 407 Phone: 408 Email: mohamed.boucadair@orange.com