Re: IPv6 only host NAT64 requirements?

Mikael Abrahamsson <swmike@swm.pp.se> Sun, 19 November 2017 09:45 UTC

Return-Path: <swmike@swm.pp.se>
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 D6AE6120724 for <ipv6@ietfa.amsl.com>; Sun, 19 Nov 2017 01:45:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 cYTJ_BkfuiaZ for <ipv6@ietfa.amsl.com>; Sun, 19 Nov 2017 01:45:31 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 ABF281200C1 for <ipv6@ietf.org>; Sun, 19 Nov 2017 01:45:31 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id A5229AF; Sun, 19 Nov 2017 10:45:27 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1511084727; bh=c+Yoh9Y0ff19BPvgK6odM0nsFB1sZ00EWZ8ADKOE0X0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=WCSfxsGupRbwIlSmDCznhT6PxsrNk9sd5NxgrJlsHJfdPAMI43V1l8L8tTeN7D8j9 JK+6KCfAO5bl2sf7DMBdJCrL+eNj/TkWlbjJpBwGh0tfe6rwLbOsop64Jhkr23BkDS ViVN6xvsLb/dZpz7KbB/FpU/fg9W2ko0TSCBtlVQ=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8D51B9F; Sun, 19 Nov 2017 10:45:27 +0100 (CET)
Date: Sun, 19 Nov 2017 10:45:27 +0100 (CET)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Ole Troan <otroan@employees.org>
cc: 6man WG <ipv6@ietf.org>
Subject: Re: IPv6 only host NAT64 requirements?
In-Reply-To: <CFDD8D9E-0726-46C1-9CC7-5C88DD111E9D@employees.org>
Message-ID: <alpine.DEB.2.20.1711190939290.32099@uplift.swm.pp.se>
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>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/hv-djxws8SIkRygkvQHma0tzkmI>
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 09:45:34 -0000

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

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.

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