Independent Submission C. Donley, Ed. Request for Comments: 7021 CableLabs Category: Informational L. Howard ISSN: 2070-1721 Time Warner Cable V. Kuarsingh Rogers Communications J. Berg CableLabs J. Doshi Juniper Networks September 2013
Assessing the Impact of Carrier-Grade NAT on Network Applications
Abstract
NAT444 is an IPv4 extension technology being considered by Service Providers as a means to continue offering IPv4 service to customers while transitioning to IPv6. This technology adds an extra Carrier- Grade NAT (CGN) 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. This document was updated to include the Dual-Stack Lite (DS-Lite) impacts also.
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7021.
Donley, et al. Informational [Page 1]
RFC 7021 NAT444 Impacts September 2013
Copyright Notice
Copyright (c) 2013 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.
IANA, APNIC, and RIPE NCC exhausted their IPv4 address space in 2011- 2012. Current projections suggest that ARIN may exhaust its free pool of IPv4 addresses in 2013. IPv6 is the solution to the IPv4 depletion problem; however, the transition to IPv6 will not be completed prior to IPv4 exhaustion. NAT444 [NAT444] and Dual-Stack Lite [RFC6333] are transition mechanisms that will allow Service Providers to multiplex customers behind a single IPv4 address, which will allow many legacy devices and applications some IPv4 connectivity. While both NAT444 and Dual-Stack Lite provide basic IPv4 connectivity, they impact a number of advanced applications. This document describes suboptimal behaviors of NAT444 and DS-Lite found in our test environments.
From July through August 2010, CableLabs, Time Warner Cable, and Rogers Communications tested the impact of NAT444 on common applications using Carrier-Grade NAT (CGN) devices. This testing was focused on a wide array of real-time usage scenarios designed to evaluate the user experience over the public Internet using NAT444 in both single and dual ISP environments. The purpose of this testing was to identify applications where the technology either breaks or significantly impacts the user experience. The testing revealed that applications, such as video streaming, video gaming, and peer-to-peer file sharing, are impacted by NAT444.
From June through October 2011, CableLabs conducted additional testing of CGN technologies, including both NAT444 and Dual-Stack Lite. The testing focused on working with several vendors including A10, Alcatel-Lucent, and Juniper to optimize the performance of those applications that experienced negative impacts during earlier CGN testing and to expand the testing to DS-Lite.
Applications that were tested included, but were not necessarily limited to, the following:
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.
Donley, et al. Informational [Page 5]
RFC 7021 NAT444 Impacts September 2013
2.1.2. Case 2: Two Clients, Single Home Network, Single Service Provider
This is similar to Case 1, except that two clients are behind the same Large-Scale NAT (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.
Donley, et al. Informational [Page 6]
RFC 7021 NAT444 Impacts September 2013
2.1.3. Case 3: Two Clients, Two Home Networks, Single Service Provider
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.
Donley, et al. Informational [Page 7]
RFC 7021 NAT444 Impacts September 2013
2.1.4. Case 4: Two Clients, Two Home Networks, Two Service Providers Cross ISP
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.
The lab environment was intended to emulate multiple Service Provider networks with a CGN deployed and with connectivity to the public IPv4 or IPv6 Internet (as dictated by the coexistence technology under test). This was accomplished by configuring a CGN behind multiple cable modem termination systems (CMTSs) and setting up multiple home networks for each ISP. Testing involved sending traffic to and from the public Internet in both single and dual ISP environments, using both single and multiple home networks. The following equipment was used for testing:
o CGN
o CMTS
Donley, et al. Informational [Page 8]
RFC 7021 NAT444 Impacts September 2013
o Cable Modem (CM)
o IP sniffer
o RF (radio frequency) sniffer
o Metrics tools (for network performance)
o CPE (Customer Premises Equipment) gateway devices
o Laptop or desktop computers (multiple OSs used)
o Gaming consoles
o iPad or tablet devices
o other Customer Edge (CE) equipment, e.g., Blu-ray players supporting miscellaneous applications
One or more CPE gateway devices were configured in the home network. One or more host devices behind the gateways were also configured in order to test conditions, such as multiple users on multiple home networks in the CGN architecture, both in single and dual ISP environments.
The scope of testing was honed down to the specific types of applications and network conditions that demonstrated a high probability of diminishing user experience based on prior testing. The following use cases were tested:
Metrics data that were collected during the course of testing were related to throughput, latency, and jitter. These metrics were evaluated under three conditions:
1. Initial finding on the CGN configuration used for testing
2. Retest of the same test scenario with the CGN removed from the network
3. Retest with a new configuration (optimized) on the CGN (when possible)
In our testing, we found only slight differences with respect to latency or jitter when the CGN was in the network versus when it was not present in the network. It should be noted that we did not
Donley, et al. Informational [Page 10]
RFC 7021 NAT444 Impacts September 2013
conduct any performance testing and metrics gathered were limited to single session scenarios. Also, bandwidth was not restricted on the Data Over Cable Service Interface Specification (DOCSIS) network. Simulated homes shared a single DOCSIS upstream and downstream channel. (In the following table, "us" stands for microsecond.)
+---------+---------+---------+---------+-----------------+---------+ | Case | Avg | Min | Max | [RFC4689] | Max | | | Latency | Latency | Latency | Absolute Avg | Jitter | | | | | | Jitter | | +---------+---------+---------+---------+-----------------+---------+ | With | 240.32 | 233.77 | 428.40 | 1.86 us | 191.22 | | CGN | us | us | us | | us | +---------+---------+---------+---------+-----------------+---------+ | Without | 211.88 | 190.39 | 402.69 | 0.07 us | 176.16 | | CGN | us | us | us | | us | +---------+---------+---------+---------+-----------------+---------+
CGN Performance
Note: Performance testing as defined by CableLabs includes load testing, induction of impairments on the network, etc. This type of testing was out of scope for CGN testing.
The CGN was configured for the optimal setting for the specific test being executed for NAT444 or DS-Lite. Individual vendors provided validation of the configuration used for the coexistence technology under test prior to the start of testing. Some NAT444 testing used private [RFC1918] IPv4 space between the CGN and CPE router; other
Donley, et al. Informational [Page 11]
RFC 7021 NAT444 Impacts September 2013
tests used public (non-[RFC1918]) IPv4 space between the CGN and CPE router. With the exception of 6to4 [RFC3056] traffic, we observed no difference in test results whether private or public address space was used. 6to4 failed when public space was used between the CGN and the CPE router was public, but CPE routers did not initiate 6to4 when private space was used.
CPE gateways and client devices were configured with IPv4 or IPv6 addresses using DHCP or manual configuration, as required by each of the devices used in the test.
All devices were brought to operational state. Connectivity of CPE devices to provider network and public Internet was verified prior to the start of each test.
IP sniffers and metrics tools were configured as required before starting tests. IP capture and metrics data was collected for all failed test scenarios. Sniffing was configured behind the home routers, north and south of the CMTS, and north and south of the CGN.
The test technician executed test scenarios listed above, for single and dual ISP environments, testing multiple users on multiple home networks, using the applications described above where applicable to the each specific test scenario. Results and checklists were compiled for all tests executed and for each combination of devices tested.
3. Observed CGN Impacts
CGN testing revealed that basic services such as email and web browsing worked normally and as expected. However, there were some service-affecting issues noted for applications that fall into two categories: dropped service and performance impacted service. In addition, for some specific applications in which the performance was impacted, throughput, latency, and jitter measurements were taken. 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. So as to not become a comparison between different vendor implementations, these results are presented in summary form. When issues were identified, we worked with the vendors involved to confirm the specific issues and explore workarounds. Except where noted, impacts to NAT444 and DS-Lite were similar.
In 2010 testing, we identified that IPv6 transition technologies such as 6to4 [RFC3056] and Teredo [RFC4380] fail outright or are subject to severe service degradation. We did not repeat transition technology testing in 2011.
Donley, et al. Informational [Page 12]
RFC 7021 NAT444 Impacts September 2013
Note: While email and web browsing operated as expected within our environment, there have been reports that anti-spam/anti-abuse measures limiting the number of connections from a single address can cause problems in a CGN environment by improperly interpreting address sharing as too many connections from a single device. Care should be taken when deploying CGNs to mitigate the impact of address sharing when configuring anti-spam/anti-abuse measures. See Section 3.4.
Several peer-to-peer applications, specifically peer-to-peer gaming using Xbox and peer-to-peer SIP calls using the PJSIP client, failed in both the NAT444 and Dual-Stack Lite environments. Many CGN devices use "full cone" NAT so that once the CGN maps a port for outbound services, it will accept incoming connections to that port. However, some applications did not first send outgoing traffic and hence did not open an incoming port through the CGN. Other applications try to open a particular fixed port through the CGN; while service will work for a single subscriber behind the CGN, it fails when multiple subscribers try to use that port.
PJSIP and other SIP software worked when clients used a registration server to initiate calls, provided that the client inside the CGN initiated the traffic first and that only one SIP user was active behind a single IPv4 address at any given time. However, in our testing, we observed that when making a direct client-to-client SIP call across two home networks on a single ISP, or when calling from a single home network across dual ISPs, calls could neither be initiated nor received.
In the case of peer-to-peer gaming between two Xbox 360 users in different home networks on the same ISP, the game could not be connected between the two users. Both users shared an outside IP address and tried to connect to the same port, causing a connection failure. There are some interesting nuances to this problem. In the case where two users are in the same home network and the scenario is through a single ISP, when the Xbox tries to register with the Xbox server, the server sees that both Xboxes are coming through the same public IP address and directs the devices to connect using their internal IP addresses. So, the connection ultimately gets established directly between both Xboxes via the home gateway, rather than the Xbox server. In the case where there are two Xbox users on two different home networks using a single ISP and the CGN is configured with only one public IPv4 address, this scenario will not work because the route between the two users cannot be determined. However, if the CGN is configured with two public NAT IP addresses, this scenario will work because now there is a unique IP address with
Donley, et al. Informational [Page 13]
RFC 7021 NAT444 Impacts September 2013
which to communicate. This is not an ideal solution, however, because it means that there is a one-to-one relationship between IP addresses in the public NAT and the number of Xbox users on each network.
Update: in December 2011, Microsoft released an update for Xbox. While we did not conduct thorough testing using the new release, preliminary testing indicates that Xboxes that upgraded to the latest version can play head-to-head behind a CGN, at least for some games.
Other peer-to-peer applications that were noted to fail were seeding sessions initiated on BitTorrent and uTorrent. In our test, torrent seeding was initiated on a client inside the CGN. Leeching was initiated using a client on the public Internet. It was observed that direct peer-to-peer seeding did not work. However, the torrent session typically redirected the leeching client to a proxy server, in which case the torrent session was set up successfully. Additionally, with the proxy in the network, re-seeding via additional leech clients worked as would be expected for a typical torrent session. Finally, uTorrent tries to use Session Traversal Utilities for NAT (STUN) to identify its outside address. In working with vendors, we learned that increasing the STUN timeout to 4 minutes improved uTorrent seeding performance behind a CGN, resulting in the ability for the uTorrent client to open a port and successfully seed content.
FTP sessions to servers located inside the home (e.g., behind two layers of NAT) failed. When the CGN was bypassed and traffic only needed to flow through one layer of NAT, clients were able to connect. Finally, multicast traffic was not forwarded through the CGN.
Large size file transfers and multiple video streaming sessions initiated on a single client on the same home network behind the CGN experienced reduced performance in our environment. We measured these variations in user experience against a baseline IPv4 environment where NAT is not deployed.
In our testing, we tried large file transfers from several FTP sites, as well as downloading sizable audio and video files (750 MB to 1.4 GB) from the Internet Archive. We observed that when Dual-Stack Lite was implemented for some specific home router and client combinations, the transfer rate was markedly slower. For example, PC1 using one operating system behind the same home router as PC2 using a different operating system yielded a transfer rate of 120 kbps for PC1, versus 250 kbps for PC2. Our conclusion is that
Donley, et al. Informational [Page 14]
RFC 7021 NAT444 Impacts September 2013
varying combinations of home routers and CE-client devices may result in a user experience that is less than what the user would expect for typical applications. It is also difficult to predict which combinations of CPE routers and CE devices will produce a reduced experience for the user. We did not analyze the root cause of the divergence in performance across CE devices, as this was beyond the scope of our testing. However, as this issue was specific to Dual- Stack Lite, we suspect that it is related to the MTU.
While video streaming sessions for a single user generally performed well, testing revealed that video streaming sessions such as Microsoft Smooth Streaming technology (i.e., Silverlight) or Netflix might also exhibit some service impacting behavior. In particular, this was observed on one older, yet popular and well-known CPE router where the first session was severely degraded when a second session was initiated in the same home network. Traffic from the first session ceased for 8 s once the second session was initiated. While we are tempted to write this off as a problematic home router, its popularity suggests that home router interactions may cause issues in NAT444 deployments (newer routers that support DS-Lite were not observed to experience this condition). Overall, longer buffering times for video sessions were noted for most client devices behind all types of home routers. However, once the initial buffering was complete, the video streams were consistently smooth. In addition, there were varying degrees as to how well multiple video sessions were displayed on various client devices across the CPE routers tested. Some video playback devices performed better than others.
Since CableLabs completed initial CGN testing in 2010, there have been quantifiable improvements in performance over CGN since that time. These improvements may be categorized as follows:
o Content provider updates
o Application updates
o Improvements on the CGNs themselves
In terms of content provider updates, we have noted improvements in the overall performance of streaming applications in the CGN environment. Whereas applications such as streaming video were very problematic a year ago with regard to jitter and latency, our most recent testing revealed that there is less of an issue with these conditions, except in some cases when multiple video streaming
Donley, et al. Informational [Page 15]
RFC 7021 NAT444 Impacts September 2013
sessions were initiated on the same client using specific types of home routers. Applications such as MS Smooth Streaming appear to have addressed these issues to some degree.
As far as application updates, use of STUN and/or proxy servers to offset some of the limitations of NAT and tunneling in the network are more evident as workarounds to the peer-to-peer issues. Applications appear to have incorporated other mechanisms for delivering content faster, even if buffering times are somewhat slower and the content is not rendered as quickly.
CGN vendors have also upgraded their devices to mitigate several known issues with specific applications. With regard to addressing peer-to-peer SIP call applications, port reservations appear to be a workaround to the problem. However, this approach has limitations because there are limited numbers of users that can have port reservations at any given time. For example, one CGN implementation allowed a port reservation to be made on port 5060 (default SIP port), but this was the only port that could be configured for the SIP client. This means that only one user can be granted the port reservation.
There are other challenges that arise when using shared IPv4 address space, as with NAT444. Some of these challenges include:
o 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.
o 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 [RFC6269].
o Anti-spoofing - Multiplexing users behind a single IP address can lead to situations where traffic from that address triggers anti- spoofing/DDoS-protection mechanisms, resulting in unintentional loss of connectivity for some users. We have received reports of
Donley, et al. Informational [Page 16]
RFC 7021 NAT444 Impacts September 2013
such anti-spoofing/DDoS mechanisms affecting email and web services in some instances, but did not experience them in our environment.
The tables below summarize results from the 2010 NAT444 testing at CableLabs, Time Warner Cable, and Rogers Communications. They are included for comparison with 2011 results, documented above.
5.1. Case 1: Single Client, Single Home Network, Single Service Provider
Our testing did not focus on mitigating the impact of Carrier-Grade NAT, as described above. As such, mitigation is not the focus of this document. However, there are several approaches that could lessen the impacts described above.
+-----------------------+-------------------------------------------+ | Challenge | Potential Workaround(s) | +-----------------------+-------------------------------------------+ | Peer-to-peer | Use a proxy server; [RFC6887] | +-----------------------+-------------------------------------------+ | Gaming | [RFC6887] | +-----------------------+-------------------------------------------+ | Negative impact to | Deploy CGN close to the edge of the | | geolocation services | network; use regional IP and port | | | assignments | +-----------------------+-------------------------------------------+ | Logging requirements | Deterministic Logging [DETERMINE]; data | | for lawful intercept | compression [NAT-LOG]; bulk port logging | +-----------------------+-------------------------------------------+
CGN Mitigation
Other mitigation techniques that are currently being researched, such as [STATELESS], may also improve performance.
Donley, et al. Informational [Page 25]
RFC 7021 NAT444 Impacts September 2013
7. Security Considerations
Security considerations are described in [RFC6264] and [RFC6269].
In general, since a CGN device shares a single IPv4 address with multiple subscribers, CGN devices may provide an attractive target for denial-of-service attacks. In addition, as described in [DETERMINE], abuse attribution is more challenging with CGN and requires content providers to log IP address, source port, and time to correlate with Service Provider CGN logs. Also, if a CGN public IP address is added to a blacklist (e.g., for SPAM) or if a server limits the number of connections per IP address, it could negatively impact legitimate users.
8. Informative References
[DETERMINE] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., and O. Vautrin, "Deterministic Address Mapping to Reduce Logging in Carrier Grade NAT Deployments", Work in Progress, July 2013.
[NAT-LOG] Sivakumar, S. and R. Penno, "IPFIX Information Elements for logging NAT Events", Work in Progress, August 2013.
[NAT444] Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., and H. Ashida, "NAT444", Work in Progress, July 2012.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[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.
[RFC4689] Poretsky, S., Perser, J., Erramilli, S., and S. Khurana, "Terminology for Benchmarking Network-layer Traffic Control Mechanisms", RFC 4689, October 2006.
[RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, June 2011.
Donley, et al. Informational [Page 26]
RFC 7021 NAT444 Impacts September 2013
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013.
[STATELESS] Tsou, T., Liu, W., Perreault, S., Penno, R., and M. Chen, "Stateless IPv4 Network Address Translation", Work in Progress, October 2012.