Re: IPv6 only host NAT64 requirements?

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Mon, 20 November 2017 20:12 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 40FDD12EA93 for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 12:12:59 -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 2UdzJua6YqXg for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 12:12:56 -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 33ED512EAA5 for <ipv6@ietf.org>; Mon, 20 Nov 2017 12:12:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1511208774; x=1511813574; 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=v5BLhJOPcaiXRQrh6c6rib+Qd wntto79wM+K6vP+Eqw=; b=IVIBLcrJcQDVRlryilTFtXWUbunz/OOyNveDBz5wq XtqDqOIwXnfkAXSZtOwR+cYpr0A2Pt1UnDKM+wKbW3yLVCkuM0CZTLHkvaXEgK5h kO48V/q2a10z6VeCCIiggN4ZyZV2pTZnJab22KTi7TEYP93VVJ1do1Y7fXQFp6Dq PQ=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=sqosDLClCELZvdJw5nfLohDTpRibJKkbxZxSccx+P82EDatsE3hOyPJKqrgu Lq4Gu+t78DqISoocY6vAeUae3XNQVeyT3/0WTrXYh5rSYsrB7Mw5UzSYB RtMDzoJPA3l/F25YB225EqVLj1mKltlVZhKykcTbRxDlf5d9sxtceg=;
X-MDAV-Processed: mail.consulintel.es, Mon, 20 Nov 2017 21:12:54 +0100
X-Spam-Processed: mail.consulintel.es, Mon, 20 Nov 2017 21:12:52 +0100
Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005632730.msg for <ipv6@ietf.org>; Mon, 20 Nov 2017 21:12:52 +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:md50005632730::L29ErrD+WiPDTR5X:0000DuyN
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:12:50 +0100
Subject: Re: IPv6 only host NAT64 requirements?
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: 6man WG <ipv6@ietf.org>
Message-ID: <D05E1703-9357-4BB2-B535-AEC23924281A@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> <5DAEE862-0BD0-4DA6-AE7A-B4B6A2CAE617@consulintel.es>
In-Reply-To: <5DAEE862-0BD0-4DA6-AE7A-B4B6A2CAE617@consulintel.es>
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/W0vTONZybr2GWHlu09-CuMYXqro>
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:12:59 -0000

And by the way …

At some point the NAT64 service, instead of being provided by the ISP it will make sense to be provided by third party companies, even if there is some extra delay to reach a remote NAT64, etc., and even if there is an extra cost for that customer that still requires it.

Regards,
Jordi
 

-----Mensaje original-----
De: ipv6 <ipv6-bounces@ietf.org>; en nombre de JORDI PALET MARTINEZ <jordi.palet@consulintel.es>;
Responder a: <jordi.palet@consulintel.es>;
Fecha: lunes, 20 de noviembre de 2017, 21:11
Para: 6man WG <ipv6@ietf.org>;
Asunto: Re: IPv6 only host NAT64 requirements?

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



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