Re: IPv6 only host NAT64 requirements?

Ole Troan <> Mon, 20 November 2017 13:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A0411298BA for <>; Mon, 20 Nov 2017 05:37:02 -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 SAfsrtlZmFJB for <>; Mon, 20 Nov 2017 05:37:00 -0800 (PST)
Received: from ( [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 52B101267BB for <>; Mon, 20 Nov 2017 05:37:00 -0800 (PST)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id AA9A12D5038; Mon, 20 Nov 2017 13:36:59 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id 4B957200CAD856; Mon, 20 Nov 2017 14:36:54 +0100 (CET)
From: Ole Troan <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_162733EB-6FCA-4157-9AC3-509305E430E3"; 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 14:36:53 +0100
In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Cc: Jen Linkova <>, 6man WG <>, Mark Andrews <>
To: Mohamed Boucadair <>
References: <> <> <> <> <> <> <> <> <> <> <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
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 13:37:02 -0000


>>>>> [Med] As you are mentioning "IETF" explicitly, NAT64 may not be the
>>>> appropriate "IPv4 service continuity" solution here.
>>>> Why not?
>>> [Med] Because dual-stack can do the job without any extra effort.
>> That's not a valid answer, when the question to be explored is "Is it
>> possible to run IPv6 only hosts?".
> [Med] You should admit that there are questions that don't make sense if not contextualized.

Freely admitted. Although I thought that was made clear both earlier in thread and by subject. ;)

>> The arguments against dual stack:
>> - expensive to operate
>> - little progress towards the end goal of IPv6 only
> [Med] These are generic statements, Ole. We are talking about the IETF case.
> * The IETF has no control on the hosts that connect to the IETF network,
> * IETF attendees who are using corporate devices, have no control on these hosts
> So, how forcing devices to use "IPv6+nat64" will help here?

Eat own dogfood. Many IETF people are developers or work for companies having applications not working.
As I said there were a minimum of applications that didn't work. Corporate VPNs largely did. Jen has the final numbers.


>>> Advanced features have been also specified, e.g.,
>>> - if you want to allow for incoming connections: e.g., access a video
>> server
>>> - if you want to avoid overloading NAT64 with all sorts of ALGs
>>> - if you want to avoid draining the battery of your mobile because of
>> the keepalive messages
>> Yep, but I think the cat is largely out of the bag here, and an
>> application must work in the "smallest common denominator" network.
> [Med] More concretely?

- ALGs do more harm than gain. Applications have been forced to deal with NAT traversal. As in ICE/STUN/TURN.
  Applications must work with any NAT also those without ALGs. ALGs are dead.
- For the applications that need the keepalive wouldn't they send traffic anyway, so that it wouldn't be an additional battery drain.
  Example of application that doesn't?
- Incoming connections? Didn't think we did that on the Internet anymore? :-(
  That's static configuration in one case, and for the other symmetric hole punching (as in the ICE/STUN case).

Would PCP have helped, yes, possibly, but given that applications must work without it anyway...