>It makes sense because the people interested to test this have already >done so to the point of seeing no problems for themself. But that group >is biased, probably running their services at home like vpn gateways at >dual stack or IPv6-only already and therefore they might simply not >encounter problems that might otherwise still be common. As IPv4 scarcity >is a reality now, public wifi installations might want to use NAT64 >networks eventually. So it makes sense to find out what would break >and should be fixed before this is deployed unto an unsuspecting public. >A community of highly qualified networking experts appears to be the >right group of people to have for a test audience.
A common complaint about IPv6 is that IPv6 is not just "IPv4 with longer addresses", but made all kinds of changes that come back to bite us. Another complaint is that there are almost always two ways of doing something and sometimes many more. So If we compare NAT64 on wifi with dual stack then we see both complaints in action. Dual stack is perfectly compatible with IPv4-only devices. In fact, it works so well that nobody even notices that they are connecting to a dual stack network. 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. We cannot use DNS64 if we expect IPv4 literals or local DNSSEC validation. 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. 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.
