Re: IPv6 only host NAT64 requirements?

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 20 November 2017 22:39 UTC

Return-Path: <brian.e.carpenter@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 A914612EAF4 for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 14:39:31 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 izkzY7g1sI1A for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 14:39:19 -0800 (PST)
Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC5512EAFA for <ipv6@ietf.org>; Mon, 20 Nov 2017 14:39:04 -0800 (PST)
Received: by mail-pf0-x22d.google.com with SMTP id a84so8365665pfl.0 for <ipv6@ietf.org>; Mon, 20 Nov 2017 14:39:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yjvwXH3pY3xxO12w92QTRh+/QpBmw6g/9Ju/Bxivf7E=; b=Kt9o7D+LzZ+qPuWTLxid/wtQTEHH7Zy2vC4T1vwyOohvr7M1+VEJKrlDnXlp/anyQ3 AlwbO/5UIsTNKabb1Dyb4r0c8Vse6k2dyakbIk5MKTVHyLFLXMDh6SDF3kD42GZthEyZ Abg6UBbIxn52lPU9s0TNtygtiO9YYquCoeNmDt1VaLorrgWxuwRDRk3A3HH8FcC2GtGD a2bHN8cxyYceajMQg+LQgTfrplJKeR0MDb8a8GnhgiNyzxx6sYz8F9hRkEVsSP9/DuPA Nxdf+Si+zg+GcNufLRxMkP8UdHAZ0u6NiVbdKhNM/2SWeMkgR8FIB2Z0eo1pXXp8DzUF lTig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=yjvwXH3pY3xxO12w92QTRh+/QpBmw6g/9Ju/Bxivf7E=; b=iG2WcJHA9S0JSoLmUgeInk1uKUwYEdxCN7cw8iozPSaKkuP2Vu8gOlezIoWNvI3XXa U3ZG9euXMOD9iSVGoxX7wGJhVWQZ9CdqaJi+xxhzv6wqqQ17kRaERc2qYeVGH44R908F eh7jLg+4TvyTPrJJ/dreSlRzHQV7tefODjfcmCXYNn+T8m4xZG3udlH4pD8scgoA4xqK Z4VQvuVFuOTHJBTCXWBXOl38DU1CVDXGGBBlYSyPSss7BAVDjdDg7XsAm6jRhrQsVydb WhJq9NGTGawPmY5A/NeYbWZ7oDNoEAFltwzNrJ7hnFO7lma2YHlUgtpufFFkoiqmCh9d hhSw==
X-Gm-Message-State: AJaThX4Fa1lcjzrFBXiYIm7YZEF/LPdmRFQgp2C+YnsdhkpXijPp3Wy3 58nvGzaXMBTHEICRU9dizFLAyA==
X-Google-Smtp-Source: AGs4zMY06eHN/4g8/UUs4qOICuyPFPq8m4V1igxTnUjctUTlrxm5i1qGfkGfoZPAdm1suK5PdgJajQ==
X-Received: by 10.84.248.65 with SMTP id e1mr14955946pln.284.1511217543219; Mon, 20 Nov 2017 14:39:03 -0800 (PST)
Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id e8sm21409475pfk.6.2017.11.20.14.39.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Nov 2017 14:39:01 -0800 (PST)
Subject: Re: IPv6 only host NAT64 requirements?
To: jordi.palet@consulintel.es, 6man WG <ipv6@ietf.org>
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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <1df96ff3-3d42-19d2-aa63-5404adffcd3b@gmail.com>
Date: Tue, 21 Nov 2017 11:38:59 +1300
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: <5DAEE862-0BD0-4DA6-AE7A-B4B6A2CAE617@consulintel.es>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/iAAfcgPfNPtho_pEW_KFPy9rims>
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 22:39:32 -0000

On 21/11/2017 09:10, JORDI PALET MARTINEZ wrote:
> 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.

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

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

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