--On Friday, June 11, 2010 10:17 +1000 Mark Andrews
<marka@xxxxxxx> wrote:
>
> In message <01NO5QT3QGKC00004S@xxxxxxxxxxxxxxxxx>,
> ned+ietf@xxxxxxxxxxxxxxxxx w rites:
>> If this is accurate, I think you need to go back and reread
>> John Klensin's recent messages for why this scenario really
>> isn't all that likely to unfold the way you think.
>>
>> Ned
>
> Turn off the root servers IPv4 address and see how fast people
> adapt. :-)
Mark,
I hate to say this, but that is silly, smiley or not.
Because this may be an example of some of the "force a
transition" ideas that are going around, let's examine what
would happen if it were done. This analysis more or less
applies to any "cut off some service to force folks onto IPv6"
strategy and is hence worth examining even if we understand that
cutting off the IPv4 root servers is not realistic.
The typical users of the Internet don't use the root servers
directly at all. They use, exclusively, some full-service
forwarder(s) that might interact with the root servers. Those
forwarders belong to ISPs, enterprises, etc., and the lusers
think they have contracts for services with those entities. So,
now, some major piece of infrastructure that, from the user's
perspective is a critical resource covered by the service is
converted to IPv6-only or otherwise made unavailable. What
happens next is pretty obvious: the provider copes or sees happy
paying customers swap themselves out and their lawyers in.
Using the root servers as an example, "provider copes" would
most naturally take one of two forms:
(1) Provider sets up an IPv6 server that is capable of
serving out the root zone (from a cache and and queries
as needed) to the forwarders who keep serving the users
with IPv4 DNS. Net effect on IPv6 deployment: just
about zero. Net effect on the DNS: very low or zero.
(2) Provider adjusts the local configuration file for the
location of the root zone to point to someone who will serve out
a root zone in IPv4. Note "a root zone" rather than "the root
zone". I hope I don't have to explain the difference to anyone
reading this list, but I'm sure I don't have to explain it to
you. Net effect on IPv6 deployment: zero or worse because even
more credibility will have been lost (for IPv6 and the
intelligence of various institutions). Net effect on the DNS:
significant and really bad... multiple roots or dubious (or at
least variable) authority. DNSSec basically has to be turned
off to make that work.
In addition for both scenarios, we have some experience with
such things for other reasons and in an earlier era. If the
infrastructure that supports those alternate roots or shadow
roots isn't as good as the infrastructure which they have come
to expect from the normal root servers, the ISPs and other
operators of major forwarders have tremendous incentives to
refresh at lower frequency than called for in SOA records and to
disable or reinterpret TTL timeouts of data. For the root
zone, that was pretty much ok around 1995 because data
volatility was very low. But, in a world in which ICANN is
contemplating thousands of separate delegations from the root
zone, volatility goes up and basing responses on slow-update
alternate roots or non-authoritative and potentially very stale
data... well, you don't cause a lot more IPv6 deployment, but
you certainly damage the quality of DNS-based identifiers.
Again, I saw the smiley so assume that you know the above. But
the point is that there are similar scenarios, with similar
outcomes, for almost every model for creating a forcing function
for IPv6 based on artificially shutting down IPv4 services.
> Seriously, I do think it is time that the root and TLD's had
> IPv6 only name servers. I'm not advocating IPv4 be turned off
> on them yet.
If "yet" points to any time prior to the point at which IPv6 is
universally deployed, then the above comments apply to the DNS
and root servers.
It may be useful to remind ourselves again that getting TCP/IPv4
"universally deployed" in an NCP-based network required a flag
day and a credible threat to disconnect any host that was still
running NCP at the point. Neither the flag day nor the threat
has plausible analogies in today's Internet.
john
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf