Re: IPv6 only host NAT64 requirements?

Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 22 November 2017 08:05 UTC

Return-Path: <alexandre.petrescu@gmail.com>
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 81259126CBF for <ipv6@ietfa.amsl.com>; Wed, 22 Nov 2017 00:05:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level:
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham 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 2POpNhcrhnCU for <ipv6@ietfa.amsl.com>; Wed, 22 Nov 2017 00:05:44 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EF03127444 for <ipv6@ietf.org>; Wed, 22 Nov 2017 00:05:44 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vAM85gZR046651 for <ipv6@ietf.org>; Wed, 22 Nov 2017 09:05:42 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7663B20289C for <ipv6@ietf.org>; Wed, 22 Nov 2017 09:05:42 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5878F2025EC for <ipv6@ietf.org>; Wed, 22 Nov 2017 09:05:42 +0100 (CET)
Received: from [132.166.84.211] ([132.166.84.211]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vAM85eHS012682 for <ipv6@ietf.org>; Wed, 22 Nov 2017 09:05:41 +0100
Subject: Re: IPv6 only host NAT64 requirements?
To: ipv6@ietf.org
References: <m1eEGbJ-0000EhC@stereo.hq.phicoh.net> <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> <46365c7f-f9e9-0559-9f09-d6b565ff7f99@nlogic.no> <0a13ea07-6b60-9ae6-659e-c054acdc156d@gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <2bbae231-d57e-4ba7-8ac5-65dbba9a9da2@gmail.com>
Date: Wed, 22 Nov 2017 09:05:39 +0100
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: <0a13ea07-6b60-9ae6-659e-c054acdc156d@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/G3JRtscyfXLtzUL0yCITrcvvJS0>
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: Wed, 22 Nov 2017 08:05:47 -0000


Le 22/11/2017 à 01:01, Brian E Carpenter a écrit :
> 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.

It will be noticed that on NAT64 ESSID the experience is worse than on 
IPv4, at least for VPN sessions.

Alex

  For this
> class of operator, any change is bad news, unfortunately. What is their
> incentive to make such a change?
> 
>      Brian
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>