RE: IPv4 outage at next IETF in Chicago

["Christian Huitema" <[e-mail]>]

On Tuesday, January 24, 2017 1:56 PM, Mark Andrews wrote:
> In message
<[e-mail]>,
 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