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

From: Ron Bonica <[email-masked]>
Date: Mon, 3 Dec 2018 16:56:51 +0000

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

---

From: Lencse Gábor <[email-masked]>
Date: Thu, 6 Dec 2018 14:05:13 +0100

Hi,

I have just found a paper, which recommends an alternative solution: 
"DNSSEC in the networks with a NAT64/DNS64". Available: 
https://ieeexplore.ieee.org/document/8501446

However, I am not sure, how good it is.

Gábor

12/3/2018 5:56 PM keltezéssel, Ron Bonica írta:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: 神明達哉 <[email-masked]>
Date: Fri, 7 Dec 2018 11:34:34 -0800

At Mon, 3 Dec 2018 16:56:51 +0000,

> This week, please review and comment on
draft-bp-v6ops-ipv6-ready-dns-dnssec.

I've read draft-bp-v6ops-ipv6-ready-dns-dnssec-00.

While the motivation is laudable, I have to say I'm skeptical about
its effectiveness if one main audience is "the IPv4 laggards".  Just
as it may be "unfair" that an IPv6-only service provider needs to
handle A-only DNSSEC signed zones, it would be "unfair" for these
"laggards" that they are required to deploy IPv6 services and publish
corresponding AAAAs when they only need (for whatever reasons)
IPv4-only services.  I suspect referring to RFC6540 doesn't help for
those people.

On a related note, there's one thing I'm not sure from the draft:
whether "requiring AAAA" also means "requiring to provide the
corresponding service over IPv6" (here I assume the existence of such
a service; that should normally be the case in practice).  In the
previous paragraph I assumed the draft requires this too, but if it
only means some AAAA that is correctly signed but the address doesn't
have to be accessible over IPv6, then it might be more acceptable for
lazy "laggards".  Ideally such an unreachable IPv6 address should
cause an immediate failure when an IPv6 node tries to send a packet to
it, but some smartness like HE may be good enough to handle cases
where those IPv6 addresses create a blackhole.  If that's the intent
of the draft, I'd suggest making it clearer, possibly with suggesting
some specific IPv6 addresses (maybe ::?) to be used for this purpose.

This draft seems to also talk about providing IPv6 reachability to
name servers (which is irrelevant to providing DNSSEC-signed AAAA).
For example Section 6 states:

   In the context of this document, and others that may be generated as
   a consequence of it, "IPv6-Ready DNS/DNSSEC Infrastructure" means
   that a DNS/DNSSEC server (root, TLD, authoritative NS, others) is
   fully accessible and operational if queried either from a remote
   dual-stack network or an IPv6-only network.

Is my understanding correct?  If so, I suspect it's more likely to be
just ignored by the "laggards" for the same reason as that I mentioned
above.  And, in any case, I personally think it's better if this
document focuses on the issue of interaction between DNSSEC and
DNS64.  If my understanding of this part is incorrect, then it's not
clear to me what it means and I'd suggest rewriting it.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 Dec 2018 08:51:26 +1300

On 2018-12-08 08:34, 神明達哉 wrote:
> its effectiveness if one main audience is "the IPv4 laggards".  

Unfortunately I have to agree. An IETF RFC seems like the least
likely method of achieving the desired result. I think past experience
shows that hard, persistent work through the major operational
gatherings and forums, particularly the various RIR-sponsored meetings,
with help from ISOC, is the only way to get anywhere.

    Brian

> Just

---

From: 神明達哉 <[email-masked]>
Date: Fri, 7 Dec 2018 12:15:22 -0800

On Fri, Dec 7, 2018 at 11:34 <[email-masked]> wrote:

>    corresponding service over IPv6" (here I assume the existence of
>    such a service; that should normally be the case in practice).

Immediately after sending the message I realized I was confused
here...it should obviously mean "also providing IPv6 services";
otherwise the IPv6-only networks would still need some trick to deal
with "inauthentic AAAAs".  So I think the draft should state it even
more clearly.  It's quite easy and cheap to Just sign and publish
AAAA, but it's certainly more complicated and costly for a
now-IPv4-only network to support IPv6 services.  It would be
misleading to simply say "requiring AAAA" without clarifying that
point.  And then my higher point about the effectiveness applies,
though...

--
JINMEI, Tatuya

---

From: Lee Howard <[email-masked]>
Date: Fri, 7 Dec 2018 16:23:32 -0500

> This week, please review and comment on draft-bp-v6ops-ipv6-ready-dns-dnssec.

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