Re: IPv6 only host NAT64 requirements?

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Tue, 21 November 2017 08:39 UTC

Return-Path: <prvs=14985c1375=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 5FE95129426 for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2017 00:39:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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] 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 3rJ6xHZKg_qP for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2017 00:39:18 -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 8471212773A for <ipv6@ietf.org>; Tue, 21 Nov 2017 00:39:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1511253555; x=1511858355; 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=q9oDxx6G08A5Kadg6EAfdAkef YepA8XawVgFC8X1r7o=; b=euQMY145AzLBtpKwEZS4ZfE/6dQXuxLrhunEKcTpf FNEGPne3triud/PDOKe3wmdgBFeHBUtdtIlKv9eauAQyug62ItymKZ/52bUyQ7nx CE/eimmIhGp6HesgbQPacARvb/92IbQ7CGauILd3G9j4vYFs9fSuuwVRoBOUZtWS oc=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=EmpR1ALVJEc938Zk0Rl3h/Ku2U2A/pdEKOIihMGkuUketFI8dTAGoRa++sfr dZ2RnGFww1dBmcc5e3ctZuqs71EaR4e27emC0EWIZa0m9+/3dUXfJASFK BzUfowXvfS/qwAM8rI2VfIT6ISVtZlycnrlubF1EKa0hDgnAA7seDQ=;
X-MDAV-Processed: mail.consulintel.es, Tue, 21 Nov 2017 09:39:15 +0100
X-Spam-Processed: mail.consulintel.es, Tue, 21 Nov 2017 09:39:14 +0100
Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005633531.msg for <ipv6@ietf.org>; Tue, 21 Nov 2017 09:39:13 +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:171121:md50005633531::7bGHY6k0xZXnjyGg:00000obJ
X-Return-Path: prvs=14985c1375=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: Tue, 21 Nov 2017 09:39:09 +0100
Subject: Re: IPv6 only host NAT64 requirements?
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: 6man WG <ipv6@ietf.org>
Message-ID: <F6592E18-8D2A-4B4D-903C-C4D407D12978@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> <D05E1703-9357-4BB2-B535-AEC23924281A@consulintel.es> <81A3232BEF82944C8F23DB1CFE276F0F494BDF1B@BPXM24GP.gisp.nec.co.jp>
In-Reply-To: <81A3232BEF82944C8F23DB1CFE276F0F494BDF1B@BPXM24GP.gisp.nec.co.jp>
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/FAH9Fid2bJGf11AXHOG1BYh0TyE>
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 08:39:20 -0000

Hi Masanobu,

Yeah, knew that, but didn’t looked at that web page before, and it looks to me very interesting action for IXs ;-)

There is at least a company that I know, already offering this as a commercial service.

Regards,
Jordi
 

-----Mensaje original-----
De: Masanobu Kawashima <kawashimam@vx.jp.nec.com>
Responder a: <kawashimam@vx.jp.nec.com>
Fecha: martes, 21 de noviembre de 2017, 5:11
Para: "jordi.palet@consulintel.es" <jordi.palet@consulintel.es>, 6man WG <ipv6@ietf.org>
Asunto: RE: IPv6 only host NAT64 requirements?

    
    Hi Jordi, 
    
    > 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. 
    
    In Japan, JPIX(Japan Internet Exchange) is providing 464XLAT trial service 
    to ISPs. 
    https://www.jpix.ad.jp/en/technical_exchange.php 
    
    PLAT(NAT64 service) is providing from JPIX, then ISPs are using CLAT CPE. 
    We might need this kind of service near future. 
    Just FYI. :-) 
    
    Regards, 
    Masanobu 
    
    ==================================== 
     NEC Platforms, Ltd.                 
     Access-Device Division              
     KAWASHIMA Masanobu                  
     kawashimam@vx.jp.nec.com            
     https://www.necplatforms.co.jp/en/  
    ==================================== 
    
    
    > -----Original Message-----
    > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of JORDI PALET MARTINEZ
    > Sent: Tuesday, November 21, 2017 5:13 AM
    > To: 6man WG <ipv6@ietf.org>
    > Subject: Re: IPv6 only host NAT64 requirements?
    > 
    > 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.
    > 
    > 
    > 
    > --------------------------------------------------------------------
    > 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.