curl -6 http://www.google.com hangs today. Normally that works.
Seeing that working successfully via tunnels to all tunnel servers.
Any changes on your side, firewall rules, MTU, etc.? What's the IP address it's trying to connect to, since Google operates clusters world-wide, it's possible you're resolving to one which our tests aren't.
I have exactly the same problem. It suddenly stopped working without changing anything on my configuration. When doing
wget -6 https://www.google.com
Wireshark shows me "TCP Previous segment not captured". It tries to connect to 2a00:1450:4005:800::1014. The following works fine
ping6 -s 1424 2a00:1450:4005:800::1014
Using a ping package size of 1425 doesn't work.
I'm using Linux kernel 3.13 from Ubuntu 14.04 and configured the tunnel via /etc/network/interfaces as given by the example configurations without the "local" option.
The tunnel MTU is 1480 but i tried other MTUs and it didn't work either.
I'm experiencing similar issues since yesterday (tserv10.par1). Some sites work (www.bsc.es (http://www.bsc.es)), others (ipv6-test.com,https://www.youtube.com,https://www.google.com) don't. In fact, I cannot even reach hurricane electric forums (https://forums.he.net) or he.net unless I disable ipv6 in my network adapter, although every url is pingable
I can also confirm that
ping6 2a00:1450:4005:800::1014 hangs if -s >1232
ping6 -s 1232 2a00:1450:4005:800::1014
PING6(1280=40+8+1232 bytes) 2001:470:1f13:130a:614d:7833:5c3b:6c18 --> 2a00:1450:4005:800::1014
1240 bytes from 2a00:1450:4005:800::1014, icmp_seq=0 hlim=53 time=49.470 ms
1240 bytes from 2a00:1450:4005:800::1014, icmp_seq=1 hlim=53 time=48.019 ms
^C
--- 2a00:1450:4005:800::1014 ping6 statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 48.019/48.745/49.470/0.725 ms
ping6 -s 1233 2a00:1450:4005:800::1014
PING6(1281=40+8+1233 bytes) 2001:470:1f13:130a:614d:7833:5c3b:6c18 --> 2a00:1450:4005:800::1014
<---------HANGS
I can confirm I've started seeing the same issue (started on Friday).
I'm using the NYC tunnel endpoint. My actual ISP is optimum/cablevision
The largest ping I can send is 1432 data bytes. Anything higher gets no response.
$ ping6 www.google.com -n -s 1432
PING www.google.com(2607:f8b0:400d:c06::67) 1432 data bytes
72 bytes from 2607:f8b0:400d:c06::67: icmp_seq=1 ttl=55 (truncated)
72 bytes from 2607:f8b0:400d:c06::67: icmp_seq=2 ttl=55 (truncated)
^C
--- www.google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1292ms
rtt min/avg/max/mdev = 26.856/27.142/27.428/0.286 ms
$ ping6 www.google.com -n -s 1433
PING www.google.com(2607:f8b0:400d:c06::67) 1433 data bytes
^C
--- www.google.com ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1500ms
I also started seeing this on Friday. I am using tserv3.fmt2. No changes on my side to cause this. As a part of research to the cause of the problem, I brought up a sixxs tunnel and a gogo6 tunnel. Both of those appear to be having the same issue, so I believe this might not be tserv3.fmt2, but could be inside google somewhere. The issue is that about three out of five links, include the safebrowsing links in firefox, seem to be "hanging". I see a syn and very slow packet flow. I wonder if google has a data center down as both google and youtube keep wanting to point to 2607:f8b0:4000::/44. The catch is that I disabled IPv6 and it would also appear to be carrying over to IPv4. I am going to do some traveling later today to see if it is duplicated elsewhere. I am seeing some intermittent routing issues with 2001:470:0:31::2, however, I am fairly certain that is not related to this issue, so not posting in this thread. I suspect the issue is a router deep inside the google/youtube network.
I don't think these issues are related to he.net. My tunnel is via fmt2. I observed some ssl errors to docs.google.com this morning. Something about a tls version downgrade causing secure connection to fail. I noticed some others reporting similar issues on an afmug forum post. This afmug post indicates that person had native IPv6 connectivity. Evidence seems to indicate this issue is either inside Google, or close to it.
https://www.mail-archive.com/af@afmug.com/msg10847.html
athena:~ pcurtis$ ping6 -c 5 -s 1220 gmail.com
PING6(1268=40+8+1220 bytes) 2001:470:1f07:533:b523:acdb:6446:c638 --> 2607:f8b0:4006:80b::1016
1228 bytes from 2607:f8b0:4006:80b::1016, icmp_seq=0 hlim=58 time=7.862 ms
1228 bytes from 2607:f8b0:4006:80b::1016, icmp_seq=1 hlim=58 time=7.674 ms
1228 bytes from 2607:f8b0:4006:80b::1016, icmp_seq=2 hlim=58 time=10.072 ms
1228 bytes from 2607:f8b0:4006:80b::1016, icmp_seq=3 hlim=58 time=40.224 ms
1228 bytes from 2607:f8b0:4006:80b::1016, icmp_seq=4 hlim=58 time=10.128 ms
--- gmail.com ping6 statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 7.674/15.192/40.224/12.560 ms
athena:~ pcurtis$ ping6 -c 5 -s 1240 gmail.com
PING6(1288=40+8+1240 bytes) 2001:470:1f07:533:b523:acdb:6446:c638 --> 2607:f8b0:4006:808::1016
1248 bytes from 2607:f8b0:4006:808::1016, icmp_seq=0 hlim=58 time=9.960 ms
--- gmail.com ping6 statistics ---
5 packets transmitted, 1 packets received, 80.0% packet loss
round-trip min/avg/max/std-dev = 9.960/9.960/9.960/0.000 ms
it seems that other tunnel brokers have the same problem
https://www.sixxs.net/forum/?msg=general-13022233
Confirming the same problem here, connected to .tserv4.nyc4.
This happened friday night, then got a bit better on Saturday, and just started happening again a couple hours ago. Adjusted my MTU in the meantime, hopefully it'll be fixed soon.
Someone in #ipv6 has opened a ticket, as well as this is making it onto ipv6-ops again. Oh Google, Y U break it for sub-1500 mtu users?
not seen the post with gogo6 yet, but that maybe because they are in canada, so get a different IP than in the 2607:f8b0:4000::/40 range. My DNS didn't move much. Over over IPv4 dns, google tries to force me to 2607:f8b0:4000:/48. Over Sixxs, google tries to force me to 2607:f8b0:4000:/48. Over gogo6, google tries to force me to 2607:f8b0:4009:/48. Over HE tunnel, google tries to force me to 2607:f8b0:4010:/48. I have found that 74.125.239.0/24 and 74.125.25.0/24 work great.
Name: youtube-ui.l.google.com
Addresses: 2607:f8b0:4000:80b::2000
74.125.239.39
Aliases: www.youtube.com
As further proof that this is not a tunnel specific issue, I forced my IP to be 2001:4860:4001:10::17 by creating the following dns zones and it works.
youtube.com. 300 IN SOA localhost. me.localhost. 2004020117 10800 3600 604800 86400
172800 IN NS localhost.
172800 IN AAAA 2001:4860:4001:10::17
* 172800 IN AAAA 2001:4860:4001:10::17
google.com. 300 IN SOA localhost. me.localhost. 2004020117 10800 3600 604800 86400
172800 IN NS localhost.
172800 IN AAAA 2001:4860:4001:10::17
* 172800 IN AAAA 2001:4860:4001:10::17
So, all issues still points to 2607:f8b0:4000::/40. When pointing to 2001:4860::/32, no issues found.
Just want to add that I've had this problem since Friday as well. I use the Toronto tunnelbroker. Mostly google that seems broken, although google is embedded in so much of the web that it seemed like half the internet was dead. It also appeared some non-google hosts were unresponsive (ie. CDN addresses.)
Here's another "me too" report. Since this weekend, anything Google related is intermittently unaccessible through IPv6 (HE Amsterdam endpoint here), no matter what type of connection. Ruled out DNS issue by entering the IPv6 address.
Seeing reports on several websites:
- Dutch IT forum gathering.tweakers.net
- http://forums.whirlpool.net.au/forum-replies.cfm?t=2360847
- http://www.dslreports.com/forum/r29799531-DSL-IPv6-Google-connection-hanging
- http://www.gossamer-threads.com/lists/nsp/ipv6/53248
The guess is that Google screwed up mtu / "icmpv6 packet too big" (again), although dropping the mtu from 1480 to 1280 didn't solve the problem here.
Lowering my ethernet adapter MTU to 1280 on OSX did the trick, and now I can reach google and youtube over ipv6 again
(http://s30.postimg.org/p0tgb1qxp/mtu1280.jpg) (http://postimg.org/image/p0tgb1qxp/)
(http://s17.postimg.org/r4rhf3v0r/youtubeipv6.jpg) (http://postimg.org/image/r4rhf3v0r/)
. I hope google's team fixes this issue asap :-[
I am not sure the MTU is the problem on all data centers. I see you have 2a00:1450:4000::/40, which that range works for me when I use a hosts file. I also have a few other ranges that work for me. I did a search for the google ipv6 hosts file from years ago and found some such as https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0CCQQFjAB&url=http%3A%2F%2Fcode.google.com%2Fp%2Fipv6-hosts%2Fissues%2FattachmentText%3Fid%3D171%26aid%3D1710002001%26name%3DHost%2BFile%2528small%2529.txt%26token%3D9I1bwXv4-w0qtlXh2gNlw1X-BJ4%253A1325270539024&ei=xnO9VLfHOIWB8gXQpoLACw&usg=AFQjCNGzLfgvvu3dySWHohdac34NukvBaQ (https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0CCQQFjAB&url=http%3A%2F%2Fcode.google.com%2Fp%2Fipv6-hosts%2Fissues%2FattachmentText%3Fid%3D171%26aid%3D1710002001%26name%3DHost%2BFile%2528small%2529.txt%26token%3D9I1bwXv4-w0qtlXh2gNlw1X-BJ4%253A1325270539024&ei=xnO9VLfHOIWB8gXQpoLACw&usg=AFQjCNGzLfgvvu3dySWHohdac34NukvBaQ)[/img] and it solved my problem with a MTU of both 1280 and 1480. I sure wish google would fix their network, or else point their CDN buggy DNS to another working data center.
Working Google ranges:
2a00:1450:4000::/40
2404:6800:4000::/40
2800:3f0:4000::/40
2001:4860::/32
Not so working google ranges:
2607:f8b0:4000::/40
EDIT: of course, I only grabbed the youtube.com, gstatic.com, googleapis.com, and google.com domains from that host file to put into mine.
The irritating issue is that because a the first packet comes back, happy eyeballs does not attempt IPv4. Probably something we all need to keep in mind as even dual stack hosts can appear IPv6 only on situations like this.
an FYI to all, it appears to be fixed. I am not sure how or when, but I routing packets to 2607:f8b0:4000::/40 just fine. I have yanked my hosts file and all appears to be good. Can someone else verify?
Seems to be fixed here as well with the tunnel MTU set to 1480.
Fixed here as well!
It appears that the issue might be back again. Issue is mostly intermittent.
>ping google.com
Pinging google.com [2607:f8b0:4000:80b::2000] from 2001:470:8747:1705:5403:aa13:
ae6a:96fa with 32 bytes of data:
Reply from 2607:f8b0:4000:80b::2000: time=104ms
Reply from 2607:f8b0:4000:80b::2000: time=105ms
Reply from 2607:f8b0:4000:80b::2000: time=106ms
Reply from 2607:f8b0:4000:80b::2000: time=106ms
Ping statistics for 2607:f8b0:4000:80b::2000:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 104ms, Maximum = 106ms, Average = 105ms
>ping -l 1440 google.com
Pinging google.com [2607:f8b0:4000:80b::2000] from 2001:470:8747:1705:5403:aa13:
ae6a:96fa with 1440 bytes of data:
General failure.
Ping statistics for 2607:f8b0:4000:80b::2000:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),
Control-C
^C
>ping -l 1340 google.com
Pinging google.com [2607:f8b0:4000:80b::2000] from 2001:470:8747:1705:5403:aa13:
ae6a:96fa with 1340 bytes of data:
Reply from 2607:f8b0:4000:80b::2000: time=185ms
Reply from 2607:f8b0:4000:80b::2000: time=165ms
Ping statistics for 2607:f8b0:4000:80b::2000:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 165ms, Maximum = 185ms, Average = 175ms
Control-C
^C
>