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