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

["Mudric, Dusan (Dusan)" <[e-mail]>]

Section 3.3:

"if the network must
   support applications using any of the following:

   o  IPv4-only hosts or applications

   Then, only the scenarios with 464XLAT, a CLAT function, or equivalent
   built-in local address synthesis features, will provide a valid
   solution."

Which document explains how 464XLAT and a CLAT function provide connectivity from IPv4only-host to IPv6only-host?

Thanks,
Dusan.


> -----Original Message-----
> From: v6ops <[e-mail]> On Behalf Of JORDI PALET
> MARTINEZ
> Sent: Sunday, July 7, 2019 5:24 PM
> To: Éric Vyncke <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; v6ops-
> [e-mail]
> Subject: 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-
> [e-mail] en nombre de [e-mail]> 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://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_iesg_statement_discuss-
> 2Dcriteria.html&d=DwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJ
> xhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=_E9ZufQAIc5wlVLDWKPA2DvW0t
> rvZwSDh5SnT8LOzdg&s=LwRXKT1d-8SS5QiUbHNrp33o3TBAeLqgs9RN-
> UwC0Yg&e=
>     for more information about IESG DISCUSS and COMMENT positions.
> 
> 
>     The document, along with other ballot positions, can be found here:
>     https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dv6ops-2Dnat64-
> 2Ddeployment_&d=DwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLe
> aJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=_E9ZufQAIc5wlVLDWKPA2DvW
> 0trvZwSDh5SnT8LOzdg&s=PHW-
> a847Dg670Srlft54euH86mfhpwcaNiqzcBPS8v4&e=
> 
> 
> 
>     ----------------------------------------------------------------------
>     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
>     [e-mail]
>     https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIGaQ&c=BFpWQw8bsuKp
> l1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=_E9
> ZufQAIc5wlVLDWKPA2DvW0trvZwSDh5SnT8LOzdg&s=wOPWzlIjnoqYXR0OM
> bl5dJswrnnMmmTX2ymOmmJ0Rfo&e=
> 
> 
> 
> 
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.theipv6company.com&d=DwIGaQ&c=BFpWQw8bsuKpl1SgiZH64
> Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=_E9ZufQAIc5
> wlVLDWKPA2DvW0trvZwSDh5SnT8LOzdg&s=DJpxsc514-
> zcfBAFS4ksUO1Az_LzLKo1Da80uIg60JA&e=
> 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.
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIGaQ&c=BFpWQw8bsuKp
> l1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=_E9
> ZufQAIc5wlVLDWKPA2DvW0trvZwSDh5SnT8LOzdg&s=wOPWzlIjnoqYXR0OM
> bl5dJswrnnMmmTX2ymOmmJ0Rfo&e=