Re: IPv6 only host NAT64 requirements?

Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com> Tue, 14 November 2017 10:44 UTC

Return-Path: <pch-bCE2691D2@u-1.phicoh.com>
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 E8A3A128BB6 for <ipv6@ietfa.amsl.com>; Tue, 14 Nov 2017 02:44:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 u3SbBpvHwKZv for <ipv6@ietfa.amsl.com>; Tue, 14 Nov 2017 02:44:39 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9704127775 for <ipv6@ietf.org>; Tue, 14 Nov 2017 02:44:38 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1eEYhl-0000FyC; Tue, 14 Nov 2017 11:44:33 +0100
Message-Id: <m1eEYhl-0000FyC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: Re: IPv6 only host NAT64 requirements?
From: Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com>
Sender: pch-bCE2691D2@u-1.phicoh.com
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> <A988838B-5738-4FF4-919A-4B7E7ED8EAAC@employees.org>
In-reply-to: Your message of "Tue, 14 Nov 2017 08:32:20 +0800 ." <A988838B-5738-4FF4-919A-4B7E7ED8EAAC@employees.org>
Date: Tue, 14 Nov 2017 11:44:32 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/2GAmFb9bkfta-s5wvH0G6b3mA84>
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 10:44:42 -0000

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

For quite a while now, I'm running two applications with local DNSSEC
validation on my laptop.

One is the cz.nic dnssec validator plugin for web browsers. The other is my
own code that uses getdns in ssh to validate SSHFP records.

In both cases, it just works. My conclusion is that wherever I take my laptop,
getdns can do local DNSSEC validation. DNSSEC works. Of course there are issues.
The fragmentation problems Geoff is seeing are real. But in practice it works.

One of the problems with DNSSEC and NAT64 is one way or another you have
to deal with a AAAA response that is not signed.

Without local synthesizing, local DNSSEC validation will fail. With local
synthesizing the local validator has to tell the application 'trust me, I
know what I'm doing'. Even if that's not actually true.