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

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 17 Apr 2019 13:50:22 +0200

Hi Dan,

I've reworded the complete section for "foreign DNS", as follows:

4.4.  Foreign DNS

   When clients, in a service provider network, use DNS servers from
   other networks, they may support or not DNS64, so the considerations
   in Section 4.3 will apply as well.

   This may be the case either if individual applications use their own
   DNS server, the Operating System itself or even the CE, or
   combinations of all the above.

   Even in the case that the external DNS supports the DNS64 function, we
   may be in the situation of providing incorrect configurations
   parameters, for example un-matching WKP or NSP, or a case such the
   one described in Section 3.2.3.

   Having a CLAT, even if using an external DNS without DNS64, ensures
   that everything will work, so the CLAT must be considered as an
   advantage against user configuration errors.  The cost of it is that
   all the traffic will use a double translation (NAT46 at the CLAT and
   NAT64 at the operator network), unless there is support for EAMT
   (Section 4.9).

   An exception to that is the case when there is a CLAT at the CE,
   which is not able to obtain the correct configuration parameters
   (again, un-matching WKP or NSP).

   However, it needs to be reinforced, that if there is not a CLAT
   (scenarios without 464XLAT), an external DNS without DNS64 support,
   will disallow any access to IPv4-only destination networks, and will
   not guarantee DNSSEC, so will behave as in the Section 3.2.1.

   The causes of "foreign DNS" could be classified in three main
   categories, as depicted in the following sub-sections.

4.4.1.  Manual Configuration of Foreign DNS

   It is becoming increasingly common that end-users or even devices or 
   applications configure alternative DNS in their Operating Systems,
   and some times in CEs.

4.4.2.  DNS Privacy

   A new trend is for clients or applications to use mechanisms for DNS
   privacy/encryption, such as DNS over TLS ([RFC7858]), DNS over DTLS
   ([RFC8094]), DNS queries over HTTPS ([RFC8484]) or DNS over QUIC
   ([I-D.huitema-quic-dnsoquic]).  Those are commonly cited as DoT, DoH
   and DoQ.

   Those DNS privacy/encryption options, currently are typically
   provided by the applications, not the Operating System vendors.  At
   the time of writing this document, at least DoT and DoH standards
   have declared DNS64 (and consequently NAT64) out of their scope, so
   an application using them may break NAT64, unless a correctly
   configured CLAT is used.

4.4.3.  Split DNS

   When networks or hosts use "split-DNS" (also called Split Horizon) or
   private DNS,the successful use of the DNS64 is not guaranteed.
   Section 4. of [RFC6950], analyses this case.

   A similar situation may happen in case of VPNs that force all the DNS
   queries thru the VPN, ignoring the DNS64.
 
Then, section 5 paragraph becomes:

   The only 100% safe solution, which also resolves all the issues, will
   be, in addition to having a CLAT, not using a DNS64 but instead
   making sure that the hosts have a built-in address synthesis feature.
   Operators could manage to use the CLAT, however the built-in address
   synthesis feature is out of their control.  If the synthesis is
   provided either by the Operating System (via its DNS resolver API) or
   by the application (via its own DNS resolver), in such way that the
   prefix used for the NAT64 is reachable for the host, the problem goes
   away.

Note than when rewriting the text, I realized that even if the DoT/DoH provider is able to provide a DNS64 function, this needs to "know" what is the operator NAT64, or an alternative one, so the "operational" problem really goes away. So, I've slightly modified your previous text suggestions, trying to address that.

Thanks again and happy to hear your inputs on this new text.

El 16/4/19 22:27, "v6ops en nombre de JORDI PALET MARTINEZ" <[email-masked] en nombre de jordi.palet=[email-masked]> escribió:

    Hi Dan,
    
    Thanks again, below some responses. 
    
    El 16/4/19 21:24, "Dan Wing" <[email-masked]> escribió:
    
        On Apr 16, 2019, at 9:16 AM, JORDI PALET MARTINEZ <[email-masked]> wrote:
        > 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ó:
        > 
        >    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.
        > 
        > 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?).
    
    Thanks, I will also re-read draft-reddy-dprive-bootstrap-dns-server and update the text.

        >    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.
        > 
        > 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).
    
    I think is perfect, thanks again!

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

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

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

    _______________________________________________
    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: Gábor Lencse <[email-masked]>
Date: Wed, 17 Apr 2019 21:40:38 +0900

Hi Jordi,

Could you send the "-05" version, so that I can continue on reading the 
most up to date text form Section 4?

Perhaps it is worth sending it on the list, if possible.

Thanks.

Gábor

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 17 Apr 2019 15:04:18 +0200

Hi Gabor,

The changes are only those that have been reflected in emails in the list, anyway, I will make a txt version and email directly to you.

Saludos,
Jordi

El 17/4/19 14:41, "v6ops en nombre de Gábor Lencse" <[email-masked] en nombre de [email-masked]> escribió:

    Hi Jordi,

    
    Thanks.
    
    Gábor

---

From: Gábor Lencse <[email-masked]>
Date: Thu, 18 Apr 2019 21:06:54 +0900

Hi Jordi,

Just a few suggestions:

12.ANNEX C: Benchmarking

Several documents provide references to benchmarking, for example in
the case of DNS64, [DNS64-Benchm].

-->

12.ANNEX C: Benchmarking

***[RFC8219] has defined a benchmarking methodology for IPv6 transition **
**   technologies. NAT64 and 464XLAT is addressed among the single **
**   translation and double translation technologies, respectively. DNS64
    is addressed**its Section 9, and the methodology is more elaborated 
in **
**   [DNS64-BM-Meth].*

    Several documents provide references to benchmarking *results*, for 
example in
the case of DNS64, [DNS64-Benchm].

16.2.Informative References

[...]

[DNS64-Benchm]
"Benchmarking DNS64 Implementations: Theory and Practice",
Computer Communications _(Elsevier_), vol. 127, no. 1,
pp. 61-74, DOI 10.1016/j.comcom.2018.05.005, September
2018.

-->

[DNS64-Benchm]
*Lencse, G. and Y. Kadobayashi, *"Benchmarking DNS64 Implementations: 
Theory and Practice",
Computer Communications, vol. 127, no. 1,
pp. 61-74, DOI 10.1016/j.comcom.2018.05.005, September
2018.

*[DNS64-BM-Meth]
**Lencse, G., Georgescu, ***M. *and Y. Kadobayashi, "Benchmarking
               Methodology for DNS64 Servers", Computer Communications,
               vol. 109, no. 1, pp. 162-175, September 1, 2017,
               DOI: 10.1016/j.comcom.2017.06.004*

[Threat-DNS64]
"Methodology for the identification of potential security
issues of different IPv6 transition technologies: Threat
analysis of DNS64 and stateful NAT64", Computers &
Security _(Elsevier)_, vol. 77, no. 1, pp. 397-411,
DOI 10.1016/j.cose.2018.04.012, August 2018.

-->

[Threat-DNS64]
*Lencse, G. and Y. Kadobayashi, *"Methodology for the identification of 
potential security
issues of different IPv6 transition technologies: Threat
analysis of DNS64 and stateful NAT64", Computers &
Security, vol. 77, no. 1, pp. 397-411,
DOI 10.1016/j.cose.2018.04.012, August 2018.

Best regards,

Gábor

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 18 Apr 2019 22:10:23 +0200

Hi Gabor,

Resolved, thanks!

Regads,

Jordi

El 18/4/19 14:07, "Gábor Lencse" <[email-masked]> escribió:

Hi Jordi,

Just a few suggestions:

12.  ANNEX C: Benchmarking

-->

12.  ANNEX C: Benchmarking

   [RFC8219] has defined a benchmarking methodology for IPv6 transition 
   technologies. NAT64 and 464XLAT is addressed among the single 
   translation and double translation technologies, respectively. DNS64 
   is addressed its Section 9, and the methodology is more elaborated in 
   [DNS64-BM-Meth].

   Several documents provide references to benchmarking results, for example in
   the case of DNS64, [DNS64-Benchm].

16.2.  Informative References

[...]

   [DNS64-Benchm]
              "Benchmarking DNS64 Implementations: Theory and Practice",
              Computer Communications (Elsevier), vol. 127, no. 1,
              pp. 61-74, DOI 10.1016/j.comcom.2018.05.005, September
              2018. 

-->

   [DNS64-Benchm]
              Lencse, G. and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice",
              Computer Communications, vol. 127, no. 1,
              pp. 61-74, DOI 10.1016/j.comcom.2018.05.005, September
              2018.

   [DNS64-BM-Meth]
              Lencse, G., Georgescu, M. and Y. Kadobayashi, "Benchmarking 
              Methodology for DNS64 Servers", Computer Communications, 
              vol. 109, no. 1, pp. 162-175, September 1, 2017, 
              DOI: 10.1016/j.comcom.2017.06.004 

   [Threat-DNS64]
              Security (Elsevier), vol. 77, no. 1, pp. 397-411,

-->

   [Threat-DNS64]
              Lencse, G. and Y. Kadobayashi, "Methodology for the identification of potential security

Best regards,

Gábor

 
Saludos,
Jordi

 
    Hi Jordi,

    
    Thanks.
    
    Gábor

    On 4/17/2019 20:50, JORDI PALET MARTINEZ wrote:
    > Hi Dan,
    >
    > I've reworded the complete section for "foreign DNS", as follows:
    >
    > 4.4.  Foreign DNS
    >
    >     When clients, in a service provider network, use DNS servers from
    >     other networks, they may support or not DNS64, so the considerations
    >     in Section 4.3 will apply as well.
    >
    >     This may be the case either if individual applications use their own
    >     DNS server, the Operating System itself or even the CE, or
    >     combinations of all the above.
    >
    >     Even in the case that the external DNS supports the DNS64 function, we
    >     may be in the situation of providing incorrect configurations
    >     parameters, for example un-matching WKP or NSP, or a case such the
    >     one described in Section 3.2.3.
    >
    >     Having a CLAT, even if using an external DNS without DNS64, ensures
    >     that everything will work, so the CLAT must be considered as an
    >     advantage against user configuration errors.  The cost of it is that
    >     all the traffic will use a double translation (NAT46 at the CLAT and
    >     NAT64 at the operator network), unless there is support for EAMT
    >     (Section 4.9).
    >
    >     An exception to that is the case when there is a CLAT at the CE,
    >     which is not able to obtain the correct configuration parameters
    >     (again, un-matching WKP or NSP).
    >
    >     However, it needs to be reinforced, that if there is not a CLAT
    >     (scenarios without 464XLAT), an external DNS without DNS64 support,
    >     will disallow any access to IPv4-only destination networks, and will
    >     not guarantee DNSSEC, so will behave as in the Section 3.2.1.
    >
    >     The causes of "foreign DNS" could be classified in three main
    >     categories, as depicted in the following sub-sections.
    >
    > 4.4.1.  Manual Configuration of Foreign DNS
    >
    >     It is becoming increasingly common that end-users or even devices or
    >     applications configure alternative DNS in their Operating Systems,
    >     and some times in CEs.
    >
    > 4.4.2.  DNS Privacy
    >
    >     A new trend is for clients or applications to use mechanisms for DNS
    >     privacy/encryption, such as DNS over TLS ([RFC7858]), DNS over DTLS
    >     ([RFC8094]), DNS queries over HTTPS ([RFC8484]) or DNS over QUIC
    >     ([I-D.huitema-quic-dnsoquic]).  Those are commonly cited as DoT, DoH
    >     and DoQ.
    >
    >     Those DNS privacy/encryption options, currently are typically
    >     provided by the applications, not the Operating System vendors.  At
    >     the time of writing this document, at least DoT and DoH standards
    >     have declared DNS64 (and consequently NAT64) out of their scope, so
    >     an application using them may break NAT64, unless a correctly
    >     configured CLAT is used.
    >
    > 4.4.3.  Split DNS
    >
    >     When networks or hosts use "split-DNS" (also called Split Horizon) or
    >     private DNS,the successful use of the DNS64 is not guaranteed.
    >     Section 4. of [RFC6950], analyses this case.
    >
    >     A similar situation may happen in case of VPNs that force all the DNS
    >     queries thru the VPN, ignoring the DNS64.
    >   
    > Then, section 5 paragraph becomes:
    >
    >     The only 100% safe solution, which also resolves all the issues, will
    >     be, in addition to having a CLAT, not using a DNS64 but instead
    >     making sure that the hosts have a built-in address synthesis feature.
    >     Operators could manage to use the CLAT, however the built-in address
    >     synthesis feature is out of their control.  If the synthesis is
    >     provided either by the Operating System (via its DNS resolver API) or
    >     by the application (via its own DNS resolver), in such way that the
    >     prefix used for the NAT64 is reachable for the host, the problem goes
    >     away.
    >
    >
    > Note than when rewriting the text, I realized that even if the DoT/DoH provider is able to provide a DNS64 function, this needs to "know" what is the operator NAT64, or an alternative one, so the "operational" problem really goes away. So, I've slightly modified your previous text suggestions, trying to address that.
    >
    > Thanks again and happy to hear your inputs on this new text.
    >
    > El 16/4/19 22:27, "v6ops en nombre de JORDI PALET MARTINEZ" <[email-masked] en nombre de jordi.palet=[email-masked]> escribió:
    >
    >      Hi Dan,
    >      
    >      Thanks again, below some responses.
    >      
    >      El 16/4/19 21:24, "Dan Wing" <[email-masked]> escribió:
    >      
    >          On Apr 16, 2019, at 9:16 AM, JORDI PALET MARTINEZ <[email-masked]> wrote:
    >          > 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ó:
    >          >
    >          >    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.
    >          >
    >          > 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?).
    >      
    >      Thanks, I will also re-read draft-reddy-dprive-bootstrap-dns-server and update the text.
    >          
    >          
    >          >    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.
    >          >
    >          > 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).
    >      
    >      I think is perfect, thanks again!
    >          
    >          
    >          >    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.
    >          >
    >          > 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.
    >      
    >      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
    >          
    >          
    >          >    -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.
    >          >
    >          >
    >          >
    >          
    >          
    >      
    >      
    >      
    >      **********************************************
    >      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.
    >      
    >      
    >      
    >      _______________________________________________
    >      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.
    >
    >
    >
    > _______________________________________________
    > v6ops mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/v6ops
    >

---

From: Dan Wing <[email-masked]>
Date: Thu, 18 Apr 2019 17:11:31 -0700

> I've reworded the complete section for "foreign DNS", as follows:
...
> Thanks again and happy to hear your inputs on this new text.

Exactly the sort of re-structuring that I was thinking -- but I did not explain well.  Thank you!  The new section 5 paragraph is great, too, because it explains the end-goal for the client endpoint to do the DNS64 synthesis -- which is also the only way for the client endpoint to validate DNSSEC.

Thanks again,
-d