Carrier Grade NAT – A Look at the Tradeoffs

Owen DeLong is Director of Professional Services at Hurricane Electric, the world’s largest IPv6-native Internet backbone and leading colocation provider. Owen, who is also an IPv6 Evangelist, has more than 25 years of industry experience.

Owen-DeLong-tn

Imagine a restaurant parking lot where each space is permanently assigned to a single patron's car. This would be very counter-productive because you could never have a big enough parking lot and the vast majority of the lot would go unused the majority of the time. Since there's only so much space and no way to make more, it's a terrible waste of that space. Given limited space, it's important to come up with a better solution. If things aren't too crowded, we simply let customers park where there's a space and the space is only tied up for that customer so long as they are at the restaurant. When someone leaves, another customer can use the space.

However, what happens if the restaurant grows or the parking lot shrinks?  Remember, we can't create more space.  Usually a combination of clever ways to park more vehicles in the same space is developed, and valets manage the insertion and removal of vehicles from those tighter spaces. Sometimes the valet may have to park in an alternate lot off-site. The valet maintains a translation table of keys to a cars' locations.

Clearly, the ideal scenario would be if we could make more space. That's what IPv6 does for us. In fact, if IPv6 addresses were parking spaces, IPv6 would literally allow us to park every car ever built in each parking lot and still have 4 billion more spaces for each and every car ever built in each parking lot.  Further, we have enough room for every single restaurant, building, house, apartment, condo, shack, shed, office, and any other structure, building, or tenant to have 65,536 such parking lots and still leave more than half of the space unpaved and unused.

However, faced with having to cope with IPv4 for a few more years, we need to consider the finite space scenario in a little more detail. The first scenario above (permanent parking-space assignments) is akin to static IP addressing. It's the most efficient way to always know where your car is, but it uses up space very quickly. The second scenario (park wherever you can find a space, but only in the one lot) is like DHCP (Dynamic Host Control Protocol), where addresses are allocated as needed. The third scenario (valet!) seems better still, because, at least from the diners' perspective, there's unlimited parking. However, valet in the Internet Protocol space is NAT (Network Address Translation) and it comes with downsides greater than waiting, tipping, and the occasional door ding.

Times Are Changing

We've been living with some of these tradeoffs and worked around others in traditional NAT for a long time, but now, the valets are having to get more creative as all the parking lots within running distance are getting full.

The IETF defines Carrier-Grade NAT (CGN) as large-scale Network Address Translation (NAT) implemented by a service provider.  In most cases, CGN is implemented as a layer of IPv4-to-IPv4 NAT on top of the “traditional” NAT implemented at the subscriber side of the connection.

There are significant challenges introduced by CGN that merit serious consideration by the service provider (and the subscriber). Traditional NAT is implemented on the subscriber side of the connection, which means that a single public IP address presented to the Internet uniquely identifies a subscriber.  A significant amount of internet infrastructure relies on this assumption; violating it is likely to affect law enforcement, civil litigation, geo-location and more. In CGN, this fundamental assumption is broken, so carriers that implement it will need the source address, the port number and the time in order to have any hope of identifying the subscriber behind a given Internet transaction. Presently, however, most servers do not log source-port numbers for incoming connections.

If a CGN implementation used the same ad-hoc port allocation as traditional NAT, then logs of these dynamic port mappings would be needed for subscriber identification. For a small number of subscribers (8,000, say), nearly a terabyte per day of logging information could be generated.  As such, CGN is unlikely to make use of ad-hoc port allocation.  Instead, subscribers could be statically mapped to port ranges. Unfortunately, this approach has two disadvantages. First, ports (and by extension, addresses) must be held in reserve for customers who are not active. Second, the number of ports (and by extension, the number of concurrent transactions or sessions per subscriber) will be limited. In order to achieve significant address conservation, ISPs using CGN will be faced with very real tradeoffs between subscriber experience and address consumption.

Control Points

The next key difference between traditional NAT and CGN is the control point. In traditional NAT, the subscriber can control the NAT device and create static inbound mappings that allow bidirectional connectivity not necessarily initiated by the subscriber. More commonly, a slightly different form of inbound mapping, accomplished through processes known as uPNP or NAT-PMP, is made by applications without direct user intervention. Neither of these mappings is supported by CGN, so applications dependent on these mappings will break in most CGN scenarios. Susceptible applications include most forms of peer-to-peer applications, multiplayer online games, many VOIP-style services and some forms of instant messaging.

As providers implement these NATs, they will likely be regionalized. For the provider, it is much simpler and more economical to locate a few large NAT centers in a small number of locations than to distribute these capabilities around their network.  Unfortunately, this means that instead of the current path from subscriber->provider->Internet, the path in a CGN environment is expanded to subscriber->provider->NAT Center->provider->Internet.

Consider a subscriber in San Jose wants to view a website in San Francisco. Today, his browser traffic follows a path that may go as far away as Sacramento (about 200 miles San Jose->Sacramento->San Francisco). In the CGN world, however, the nearest NAT center may be Los Angeles or even Denver, expanding the path to a little over 2,000 miles in the case of Denver, and about 600 miles in the case of Los Angeles, so a 3x to 10x increase in packet delay times.

Finally, geolocation data for the public side of these NATs will likely reflect the location of the regional NAT center and not the subscriber's actual location. Geolocation of IP addresses is already of dubious accuracy, but CGN will make it significantly worse. Imagine being in San Francisco and having a web site think you are looking for things near your current location (which it thinks is San Jose, Los Angeles, or even Denver).

Is CGN an Effective Alternative to IPv6?

Because of the way things have evolved, the question isn't whether to implement CGN, but rather whether CGN is an effective - or even a viable - alternative to IPv6. On this question, two fundamental camps have emerged.

The first camp views CGN as a necessary interim solution on the way to IPv6 transition in order to accommodate subscribers who can't get public IPv4 addresses due to shortage. This camp will deploy CGN only when their IPv4 addresses space is nearly exhausted and when IPv6 is not an option, due to technological limitations of the subscriber, the destination, or even (in rare cases) the provider. This camp will have strong incentive to encourage as many others as possible to deploy IPv6 technologies in order to reduce the load and minimize the required investment in CGN capabilities.

The second camp is a bit more problematic. This camp believes that because they have to implement CGN anyway, they might as well just transition to CGN and avoid investing in IPv6 deployment.  This camp views an Internet with all (or nearly all) subscribers behind CGN as viable, and favors the universal deployment of CGN.  This second approach is insidious, because it creates a number of initial advantages but an even larger set of long-term drawbacks.

Benefits and Drawbacks

Almost all of the advantages of the second approach are immediate and accrue to the benefit of the provider, while almost all of the immediate drawbacks impact the subscriber. The advantages include a lower initial cost of staff training (most network engineers already understand NAT fundamentally, whereas IPv6 requires significant training). Also, in the short-term it is cheaper to add a few CGN gateways to a network than to roll out IPv6 to all subscribers. Furthermore, while most IPv6 deployments don't represent significant revenue for equipment vendors, CGN is a massive opportunity for huge hardware sales – creating strong economic incentives for vendors to push CGN solutions even (or especially) in cases where IPv6 is a more cost effective solution for the provider in the long term.

Subscribers’ drawbacks are severe and far outweigh the providers’ benefits. First, traditional NAT – and also CGN - block real innovation in Internet applications. CGN workarounds are often hopelessly complex and interfere with Internet applications in often non-deterministic ways. And not only does CGN block future innovation, it also rolls back some of the advances made in overcoming the limitations of traditional NAT.

One of the main barriers to IPv6 deployment at this point is the effort involved in upgrading applications and updating legacy embedded systems (such as home entertainment devices, printers, etc.). However, if CGN becomes widely accepted, this same effort will also be required in order to work around the above difficulties. As such, allocating development resources to CGN workarounds instead of IPv6 deployment is a somewhat self-defeating proposition.

To make matters worse, only technically astute subscribers are likely to be able to understand what is causing these new drawbacks. Most likely, the service provider will market CGN as "improved security" or some other vague positive sounding claim. The disadvantages that accrue to the provider come mainly in the form of gradually increasing long-term costs and the costs of increased helpdesk calls. While helpdesk calls are an extremely detrimental expense for service providers, their impact is usually underestimated (often considerably) when evaluating technologies such as CGN.  While both CGN and IPv6 can be implemented incrementally over time, unless one does a very thorough analysis, CGN will appear – falsely - to offer smaller steps and lower costs. Only IPv6 completely eliminates the need for NAT and CGN, freeing the subscriber from their limitations.

Further, those who fail to deploy IPv6 in addition to their CGN will increase not only their own costs, but, by extension, the costs to everyone else in order to operate their networks. The longer the transition towards IPv6 lasts, the more expensive continuing to operate the IPv4 internet will become. If we all move forward together, everyone benefits. The longer we delay this progress, the more everyone will pay. Unfortunately, if one takes only a short-term view of the economics, holding off on IPv6 can appear to provide short-term savings while deploying IPv6 can appear as an unjustified cost. At the end of the day, we're all in this together and the stakes are nothing short of the future of the internet which has always depended on the good will of people choosing to do the right thing whether or not there was a business case for it.

Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating. View previously published Industry Perspectives in our Knowledge Library.