Re: IPv6 only host NAT64 requirements?

Brian E Carpenter <> Wed, 22 November 2017 00:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 511BB129BF5 for <>; Tue, 21 Nov 2017 16:01:46 -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 vPLLcQFiKKU4 for <>; Tue, 21 Nov 2017 16:01:45 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EFD27129BF3 for <>; Tue, 21 Nov 2017 16:01:44 -0800 (PST)
Received: by with SMTP id z184so11488044pgd.13 for <>; Tue, 21 Nov 2017 16:01:44 -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-language:content-transfer-encoding; bh=WGLVQDX8rVCEpzYV6R7ftZJkrD9jLjWlwKR1VW1xuQ4=; b=AdnrdjU4zNDMLUEqhahJWJFeX/6tXoZ0TOnqhihacpqVJDqhZ9UnWalrA2WazplGqC c0jmk5Rk4+rGj1OHAF809RTpN2I5DiWM7TYHKG5aNFjTq9pp3bu4BFH2RO2S/fV+aHwe SgpI78hEyEV6M+se+Du1l3ejVUsfzI9F5xx2lOsW1NsaxBOlidAWoOB7kQc63ZUodjm9 TzqPyIyVq9cNQn8cpmGl/swC3Kd+94MxQeefd5V6ZoqnqyBGNR9UExatvLZFORtkxOOH aeHRl6XnPrO7WnRrTtpVXDgcRwAOt8qQIGlFV0/goAoCR4juPRqCmBUuMt49CJDHassP 8qkA==
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-language:content-transfer-encoding; bh=WGLVQDX8rVCEpzYV6R7ftZJkrD9jLjWlwKR1VW1xuQ4=; b=KKs0jH2ST67Hvyrr2sBk/JE/wNgeVlf5vUFiY2GYMWXrx1zDC861epkCp/IvJhQuvK aS3Ep9vVQ2pkNDBvLHZbsNbejgII8YqTCSbqZCEZc9/sM6pN+/vZndQ0bujnR6lCaMFB MZCbWJvoecE7/x2X2VHapD/s4mpgixaiFYqIHfCvRD7q6Vr/xfmapUO47mZTUA62kgca DuPlD4xBqbDOfpyTtQE3Jpjk/O9gagYqZfQeMYMFT20N6gUgKCZSRkLE2gH9I4IJjtzZ +jGISw4jTwRuP5eorOX/W2dgTBJhRGEgk7D+MqSVMQp/i2UIBbMY3QjdMiCE9w0G8Ii/ joGg==
X-Gm-Message-State: AJaThX7J5+7S0+RO6hfrVFjUdYUqduA9VpQT+O7Rd85fZUU7Mu7QhpmH 6GCx48cfJ9BQKl6ZZwekeWPziz5+
X-Google-Smtp-Source: AGs4zMYDyiwamSDE9LFZBDbi2cWbXUFYqvwYr/nvgCxZdgn+qXAFiLdq7WCJE/9ffQKtVl83/1wtbQ==
X-Received: by with SMTP id s25mr18911865pge.310.1511308904032; Tue, 21 Nov 2017 16:01:44 -0800 (PST)
Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by with ESMTPSA id a78sm26659314pfl.155.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Nov 2017 16:01:42 -0800 (PST)
Subject: Re: IPv6 only host NAT64 requirements?
To: Ola Thoresen <>,
References: <> <> <> <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Wed, 22 Nov 2017 13:01:44 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Nov 2017 00:01:46 -0000

in line...

On 21/11/2017 22:40, Ola Thoresen wrote:
> On 20. nov. 2017 20:37, Brian E Carpenter wrote:
>> On 21/11/2017 02:36, Ole Troan wrote:
>> ...>> [Med] These are generic statements, Ole. We are talking about the IETF case.
>>>> * The IETF has no control on the hosts that connect to the IETF network,
>>>> * IETF attendees who are using corporate devices, have no control on these hosts
>>>> So, how forcing devices to use "IPv6+nat64" will help here?
>>> Eat own dogfood. Many IETF people are developers or work for companies having applications not working.
>>> As I said there were a minimum of applications that didn't work. Corporate VPNs largely did. Jen has the final numbers.
>> However, as long as even one application, such as one VPN, or one
>> literal IPv4 address, fails, that represents millions of failure cases
>> if we consider the whole world (e.g. imagine every hotel network in
>> the world running IPv6+NAT64 only). That simply isn't viable. Dual
>> stack in every hotel room in the world is viable, from the hotel guests'
>> point of view. Operators might not like it, but users wouldn't care.
> In hotel rooms and other "public" or "guest" networks, there are so many 
> things that fail already, due to NAT, misconfigured firewalls, 
> unmaintained blocklists, SSL-proxies and whatnot, so you can hardly 
> expect any services other than basic web-surfing without https to work.
> Not that this is an ideal situation today, but i do not believe that "if 
> even one VPN or one liter IPv4 address fails" should be a showstopper 
> for introducing this.

Hotels won't make that choice, but the providers of hotel networks will,
entirely based on their perception of the number of help desk calls
they will have to handle for any given change. Since they haven't even
made the move from IPv4 to dual stack, I think we'll wait a long time
before they attempt any form of IPv6-only. Sad but true.

> Possibly, or even probably, introducing IPv6 (-only and NAT64) will even 
> make the situation better for a lot of people, as you get rid of all the 
> horrible NAT solutions for services that are already dual stacked.

But those horrible NAT solutions are up and running today. For this
class of operator, any change is bad news, unfortunately. What is their
incentive to make such a change?