Re: IPv6 only host NAT64 requirements?

Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com> Mon, 13 November 2017 15:35 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 B8E0B129454 for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 07:35:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 QCCXaHuA8ZT7 for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 07:35:42 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 257E4129449 for <ipv6@ietf.org>; Mon, 13 Nov 2017 07:35:42 -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 m1eEGlw-0000FsC; Mon, 13 Nov 2017 16:35:40 +0100
Message-Id: <m1eEGlw-0000FsC@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: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org> <CAD6AjGRhn80LUJrut4ebDKPfFkdu3ySN8fjH_JvCjSNA-_tfYw@mail.gmail.com>
In-reply-to: Your message of "Mon, 13 Nov 2017 03:32:22 +0000 ." <CAD6AjGRhn80LUJrut4ebDKPfFkdu3ySN8fjH_JvCjSNA-_tfYw@mail.gmail.com>
Date: Mon, 13 Nov 2017 16:35:34 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/W4RkwsKs8g6Z8PM_C0lQsuvjZeY>
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:35:44 -0000

>I am not optimistic on the demand / need / value of dnssec in any scenario
>....let alone an ipv6-only host validating an ipv4-only dns name. If the
>folks operating this service cared, they could operate the server with
>signed v6 names.  It is more reasonable in todays internet to asked the
>server (lets assume most signed name scenarios are servers) to be setup
>right (with v6). There is not a compelling reason why having v6 is
>unattainable today for named nodes.

DNSSEC is something that works today. Opinions are divided on what security
it offers. Some people like it way more than the traditional CA system. 
Other people believe that we should continue making random changes to the CA
system in the hope that one day it will be secure.

The problem for people who do local DNSSEC validation is that if neither the
NAT64/DNS64 operator nor the operator of the target server cares about 
DNSSEC/IPv6 then it just breaks.

If all server operators cared, then there would be no need for NAT64/DNS64
so the problem would not exist in the first place.

If the NAT64/DNS64 operator cared, then they would offer be dual stack IPv4
or a tunneling based transition technology that doesn't break DNSSEC.

I guess the good news is that at least one group of people writing a local
DNSSEC validating resolver (getdns) are aware of this issue and are adding
code to handle this situation.