[formerly_proven]

AMD64 hit the market in 2003. Adoption on the software, desktop side was mostly delayed because Vista as a whole failed and XP64 was very niche (on servers and Linux desktops everyone jumped on it). 32 bit Windows outside VMs is only really needed for Intels gimped low end SoCs which lacked AMD64 support for a long time.

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!

[throw0101a]

> The value prop of v6 is: ??? Learn an entirely new networking stack!

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.

[tenebrisalietum]

NAT is essentially required in IPv4 due to IPv4 address exhaustion.

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.

[saurik]

Does the CGNAT setup you contend with not support NAT-PMP/PCP? (To me that is the reasonable solution to the problem you cite, not IPv6, and I have been thinking it is already widely deployed... just not adopted by developers for some reason.)

[tenebrisalietum]

I don't contend with CGNAT, thankfully, but no one ever moves from IPv4 then everyone's going to eventually be behind a CGNAT at some point.

I don't know too much about NAT-PMP/PCP - so I'm looking into it.

[fanf2]

It’s easy to cause triple-NAT if you tether to a phone, or if you run VMs at home...

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.

[p1mrx]

The "single device" problem comes from WiFi, not IP. Normally, you can extend Ethernet by plugging in a switch or bridge, but WiFi is limited to 1 MAC address per associated client, unless operating in WDS mode.

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.

[fanf2]

It isn’t specific to WiFi: there is the same problem if you use SLIP or PPP dial-up or DSL or cellular data, or many kinds of VPN.

And for IPv6 over ethernet, ND proxying is not a protocol you would normally use to construct a network.

[formerly_proven]

Right. This is a big clash between the "v4 model" (as it has panned out in practice) and the "v6 model". The OG assumption of both was that there is _only one_ Network, but v4 in practice turned out to be segregated, private networks that happen to have a gateway to The Network. The original RFCs for private IPv4 networks and NAT explicitly call this change in stance out. So v6 was designed to go back to a world with only The One Network. The possibility of having a private v6 network was added much later (some time in the 2000s I think?).

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.

[throw0101a]

> The possibility of having a private v6 network was added much later (some time in the 2000s I think?).

ULA seems to be RFC 4193 (October 2005). NTPv6 is RFC 6296 (June 2011).

* https://datatracker.ietf.org/doc/html/rfc4193

* https://datatracker.ietf.org/doc/html/rfc6296

[trulyrandom]

I'm not a network guy, so forgive my ignorance, but this is the first time I'm hearing about this. Why will IPv6 cause inexplicable hangs and timeouts?

[corty]

When a server has IPv4 and IPv6 connectivity, i.e. an A and AAAA DNS record, clients would usually try IPv6 first, then IPv4. Now, if IPv6 is broken somehow (as it was prone to be due to tunneling, Teredo and even nowadays stupid ISPs), the client would wait for a connection timeout, then try IPv4, so every connection would hang for one timeout.

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.

[formerly_proven]

It's not a myth when it happens. Last time I tried v6 again on my network (about a year ago) I had these issues. Not a lot of them, but toggling v6 off made them go away. There are fewer issues, true, but having dual-stack does still appear to break some things. I say "appear to" because I'm assuming that it's not actually an issue with v4+v6 dual stack, but rather a problem with misconfigured services (e.g. services having wrong AAAA records, stuff using v6 that doesn't work properly with v6 etc.); from an end-user perspective this does not really matter: There are sometimes issues when v6 is on, which go away by turning v6 off - end user perception: v6 is wonky.

[mindcrime]

Your lived experience is what it is, and I certainly don't mean to contradict you. But just to add another viewpoint for perspective...

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.

[easrng]

I use Spectrum and their IPv6 connectivity drops out relatively frequently, but IPv4 connectivity stays.

[MisterTea]

I believe XP64 was OEM only, there was no retail availability. I had.. uh ... obtained a copy and installed it on my brothers gaming PC and it ran surprisingly well for an OS that barely made it to market.

[formerly_proven]

XP x64 was available in retail, I used it for a pretty long time. The biggest issue was lack of drivers for stuff like printers and scanners, though iirc later on the Vista 64-bit drivers would usually work.