Re: IPv4 outage at next IETF in Chicago

Brian E Carpenter <> Wed, 25 January 2017 01:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E0F1C1295F9 for <>; Tue, 24 Jan 2017 17:21:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kyTcVo90Ofck for <>; Tue, 24 Jan 2017 17:21:22 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6A802129564 for <>; Tue, 24 Jan 2017 17:21:22 -0800 (PST)
Received: by with SMTP id 194so59446175pgd.2 for <>; Tue, 24 Jan 2017 17:21:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 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 with ESMTPSA id 19sm47445396pft.46.2017. (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 <>
References: <> <> <WM!9d8566ee4a667cbd16edab2df707ef7a0c8c696ee92bca1ab194c80d7f9f38afca46538cbe422dcfd43306b1345f3435!> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
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: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: IETF <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


On 25/01/2017 14:05, Franck Martin wrote:
> ----- Original Message -----
>> From: "Brian E Carpenter" <>
>> To: "Franck Martin" <>rg>, "IETF" <>
>> 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:
> 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.