Re: IPv6 only host NAT64 requirements?

Brian E Carpenter <> Mon, 20 November 2017 19:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B493120713 for <>; Mon, 20 Nov 2017 11:37:32 -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 S40ysdz2Bi6Z for <>; Mon, 20 Nov 2017 11:37:31 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB57512EA81 for <>; Mon, 20 Nov 2017 11:37:30 -0800 (PST)
Received: by with SMTP id r62so8016913pfd.5 for <>; Mon, 20 Nov 2017 11:37:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/QAj1Ar5KXUpwM7JMaK+4OkufHThGOQdXAhzCAG8WT0=; b=H1bf85nJP17r3BlbxCBFqyteAbZoeWTh+th/UlOtG+mAI9fvQozDzemtrhejeMdMz7 HiHEofTDH2jDfoFaGyQJ5ey8HA1qH0Hd6rDi01cBp0WkeFbxiXwZ12S/99FOeHSA6VEe rTnNxgKNAsr8BgPhguIBJqCCX2vzuFaACECATz1CryDNUSVN+6igVF/TFSiYOOXX5qj8 uvcRPwYQaYRu7EOKqRmP6iKnxepAOb0x/EWgHynYJ4Fs+fI7L5VYyhYJxEPwcFIn9tnS jOJFPi/LxtJaCDYXmQVFKtfCFN1vF6poJs1gJ2BqmFF+Yw1GDWXQrEw5Kau9WZ5/wmDp V1+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=/QAj1Ar5KXUpwM7JMaK+4OkufHThGOQdXAhzCAG8WT0=; b=BWbg4yjWZbz1MdA49IcpPc3LHx7NCAN7JIEbUBxOa58u+8BXvAOXPb5iRwajYmLJGp Vac8bYsBM/QK4ZWVSahAuIZhyV60SDTsqsfyEgR6P9AbU7o55Fl2NVmSrmM5Ep2nwA8U VJKdItYfcEtMCoAn8CQ8niPcYPhigpz/R6+MKCzEnXaeZJF0XC+OrSUffAdyOYn1z9eG L3lCtBFDpjpw1/T7TuEaNJaYq/N9OmOneQtA5gXyGyz35j4UjngqVoRALpKS4pZs1sm5 kcYyQQ2Mq0IG8qfeVbxEHS2flI0EuW25BjSSUVLhuAib8lhf9n6gjCfNapdcwqbiVHoA 58Bg==
X-Gm-Message-State: AJaThX7oF6Q6nGdnQ65oHpsi/Cwa2iaCDA9eN5VTNMrD8CdDGyVnZTY/ FyFA8DFb54e07qo63nfw3NM=
X-Google-Smtp-Source: AGs4zMasCus2cOXTr78O+EAkIjUb2lWSvxVRnNCN+nqujwhP5EFayo0er8BU7jls19qz5uhKvF/sHA==
X-Received: by with SMTP id h26mr12275282pfi.233.1511206650321; Mon, 20 Nov 2017 11:37:30 -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 l191sm25573936pfc.180.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Nov 2017 11:37:29 -0800 (PST)
Subject: Re: IPv6 only host NAT64 requirements?
To: Ole Troan <>, Mohamed Boucadair <>
Cc: 6man WG <>, Mark Andrews <>
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: Tue, 21 Nov 2017 08:37:28 +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: Mon, 20 Nov 2017 19:37:32 -0000

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.