Re: IPv6 only host NAT64 requirements?

Ole Troan <otroan@employees.org> Mon, 13 November 2017 15:36 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 9301A128B8D for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 07:36:16 -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 veienttM6Ud8 for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 07:36:10 -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 4BB55127843 for <ipv6@ietf.org>; Mon, 13 Nov 2017 07:36:09 -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 D20192D5038; Mon, 13 Nov 2017 15:36:08 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 1BD9E200BFF204; Mon, 13 Nov 2017 23:35:44 +0800 (+08)
From: Ole Troan <otroan@employees.org>
Message-Id: <D43E103C-27B8-48CF-B801-ACCF9B42533E@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_1EDC8158-6581-4A82-BD32-C94846927E2D"; 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, 13 Nov 2017 23:35:43 +0800
In-Reply-To: <m1eEGbJ-0000EhC@stereo.hq.phicoh.net>
Cc: 6man WG <ipv6@ietf.org>
To: Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com>
References: <m1eEGbJ-0000EhC@stereo.hq.phicoh.net>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/87wMaBg2uhsKYM-vQw85Z3t3sGg>
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, 13 Nov 2017 15:36:16 -0000

Philip,

> In your letter dated Mon, 13 Nov 2017 10:50:40 +0800 you wrote:
>> If this is the direction we want to go. Encourage IPv6 only host
>> deployments (as opposed to dual stack hosts), are these requirements
>> we'd like to add to the IPv6 node requirements document? Somewhere else
> 
> Personally I don't like how NAT64 requires an IPv6 stack to deal with all
> kinds of IPv4 issues. So for IPv6 node requirements, it should not go
> beyond the level of MAY.

Yes, that's certainly the bind we are in. Are we going to require all IPv6 only nodes to be able to communicate with IPv4? And what does that entail? Do you have examples of "all kinds of IPv4 issues"?

Apart from the requirement of NAT64 prefix discovery and IPv4 synthesising, is there anything you don't need to do anyway?
I can't quite see ICE/STUN going away, just because the end to end path is IPv6.

While I'm also concerned about the consequences of carrying IPv4 debt in all IPv6 implementations, the alternative seems to be that we are stuck with Dual stack forever (for some definition of forever). This would at least allow us to move to single stack IPv6. Which appears to me to be a step forward. And we're very close to that already, and there are millions of devices already implementing it.

Cheers,
Ole