On the client side there are apparently some subtleties about the DNS interaction if you want to literally have IPv6-only on the clients (as opposed to IPv4 CGN). If the clients do anything to not trust their ISP's view of DNS (like DNSSEC enforcement, or using DoH and an outside resolver), the ISP can't fool them into thinking that they should connect to an IPv6 address for a service that, from the point of view of the Internet as a whole, is actually IPv4-only.
Can I do "ssh 1.2.3.4" on a pure ipv6 stack yet? Last time I looked at ipv6 I couldn't even ping an ipv6 host by doing "ping 1234::5678", I had to run a separate tool (ping6)
The nat64 and vice versa should have been the play from the start. Want to host a sevice? Put in ipv6 only network, host it on 1234:5678::1, have your firewall with a public ipv4 address do the port forwarding, taking your public 12.34.56.78:1234 and natting it to 1234:5678::1.
Just the same as hosting your service on 192.168.0.1 and port forwarding.
But 20 years of dual stack and horrible cludges around changing public IPs later and many people still prefer ipv4.
IIRC, it's been over a decade since the "ping" command became able to understand both IPv4 and IPv6 addresses; it was only during the early adoption of IPv6 by userspace that we had separate commands for the new IPv6 stuff. Quoting https://www.man7.org/linux/man-pages/man8/ping.8.html "As of version s20150815, the ping6 binary doesn't exist anymore. It has been merged into ping. Creating a symlink named ping6 pointing to ping will result in the same functionality as before." So it seems it has been a long time since you last looked at IPv6.
I ran IPv6 on xfinity. It works. My devices don’t. I like my devices. Easier to just not use it.
I thought it was possible to make a pure v6 network and use NAT64 as needed? I mean, we can argue if that counts, but I argue yes:)