Hopefully it is not news to you that allocations of IPv4 addresses from the Internet Assigned Numbers Authority (IANA) are currently forecast to be complete during the first half of 2011. Read Report… Allocations from the Regional Internet Registries are anticipated to be complete a year later, although the exact date will vary from registry to registry. This looming address crunch is causing Internet service providers (ISPs) around the world to start to question how they will continue providing IPv4 service for IPv4-speaking customers when there are no longer sufficient IPv4 addresses to allocate. Universal IPv6 deployment was originally thought to be the solution to ensure continued global addressability of an ever-expanding network. However, it appears likely that there will be a gap between the demise of the IPv4 free pool of addresses and the arrival of IPv6.
Several possible solutions aimed at bridging that gap are now emerging. In this article we discuss some of the criteria that will help the community evaluate the merits of those choices and we cover the common and potentially serious issues to which address sharing across multiple subscribers may inevitably give rise. In addition, while network operators are busy devising solutions to the addressing problem that is looming on the horizon, content providers are encouraged to consider the impact of shared addressing on their business and operational practices.
The end-to-end principle is the core architectural guideline of the Internet. Section 2 of RFC 3724 RFC 3724-The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture-provides a concise history of the end-to-end principle. While the original articulation was concerned with where best to place functionality in a communication system, the growth and development of the Internet have resulted in an expansion of the scope of the end-to-end principle. The principle now encompasses the question of where best to locate the state associated with Internet applications. This expanded principle is well articulated in RFC 1958: Architectural Principles of the Internet:
An end-to-end protocol design should not rely on the maintenance of state (i.e., information about the state of the end-to-end communication) inside the network. Such state should be maintained only in the endpoints, in such a way that the state can only be destroyed when the endpoint itself breaks (known as fate-sharing).
The end-to-end principle is, arguably, the fundamental principle of the Internet architecture. In a sense, the Internet is the embodiment of the principle. By allowing either tacit or explicit erosion of the principle as we apply our understanding to the construction and operation of the global network, we allow the dismantling of the utility itself. Unfortunately, address sharing threatens just such erosion.
Shared-addressing solutions are being proposed as pragmatic responses to the very real problems faced by operators who need to be able to continue providing service for customers who do not have IPv6-capable equipment or who want to access services that are available only via IPv4. However, while we advocate solutions that allow continued operation of the IPv4 Internet and the continued provision of services for IPv4-speaking customers, we do not in any way advocate prolonging the life of IPv4 or of any solution that delays the widespread adoption of IPv6.
Based on the importance of the end-to-end principle and the ultimate goal of global addressability through widespread IPv6 deployment as discussed earlier, solutions to the problem of how to continue providing IPv4 service post-IPv4-address completion should be judged on two primary criteria:
- The ability of the end user to readily control the parameters of the solution to minimize the impact of the solution on the end-to-end communication and
- The extent to which the solution affords a natural progression to widespread IPv6 deployment.
Adherence to these criteria will minimize the impact of address sharing on end-to-end communications, and it will keep the network on track toward the universal deployment of IPv6.
Potential Responses to IPv4 Address Shortages
Assuming ISPs wish to continue growing their businesses in a post-IPv4 world, there are a number of possible avenues they can take:
- Obtain previously allocated IPv4 addresses through some unspecified means;
- Deploy large-scale address translation and allocate customers with private addresses; or
- Deploy a port-shared addressing solution whereby customers would get public addresses with fewer available ports.
Let us deal with each of these in turn.
Obtain Previously Allocated Addresses
Acquisition of previously allocated IPv4 addresses by whatever means is a strategy with currently unknown (but definitely limited) viability. It is also impossible to estimate in advance the cost of such an approach, so it does nothing to minimize business risk. Acquiring previously allocated addresses may provide a short-term tactical solution whereby a relatively small number of addresses are required urgently to address a specific need. It is not a solution that has the potential for long-term network business growth. It is likely that previously allocated blocks acquired by whatever means will be small and that obtaining lots of contiguous small blocks may be impossible. This would inevitably lead to operational complexity and associated cost for the network operator taking this approach. In other words, except as a short-term solution, it is operationally unsustainable.
Deploy Large-Scale Address Sharing and Allocate Private Addresses
In light of the two criteria for judging solutions to the IPv4 address shortage that we have identified, so-called carrier- grade network address translation (NAT) proposals-otherwise known as CGN (I-D.nishitani-cgn)-raise several issues. Centralization of NAT functionality in the network core may reduce the abilities of end users to deploy applications as they wish without support from the network operator. This means that unadorned CGN solutions may struggle to meet the first criterion. Providing mechanisms for end users to control their treatment by the CGN may go some way toward mitigating that concern; however, those mechanisms would need to be very carefully engineered to avoid raising additional scalability and resilience concerns of their own. CGNs may create a single point of failure for all of their clients, and they may decrease the resilience of the network from an end user's perspective. CGN implementations may also struggle when considering the second criterion, as there is no requirement to make use of IPv6 technology as part of the solution. For these reasons there is a real risk that CGNs will do nothing to advance the state of IPv6 deployment; in fact, they will serve only to degrade the utility of the current network. However, for ISPs that don't have any control over their customer provided equipment (CPE), CGN is an obvious and flexible solution for continuing to provide IPv4 service post-runout.
While the subject of CGN deployment has arisen recently in the context of IPv4 address depletion, some operators, particularly mobile network operators, have long histories of allocating private addresses to their subscribers. Recent discussions have indicated that the increasing sophistication of both mobile handsets and the applications that run on them is driving operators of mobile networks toward public addressing solutions, including IPv6 deployment, to improve scalability and to minimize operating expenses. This suggests that those operators with real-world experience of CGN technology are already choosing to migrate away from it as a solution to their addressing needs.
Improving on CGN
How could we do better? There are proposals currently in the IETF that attempt to address one or both of the criteria identified earlier. These alternative proposals use IPv6 as a transport substrate for the legacy traffic [I-D.durand-softwire-dual-stack-lite]-thereby motivating IPv6 deployment-and may also ensure that control over the fate of end-user applications be kept as close to the end user as possible by distributing the NAT functionality toward the CPE [I-D.ymbk-aplusp]. However, some reduction of utility for IPv4-speaking Internet users is unavoidable in the future. It is inevitable that a reduced number of ports will be available for individual end-user applications. Operation of servers on well-known ports will most probably be an activity that is restricted to users willing to pay premiums for higher tiers of service contract. These may turn out to be good incentives for end users to migrate to IPv6.
Issues with Shared-Address Solutions
A number of proposals that came up for discussion as part of the Sharing of an IPv4 Address (shara) BoF meeting at IETF 74 in San Francisco rely on the concept of address sharing across multiple subscribers in order to achieve their goals. These proposals include carrier-grade NAT [I-D.nishitani- cgn], Dual-Stack-Lite [I-D.durand-softwire-dual-stack-lite], NAT64 [I-D.bagnulo-behave-nat64], IVI [I-D.baker-behave-ivi], Address+ Port proposals [I-D.ymbk-aplusp] [I-D.boucadair-port- range], and SAM [I-D.despres-sam]. In many operator networks today, a subscriber receives a single public IPv4 address at the subscriber's home or small business. Within that home or small business there is a NAT function that translates private addresses (RFC 1918 addresses) issued from devices within the home. All of those devices share the single public IPv4 address, and all are associated with a single small set of users and a single operator subscriber account. With the new proposals, a single public IPv4 address would be shared by a number of homes or small businesses, such as multiple subscribers, so the operational paradigm described earlier would no longer apply. All of the previously described proposals share a number of technical or operational issues, and these are addressed in the subsections that follow.
Fragmentation and Broken Applications
Address sharing has the potential to break a wide range of applications, such as applications that establish inbound communications, carry port information in the payload, carry address information in the payload, use well-known ports, do not use ports (Internet Control Message Protocol, or ICMP), assume uniqueness of IP addresses, or explicitly prohibit multiple simultaneous connections from the same IP address.
In addition, IP fragmentation will require special handling.
Port Distribution, Port Reservation, Port Negotiation
When we talk about port numbers, we need to make a distinction between outgoing connections and incoming connections. For outgoing connections, the actual source port number used is usually irrelevant. But for incoming connections, the specific port numbers allocated to customers matter because they are part of external referrals; in other words, third parties use them to contact services run by the customers. It is desirable to make sure those incoming ports remain stable over time, which is challenging because the network does not know anything in particular about the applications that it is supporting. The network has no real notion of how long an application or service session will remain ongoing and, therefore, how long it will require port stability. According to actual measurements, the average number of outgoing ports per customer is much, much smaller than the maximum number of ports a customer can use at any given time. However, the distribution is heavy tailed, so there are typically a small number of subscribers who use a very high number of ports [CGN_Viability]. This means that an algorithm that dynamically allocates outgoing port numbers from a central pool is much more efficient than are algorithms that statically divide the resource by pre-allocating a fixed number of ports to each subscriber. Similarly, such an algorithm should be better able to accommodate users wishing to use a relatively high number of ports. Early measurements also seem to indicate that, on average, customers use very few ports for incoming connections. However, a majority of subscribers accept at least one inbound connection. That means it is not necessary to pre-allocate a large number of ports to each subscriber. It is possible, however, to either pre-allocate a small number of ports for incoming connections or do port allocation on demand when the application wishing to receive a connection is initiated. The bulk of ports can be reserved as a centralized resource shared by all subscribers using a given public IPv4 address.
A potential problem with this approach occurs when one of the subscriber devices behind such a port-shared IPv4 address becomes infected with a worm, which then quickly sets about opening many outbound connections in order to propagate itself. Such an infection could rapidly exhaust the shared resource of the single IPv4 address for all of the connected subscribers. The poor network hygiene of one subscriber now threatens the connectivity for all of the immediate network neighbours.
Connection to a Well-Known Port Number
Once a port-address-mapping scheme is in place, connections to well-known port numbers will not work in the general case. Given sufficient incentives, a workaround, such as redirects to a port-specific URL, could be deployed. Some of the existing proposals for application-service-location protocols would provide a means for addressing this problem, but historically, those proposals have not gained much deployment traction.
Universal Plug and Play
Using the Universal Plug and Play (UPnP) semantic, a client asks, “I want to use port number X. Is that OK?”? The answer is yes or no. If the answer is no, the client will typically try the next port until either it finds one that works or, after a limited number of attempts, it gives up. To date, UPnP has no way to redirect the client to use another port number, although UPnP IGD 2.0 will most likely fix this for new or upgraded devices. Network addressing translation-port mapping protocol (NAT-PMP) has a better semantic, thereby enabling the NAT to redirect the client to an available port number.
Security and Subscriber Identification with IPv4
Nowadays, a report of abuse is usually in the following form: “IPv4 address x has done something bad at time t0.”? This is not enough information to uniquely identify the subscriber responsible for the abuse when IPv4 address x is shared by more than one subscriber. This particular issue can be fixed by logging port numbers, but the operations support system will still require updates to deal with service activation, subscriber profile management, and lawful interception.
A number of application servers on the network today log IPv4 addresses in connection attempts to protect themselves from certain attacks. For example, if a server sees too many log-in attempts from the same IPv4 address, it may decide to put that address in a penalty box for a certain time. If an IPv4 address is shared by multiple subscribers, this would have unintended consequences in a couple of ways. First, it may become the natural behaviour to see many log-in attempts from the same address because it is now shared across a potentially large number of users. Second, and more likely, one user who fails a number of log-in attempts may block out other users who have not made any previous attempts but who will now fail on their first attempt. Moreover, the assumption that a single IPv4 address maps to a single user may be used for other purposes, such as geolocation or counting the number of individual users of a service. All of those things may become more complicated when several subscribers share an IPv4 address at the same time.
Port randomization, which is used for mitigation of blind attacks against established transport connections, will have reduced effectiveness as port entropy gets reduced. In addition, good randomization functions on the operating system may be defeated by nonimplementation on address-sharing CPE.
To some extent, the problems of shared addressing are already with us due to the prevalence of dynamically assigned addresses to domestic broadband subscribers and the use of CPE NAT. However, the point here is that the widespread adoption of port-shared addresses by service providers will make those complications considerably more widespread and more severe.
As we approach the completion of IPv4 address allocations from the IANA, there are various options available to service providers. Of those options, some of the shared-address solutions seem to offer an approach consistent with the long-term goal of IPv6 deployment and to provide maximal preservation of the end-to-end principle. Nevertheless, it must be emphasized that all shared-addressing solutions have a number of common and potentially serious issues. Address sharing among multiple subscribers inevitably will result in a degraded experience of the network for many users, as well as increased operating costs for ISPs. Content providers are encouraged to consider carefully the potential impact of shared addressing on their business and operational practices.
This article was largely inspired by conversations that took place as part of an Internet Society-hosted roundtable event for operators deploying IPv6. The participants in that discussion were John Brzozowski, Leslie Daigle, Wes George, Christian Jacquenet, Tom Klieber, Yiu Lee, and Kurtis Lindqvist.
[CGN_Viability] Alcock, S., “Research into the Viability of Service-Provider NAT,”? 2008.
[I-D.bagnulo-behave-nat64] Bagnulo, M., Matthews, P., and Beijnum, I., “NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers,”? draft-bagnulo-behave-nat64-02 (work in progress), November 2008.
[I-D.baker-behave-ivi] Li, X., Bao, C., Baker, F., and Yin, K., “IVI Update to SIIT and NAT-PT,”? draft-baker-behave-ivi-01 (work in progress), September 2008.
[I-D.boucadair-port-range] Boucadair, M., ed., “IPv4 Connectivity Access in the Context of IPv4 Address Exhaustion,”? , January 2009.
[I-D.despres-sam] Despres, R., “Stateless Address Mappings (SAMs) IPv6 & Extended IPv4 via Local Routing Domains-Possibly Multihomed,”? draft-despres-sam-01 (work in progress), November 2008.
[I-D.durand-softwire-dual-stack-lite] Durand, A., Droms, R., Haberman, B., and Woodyatt, J., “Dual-Stack Lite Broadband Deployments Post IPv4 Exhaustion,”? draft-durand-softwire-dual-stack-lite-01 (work in progress), November 2008.
[I-D.nishitani-cgn] Nishitani, T., Miyakawa, S., Nakagawa, A., and Ashida, H., “Common Functions of Large Scale NAT (LSN),”? draft-nishitani-cgn-01 (work in progress), November 2008.
[I-D.ymbk-aplusp] Maennel, O., Bush, R., Cittadini, L., and Bellovin, S., “The A+P Approach to the IPv4 Address Shortage,”? draft-ymbk-aplusp-02 (work in progress), January 2009.
[IPv4_Report] Huston, G., “IPv4 Address Report”?, 2009.
[RFC1958] Carpenter, B., “Architectural Principles of the Internet,”? RFC 1958, June 1996.
[RFC3724] Kempf, J., Austein, R., and IAB, “The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture,”? RFC 3724, March 2004.
Note: For another perspective on address sharing, see the article entitled NAT++: Address Sharing, by Geoff Huston, which appeared in the April 2009 edition of the ISP Column.