Subject: Re: [v6ops] New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 10 Oct 2018 20:32:43 +0200

Hi all,

We have worked in an integrated version of two documents:

draft-v6ops-byrne-dnssecaaaa
draft-palet-sunset4-ipv6-ready-dns-00

The new document is now:

https://datatracker.ietf.org/doc/draft-bp-v6ops-ipv6-ready-dns-dnssec/?include_text=1

Inputs welcome!

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]>
Fecha: miércoles, 10 de octubre de 2018, 20:30
Para: Jordi Palet <[email-masked]>, Jordi Palet Martinez <[email-masked]>, Cameron Byrne <[email-masked]>, Cameron Byrne <[email-masked]>
Asunto: New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt

    A new version of I-D, draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt
    has been successfully submitted by Jordi Palet Martinez and posted to the
    IETF repository.
    
    Name:		draft-bp-v6ops-ipv6-ready-dns-dnssec
    Revision:	00
    Title:		IPv6-Ready DNS/DNSSSEC Infrastructure
    Document date:	2018-10-10
    Group:		Individual Submission
    Pages:		6
    URL:            https://www.ietf.org/internet-drafts/draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt
    Status:         https://datatracker.ietf.org/doc/draft-bp-v6ops-ipv6-ready-dns-dnssec/
    Htmlized:       https://tools.ietf.org/html/draft-bp-v6ops-ipv6-ready-dns-dnssec-00
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-bp-v6ops-ipv6-ready-dns-dnssec

    Abstract:
       This document defines the timing for implementing a worldwide
       IPv6-Ready DNS and DNSSEC infrastructure, in order to facilitate the
       global IPv6-only deployment.
    
       A key issue for this, is the need for a global support of DNSSEC and
       DNS64, which in some scenarios do not work well together.  This
       document states that any DNSSEC signed resources records should
       include a native IPv6 resource record as the most complete and
       expedient path to solve any deployment conflict with DNS64 and DNSSEC

    
    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org.
    
    The IETF Secretariat

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
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: Lencse Gábor <[email-masked]>
Date: Wed, 10 Oct 2018 21:22:23 +0200

Dear Jordi and Cameron,

I have read the draft and I agree with the solution (to provide also a 
AAAA record if the zone is DNSSEC signed) as a "recommendation".

However, I do not think that the timing described in Section 7 would be 
feasible. What do you mean under "MUST be suspended" in the following 
sentence?

	[...] If there is a failure at the
    deadline in complying with those requirements, the relevant NS, MUST
    be temporarily suspended until there is a subsequent successful
    verification.

Who would suspend what?

In my (admittedly incomplete) understanding  of the role of 
informational RFCs of the v6ops WG, they should provide guidance, and 
they may not command other bodies to do something.

Please correct me if I am mistaken.

Best regards,

Gábor

10/10/2018 8:32 PM keltezéssel, JORDI PALET MARTINEZ írta:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 11 Oct 2018 22:27:34 +0200

Hi Gabor,

I see this draft more than a recommendation (despite the wording and the type of document), which can be changed along the progress in this WG or even other levels, as a call for one more IANA/ICANN action.

They mandate the support of IPv6 in the contracts with the gTLDs, etc., but is not always being followed.

In addition to ensure that that is followed sometime soon, why not make sure that the same conditions are in place for any NS and so on for any kind of RRs ?

I see the IETF as responsible for taking actions, as we are the “protocol owners” and that means something. We have liaisons also with all the related organizations, to make this work and have a shorter period of “pain” (yes transition is not perfect, so will be better to speed it up now that is feasible, just look at the success of IPv6 in cellular networks and other big broadband networks) for the complete world population.

Regards,

Jordi

De: v6ops <[email-masked]> en nombre de Lencse Gábor <[email-masked]>
Fecha: miércoles, 10 de octubre de 2018, 21:23
Para: <[email-masked]>
Asunto: Re: [v6ops] New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt

Dear Jordi and Cameron,

I have read the draft and I agree with the solution (to provide also a AAAA record if the zone is DNSSEC signed) as a "recommendation". 

However, I do not think that the timing described in Section 7 would be feasible. What do you mean under "MUST be suspended" in the following sentence?
  [...] If there is a failure at the
   deadline in complying with those requirements, the relevant NS, MUST
   be temporarily suspended until there is a subsequent successful
   verification.

Who would suspend what?

In my (admittedly incomplete) understanding  of the role of informational RFCs of the v6ops WG, they should provide guidance, and they may not command other bodies to do something.

Best regards,

Gábor

 
 
The new document is now:

Inputs welcome!
 
Regards,
Jordi

 
-----Mensaje original-----
De: <[email-masked]>
Fecha: miércoles, 10 de octubre de 2018, 20:30
Para: Jordi Palet <[email-masked]>, Jordi Palet Martinez <[email-masked]>, Cameron Byrne <[email-masked]>, Cameron Byrne <[email-masked]>
Asunto: New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt

    Abstract:

    

    The IETF Secretariat

 

_______________________________________________ v6ops mailing list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops

---

From: Jen Linkova <[email-masked]>
Date: Wed, 17 Oct 2018 20:46:54 +1100

> https://datatracker.ietf.org/doc/draft-bp-v6ops-ipv6-ready-dns-dnssec/?include_text=1

The new document starts with:
"This document defines the timing for implementing a worldwide
   IPv6-Ready DNS and DNSSEC infrastructure, in order to facilitate the
   global IPv6-only deployment."

So you are suggesting that DNS operators have to do some work (in
quite short timeframe) to facilitate something they might not even
care about...Not sure it would work.

Then there is a section 7 (Implementation Timeline) which look a bit
unrealistic. (I have to confess I wish we had a magic wand to make it
happen...).
If I let my imagination run wild...let's say a miracle has happened
and steps 1-3 are done.
Obviously *just* adding AAAA RR for A-only names has nothing to do
with enabling IPv6 for a service.
The service needs to have IPv6 connectivity (which might not even be
available in the specific location) it needs to be tested etc. Adding
AAAA w/o doing all of that would just negatively impact user
experience.
What would happen if a imaginary website cutekittens.example.net which
hosts popular videos of kittens (and koals) suddenly gets AAAA RR in
DNS w/o IPv6 being properly enabled for it? Or even worse, the
webservice would respond to TCP handshake but would not be able to
server users over IPv6? Well, I'm sure 99.9% of level1 techsupport
engineers would tell the unhappy customers "disable IPv6 on your
device and it would solve your issue". I'm not sure it's want we want.

Also, how exactly are you suggesting to enforce the step 4?

Last but not least: "If there is a failure at the
   deadline in complying with those requirements, the relevant NS, MUST
   be temporarily suspended until there is a subsequent successful
   verification."
So an NS for cutekittens.example.net got suspended (whatever it means).
So the server would become unreachable? How could it be fixed/get IPv6 enabled?

"MUST" in RFCs are (usually) for a reason. If you do not follow MUST
smth bad would happen.
This draft has a lot of MUST which (IMHO) could not be enforced.

To sum up, I found draft-v6ops-byrne-dnssecaaaa be more useful and
realistic. It explains why if you want to use DNSSEC for your zone,
you should consider enable IPv6.

-- 
SY, Jen Linkova aka Furry

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 17 Oct 2018 21:13:14 +0200

Hi Jen,

Responding below, in-line.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Jen Linkova <[email-masked]>
Fecha: miércoles, 17 de octubre de 2018, 11:47
Para: <jordi.palet=[email-masked]>
CC: V6 Ops List <[email-masked]>
Asunto: Re: [v6ops] New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt

    

They should care about providing a good service, right?

A good service today is not just IPv4-only.

Clearly, we need to rephrase it. We meant not just the RR part, but of course, having the IPv6 connectivity.

IPv6 free tunnels are available, in case, I doubt, you can't setup a tunnel to your upstream provider or alternatively to any of their upstreams. I've been there, several times, in the most strange and remote locations.

    

We are calling ICANN to take actions and enforce them to the registrars. ICANN has something already in TLD contracts. Is time to enforce it.

I think trying is much better than just complaining and not doing something. Clearly IETF liaison with ICANN need to take actions here.

Believe it or not, there are still many DNS "operators" that have no idea about IPv6, and a call for action should enforce them to do something.

---

From: Jen Linkova <[email-masked]>
Date: Fri, 19 Oct 2018 01:43:44 +1100

> A good service today is not just IPv4-only.

So you are saying that IETF needs to publish a document which mandates
that all DNS operators not providing good services should get their
NSes "temporarily suspended"?

Well, why stop here? As both of us are at RIPE77 now - maybe it's time
to suggest that ASes  not advertizing IPv6 blocks (or not getting 5
starts in IPv6 RIPEness?) shall get their v4 blocks taken away?
Together with AS numbers? ;)

> Clearly, we need to rephrase it. We meant not just the RR part, but of course, having the IPv6 connectivity.

And - as per the draft - "Probing mechanisms to verify that the
relevant AAAA are fully operational MUST be setup by IANA. ". While
I'm sure many service owners would love to have a free monitoring
system run by IANA,  I'm not entirely convinced it's feasible.

> IPv6 free tunnels are available, in case, I doubt, you can't setup a tunnel to your upstream provider or alternatively to any of their upstreams. I've been there, several times, in the most strange…

I'm not entirely sure recommending tunnels is such a good idea...

> I think trying is much better than just complaining and not doing something. Clearly IETF liaison with ICANN need to take actions here.

As I described in my previous email, I believe that the proposed
actions are more likely to hurt v6 adoption than promote it.

> Believe it or not, there are still many DNS "operators" that have no idea about IPv6, and a call for action should enforce them to do something.

I do believe you indeed. I did measurements on overlap between signed
zones and v4-only names while ago.
If those operators have no idea about IPv6 they need to be educated.
Publishing a document explaining why not having AAAA in a signed zone
is not such a good idea and providing recommendations does sound as a
good idea.
Requesting something non-feasible and non-enforceable (and not clearly
defined) does not sound like a good idea to promote IPv6 deployments.