A couple of weeks ago we had a strange problem in the CACE Technologies World Domination Secret Lair. Loris was having trouble loading the Wireshark blog. It was working fine on my machine so I checked some of the other machines in the office. I found the same problem on one of the development machines. Loading the page in Firebug showed that the object requests were stalling out every 20 seconds or so:
I fired up Wireshark and captured the browser attempting to connect to the blog:
The problem was immediately obvious. The browser attempted to connect to the blog’s IPv6 address (2607:f0d0:2001:e:1::1), timed out, and connected to the blog’s IPv4 address (67.228.110.126).
As it turns out Loris and I ran some IPv6 tests a long time ago and we added unique local addresses to our machines (mine was fd00:cace::4) . Since each machine had an IPv6 address the TCP stack assumed that there was general IPv6 connectivity. However, our ISP is steadfastly ignoring IPv6 so end-to-end connectivity wasn’t there. After timing out the connection fell back to IPv4 and proceeded normally.
This sort of thing will likely crop up more and more often as we transition to IPv6. If either IPv4 or IPv6 connectivity fails, your applications will still have connectivity so the failure may not be immediately obvious. In this case Firefox stalled out but still managed to connect. If it used a connect-by-name socket API the failure wouldn’t have been evident at all.
Comments 🔗
Comment by siyu on 2010-01-28 17:58:55 +0000 🔗
thanks a lot.