Re: IPv4 outage at next IETF in Chicago

Brian E Carpenter <> Wed, 25 January 2017 00:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BBB721295D1 for <>; Tue, 24 Jan 2017 16:33: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, 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 bpciQZR9s1n1 for <>; Tue, 24 Jan 2017 16:33:22 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 759341295CD for <>; Tue, 24 Jan 2017 16:33:22 -0800 (PST)
Received: by with SMTP id 14so59114302pgg.1 for <>; Tue, 24 Jan 2017 16:33:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=XgKHCrqy//jKikJ4u10dBkrR2FAh6GfFHwA001EGhUs=; b=Y01zodmwtRP0asWEJuj+ZRA1TfU8us+FHn1WPT67MeKii5G4atTgcpV4G61uhGOdmd 6rmd72MccDQwd8vgSiJIeKepTxjGh1QS8CJe08ZK0kaAzDGw3aPRdl2OpxlITW5wK0Rp yVlQthCT3ZK24lEtSA000Mm97X3MSC7z+znqf8aqYEQLjwj/uZVhPd/7+4+0buZZfR8D /eCZR/iuHkluABe0xFJTAuo0CWImBu5XiLOqxGfZgqyiolDB0CJWM+ZxjImN4AMa27FR So017pREJnd1hNG/mq5YpFKmZhciVOXqnEPquTlmIUFbjfb/2asnbE1OtVVHJymM2Qwy pbTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=XgKHCrqy//jKikJ4u10dBkrR2FAh6GfFHwA001EGhUs=; b=hrzPKWvb080+OF+7R7giAM3ALjZYYUtk6xFhq7v3uewezLh1tU0QhB4dGok5mID6tI EP+8DmaardmLcBZ+xILPBB0irdXvA7ftYw94UP2kPzt37aHk0+Pn09Mx6duUDAujqxhw I+2pbm74Hlm0YsezjPukRTnf/ssK7v4ZDVaH57k7bkU8I7BQKeRH+krV1EQMOQUateT9 +IFVNkn52X1ubeRqivgfk02KXEXjI6upnCNqS1FfKtZi+Hur5L3CmVscwsmx4/u+EJg3 gRlp9WtbIbgdcLCw/5Vt/eW9lisrLPjhzWdqd5Wh5rKVovp1xYoEjtQZH+nYtrbQFb9+ SuxQ==
X-Gm-Message-State: AIkVDXKrUdAluXSlWbsA1Km4DZsBizUs3deHsdeqPKF6crKn3leOT31uSVmiWcfRmeK2gQ==
X-Received: by with SMTP id u74mr42791732pfi.116.1485304401335; Tue, 24 Jan 2017 16:33:21 -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 e129sm28856311pfe.8.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Jan 2017 16:33:20 -0800 (PST)
Subject: Re: IPv4 outage at next IETF in Chicago
To: Franck Martin <>, IETF <>
References: <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Wed, 25 Jan 2017 13:33:22 +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: <>
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 00:33:24 -0000

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.

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.

IPv6-only is a *very* long term goal for campus/enterprise networks, which the IETF
network resembles. Our realistic goal today is for enterprise networks to achieve
dual-stack coexistence, and most enterprise network are nowhere near that point yet.

There is no point in leading from so far out in front that nobody else can
see you.


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