One document matched: draft-donley-nat444-impacts-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY I-D.shirasaki-nat444 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-shirasaki-nat444-02.xml">
<!ENTITY I-D.nishitani-cgn SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-nishitani-cgn-05.xml">
<!ENTITY I-D.ietf-intarea-shared-addressing-issues SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-intarea-shared-addressing-issues-02.xml">
<!ENTITY RFC3056 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3056.xml'>
<!ENTITY RFC4380 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4380.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" ipr="trust200902" docName="draft-donley-nat444-impacts-01">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="NAT444 impacts">Assessing the Impact of NAT444 on Network Applications</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author initials='C.D.' surname="Donley" fullname='Chris Donley'>
<organization>CableLabs </organization>
<address>
<postal>
<street>858 Coal Creek Circle</street>
<city>Louisville</city> <region>CO</region>
<code>80027</code>
<country>USA</country>
</postal>
<email>c.donley@cablelabs.com</email>
</address>
</author>
<author initials='L.H.' surname="Howard" fullname='Lee Howard'>
<organization>Time Warner Cable </organization>
<address>
<postal>
<street>13241 Woodland Park Rd</street>
<city>Herndon</city> <region>VA</region>
<code>20171</code>
<country>USA</country>
</postal>
<email>william.howard@twcable.com</email>
</address>
</author>
<author initials='V.K.' surname="Kuarsingh" fullname='Victor Kuarsingh'>
<organization>Rogers Communications </organization>
<address>
<postal>
<street>8200 Dixie Road</street>
<city>Brampton</city> <region>ON</region>
<code>L6T 0C1</code>
<country>Canada</country>
</postal>
<email>victor.kuarsingh@rci.rogers.com</email>
</address>
</author>
<author initials='A.C.' surname="Chandrasekaran" fullname='Abishek Chandrasekaran'>
<organization>University of Colorado</organization>
<address>
<email>abishek.chandrasekaran@colorado.edu</email>
</address>
</author>
<author initials='V.G.' surname="Ganti" fullname='Vivek Ganti'>
<organization>University of Colorado</organization>
<address>
<email>vivek.ganti@colorado.edu</email>
</address>
</author>
<date month="October" year="2010" />
<abstract>
<t>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. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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 <xref target="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.</t>
</section>
<section title="NAT444 Findings">
<t>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 <xref target="RFC3056"/> and Teredo <xref target="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.</t>
<section title="NAT444 Additional Challenges">
<t>There are other challenges that arise when using shared IPv4 address space, as with NAT444. Some of these challenges include:
<list style="symbols">
<t>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.</t>
<t>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 <xref target="I-D.ietf-intarea-shared-addressing-issues"/></t>
<t>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.</t>
</list>
</t></section>
</section>
<section title="Test Cases">
<t>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.</t>
<section title="Case1: Single Client, Single Home Network, Single Service Provider">
<figure>
<artwork>
^^^^^^^^
(Internet)
vvvvvvvv
|
|
+---------------+
| LSN |
+---------------+
|
+---------------+
| CMTS |
+---------------+
|
+---------------+
| CM |
+---------------+
|
+-------------------------+
| Home Router |
+-------------------------+
|
+---------------+
| Client |
+---------------+
</artwork>
</figure>
<t>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.
</t></section>
<section title="Case2: Two Clients, Single Home Network, Single Service Provider">
<figure>
<artwork>
^^^^^^^^
(Internet)
vvvvvvvv
|
|
+---------------+
| LSN |
+---------------+
|
+---------------+
| CMTS |
+---------------+
|
+---------------+
| CM |
+---------------+
|
+-------------------------+
| Home Router |
+-------------------------+
| |
+---------------+ +---------------+
| Client | | Client |
+---------------+ +---------------+
</artwork>
</figure>
<t>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.</t>
</section>
<section title="Case3: Two Clients, Two Home Networks, Single Service Provider">
<figure>
<artwork>
^^^^^^^^
(Internet)
vvvvvvvv
|
|
+---------------+
| LSN |
+---------------+
|
+---------------+
| CMTS |
+---------------+
|
----------------------------------------
| |
+---------------+ +---------------+
| CM | | CM |
+---------------+ +---------------+
| |
+-------------------------+ +-------------------------+
| Home Router | | Home Router |
+-------------------------+ +-------------------------+
| |
+---------------+ +---------------+
| Client | | Client |
+---------------+ +---------------+
</artwork>
</figure>
<t>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.</t>
</section>
<section title="Case4: Two Clients, Two Home Networks, Two Service Providers Cross ISP">
<figure>
<artwork>
^^^^^^^^ ^^^^^^^^
( ISP A ) ( ISP B )
Vvvvvvvv vvvvvvvv
| |
+---------------+ +---------------+
| LSN | | LSN |
+---------------+ +---------------+
| |
+---------------+ +---------------+
| CMTS | | CMTS |
+---------------+ +---------------+
| |
+---------------+ +---------------+
| CM | | CM |
+---------------+ +---------------+
| |
+-------------------------+ +-------------------------+
| Home Router | | Home Router |
+-------------------------+ +-------------------------+
| |
+---------------+ +---------------+
| Client | | Client |
+---------------+ +---------------+
</artwork>
</figure>
<t>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.</t>
</section>
</section>
<section title="Summary of Results">
<section title="Case1: Single Client, Single Home Network, Single Service Provider">
<texttable title="Case1">
<ttcol >Test Case </ttcol><ttcol> Results </ttcol><ttcol>Notes</ttcol>
<c>Web browsing</c> <c>pass</c><c></c>
<c>Email</c><c>pass</c><c></c>
<c>FTP download</c><c>pass</c> <c>performance degraded on very large downloads</c>
<c>Bittorrent leeching</c><c>pass</c><c></c>
<c>Bittorrent seeding</c><c>fail</c><c></c>
<c>Video streaming</c><c>pass</c><c></c>
<c>Voice chat</c><c>pass</c><c></c>
<c>Netflix streaming</c><c>pass</c><c></c>
<c>Instant Messaging</c><c> pass</c><c></c>
<c>Ping </c><c>pass</c><c></c>
<c>Traceroute </c><c>pass</c><c></c>
<c>Remote desktop </c><c>pass</c><c></c>
<c>VPN </c><c> pass</c><c></c>
<c>Xbox live </c><c> pass</c><c></c>
<c>Xbox online </c><c> pass </c> <c>Blocked by some LSNs.</c>
<c>Xbox network test </c><c>fail</c> <c>Your NAT type is moderate. For best online experience you need an open NAT configuration. You should enable UPnP on the router.</c>
<c>Nintendo Wii</c><c> pass behind one LSN, fail behind another</c><c></c>
<c>Playstation 3 </c><c> pass</c><c></c>
<c>Team Fortress 2 </c><c> fail </c><c> pass behind one LSN, but performance degraded</c>
<c>Starcraft II </c><c> pass</c><c></c>
<c>World of Warcraft </c><c> pass</c><c></c>
<c>Call of Duty </c><c> pass </c><c> performance degraded behind one LSN</c>
<c>Slingcatcher </c><c> fail</c><c></c>
<c>Netflix Party (Xbox)</c><c>fail </c><c> pass behind one LSN</c>
<c>Hulu </c><c> pass </c><c> performance degraded behind one LSN</c>
<c>AIM File Tranfer </c><c> pass </c><c> performance degraded</c>
<c>Webcam </c><c> fail</c><c></c>
<c>6to4 </c><c> fail</c><c></c>
<c>Teredo </c><c> fail</c><c></c>
</texttable>
</section>
<section title="Case2: Two Clients, Single Home Network, Single Service Provider">
<texttable title="Case2">
<ttcol>Test Case </ttcol><ttcol>Results</ttcol><ttcol>Notes</ttcol>
<c>Bittorrent leeching</c><c> pass</c><c></c>
<c>Bittorrent seeding</c><c> fail</c><c></c>
<c>Video streaming </c><c> fail</c><c></c>
<c>Voice chat </c><c> pass</c><c></c>
<c>Netflix streaming </c><c>pass </c><c> performance severely impacted, eventually failed</c>
<c>IM </c><c> pass</c><c></c>
<c>Limewire leeching </c><c> pass</c><c></c>
<c>Limewire seeding </c><c> fail</c><c></c>
</texttable>
</section>
<section title="Case3: Two Clients, Two Home Networks, Single Service Provider">
<texttable title="Case3">
<ttcol>Test Case </ttcol><ttcol>Results</ttcol><ttcol> Notes</ttcol>
<c>Limewire leeching </c><c> pass</c><c></c>
<c>Limewire seeding </c><c> fail</c><c></c>
<c>Utorrent leeching </c><c> pass</c><c></c>
<c>Utorrent seeding </c><c> fail</c><c></c>
</texttable>
</section>
<section title="Case4: Two Clients, Two Home Networks, Two Service Providers Cross ISP">
<texttable title="Case4">
<ttcol>Test Case </ttcol><ttcol>Results</ttcol><ttcol>Notes</ttcol>
<c>Skype voice call </c><c> pass</c><c></c>
<c>IM </c><c> pass</c><c></c>
<c>FTP </c><c> fail</c><c></c>
<c>Facebook chat </c><c> pass</c><c></c>
<c>Skype video </c><c> pass</c><c></c>
</texttable>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document has no IANA considerations.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Security considerations are described in <xref target="I-D.shirasaki-nat444"/>.</t>
</section>
</middle>
<back>
<references title="Informative References">
&I-D.shirasaki-nat444;
&I-D.nishitani-cgn;
&I-D.ietf-intarea-shared-addressing-issues;
&RFC3056;
&RFC4380;
</references>
<section title="Acknowledgements">
<t>Thanks to the following people (in alphabetical order) for their guidance and feedback:
<list style="hanging">
<t>Paul Eldridge</t>
<t>John Berg</t>
<t>Lane Johnson</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 06:02:02 |