Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks
draft-ietf-v6ops-nat64-deployment-08

(1) Section 5.  Is there an informative reference that can be made about the successful deployment on cellular networks?

(2) Section 7.  Consider adding an explicit statement such as the following after the intro sentence that “no new security considerations are added”:

As noted in the relevant sections above, the NAT64 and DNS64 technologies can impact the efficacy or functionality of key security (i.e., DNSSEC and VPNs) and privacy preserving (i.e., DNS-over-TLS and DNS-over-HTTP) technologies.

(3) Editorial Nits

** Section 1.  Editorial. s/today unrealistic/unrealistic today/

** Section 5.  Typo.  s/learn he/learn the/

** Section 5.  Editorial.  “Hundreds of millions of users” mentioned twice.

OLD:
NAT64/464XLAT has demonstrated to be a valid choice in several scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), with hundreds of millions of users, being the predominant mechanism in the majority of the cellular networks (which account for hundreds of millions of users).

NEW:
NAT64/464XLAT has demonstrated to be a valid choice in several scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4) in cellular networks which account for hundreds of millions of users.

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/

It is strange to me that this document interleaves figures that are numbered and figures that are lettered.

= Section 4.4.2 =

"A new trend is for ..." 

This will not age well, probably better to phrase this in a timeless fashion.

The use of normative language in section 5 doesn't very consequent. While it is okay for informational document to have normative language, I have the feeling that the recommendation given in this document aren't very "strong" and therefore it might be more suitable to not use any normative language at all. Just a thing to consider before publication.

Minor comment: STUN ([RFC5389]) and TURN ([RFC5766]) have recently been bis'ed. Please update to the new RFC/draft.