Yahoo and IPv6

No, it isn't. The transport is failing if you are having to retransmit more than once in a blue
moon. Yes, retransmission helps overcome such failures in the transport, but, that does
not mean that the transport isn't broken.

Owen

Actually, I have just noticed a slightly more disturbing thing on the Yahoo
IPv6 help page...

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 World IPv6 Launch 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.

The *really* depressing part is that it says the same thing for me, on a *known*
working IPv6 network.

FWIW, it is happy with my connection and consistently reports positive results.

I'm running my own addresses through HE tunnels and tunnels
to Layer42.

The tunnels ride over Comcast and Raw Bandwidth DSL.

Yup -- while not perfect, the Yahoo! testing has been working well for me.

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

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.

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

:: Given the following posting from earlier this morning:
::
:: > The location that's affecting the results is pending removal from DNS;
:: > and ASAP we hope to have the name moved to the geo-LB that suppors v6,
:: > instead of the round robin it is today.
::
:: I feel pretty damned justified in saying it wasn't *my* network causing the retransmits.
::
:: (Oh - and kudos for the person quoted above for 'fessing up, and to the people
:: that tracked down the actual issue. That always sucks when the test rig itself
:: has issues. Glad to hear it will be fixed)

In the spirit of full disclosure, I'll "fess up" a little more then :slight_smile: We
did have the cname for the help pages point to an old rotation, something
that is getting rectified, and the timeout in the javascript was a tad too
aggressive (would lead to some unwanted false negatives), so that timeout
is going to be up'ed to between 5 and 10 seconds (we are measuring a few
different things, so which value will be used will depend on what is being
measured where).

Thank you for catching this -- we are still working on finishing up the
monitoring component of flag day related content :slight_smile:

-igor

Igor,

When testing, you should take into consideration that people from all across
the world may use this tool, and in some places speed is not the same as in
other places... Latency... Bad linkes... Etc.

Arie

Weird as I also use the HE tunnel and the yahoo report for me was clean.

Tom

And I was just sent this link from our very own NSA: http://www.nsa.gov/ia/_files/factsheets/macosx_10_6_hardeningtips.pdf

Disable IPv6 and AirPort when Not Needed
Open the Network pane in System Preferences. For every
network interface listed:
� If it is an AirPort interface but AirPort is not required,
click "Turn AirPort off."
� Click "Advanced." Click on the TCP/IP tab and set
"Configure IPv6:" to "Off" if not needed. If it is an
AirPort interface, click on the AirPort tab and enable
"Disconnect when logging out."

Matthew Kaufman

Proving that the NSA is behind the times like any other government institution. No real surprise.

Owen

Going to http://help.yahoo.com/l/us/yahoo/ipv6/ and hitting "Start IPv6 Test" I get:
"Your system will continue to work for you on World IPv6 day. However, we found that your server only supports IPv4 at this time. You'll simply continue to use IPv4 to reach your favorite web sites."

Netalyzr (http://n3.netalyzr.icsi.berkeley.edu/analysis) finds no issues with my IPv6 status, but alerts me to the fact (since confirmed by switching to IE) that Google Chrome defaults to IPv4 rather than IPv6, and consequently a lot of the testing tools claim that my IPv6 is broken.

Toivo Voll
Network Administrator
Information Technology Communications
University of South Florida

Interesting - must be a windows issue, Google Chrome on Linux works fine at
http://help.yahoo.com/l/us/yahoo/ipv6/

I'm a little confused there - the current Chrome prefers IPv6, and also now includes code to allow fast failover to IPv4 in the event IPv6 connectivity is down/slow (300ms headstart).

I had some issues with Netalyzer detecting my dual-stack status, which the chaps there are helping with.

Tim

Netalyzer is Java-based, thus it uses the Java stack and not the
Javascript/ECMAScript stack that Chrome provides. As such it just
bypasses all of that and the coolest thing is that you might not even
have an IPv6-capable Java stack for your host.

The 1.6.0_25-b06 Oracle/Sun version on Windows that I have here seems to
do IPv6 just fine btw in combination with Netalyzr.

Apparently in my home case I have a slow DNS lookup (odd, never had
issues with that, maybe it has to do with me having to click 'accept' on
the windows firewall UI :wink:

8<-----------------------------------------------
It takes 239 ms for your computer to fetch a response from our test
server using IPv6, while it takes 7289 ms for the same host to fetch a
response using IPv4 from the same server.
----------------------------------------------->8

Definitely has to do with clicking 'ok' on the firewall button :wink:

Greets,
Jeroen

Disable the firewall and try again or all results are worthless.

On the other hand, if you have a firewall you need to disable in order
for it to get valid IPv6 results, you don't actually have a working IPv6
configuration, do you?

Disable the firewall and try again or all results are worthless.

That is quite what I noted, the thing is that apparently the delay for
clicking 'ok' is taken into account for the measurements :wink:

On the other hand, if you have a firewall you need to disable in order
for it to get valid IPv6 results, you don't actually have a working IPv6
configuration, do you?

The standard Windows Firewall on XP asks the user if it is okay if a
program, in this case java, is allowed to open a listen socket.

This is common for quite a few firewall tools out there, and the moment
you have hit okay, all is fine.

On Win7 one can even enable the same question for outbound requests, one
of the few things that is actually missing in XP IMHO.

But all of that is not really operational....

Greets,
Jeroen

> On the other hand, if you have a firewall you need to disable in order
> for it to get valid IPv6 results, you don't actually have a working IPv6
> configuration, do you?

The standard Windows Firewall on XP asks the user if it is okay if a
program, in this case java, is allowed to open a listen socket.

That's reconfiguring the firewall, not disabling it entirely...

But all of that is not really operational....

Your help desk will probably say it's an operation issue for them this time
next week. :wink: