NAT has not solved the IP address problem, it has merely postponed it slightly. Multi-level NATs are a hell far beyond the single-level NATs that most consumers see (and single-level NATs already cause all sorts of problems for even moderately advanced network usage). So most people only have single-level NATs, which practically only extends the address space by a small multiple - 8 bits at most, in practice ~2-3 bits.
128 bits allows routing tables to be super small and fast. While RAM has gotten cheaper, it is still slow, and smaller routing tables are way more important than smaller addresses.
However, I agree with your central point - IPv4 was "good enough" that IPv6 is going to be a tougher battle than it ought to be. However, IPv6 is winning that battle already. 15% of google's users use IPv6, and it's increasing sigmoidally. [1]
It's getting to be time for us to admit what the holdup is—IPv6 hasn't been deployed because IPv6 NAT ("NAT66") isn't a thing.
There are a million reasons NATs are terrible for the internet. But they're used on IPv4, and IPv6's technical goal of increasing the address space is tied up into the technical goal of killing NAT, immediately, and changing the way a lot of people think about networking. For instance, end-user ISPs are expected to give you a /64 or more instead of a single IPv6 address so that you don't need to NAT, but many of them don't, because that's not how people think about addressing. If you have a NAT-using site and you want to switch to IPv6, you have to pursue the political goal of convincing your ISP to think differently about addressing.
Meanwhile, IPv4 and IPv4 NAT works. I'm typing this from behind a NAT, you're probably reading it from behind a NAT. It's not ideal, but, rough consensus and running code.
As soon as we all put our collective feet down and insist on IPv6 NAT implementations, such that IPv4 sites can move without rearchitecting their environment (whether or not that rearchitecting would be a good thing), IPv6 will get deployed quickly.
> NAT, for all its problems, has more or less solved the IP address problem.
A bunch of very large-scale network operators (like Comcast, T-Mobile USA, Verizon, and Facebook) seem to strongly disagree with that, given how eagerly they've deployed IPv6 to get away from the hell that is IPv4 NAT and CGN.
Yes, IPv6 has lots of complexity/flaws/idiosyncrasies/weirdnesses (multicast, mobility, slaac, ndp, prettyprinting / the colons, extension headers, etc.) that mostly only look good through the rose-tinted glasses of the 90s and significantly slowed down deployment -- and in the end mostly ended up as "difference for difference's sake".
128 bits of addressing space and getting away from IPv4 NAT were unambiguously good. 128 bits is a lot, but memory/bandwidth is just going to get cheaper (for slow links you should use header-compression anyway), and it was better to go whole hog and skip 64 and go to 128 to avoid a future 64->128 transition. Given how the 32->128 transition is going, this seems like it was an excellent decision.
NAT has been more successful than IPv6 at fixing the same issue, the shortage of IPv4 adresses, but without breaking compatibility (well at the cost of crazy hacks for weird protocols such as FTP).
Not being able to route directly doesn’t seem to be a major issue to me. It for sure require more computing power in routers but also adds some safety and privacy by design.
The problem is the "Global Routing table size problem" is a problem we actually have _right meow_, whereas the impending omg-out-of-ipv4-address problems is one that will stretch on for another 40+ years.
If IPv6 actually solved the problem we have right now, people would adopt it. But IPv6 solves no current problems, it only creates new current problems.
Anyway, I know IETF pisses vinegar all over NAT, but I'm hoping a grassroots effort pops up to solve the problem IPv6 should have actually solved.
All we really need is forward-compatible extension to IPv4 that allows for easier incoming NAT traversal. A working solution would allow border routers to identify traffic belonging to an individual host on their network (in the private address space), while the client remains blissfully happy on traditional IPv4.
The goal would be, merely update your border router to speak this extension to IPv4... rather than every device on your network and oh by the way, rewrite half the software you have that parses ipv4 addresses.
NAT is the problem that IPv6 fixes. Think about the parent comment
>if you are making more than 4B addresses routable then any existing IPv4 device will not be able to route some addresses, so you will have caused a split in the internet
This has basically already happened. We've massively extended IPv4 by stuffing extra address bits into the router's port number, and it means that any two devices behind NATs can't directly route to each other.
Truth is NAT works just fine for the vast majority of cases, and makes a layered (IE not-eggs-all-in-one-basket) approach to security much simpler.
The real problem is routing table size with BGP. As we continue to divide the internet into smaller routable blocks, this is requiring an exponential amount of memory in BGP routers. Currently, the global BGP table requires around 256mb of RAM. IPv6 makes this problem 4 times worse.
IPv6 is a failure, we don't actually _need_ everything to have a publicly routable address. There were only two real problems with IPv4: wasted space on legacy headers nobody uses, and NAT traversal. IETF thumbed their noses as NAT (not-invented-here syndrome) and instead of solving real problems using a pave-the-cowpaths-approach, they opted to design something that nobody has a real use for.
Anyway, I'm hoping a set of brilliant engineers comes forward to invent IPv5, where we still use 32 bit public address to be backward compatible with today's routing equipment, but uses some brilliant hack re-using unused IPv4 headers to allow direct address through a NAT.
The more I hear about IPv6 (these comments in particular), the more it seems like it contains many solutions to non-problems. Yes, IPv4's 32 bit address space is basically full, and upgrading that is a good thing.
But honestly, burning 64 bits of address space for a redundant global identifier just so "nat+dhcp" are only half as complicated? And then needing privacy extensions to keep the uuid from leaking out? All while doing nothing to solve the problem that caused NAT to spring up in the first place.
On the surface, "no NAT" sounds like a reasonable goal, but ignores the realities of what NAT is actually used for - keeping your network your business. How long until consumer providers offer different tiers of plans based on number of devices that can be connected, and smart users are back to NAT anyway? The proper solution to NAT problems is at layer 4 - a standard way of making connections from the outside to a device inside based on some kind of onion address, where the upstream can only see the outer part.
NAT doesn't solve the issues with IPv4, it merely delayed them. IPv6 is still the future, but everyone from ISP's to switch and router manufacturers have been dragging their feet on a real push to get us off IPv4. Hell, there are still modern switch platforms out there with full Layer 3 IPv4 support but IPv6 is curiously omitted - you've got to buy a bigger switch to get support for modern protocols (or an implementation that isn't totally gimped).
Now consider that IPv4 + NAT + NAT traversal is essentially a crap version of IPv4+ that uses UDP port numbers to achieve an unstable, unreliable 16 bit extension to the IPv4 address space. Of course because these port numbers are ephemeral and unreliable all P2P code must be full of complex logic to constantly check for dead paths, remap ports, deal with different kinds of NAT, etc.
I happen to think DJB was right. If we could rewind history to, say, 1998 and implement an address space extension to IPv4 that was less of a severe change than IPv6 that probably would have been the better way forward.
Personally I would have implemented IP64, using the existing IPv4 space as the most significant 32 bits of a 64 bit address space. The advantage here is that an IP remains something that can fit in a typical 64-bit CPU register and remains short enough that it's type-able and at least a little bit memorable. 64 bits would be plenty to address every device on Earth. There are some nice things about having a larger address space but most of them are minor compared with the address shortage problem. IPv6 gives you enough space for reliable stateless auto configuration, but in practice that's going out of favor since it turns out you need DHCP (DHCPv6) for other reasons besides just assigning addresses.
NAT was a thing much before ip addresses became scarse, is a key enabler in the "internets" ease of use as well as the principal ability to connect nearly double-digit billions of devices with about 200mio live addresses.
the end-to-end principle is mostly undermined by stateful firewalls and a total lack of secure-by-design in software developement, this will not change with ipv6
Isn't the NAT issue the IP6 issue? In other words, once we solve the fact that IP4 is running out of addresses, then we will not have to deal with NAT penetration anymore.
I do believe there is some kind of 1:1 NAT with IPv6 these days, which is way better than 1:Many of IPv4. There are so many potentially useful applications that are DOA because of v4 NAT being everywhere.
The IPv4 perspective is a red herring. NATting was indeed necessitated by IP address scarcity, but a domestic installation that does NAT comes with ancillary benefits, like giving you, the home user, a single place to control access to your network.
In IPv6 it's nice that you have an address space that's not only big enough to accommodate every device, but large enough to even burn through addresses and treat them as disposable, but once IPv6 becomes widespread there will need to be some rethinking as to how to manage firewall rules between your own devices, how to segregate your portion of the network from the spurious (and sometimes malicious) traffic of everywhere else.
You are right, NAT is why the internet still works in the first place. However, NATs have many issues, like severely harming peer to peer capabilities. There is also additional complexity. My ISP frequently has downtimes of their NAT infrastructure.
Then there is the more complex routing tables. ipv4 is highly fragmented so users with many users don't have large contiguous blocks, but multiple smaller ones. This causes routing tables to bloat up, which increases routing overhead of the packets.
Lastly, there is the ridiculousness of paying for ipv4 addresses in the first place. Ideally, companies could just register them, having to pay a small service fee, that's it. In ipv6 this is the case, but in ipv4 you see Amazon paying huge sums for large ipv4 blocks. More importantly though, this cost is also handed down to customers, at least for hosters like Hetzner. For small servers, this can quickly be a significant fraction of the cost.
As a network engineer for over 2 decades, I've been skeptical of IPv6 for the majority of them.
I still am.
As IPv4 becomes more scarce, two economic forces trigger
1) They become more valuable (read more desired). IPv4 has all the network effects going for it. It's where 99.9% of the Internet already is. .1% being IPv6 only devices.
2) To counter the rising value/cost: Workaround/Kludges/Alternatives to every devices needing a globally unique address are tried. Everyone is going to reply with how awful NAT is, and I concede it has its flaws. However, it is hard to deny its success so far. Business then do the cost benefit of the shortcomings of things like NAT vs selling their now valuable IPv4 address space, think where they are going to come down?
128 bits allows routing tables to be super small and fast. While RAM has gotten cheaper, it is still slow, and smaller routing tables are way more important than smaller addresses.
However, I agree with your central point - IPv4 was "good enough" that IPv6 is going to be a tougher battle than it ought to be. However, IPv6 is winning that battle already. 15% of google's users use IPv6, and it's increasing sigmoidally. [1]
[1] https://en.wikipedia.org/wiki/IPv6_deployment
reply