[140331] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Yahoo and IPv6

daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon May 9 23:35:49 2011

From: Owen DeLong <owen@delong.com>
In-Reply-To: <6628BD73-CCC3-4173-8A07-8693E813CE2D@kumari.net>
Date: Mon, 9 May 2011 20:31:07 -0700
To: Warren Kumari <warren@kumari.net>
Cc: "nanog@nanog.org" <nanog@nanog.org>, Arie Vayner <ariev@vayner.net>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org


On May 9, 2011, at 7:15 PM, Warren Kumari wrote:

>=20
> On May 9, 2011, at 9:14 PM, Owen DeLong wrote:
>=20
>>=20
>> On May 9, 2011, at 9:25 AM, Valdis.Kletnieks@vt.edu wrote:
>>=20
>>> On Mon, 09 May 2011 18:16:20 +0300, Arie Vayner said:
>>>> Actually, I have just noticed a slightly more disturbing thing on =
the Yahoo
>>>> IPv6 help page...
>>>>=20
>>>> I have IPv6 connectivity through a HE tunnel, and I can reach IPv6 =
services
>>>> (the only issue is that my ISP's DNS is not IPv6 enabled), but I =
tried to
>>>> run the "Start IPv6 Test" tool at =
http://help.yahoo.com/l/us/yahoo/ipv6/ and
>>>> it says:
>>>> "We detected an issue with your IPv6 configuration. On World IPv6 =
Day, you
>>>> will have issues reaching Yahoo!, as well as your other favorite =
web sites.
>>>=20
>>> The *really* depressing part is that it says the same thing for me, =
on a *known*
>>> working IPv6 network.
>>>=20
>> FWIW, it is happy with my connection and consistently reports =
positive results.
>>=20
>> I'm running my own addresses through HE tunnels and tunnels
>> to Layer42.
>>=20
>> The tunnels ride over Comcast and Raw Bandwidth DSL.
>=20
>=20
> Yup -- while not perfect, the Yahoo! testing has been working well for =
me.
>=20
> Yahoo has to tread a very careful line between giving too little and =
too much information --  I have tried walking a few non-technical folk =
through troubleshooting their v6 connectivity by phone and it is really =
very hard to do, and that is interactively. Writing something that =
someone can download, print and then follow is nigh impossible. No =
matter how well this guide is written, a number of folk will manage to =
screw it up, and of *course* that will be Yahoo's fault....
>=20
Gathering a list of IPv6 resources that people could refer to and =
publishing them
would be better than saying "Meh, turn it off."

Saying "It's broken, you should work with your ISP to correct the =
problem. A technical detailed
description of what went wrong is available <here>(should be a link)." =
would be preferable.

There are lots of better options that don't require Yahoo to actually do =
more than they are
doing now.

> Jason's page at http://test-ipv6.com/ gives way way more information =
(and the page at http://ipv6-test.com/ also gives some more), both of =
these pages are much too complex for the average user.
>=20
True... I'm not saying Yahoo should go that way. I'm just taking issue =
with the idea of them
suggesting users turn off IPv6 as a preferred alternative over fixing =
it.

Owen

> W
>>=20
>>> And then when I retry it a few minutes later, with a tcpdump =
running, it works.
>>>=20
>>> And then another try says it failed, though tcpdump shows it seems =
to work.
>>>=20
>>> For what it's worth, the attempted download  file is:
>>>=20
>>> % wget http://v6test.yahoo.com/eng/test/eye-test.png
>>> --2011-05-09 11:44:39--  =
http://v6test.yahoo.com/eng/test/eye-test.png
>>> Resolving v6test.yahoo.com... 2001:4998:f00d:1fe::2000, =
2001:4998:f00d:1fe::2002, 2001:4998:f00d:1fe::2003, ...
>>> Connecting to v6test.yahoo.com|2001:4998:f00d:1fe::2000|:80... =
connected.
>>> HTTP request sent, awaiting response... 200 OK
>>> Length: unspecified [image/png]
>>> Saving to: `eye-test.png.1'
>>>=20
>>>  [ <=3D>                                   ] 2,086       --.-K/s   =
in 0s     =20
>>>=20
>>> 2011-05-09 11:44:39 (154 MB/s) - `eye-test.png.1' saved [2086]
>>>=20
>>> Looking at the Javascript that drives the test, it appears the =
*real* problem
>>> is that they set a 3 second timeout on the download - which =
basically means
>>> that if you have to retransmit either the DNS query or the TCP SYN, =
you're
>>> dead as far as the test is concerned.
>>=20
>> Well, if you're having to retransmit those intermittently, then, it =
does seem you
>> have some level of brokenness with your network, no?
>>=20
>> Owen
>>=20
>>=20



home help back first fref pref prev next nref lref last post