Re: IPv4 outage at next IETF in Chicago

Franck Martin <franck@peachymango.org> Wed, 25 January 2017 03:24 UTC

Return-Path: <franck@peachymango.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 9B59C129650 for <ietf@ietfa.amsl.com>; Tue, 24 Jan 2017 19:24:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=peachymango.org
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 xj804t7sPfno for <ietf@ietfa.amsl.com>; Tue, 24 Jan 2017 19:24:33 -0800 (PST)
Received: from zmcc-5-mx.zmailcloud.com (zmcc-5-mx.zmailcloud.com [192.198.93.228]) (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 2C65D12964F for <ietf@ietf.org>; Tue, 24 Jan 2017 19:24:33 -0800 (PST)
Received: from zmcc-5-mta-1.zmailcloud.com (127.37.197.104.bc.googleusercontent.com [104.197.37.127]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by zmcc-5-mx.zmailcloud.com (Postfix) with ESMTPS id 5E86D520273; Tue, 24 Jan 2017 22:24:32 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id 11A09C1962; Tue, 24 Jan 2017 21:24:32 -0600 (CST)
Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id XXbrLXLs7ife; Tue, 24 Jan 2017 21:24:31 -0600 (CST)
Received: from localhost (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id 8AC7CC1985; Tue, 24 Jan 2017 21:24:31 -0600 (CST)
DKIM-Filter: OpenDKIM Filter v2.9.2 zmcc-5-mta-1.zmailcloud.com 8AC7CC1985
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1485314671; bh=c2EhU5YGwFh7d8b6fLK/JlJDdiUpjyJY/bvyJKothNg=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=hHo1x/vYzgzBReABbpKtuXoQlHEwm4PDOgHz6nliIy1kt3yUYUQp8aLsD6L7KRopD H3NPhzo5fRXwi+18bo3E8vxTMbavoLiOjdVWzEhQKwcASvMpT34EDyCP5WN7a1RF+R ByDYQ2WJWy7yHfBLW4VMBIdf2AhDx+uY4DTjwaIY=
X-Virus-Scanned: amavisd-new at zmcc-5-mta-1.zmailcloud.com
Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yQNOr5Pz74X6; Tue, 24 Jan 2017 21:24:31 -0600 (CST)
Received: from zmcc-5-mailbox-1.zmailcloud.com (zmcc-5-mailbox-1.zmailcloud.com [10.240.0.12]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id 730A9C1962; Tue, 24 Jan 2017 21:24:31 -0600 (CST)
Date: Tue, 24 Jan 2017 21:24:31 -0600 (CST)
From: Franck Martin <franck@peachymango.org>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <1241168857.114300131.1485314671295.JavaMail.zimbra@peachymango.org>
In-Reply-To: <WM!d42d3ceb3d1cd674dd9f1ad2a99fbed5e41e8de6ce258b70db511984b58d1e426445eb716e9fa13ee84ef542e91f73ed!@mailstronghold-1.zmailcloud.com>
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> <2f5e2404-7d71-afcc-9b50-4d791ef74299@gmail.com> <WM!d42d3ceb3d1cd674dd9f1ad2a99fbed5e41e8de6ce258b70db511984b58d1e426445eb716e9fa13ee84ef542e91f73ed!@mailstronghold-1.zmailcloud.com>
Subject: Re: IPv4 outage at next IETF in Chicago
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - FF50 (Mac)/8.6.0_GA_1194)
Thread-Topic: IPv4 outage at next IETF in Chicago
Thread-Index: 3gS484+R/fMdG2k5admghzJ8QxjxIA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/tZiTJueIdFv495AYQUzLzRv5qZk>
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 03:24:34 -0000

Brian,

This is hardly to prove a point.

It is to have an operational experience so that stuff gets fixed and standards get written to fix stuff.

An IPv4 outage is radical, granted, may be it should be done during hackday on the weekend before IETF. May be it should not be done at all and instead the default network SSID:IETF to be NAT64, with an SSID:IETF-IPv4-only.

May be NAT64 is not the right one, may be it is XLAT464? (NAT64/DNS64 does not require much client participation, XLAT464 does).

May be it is way too short to have it in Chicago? Likely.

May be it should be better planned. Certainly.

We need a transition to IPv6-only, this go via dual stack, sure, but do we have to wait for the whole world to be IPv6 before we can deprecate IPv4? No, we need something that allows to have IPv6-only networks (enterprise, guest, customers,...) capable of talking to the legacy Internet. We also realize that the bottom line is: "dual stack=dual costs" and "dual stack=dual security issues". As the world progress, the need for NAT64 will go away...

So, this is a very interesting discussion, as long we move towards some solution(s).

What do you propose?

----- Original Message -----
From: "Brian E Carpenter" <brian.e.carpenter@gmail.com>
To: "Franck Martin" <franck@peachymango.org>
Cc: "IETF" <ietf@ietf.org>
Sent: Tuesday, January 24, 2017 5:21:23 PM
Subject: Re: IPv4 outage at next IETF in Chicago

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.
> 
>  
>