[v6ops] Éric Vyncke's No Objection on draft-ietf-v6ops-nat64-deployment-06: (with COMMENT)

Éric Vyncke via Datatracker <noreply@ietf.org> Sun, 07 July 2019 12:58 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: v6ops@ietf.org
Delivered-To: v6ops@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C0512002E; Sun, 7 Jul 2019 05:58:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-v6ops-nat64-deployment@ietf.org, Mikael Abrahamsson <swmike@swm.pp.se>, v6ops-chairs@ietf.org, swmike@swm.pp.se, v6ops@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.98.2
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <156250429326.14626.2912462164177679261.idtracker@ietfa.amsl.com>
Date: Sun, 07 Jul 2019 05:58:13 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Z8LFhUn0PB64S5NF1TxP-Jex_Jo>
Subject: [v6ops] Éric Vyncke's No Objection on draft-ietf-v6ops-nat64-deployment-06: (with COMMENT)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 07 Jul 2019 12:58:14 -0000

Éric Vyncke has entered the following ballot position for
draft-ietf-v6ops-nat64-deployment-06: No Objection

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:
----------------------------------------------------------------------

Hello Jordi,

Thank you  for the work put into this clear and well-written document.

I only wonder whether section 3 and section 4 should be swapped for a more
logical flow: explain the issues, then describe working solutions. Probably too
late in the publication to change though.

The underlying message of "464XLAT solves everything" is annoying but I must
admit that this is true ;-)

Please find below many COMMENTs in the hope of improving the readability and
factual data points in the document.

-éric

== COMMENTS ==

Is there a description of the use of DNS64 in the host as it fixes the DNSSEC
issues ? (except in section 3.2.2.)

-- Section 3.1 --

"known to work": can you add references or data backing this statement ?

-- Section 3.1.1 --

When discussing scenarii, please refer to the figure ID in the text for clarity.

-- Section 3.1.2 --

It is unclear to me whether "The support of this scenario" refers to the
UE-only or the CPE deployment.

Same demand as above: please refer to the figure ID in the text for clarity.

-- Sectio 3.2.1 --

I really wonder whether it is useful to describe this scenario as 'working
under special conditions'... those 'special conditions' will probably never met
in real life.

More generally, I am unsure about the value of the whole section 3.2 (it is
more like an academic thing).

-- Section 4.1.1. --

Can you add reference and/or data for "monitored by some governmental bodies
and other institutions".

Please add a reference for the use of "ipv4only.arpa". AFAIK
draft-cheshire-sudn-ipv4only-dot-arpa appears to be dormant/dead.

-- Section 4.1.2 --

The leading paragraph is a little confusing as it assumed that CLAT exists
(stated in the text but not in the section title).

-- Section 4.1.5 --

The section title is rather misleading "ACL of clients" and I wonder why a
dual-stack client would use a DNS64 server as its recursive DNS server. Isn't
it an obvious configuration mistake?

-- Section 4.4.1 --

Some explanations of the consequences of a foreign DNS would be welcome.

-- Section 4.4.2 --

Rather than using "DNS privacy" please use "DNS request confidentiality" as the
DNS64 will learn/glean about the client activities.

-- Section 4.6 --

Please explain why older API is a problem (or rather rephrase it into
applications using IPv4-only API).

-- Section 4.10 --

draft-ietf-tram-turnbis is also able to support IPv6-only client. It is
currently in the same IESG status as this document.

-- Section 5 --

Please add data/references for "with hundreds of millions of users"

-- Section 7 --

Not so much about security but about privacy. I would appreciate to have some
text around the lack of privacy when using an external DNS64 as this server
will learn about all clients activities.

== NITS ==

Generally, please refrain from using "HEv2" in place of "Happy Eyeball version
2".

-- Section 3.1.1. --

Figure 1 shows a box containing both NAT64 and DNS64 while those functions
could reside in different devices.

s/One more equivalent scenario/One additional equivalent scenario/ ?

-- Section 4.1 --

s/to an IPv6-only WAN/to an IPv6-only access network/