Re: [v6ops] draft-bp-v6ops-ipv6-ready-dns-dnssec

[Lee Howard <[e-mail]>]

On 12/3/18 11:56 AM, Ron Bonica wrote:
> Folks,
>
> Each week between now and IETF 104, we will review and discuss one draft with an eye towards progressing it.
>
> This week, please review and comment on draft-bp-v6ops-ipv6-ready-dns-dnssec.
>
>                                                               Fred and Ron

I like the wording of draft-byrne-v6ops-dnssecaaaa better. The 
substantive change here is section 7, the actual timeline, and I expect 
it would have the same effectiveness as rfc5211 "An Internet Transition 
Plan," which indicated a transition phase January 2010 - December 2011. 
In all other ways I find this document inferior to 
draft-byrne-v6ops-dnssecaaaa, a document I supported (with comments, 
like wanting to know if there are ever any DNSSEC validators behind DNS64).

For judging consensus: I think a document would be useful in this space, 
but I don't think this is that document.

Detailed review follows.

_Abstract_:

A key issue for this, is the need for a global support
to
A key need is for global support

_Introduction_:

which will help
    to ensure that, when a network or part of it, becomes IPv6-only,
    still can have access to IPv4-only resources.
to
which will help
    to ensure that, when a network has IPv6 only, devices still have access to IPv4-only hosts.

DNS64 ([RFC6147  <https://tools.ietf.org/html/rfc6147>]) is a widely deployed technology allowing hundreds
    of millions of IPv6-only hosts/networks to reach IPv4-only resources.

Sounds like there's something uniquely scalable about DNS64. The 
description is section 3 is better, but also completely redundant with 
this paragraph.

The text from "Furthermore, the deployment of those transition 
mechanisms" to "deployment in a fair way" seems out of place for an IETF 
document. I completely agree that it's unfair that those without IPv4 
addresses must bear the cost of connecting to those with IPv4 addresses, 
I'm just not sure that's a consideration for the IETF.

_Section 3_

I don't understand "While DNS64([RFC6147 
<https://tools.ietf.org/html/rfc6147>]) outlines may work in harmony". 
Is that meant to read "as outlined"? Or are there outlines in DNS64?

Suggest editing:

  The document also states that the most complete and expedient path to
    avoid any negative interactions is, for the DNSSEC signed resources,
    to always include IPv6 AAAA resources records.

to

  The best path to avoid any negative interactions is for all DNSSEC signed resources
    to always include IPv6 AAAA resource records.

_Section 4_

unlikely to changes

to

unlikely to change

not recommend

to

not recommended


The sentence

Ultimately, this guidance is simply restating [RFC6540  <https://tools.ietf.org/html/rfc6540>], that IPv6 is
    mandatory for all Internet systems.

  is true, but begs the question of why this document is needed. The 
text from the original introduction is better:

As stated in [RFC6540  <https://tools.ietf.org/html/rfc6540>], IPv6 [RFC8200  <https://tools.ietf.org/html/rfc8200>] is not optional and
    failing to support IPv6 may result in failure to communicate on the
    internet, especially when DNSSEC signed IPv4-only resources are
    present.

There is no reason for sections 3 and 4 to be separate sections, and 
there is no need for section 5, and I don't understand any reason for 
section 6.

Section 7 was mentioned earlier.

Section 8 could be rewritten to point out that if users get frequent 
warnings of DNSSEC validation failures (due to DNS64), they will begin 
to ignore them.

Section 9 is not really within the authority of the IETF. ICANN does 
have an IPv6 program, and a proposal to track DNSSEC and IPv6 on servers 
is something they could do, but such a request would have to come via a 
liaison statement from the IAB, or even better, suggestions from the 
supporting organizations, including SSAC, RSSAC, ASO, gNSO, ccNSO, and 
maybe GAC.

I hope that's useful.

Lee