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.
I'm confused how it can be a good thing to use a different way to connect to a RIPE meeting network then the one you would use at the office or at home.
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 :)
There is an experimental NAT64 network. That should be enough for people who love to fix something. I'm very happy with dual stack. It is a technology that just works and doesn't need fixes on the host. Network configuration on hosts is complicated enough. We don't need more options.
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...
I assumed that the point of testing this at a RIPE meeting is to deploy it in other locations. In those locations, most people are not network engineers but still have to deal with the fact that suddenly some devices/software don't work on some wifi networks. And they have no clue why not, other than that it has something to do with IPv6.
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?
There is quite a lot of NAT64 in mobile networks. As far as I know there is very little NAT64 on wifi. But I might be wrong. Any pointers to wide scale NAT64 on wifi?