ietf
[Top] [All Lists]

Re: The point is to change it: Was: IPv4 depletion makes CNN

2010-06-10 22:04:52

In message <55562CF3CFC08C5C6DA3DD8F(_at_)PST(_dot_)JCK(_dot_)COM>, John C 
Klensin writes:


--On Friday, June 11, 2010 10:17 +1000 Mark Andrews
<marka(_at_)isc(_dot_)org> wrote:


In message <01NO5QT3QGKC00004S(_at_)mauve(_dot_)mrochek(_dot_)com>,
ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com 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.  

The provider only needs access to a dual stack name server.  I don't
know about other vendors but named can run IPv4 only or IPv6 only
and still access zones served only by servers using the the other
flavour of IP and has been able to do so for nearly a decade provided
it has access to a dual stack server somewhere on the internet which
will answer its queries.

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.

I said adapt, I didn't necessarially mean adapt well or the way
we would want them to adapt.
 
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.   

I'm thinking 10, 15+ years out when there are lots of IPv6 only
served zones.  Much the same way we no longer worry about MTA's
that don't know about MX records and no longer add A records
to accomodate them.
 
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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>