Subject: [v6ops] Benjamin Kaduk's No Record on draft-ietf-v6ops-nat64-deployment-07: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Thu, 11 Jul 2019 11:51:59 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-v6ops-nat64-deployment-07: No Record

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

Staying at No Record since I'm balloting late, but:

Just asking "DNSSEC: Are there hosts validating DNSSEC?" may not be the
best way to plan for the future, as it ignores the question of whether
hosts may in the future start or want to start validating DNSSEC.
It would be unfortunate if deploying a NAT64 solution hindered DNSSEC
deployment as a side effect.

---

From: Jordi Palet Martínez <[email-masked]>
Date: Thu, 11 Jul 2019 22:58:51 +0200

Hi Benjamin,

I think if you put that question in the overall document context, the interpretation is different.

Actually, the document advocates clearly to avoid breaking DNSSEC, and the best way to do that is either not doing DNS64 or (even better), ensuring that hosts do DNSSEC validation + DNS64 by themselves. This is possible already if you're using 464XLAT.

Also remember that the NAT64 is going to be used only for those services that are IPv4-only. I think we should advocate for those services to be IPv6-enabled + DNSSEC-enabled. If we agree on that, then the only missing piece is older IPv4-only boxes (in the customer side), which if can't be upgraded to support IPv6, I expect as well they will not be upgraded to support DNSSEC.

Regards,
Jordi
@jordipalet

El 11/7/19 20:52, "Benjamin Kaduk via Datatracker" <[email-masked]> escribió:

    

    

**********************************************
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: Benjamin Kaduk <[email-masked]>
Date: Fri, 12 Jul 2019 21:26:26 -0500

> I think if you put that question in the overall document context, the interpretation is different.

Oh, definitely.  I was just making an editorial comment about the wording
of question (a) in Section 3.3.

> Also remember that the NAT64 is going to be used only for those services that are IPv4-only. I think we should advocate for those services to be IPv6-enabled + DNSSEC-enabled. If we agree on that,…

That sounds pretty likely, yeah; only some weird combination of legacy
technology and regulatory decree seems likely to get past it.

Thanks for writing the document; it was a good read!

-Ben

---

From: Jordi Palet Martínez <[email-masked]>
Date: Sat, 13 Jul 2019 09:01:39 +0200

Thanks Ben,

I guess then the RFC Editor may tell something if they consider that that specific question should be reworded.

Regards,
Jordi
@jordipalet

El 13/7/19 4:26, "Benjamin Kaduk" <[email-masked]> escribió:

    

    
    -Ben