Internet service providers are circling carrier-grade or large-scale network address translation as a strategy that would allow them to cling to IPv4 for longer, further delaying moves to adopt IPv6.
NAT was developed in the 1990s when the IPv4 address exhaustion problem first arose. The thinking behind NAT is to conserve the number of publicly visible and therefore unique IPv4 addresses through reuse of private addresses for devices in internal networks.
Under NAT, one or more Internet-visible addresses acts as a network gateway, “translating” traffic to and from private, internal networks that cannot be directly reached from the outside world.
That way, one public IPv4 address can “hide” many private ones. Home networks almost exclusively use such address sharing, as do many corporate ones.
While NAT used to be confined to the edge of networks, what is now being proposed and trialled is to use address sharing closer to the core of providers’ networks.
Providers such as BT’s Plusnet in the United Kingdom are already trialling CGNAT to use an alternative to IPv6. It sees IPv6 being "years away" and believes that everyone will still need an IPv4 address for the foreseeable future.
iiNet chief technical officer John Lindsay doesn’t expect iiNet to deploy IPv4 CGNAT for the next few years, but says the provider uses CGNAT for its wifi network and through its many load balancers and servers.
“We may use it in the future for fixed-line customers, but only in a world where they have a real IPv6 connection too, and the IPv4 layer is legacy glue,” Lindsay says.
CGNAT — where several customers share one public IP address — isn’t without its share of problems.
Most internet users will never notice CGNAT.
“Most end users see the world via web browsers and email clients. They live in a world of domain names and email addresses,” Lindsay says. “The encapsulation of that traffic through IPv4 or IPv6 is a hidden layer that doesn’t trouble users."
However, customers hosting a small website or playing games on broadband connections may not be so lucky.
CGNAT would become immediately unpopular if a customers’ games console got cut off from the Internet due to connection problems caused by address sharing.
“Large-scale NATs pose a challenge in a scenario where customers are running servers in an address sharing environment,” says Alcatel-Lucent senior Internet Protocol product line manager Alastair Johnson.
Johnson believes the challenge could be resolved with a new Port Control Protocol (PCP) standardised by the Internet Engineering Task Force.
PCP extends the Universal Plug’n’Play (UPnP) and NAT Port Mapping protocols that, in the home, ensure traffic flow between, for instance, an Xbox console and the broadband gateway to the ISP’s CGNAT device.
New broadband routers that support PCP can then work with the providers' CGNAT device to open external ports as required.
APNIC chief scientist Geoff Huston takes a more pessimistic view of networks behind NAT.
Huston says that as long as the consumer’s host is the client for a server with a public address, NAT means common protocols such as HTTP for web browsing, FTP for file transmission and SMTP for email will continue to work.
From there, the situation becomes more complex. For instance, symmetric traffic paths are required for CGNAT as both sides of the data conversation have to go through the same address sharing unit, Huston says.
This calls for careful engineering, particularly when the network has multiple upstream connections and peers, to make sure incoming and outgoing traffic are pushed through the same NAT device, he says.
“Failover redundant systems will not operate in such an environment,” Huston says, adding that network failures will break applications, which is otherwise rare in networks without address sharing.
“If you want to use vanilla HTTP and nothing else and put up with a more brittle network and more fragile applications that run slower, then CGN[AT]s will work just fine,” Huston says.
“If you want resilience, robustness, speed, flexibility, then this is not going to happen in a network built upon CGNAT”, he said.
Another issue that may cause headaches is the emergence of IPv6-only services on the public Internet that users with IPv4 addresses behind CGNAT will want to access, Lindsay says.
He says this will lead to some ISPs using transparent proxy servers in order to translate between the IPv6 Internet and address-shared IPv4 networks.
Read on for the port exhaustion problem and alternatives to large-scale NAT deployments.
The port exhaustion problem
The two main transport protocols on the Internet, TCP and UDP, are designed so that each IP address has 65,536 ports over which data is sent and received to a host.
That number is more than adequate for small-scale address sharing, but there are concerns that CGNATs could run out of ports.
“In the quest for ever more speed, application designers discovered parallelism. When you load a Google map, or Gmail, or iTunes, it’s not unusual for the application to divide the tasks such map cells and mail lines into separate tasks and fire up a new TCP session for each sub task, “ Huston explains.
“We've seen applications fork up to 200 or more sub-processes in some cases. While the NAT was at the edge this was not a big deal".
With CGNAT, it could be a different story.
“What happens if the load ratio is 8000:1 [customers per visible IP address]?” Huston asks.
“The actual sustained number of ports available to each customer is just 8 ports. This will break applications that want to operate in a parallel fashion at peak times,” Huston warns.
Lindsay believes “the socket issue isn’t a real problem” as technology has evolved to cope with it.
“CGNAT boxes are feasible because Moore’s Law [of expanding computing capacity] means we can trivially keep track of the four billion real IPv4 addresses in memory in a general purpose computer,” Lindsay says.
There are several strategies CGNAT can use to avoid port exhaustion, Lindsay says, which includes matching customer addresses to real addresses and sockets.
Socket reuse — where one socket on a real IPv4 address is used to communicate with many private IPv4 addresses at the same time — is another, Lindsay says.
Alcatel-Lucent’s Johnson agrees with Huston that “port exhaustion becomes an interesting challenge for large-scale NAT deployments”.
He says his company worked with Waikato University’s applied network dynamics group (WAND) to analyse typical usage profiles and port range requirements in residential ISP networks (pdf)
Johnson echoes Lindsay's sentiments that technological solutions are available to address the problem, and points to his company’s network Layer 2-aware and subscriber-aware NAT platforms as ways to prevent port exhaustion.
“In live deployments, subscribers have not even noticed their ISP had implemented large scale NAT,” Johnson says.
No real alternatives?
Despite the risk of network breakage with large-scale NAT deployments, there is no real alternative to it beyond moving to full IPv6 connectivity, Huston believes.
Transiting IPv6 is still the preferable solution to building a robust, fast and resilient network, he said.
“IPv6 costs real money, and most last-mile carriers don’t have the large reserves of cash, talented engineers at hand and committed vendors with robust IPv6 products,” Huston says.
Johnson says there are some alternatives available such as Dual-Stack Lite (DS-Lite) that allows IPv4 services to traverse IPv6-only access networks. Another one is NAT64 that allows IPv6 hosts to communicate with IPv4 servers.
NAT64 requires a domain name server function or DNS64 to enable IPv6 clients to talk to IPv4 hosts, but can be an intermediate step in the transition between the older and the newer addressing protocol, Johnson believes.
Ultimately, Lindsay believes that over time, providers will move customers to real IPv6 addresses and shared IPv4 ones, in a dual-stack scenario. Lindsay forsees that real IPv4 addresses will be exclusively used for servers and CGNAT.
In the long run however, IPv6 is the best solution.
“Alcatel-Lucent always recommends that ISPs deploy IPv6 as a foremost approach, and manage IPv4 exhaustion as and when required,” Johnson said.