On 30-mei-2007, at 13:23, Nathan Ward wrote:
I can't seem to reach www.ietf.org over IPv6 these days and I have to wait 10 seconds before I fall back to IPv4.
What browser are you using that falls back? Does it require hints (ie. unreachables, or similar) or does a timeout in TCP session establishment trigger it?
Both Safari and Firefox on the Mac. The delay is actually more than a minute for Firefox and about the same for Safari, though. Too long to wait for for most people, but I can't be bothered to find a workaround... I think what's going on is that packets from www.ietf.org don't make it back to my ISP. A ping6 or traceroute6 doesn't show any ICMP errors and TCP sessions don't connect so it's not a PMTUD problem. So it's an actual timeout. The IETF meetings have had IPv6 connectivity for years, but IPv6 for www.ietf.org is fairly new. Not so long ago, I couldn't connect to www.ietf.org from the meeting network over IPv6 because the /48 that the web server was hosted in was filtered by the ISP providing the meeting IPv6 transit. In that case, an unreachable was returned and there was no delay.
how many calls to your help desk will it take until your helpdesk staff says "turn off IPv6"?
Not many. That's why we need to proceed with caution. But there is still time, making rash decisions based on the current situation would be a mistake. The IPv6 internet and applications grow more mature every year.
The ball is in the ISP/NSP court at the moment.
No, not really. End-users can get IPv6 connectivity without support from their ISP, and Windows Vista will result in a big bump in IPv6- active users. The next step that we need is more IPv6 content to flush out problems like the one I'm having and make it such that those don't persist like they sometimes do now.
Here's why, which is really a really really brief summary of how I've read this thread, and my thoughts as it's progressed.
a) Vista and other systems try IPv6. If they think they can get IPv6 they'll (often) prefer AAAA records to A records.
Note that the latter only applies to "real" IPv6 connectivity. With 6to4 or Teredo, Windows will generally prefer IPv4.
b) If (a) happens, and the endpoint referred to by the AAAA record isn't reachable, then the eyeball can't reach the content. Service is degraded. c) Because of (b), content providers aren't going to turn on AAAA records.
They aren't going to turn on AAAA records because they're not reachable over IPv6. :-)
So, it seems to me that the unreachable mentioned in (b) needs to be fixed. That's us, as network operators.
Note that these are exceptions. The only remarkable part is that they aren't fixed as quickly as the same problems are when they happen with IPv4. Iljitsch