Re: IPv6 only host NAT64 requirements?

Ole Troan <> Mon, 20 November 2017 11:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E89CE127010 for <>; Mon, 20 Nov 2017 03:32:33 -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 0B74sIHlZo00 for <>; Mon, 20 Nov 2017 03:32:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5588C1200FC for <>; Mon, 20 Nov 2017 03:32:32 -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 B839D2D508B; Mon, 20 Nov 2017 11:32:30 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id 0E75C200C9D742; Mon, 20 Nov 2017 12:32:29 +0100 (CET)
From: Ole Troan <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_6D075E5C-4B11-45DF-BA9B-C58FE33D271B"; 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 12:32:27 +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 11:32:34 -0000


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

But for _me_ on my local network, with my applications... I haven't found anything better with it...

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

Not really. A+P gives you 48 bit addressing. ;-)
And especially not with upcoming new transport layers.
With traditional NAT, you burn one outside NAT port per multiple connections to same external destination:port.
We should ask CAIDA for an analysis.
Continuing to scale IPv4 is possible. It's not going to be free... far from it, but that seems to be where we're backwards walking ourselves into.

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

But I think we should encourage it, we should make it as edible as possible, and we should try to push the burden of interoperability over to the laggards.

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

As I said we didn't find many applications during the hackathon.
The main culprits in my home is bath scale, light bulbs, weather stations.
The other culprits are the plethora of open source projects around VM and container networking, those are largely IPv4 NAT based.