In message <55562CF3CFC08C5C6DA3DD8F@xxxxxxxxxxx>, John C Klensin writes: > > > --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. 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@xxxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf