Hi Philip,
In contrast NAT64 breaks existing systems in lots of subtle (and not so subtle) ways. We cannot use NAT64 if we expect IPv4-only devices.
I would expect such devices mostly in a home network (gaming consoles etc). On a business meeting network like RIPE the number of IPv4-only devices is negligible.
We cannot use DNS64 if we expect IPv4 literals or local DNSSEC validation.
I am sure the few of us who run local DNSSEC validation would love the opportunity to make it work. Finding IPv4 literals and fixing them is a feature :)
The 464XLAT component is complicated did cause signficant operational problems in the past.
The net result is that with dual stack and NAT64 we now have two options of providing IPv6+IPv4 on a network. This is confusing to everybody who is not a network engineer.
This _is_ a RIPE meeting...
Does dual stack require more IPv4 addresses? No, there are (of course multiple) ways to provide dual stack on wifi without consuming additional public IPv4 addresses. Plenty of ISPs provide consumers with dual stack wifi at home while maintaining an IPv6-only access network.
There is also more and more live deployment of IPv6-only with NAT64. I am honestly surprised by the back pressure in the RIPE community. If production networks can deploy this for millions of users, why should a small conference network with a huge number of network engineers be any problem? Cheers, Sander