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

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, often 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 29, 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
2.  NAT444 Findings
    2.1.  NAT444 Additional Challenges
3.  Test Cases
    3.1.  Case1: Single Client, Single Home Network, Single Service Provider
    3.2.  Case2: Two Clients, Single Home Network, Single Service Provider
    3.3.  Case3: Two Clients, Two Home Networks, Single Service Provider
    3.4.  Case4: Two Clients, Two Home Networks, Two Service Providers Cross ISP
4.  Summary of Results
    4.1.  Case1: Single Client, Single Home Network, Single Service Provider
    4.2.  Case2: Two Clients, Single Home Network, Single Service Provider
    4.3.  Case3: Two Clients, Two Home Networks, Single Service Provider
    4.4.  Case4: Two Clients, Two Home Networks, Two Service Providers Cross ISP
5.  IANA Considerations
6.  Security Considerations
7.  Informative References
Appendix A.  Acknowledgements
§  Authors' Addresses

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] (Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., and H. Ashida, “NAT444,” July 2010.) 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] (Carpenter, B. and K. Moore, “Connection of IPv6 Domains via IPv4 Clouds,” February 2001.) and Teredo [RFC4380] (Huitema, C., “Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs),” February 2006.)) 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:

• Loss of geolocation information - Often, translation zones will cross traditional geographic boundaries. Since the source addresses of packets traversing an LSN are set to the external address of the LSN, it is difficult for external entities to associate IP/Port information to specific locations/areas.
• Lawful Intercept/Abuse Response - Due to the nature of NAT444 address sharing, it will be hard to determine the customer/endpoint responsible for initiating a specific IPv4 flow based on source IP address alone. Content providers, service providers, and law enforcement agencies will need to use new mechanisms (e.g., logging source port and timestamp in addition to source IP address) to potentially mitigate this new problem. This may impact the timely response to various identification requests. See [I‑D.ietf‑intarea‑shared‑addressing‑issues] (Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, “Issues with IP Address Sharing,” October 2010.)
• Antispoofing - Multiplexing users behind a single IP address can lead to situations where traffic from that address triggers antispoofing/DDoS protection mechanisms, resulting in unintentional loss of connectivity for some users.

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

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

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

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

5.  IANA Considerations

This document has no IANA considerations.

6.  Security Considerations

Security considerations are described in [I‑D.shirasaki‑nat444] (Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., and H. Ashida, “NAT444,” July 2010.).

7. Informative References

Appendix A.  Acknowledgements

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

Paul Eldridge

John Berg

Lane Johnson

Authors' Addresses