idnits 2.17.1 draft-tsou-bfd-ds-lite-02.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 seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 23, 2012) is 4409 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.vinokour-bfd-dhcp' is defined on line 321, but no explicit reference was found in the text -- No information found for draft-ietf-pcp-base-23 - is the name correct? -- No information found for draft-vinokour-bfd-dhcp - is the name correct? Summary: 1 error (**), 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 March 23, 2012 5 Expires: September 24, 2012 7 BFD Support DS-Lite 8 draft-tsou-bfd-ds-lite-02 10 Abstract 12 In DS-Lite, the tunnel is not associated with any state information, 13 which makes it difficult to manage and diagnose. Some tools may be 14 used to resolve this problem. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 24, 2012. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Problem statement . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. BFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.1.1. DS-Lite Scenario . . . . . . . . . . . . . . . . . . . 4 56 3.1.2. Parameters for BFD . . . . . . . . . . . . . . . . . . 4 57 3.1.3. Procedures . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1.4. Implementation Considerations . . . . . . . . . . . . . 5 59 3.2. PCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.3. PING . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Problem statement 72 In DS-Lite [RFC6333], the IPv4-in-IPv6 tunnel is stateless, no status 73 information about tunnel is available, and no keep-alive mechanism is 74 available. It is difficult to know whether the tunnle is up or down, 75 which creates a problem for operation and maintenance. 77 If a B4 can detect a failure in the link to AFTR, it can switch to 78 another AFTR, setup new tunnel to that AFTR, so as to continue the 79 network service. Anycast could be used for the same purpose -- 80 failover, but there is an ICMP error message problem, that is, when a 81 packet is sent from AFTR to B4, one of the routers along the path may 82 generate an error ICMP message, e.g., packet too big, and the error 83 message is not sent back to the source AFTR, but sent to another 84 AFTR. 86 In some cases, the operators may want to have some more diagnostic 87 functions besides connectivity test, e.g. delay and throughput test, 88 this may be useful if the operator is providing services like IPTV 89 and video conference. ETHOAM and BFD can provide these 90 functionalities. But ETHOAM[802.1ag - 2007]is for ethernet layer2; 91 and BFD OAM functions now is only available for MPLS-TP[RFC6374]. 92 This is currently out of the scope of this spec. 94 1.1. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 2. Terminology 102 AFTR: Address Family Transition Router. 104 B4: Basic Bridging BroadBand. 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. BFD 118 BFD is a mechanism intended to detect faults in the bidirectional 119 path. It is usually used in conjunction with applications like OSPF, 120 IS-IS, etc, for fast fault recovery/fast re-route. [RFC5882] 122 BFD [RFC5880]can be used in DS-Lite, by creating a BFD session 123 between the B4 and the AFTR to provide tunnel status information. If 124 a fault is detected the B4 can try to create a DS-Lite tunnel with 125 another AFTR and terminate the existing one, so as to continue 126 network service. 128 [I-D.vinokour-bfd-dhcp]proposes using a DHCP option to distribute BFD 129 parameters to the B4. But in case of DS-Lite, some of the key BFD 130 parameters are already available (e.g., peer IP address is already 131 available), and other parameters can be negotiated by BFD signaling 132 or statically configured, so that no extra DHCP option(s) need to be 133 defined. 135 3.1.1. DS-Lite Scenario 137 In DS-Lite [RFC6333], the BFD packet SHOULD be sent through an IPv4- 138 in-IPv6 tunnel, as shown in Figure 1. The IPv4 addresses of the B4 139 and AFTR SHOULD be the endpoints of a BFD session. 141 +--------------+ +--------------+ 142 +------+ | | +------+ | | 143 | |-----+--------------+-----| | | | 144 | CPE | IPv6 Tunnel | AFTR |-----| IPv4 Network | 145 | (B4) |-----+--------------+-----| | | | 146 +------+ | IPv6 Network | +------+ | | 147 192.0.0.2 +--------------+ 192.0.0.1 +--------------+ 149 Figure 1: DS-Lite Scenario 151 3.1.2. Parameters for BFD 153 In order to set up a BFD session, the following parameters are 154 needed, as shown in Section 4.1 of[RFC5880]: 156 o Peer IP address 158 o My Discriminator 160 o Your Discriminator 161 o Desired Min TX Interval 163 o Required Min RX Interval 165 o Required Min Echo RX Interval 167 In DS-Lite [RFC6334], the B4 WAN-side IPv4 address is a well-known 168 address 192.0.0.2, and the AFTR's IPv4 address is 192.0.0.1, as 169 defined in section 5.7 of[RFC6333]. Because all the B4s and AFTRs 170 use the same well-known IP addresses, IPv4 addresses are not 171 sufficient for setting up a BFD session. From the B4's point of 172 view, the B4 needs to create an IPv6 tunnel to an AFTR so as to get 173 network connectivity to the AFTR, and send IPv4 BFD packets through 174 the tunnel to manage it. 176 The other parameters listed above can be negotiated by BFD signaling, 177 and initial values can be configured on the B4 and AFTR. 179 3.1.3. Procedures 181 In DS-Lite [RFC6333], when a B4 gets online, it will be assigned an 182 IPv6 prefix/address, and also the FQDN of the AFTR, as defined in 183 [RFC6334]. The B4 will create an IPv6 tunnel to the AFTR with which, 184 along with the well known B4 IPv4 address 192.0.0.2 and AFTR IPv4 185 address 192.0.0.1, the B4 can initiate a BFD session to the AFTR. 186 BFD packets will be sent through DS-Lite tunnel. As defined in 187 section 4 of [RFC5881], BFD control packet MUST be sent in UDP packet 188 with destination port 3784, and BFD echo packet MUST be sent in UDP 189 packet with destination port 3785. 191 When sending out the first BFD packet, the B4 can generate a unique 192 local discriminator, and set the remote discriminator to zero. When 193 the AFTR receive the first BFD packet from a B4, the AFTR will also 194 generate a corresponding local discriminator, and put it in the 195 response packet to the B4. This will finish the discriminator 196 negotiation in the B4 to AFTR direction, without any manual 197 configuration. 199 When the AFTR receives the first packet from a B4, AFTR will get the 200 IPv6 address and discriminator of the B4, so that the AFTR can 201 initiate the BFD session in the other direction and a similar 202 discriminator negotiation can be carried out. 204 3.1.4. Implementation Considerations 206 BFD is usually used for quick fault detection, at a very small time 207 scale, e.g. milliseconds. But in DS-Lite, it may not be necessary to 208 detect faults in such a short time. On the other hand, an AFTR may 209 need to support tens of thousands of B4s, which means the AFTR will 210 need to support the same number of BFD sessions. In order to meet 211 performance requirements on the AFTR, it may be necessary to extend 212 the time period between BFD packet transmissions to a longer time, 213 e.g., 10s or 30s. 215 3.2. PCP 217 PCP [I-D.ietf-pcp-base-23] is a NAT traversal tool, and it can also 218 be used for network connectivity test if PCP is supported in the 219 network. A common use case of PCP is to create pinhole so that 220 external users can visit the serviers located behind a NAT, and the 221 lifetime of the pinhole mapping is usually long, e.g. hours, and the 222 lifetime will be refreshed periodically by the client before it is 223 expired. For the purpose of network connectivity test, B4 can create 224 a mapping in the CGN via PCP, with short life time, e.g. 10s of 225 seconds, and keep on refreshing the mapping before it is expired. If 226 any refresh request fail, B4 knows that something is wrong with the 227 link or the PCP server or CGN. 229 In order to detect the network connectivity of the DS-Lite tunnel, 230 the encapsulation mode MUST be used for PCP -- PCP packets are sent 231 through DS-Lite tunnel. Encapsulation mode and plain mode are two 232 alternatives for PCP, there is no concensus yet which one should be 233 prefered in the PCP spec. 235 3.3. PING 237 PING is a common tool used for network node reachability tes, most of 238 the network nodes provide this tool. In case of DS-Lite, B4 can send 239 PING packets to AFTR periodically. If B4 does not receive response 240 packets for a certain number of PING request packet, e.g. 3, then B4 241 decides that a fault is detected. 243 In order to test the connectivity of DS-Lite tunnel, PING packets 244 MUST be sent using ICMPv4, rather than ICMPv6. 246 BFD can provide more diagnostic functions than PING, as depicted in 247 section 4.1 of [RFC5880]. 249 4. Failover 251 The FQDN of the AFTR is sent to B4 via a DHCP option, as defined in 252 [RFC6334]. Multiple IP addresses can be configured for an FQDN on 253 the DNS server. If B4 detect a failure on the link to AFTR, B4 MUST 254 terminate the current DS-Lite tunnel, choose another AFTR address in 255 the list, and create a tunnel to the new AFTR. B4 SHOULD also re- 256 configure the connectivity test tool accordingly if necessary, and 257 restart the test procedures. 259 5. IANA Considerations 261 This memo includes no request to IANA. 263 6. Security Considerations 265 In DS-Lite [RFC6333], the B4 may not be directly connected to the 266 AFTR; there may be other routers between them. Then there are 267 potential spoofing problems, as described in [RFC5883]. Hence 268 cryptographic authentication SHOULD be used as described in [RFC5880] 269 if security is concerned. 271 7. Acknowledgements 273 The author would like to thank Mohamed Boucadair for his useful 274 comments, more solutions are included in this memo. 276 8. References 278 8.1. Normative References 280 [I-D.ietf-pcp-base-23] 281 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 282 Selkirk, "Port Control Protocol (PCP)(work in progress)", 283 Feb 2012. 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, March 1997. 288 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 289 (BFD)", RFC 5880, June 2010. 291 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 292 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 293 June 2010. 295 [RFC5882] Katz, D. and D. Ward, "Generic Application of 296 Bidirectional Forwarding Detection (BFD)", RFC 5882, 297 June 2010. 299 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 300 (BFD) for Multihop Paths", RFC 5883, June 2010. 302 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 303 Stack Lite Broadband Deployments Following IPv4 304 Exhaustion", RFC 6333, August 2011. 306 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 307 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 308 RFC 6334, August 2011. 310 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 311 Measurement for MPLS Networks", RFC 6374, September 2011. 313 8.2. Informative References 315 [802.1ag - 2007] 316 IEEE Computer Societ, "IEEE Standard for Local and 317 Metropolitan Area Networks - Virtual Bridged Local Area 318 Networks Amendment 5: Connectivity Fault Management", 319 2007. 321 [I-D.vinokour-bfd-dhcp] 322 Vinokour, V., "Configuring BFD with DHCP and Other 323 Musings", May 2008. 325 Author's Address 327 Tina Tsou (editor) 328 Huawei Technologies (USA) 329 2330 Central Expressway 330 Santa Clara CA 95050 331 USA 333 Phone: +1 408 330 4424 334 Email: tina.tsou.zouting@huawei.com