Latest News and Events
November 22, 2016
BITAG Publishes Report: Internet of Things (IoT) Security and Privacy Recommendations
June 28, 2016
BITAG Announces Technical Review Focused on Internet of Things(IoT) Security and Privacy Recommendations
Oct 8, 2015
BITAG Publishes Report: Differentiated Treatment of Internet Traffic
Apr 14, 2015
BITAG Announces Technical Review Focused on Prioritization and Differentiated Treatment of Internet Traffic
Dec 1, 2014
BITAG Publishes Report: Interconnection and Traffic Exchange on the Internet
June 18, 2014
BITAG Announces Technical Review Focused on Internet Interconnection
May 29, 2014
BITAG Publishes Report on VoIP Impairment, Failure, and Restrictions
October 2013
BITAG Publishes Annual Report
October 2013
BITAG Publishes Report on Congestion Management
August 2013
BITAG Publishes Report on Port Blocking
March 2013
BITAG Announces Next Technical Topic on Congestion Management
Large Scale Network Address Translation

Large Scale Network Address Translation
A Broadband Internet Technical Advisory Group Technical Working Group Report.

Please direct comments on the substance of the report to
* Suggested Citation: Broadband Internet Technical Advisory Group (BITAG), Implications of Large Scale Network Address Translation (2012),


The Internet is running out of addresses in the format in which they were originally standardized, known as IPv4, due to aspects of that format which constrain the address space to a relatively "small" number of unique addresses as compared to the burgeoning number of devices requiring those same addresses to function on the Internet. A successor address format, IPv6, has been developed to support as many devices as can conceivably be connected to the Internet for the foreseeable future. While the global transition to IPv6 is in progress, it is going to take a number of years to upgrade all Internet applications and services, consumer electronics devices, and networks to support IPv6. The transition period is also likely to be lengthy given that, among other things, IPv4-only equipment is still being manufactured and sold to consumers. As network operators deploy IPv6 technology into their existing IPv4 networks, IPv4 and IPv6 will thus need to co-exist until the demand for IPv4 services diminishes.

Given the amount of time it may take to migrate out of a pure IPv4, or mixed IPv4 and IPv6 network environment, to pure IPv6 service, network operators are employing a variety of techniques to extend the life of IPv4 addressing. One such technique is the use of Large Scale Network Address Translation (also known as Large Scale NAT or LSN). LSN equipment allows a large number of IPv4-enabled end devices to share a single public IPv4 address. Network Address Translation (NAT) functionality has long existed in local/private networks to help network operators manage their network addresses using private address space. NAT functionality is known to adversely impact some Internet applications; wider use of NAT as part of LSN therefore deserves careful examination.

The BITAG is interested in LSN given that IP address sharing is a key tool for extending the life of IPv4 during the transition to IPv6. LSN is likely to affect many players in the Internet ecosystem: ISPs, end users, application providers, equipment vendors, content delivery networks, and third parties such as law enforcement agencies. A broad understanding of problems that may arise has the following benefits: (1) it will help stakeholders to prepare for actions that minimize the impact on end users and applications; (2) it will inform policymakers and regulators of the motivations and trade-offs for the deployment of this technology; (3) it will accelerate the transition to IPv6; and (4) it will more generally help to reduce or preclude friction and/or conflict surrounding use of this technique among stakeholders, as some have argued that Large Scale NAT could be abused by parties for anti-competitive, discriminatory, or other non-technical purposes.

LSN Deployments and Impacts

LSN will be deployed in different ways depending on which IPv6 transition technologies are in use. These alternatives are discussed in the body of this paper. For all of these alternatives, there are a variety of technical implications of LSN for end users, ISPs, and application providers to consider.

The address sharing enabled by LSN use impacts end users in three primary ways: (1) the number of connections available per user is affected, (2) the ability to uniquely identify an end user device solely via the source IP address is lost, and (3) it becomes much more difficult to reach and maintain connectivity to end user devices. All of these impacts are present in local/private network implementation of NATs. Introduction of LSN increases the probability that users will be affected due to sharing of the port number space. The number of users affected by the limitation in port availability may also increase for the same reason. However, note that a user checking email or performing simple web browsing functions will not be affected by the LSN.

Internet Service Providers (ISPs) electing to use LSNs must balance the impacts of new network infrastructure (operational and capital costs) and of engineering this new infrastructure for scalability, resiliency, security, and capacity, as well as meeting mandates to be able to log individual customer IP address assignments, with maintaining an appropriate level of customer service. In the mobile environment, where every device must be assigned at least one IP address and where simple devices may have limited access to Internet applications, mobile operators have already implemented LSN and faced some of these challenges. However, the continued swift growth in the number of mobile customers and their likely evolution toward expecting wireless Internet service to behave in a manner comparable to wireline service presents new challenges.

LSN can have a wide variety of impacts on applications. These may relate to capacity constraints if the LSN is undersized, the handling of multiple connections to the same application server, the loss of IP-based geolocation capability, new logging requirements, and a variety of other factors.


BITAG has compiled the following recommendations regarding steps that can be taken to help ensure optimal user experience, balanced with efficient LSN deployments and operations:
  • Commit to rapid deployment of IPv6. The best way to mitigate the impacts of LSN is to reach a state where IPv6 is the dominant addressing scheme. BITAG suggests that ISPs deploy IPv6, that equipment manufacturers support IPv6 in their devices, and that applications sensitive to NAT be supported via IPv6 as soon as possible.
  • Address application impacts of LSN. BITAG suggests that vendors of LSN equipment adhere to existing requirements [Common requirements for Carrier Grade NAT (CGN)] intended to increase the likelihood that applications will function properly in the presence of LSN. BITAG also suggests that ISPs test their LSN implementations and mitigate application issues prior to deployment, and that application developers use LSN work-arounds or avoid deploying services that do not function properly in the presence of NAT or LSN.
  • Disclose LSN deployment. To assist with end user troubleshooting, BITAG suggests that ISPs be transparent with respect to the locations and timing of LSN deployment.
  • Provide mechanisms to facilitate LSN traversal to end users. BITAG suggests that, where feasible, ISPs and equipment vendors support mechanisms to facilitate NAT traversal, including mechanisms for the manual or automatic creation and management of port forwarding rules. Such mechanisms increase the likelihood that applications requiring inbound connections to end users can function across LSN.
  • Provide contact information. BITAG suggests that ISPs provide a means for application providers to contact them to discuss LSN impacts and possible mitigations.
  • Consider Logging Impacts of Port Allocation. BITAG suggests that ISPs deploying LSN consider logging and operational impacts when deciding whether to implement a deterministic or dynamic mechanism (or a hybrid of the two) for assigning ports to subscriber sessions.
  • Include Port Number When Logging Activity. BITAG suggests that Application Providers that maintain a log of user activity include both the IPv4 address and port number in the log. This would ensure that logs accurately reflect the actions of a single ISP customer when IPv4 traffic goes across a LSN.

* Suggested Citation: Broadband Internet Technical Advisory Group (BITAG), Implications of Large Scale Network Address Translation (2012),