Network Working Group C.D. Donley
Internet-Draft CableLabs
Intended status: Informational L.H. Howard
Expires: April 02, 2011 Time Warner Cable
V.K. Kuarsingh
Rogers Communications
A.C. Chandrasekaran
V.G. Ganti
University of Colorado
October 2010

Assessing the Impact of NAT444 on Network Applications
draft-donley-nat444-impacts-00

Abstract

NAT444 is an IPv4 extension technology being considered by Service Providers to continue offering IPv4 service to customers while transitioning to IPv6. This technology adds an extra Large-Scale NAT ("LSN") in the Service Provider network, thereby resulting in two NATs. CableLabs, Time Warner Cable, and Rogers Communications independently tested the impacts of NAT444 on many popular Internet services using a variety of test scenarios, network topologies, and vendor equipment. This document identifies areas where adding a second layer of NAT disrupts the communication channel for common Internet applications.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 02, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠trustee.ietf.org/⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

Current projections suggest that IANA will exhaust its free pool of IPv4 addresses in 2011. IPv6 is the solution to the IPv4 depletion problem; however, the transition to IPv6 will not be completed prior to IPv4 exhaustion. NAT444 [I-D.shirasaki-nat444] is one transition mechanism that will allow Service Providers to multiplex customers behind a single IPv4 address, which will allow many legacy devices and applications some IPv4 connectivity without requiring a home router upgrade. While NAT444 does provide basic IPv4 connectivity, it breaks a number of advanced applications. This document describes suboptimal behaviors of NAT444 in our test environments.

2. NAT444 Findings

Overall, NAT444 was able to provide IPv4 connectivity for many basic operations conducted by consumers; however, there are several areas of concern with respect to the nested NAT environments. In particular, many advanced tasks (e.g. peer-to-peer seeding, video streaming, some Internet gaming, and IPv6 transition technologies such as 6to4 [RFC3056] and Teredo [RFC4380]) fail outright or are subject to severe service degradation. We observed that performance often differs from vendor to vendor and from test environment to test environment, and the results are somewhat difficult to predict.

2.1. NAT444 Additional Challenges

There are other challenges that arise when using shared IPv4 address space, as with NAT444. Some of these challenges include:

3. Test Cases

The test cases illustrated below are designed to simulate an average home user experience for various combinations of clients behind a single or multiple LSN devices.

3.1. Case1: Single Client, Single Home Network, Single Service Provider

		               ^^^^^^^^
		              (Internet)
		               vvvvvvvv
			            |
			            |
                      +---------------+
                      |      LSN       |
                      +---------------+
		           	     	|
		           +---------------+
                       |      CMTS     |
		           +---------------+
                               |
		           +---------------+
                       |      CM       |
                       +---------------+ 
		                 	|
		          +-------------------------+
		          |      Home Router        |
		          +-------------------------+
                              |
		          +---------------+
		          |      Client   |
		          +---------------+
      

This is a typical case for a client accessing content on the Internet. For this case, we focused on basic web browsing, voice and video chat, instant messaging, video streaming (using YouTube, Google Videos , etc.), Torrent leeching and seeding, FTP, and gaming. Applications used in this case generally worked better than other topologies. However, Netflix streaming performance was generally slow and erratic. Also, large FTP downloads experienced issues when translation mappings timed out. Bittorrent seeding also failed during some tests. Finally, when a feature on XBOX is used to determine the Network Settings, it generates a warning that NAT settings are not ideal and may slow down the experience when more than one client is connected. Gaming generally worked, but had connectivity problems behind one specific LSN platform. Slingcatcher video streaming failed.

3.2. Case2: Two Clients, Single Home Network, Single Service Provider

		               ^^^^^^^^
                          (Internet)
                           vvvvvvvv
		                 	|
		                 	|
	          	    +---------------+
	           	    |      LSN      |
		          +---------------+
		                	|
		          +---------------+
	           	    |      CMTS     |
                      +---------------+
		                	|
	          	    +---------------+
	                |      CM       |
                      +---------------+ 
		                	|
	     	+-------------------------+
	  	|      Home Router        |
		+-------------------------+
                |                |
 	  +---------------+   +---------------+
	  |      Client   |   |      Client   |
	  +---------------+   +---------------+
		

This is similar to Case 1, except that two clients are behind the same LSN and in the same home network. This test case was conducted to observe any change in speed in basic web browsing and video streaming. It is generally noted that the performance decreases in bandwidth intensive applications. Torrent leeching was performed from the two clients to a public server in the Internet. The observed speed was considerably slower than with only one client connected to the home network. Torrent seeding fails. Netflix video streaming is also observed to be considerably choppy. When streaming starts on one client, it does not start on the other, generating a message saying that the Internet connection is too slow.

3.3. Case3: Two Clients, Two Home Networks, Single Service Provider

		          	^^^^^^^^
			     (Internet)
		          	vvvvvvvv
				    |
	            	    |
                    +---------------+
	         	  |      LSN      |
	        	  +---------------+
			          |
                    +---------------+
		        |      CMTS     |
		        +---------------+
			          |
	----------------------------------------	
                  |                     |
      +---------------+         +---------------+
	|      CM       |         |      CM       |
	+---------------+         +---------------+
	       	|                     |
+-------------------------+ +-------------------------+
|      Home Router        | |      Home Router        |
+-------------------------+ +-------------------------+
	        |                     |
  +---------------+         +---------------+
  |      Client   |         |      Client   |
  +---------------+         +---------------+

In this scenario, the two clients are under the same LSN but behind two different gateways. This simulates connectivity between two residential subscribers on the same ISP. We tested peer-to-peer applications. utorrent leeching and limewire leeching passed, while utorrent seeding and limewire seeding failed.

3.4. Case4: Two Clients, Two Home Networks, Two Service Providers Cross ISP

	 ^^^^^^^^                    ^^^^^^^^
	( ISP A )                   ( ISP B  )
	 Vvvvvvvv                    vvvvvvvv
          |                           |
	+---------------+         +---------------+
	|      LSN      |         |      LSN      |
	+---------------+         +---------------+
            |                         |
	+---------------+         +---------------+
	|      CMTS     |         |      CMTS     |
	+---------------+         +---------------+
           |                          | 
      +---------------+         +---------------+
	|      CM       |         |      CM       |
	+---------------+         +---------------+
	      |                         |
+-------------------------+ +-------------------------+
|      Home Router        | |      Home Router        |
+-------------------------+ +-------------------------+
	       |                        |
  +---------------+         +---------------+
  |      Client   |         |      Client   |
  +---------------+         +---------------+

This test case is similar to Case 1 but with the addition of another identical ISP. This topology allows us to test traffic between two residential customers connected across the Internet. We focused on client-to-client applications such as IM and peer-to-peer. Instant messaging applications including Skype and Google Talk perform well. Skype video and voice chat also performed well. However, FTP transfers and peer-to-peer seeding failed.

4. Summary of Results

4.1. Case1: Single Client, Single Home Network, Single Service Provider

Case1
Test Case Results Notes
Web browsing pass
Email pass
FTP download pass performance degraded on very large downloads
Bittorrent leeching pass
Bittorrent seeding fail
Video streaming pass
Voice chat pass
Netflix streaming pass
Instant Messaging pass
Ping pass
Traceroute pass
Remote desktop pass
VPN pass
Xbox live pass
Xbox online pass Blocked by some LSNs.
Xbox network test fail Your NAT type is moderate. For best online experience you need an open NAT configuration. You should enable UPnP on the router.
Nintendo Wii pass behind one LSN, fail behind another
Playstation 3 pass
Team Fortress 2 fail pass behind one LSN, but performance degraded
Starcraft II pass
World of Warcraft pass
Call of Duty pass performance degraded behind one LSN
Slingcatcher fail
Netflix Party (Xbox) fail pass behind one LSN
Hulu pass performance degraded behind one LSN
AIM File Tranfer pass performance degraded
Webcam fail
6to4 fail
Teredo fail

4.2. Case2: Two Clients, Single Home Network, Single Service Provider

Case2
Test Case Results Notes
Bittorrent leeching pass
Bittorrent seeding fail
Video streaming fail
Voice chat pass
Netflix streaming pass performance severely impacted, eventually failed
IM pass
Limewire leeching pass
Limewire seeding fail

4.3. Case3: Two Clients, Two Home Networks, Single Service Provider

Case3
Test Case Results Notes
Limewire leeching pass
Limewire seeding fail
Utorrent leeching pass
Utorrent seeding fail

4.4. Case4: Two Clients, Two Home Networks, Two Service Providers Cross ISP

Case4
Test Case Results Notes
Skype voice call pass
IM pass
FTP fail
Facebook chat pass
Skype video pass

5. IANA Considerations

This document has no IANA considerations.

6. Security Considerations

Security considerations are described in [I-D.shirasaki-nat444].

7. References

[I-D.shirasaki-nat444] Yamagata, I, Shirasaki, Y, Nakagawa, A, Yamaguchi, J and H Ashida, "NAT444", Internet-Draft draft-shirasaki-nat444-02, July 2010.
[I-D.nishitani-cgn] Yamagata, I, Miyakawa, S, Nakagawa, A and H Ashida, "Common requirements for IP address sharing schemes", Internet-Draft draft-nishitani-cgn-05, July 2010.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.

Appendix A. Acknowledgements

Thanks to the following people (in alphabetical order) for their guidance and feedback:

Paul Eldridge
John Berg
Lane Johnson

Authors' Addresses

Chris Donley CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA EMail: c.donley@cablelabs.com
Lee Howard Time Warner Cable 13241 Woodland Park Rd Herndon, VA 20171 USA EMail: william.howard@twcable.com
Victor Kuarsingh Rogers Communications 8200 Dixie Road Brampton, ON L6T 0C1 Canada EMail: victor.kuarsingh@rci.rogers.com
Abishek Chandrasekaran University of Colorado EMail: abishek.chandrasekaran@colorado.edu
Vivek Ganti University of Colorado EMail: vivek.ganti@colorado.edu