Re: IPv6 only host NAT64 requirements?

Mark Andrews <marka@isc.org> Sun, 19 November 2017 23:17 UTC

Return-Path: <marka@isc.org>
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 EDCDA1200B9 for <ipv6@ietfa.amsl.com>; Sun, 19 Nov 2017 15:17:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 abl3VJeBAlS4 for <ipv6@ietfa.amsl.com>; Sun, 19 Nov 2017 15:17:21 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62EE612009C for <ipv6@ietf.org>; Sun, 19 Nov 2017 15:17:21 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 9B92E3B6593; Sun, 19 Nov 2017 23:17:17 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 893B216003E; Sun, 19 Nov 2017 23:17:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 79CBD16006E; Sun, 19 Nov 2017 23:17:17 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gbJfRL3DRRft; Sun, 19 Nov 2017 23:17:17 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 9ED9E16003E; Sun, 19 Nov 2017 23:17:16 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: IPv6 only host NAT64 requirements?
From: Mark Andrews <marka@isc.org>
In-Reply-To: <alpine.DEB.2.20.1711190939290.32099@uplift.swm.pp.se>
Date: Mon, 20 Nov 2017 10:17:14 +1100
Cc: Ole Troan <otroan@employees.org>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <83B04565-4A62-47AE-90FA-13F9254C5A1C@isc.org>
References: <m1eEGbJ-0000EhC@stereo.hq.phicoh.net> <D43E103C-27B8-48CF-B801-ACCF9B42533E@employees.org> <m1eEHPS-0000FyC@stereo.hq.phicoh.net> <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org> <m1eEIGX-0000FjC@stereo.hq.phicoh.net> <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org> <CAKD1Yr1aFwF_qZVp5HbRbKzcOGqn==MRe_ewaA8Qc8t3+CVu_Q@mail.gmail.com> <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org> <D42D8D7A-6D19-4862-9BB3-4913058A83B6@employees.org> <CAFU7BARCLq9eznccEtkdnKPAtKNT7Mf1bW0uZByPvxtiSrv6EQ@mail.gmail.com> <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <CAFU7BARaJHKOyrD1KAeorbYQwgsmxBLk1QELH+wZ4=HDCP1q-w@mail.gmail.com> <8470b00f-ecc5-0a63-fd8f-a4e2f65a005d@gmail.com> <CFDD8D9E-0726-46C1-9CC7-5C88DD111E9D@employees.org> <alpine.DEB.2.20.1711190939290.32099@uplift.swm.pp.se>
To: Mikael Abrahamsson <swmike@swm.pp.se>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/POlVCrn6nBSWIf6lYxq-sP7t960>
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: Sun, 19 Nov 2017 23:17:23 -0000

> On 19 Nov 2017, at 8:45 pm, Mikael Abrahamsson <swmike@swm.pp.se>; wrote:
> 
> On Sun, 19 Nov 2017, Ole Troan wrote:
> 
>> The challenge we have in front of us is to make IPv6 only work.
> 
> When I speak to vendors about this, I get different answers. Some are saying "nobody will deploy IPv6 only, so why should I make changes in my desktop OS to support it for legacy applications?”

Well as this stage you can say that there are ISP that are deploying IPv6-only on
the access network with DS-Lite to provide IPv4 as a service.  If you want your
host to be able to connect directly to such ISPs you need to add support to detect
that DS-Lite is in use (a IPv6 DHCP option) and bring up a IPv4 in IPv6 tunnel to
the ISPs B4 router.

Repeat this for other transition technologies that you are aware is in use.

> And I imagine any access provider will say "I can't deploy IPv6 only, because it'll break a lot of applications that people are using on desktop OSes".
> 
> So this is classic catch 22.

You stop talk ipv6-only and start talking ipv6-only access + ipv4 as a service.

It’s only a “catch 22” because people fail to look at the options available.  ISPs
are going ipv6-only access + ipv4 as a service because it is easier to manage than
dual stack access + 44CGN.   Many ISPs deliver CPE routers that support DS-Lite
so the customer still see IPv4 + IPv6.

The question to host vendors is “do you want your machines to be able to connect
directly to ISP’s that have ipv6-only access networks or not?”  Ipv6-only access
networks are a reality.

> This was fixed on Android by throwing up hands and giving up on IPv6 only, and just installing CLAT on it to make sure most legacy applications just work.
> 
> On iOS it was fixed by doing bump-in-the-API plus mandating Apps work properly, and then waiting, and weeding out apps that didn't work because some mobile operators said "we're going to deploy this on a per-device type basis" after testing that these workarounds were successful.
> 
> MacOS is in-between, because applications that use the Apple APIs get bump-in-the-API help, but the ones that use the socket API doesn't. So here it's a mix of both worlds.
> 
> Windows has none of this. Linux also has none of this out of the box on any flavour of Linux I am aware of. This means lots of applications do not work.
> 
> Long tail of applications, is long.
> 
> Believing that all apps will get fixed on Windows and Linux (and MacOS) is for me a veeeeery long game to play. Also it's a nice idea to start opening tickets and trying to get them fixed, but again. Long tail is long.
> 
> So only practical way forward here I can see that would yield rewards in the next few years is for OSes to implement bump-in-the-API even for legacy socket API using applications, that would automatically turn on NAT64 traversal for legacy IPv4 applications.
> 
> -- 
> Mikael Abrahamsson    email: swmike@swm.pp.se
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org