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

Jordi Palet Martínez <jordi.palet@theipv6company.com> Thu, 11 July 2019 20:59 UTC

Return-Path: <prvs=1095f3ff43=jordi.palet@theipv6company.com>
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 48FAE120123; Thu, 11 Jul 2019 13:59:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=theipv6company.com
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 h9CTzzfT4yKZ; Thu, 11 Jul 2019 13:59:00 -0700 (PDT)
Received: from consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F4D6120043; Thu, 11 Jul 2019 13:58:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=theipv6company.com; s=MDaemon; t=1562878736; x=1563483536; i=jordi.palet@theipv6company.com; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=fp9BwycW3LD9swCYwg1jgGzuB4kmXx+G+Cv4gdfU/PY=; b=jlOjLKGKYhw9h 3kDNjSDUq7vYTxSn8jmvYjourvvdlDVfZua21GJ5tuN5DZSwbhE5Hl1aL6z5GeWk xTZDmFwXqAorNK8Mmuq7CvOZthQNUfa8HfMG29BLD/P1vUiIMVKmCucKjx1naxsD UVAgVyKyg5DCh5bqozMjV/bj96KQro=
X-MDAV-Result: clean
X-MDAV-Processed: consulintel.es, Thu, 11 Jul 2019 22:58:56 +0200
X-Spam-Processed: consulintel.es, Thu, 11 Jul 2019 22:58:56 +0200
Received: from [10.10.10.130] by consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006322879.msg; Thu, 11 Jul 2019 22:58:56 +0200
X-MDRemoteIP: 2001:470:1f09:495:9012:1705:2c6:98c1
X-MDHelo: [10.10.10.130]
X-MDArrival-Date: Thu, 11 Jul 2019 22:58:56 +0200
X-Authenticated-Sender: jordi.palet@theipv6company.com
X-Return-Path: prvs=1095f3ff43=jordi.palet@theipv6company.com
X-Envelope-From: jordi.palet@theipv6company.com
User-Agent: Microsoft-MacOutlook/10.10.b.190609
Date: Thu, 11 Jul 2019 22:58:51 +0200
From: Jordi Palet Martínez <jordi.palet@theipv6company.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: draft-ietf-v6ops-nat64-deployment@ietf.org, Mikael Abrahamsson <swmike@swm.pp.se>, v6ops-chairs@ietf.org, v6ops@ietf.org
Message-ID: <1B6059DD-5BC9-4EBB-8278-A0EC436E543E@theipv6company.com>
Thread-Topic: Benjamin Kaduk's No Record on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT)
References: <156287111965.12025.574936602251693337.idtracker@ietfa.amsl.com>
In-Reply-To: <156287111965.12025.574936602251693337.idtracker@ietfa.amsl.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/qM_zbokRgS9tl6a-8WTQCj0NlCA>
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: Thu, 11 Jul 2019 20:59:03 -0000

Hi Benjamin,

I think if you put that question in the overall document context, the interpretation is different.

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.

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.