Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04

From: Dan Wing <[email-masked]>
Date: Tue, 16 Apr 2019 08:28:19 -0700

Fred Baker <[email-masked]> wrote:

> For the record, the question here is two-fold. First, is it correct and complete? Is there more, or less, that should be said? Second, are there operators -ISPs, IxPs, enterprise, or whatever, that consider this useful in their deployments?

I find the document useful.

There are two things I noticed with this one sentence in Section 5,

  "however the built-in address synthesis feature is out of their control, and can only be resolved by operating system vendors."

which should mention (1) DoT and DoH and (2) centralized un-encrypted DNS, detailed below.

1. DoT and DoH are provided by the application, not provided by OS vendors (at least, not yet) - but that text implies only the OS vendor can change how DNS works on the host.  DoT and DoH demonstrate otherwise.  The above text should at least mention that DoT and DoH standards have declared DNS64 (and thus NAT64) out of their scope but explain that an application doing DoT/DoH will break with NAT64, and should discuss the operational difficulties of DoT and DoH on a network with NAT64 and DNS64.

2. The document should also mention using a non-network provided DNS (e.g., 8.8.8.8) won't provide the necessary/expected DNS64.  Most hosts do not support changing DNS settings on a per-network basis, either, so using a specific DNS like 8.8.8.8 when on WiFi and using the network-provided DNS64 when on a NAT64 network is usually not possible -- a further operational difficulty placed on the user.  

-d

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 16 Apr 2019 18:16:45 +0200

Hi Dan,

Thanks a lot for the inputs.

El 16/4/19 18:05, "v6ops en nombre de Dan Wing" <[email-masked] en nombre de [email-masked]> escribió:

    

    

I will update/reword the sentence. There is an explicit section (4.5.  DNS Privacy) covering that.

Exactly, we had that discussion when I was working in the initial versions of this document and the DoH work was on-going as well.

This is covered in Section 4.4.  Manual Configuration of Foreign DNS. I will double check that I'm not missing it in the summary.
    
    -d
    
    _______________________________________________
    v6ops mailing list
    [email-masked]
    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.

---

From: Dan Wing <[email-masked]>
Date: Tue, 16 Apr 2019 12:23:58 -0700

> I will update/reword the sentence. There is an explicit section (4.5.  DNS Privacy) covering that.

Thanks for the pointer.  That existing text in 4.5 makes an unstated assumption that the DNS-over-encrypted-channel server is not doing DNS64.  I would make that clearer.  Note there are ideas floating around, such as draft-reddy-dprive-bootstrap-dns-server, which have the local network provide the DNS-over-encrypted-channel function, where DNS64 could be provided.  I don't think draft-reddy-dprive-bootstrap-dns-server is ready to be cited yet, but I would tighten up the wording of Section 4.5 to make clear the problem is the DoH/DoT/DoQ operator is not also doing the necessary DNS64 function.  If they are, the operational problem goes away (right?).

> Exactly, we had that discussion when I was working in the initial versions of this document and the DoH work was on-going as well.

Ok.  I suggest changing that sentence in Section 5 something like this,

OLD:
  can only be resolved by operating system vendors
NEW:
  can be synthesized by the OS vendor (via its DNS resolver API) or the application (via its own own DNS resolver).

> This is covered in Section 4.4.  Manual Configuration of Foreign DNS. I will double check that I'm not missing it in the summary.

Thanks for the pointer.  I'm confused that both section 4.4 and section 4.5 are about manual configuration of a foreign DNS -- 4.4 is un-encrypted, 4.5 is encrypted.  

-d

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 16 Apr 2019 22:26:34 +0200

Hi Dan,

Thanks again, below some responses. 

El 16/4/19 21:24, "Dan Wing" <[email-masked]> escribió:

Thanks, I will also re-read draft-reddy-dprive-bootstrap-dns-server and update the text.

    
    OLD:

I think is perfect, thanks again!

Another good point. The explanation is simple. I did 4.4 in earlier versions and then created 4.5. It clearly makes sense to have a single section (4.4) and a sub-section for each one, so definitively will work on this tomorrow and try to publish how it will look like in the list to seek further comments.
    
    -d