Subject: [sunset4] FW: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 24 Nov 2017 21:36:11 +0100

Hi,

I’ve posted “Towards a Worldwide IPv6-Ready DNS Infrastructure”

https://datatracker.ietf.org/doc/draft-palet-sunset4-ipv6-ready-dns/

I believe this is covered by the charter of sunset4, however, it is very relevant as well for a recent discussion in 6man and v6ops and of course, it is relevant as well to dnsop.

I will love to get some inputs. I order to avoid unnecessary noise in several mail exploders, I will suggest responding only in sunset4.

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]>
Responder a: <[email-masked]>
Fecha: viernes, 24 de noviembre de 2017, 21:30
Para: Jordi Palet Martinez <[email-masked]>, Jordi Martinez <[email-masked]>
Asunto: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt

    A new version of I-D, draft-palet-sunset4-ipv6-ready-dns-00.txt
    has been successfully submitted by Jordi Palet Martinez and posted to the
    IETF repository.
    
    Name:		draft-palet-sunset4-ipv6-ready-dns
    Revision:	00
    Title:		Towards a Worldwide IPv6-Ready DNS Infrastructure
    Document date:	2017-11-23
    Group:		Individual Submission
    Pages:		4
    URL:            https://www.ietf.org/internet-drafts/draft-palet-sunset4-ipv6-ready-dns-00.txt
    Status:         https://datatracker.ietf.org/doc/draft-palet-sunset4-ipv6-ready-dns/
    Htmlized:       https://tools.ietf.org/html/draft-palet-sunset4-ipv6-ready-dns-00
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-palet-sunset4-ipv6-ready-dns-00

    Abstract:
       This document defines the timing for implementing an IPv6-Ready
       global DNS infrastructure, worldwide, in order to allow the global
       IPv6-only deployment.

    
    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: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 24 Nov 2017 21:47:33 +0100

By the way, forgot to mention something else.

I’ve started also to work in a policy proposal for ICANN in order to make sure that we get aligned.

Regards,
Jordi

-----Mensaje original-----
De: JORDI PALET MARTINEZ <[email-masked]>
Fecha: viernes, 24 de noviembre de 2017, 21:36
Para: <[email-masked]>
CC: <[email-masked]>, <[email-masked]>, <[email-masked]>
Asunto: FW: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt

    Hi,

    

    Regards,
    Jordi

    -----Mensaje original-----
    De: <[email-masked]>
    Responder a: <[email-masked]>
    Fecha: viernes, 24 de noviembre de 2017, 21:30
    Para: Jordi Palet Martinez <[email-masked]>, Jordi Martinez <[email-masked]>
    Asunto: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt

        Abstract:

        
        
        The IETF Secretariat

---

From: Bob Harold <[email-masked]>
Date: Fri, 24 Nov 2017 22:00:54 -0500

On Fri, Nov 24, 2017 at 3:36 PM, JORDI PALET MARTINEZ <
[email-masked]> wrote:

> I believe this is covered by the charter of sunset4, however, it is very
> relevant as well for a recent discussion in 6man and v6ops and of course,
> it is relevant as well to dnsop.
>
> I will love to get some inputs. I order to avoid unnecessary noise in
> several mail exploders, I will suggest responding only in sunset4.
>
> Regards,
> Jordi
>
>
>
> Para: Jordi Palet Martinez <[email-masked]>, Jordi
> Martinez <[email-masked]>
>     URL:            https://www.ietf.org/internet-
> drafts/draft-palet-sunset4-ipv6-ready-dns-00.txt
>     Htmlized:       https://datatracker.ietf.org/
> doc/html/draft-palet-sunset4-ipv6-ready-dns-00
>
>
>     Abstract:
As much as I would like to see the transition happen,
Realistically, IPv4 will continue to 'work', for a large number of users,
for a very long time.
If you multiply your times by 10 (or more) and work hard, you might be
successful in phasing out most of IPv4 in DNS.
But forcing users to change seems like a bad idea.

I note issues like:
- Cloud providers (Amazon, Google, Azure?) only provide a private IPv4
address to virtual machines.  They use NAT to get an IPv6 address for
incoming traffic.  I don't know of any way to do IPv6 outgoing.  (I could
be wrong, still learning here.)
- Android does not support DHCPv6.
- DNS64 breaks DNSSEC.
- There are probably a large number of legacy hardware devices and software
programs that do not support IPv6, but will still be running 10 or 20 years
from now.
I expect there are many more, but those come to mind.

-- 
Bob Harold

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 25 Nov 2017 09:22:56 +0100

Hi Bob,

The lack of DHCPv6 doesn’t present a problem for the transition or IPv6 support, in fact is in cellular networks where IPv6 is more predominant.

For DNS64, you will see in my document this is one of the reasons for calling to this action.

In the “DNS world” I doubt there are legacy “servers” or “devices” that don’t support IPv6. If a “DNS” provider or a “hosting provider” or “cloud provider” is unable to do IPv6 in two years from now, do all the rest of the citizens need to pay the cost of upgrading his network or only their own customers?

Do we want that those services stay as IPv4 for 10 years? Or Maybe 20 or 40 if we don’t take an action to let them know that the Internet services need to be IPv6-Ready ?

Please note that I fully agree that at every office, every home, there are IPv4 devices or apps that will never work with IPv4, and actually I don’t care about that (even I wish is not the case). If the servers where those devices need to access are IPv6-Ready, then 464XLAT/NAT64 will work without breaking DNSSEC, so we bypass that problem.

Regards,
Jordi

    
    Realistically, IPv4 will continue to 'work', for a large number of users, for a very long time.
    If you multiply your times by 10 (or more) and work hard, you might be successful in phasing out most of IPv4 in DNS.
    But forcing users to change seems like a bad idea.

    I note issues like:
    - Cloud providers (Amazon, Google, Azure?) only provide a private IPv4 address to virtual machines.  They use NAT to get an IPv6 address for incoming traffic.  I don't know of any way to do IPv6 outgoing.  (I could be wrong, still learning here.)
    
    - Android does not support DHCPv6.
    - DNS64 breaks DNSSEC.
    - There are probably a large number of legacy hardware devices and software programs that do not support IPv6, but will still be running 10 or 20 years from now.

    -- 
    
    Bob Harold

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

---

From: Fred Baker <[email-masked]>
Date: Sat, 25 Nov 2017 11:00:19 -0800

> On Nov 24, 2017, at 12:47 PM, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 

One thing you might want to think about: the root servers are all IPv6-capable today and serve requests using IPv6, and the 1541 TLDs are all required by contract with ICANN to be IPv6-capable. I think you'll find yourself holding the burden of proof that the infrastructure isn't capable of IPv6-only operation today.

RSO statistics are available from http://www.root-servers.org/. ICANN TLDs are at https://data.iana.org/TLD/tlds-alpha-by-domain.txt.

Reading through your draft, what I see that is probably not present today is an IPv6 address for every SLD, which is to say names like "example.com".

What might be worth your while (I copy Daniel because he did a similar study using RIPE Atlas not too long ago and can point you to relevant documentation on how to do one yourself) would be to set up a RIPE Atlas study that accesses the Root, ccTLD, and gTLD authoritative servers using their IPv6 addresses and reports on the status of that from a wide variety of locations.

---

From: Joe Abley <[email-masked]>
Date: Sat, 25 Nov 2017 18:45:52 -0500

Hi Fred,

[I haven't read Jordi's draft; I'm just responding to what I've read in this thread.]

> One thing you might want to think about: the root servers are all IPv6-capable today and serve requests using IPv6, and the 1541 TLDs are all required by contract with ICANN to be IPv6-capable. I t…

monster:~]% egrep -c '^[A-Z]' /usr/share/misc/iso3166 
249
[monster:~]% 

There are potentially 249 TLDs that are not operated under any such contract with ICANN, although I agree that the majority of ccTLDs have at least one nameserver that is v6-capable (maybe all, but I haven't checked and I wouldn't want to assume).

The important clients for all of these authoritative servers from the perspective of end-users are resolvers. I think it's uncontroversial to suggest without citation that not all resolvers used by end-users today are v6-capable, or downstream from a resolver that is v6-capable. So we are not ready to turn off v4 today unless significant collateral damage is considered acceptable (and surely it's not).

This is a relatively small problem to solve, though (note use of "relatively"). I think it would actually be practical to announce a sunset for v4 on gTLD and root servers at some suitable target date in the not too distant future, the implementation of which could be mainly handled within the root zone itself.

Aside from the techno-political v6-deployment motivations, I think there would be good engineering reasons to sunset v4 in root and TLD servers.

Such a move would open the door to the complete removal of v4 transport from all of those servers which would eliminate them as viable amplifiers in attacks against v4 targets. It would also provide greater motivation to deal with any unreliability in v6 operations in the DNS or connecting networks, fragmentation-related transport issues, etc which will surely otherwise see minimal attention so long as working v4 transport masks v6 problems.

Joe

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 26 Nov 2017 10:06:36 +0100

(keeping the discussion in sunset4, as I believe is where it belongs to)

Hi Fred,

Thanks a lot for reading and providing input!

I know the root servers are IPv6 enables since many years ago, however, in my document I want to “reinforce it”, because I don’t think there is any IETF document that mandates it, so at this way we ensure that IPv6 support is not “dropped” in a root in the future (looks silly, but just in case). Also at this way if there is such document, we have a “single on” that include all the DNS levels.

I tried to find an ICANN document that states it before writing the draft, but google didn’t helped. Right now, doing some new searches, I found this:

https://www.icann.org/resources/pages/ipv6-initiative-2017-02-28-en

So, it looks like only the ccTLDcan opt-out that rule, which is very sad … However, if we make it happen in a couple of years for all but a few ccTLDs, that’s a great success. Even more, ccTLDs frequently have copies among themselves, so for example .es, .cl, .fr, which are IPv6 enabled, may backup .sv which is not (is just an example, not saying this is the case, but lots of them do this way).

Regarding SLD, I actually say it … I didn’t want to say SLDs, 3LDs, and so on, because they may be many extra levels, and I wanted to cover all the with a more simpler terminology (I think many folks don't know SLD or 3LD), but they know “anything that has an A record …” so I used “Other A RRs, MUST be IPv6-Ready in 24 months”, and before that I spell out “IPv6-Ready” as 

“IPv6-Ready DNS Infrastructure" means that a DNS
   server (root, TLD, authoritative NS) is fully accessible and
operational if queried from a remote dual-stack and IPv6-only
   network.

   In general, that means having AAAA RRs in addition to A RRs, ensuring
   that PMTUD works correctly and fragmentation is correctly handled.

   In case DNSSEC is implemented with IPv4, it MUST support also
   IPv6-only operation according the below defined timing.”

I guess that if you didn’t get that in my ID, I need to do some clarification in the text …

I’m an ATLAS ambassador and I’ve about 100 million credits, so I guess it will be easy to use them for this very interesting measurement, we just need to restart those measurements and if needed readjust what it was done before, to make sure that works in an IPv6-only environment, and checks as I mention in the draft not just the availability and reachability of AAAA, but also PMTUD/fragmentation, and I will say in both TCP and UDP. I also think that the community and/or RIPE NCC will be happy to provide more credits/resources for something like this if needed.

Regards,
Jordi

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 26 Nov 2017 10:20:40 +0100

Hi Joe,

As I just mention, it is pity that the ccTLDs can opt-out that policy.

What I don’t think is that, if the gTLDs have such requirement in the contract, they are actually enforcing it?

Do you have pointers to relevant documents to understand what are the exact requirements and why is not being enforced?

My perspective is that end-users, in their LANs, will have IPv4 for a while, but the access may turn into IPv6-only sooner. End-users have devices such as IP cameras and many others, that cost money, and they will not be sent to the trash can in several years (5-10 years?). So even if the resolvers aren’t IPv6-capable, is not an issue, but want we need to avoid is the situation of having a service in Internet which is NOT-IPv6 enabled and breaks (example breaks DNSSEC) using the transition mechanism required for having an IPv6-only access but IPv4 support in the LAN (for example 464XLAT with NAT64). The same solution I’m proposing, actually helps to have IPv6-only LANs, of course, so in the way to a complete IPv6-only Internet.

I think including in my ID a sunset for IPv4 in root and TLDs (again even if ccTLDs can opt-out), is interesting and definitively will be an extra “push” in the right direction. I will include that in a new version.

I think we can have something like this:

1.  Root and TLDs MUST be IPv6-Ready in 6 months.

2.  Authoritative NS MUST be IPv6-Ready in 12 months.

3. Root and TLDs MUST drop IPv4 support in 15 months.

4.  DNSSEC authoritative MUST be IPv6-Ready in 18 months.

5.  Other A RRs, MUST be IPv6-Ready in 24 months.

6.  Other RRs, MUST be IPv6-Ready in 30 months.

If you don’t mind, I will steal your technical motivations in my text, I didn’t considered initially in my document extending too much in the “technical” reasons, but it looks like a better way to justify the need for this additional step.

Regards,
Jordi

-----Mensaje original-----
De: sunset4 <[email-masked]> en nombre de Joe Abley <[email-masked]>
Responder a: <[email-masked]>
Fecha: domingo, 26 de noviembre de 2017, 0:47
Para: Fred Baker <[email-masked]>
CC: "[email-masked] WG" <[email-masked]>, <[email-masked]>, Daniel Karrenberg <[email-masked]>, <[email-masked]>, <[email-masked]>, JORDI PALET MARTINEZ <[email-masked]>
Asunto: Re: [sunset4] [DNSOP] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt

    Hi Fred,

    

    

    

    Joe

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 27 Nov 2017 10:43:59 +0100

On Fri, Nov 24, 2017 at 09:36:11PM +0100,
 JORDI PALET MARTINEZ <[email-masked]> wrote 

> https://datatracker.ietf.org/doc/draft-palet-sunset4-ipv6-ready-dns/

Besides the good remarks on ccTLDs that you already had (management of
ccTLDs is not ICANN's business), a few remarks:

> In general, that means having AAAA RRs in addition to A RRs,
> ensuring that PMTUD works correctly and fragmentation is correctly
> handled.

The problem is that it is not entirely in the hands of the manager of
the DNS authoritative server: the problem may be on the client
side. And it is hard for the sysadmin of an authoritative DNS server
to know if his clients received the fragments.

>   1.  Root and TLDs MUST be IPv6-Ready in 6 months.

The ICANN root is IPv6-ready for a long time. Otherwise, the
experience of Yeti draft-song-yeti-testbed-experience might be useful.

>   2.  Authoritative NS MUST be IPv6-Ready in 12 months.

At every level in the DNS tree? Noble goal but which seems completely
unrealistic. How will you convince Joe User, who manages the NS for
foo.bar.example.com to act?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 27 Nov 2017 10:46:08 +0100

On Fri, Nov 24, 2017 at 10:00:54PM -0500,
 Bob Harold <[email-masked]> wrote 

> - DNS64 breaks DNSSEC.

That's not a fair summary. People should read RFC 6147 and 7050
before repeating this.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 27 Nov 2017 10:50:23 +0100

On Sat, Nov 25, 2017 at 06:45:52PM -0500,
 Joe Abley <[email-masked]> wrote 
 a message of 28 lines which said:

> I think it's uncontroversial to suggest without citation that not
> all resolvers used by end-users today are v6-capable,

See this experience
<https://labs.ripe.net/Members/stephane_bortzmeyer/how-many-ripe-atlas-probes-can-resolve-ipv6-only-domain-names>.
It was three years ago, we can re-run it but I'm afraid it will show
that it is still the case.

Quote: "As expected, the success rate with IPv6-only domain names
(around two thirds) is much lower than with "mixed" domain names. We
are not yet ready to switch off IPv4 . If you serve a domain name only
on IPv6 name servers, you will get less traffic (and probably less
spam, too)."

---

From: Tony Finch <[email-masked]>
Date: Mon, 27 Nov 2017 12:28:16 +0000

Joe Abley <[email-masked]> wrote:
>
> There are potentially 249 TLDs that are not operated under any such
> contract with ICANN, although I agree that the majority of ccTLDs have
> at least one nameserver that is v6-capable (maybe all, but I haven't
> checked and I wouldn't want to assume).

Quick root zone stats:

zones 1542
servers 4216

Most servers are dual-stacked; 539 are v4-only, and 2 are v6-only
(j.zdnscloud.com and i.zdnscloud.com).

The 31 TLDs with no v6 nameservers:

ai.
bb.
bh.
ck.
dj.
fk.
gf.
hm.
kp.
mh.
mil.
mp.
mq.
mv.
ni.
pf.
pk.
sl.
sr.
st.
to.
uz.
ws.
xn--l1acc.
xn--lgbbat1ad8j.
xn--mgba3a4f16a.
xn--mgbai9azgqp6j.
xn--wgbh1c.
xn--ygbi2ammx.
ye.
zw.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Biscay, Fitzroy: Variable 3 or 4 until later in south, otherwise westerly 5 or
6, veering northwesterly 4 or 5, except in south Fitzroy, becoming
northeasterly 5 or 6 in southeast Fitzroy. Slight at first in south, ohterwise
moderate or rough. Rain or squally showers. Moderate or good.

---

From: Gert Doering <[email-masked]>
Date: Mon, 27 Nov 2017 18:58:46 +0100

Hi,

> The 31 TLDs with no v6 nameservers:
[..]

> mil.

Yay.  Like, IPv6 mandate, and all that.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Mark Andrews <[email-masked]>
Date: Tue, 28 Nov 2017 09:29:51 +1100

DNS64 requires EVERY validating client to support DNS64 prefix discover and
implement DNS64.  If that isn’t breaks DNSSEC I don’t know what is.

> On 27 Nov 2017, at 8:46 pm, Stephane Bortzmeyer <[email-masked]> wrote:
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]