>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?
