idnits 2.17.1 draft-tsou-softwire-bfd-ds-lite-03.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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 27, 2012) is 4320 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- No information found for draft-ietf-pcp-base-26 - is the name correct? -- No information found for draft-vinokour-bfd-dhcp - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 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: December 29, 2012 Huawei Technologies 6 J. Schoenwaelder 7 Jacobs University Bremen 8 R. Penno 9 Cisco Systems, Inc. 10 June 27, 2012 12 DS-Lite Failure Detection and Failover 13 draft-tsou-softwire-bfd-ds-lite-03 15 Abstract 17 In DS-Lite, the tunnel is stateless, not associated with any state 18 information, and no failure detection and failover mechanism is 19 available. This makes it difficult to manage and diagnose if there 20 is a problem. This draft analyzes the applicability of some of the 21 possible solutions. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 29, 2012. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. Bidirectional Forwarding Detection (BFD) . . . . . . . . . 3 61 3.1.1. DS-Lite Scenario . . . . . . . . . . . . . . . . . . . 4 62 3.1.2. Parameters for BFD . . . . . . . . . . . . . . . . . . 4 63 3.1.3. Elements of Procedure . . . . . . . . . . . . . . . . . 5 64 3.1.4. Implementation Considerations . . . . . . . . . . . . . 5 65 3.2. Port Control Protocol (PCP) . . . . . . . . . . . . . . . . 6 66 3.3. ICMP Echo (Request) / Echo Reply (PING) . . . . . . . . . . 6 67 4. Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 In DS-Lite [RFC6333], the IPv4-in-IPv6 DS-Lite tunnel is stateless, 79 no status information about the tunnel is available, and no keep- 80 alive mechanism is available. It is difficult to know whether the 81 tunnel is up or down; and if there is a link problem, the Basic 82 Bridging BroadBand (B4) element can not automatically switch to 83 another Address Family Transition Router (AFTR) so as to continue the 84 network service automatically, without the involvement of operators. 85 This lack of failure detection and failover creates problems for 86 network operation and maintenance. 88 Possible solutions for failure detection include the usage of 89 Bidirectional Forwarding Detection (BFD), the Port Control Protocol 90 (PCP), and ICMP Echo (Request) / Echo Reply (PING). The properties 91 of these solutions are discussed in this document and guidelines are 92 provided how to implement failure detection and automatic failover. 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 2. Terminology 100 AFTR: Address Family Transition Router. 102 B4: Basic Bridging BroadBand. 104 BBF: BroadBand Forum. 106 BFD: Bidirectional Forwarding Detection. 108 CPE: Customer Premise Equipment (i.e., the DS-Lite B4). 110 FQDN Fully Qualified Domain Name. 112 PCP Port Control Protocol. 114 3. Solutions 116 3.1. Bidirectional Forwarding Detection (BFD) 118 Bidirectional Forwarding Detection [RFC5880] (BFD) is a mechanism 119 intended to detect faults in a bidirectional path. It is usually 120 used in conjunction with applications like OSPF, IS-IS, for fast 121 fault recovery and fast re-route [RFC5882]. BFD is being made 122 mandatory for keep-alive for subscriber sessions, including DS-Lite, 123 by the BroadBand Forum (BBF) [WT-146]. 125 BFD can be used in DS-Lite, by creating a BFD session between the B4 126 element and the AFTR to provide tunnel status information. If a 127 fault is detected, the B4 element can try to create a DS-Lite tunnel 128 with another AFTR and terminate the existing one, so as to continue 129 network service. 131 [I-D.vinokour-bfd-dhcp] proposes using a DHCP option to distribute 132 BFD parameters to B4 elements. But in case of DS-Lite, some of the 133 key BFD parameters are already available (e.g., peer IP address), and 134 other parameters can be negotiated by BFD signaling or statically 135 configured, so that no extra DHCP option(s) need to be defined. 137 3.1.1. DS-Lite Scenario 139 In DS-Lite [RFC6333], the BFD packet SHOULD be sent through an IPv4- 140 in-IPv6 tunnel, as shown in Figure 1. The IPv4 addresses of the B4 141 element and the AFTR SHOULD be the endpoints of a BFD session. 143 +--------------+ +--------------+ 144 +------+ | | +------+ | | 145 | |-----+--------------+-----| | | | 146 | CPE | IPv6 Tunnel | AFTR |-----| IPv4 Network | 147 | (B4) |-----+--------------+-----| | | | 148 +------+ | IPv6 Network | +------+ | | 149 192.0.0.2 +--------------+ 192.0.0.1 +--------------+ 151 Figure 1: DS-Lite Scenario 153 3.1.2. Parameters for BFD 155 In order to set up a BFD session, the following parameters are 156 needed, as shown in Section 4.1 of [RFC5880]: 158 o Peer IP address 160 o My Discriminator 162 o Your Discriminator 164 o Desired Min TX Interval 166 o Required Min RX Interval 168 o Required Min Echo RX Interval 169 In DS-Lite [RFC6334], the B4's WAN-side IPv4 address is the well- 170 known address 192.0.0.2, and the AFTR's well-known IPv4 address is 171 192.0.0.1, as defined in section 5.7 of [RFC6333]. The B4 element 172 needs to create an IPv6 tunnel to an AFTR so as to get network 173 connectivity to the AFTR, and send IPv4 BFD packets through the 174 tunnel to manage it. 176 The other parameters listed above can be negotiated by BFD signaling, 177 and initial values can be configured on B4 elements and AFTRs. 179 3.1.3. Elements of Procedure 181 When a B4 element gets online, it will be assigned an IPv6 prefix or 182 address, and also the FQDN of the AFTR, as defined in [RFC6334]. The 183 B4 element will create an IPv6 tunnel to the AFTR with which the B4 184 element can initiate a BFD session to the AFTR. BFD packets will be 185 sent through the DS-Lite tunnel. As defined in section 4 of 186 [RFC5881], BFD control packets MUST be sent in UDP packets with 187 destination port 3784, and BFD echo packets MUST be sent in UDP 188 packets with destination port 3785. 190 When sending out the first BFD packet, the B4 element can generate a 191 unique local discriminator, and set the remote discriminator to zero. 192 When the AFTR receives the first BFD packet from a B4 element, the 193 AFTR will also generate a corresponding local discriminator, and put 194 it in the response packet to the B4 element. This will finish the 195 discriminator negotiation in the B4 to AFTR direction, without any 196 manual configuration. 198 When an AFTR receives the first packet from a B4 element, the AFTR 199 will get the IPv6 address and discriminator of the B4 element, so 200 that the AFTR can initiate the BFD session in the other direction and 201 a similar discriminator negotiation can be carried out. 203 3.1.4. Implementation Considerations 205 BFD is usually used for quick fault detection, at a very small time 206 scale, e.g. milliseconds. But in DS-Lite, it may not be necessary to 207 detect faults in such a short time. On the other hand, an AFTR may 208 need to support tens of thousands of B4 elements, which means an AFTR 209 will need to support the same number of BFD sessions. In order to 210 meet performance requirements on an AFTR, it may be necessary to 211 extend the time period between BFD packet transmissions to a longer 212 time, e.g., 10s or 30s. 214 Compared to other solutions, BFD has a simple and fixed packet 215 format, which is easy to implement by logic devices (e.g., ASIC, 216 FPGA). Complicated protocols are usually processed by software which 217 is relatively slow. An AFTR may need to support 10000-20000 users, 218 and if the protocol is handled by software, it will bring extra load 219 to the AFTR. 221 3.2. Port Control Protocol (PCP) 223 PCP [I-D.ietf-pcp-base-26] is a NAT traversal tool. It can also be 224 used for network connectivity test if PCP is supported in the 225 network. A common use case of PCP is to create a pinhole so that 226 external users can visit the servers located behind a NAT. The 227 lifetime of the pinhole mapping is usually long, e.g., hours, and the 228 lifetime will be refreshed periodically by the client before it is 229 expired. For the purpose of network connectivity tests, a B4 element 230 can create a mapping in the CGN via PCP, with a short life time, 231 e.g., 10s of seconds, and keep on refreshing the mapping before it 232 expires. If any refresh requests fail, the B4 element knows that 233 something is wrong with the link or the PCP server or the CGN. 235 In order to detect the network connectivity of the DS-Lite tunnel, 236 the encapsulation mode MUST be used for PCP: PCP packets are sent 237 through the DS-Lite tunnel. Encapsulation mode and plain mode are 238 two alternatives for PCP, there is no consensus yet which one should 239 be preferred in the PCP specification. 241 PCP can detect the failure of more components of the DS-Lite system. 242 Besides failures of the link and the routing, it also covers NAT 243 functions. 245 3.3. ICMP Echo (Request) / Echo Reply (PING) 247 PING is commonly implemented using the Echo (Request) and Echo 248 Response messages of the Internet Control Message Protocol (ICMP) 249 [RFC0792] [RFC4443]. In case of DS-Lite, a B4 element can send Echo 250 (Request) packets to the AFTR periodically. If the B4 element does 251 not receive Echo Response packets for a certain number (e.g., 3) of 252 Echo (Request) packets, then the B4 element decides that a fault has 253 been detected. 255 In order to test the connectivity of DS-Lite tunnel, Echo (Request) 256 packets MUST be sent using ICMPv4, rather than ICMPv6. 258 Since ICMP is an integral part of any IP implementation, the usage of 259 PING to detect tunnel failures does not require any special 260 implementation efforts on the B4 elements. However, on AFTRs that 261 process ICMP messages in software rather than in hardware, the usage 262 of PING might lead to scalability issues. 264 4. Failover 266 The FQDN of the AFTR is sent to the B4 element via a DHCP option, as 267 defined in [RFC6334]. Multiple IP addresses can be configured for 268 the FQDN of an AFTR on the DNS server. If a B4 element detects a 269 failure on the link to the AFTR, the B4 element MUST terminate the 270 current DS-Lite tunnel, choose another AFTR address in the list, and 271 create a tunnel to the new AFTR. If necessary, the B4 element SHOULD 272 re-configure the connectivity test tool accordingly and restart the 273 test procedures. 275 Anycasts may also be used for failover. But there is an ICMP-error- 276 message problem with anycast, that is, when a packet is sent from the 277 AFTR to a B4 element, if one of the routers along the path generates 278 an ICMP error message, e.g., Packet Too Big (PTB), then the error 279 message may not be sent back to the source AFTR but to another AFTR. 281 5. IANA Considerations 283 This memo includes no request to IANA. 285 6. Security Considerations 287 In the DS-Lite [RFC6333] application, the B4 element may not be 288 directly connected to the AFTR; there may be other routers between 289 them. In such a deployment, there are potential spoofing problems, 290 as described in [RFC5883]. Hence cryptographic authentication SHOULD 291 be used with BFD as described in [RFC5880] if security is concerned. 293 7. Acknowledgements 295 The authors would like to thank Mohamed Boucadair for his useful 296 comments. 298 8. References 300 8.1. Normative References 302 [I-D.ietf-pcp-base-26] 303 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 304 Selkirk, "Port Control Protocol (PCP)(work in progress)", 305 Jun 2012. 307 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 308 RFC 792, September 1981. 310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, March 1997. 313 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 314 Message Protocol (ICMPv6) for the Internet Protocol 315 Version 6 (IPv6) Specification", RFC 4443, March 2006. 317 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 318 (BFD)", RFC 5880, June 2010. 320 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 321 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 322 June 2010. 324 [RFC5882] Katz, D. and D. Ward, "Generic Application of 325 Bidirectional Forwarding Detection (BFD)", RFC 5882, 326 June 2010. 328 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 329 (BFD) for Multihop Paths", RFC 5883, June 2010. 331 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 332 Stack Lite Broadband Deployments Following IPv4 333 Exhaustion", RFC 6333, August 2011. 335 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 336 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 337 RFC 6334, August 2011. 339 [WT-146] Kavanagh, A., Klamm, F., Boucadair, W., and R. Dec, "WT- 340 146 Subscriber Sessions (work in progress)", Apr 2012. 342 8.2. Informative References 344 [I-D.vinokour-bfd-dhcp] 345 Vinokour, V., "Configuring BFD with DHCP and Other 346 Musings", May 2008. 348 Authors' Addresses 350 Tina Tsou (editor) 351 Huawei Technologies (USA) 352 2330 Central Expressway 353 Santa Clara CA 95050 354 USA 356 Phone: +1 408 330 4424 357 Email: tina.tsou.zouting@huawei.com 359 Brandon Li 360 Huawei Technologies 361 M6, No. 156, Beiqing Road, Haidian District 362 Beijing 100094 363 China 365 Phone: 366 Email: brandon.lijian@huawei.com 368 Juergen Schoenwaelder 369 Jacobs University Bremen 370 Campus Ring 1 371 Bremen 28759 372 Germany 374 Phone: 375 Email: j.schoenwaelder@jacobs-university.de 377 Reinaldo Penno 378 Cisco Systems, Inc. 379 170 West Tasman Drivee 380 San Jose, California 95134 381 USA 383 Phone: 384 Email: repenno@cisco.com