idnits 2.17.1 draft-donley-nat444-impacts-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 25, 2010) is 4929 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.nishitani-cgn' is defined on line 423, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-intarea-shared-addressing-issues-02 == Outdated reference: A later version (-06) exists of draft-shirasaki-nat444-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Donley 3 Internet-Draft CableLabs 4 Intended status: Informational L. Howard 5 Expires: April 28, 2011 Time Warner Cable 6 V. Kuarsingh 7 Rogers Communications 8 A. Chandrasekaran 9 V. Ganti 10 University of Colorado 11 October 25, 2010 13 Assessing the Impact of NAT444 on Network Applications 14 draft-donley-nat444-impacts-01 16 Abstract 18 NAT444 is an IPv4 extension technology being considered by Service 19 Providers to continue offering IPv4 service to customers while 20 transitioning to IPv6. This technology adds an extra Large-Scale NAT 21 ("LSN") in the Service Provider network, often resulting in two NATs. 22 CableLabs, Time Warner Cable, and Rogers Communications independently 23 tested the impacts of NAT444 on many popular Internet services using 24 a variety of test scenarios, network topologies, and vendor 25 equipment. This document identifies areas where adding a second 26 layer of NAT disrupts the communication channel for common Internet 27 applications. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 24, 2011. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. NAT444 Findings . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.1. NAT444 Additional Challenges . . . . . . . . . . . . . . . 3 66 3. Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Case1: Single Client, Single Home Network, Single 68 Service Provider . . . . . . . . . . . . . . . . . . . . . 4 69 3.2. Case2: Two Clients, Single Home Network, Single 70 Service Provider . . . . . . . . . . . . . . . . . . . . . 5 71 3.3. Case3: Two Clients, Two Home Networks, Single Service 72 Provider . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.4. Case4: Two Clients, Two Home Networks, Two Service 74 Providers Cross ISP . . . . . . . . . . . . . . . . . . . 7 75 4. Summary of Results . . . . . . . . . . . . . . . . . . . . . . 7 76 4.1. Case1: Single Client, Single Home Network, Single 77 Service Provider . . . . . . . . . . . . . . . . . . . . . 8 78 4.2. Case2: Two Clients, Single Home Network, Single 79 Service Provider . . . . . . . . . . . . . . . . . . . . . 9 80 4.3. Case3: Two Clients, Two Home Networks, Single Service 81 Provider . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 4.4. Case4: Two Clients, Two Home Networks, Two Service 83 Providers Cross ISP . . . . . . . . . . . . . . . . . . . 10 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 86 7. Informative References . . . . . . . . . . . . . . . . . . . . 10 87 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 90 1. Introduction 92 Current projections suggest that IANA will exhaust its free pool of 93 IPv4 addresses in 2011. IPv6 is the solution to the IPv4 depletion 94 problem; however, the transition to IPv6 will not be completed prior 95 to IPv4 exhaustion. NAT444 [I-D.shirasaki-nat444] is one transition 96 mechanism that will allow Service Providers to multiplex customers 97 behind a single IPv4 address, which will allow many legacy devices 98 and applications some IPv4 connectivity without requiring a home 99 router upgrade. While NAT444 does provide basic IPv4 connectivity, 100 it breaks a number of advanced applications. This document describes 101 suboptimal behaviors of NAT444 in our test environments. 103 2. NAT444 Findings 105 Overall, NAT444 was able to provide IPv4 connectivity for many basic 106 operations conducted by consumers; however, there are several areas 107 of concern with respect to the nested NAT environments. In 108 particular, many advanced tasks (e.g. peer-to-peer seeding, video 109 streaming, some Internet gaming, and IPv6 transition technologies 110 such as 6to4 [RFC3056] and Teredo [RFC4380]) fail outright or are 111 subject to severe service degradation. We observed that performance 112 often differs from vendor to vendor and from test environment to test 113 environment, and the results are somewhat difficult to predict. 115 2.1. NAT444 Additional Challenges 117 There are other challenges that arise when using shared IPv4 address 118 space, as with NAT444. Some of these challenges include: 120 o Loss of geolocation information - Often, translation zones will 121 cross traditional geographic boundaries. Since the source 122 addresses of packets traversing an LSN are set to the external 123 address of the LSN, it is difficult for external entities to 124 associate IP/Port information to specific locations/areas. 126 o Lawful Intercept/Abuse Response - Due to the nature of NAT444 127 address sharing, it will be hard to determine the customer/ 128 endpoint responsible for initiating a specific IPv4 flow based on 129 source IP address alone. Content providers, service providers, 130 and law enforcement agencies will need to use new mechanisms 131 (e.g., logging source port and timestamp in addition to source IP 132 address) to potentially mitigate this new problem. This may 133 impact the timely response to various identification requests. 134 See [I-D.ietf-intarea-shared-addressing-issues] 136 o Antispoofing - Multiplexing users behind a single IP address can 137 lead to situations where traffic from that address triggers 138 antispoofing/DDoS protection mechanisms, resulting in 139 unintentional loss of connectivity for some users. 141 3. Test Cases 143 The test cases illustrated below are designed to simulate an average 144 home user experience for various combinations of clients behind a 145 single or multiple LSN devices. 147 3.1. Case1: Single Client, Single Home Network, Single Service Provider 149 ^^^^^^^^ 150 (Internet) 151 vvvvvvvv 152 | 153 | 154 +---------------+ 155 | LSN | 156 +---------------+ 157 | 158 +---------------+ 159 | CMTS | 160 +---------------+ 161 | 162 +---------------+ 163 | CM | 164 +---------------+ 165 | 166 +-------------------------+ 167 | Home Router | 168 +-------------------------+ 169 | 170 +---------------+ 171 | Client | 172 +---------------+ 174 This is a typical case for a client accessing content on the 175 Internet. For this case, we focused on basic web browsing, voice and 176 video chat, instant messaging, video streaming (using YouTube, Google 177 Videos , etc.), Torrent leeching and seeding, FTP, and gaming. 178 Applications used in this case generally worked better than other 179 topologies. However, Netflix streaming performance was generally 180 slow and erratic. Also, large FTP downloads experienced issues when 181 translation mappings timed out. Bittorrent seeding also failed 182 during some tests. Finally, when a feature on XBOX is used to 183 determine the Network Settings, it generates a warning that NAT 184 settings are not ideal and may slow down the experience when more 185 than one client is connected. Gaming generally worked, but had 186 connectivity problems behind one specific LSN platform. Slingcatcher 187 video streaming failed. 189 3.2. Case2: Two Clients, Single Home Network, Single Service Provider 191 ^^^^^^^^ 192 (Internet) 193 vvvvvvvv 194 | 195 | 196 +---------------+ 197 | LSN | 198 +---------------+ 199 | 200 +---------------+ 201 | CMTS | 202 +---------------+ 203 | 204 +---------------+ 205 | CM | 206 +---------------+ 207 | 208 +-------------------------+ 209 | Home Router | 210 +-------------------------+ 211 | | 212 +---------------+ +---------------+ 213 | Client | | Client | 214 +---------------+ +---------------+ 216 This is similar to Case 1, except that two clients are behind the 217 same LSN and in the same home network. This test case was conducted 218 to observe any change in speed in basic web browsing and video 219 streaming. It is generally noted that the performance decreases in 220 bandwidth intensive applications. Torrent leeching was performed 221 from the two clients to a public server in the Internet. The 222 observed speed was considerably slower than with only one client 223 connected to the home network. Torrent seeding fails. Netflix video 224 streaming is also observed to be considerably choppy. When streaming 225 starts on one client, it does not start on the other, generating a 226 message saying that the Internet connection is too slow. 228 3.3. Case3: Two Clients, Two Home Networks, Single Service Provider 230 ^^^^^^^^ 231 (Internet) 232 vvvvvvvv 233 | 234 | 235 +---------------+ 236 | LSN | 237 +---------------+ 238 | 239 +---------------+ 240 | CMTS | 241 +---------------+ 242 | 243 ---------------------------------------- 244 | | 245 +---------------+ +---------------+ 246 | CM | | CM | 247 +---------------+ +---------------+ 248 | | 249 +-------------------------+ +-------------------------+ 250 | Home Router | | Home Router | 251 +-------------------------+ +-------------------------+ 252 | | 253 +---------------+ +---------------+ 254 | Client | | Client | 255 +---------------+ +---------------+ 257 In this scenario, the two clients are under the same LSN but behind 258 two different gateways. This simulates connectivity between two 259 residential subscribers on the same ISP. We tested peer-to-peer 260 applications. utorrent leeching and limewire leeching passed, while 261 utorrent seeding and limewire seeding failed. 263 3.4. Case4: Two Clients, Two Home Networks, Two Service Providers Cross 264 ISP 266 ^^^^^^^^ ^^^^^^^^ 267 ( ISP A ) ( ISP B ) 268 vvvvvvvv vvvvvvvv 269 | | 270 +---------------+ +---------------+ 271 | LSN | | LSN | 272 +---------------+ +---------------+ 273 | | 274 +---------------+ +---------------+ 275 | CMTS | | CMTS | 276 +---------------+ +---------------+ 277 | | 278 +---------------+ +---------------+ 279 | CM | | CM | 280 +---------------+ +---------------+ 281 | | 282 +-------------------------+ +-------------------------+ 283 | Home Router | | Home Router | 284 +-------------------------+ +-------------------------+ 285 | | 286 +---------------+ +---------------+ 287 | Client | | Client | 288 +---------------+ +---------------+ 290 This test case is similar to Case 1 but with the addition of another 291 identical ISP. This topology allows us to test traffic between two 292 residential customers connected across the Internet. We focused on 293 client-to-client applications such as IM and peer-to-peer. Instant 294 messaging applications including Skype and Google Talk perform well. 295 Skype video and voice chat also performed well. However, FTP 296 transfers and peer-to-peer seeding failed. 298 4. Summary of Results 299 4.1. Case1: Single Client, Single Home Network, Single Service Provider 301 +--------------+---------------+------------------------------------+ 302 | Test Case | Results | Notes | 303 +--------------+---------------+------------------------------------+ 304 | Web browsing | pass | | 305 | Email | pass | | 306 | FTP download | pass | performance degraded on very large | 307 | | | downloads | 308 | Bittorrent | pass | | 309 | leeching | | | 310 | Bittorrent | fail | | 311 | seeding | | | 312 | Video | pass | | 313 | streaming | | | 314 | Voice chat | pass | | 315 | Netflix | pass | | 316 | streaming | | | 317 | Instant | pass | | 318 | Messaging | | | 319 | Ping | pass | | 320 | Traceroute | pass | | 321 | Remote | pass | | 322 | desktop | | | 323 | VPN | pass | | 324 | Xbox live | pass | | 325 | Xbox online | pass | Blocked by some LSNs. | 326 | Xbox network | fail | Your NAT type is moderate. For | 327 | test | | best online experience you need an | 328 | | | open NAT configuration. You | 329 | | | should enable UPnP on the router. | 330 | Nintendo Wii | pass behind | | 331 | | one LSN, fail | | 332 | | behind | | 333 | | another | | 334 | Playstation | pass | | 335 | 3 | | | 336 | Team | fail | pass behind one LSN, but | 337 | Fortress 2 | | performance degraded | 338 | Starcraft II | pass | | 339 | World of | pass | | 340 | Warcraft | | | 341 | Call of Duty | pass | performance degraded behind one | 342 | | | LSN | 343 | Slingcatcher | fail | | 344 | Netflix | fail | pass behind one LSN | 345 | Party (Xbox) | | | 346 | Hulu | pass | performance degraded behind one | 347 | | | LSN | 348 | AIM File | pass | performance degraded | 349 | Tranfer | | | 350 | Webcam | fail | | 351 | 6to4 | fail | | 352 | Teredo | fail | | 353 +--------------+---------------+------------------------------------+ 355 Case1 357 4.2. Case2: Two Clients, Single Home Network, Single Service Provider 359 +-----------------+---------+---------------------------------------+ 360 | Test Case | Results | Notes | 361 +-----------------+---------+---------------------------------------+ 362 | Bittorrent | pass | | 363 | leeching | | | 364 | Bittorrent | fail | | 365 | seeding | | | 366 | Video streaming | fail | | 367 | Voice chat | pass | | 368 | Netflix | pass | performance severely impacted, | 369 | streaming | | eventually failed | 370 | IM | pass | | 371 | Limewire | pass | | 372 | leeching | | | 373 | Limewire | fail | | 374 | seeding | | | 375 +-----------------+---------+---------------------------------------+ 377 Case2 379 4.3. Case3: Two Clients, Two Home Networks, Single Service Provider 381 +-------------------+---------+-------+ 382 | Test Case | Results | Notes | 383 +-------------------+---------+-------+ 384 | Limewire leeching | pass | | 385 | Limewire seeding | fail | | 386 | Utorrent leeching | pass | | 387 | Utorrent seeding | fail | | 388 +-------------------+---------+-------+ 390 Case3 392 4.4. Case4: Two Clients, Two Home Networks, Two Service Providers Cross 393 ISP 395 +------------------+---------+-------+ 396 | Test Case | Results | Notes | 397 +------------------+---------+-------+ 398 | Skype voice call | pass | | 399 | IM | pass | | 400 | FTP | fail | | 401 | Facebook chat | pass | | 402 | Skype video | pass | | 403 +------------------+---------+-------+ 405 Case4 407 5. IANA Considerations 409 This document has no IANA considerations. 411 6. Security Considerations 413 Security considerations are described in [I-D.shirasaki-nat444]. 415 7. Informative References 417 [I-D.ietf-intarea-shared-addressing-issues] 418 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 419 Roberts, "Issues with IP Address Sharing", 420 draft-ietf-intarea-shared-addressing-issues-02 (work in 421 progress), October 2010. 423 [I-D.nishitani-cgn] 424 Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, 425 "Common requirements for IP address sharing schemes", 426 draft-nishitani-cgn-05 (work in progress), July 2010. 428 [I-D.shirasaki-nat444] 429 Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., 430 and H. Ashida, "NAT444", draft-shirasaki-nat444-02 (work 431 in progress), July 2010. 433 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 434 via IPv4 Clouds", RFC 3056, February 2001. 436 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 437 Network Address Translations (NATs)", RFC 4380, 438 February 2006. 440 Appendix A. Acknowledgements 442 Thanks to the following people (in alphabetical order) for their 443 guidance and feedback: 445 Paul Eldridge 447 John Berg 449 Lane Johnson 451 Authors' Addresses 453 Chris Donley 454 CableLabs 455 858 Coal Creek Circle 456 Louisville, CO 80027 457 USA 459 Email: c.donley@cablelabs.com 461 Lee Howard 462 Time Warner Cable 463 13241 Woodland Park Rd 464 Herndon, VA 20171 465 USA 467 Email: william.howard@twcable.com 469 Victor Kuarsingh 470 Rogers Communications 471 8200 Dixie Road 472 Brampton, ON L6T 0C1 473 Canada 475 Email: victor.kuarsingh@rci.rogers.com 476 Abishek Chandrasekaran 477 University of Colorado 479 Email: abishek.chandrasekaran@colorado.edu 481 Vivek Ganti 482 University of Colorado 484 Email: vivek.ganti@colorado.edu