test-ipv6.com

Fri Jan 28 01:25:49 UTC 2011

In message <alpine.BSF.2.00.1101271623320.15852 at goat.gigo.com>, Jason Fesler wr
ites:
> > Note you can have totally broken IPv6 connectivity and still be
> > fine on World IPv6 day.  You just need applications with good
> > multi-homing support.
> 
> Agreed so far.
> 
> > No web site can check this for you.
> 
> Hmm. What's wrong with asking the browser to try a dual-stack url today, 
> as a proxy for what will happen to said web browser on June 8?

There is nothing wrong with that.  Just remember you are only testing
a single application.

> The concern with World IPv6 day is with the users who have IPv6 enable, 
> and have a default route - yet have broken IPv6 connectivity.  This 
> specific population will see timeouts on June 8.

Yes.  Their *applications* are broken.  Application should continue
to work well even in the presence of network breakage to one of the
address to the site it is connecting to.

Nameservers have been doing this for decades with sub second timeouts.

> > If you are a application developer and want TCP example code that
> > will work well with a broken IPv6 connection have a look at my blog.
> 
> Hopefully browsers will adopt your idea (or Happy Eyeballs).
> It may be the only remedy available, short of content providers
> collectively moving forward with dual stack, 0.05% broken users be damned.

Moving forward and be damned is a good idea provide you have enough
content providers take the step at the same time.  Your breakage will
initially be 0.05 but when BING, Yahoo and Google etc. are all slow you
will start to ask yourself why is the network slow.  I would expext a
measurable improvement over 24 hours especially if the websites also
put up hints for how to fix the problems.

> http://tools.ietf.org/html/draft-wing-v6ops-happy-eyeballs-ipv6-01
> 
> I'm personally not a big fan of either method, as that's going to increase 
> the amount of tcp sessions to my web servers.  It is merely less bad than 
> the alternative.

Unless the client is coming in over a congested link or a very long
rtt path you are unlikely to see any additional tcp sessions.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org