Re: IPv6 only host NAT64 requirements?

Ole Troan <otroan@employees.org> Tue, 14 November 2017 00:38 UTC

Return-Path: <otroan@employees.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 14E31126CD6 for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 16:38:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2Cht-oZMF_M for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 16:38:05 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E6D1200CF for <ipv6@ietf.org>; Mon, 13 Nov 2017 16:38:05 -0800 (PST)
Received: from h.hanazo.no (dhcp-9240.meeting.ietf.org [31.133.146.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 2BC572D5122; Tue, 14 Nov 2017 00:38:05 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 3099C200C08E7C; Tue, 14 Nov 2017 08:37:41 +0800 (+08)
From: Ole Troan <otroan@employees.org>
Message-Id: <E6BCB92F-615A-4692-8AF2-D993D5B9AF7F@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_F1AE219E-F75A-4B7E-B41D-8335A79ADCA4"; 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: Tue, 14 Nov 2017 08:37:40 +0800
In-Reply-To: <909eb642-b2a0-2fb5-8f41-297e013ae307@gmail.com>
Cc: Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com>, 6man WG <ipv6@ietf.org>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <m1eEGbJ-0000EhC@stereo.hq.phicoh.net> <D43E103C-27B8-48CF-B801-ACCF9B42533E@employees.org> <m1eEHPS-0000FyC@stereo.hq.phicoh.net> <909eb642-b2a0-2fb5-8f41-297e013ae307@gmail.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/n5HvaZ_pPlA0Uo0pp01wxFnNZjE>
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: Tue, 14 Nov 2017 00:38:07 -0000

Brian,

> ...
>> But for host software there is a lot more incentive to support dual stack then
>> to do the extra step for NAT64.
>> 
>> The big problem I see for NAT64 is that for old IPv4-only applications you
>> have to make two fundamental changes to the application. The first to
>> make sure that the application handles IPv6 in every possible way. And a
>> second pass that makes sure that every place where an IPv4 address literal
>> is handled, works with NAT64.
>> 
>> For an application writer it is better to try to avoid doing the second pass.
> 
> I think there is a missing document, and it may well belong in v6ops not
> 6man: "IPv4 Applications on an IPv6-only Host".

IPv4 applications do not run on an IPv6 only host, so that's a short document.

> Your text above is probably a good summary of what the document needs
> to cover. (I also suspect that if this document existed, we wouldn't need
> Jordi's draft attempting to define "IPv6-only".)

Please take that to a different thread. This thread is about a IPv6 only, single stack host connecting to an IPv6 only network.
With a backdoor to the IPv4 Internet for legacy destinations.


Ole