Consider the counter-factual: what if 64 bits ended up being not enough?
Given all the effort that needed and still needs to be done to move from IPv4 to IPv6, if we eventually needed to move to IPv7/8 it would even more difficult given how much IP in general has/is pervading civilization.
It's better to have the extra addresses and not need them, than need them and not have them.
It's the reason why ZFS went with 128 bits as well:
> Some customers already have datasets on the order of a petabyte, or 2^50 bytes. Thus the 64-bit capacity limit of 2^64 bytes is only 14 doublings away. Moore's Law for storage predicts that capacity will continue to double every 9-12 months, which means we'll start to hit the 64-bit limit in about a decade. Storage systems tend to live for several decades, so it would be foolish to create a new one without anticipating the needs that will surely arise within its projected lifetime.
> If 64 bits isn't enough, the next logical step is 128 bits. That's enough to survive Moore's Law until I'm dead, and after that, it's not my problem. But it does raise the question: what are the theoretical limits to storage capacity?
* https://web.archive.org/web/20171118074243/https://blogs.ora...
I did the math and it was something like a decade of the worlds production of disks, in a single filesystem. I could somewhat understand if it was a distributed filesystem, but it's not.
It doesn’t seem impossible that someone might have a single pool too big for 2^64 by the end of ZFS’s useful life.
Just kidding, but maybe not.
So did Jeff Bonwick:
> Thus, fully populating a 128-bit storage pool would, literally, require more energy than boiling the oceans.
* https://web.archive.org/web/20171118074243/https://blogs.ora...
For IPv6, people memorize/type IP address all the time. So the IPv6 designers needed to balance the address space size with ergonomics - and they did this poorly, imo.
Increasing the address space by a factor of 2^96 while still reasonably allowing addresses shorter than the v4 equivalent seems like a pretty good balance to strike, especially when the vast majority of users use DNS or other automatic discovery and thus won't ever interact with them anyway.
Most people have a hard time with remembering more than a handful of important telephone numbers (15 digits per E.164), so I don't think 64- (36:31:85:fc:bc:64:21:58) or even 48-bit (da:e1:4d:a5:9d:e7) addresses would be any easier.
And if you don't like the current IPv6 addresses, be thankful the IETF didn't go with RFC 1561:
> General purpose CLNP implementations MUST handle NSAP addresses of variable length up to 20 octets, as defined in ISO/IEC 8348 [11]. TUBA implementations, especially routers, MUST accommodate these as well. Thus, for compatibility and interoperability with OSI use of CLNP, the initial octet of the Destination Address is assumed to be an Authority and Format Indicator, as defined in ISO/IEC 8348. NSAP addresses may be between 8 and 20 octets long (inclusive).
* https://datatracker.ietf.org/doc/html/rfc1561.html#section-4...
As my home router only supports stateless auto configuration, it’s an additional friction point to have stable addresses. Oh, and since the /56 is assigned by my ISP, it sometimes changes, so I can’t just rely on addresses being stable.
I’m not saying that IPv6 is necessarily bad — we _need_ the extra address space! - but it definitely requires a different way of working and I haven’t completely cracked that nut myself yet. I’m almost at the point that I’m just considering using NAT with IPv6, but I fear the IP gods will spell an evil curse on me if I dare to do that.
I don't even know what's my workstation's IPv4 address. I just connect to desktop.local and my NAS with nas.local
Or just have IPv4 on the LAN.
I go to `router.localnet`, not some IP I have to remember.
NAT is a nightmare that has directly lead to the crappy world of every "IoT" device relying on some remote service that can shut down any time, instead of just... connecting to your device. Also every game having connectivity issues when trying to do peer-to-peer play. Not to mention a reliance on NAT as security, something this article advocates for, despite being a job it isn't good at.
The obsolescence of NAT is the bit of IPv4's demise I look forward to most.
Kinda scary/weird
How so? Allow established, then drop. You know. The same rules in ever consumer level router on the market now.
This is true... but the security impact of NAT is negative. It provides no security benefit, but it does confuse people about the security properties of their network, often providing a false sense of security.
This one probably is the best
"The world in which IPv6 was a good design" https://apenwarr.ca/log/20170810
It's interesting but that doesn't make it right. v6 was a good design in our world.
Remember that the IP layer exists for the purpose of routing and aggregation. Instead of tracking the current location of every machine on the planet, we bundle them into networks, and then bundle those networks together, and then bundle those bundles together too, and so on. There are maybe something like 10 billion devices that are either on the internet or that want to be on it, but with all the aggregation we're only tracking about a million routes at the global level.
This aggregation is critical for allowing the internet to scale to planetary size... but it also results in the vast majority of the addresses in the address space not being assigned to any end machine. In other words, having N in-use addresses needs a lot more than log_2(N) bits of address space.
There's likely to be less than 2^64 devices on the internet in the long run, so if we could assign one address to each of them and not have to worry about routing table sizes, then a 64-bit address space probably would be enough. But that doesn't describe IP addresses... it describes MAC addresses. And MAC addresses are in fact 64 bits long for new L2 protocols today.
Since L3 needs aggregation, which results in most L3 addresses being unused, it follows that we need more than 64 bits of L3 address space to handle the 2^64 devices that the 64-bit L2 addresses can handle.
What exactly is complicated, using hexadecimal in addresses? The IP packet format itself is as simple as ever, and management things are done in a more elegant way (ND runs over ICMP rather than ARP being sort of there on the side not-in-IP-at-all).
> not backwards compatible
Massive service providers like T-Mobile US who use NAT64 as the only way to connect to v4 hosts anymore would disagree.
> doesn't actually solve the NAT problems for home users because of how ISPs work in the real world
My ISP delegates me a /56. How else do ISPs work in the "real world"? I've heard of some giving out smaller networks but never something egregiously small.
That isn't the complicated part, but thanks for strawmanning that as hard as you possibly could.
> My ISP delegates me a /56. How else do ISPs work in the "real world"? I've heard of some giving out smaller networks but never something egregiously small.
It's got nothing to do with the size of the address space, it's that they insist on changing it constantly which invalidates firewall rules and any non-dynamic DNS.