Re: IPv4 outage at next IETF in Chicago

Mark Andrews <marka@isc.org> Tue, 24 January 2017 23:56 UTC

Return-Path: <marka@isc.org>
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 A62F112958A for <ietf@ietfa.amsl.com>; Tue, 24 Jan 2017 15:56:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.1
X-Spam-Level:
X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 XCuJI5Fl5kHU for <ietf@ietfa.amsl.com>; Tue, 24 Jan 2017 15:56:35 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (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 71A5D12955A for <ietf@ietf.org>; Tue, 24 Jan 2017 15:56:35 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id DD5721FCADA; Tue, 24 Jan 2017 23:56:30 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 8EF7C16006F; Tue, 24 Jan 2017 23:56:29 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 80F0D16006D; Tue, 24 Jan 2017 23:56:29 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id O0TteeQ4WJuL; Tue, 24 Jan 2017 23:56:29 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 0AEC3160067; Tue, 24 Jan 2017 23:56:29 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 042F960836B0; Wed, 25 Jan 2017 10:56:26 +1100 (EST)
To: Franck Martin <franck@peachymango.org>
From: Mark Andrews <marka@isc.org>
References: <844840869.114000858.1485299485194.JavaMail.zimbra@peachymango.org>
Subject: Re: IPv4 outage at next IETF in Chicago
In-reply-to: Your message of "Tue, 24 Jan 2017 17:11:25 -0600." <844840869.114000858.1485299485194.JavaMail.zimbra@peachymango.org>
Date: Wed, 25 Jan 2017 10:56:25 +1100
Message-Id: <20170124235626.042F960836B0@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/3fxAcPfL707d5UADkh4VPCvoKFw>
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: Tue, 24 Jan 2017 23:56:36 -0000

In message <844840869.114000858.1485299485194.JavaMail.zimbra@peachymango.org>,
 Franck Martin writes:
> 
> I think it is time to move to the next level of IPv6 deployment. 

There are several "next level" alternatives when moving on from dual
stack native IPv4 + native IPv6.

There is:
(1) native IPv6 + RFC 1918 (single NAT)
(2) native IPv6 + RFC 6598 + RFC 1918 (double NAT)
(3) dual stack lite (network)
(4) dual stack lite (host mode)
(5) MAP-*
(6) 464XLAT + RFC 1918
(7) DNS64/NAT64

Now if we want to simulate a IPv6 only access network then the choices
above drop.

> Ideally the IETF WiFi network should now only provide the following 2 network
> s: 
> 1)IPv6-only 
> 2)IPv6-only with NAT64 

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.
 
> The later should be the default network. 

Something other than native IPv4 + native IPv6 should be the default
network.  DNS64/NAT64 is really the worst choice that could be made.
 
> However you would say, well some stuff will break, some non technical people 
> will use the IETF network and may have a bad experience, etc... 
> 
> So to be conservative but at the same time futurist and like it was done a
> few years back, why not create again an IPv4 outage of a few hours where the
> above 2 networks would be the only networks available? 
> 
> Depending on results, this outage could be expanded to a full day at the
> following meeting, until the IPv4 network is totally removed from the WiFi? 



-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org