Re: IPv6 only host NAT64 requirements?

Ola Thoresen <ola@nlogic.no> Tue, 21 November 2017 09:40 UTC

Return-Path: <ola@nlogic.no>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AFD12944A for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2017 01:40:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
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 pl1f6S8BCEA7 for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2017 01:40:20 -0800 (PST)
Received: from smtp12.doorway.no (smtp12.doorway.no [212.125.205.195]) (using TLSv1.2 with cipher AES256-SHA256 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AEF3120227 for <ipv6@ietf.org>; Tue, 21 Nov 2017 01:40:19 -0800 (PST)
Received: from dware1044.doorway.loc (10.0.20.54) by smtp12.doorway.no (10.0.21.42) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 21 Nov 2017 10:40:13 +0100
Received: from olen-ws.dhcp.nlogic.no (84.208.27.142) by dware1044.doorway.loc (10.0.20.54) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 21 Nov 2017 10:40:13 +0100
Subject: Re: IPv6 only host NAT64 requirements?
To: <ipv6@ietf.org>
References: <m1eEGbJ-0000EhC@stereo.hq.phicoh.net> <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org> <D42D8D7A-6D19-4862-9BB3-4913058A83B6@employees.org> <CAFU7BARCLq9eznccEtkdnKPAtKNT7Mf1bW0uZByPvxtiSrv6EQ@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <CAFU7BARoXgodiTJfTGc1dUfQ8-ER_r8UOE1c3h-+G0KTeCgBew@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <F9E3BD88-38E0-4329-A4BF-22083A023268@employees.org> <f673d6c7-570e-b2b8-e8aa-15d73ea8ba3f@gmail.com>
From: Ola Thoresen <ola@nlogic.no>
Message-ID: <46365c7f-f9e9-0559-9f09-d6b565ff7f99@nlogic.no>
Date: Tue, 21 Nov 2017 10:40:13 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <f673d6c7-570e-b2b8-e8aa-15d73ea8ba3f@gmail.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Originating-IP: [84.208.27.142]
X-ClientProxiedBy: DWARE1041.doorway.loc (10.0.20.51) To dware1044.doorway.loc (10.0.20.54)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/L9swvKgNfeKHXCvp-E-PT_D_v4M>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2017 09:40:22 -0000

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


Rgds.

Ola Thoresen