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

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 <sunset4-bounces@ietf.org> en nombre de Joe Abley <jabley@hopcount.ca>
Responder a: <jabley@hopcount.ca>
Fecha: domingo, 26 de noviembre de 2017, 0:47
Para: Fred Baker <fredbaker.ietf@gmail.com>
CC: "v6ops@ietf.org WG" <v6ops@ietf.org>, <6man@ietf.org>, Daniel Karrenberg <daniel@karrenberg.net>, <dnsop@ietf.org>, <sunset4@ietf.org>, JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
Asunto: Re: [sunset4] [DNSOP] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt

    Hi Fred,

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

    On Nov 25, 2017, at 14:00, Fred Baker <fredbaker.ietf@gmail.com> 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.

    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
    _______________________________________________
    sunset4 mailing list
    sunset4@ietf.org
    https://www.ietf.org/mailman/listinfo/sunset4

**********************************************
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.