The value prop of AMD64 was very clear from the start: better performance, more memory, without porting to a 64 bit RISC which coincidentally were all dying or dead at the time. The only other option at the time was IA64 - Itanium - which sucked and was way more expensive.
The value prop of v6 is: ??? Learn an entirely new networking stack! Enjoy degraded service because v6 will cause inexplicable hangs and timeouts! Deal with a weird ass protocol founded on perimeter security which is not something we have been doing for 20 years! Fun for the whole family!
The value prop of IPv6 is not having to pay US$ 30/IP (and rising) when you need a block of new IPs. Most folks don't need that many public IPs and so simply use RFC 1918 addresses and then implement the kludge that is NAT. NA(P)T was codified in 1999 (RFC 2663), and it is now "background radiation" so people think it's normal because it's all that they've ever know.
But we've long gotten to the point where we're now doing double-(CG)NAT, and entire chunk of address space (100.64.0.0/10) has been reserved just for this purpose:
* https://en.wikipedia.org/wiki/IPv4_shared_address_space
I'm waiting for triple-NATing to start occurring.
NAT, when done on the carrier level (CGNAT), more or less prevents external systems from initating connections with anything on your network (without ISP involvement). You can still initiate outgoing connections fine.
Sounds great for security, but this enforces the existence of centralized services (middlemen) that you have to use/pay for if you want to have asynchronous communication with anyone that you might not necessarily initiate.
If you want a chance at a real decentralized Internet without dependency on tech giants, you're gonna need IPv6.
I don't know too much about NAT-PMP/PCP - so I'm looking into it.
One of the vexing things about IPv4 (which is not really fixed by IPv6) is that endpoint devices are connected to the network but not really part of the network: there are different sets of protocols for connectivity within the network, and at the edge of the network. So an edge device (your phone, your VM host) can’t easily extend the network to more downstream systems (tethered devices, VMs) without hacks that hide the cluster from the network so the whole thing still appears to be a single device.
So an unprivileged WiFi client needs to hide tethered devices and VMs behind a single MAC address, using ARP proxy (IPv4) or ND proxy (IPv6). These proxies do NAT-like mangling of MAC addresses, but are mostly transparent at the IP layer.
The Linux environment on Chrome OS uses ND proxy, and IPv6 works fine on WiFi. Compare that to WSL2 on Windows, which is IPv4-only.
And for IPv6 over ethernet, ND proxying is not a protocol you would normally use to construct a network.
This is probably why going to v6 is so confusing even for us Elite HN Readers; you don't have a private network connected to The Internet any more, The Internet directly extends to all devices. You can have a private network _in addition_ to that though.
This is actually pretty nice because it restores end-to-end connectivity, so P2P and mesh networking become easier; however, most everyone has a central firewall between their splinter of The Internet and The Greater Internet, so in practice you still need hole punching and some central services to offer hole punching duties, because hole punching works around NAT and opens a port in stateful firewalls; v6 only removes the NAT part in most instances. So in reality P2P with v6 is only slightly less messy than with v4.
ULA seems to be RFC 4193 (October 2005). NTPv6 is RFC 6296 (June 2011).
Nowadays, most clients, especially browsers, will try IPv4 and IPv6 concurrently and use the connection that comes back with an ack first. This prevents hangs at the expense of a little higher server resource usage.
But the myth of "IPv6 makes things hang randomly" remains.
My ISP (formerly Time Warner, now Spectrum) has been handing out v6 addresses here, and I've been running in dual stack mode, for a good 3 years or more now. And in all that time, I can remember exactly one occasion where IPv6 caused any issue. And that was only because somebody at my employer who was setting up a GCP environment didn't take into account that anybody would be coming in on IPv6, didn't configure the corresponding firewall rules, and it broke using kubectl to access GKS clusters from my home network, as kubectl was defaulting to the v6 connection.
So yeah, v6 can cause some weirdness, even now (the event described above was about 3 months ago) but in my experience it is exceedingly rare. YMMV, of course.
