Re: IPv6 only host NAT64 requirements?

Ole Troan <> Mon, 20 November 2017 08:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C9FD12941C for <>; Mon, 20 Nov 2017 00:40:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VOqTAEpnRx1v for <>; Mon, 20 Nov 2017 00:40:54 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 428401294B8 for <>; Mon, 20 Nov 2017 00:40:54 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 915332D5038; Mon, 20 Nov 2017 08:40:53 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id 2CB2C200C8EBCB; Mon, 20 Nov 2017 09:40:51 +0100 (CET)
From: Ole Troan <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_C39C4FD5-7337-421E-8FC3-205BC014667B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Mon, 20 Nov 2017 09:40:50 +0100
In-Reply-To: <>
Cc: Mikael Abrahamsson <>, 6man WG <>
To: Mark Andrews <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Nov 2017 08:40:56 -0000


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

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

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.