Re: IPv4 outage at next IETF in Chicago

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 25 January 2017 01:21 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 E0F1C1295F9 for <ietf@ietfa.amsl.com>; Tue, 24 Jan 2017 17:21:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 kyTcVo90Ofck for <ietf@ietfa.amsl.com>; Tue, 24 Jan 2017 17:21:22 -0800 (PST)
Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A802129564 for <ietf@ietf.org>; Tue, 24 Jan 2017 17:21:22 -0800 (PST)
Received: by mail-pg0-x22d.google.com with SMTP id 194so59446175pgd.2 for <ietf@ietf.org>; Tue, 24 Jan 2017 17:21:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=v/VzdkEe3x5U2NFDG/dCGW5SKtdEZuYD388gvpHIz2A=; b=iWuFXUZwSy/ZkseFwGOOmJM4r8Xu5mu9pcggbBhNVGAhZylKVXDgH5z7tLkb/IFSW3 4nsSJRCikNY/+N89HZfMDTbY4tvdV8geewZnITCxGOmolMfVA+1yE0LASAgqd927W/IK A4iX36H2DjPW/m+03V1MkbA8775flR+cXfIazCKDXTIFWkt2QBKAHrOLdTYXyXtmQCPO Vqf6uezK4qFzlW1MVGNc6Kx1Of9mA52+zgIFQTIWwlnsakBmP1PheHkPJGnD/evAh/Q2 pgRI3M9doqWfMssc+b7a3k5gER1bf5c0a03tOBo6zIsxQm1HsxSExWb03AFz8OeB2/2D lDMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=v/VzdkEe3x5U2NFDG/dCGW5SKtdEZuYD388gvpHIz2A=; b=NVIdOOojgE8ye5ubTenqDa6mXMt7GA68sSFq4pfIKt5nCOGeBxsnDWziW/zWd1ZEjP wZJs7AYYuKmhbv4cSgwRTfExywOlPXiI1ZISsyfOnc/9b8bYnkzJ/wNURmJLAr7afekf IiHVUyCbXRHv3orN1s78qeOMFngnZqgiQhLEGnhOb4dzNHYq2AeCz6upQ07Q754F4Ngb Cqu+YPJmyooPrOl5TQAORw3GMND0Ceu5zmo8G8eII6fHxAbrbhxaETa5Owf2nnAPjEu7 UfKNKueg8thA4eUbWg5OjIfnbTY8PzM6OsJ1FlkugO2E8+/P1FN67n/cojboKF5Qd7pi OmIw==
X-Gm-Message-State: AIkVDXLXgZN3p8jrPpuv7rl+oedInKhnXilKXe5pavXTY5Y4tcyUQSSjurKokJ2QFTI4IA==
X-Received: by 10.99.65.1 with SMTP id o1mr43243143pga.93.1485307282000; Tue, 24 Jan 2017 17:21:22 -0800 (PST)
Received: from ?IPv6:2406:e007:6382:1:28cc:dc4c:9703:6781? ([2406:e007:6382:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 19sm47445396pft.46.2017.01.24.17.21.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Jan 2017 17:21:21 -0800 (PST)
Subject: Re: IPv4 outage at next IETF in Chicago
To: Franck Martin <franck@peachymango.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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <2f5e2404-7d71-afcc-9b50-4d791ef74299@gmail.com>
Date: Wed, 25 Jan 2017 14:21:23 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <212835829.114144965.1485306337275.JavaMail.zimbra@peachymango.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/2kVC4436Dx4A6uwAcT9Hbb8DZY0>
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:21:24 -0000

Franck, I try not to be religious about NAT, and I use NAT44 every day
like most people. Also like most people, I experience occasional
unexplained failures of web-based transactions. Whether they are due
to a NAT garbage-collect or a load-balancer failure, I don't know,
of course. But actually I am not deeply concerned about NAT64, although
any failures that it generates would be very hard to identify. I am
more concerned about IETF participants whose devices are not set up
as dual stack nodes at all. They would be completely blocked. Yes,
I know, such people should not exist, should be deeply ashamed, etc.
But I don't see why we would cut them off to prove a point.

Regards
   Brian

On 25/01/2017 14:05, Franck Martin wrote:
> 
> ----- 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 networks:
>>> 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.
> 
>>
>> 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...
> 
> Nevertheless, the goal here is to get the Internet designers (IETF) to have operational experience on what needs to be fixed.
> 
> 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...
> 
> 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 NAT64 network at IETF meetings and a dual stack network for the people that experience issues.
> 
>  
>