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.