All Google properties unreachable on IPv6

[Guest]

Hello,

This morning I discovered that Google, YouTube, GMail, you name it, would either load extremely slowly or not at all. This problem has persisted all day.

Turning off IPv6 on my computer resolves all issues. IPv4 ping, IPv4 traceroute, and IPv6 ping all look normal... IPv6 traceroute just gives "* * *" everywhere.

This is my DNS result, for what it's worth...

Code: Select all

~$ dig google.com AAAA +short
2607:f8b0:4010:801::1008

I'm sort of at a loss as to what the problem could be...

[dkenglish7]

Still seeing this behavior today.

[nsmiller]

It has been spotty for me, ever since "Patch Tuesday". I have not begun unloading the MS updates. At one point, two days ago, it was everything Google on all browsers. Now it is only YouTube, and only Opera 26. Ping and tracert always work, and "Is it everyone, or only me" type sites say it is only me.

Tracing route to youtube-ui.l.google.com [2607:f8b0:4010:801::1008]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 1000-0000-0000-0000-09d7-04ed-a420-2062.6rd.ip6.sonic.net [2602:24a:de40:7d90::1]
2 22 ms 21 ms 21 ms cust-gw.ipv6.sonic.net [2602:24b:8179:10::1]
3 21 ms 23 ms 22 ms 201.ge-6-1-1.gw.equinix-sj.sonic.net [2001:5a8:5:e::1]
4 23 ms 21 ms 22 ms 0.xe-7-0-0.gw.pao1.sonic.net [2001:5a8:5:3::2]
5 23 ms 22 ms 23 ms 2001:550:2:3a::9:1
6 23 ms 24 ms 23 ms be2013.ccr21.sjc03.atlas.cogentco.com [2001:550:0:9a36:569]
7 22 ms 22 ms 22 ms 2001:550:2:1f::46:2
8 25 ms 31 ms 23 ms 2001:4860::1:0:21
9 23 ms 23 ms 23 ms 2001:4860:0:1::3d5
10 24 ms 24 ms 22 ms nuq04s19-in-x08.1e100.net [2607:f8b0:4010:801::1008]

Trace complete.

Google is slow, though; and this site hangs for a couple of seconds waiting for 'apis.google.com'.

[davidstrauss]

We also saw this on 20 January 2015 on our office network.

[kentjulia]

Hi all,

I have been experiencing this issue for at least six months now. When I first started experiencing it, I was an AT&T U-Verse customer. Their technical support was never able to resolves the issue, despite multiple calls over the months. I switched to Sonic's FTTN service, but was dismayed to discover that AT&T still handles the Internet traffic up to a point.

This issue seems like it's on AT&T's end because once I switch to using my phone's cellular connection to connect to the Internet, the issue instantly goes away. If I switch back to Sonic, the same performance issues persist.

It's incredibly frustrating because I work from home several days a week and depend on Google Drive to deliver/receive files from clients. Drive's connection will timeout more often than not, which makes downloading and uploading multiple gigabyte files beyond nerve-racking. Even Google Search will timeout about half the times when I try to use it, not to mention YouTube, Google Maps, etc...

I contacted Sonic's support about it and he basically threw up his arms saying that there is nothing he can do. He said that they have no way of reporting support issues to AT&T, which doesn't seem like a very good relationship to me. At this point, I don't know what to do. I wish Sonic would step up and force AT&T to address this issue. Otherwise, I'm stuck with awful Google service for another 11 months until my Sonic contract expires when I could switch to another ISP.

I'm out here in Livermore, FWIW.

Ben

[dherr]

Why not disable IPv6?

[kentjulia]

Holy smokes, that did the trick! Sorry, my bad for not reading through this thread carefully. I didn't realize that IPv6 was definitively the cause of this issue, but apparently it is. I was having similar issues with Facebook, but those appear to be resolved as well. So far, so good.

I've been wrestling with this for several months now. Thanks a ton for helping to resolve this issue!

Ben

[toast0]

If you're on FTTN (u-verse), using att 6rd, the MTU seems to need adjustment, especially with the NV589 and doing 6rd on your own box with the gateway in 'ip passthrough' mode. For whatever reason, the ipv6 mtu needs to be 1472 instead of the expected 1480, and the att 6rd gateway is rate limiting path mtu icmp, so things kind of work a bit, but quickly fall apart. (FWIW, I setup a he.net tunnel, and it works fine at mtu 1480 via u-verse... so it must be something inside the depths of att)