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
- Re: IPv4 outage at next IETF in Chicago Mark Andrews
- Re: IPv4 outage at next IETF in Chicago Matthew Pounsett
- IPv4 outage at next IETF in Chicago Franck Martin
- Re: IPv4 outage at next IETF in Chicago Franck Martin
- Re: IPv4 outage at next IETF in Chicago JORDI PALET MARTINEZ
- Re: IPv4 outage at next IETF in Chicago JORDI PALET MARTINEZ
- Re: IPv4 outage at next IETF in Chicago Mark Andrews
- Re: IPv4 outage at next IETF in Chicago Brian E Carpenter
- Re: IPv4 outage at next IETF in Chicago Jared Mauch
- Re: IPv4 outage at next IETF in Chicago Franck Martin
- Re: IPv4 outage at next IETF in Chicago Brian E Carpenter
- Re: IPv4 outage at next IETF in Chicago Mark Andrews
- Re: IPv4 outage at next IETF in Chicago JORDI PALET MARTINEZ
- RE: IPv4 outage at next IETF in Chicago Christian Huitema
- Re: IPv4 outage at next IETF in Chicago Jeffrey Eric Altman
- RE: IPv4 outage at next IETF in Chicago Michel Py
- Re: IPv4 outage at next IETF in Chicago Franck Martin
- Re: IPv4 outage at next IETF in Chicago Mark Andrews
- Re: IPv4 outage at next IETF in Chicago JORDI PALET MARTINEZ
- Re: IPv4 outage at next IETF in Chicago Franck Martin
- RE: IPv4 outage at next IETF in Chicago Michel Py
- Re: IPv4 outage at next IETF in Chicago Mark Andrews
- Re: IPv4 outage at next IETF in Chicago Stewart Bryant
- Re: IPv4 outage at next IETF in Chicago Marco Davids
- Re: IPv4 outage at next IETF in Chicago John C Klensin
- Re: IPv4 outage at next IETF in Chicago Dave Crocker
- RE: IPv4 outage at next IETF in Chicago Adrian Farrel
- Re: IPv4 outage at next IETF in Chicago Paul Hoffman
- Re: IPv4 outage at next IETF in Chicago Matthew Pounsett
- Re: IPv4 outage at next IETF in Chicago Randy Bush
- Re: IPv4 outage at next IETF in Chicago Brian E Carpenter
- Re: IPv4 outage at next IETF in Chicago Franck Martin
- Re: IPv4 outage at next IETF in Chicago Michal Krsek
- Re: IPv4 outage at next IETF in Chicago joel jaeggli
- Re: IPv4 outage at next IETF in Chicago Mark Andrews
- Re: IPv4 outage at next IETF in Chicago Phillip Hallam-Baker
- Re: IPv4 outage at next IETF in Chicago Warren Kumari
- Re: IPv4 outage at next IETF in Chicago Lee Howard
- Re: IPv4 outage at next IETF in Chicago Randy Bush
- Re: IPv4 outage at next IETF in Chicago John C Klensin
- Re: IPv4 outage at next IETF in Chicago Randy Bush
- Re: IPv4 outage at next IETF in Chicago Randy Bush
- Re: IPv4 outage at next IETF in Chicago John C Klensin