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
Hurricane Electric

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.