On killing IPv6 transition mechanisms

Benedikt Stockebrand me at benedikt-stockebrand.de
Tue Mar 16 13:01:38 CET 2010

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

> 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.  Since you are quite likely better connected
than many other people I'd suspect that your experience is also
significantly biased.

Do you get the same result when you connect to a statistically
significant selection of IPv4-only ISPs using whatever 6to4 public

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.

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.

As usual, this is way from a one-size-fits-all solution, but it may be
an alternative approach worth some thought.

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.

- That doesn't stop them from complaining about bad service:-)

- 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.

- 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.



			 Business Grade IPv6
		    Consulting, Training, Projects

Dipl. Inform.                 Tel.:  +49 (0) 69 - 247 512 362
Benedikt Stockebrand          Mobil: +49 (0) 177 - 41 73 985           
Fichardstr. 38                Mail:  me at benedikt-stockebrand.de        
D-60322 Frankfurt am Main     WWW:   http://www.benedikt-stockebrand.de/

Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen
Umfragen.  Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet.  
No spam, no unsolicited sales calls, no telephone surveys, please. Calls
may be recorded for legal purposes.

More information about the ipv6-ops mailing list