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.
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...
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.
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.
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.
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.
I’m behind CGNAT for the last 1.5 years without issue. What am I missing? I actually prefer my router not being bombarded by connection attempts all day.
Try connecting to an SSH server for more than a few hours without passing traffic and then have the server be the one to send a message. Oops! Your ISP tore down the NAT association and you have no idea the server isn't sending anything until you try to communicate with the server and get a timeout / RST.
NAT breaks TCP, but at least with consumer NAT you're in control of the timeouts on your router. With CGNAT you're at the mercy of an ISP that likely optimizes for HTTP and has low timeouts that you can't control.
I actually used to have that issue years ago at work. To work around that I just enabled a keepalive (ServerAliveInterval maybe?) setting in my ssh config. I don’t connect to any ssh servers outside my house for long periods of time, so I haven’t encountered that. Thanks for the heads up, good info!
OpenSSH does enable TCP keepalives by default so that it can detect and close dead connections, but the keepalive interval is far too high to work around bad NATs.
Kind of related to the OP, I spent a decent amount of time trying to have my SSH sessions survive a sleep on Windows. With keepalive disabled, proper Wi-Fi adapter sleep behavior and long enough DHCP leases, I was able to put my PC to sleep and come back the next day and still have my sessions active on resume. Unfortunately it wasn't too practical to disable keepalive as sessions that really do crash never get cleaned up.
With IPv4 you need an addres, a gateway, netmasks, DNS.
On v6, as long as you have a working router sending RADV packets, clients will self-configure via SLAAC. Granted, same with IPv4 and DHCP.
If you don't have a router, most things should work thanks to link-local+mDNS.
You can easily pop a second router on the network to bridge two LANs, no need to reconfigure the DHCP. Gateways self-advertise, etc.
The point I'm trying to make is that most people trying toconfigure their IPv4 network have a functional IPv6 network the moment they put the cables in (on Linuxes es at least, not sure about other platforms).
I hope you're right, if only so that cgNAT goes away someday. But I'm pessimistic on that front. cgNAT is too easy and works just well enough to make adopting something better too low a priority to ever happen.
The increasing prices of IPv4 address blocks will probably drive adoption of IPv6. The increased complexity will be outweighed by the elimination of scarcity that IPv6 brings. If we are still using IPv4 in 2100 that would be tragic.
IPv4 block pricing: https://ipv4marketgroup.com/ipv4-pricing/
I do (and I guess I'm not alone...) -- have IPv6 exposed machines over a HE.net tunnel. Some of the things are ONLY accessible over IPv6 (because nobody needs them over IPv4, so that's enough).
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.