On killing IPv6 transition mechanisms
jeroen at unfix.org
Tue Mar 16 13:20:28 CET 2010
Benedikt Stockebrand wrote:
> Hi Gert and list,
> I really tried to stay out of this thread, but since things are
> cooling down to a reasonable level again:
> Gert Doering <gert at space.net> writes:
>> I keep wondering about those 150ms. I seem to remember that Google saw
>> *few users* that had a much higher IPv6 latency - but at the same time
>> they also saw users with a *lower* latency via IPv6 (due to different
>> network paths being taken).
> As I understand it they pick who they actually advertise AAAA's to, so
> their numbers are statistically biased. What would be interesting to
> know was what the latency looked like if they provided AAAA's to
From what I understood the Google test was that they randomly inserted
over the base of 'everybody'. Google folks can of course confirm this
what they did exactly (afaik it is detailed in the presentations at RIPE
>> For me, the v4/v6 latency is very similar - I use v6 all day, many of
>> the sites I connect to (including google) have v6, and I do not see any
>> adverse effects (nor any positive effects - it's just IP, after all).
> Sensible content providers won't offer AAAA's unless they can provide
> decent connectivity on their side.
> The big problem here is on the customer end of the line.
Yep. Deploying IPv6 in the DC, getting peering etc is easy in most parts
of the world. (There are places where connectivity in general is
difficult, they will have it difficult with IPv6 too unfortunately).
Getting it to the end-user is the tricky part, but solvable given some
effort and some cash and some smart people.
> Since you are quite likely better connected
> than many other people I'd suspect that your experience is also
> significantly biased.
Having been around at least Europe and a bit of the US I have seen all
kinds of connections and from a European point of view most US
connections s.u.c.k..... heck even at a NANOG they where unable to
provide proper connectivity as it was heavily overloaded (I can only
assume that the fact that one of the main sponsors was providing free
IPv6 usenet access had to do something with it, or just plain
Points of view are always points of view. Thus one will always have a
bias of one sort or another.
> Do you get the same result when you connect to a statistically
> significant selection of IPv4-only ISPs using whatever 6to4 public
AFAIK in western-Europe 6to4&teredo are pretty well deployed and
generally just works, go outside of the stronger concentrations of IPv6
deployment, aka the places where people don't care enough yet and you
will start running into trouble though.
> On another track: Much of the discussion in this thread makes an
> implicit assumption that there's a single DNS name for both IPv4 and
> IPv6 services, i.e. "www.example.com." has both an A and a AAAA
> record. That's fine if have the resources to do the Google approach
> and only serve AAAA's to whitelisted clients. If you can't do that,
> then there's the alternative approach of using "www6.example.com." for
> AAAA's---that requires conscious action on the client side.
Google does that partially too: http://ipv6.google.com has been live for
quite a long time. A lot of folks also provide www.ipv4.XXXX +
www.ipv6.XXXX variants. The trick question is: why would people even
bother using those?
Generally folks don't type hostnames any more anyway, you google for
your query, click and presto.
> Doing so provides straightforward "workaround" by using the non-ipv6
> name, only attracts those users who intentionally use IPv6 and allows
> you to show off with your IPv6 service.
You will have a pretty low volume of users I think.
> As usual, this is way from a one-size-fits-all solution, but it may be
> an alternative approach worth some thought.
It is deployed, ask the big sites though how many people actually use
it, not too many I would assume.
> And finally, as far as some of the more heated part of the thread is
> concerned, please keep a few things in mind:
> - The "dumb unwashed masses" are those who actually fund most of the
> - Since they don't understand the difference between services they
> have a tendency to pick whatever they consider "best value"
> based on any criterium they think they understand---in our case
> that's usually bandwidth and money.
Actually the factor of warez/money for one very large group,
latency/money for the gaming group.
> - That doesn't stop them from complaining about bad service:-)
Depends on the type of user, if their download is low you'll get
complaints from group one, if their latency is high from group two.
I recall stories that AMS-IX NOC would get phone calls that the latency
of Quake was up....
For that matter, having in your userbase a couple of gamers who whine
about latency issues in the proper places can be one of the best active
monitoring you'll ever get ;)
> - With this pressure on, the profit margin is rather small, so the
> difference between gross income and net profit is extremely
> significant; losing an "insignificant" fraction of .1% of your gross
> income *very* *seriously* hurts your net profit.
> - First level support in this business is a very significant
> contributor to your overall costs.
Definitely, and training them to even understand that IPv6 exists will
be one of the bigger costs in deploying IPv6.
> - No matter if a problem is actually your fault or not, if your
> customer *perceives* it as your fault, you lose business.
> - When you have several million customers, "small" changes that
> involve some sort of cooperation turn into significant efforts---and
> if anything goes wrong and customers call your first level support
> this can quickly spell disaster.
> These points aren't only crucial to keep in mind if you do business
> with end users; they also apply to end user acceptance of IPv6 and as
> such the move towards IPv6.
Which is why companies that now suddenly realize that they need to do
IPv6 will have to spend more money in one go than a company that have
been playing with IPv6 already for ten years where everybody already has
a moderate understanding of the pitfalls etc.
For the folks who thus jump in now: You are too late! :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 196 bytes
Desc: OpenPGP digital signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100316/25dc2cf4/attachment.bin
More information about the ipv6-ops