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
