As we discussed recently, some U.S. network operators have begun to pave the way for customers to use IPv6. A critical first step is to deploy dual stack networks capable of carrying IPv4 and IPv6 side by side—a step that many carriers already have taken in their backbone networks and in connections to some enterprise customers.

As Owen DeLong, IPv6 evangelist for Internet service provider Hurricane Electric, explained, some carriers -- including Comcast and AT&T -- have begun to extend their dual stack networks all the way to residential end users. In addition those carriers have begun to provide IPv6-capable devices and to assign both an IPv4 and an IPv6 address to the end user. When all of this is in place, a customer can communicate with IPv4 or IPv6 endpoints.

The question now is whether, when these efforts are completed, the service providers will be ready for the day when their supply of IPv4 addresses runs out. The current practice of assigning both types of addresses to an end user enables the end user to communicate with endpoints that have either type of address. But when service providers have to start assigning only IPv6 addresses, the end users receiving only that type of address will not be able to reach endpoints that only have IPv4 addresses unless certain additional steps are taken.

Some service providers apparently are betting that their stock of IPv4 addresses is sufficiently large that by the time they run out, virtually all endpoints will be IPv6-capable. Those without a large store of IPv4 addresses – or those who just want to hedge their bets – may be looking to implement something known as carrier-grade network address translation (CGN) or an alternative option called NAT64.

Carrier NAT options

Many readers may be familiar with network address translation in the enterprise or home networking domain, where it enables multiple devices on an enterprise or home local area network to share a single IP address to the outside world. CGN and NAT64 have similar goals, except that the shared address is in the carrier network and it’s a special IPv4 address reserved for that purpose.

Just as enterprise NAT enables an Internet endpoint to connect to an individual computer or other device on a LAN, CGN and NAT64 aim to enable an IPv4 endpoint to use the carrier’s NAT infrastructure to communicate with customers whose only publicly routable addresses are IPv6.

With NAT64, the carrier takes full responsibility for network address translation when the customer needs to communicate with an IPv4-only endpoint. Network address translation is no longer used at the customer premises even if the customer has a LAN.

CGN, on the other hand, is used in combination with traditional enterprise NAT – and the combination of the two is known as NAT444.

 Carrier NAT concerns

DeLong sees potential problems with both of these solutions, but he sees CGN and NAT444 as the most problematic.

One concern with CGN, he said, is that while enterprise-grade NAT includes technology to enable traffic to traverse the enterprise firewall, things are different in the carrier domain. “The second layer of NAT won’t have all the traversal technologies because a lot of them don’t scale to the service provider and most are not designed to cope with the second layer anyway,” he said. 

And when CGN is combined with traditional enterprise NAT to support NAT444, the two layers of NAT can create other problems. Applications such as web browsing may work OK through two layers of NAT, according to DeLong. But he said, “What will break are instant messaging, VoIP and certain kinds of streaming. Also complicating matters, he said, is the fact that the second layer may or may not have a SIP applications gateway.

And both forms of carrier-focused NAT – including NAT64 and NAT444 with CGN – may have a problem with the fact that “the way VOIP works is the person placing the call sends an invite message in one protocol to telephony software at the other end saying ‘Please connect your audio stream on this address,’” said DeLong. That’s challenging when not all of the devices involved in supporting the call are aware of what that address is, he said.

A lot of people are doing a lot of research to address issues such as these, DeLong said, but to date solutions have proved elusive.

The upshot

When all is said and done, DeLong believes NAT64 will mostly be adopted only by mobile carriers. Any landline carriers that make the decision to deploy a carrier-focused NAT solution are likely to opt for something based on CGN, DeLong said.

That matches with what I heard from Rob Fleischman, chief technology officer for Xerocole, a developer of domain name server (DNS) technology. Fleischman said his company is seeing little interest in its DNS64 solution – and such a solution typically would be needed to implement NAT64.

DeLong conceded that although NAT64 is more efficient and requires fewer resources, NAT traversal techniques in some cases require applications to be aware of the inside and outside addresses of their connection. Making an IPv4 endpoint aware of a client’s IPv6 interior address behind NAT64 would, in most cases, be more complicated than just adding IPv6 capabilities to that endpoint, he said. NAT444 on the other hand may allow those problems to be solved within the NAT mechanisms and not at the application level, even though it will be quite a bit more complex in both development and implementation to do so, he said.

It’s easy to see why carriers who believe they have ample IPv4 addresses may simply prefer to avoid the hassle of deploying any of these options.

It’s also possible that if a carrier has any doubts about its IPv4 reserves, it may perceive that a less risky solution would be to simply obtain more IPv4 addresses in the aftermarket. 

No wonder those addresses are selling for as much as $10 each.