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-boun...@ietf.org> en nombre de Joe Abley
<jab...@hopcount.ca>
Responder a: <jab...@hopcount.ca>
Fecha: domingo, 26 de noviembre de 2017, 0:47
Para: Fred Baker <fredbaker.i...@gmail.com>
CC: "v6...@ietf.org WG" <v6...@ietf.org>, <6...@ietf.org>, Daniel Karrenberg
<dan...@karrenberg.net>, <dn...@ietf.org>, <sunset4@ietf.org>, JORDI PALET
MARTINEZ <jordi.pa...@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.i...@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.
_______________________________________________
sunset4 mailing list
sunset4@ietf.org
https://www.ietf.org/mailman/listinfo/sunset4
