Re: IPv6 only host NAT64 requirements?

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Tue, 21 November 2017 08:36 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 E28A8129401 for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2017 00:36:34 -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 Y1ebawly5OJ1 for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2017 00:36:32 -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 D046812773A for <ipv6@ietf.org>; Tue, 21 Nov 2017 00:36:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1511253390; x=1511858190; 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=obFYJpPR4lz/0N8+GrJB2Hf6i a0O8GF4vgreSJOrn4E=; b=l916m63heK5g2H31blOmEsY0OTxlCnWAoznSUyoD3 fdja+ullKFl9U7D0oEszNrr5chTurmMXlbmMLkylTg3QdSLknLWZv78bM2X0LpwJ lVRh7oj6P2IMgl3M2W9VCkzpI2u3IxM1oxLAgrDWW9+084TJCPC+BQDgKXtLOD+3 M4=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=L0VF97o/O9AaDYYg4g9LUx4KvL3M0z0939tfobGgHDqQeQ6TRO70WGq0G1HE aWI5P9WSiU4tLU7yybwjDOPhRiVoutFRP8Zi/McJkGos9YpUn++Fd72nL JZbgyWkV9RO1oCi7L2n/5cTsvkAben/iCOsl8jr+hz6AB4kudngIXM=;
X-MDAV-Processed: mail.consulintel.es, Tue, 21 Nov 2017 09:36:29 +0100
X-Spam-Processed: mail.consulintel.es, Tue, 21 Nov 2017 09:36:28 +0100
Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005633528.msg for <ipv6@ietf.org>; Tue, 21 Nov 2017 09:36:28 +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:md50005633528::QikN8+2nKgxchbOA:00001kCv
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:36:23 +0100
Subject: Re: IPv6 only host NAT64 requirements?
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: 6man WG <ipv6@ietf.org>
Message-ID: <1AFC5341-820B-4ECB-B565-4C1160A3F691@consulintel.es>
Thread-Topic: IPv6 only host NAT64 requirements?
References: <m1eEGbJ-0000EhC@stereo.hq.phicoh.net> <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> <1df96ff3-3d42-19d2-aa63-5404adffcd3b@gmail.com>
In-Reply-To: <1df96ff3-3d42-19d2-aa63-5404adffcd3b@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/pqzOGLIXY5J5yR32K7QAo6e4-HA>
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:36:35 -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.
    
    What users need is that the WiFi (or, rarely, the RJ45 connector) supports
    native IPv4 and native IPv6. If  the SP wants IPv6-only on the hotel's
    access link, then the hotel's CE must use one of the known solutions.
    I don't care if it's CLAT or dslite or homebrew. It must not place unusual
    requirements on the user's device, since by definition in such a scenario
    the user device and its applications are random and only a lowest common
    denominator can be assumed.

[Jordi] Just to be clear on this: When I say the hotel CE or AP with CLAT, I mean the same as you – users get in the RJ45/WiFi dual stack (as per today private IPv4 plus global IPv6). The point is that user device doesn’t require anything “new” or “extra”.
    
    > I’m sure someone will argue that this means perpetuating IPv4: Is not the case.
    
    The religious aspect is not important; the market doesn't care about
    religion. IPv4 will die when it's ready to die, and not before.
    
    > 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 I believe that is the *only* way to make all customers happy
    while deploying IPv6. Also, it can only be motivated if accessing
    Facebook, Google etc. is faster or cheaper using IPv6, providing
    an incentive for change.

[Jordi] The fact that some content providers are still not on IPv6, means those contents/services will be slightly slower (NAT64, CGN, etc.), and I guess more and more transit providers will have less incentive to keep the “quality” of the IPv4 path at the same level as the IPv6 one if there is less and less usage. May be some transit providers or ISPs will start charging some extra for IPv4 because the extra cost of maintaining it for a number of users which is going down … I see that already happening in the access for xDSL links vs GPON.
    
    > 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.
    
    Whatever the reason, ISPs won't do this until it affects a
    negligible number of users, given the cost of help desk
    calls compared to everything else.
    
    > 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. 
    
    I don't know who you mean by "we". Certainly the IETF has no
    power to make such statements.

[Jordi] sunset4 is IETF. I think we should go that way as soon as possible, because after we have RFCs, it takes at least a couple of years to start flooding into the market. So, we disagree here, we can make IPv4 “somehow” historic in order to do the last push from the technical perspective. Each vendor and ISP will decide, but for example, if there is an RFC, many governments, for public procurement, will consider it, and this is, in turn a pushing factor for vendors and ISPs in that country. From my own experience being contracted by several governments in order to mandate IPv6 support in laws for public procurement, I can tell you that in a matter of months, many other countries took similar decisions looking for the earlier ones, so it becomes a snowball, and at the end it affects also industry and residential users, it just takes time. I’m sure ISOC, ICANN and other organizations will be able to support that “public call” once do our work in sunset4.

    Regards,
       Brian
    
    > 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.