The Road To IPv6 Is Paved With NATs

Even though IPv6 adoption is dangerously slow, we will see adoption eventually. There are three main sections of the Internet that need to handle IPv6. The Internet networking equipment like routers, proxies and firewalls, and services like DNS and routing need to support IPv6 so that clients can talk to servers that users are connecting to from giants like Google and Amazon to smaller web, email and other hosts. Then, there are the enterprise and consumer products that will connect to Internet hosts. The question remains how to deliver IPv6 services in a non-disruptive manner to consumers in homes, small businesses and enterprises, all of whom can't control either the content being provided or the consumers visiting that content.

To this point, IPv6 adoption on the broader Internet remains in its infancy. The 2,500 IPv6  prefixes announced today on the Internet are a fraction of the 300,000 IPv4 announcements, says Earl Zmijewski, vice president and general manager at Renesys. What's more, most of these IPv6 announcements are run by research institutions, he says.

The limited number of IPv6 networks makes the IPv6 Internet fairly brittle. In one recent instance, a IPv6 provider stopped exchanging routes with Hurricane Electric, the largest IPv6 transit provider in the world today, cutting off a major portion of the IPv6 Internet from one another.  That event has raised concerns about the IPv6 Internet's maturity. "The question still stands about the stability, and therefore, utility of the IPv6 'Net. Is it still some bastard child, some beta test, some side project? Or is it ready to have revenue producing traffic put on it? When a network as solid and customer-oriented as  HE [Hurricane Electric] can have a long outage to such a large network as Telia, I submit  it is not," Patrick W. Gilmore says in a recent post on the North American Network Operators Group (NANOG). Gilmore is principal architect at Akamai Technologies and a NANOG steering committee.

Greater network adoption is needed to prevent these sort of outages that the IPv4-based Internet hasn't seen since its early days. Part of the problem, say IPv6 operators, has been the lack of carrier equipment. "As IPv6 is newer than IPv4, the equipment to support IPv6 natively is newer than legacy equipment already deployed that only supports IPv4," wrote Mike Leber, president of Hurricane Electric, in an email. "As the equipment that supports native IPv6 is newer, there are fewer core networks that run native IPv6. As these new IPv6 networks are deployed they are growing and developing."

Even with more IPv6 gear, operators need to find away to provide an incentive for customers to want to be on IPv6, and that comes down to content. Except for a few notable examples, such as the 2008 summer Olympics, very little of the Internet's content has been IPv6 accessible. "Until that changes there will be no IPv6 adoption," says Zmijewski. Instead, there's a push to create and deploy larger Network Address Translation (NAT) devices within service provider networks. Today, NATs exist at the network edge, between the service provider and the organization's networks. These NATs, technically called NAT44s, public IPv4 addresses amongst private IPv4 address holders (hence the name NAT(IPv)4(IPv4).Increasingly, providers are talking about aggregating their customers behind a super NAT called Carrier Grade NAT (CGN) or Large Scale NAT (LSN). Under LSN, service providers will assign private IPv4 addresses to their customer. The service providers will convert those IPv4 addresses into routable IPv4 addresses when leaving their networks for the greater Internet.  

A hierarchical NAT tree is created with the LSN facing other providers sharing publicly routable IPv4 addresses amongst customers each with a private IPv4 address. Each customer would then share that private IPv4 address amongst the devices and users on its networks. In fact, the configuration will be even more complicated with the multiple LSNs behind one another in the hierarchy, as well. The LSNs would be referred to as NAT444s, converting from customer's private IPv4 address to a service provider's private IPv4 address to a publicly routable IPv4 address.

Today, most firewalls and ACLs will reject packets with private source addresses. LSNs will then need to be responsible for assigning public addresses to packets staying within their networks (a process called hair-pinning), so that they can traverse the enterprise perimeter. What's more, the potential for misrouted packets is introduced as service providers and private enterprises could end up using identical addresses. Three solutions are widely seen to the problem:

LSNs introduce significant engineering complexity into the network, though. Each NAT represents tens of computers if not more, each computer handling several sessions. LSNs end up having to maintain state on tens of thousands, if not hundreds of thousands, of sessions. A significant amount of testing and field experience will be needed to understand just how far LSNs can scale. The NAT also violates the basic design philosophy that calls for a fast, packet forwarding core and an intelligent edge. This model allows for new protocols and applications to be deployed without the consent of the service provider. It gives maximum freedom to users and has allowed the variation of applications and protocols that is the internet today. LSNs and NATs in general violate that principle by centralizing intelligence in the NAT in the carrier's core. This suggests that as customer deploys new applications that might need to interact with the NAT, they'll need to get their provider's consent first.

Like Y2K, IT professionals need to plan for the transition to IPv6. In part this means insuring that IPv6 support is a part of all RFIs going forward and verifying IPv6 support amongst deployed equipment. They ought to also pay close attention to how service providers will evolve their networks towards IPv6. The changes operators make could well disrupt critical corporate applications and technologies. At the very least, a viable IPv6 transition story will be necessary if the organization is to continue growing its Internet operations.