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

Hi Eric,

Thanks a lot for your review!

Comments in-line below. Most of them I will reword some text or correct nits, but there are a couple of questions for you to clarify.

Regards,
Jordi
@jordipalet

El 7/7/19 14:59, "v6ops en nombre de Éric Vyncke via Datatracker" <v6ops-bounces@ietf.org en nombre de noreply@ietf.org> escribió:

    É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.

I think that will be a major change, because I've a lot of references to the "possible" deployment scenarios to explain the different issues. My "flow" was thinking in how you can deploy it, and then what are the issues that you need to consider.

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

This document started as 464XLAT deployment guidelines, and the WG asked me to turn it also to "NAT64". I think that explains it, but in any case, as you well say, it is true ... and there is explicit text to indicate that if you're sure that everything inside the network is supporting IPv6, no literals, etc., then it may be fine with just NAT64. However we all know that this is a non-realistic scenario.

    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.)

Not sure to completely understand what you mean here, just trying ... This is not something that the service provider can solve, as it is up to the OS (for all the devices in that network). That's why I think is not something for this document. However, I just realized that this is described in section 7.2 of RFC6147. I can add a reference to that in section 3.2.2.

    -- Section 3.1 --

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

Well, those are the models being used today in cellular and broadband networks. So I can just say that?

    -- Section 3.1.1 --

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

Done (I'm already editing a new version while writing this, pending on some that you can provide to my comments).

    -- Section 3.1.2 --

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

It is referring to the "service provider network support". Will clarify it.

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

Done!

    -- 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).

I think some of those scenarios are possible in some networks, may be not connecting to Internet, or for example, you may want to configure explicit mappings, which can be done with EAM. I just realized that I've not cited that. I will do.

    -- Section 4.1.1. --

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

I believe that was pointed out by somebody in the WG, but it is true that some regulators do that. I recall having seen something about that in France, but I'm not 100% sure right now.

    Please add a reference for the use of "ipv4only.arpa". AFAIK

Right, this is defined by RFC7050, done!

    draft-cheshire-sudn-ipv4only-dot-arpa appears to be dormant/dead.

This is one of the issues that I've commented with Warren, responding to IANA. I understand he is sponsoring that document. 

    -- 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).

Will clarify it.

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

No, I think that text is correct, but I will try to reword it to make it clearer. You may have a situation with IPv4-only servers, which are located, in the path between the dual-stack hosts and the NAT64. So, if the DNS64 is not configured to exclude those servers, it will synthetize the AAAA records and they will become unreachable. So that's why bind and other DNS64 servers provide this ACL function.

    -- Section 4.4.1 --

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

Done!

    -- Section 4.4.2 --

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

I used this terminology as it was suggested as the common one for the different protocols in this category. I will try to confirm if is the right one just in case. May be rewording the title as "DNS Privacy/Encryption Mechanisms" ?

    -- Section 4.6 --

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

Done!

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

Definitively, will add a reference to it!

    -- Section 5 --

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

I can cite several cellular networks, but I will do in a generic way, I don't think we should mention explicit providers, right?. 

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

Good point, thanks. Will do!

    == NITS ==

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

Done!

    -- Section 3.1.1. --

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

Will clarify it.

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

Done!

    -- Section 4.1 --

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

Done!    

    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
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.