|
Qtel, the largest carrier in Qatar (and nearly the only Internet provider) appears to connect all their users (~600K) to the Internet through just one or a very few public IPv4 addresses. 82.148.97.69 was their single public address in 2006-2007. How can network address translation (NAT) put all those users through just one IP address?
Well, both UDP and TCP include 16-bit port numbers, so for each IP address there are 2**16 = 65,536 unique IP address/TCP port number combinations which can support network address translation (NAT) for more than 65K simultaneous connections. Of course, individual browser sessions may open multiple connections so each on-line user can tie up several such connections, even several dozen.
But there are more unique fields that come into play. On the Internet side of the NAT, each active IP session has five fields of interest: source IP address, source port, protocol, destination address; destination port. So you can use the same source address and port number for multiple independent sessions if the sessions are going to different destinations or using different protocols. With this approach, one public IP address can clearly support millions and millions of connections.
But what if most of your users are trying to reach just a few destination addresses? That’s a problem Qtel had (or at least their users had) when accessing Wikipedia in 2006.
One obvious solution is to devote more than one public IP address for the whole country! Indeed, if a few hundred people are attempting to access the same address simultaneously, then having a few hundred IP addresses (for the whole country!) would do it. Of course, if the destination IP address is that of Google’s search bar, you might need more than a few hundred IP addresses.
There is another path, one which Geoff Huston alludes to in a recent article on the IPv6 transition.
... we may expect to see a push to re-architect content into Content Distribution Networks that have points of presence in major access networks.
Today, major content distribution networks (CDNs) like Akamai, Amazon Cloudfront, Limelight and Google each maintain thousands of servers close to the edges of the Internet. These servers cache popular content close to where the users are.
When many, many users in Qatar simultaneously try to access the same content, the load on Qtel’s NAT boxes could be dramatically reduced by putting the appropriate CDN’s caching servers within Qtel’s private address space. Then requests for popular content wouldn’t even go through the NAT, reducing total traffic and dramatically reducing the occasions when two users are going through the NAT to the same public IP address.
It’s not in line with the Internet’s original end-to-end design, but as IPv4 addresses get more expensive, we can expect to see more and more use of NAT and CDN servers moving into carriers’ private address domains.
Sponsored byCSC
Sponsored byDNIB.com
Sponsored byRadix
Sponsored byVerisign
Sponsored byVerisign
Sponsored byIPv4.Global
Sponsored byWhoisXML API
Brough, I’m missing the point of the article I’m afraid. Are you proposing a workaround (CDNs) for a workaround (NAT)? Wouldn’t it be easier, cheaper, faster, more scalable, more sensible to just use IPv6? Or for the time of being, buy a few more IPv4 addresses? Cash is not an issue in Qatar.
If you take the way of thinking in your article a little further, we end up with the solution of putting the internet on a DVD and handing it out to every internet user, so we just need 127.0.0.1 for 6 billion people.
Marcel, I’m not advocating either carrier grade NAT or CDNs within local NAT address spaces, but I’m suggesting we will see them. Yes, IPv6 would solve the problem, but after 17 years of discussion and 14 years since the first IPv6 RFC (2460 in 1998) we’re left with a lumpy migration path that most enterprises cannot justify investing in. So we will see CG-NAT, CDNs and who knows what else for years to come.
In any event, I wrote this post on my personal blog when I stumbled on the Qtel situation and was bemused. I wasn’t expecting it to be republished here - but I don’t mind. :)