IPv6 day non-participants
georgeb at gmail.com
Thu Jun 9 14:21:12 CDT 2011
> IMHO, it's worse than that. Most sites only added a AAAA record for
> their website, and frequently didn't for their DNS server. So they
> weren't *really* doing a complete IPv6 test, IMHO.
There is a reason for that. First of all, we (my employer) took this
as a brief test to simply see how much IPv6 traffic there really was,
and who and what would actually attempt to reach us by IPv6. The idea
here being to attempt to identify IPv6 native networks.
We had to do this in a way that did not break our existing IPv4
services. We run some services that we do not consider "breakable"
and our user profile is much different than a web site is. We might
have millions of clients on a network that are, for the most part,
identically configured. So for example, if one users device believes
it has IPv6 but doesn't *really* have IPv6 (as a link local IP so it
believes it has IPv6 or has IPv6 inside its network but not clean to
the Internet), then there are probably tens of thousands of
identically configured devices in that customer's network. So we
don't face the "some small fraction of one percent are broken"
problem, we face a "if one is broken, then a significant portion of
and possibly all of that customer's devices are broken".
If we put IPv6 DNS records in place that caused 100,000 clients to
break, we would have some serious explaining to do. In this case, a
very safe approach was to place an IPv6 address for our web site in
DNS. None of our "business" traffic goes to our website. In the
course of IPv6 day for the roughly 18 hours it was operating, we might
have had 200 hits on IPv6 compared to thousands of transactions per
second on our "business" protocols.
The test did, however, expose a bug in a piece of vendor gear that was
catastrophic to the business service. The entire piece of gear blew
up that handles the business traffic in addition to the web traffic.
It rebooted itself but apparently did not boot cleanly. This was bad
enough but it was rather quickly placed back into service (manual
kick) and happened at the slowest traffic time of the day and few/no
clients would have noticed. Had we also experienced customer
complaints of slow/poor/no service during the time of the test, it
would have been pretty bad.
So enabling IPv6 DNS had the potential to cause global problems and
not limited to a single data center, it could have had global impact
to the domain. Placing a single IPv6 DNS glue record and DNS server
in service would have also potentially resulted in local DNS servers
from around the globe that might prefer IPv6 attempting to reach that
one DNS server. In other words, it would have created a potential
single point of failure and possibly degraded performance. So the IPv6
DNS infrastructure is being rolled out in a planned, methodical
fashion. Dropping an AAAA record for the web site was an easy thing
to do that was considered very low risk (as we assumed all of our
other gear could simply pass IPv6 packets without exploding) and
offered some participation with the community.
(speaking for himself)
More information about the NANOG