Worth Reading: Contrarian View on NAT
I love reading well-argued contrarian views, and Geoff Huston’s Opinion in Defense of NAT is definitely worth the time it will take you to read it.
TL&DR: Geoff argues that with all the wastage going on in IPv6 land (most bizarre: let’s give a /48 to every residential subscriber) the number of bits available for IPv6 endpoint addressing gets close to what we can squeeze out of IPv4 NAT.
If it was up to the operational people, the Internet would have been one huge flat layer-2 domain. Because that is easiest to operate. If it doesn't work, blame the vendors.
Somebody has to make this technology work.
What we needed in IPng was: variable-length addresses, locator/identifier separation, any device is allowed to re-write the network part of an address. But 25 years ago, the IPv6 community was opposed to that. They wanted the same thing as IPv4, only with 96 more bits. The reason was that everyone with a clue was working to become a millionaire by making the IPv4 Internet work. And all the clueless people who played no role whatsoever in the IPv4 world took hold of IPng. IPv6 is the work of talentless amateurs.
Somebody has to make this technology work.
And over the last 25 years it was CIDR and NAT that made the Internet work. Not IPv6. If it had been up to IPv6 to save the world, we'd now all be paying for our Internet services by the minute. On a 128 Kbps connection over ATM.
If IPV6 goes truly beyond the poor countries, the content providers and the cell phones networks - it is time to hang up my boots and open a bar beside the sea.
http://packetpushers.net/podcast/podcasts/show-275-future-of-networking-geoff-huston/
Regards,
Joel
But failed to mention a few problems.
With no more IPv4 addresses left it is harder to dual home to the internet, you don't own your IP addresses so when connecting to dual ISPs you can't publish a single space through both ISPs which force to use some kind of GSLB which is not that good.
Furthermore it failed to mention that a single host can use more than one connection, so you don't really borrow all the bits from the Tcp udp layer.
True IPv6 is hard to adopt,and it is a real problem that it not backwards compatible.
But I don't see any other solution in the future, we can't keep doing workarounds forever and eventually we will have to solve the problem from the roots
I do think that the piece falls short of its goal of providing a defense that NATs are anything better than a necessary evil. The "NATs as Architecture" section talks about how "the IPv4 architecture made several simplifying assumptions", and to paraphrase, they are 1) that addresses are 1:1 with hosts and 2) that mobility wasn’t accounted for. It also suggests that NATs helped applications break free from these limitations.
I can’t find a strong footing for either of these. For instance, RFC 1123 talks about how DNS might return multiple addresses for a host and that the “application protocol implementations SHOULD be prepared to try multiple addresses from the list [of addresses] until success is obtained." This doesn’t sound like addresses being 1:1. Whether applications actually implemented this behavior is another story — most didn’t. �That points the finger at applications and socket libraries rather than at any sort of architectural property of IPv4.
For the second bit, assume for a second that NAT did free the internet from its "IP <-> host identity" relationship. Why then is NAT so important in mobility like Geoff argues? Permanent addressing doesn’t mean "permanent endpoint association". If applications (or TCP) really did keep sessions intact disjoint from their "IP, port <-> identity" tuples, then shouldn’t mobility be a piece of cake for IPv4 and IPv6? Simply change addresses as you move between cell towers, the application knows how to keep a socket together! It seems like NAT is instead the tourniquet that stops applications from bleeding out when they change locations.
NAT can’t have been both the cure and the salve for the side effects.
It’s a pretty good retrospective of what happened, though. :)