Re: IPv6 only host NAT64 requirements?

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Mon, 20 November 2017 20:10 UTC

Return-Path: <prvs=1497b6414a=jordi.palet@consulintel.es>
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 6DE7C12EA93 for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 12:10:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es
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 Q93yVCRLYT6W for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 12:10:39 -0800 (PST)
Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53321126BF7 for <ipv6@ietf.org>; Mon, 20 Nov 2017 12:10:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1511208637; x=1511813437; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=cDkBmImMnQhR6CGoFndw/grjA cbyCv/ecmWyCRLDLM0=; b=m31o/kv2PUF8CbLqZceuDdjXvJVowAXIEOW9u9DdT 8DROho6MqKishZQ3VwfwiLmgcOeThyvfEr6BZyOYI6E4rBxAbAiEDgoAK7+xGLTd Y33LUlCOzUqF2N/mXo2cnzGxrZgADq79SfpIq8i7vKU4u1b8II+qOGEcdBxzRSsz D8=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=VOFuIV/GWXPiRuXLq9JI+cxt4r+KcvlDXgxpkQaQMOcVhMV5ZJCgXUjvw6I/ ZhvOcx7q0SJX8mPNCed3bQm92gPqVITujiUNKLjDfhOdaRLlqBx6gg0uZ 9jziXoFB6RPQjMbj1LjCKreltre0sahukxDQszOnDQClInt1UY50fc=;
X-MDAV-Processed: mail.consulintel.es, Mon, 20 Nov 2017 21:10:37 +0100
X-Spam-Processed: mail.consulintel.es, Mon, 20 Nov 2017 21:10:36 +0100
Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005632724.msg for <ipv6@ietf.org>; Mon, 20 Nov 2017 21:10:36 +0100
X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0)
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:171120:md50005632724::nHeYk3CP2sQkaKpa:000073Ch
X-Return-Path: prvs=1497b6414a=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Mon, 20 Nov 2017 21:10:32 +0100
Subject: Re: IPv6 only host NAT64 requirements?
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: 6man WG <ipv6@ietf.org>
Message-ID: <5DAEE862-0BD0-4DA6-AE7A-B4B6A2CAE617@consulintel.es>
Thread-Topic: IPv6 only host NAT64 requirements?
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>
In-Reply-To: <f673d6c7-570e-b2b8-e8aa-15d73ea8ba3f@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Reply-To: jordi.palet@consulintel.es
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/c5HakMQlEyeScAIDjE2NWOzxGHs>
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: Mon, 20 Nov 2017 20:10:42 -0000

It is clear to me that hotel rooms need to provide IPv6 + IPv4-as-a-service (for example using a CE or AP with CLAT).

The hotel network or its access can be IPv6-only and then the ISP provide the NAT64.

I’m sure someone will argue that this means perpetuating IPv4: Is not the case.

The case is being realistic about what an ISP or an hotel or any other organizations NEEDs to provide to their customers if they want to keep them.

If the hotels provide IPv6 + IPv4-as-a-service, the customer is happy and more and more traffic is moving from IPv4 to IPv6 in a natural way.

If some app developers don’t see it, or if some content providers or enterprises where the VPN is being connected, there will be a point where the IPv4 traffic is meaningless and they have the risk that at that point the IPv4-as-a-service is not offered anymore, not because the cost of the CLAT, but because the cost of the NAT64.

The only way we can motivate all them to move to IPv6 is to make sure that when, for example 75% of the Internet traffic is IPv6, we clearly announce that IPv4 is historical, has not maintenance, and will be dropped and unsupported and will not be able to be reachable. It is the ISPs work to decide if they want to keep providing NAT64 or not, and to tell their customers. At some point, more and more ISPs will drop that service. Wherever that point is at the 75% of IPv6 traffic or 95% or something in the middle is to be decided by each ISP, also maybe depending on their competitors, etc.

I recall a few years ago when a phone company in Spain still had a few customers with old “pulse disk phones”. They took the decision to cancel the contract to those customers if they don’t want to get the phone replaces with DTMF phones.

Same today is happening with customers with ADSL where there is GPON coverage. You accept to be replaced to GPON, or they cancel the contract, because it is more expensive to keep a few “old fashioned” customers that the profit they generate.

Regards,
Jordi
 

-----Mensaje original-----
De: ipv6 <ipv6-bounces@ietf.org> en nombre de Brian E Carpenter <brian.e.carpenter@gmail.com>
Organización: University of Auckland
Responder a: <brian.e.carpenter@gmail.com>
Fecha: lunes, 20 de noviembre de 2017, 20:37
Para: Ole Troan <otroan@employees.org>, Mohamed Boucadair <mohamed.boucadair@orange.com>
CC: 6man WG <ipv6@ietf.org>, Mark Andrews <marka@isc.org>
Asunto: Re: IPv6 only host NAT64 requirements?

    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.
    
        Brian
    
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.