I thought the Paris tunnel server was down again this morning but after a bit of troubleshooting it seems to be a routing issue. If I traceroute from my workstation I get this far:
C:\tracert www.google.com
Tracing route to www.google.com [2607:f8b0:4005:80a::2004]
over a maximum of 30 hops:
1 1 ms 2 ms 1 ms 2001:xxx:xxxx:xxxx::xx
2 <1 ms <1 ms <1 ms 2001:xxx:xxxx:xxxx::xx
3 20 ms 19 ms 19 ms tunnel151330.tunnel.tserv10.par1.ipv6.he.net [2001:470:1f12:ac6::1]
4 16 ms 16 ms 18 ms e0-1.core1.par1.he.net [2001:470:0:7b::1]
5 19 ms 24 ms 46 ms 10ge7-6.core1.par2.he.net [2001:470:0:1b0::2]
6 15 ms 15 ms 15 ms google.equinix-ix.fr [2001:7f8:43::1:5169:1]
7 15 ms 16 ms 15 ms 2001:4860:0:1015::10
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
Nothing after that. It seems 2001:4860:0:1015::10 is a Google address so maybe an issue within Google?
And it's back working...
Glad to see your issue is resolved. However, note: A failing traceroute can also occur when someone is blocking ICMP packets and/or their replies. When traceroutes fail, they should be tested with both UDP packets and ICMP echo packets, with both failing. Even so, direct connections (via TCP, e.g.) sometimes still work.
Note also that many admins limit or firewall drop ICMP echo packets at destination hosts. I do drop them, except I have a list of IP addresses (v4 and v6) which may ping and receive replies (my own network ranges and some friends). ICMP packets should never be dropped by routers, but some admins do that also (whether intentional or by misconfiguration).