Re: IPv6 only host NAT64 requirements?

Ole Troan <otroan@employees.org> Tue, 14 November 2017 00:32 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 BAE411243F6 for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 16:32:48 -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 X1yKDlhuD2QB for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 16:32:47 -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 1496F128954 for <ipv6@ietf.org>; Mon, 13 Nov 2017 16:32:47 -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 68DAB2D4F99; Tue, 14 Nov 2017 00:32:46 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id BF1D7200C08C5A; Tue, 14 Nov 2017 08:32:21 +0800 (+08)
From: Ole Troan <otroan@employees.org>
Message-Id: <A988838B-5738-4FF4-919A-4B7E7ED8EAAC@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_9989E0A9-117E-44C8-9F8A-D2C9992BA70C"; 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:32:20 +0800
In-Reply-To: <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>
Cc: Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com>, 6man WG <ipv6@ietf.org>
To: Mark Andrews <marka@isc.org>
References: <m1eEGbJ-0000EhC@stereo.hq.phicoh.net> <D43E103C-27B8-48CF-B801-ACCF9B42533E@employees.org> <m1eEHPS-0000FyC@stereo.hq.phicoh.net> <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org> <m1eEIGX-0000FjC@stereo.hq.phicoh.net> <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Te9fpQ1NfpVA1GZDvaRwSEi6F6s>
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:32:49 -0000

Mark,

> Is there any reason to run DNS64 at all these days?  ipv4only.arpa can be a preconfigured
> zone which allows CLAT to get its mapping.  All the phones have CLAT support.  Can we just
> make DNS64 historic and let the phones run all IPv4 connections through CLAT rather than
> having to stuff up DNSSEC and have IPv6 connections terminate in IPv4 servers without
> the application knowing?

For the last point, that's no different than today's IP4 network where addresses change underneath you.

The scenario this thread is about, albeit the efforts in derailing it, is about an IPv6 only host (and application), connecting to something like the Internet. The premise of the experiment was "single stack".

There is therefore no CLAT in this scenario.

If you go back and look at my proposed host requirements, you'll see I added a requirement that hosts must be able to do the DNS64 function themselves, exactly for the reason of solving the DNSSEC problem with NAT64.
Now people here tell me that local validation of DNSSEC isn't done for IP4 either and in practice it's not deployable. I'd hope that's untrue, but regardless you don't appear to be in a worse position with DNS64 than you are without. Either you trust a distance recursive resolver to do the validation for you, or you do validation yourself (and also the synthesizing of IP6 addresses).

Cheers,
Ole