FYI...MacOSX 10.7.4, Google and IPv6

[jleonguerrero]

Just sharing in case anyone else runs into this problem...

I switched from AT&T and discovered that Firefox and Safari could not access Google from my MacBook Pro laptop, running 10.7.4. Other sites were working.

It boiled down to this test, that showed I was getting an IPv6 address, when my line is only IPv4 capable.

Code: Select all

$ telnet www.google.com 80
Trying 2001:4860:4001:803::1014...
telnet: connect to address 2001:4860:4001:803::1014: No route to host
Trying 2001:4860:4001:803::1014...
telnet: connect to address 2001:4860:4001:803::1014: No route to host
Trying 2001:4860:4001:802::1011...
telnet: connect to address 2001:4860:4001:802::1011: No route to host
telnet: Unable to connect to remote host

I tried a number of tests and ultimately discovered that rebooting the Mac fixed the problem (I now get IPv4 addresses for Google). I'm not sure how the problem started, but I was not seeing the issue when I was on AT&T, nor when I was at work. I saw something about Google being aware that Sonic was IPv6 capable, so perhaps that was related to the problem, along with whatever my laptop was doing.

[Sam]

I hit the same problem—It's been on and off for months, and only for the google.com domain. gmail.com and google.co.[whatever] all seem to work.

As an alternative, if not ideal, fix, I switched from Sonic's DNS addresses to OpenDNS's.

[bobrk]

Weird, perhaps AT&T was using IPV6?

[jleonguerrero]

Actually, I had the problem again, so this time, I just turned off ipv6 on my Wi-Fi and it's working fine now.

For those that need the instructions, first get the list of devices with this:
networksetup -listallnetworkservices
Ethernet
Wi-Fi

Then turn off ipv6 using this:
networksetup -setv6off Wi-Fi

[jleonguerrero]

Well, this problem keeps coming back, even with ipv6 turned off on the MacOSX laptop. Rebooting is an ugly "solution", for many reasons. So I did what Guest Sam suggested and switched to the OpenDNS servers.

It would be great if someone at Sonic net could figure this out and offer a better solution. I suspect it's an ipv6 growing pain that someone at Sonic net would want to investigate and understand.

[bobrk]

I think Sonic is pretty clear about the fact that if you're using IPV6, you're on your own.

[kgc]

I think we'll need someone more familiar with OSX that I am to track this one down. From the description of the problem it sounds like under some circumstances some OSX machines without functional IPv6 decide out of the blue that they actually do, and start using the AAAA's for hosts that provide them. After that the problem is either that the record is now cached or that something is "stuck" in the tcp/ip stack both of which get cleared by rebooting.

Next time this happens to someone supplying the output of "ifconfig -a" and "netstat -rn" would be helpful to figure out what is going on.

[jon]

For Firefox, at least, a work-around might be to go to about:config and set "network.dns.disableIPv6" to true.
Don't know about Safari, though.