Re: IPv4 outage at next IETF in Chicago

Mark Andrews <marka@isc.org> Wed, 25 January 2017 01:46 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 C06E3129601 for <ietf@ietfa.amsl.com>; Tue, 24 Jan 2017 17:46:21 -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 YpNMXzANxbBd for <ietf@ietfa.amsl.com>; Tue, 24 Jan 2017 17:46:20 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.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 4A36D1295F8 for <ietf@ietf.org>; Tue, 24 Jan 2017 17:46:20 -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 BF8891FCADD; Wed, 25 Jan 2017 01:46:15 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 746DB160067; Wed, 25 Jan 2017 01:46:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 61BCA16006D; Wed, 25 Jan 2017 01:46:14 +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 cYqZjTgpwh_i; Wed, 25 Jan 2017 01:46:14 +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 8F942160067; Wed, 25 Jan 2017 01:46:13 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id B66F160845F9; Wed, 25 Jan 2017 12:46:08 +1100 (EST)
To: Franck Martin <franck@peachymango.org>
From: Mark Andrews <marka@isc.org>
References: <844840869.114000858.1485299485194.JavaMail.zimbra@peachymango.org> <8112f1a6-f63a-e771-f354-206fbb9d684f@gmail.com> <WM!9d8566ee4a667cbd16edab2df707ef7a0c8c696ee92bca1ab194c80d7f9f38afca46538cbe422dcfd43306b1345f3435!@mailstronghold-1.zmailcloud.com> <212835829.114144965.1485306337275.JavaMail.zimbra@peachymango.org>
Subject: Re: IPv4 outage at next IETF in Chicago
In-reply-to: Your message of "Tue, 24 Jan 2017 19:05:37 -0600." <212835829.114144965.1485306337275.JavaMail.zimbra@peachymango.org>
Date: Wed, 25 Jan 2017 12:46:08 +1100
Message-Id: <20170125014608.B66F160845F9@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/9Jts7O7aN-2WhcJ4HsWPMBFHCuE>
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 01:46:22 -0000

In message <212835829.114144965.1485306337275.JavaMail.zimbra@peachymango.org>rg>,
 Franck Martin writes:
> 
> ----- Original Message -----
> > From: "Brian E Carpenter" <brian.e.carpenter@gmail.com>
> > To: "Franck Martin" <franck@peachymango.org>rg>, "IETF" <ietf@ietf.org>
> > Sent: Tuesday, January 24, 2017 4:33:22 PM
> > Subject: Re: IPv4 outage at next IETF in Chicago
> 
> > On 25/01/2017 12:11, Franck Martin wrote:
> >> I think it is time to move to the next level of IPv6 deployment.
> >> 
> >> Ideally the IETF WiFi network should now only provide the following 2 netw
> orks:
> >> 1)IPv6-only
> >> 2)IPv6-only with NAT64
> >> 
> >> The later should be the default network.
> >> 
> >> 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?
> > 
> > That would be a good way of damaging IETF productivity for a few hours.
> 
> Do you have evidence of applications not running in a NAT64 environment? I'm 
> interested to know them.

Anything that really wants to know is AAAA records exist or not.
You don't run NAT64 w/o DNS64 and that munges with DNS answers.
Lots of what I do would break because of that.  I need to know the
truth, not the lies from DNS64.  And yes I have written DNS64 code.

> > And for what? Moving away from the mainstream coexistence mechanism (dual
> > stack),
> > to a mechanism known to be intrinsically defective (NAT). I don't see
> > the point.
> 
> I fail to see how NAT is intrinsically defective, since it is used
> successfully by everyone...

No one successfully uses NAT.  They just put up with its limitations.
There is a big difference.  That said there will always be limitations
delivering IPv4 going into the future.

> Nevertheless, the goal here is to get the Internet designers (IETF) to
> have operational experience on what needs to be fixed.

Step 1.  Stop saying to use NAT64.  There are other ways to provide
IPv4 as as a service with IPv6 only all the way to the node.

> When the IPv4 outage happened a few years back, it gave a serious impetus
> in getting IPv6 totally mainstream on many platforms.
> 
> IAB encourages IPv6: https://www.iab.org/2016/11/07/iab-statement-on-ipv6/
> 
> However going IPv6-only can only be done in walled gardens. There still will 
> be many environments with IPv4 only. A solution here is to move networks to
> NAT64, so you only need to support IPv4 at the edges...

No.  The goal is IPv6-only access networks with IPv4 as service,
then IPv6-only within the home / enterprise with IPv4 as a service.
Note this doesn't specify a solution.

> Yes creating an outage for the sake of an outage is pointless, experience on 
> what works and not work needs to be recorded.
> 
> May be the first step instead of doing an outage is to have as default
> a NAT6 4 network at IETF meetings and a dual stack network for the people
> that experience issues.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org