RE: IPv4 outage at next IETF in Chicago

"Christian Huitema" <huitema@huitema.net> Wed, 25 January 2017 02:32 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91E112960B for <ietf@ietfa.amsl.com>; Tue, 24 Jan 2017 18:32:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.757
X-Spam-Level:
X-Spam-Status: No, score=-3.757 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAggkGKT7ZFp for <ietf@ietfa.amsl.com>; Tue, 24 Jan 2017 18:32:18 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9E5C129609 for <ietf@ietf.org>; Tue, 24 Jan 2017 18:32:18 -0800 (PST)
Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from <huitema@huitema.net>) id 1cWDNe-0008R9-Qh for ietf@ietf.org; Wed, 25 Jan 2017 03:32:17 +0100
Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1cWDNY-0002Qm-KQ for ietf@ietf.org; Tue, 24 Jan 2017 21:32:12 -0500
Received: (qmail 29877 invoked from network); 25 Jan 2017 02:32:07 -0000
Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[72.235.151.78]) (envelope-sender <huitema@huitema.net>) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for <franck@peachymango.org>; 25 Jan 2017 02:32:07 -0000
From: "Christian Huitema" <huitema@huitema.net>
To: "'Mark Andrews'" <marka@isc.org>, "'Franck Martin'" <franck@peachymango.org>
References: <844840869.114000858.1485299485194.JavaMail.zimbra@peachymango.org> <20170124235626.042F960836B0@rock.dv.isc.org>
In-Reply-To: <20170124235626.042F960836B0@rock.dv.isc.org>
Date: Tue, 24 Jan 2017 16:32:04 -1000
Message-ID: <158901d276b3$387d6050$a97820f0$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQG+jtYcbBystn14OjrLO3uYI3C8fwLHtyGeoVoAj/A=
Content-Language: en-us
Subject: RE: IPv4 outage at next IETF in Chicago
X-Originating-IP: 168.144.250.223
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.07)
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49KxQtGn3AswOT8Z9YHdvpk1TugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXrS5K5M/+nUhFJOOeOCh1LFRcOb18WfxGyg6Om6u4YYm+2z8zFgNNTT0xn2 LclGjHY5hjoyEb9Oq0NWpyO3vrfYnGR8JorokUtMqNDt1Oktij3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB8y9Ga5iCmdJFIvDEJb+pKRQRCdMNhge1Unb77YyuZq7yps5sRMgeW0yV2MVvo4GwRBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/edseI+0iffshWIcU02XSgP6DwZpjxPTx I2S/vwoydU2Z0wfN9VTx9JdR4F4pphrEJ0EukYkH0+QwgTkvGReJqYh2OsKXXkoVR3vRgp+PhUTh 7upESYb585WZ0BSQoLJU+W1yoEebBdUEsgNISVL9yegi7l2L6mELqRuZP6QqjQj7NlKfHadlY9VB h5JyIzzQ/I1dpLTifeoHWo0A7trCgivvMbIIty1BrdRX3euPU+v6hYCF0D67O+iDK8Lnv/b76AUl dlnP6rsIRqexmUumoDs+X00vOaBfD53MN4G7rdk=
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
X-Recommended-Action: accept
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/kgPaNKiNpEt0ZeDGaijh8Ey4h4E>
Cc: 'IETF' <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Jan 2017 02:32:21 -0000

On Tuesday, January 24, 2017 1:56 PM, Mark Andrews wrote:
> In message
<844840869.114000858.1485299485194.JavaMail.zimbra@peachymango.org>rg>,
 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