On Tuesday, January 24, 2017 1:56 PM, Mark Andrews wrote: > In message <844840869.114000858.1485299485194.JavaMail.zimbra@xxxxxxxxxxxxxxx>, Franck Martin writes: >> >> I think it is time to move to the next level of IPv6 deployment. > ... > Somehow the IETF has been brain washed into thinking than DNS64/NAT64 > is actually the best solution. It really is a total piece if garbage > and should be made historic. It breaks DNSSEC. It requires that > DNS recursive server accept answers from broken authoritative > servers. It doesn't prevent PMTU issues. It doesn't actually have > the reported property that you can tell when you can turn it off. > It makes the network less robust as you cut off IPv4 fallback if > the IPv6 path / servers are broken when both are offered. Language apart, there is a serious question here. Did the IETF produce the right standards for IPv6 only networks? Is NAT64/DNS64 useful or harmful? What else are we missing? It seems that the IETF should try to answer that sooner rather than later. The IETF culture, besides the flowery language, encourages practical engineering and experimentation over speculation. So, yes, maybe we should do some practical experimentation, just like Franck Martin is proposing. Some of that experimentation is of course going on outside the IETF, as reported is this APNIC blog entry https://blog.apnic.net/2017/01/19/ipv6-only-at-microsoft/. The blog explains that Microsoft IT wants to move their network to IPv6 only. They have so many devices that using RFC 1918 addresses requires multiple layers of NAT, and that is really painful to manage. Moving to IPv6 only would reduce the management costs, but of course they have to proceed cautiously. One of the starting points is to deploy IPv6 only in the "guest" network, the Wi-Fi networks used by visitors. This is interesting, because the usage profile of this guest network is very similar to that of the IETF network: visitors using the Internet and connecting back to a variety of companies. As you might expect, they did find issues. Some routers lacked support for RDNSS (RFC6106), and that prevented access by Android devices. The deployment of Azure-AD requires dynamic ACLs (name-based), and these were not supported with IPv6 by some vendors. They found a DHCPv6 bug in Windows 10, which affected both stateful and stateless schemes, but was masked in dual stack deployments. All of these issues are being fixed. On the other hand, they did not find any particular issue with NAT64/DNS64, maybe because few of their visitors actually require DNSSEC. Could we find similar issues with the current IETF network setup? Possibly, but I expect that the bugs will happen in corner cases, such as old OS releases or specific business applications. We will only find these bugs if a large variety of people actually try the IPv6 only network, and complain when stuff does not work. We need to encourage people to actually try the IPv6 only network. Disconnecting IPv4 is one radical way to do that. It certainly has its merits. -- Christian Huitema