I wanted to try installing the module into my router so it would pass the WebRTC test for STUN/TURN and perhaps make video even more efficient to allow point to point connection instead of having everything be relayed through a tertiary server, but there was no documentation and having never set up a STUN/TURN server before I couldn't get it to work. So I am dependent on what a third party has set up to facilitate connectivity.
In the old days, you'd just connect to an IP address and that was it.
And every one of those has introduced its own security flaws and implementation bugs increasing the complexity of applications.
The thing is we would be addressing in 128-bit IP already if it was done the BGP way: just minimising the necessary changes to implement it. Look at the effectiveness of Itanium versus AMD64 at migrating customers: IPv6 feels like Itanium, while extended ASes work more like AMD64. Whoever designed IPv6 was focused too much at the theoreticals, than looking at what the real world is and then designing around it.
I've asked a lot of people this question, and the only answers I've ever gotten are either impossible or already implemented by v6. Perhaps you will be the person to finally explain how to do it -- but as far as I can tell, it's just not possible, and I don't think it's fair to criticise v6 for not doing the impossible.
Or are we forever stuck with either going all in to IPv6 or the current hybrid?
One is connectivity. Even theoretically we should have the same network connectivity (so to speak), you can feel the pettiness when Hurricane-Electric and Cogent fought exclusively on IPv6 (https://www.theregister.com/2018/08/28/ipv6_peering_squabble...) I can't believe I'm saying this, but IPv6 isn't free (or at least costs the same as IPv4).
Second is security. Yes, the world is no longer scannable, but consumer routers are a dud when it comes to IPv6 security. This router (https://pierrekim.github.io/blog/2021-01-12-fiberhome-ont-0d...) has serious problems at IPv6 security, and because it's suffix is always at ::0000:0000:0000:0001 and you've eliminate around 18 bits more because of how networks are laid, you've got yourself an IPv6 botnet, which speaking by, how do you block them? A /64 would be a good start, but OVH provides a single address per server (https://www.ovhcloud.com/vps/compare/). That's it. Don't forget that fiasco with MAC addresses (https://datatracker.ietf.org/doc/html/rfc8981), but at least that's solved.
Third, IPv6 should just work as you said. I wish that's true, but embedded devices will trip you up badly. Some don't fallback to IPv4 and instead try and try again using IPv6. This would be a concern while transitioning, but even after that, some would be still stuck because their servers are only operating on IPv4!
Implementing IPv6 is not free lunch if you know the gritty details.
NAT was developed. CGNAT was developed. HTTP Host differentiation was developed. SNI was developed. STUN was developed. TURN was developed.
The main problem with IPv4 to IPv6 migration is the, frankly, overzealous utopia that "they will migrate anyway". Worse, it's very different that doesn't allow for a simple upgrade option of "IPv4, but longer addresses" because IPv6 is designed to be fundamentally different.
Which is more insulting considering that BGP was seamlessly upgraded from 65536 ASes to more than a million because they only changed the bits in an AS and nothing more. As a router developer, you only need to do the relatively minute changes of extended ASes than the (relative) mess that is IPv6.