[MrFoof]

Especially when the reality is… you can almost go IPv6 only nowadays if you wanted to.

I went down the rabbit hole recently, switching my network to IPv6 primary with IPv4 as the fallback. The ultimate test was disabling IPv4 for a weekend to see what, if anything, broke.

I had set up DNS64, NAT64 and 464XLAT. The only weirdness is how Windows clients handle IPv6 literals in UNC paths, which is super ugly, and how some applications (like Discord calls) will actually embed IPv4 literals. Discord apparently does that for the relay servers for calls.

Those things — and the rare website not supporting it - aside, I could actually be IPv6 only. I have IPv4 enabled as a fallback now, but it’s no longer primary on my network.

[ninkendo]

464XLAT should work fine with ipv4 literals, no? At least on macOS, this will get routed to a local 192.0.0.2 interface, which does the CLAT, translates it to an ipv6 64:ff9b::<ipv4> address, and relays it to your nat64 server. The ipv4-only software doesn't know any different, and the only traffic going on your LAN is ipv6.

I'm not sure if windows works the same way though...

(Edit: Looks like windows can do this, but it only configures it for WWAN interfaces, go figure: https://techcommunity.microsoft.com/t5/windows-os-platform/c...)

[MrFoof]

Discord calls on Windows was the only exception I ran into, because as you found yourself, it functionally had to fallback on DNS64. In general, some peer-to-peer situations are the likely one of the few cases where it will end up falling back onto DNS64 for resolution. This isn’t something I entirely realized myself — I’m apparently far from the only person to discover this behavior (Discord embedding IPv4 literals for its relay servers). Discord has had tickets open about it for years so far.

I appreciate my son being patient on that one, but he appreciated how seriously I dug into everything. Again, we have IPv4 enabled again as fallback, but the family agreed for an IPv6-only weekend as a test, and that was the only thing (outside of one website) that failed.

Everything else worked perfectly, including tons of legacy devices and software, some of which had no concept of IPv6.

For 464XLAT on clients, phones are actually the leaders here. It’s worked perfectly on at least iOS (and I assume Android) for a LONG time because of its built-in automatic tunneling. Mac OS had some recent improvements in Ventura to make things easier. Windows absolutely has some quirks, the biggest being IPv6 literals in UNC paths ending up using a domain Microsoft doesn’t actually own - a potential huge future attack vector.

[kube-system]

> you can almost go IPv6 only nowadays if you wanted to.

I think that is the reason why many aren't enthusiastic about it.

[MrFoof]

Again, I disabled IPv4 purely for testing reasons, to guarantee nothing was using IPv4 without me knowing it. There’s no reason to actually disable IPv4 as a fallback.

Over 99.999% of traffic through my home network is IPv6 now. The tiny remainder that has to use IPv4 does, without issue. 5 months on, and nary a complaint. Just works.

The world is ready for IPv6 as your primary, with IPv4 as the fallback.

[0x457]

Not really. When I worked in a networking company, we've observed that connections between hosts via IPv6 were often worse than with IPv4. By connection, I mean between two hops on route to your destination.

[kube-system]

I understand that. I'm just saying that the people who don't want to try IPv6 aren't motivated by that. For many the calculus is simply functionality divided by effort. They're not configuring IPv6 because it's hard or because it doesn't work. They're not configuring IPv6 because they already use IPv4 and it still works for them.