Re: [v6ops] Benjamin Kaduk's No Record on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Sat, 13 July 2019 02:26 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3DD120074; Fri, 12 Jul 2019 19:26:36 -0700 (PDT)
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, SPF_HELO_NONE=0.001, 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 M3NQZfscFfFL; Fri, 12 Jul 2019 19:26:33 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7499712000E; Fri, 12 Jul 2019 19:26:32 -0700 (PDT)
Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6D2QQYC032041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Jul 2019 22:26:29 -0400
Date: Fri, 12 Jul 2019 21:26:26 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Jordi Palet Martínez <jordi.palet@theipv6company.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-v6ops-nat64-deployment@ietf.org, Mikael Abrahamsson <swmike@swm.pp.se>, v6ops-chairs@ietf.org, v6ops@ietf.org
Message-ID: <20190713022625.GT16418@mit.edu>
References: <156287111965.12025.574936602251693337.idtracker@ietfa.amsl.com> <1B6059DD-5BC9-4EBB-8278-A0EC436E543E@theipv6company.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1B6059DD-5BC9-4EBB-8278-A0EC436E543E@theipv6company.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/rH58qVNO0U93cqIHjBzN_lUOna0>
Subject: Re: [v6ops] Benjamin Kaduk's No Record on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Jul 2019 02:26:37 -0000

On Thu, Jul 11, 2019 at 10:58:51PM +0200, Jordi Palet Martínez wrote:
> Hi Benjamin,
> 
> I think if you put that question in the overall document context, the interpretation is different.

Oh, definitely.  I was just making an editorial comment about the wording
of question (a) in Section 3.3.

> Actually, the document advocates clearly to avoid breaking DNSSEC, and the best way to do that is either not doing DNS64 or (even better), ensuring that hosts do DNSSEC validation + DNS64 by themselves. This is possible already if you're using 464XLAT.
> 
> Also remember that the NAT64 is going to be used only for those services that are IPv4-only. I think we should advocate for those services to be IPv6-enabled + DNSSEC-enabled. If we agree on that, then the only missing piece is older IPv4-only boxes (in the customer side), which if can't be upgraded to support IPv6, I expect as well they will not be upgraded to support DNSSEC.

That sounds pretty likely, yeah; only some weird combination of legacy
technology and regulatory decree seems likely to get past it.

Thanks for writing the document; it was a good read!

-Ben

> Regards,
> Jordi
> @jordipalet
>  
> 
> El 11/7/19 20:52, "Benjamin Kaduk via Datatracker" <noreply@ietf.org> escribió:
> 
>     Benjamin Kaduk has entered the following ballot position for
>     draft-ietf-v6ops-nat64-deployment-07: No Record
>     
>     When responding, please keep the subject line intact and reply to all
>     email addresses included in the To and CC lines. (Feel free to cut this
>     introductory paragraph, however.)
>     
>     
>     Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>     for more information about IESG DISCUSS and COMMENT positions.
>     
>     
>     The document, along with other ballot positions, can be found here:
>     https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/
>     
>     
>     
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>     
>     Staying at No Record since I'm balloting late, but:
>     
>     Just asking "DNSSEC: Are there hosts validating DNSSEC?" may not be the
>     best way to plan for the future, as it ignores the question of whether
>     hosts may in the future start or want to start validating DNSSEC.
>     It would be unfortunate if deploying a NAT64 solution hindered DNSSEC
>     deployment as a side effect.
>     
>     
>     
> 
> 
> 
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
> 
> 
>