Re: IPv6 only host NAT64 requirements?

Mark Andrews <marka@isc.org> Mon, 20 November 2017 11:12 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 A07F9127010 for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 03:12:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 56DD7bRmc_wv for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 03:12:22 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 28F98129540 for <ipv6@ietf.org>; Mon, 20 Nov 2017 03:12:22 -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 3F60C3B1F24; Mon, 20 Nov 2017 11:12:17 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 0B1D5160053; Mon, 20 Nov 2017 11:12:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id EFE31160072; Mon, 20 Nov 2017 11:12:15 +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 QKHIGgz-624Z; Mon, 20 Nov 2017 11:12:15 +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 0669D160053; Mon, 20 Nov 2017 11:12:14 +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: <1986EEC9-ED01-40D1-A1E6-3B7703A8ED34@employees.org>
Date: Mon, 20 Nov 2017 22:12:12 +1100
Cc: Mikael Abrahamsson <swmike@swm.pp.se>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D2702C6C-911E-49B3-A62A-953C47E1F023@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> <83B04565-4A62-47AE-90FA-13F9254C5A1C@isc.org> <1986EEC9-ED01-40D1-A1E6-3B7703A8ED34@employees.org>
To: Ole Troan <otroan@employees.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ZDU_uswO3-f_FvhqC2Cm6JqSpOs>
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 11:12:23 -0000

> On 20 Nov 2017, at 7:40 pm, Ole Troan <otroan@employees.org>; wrote:
> 
> Mark,
> 
>>>> 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.
> 
> From the perspective of the host and the application, "IPv4 as a service" is hardly progress.
> (Progress being defined as something moving us towards an IPv6 only network).
> 
> IPv4aaS offers dual stack to the hosts. Sure, it is typically carried over IPv6, and it allows the access network to use IPv6 transport. But from the perspective of delivering the service, it could as well have been ATM.

IPv4aaS delivers IPv6 connectivity to the customer net.  That is better than IPv4 only.  It moves the global percentage of IPv6 traffic upwards.  It allows customers to offer services on well known ports.  We need to reach 90 something percent IPv6 traffic before most people will be willing to turn off IPv4.

I’d prefer mechanisms that can be out sourced so ISPs can off the deliver of IPv4 as a service to someone else in the future.  The costs then go back onto only those that need to reach legacy only services.

> The other coin of IPv4aaS is that it is a mechanism that allows IPv4 to scale indefinitely.

There are limits to how many customers can share a IP address especially if you are allowing incoming connections by mapping ports to customers.   Even stateless mapping, eyeball only, imposes costs.

> The tragicomedy of where we are at the moment is that an ISP would offer better service to the end-user network by delivering IPv4 only service over it's IPv4aaS infrastructure... we need to find a way to move off dual-stack.

Moving off dual stack will come.  It just hard to force it.  Encouraging every small step in the right direction is important.

I’m sure there are a couple of Summer of Code projects in going through the existing applications that make network connections and 1) adding IPv6 support if it doesn’t exist and 2) adding happy eyeball style connection creation where the application is {S}TCP based.  Contribute those changes back to the projects.

> Ole

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