In my case it is not DNS-related.

True. I noticed that much, when I read your post the first time. However since I didn't have anything to add to what you already found out yourself, I didn't reply at the time. You could write to ipv6@he.net and ask if there is some reason for the length of that path. I guess a roundtrip time of 67ms just isn't considered to be long enough to really be a concern.

If Google and HE are peering in both locations it is difficult for an outsider to find out who chooses which of the peering points will be used. It is also possible that the traffic takes different paths in the two directions. A traceroute will only reveal the forward path, and the timings on the traceroute will include both forward and return path with no way to know, how much time was used in each direction. It is even possible, that the different hops you see on the traceroute will take different return paths.

PING: transmit failed. General failure.

Sounds like your computer does not have any IPv6 address. I guess this means either that the router is not advertising itself as an IPv6 router on the LAN, or IPv6 is disabled on the computer. Check the local network tab in the router configuration.

I did receive some pings on 2001:470:28:940:f015:4a71:c958:1ffd. They came from a gogo6 address, I suppose that was somebody else.

the netsh protocols that HE provide I assume only apply if making the tunnel from the computer not from the router. correct?

Assuming those are commands to setup the tunnel, then it is correct, that they only apply if the computer is the tunnel endpoint.

When using a router as the tunnel endpoint, then you obviously need to configure the tunnel on the router. You may still need to enable IPv6 on the computer. There may exist systems, where enabling IPv6 can be done with a simple netsh command.

MY address is 99.18.173.230.

I can get no packets through to that IP. Traceroute ends at 12.122.103.113. That is true for both ordinary traceroute as well as protocol 41 packets.

Could you try this from your end: traceroute -P 41 209.51.181.2

Server IPV4 Address :        216.66.80.26
Routed /64:                      2001:470:1f09:b4b::/64

Tunnel was only set up recently.

Could you try temporarily setting your tunnel server as 80.167.222.169 and then try to ping 2001:470:28:940:f015:4a71:c958:1ffd. That way we can see if you can even get protocol 41 packets out.

99.XXX.173.230

How are we supposed to help you, with only that information?

99.13.173.230 is rejecting protocol 41 packets with ICMP port unreachable. Usually that means the receiving tunnel endpoint has been configured to only allow incoming packets from a specific source IPv4 address. I can see how such filtering makes sense, if the packets would be forwarded onto the IPv6 backbone. But if they are just being delivered to the LAN, I know of no harm done by allowing arbitrary source IPv4 addresses in the header, which is going to be removed anyway. The possibility of filtering legitimate packets is however a real concern.

99.245.173.230 is accepting the protocol 41 packets, but after decapsulation it applies filtering rules to the IPv6 packets. It is rejecting the packets with type=1, code=1. Also, it is using a spurious source IP address on the ICMPv6 errors. Those are sent with source ::99.245.173.230. This is a known behaviour of some 6rd implementations.

99.232.173.230 is forwarding protocol 41 packets to 192.168.1.104 on the LAN, but no host on the LAN is responding to ARP requests for that IP address.

Is packet forwarding enabled? Try

Code:

head /proc/sys/net/ipv6/conf/*/forwarding

Do you have any firwall rules, which may be blocking the packets? Try

Code:

ip6tables-save

What command did you use to create the tunnel. Did you get the server IPv4 address right?
Does the server know the correct IPv4 address of your tunnel endpoint?
Is there any NAT between your tunnel endpoint and the server, which could mess up the connection?
If you run a tcpdump on the physical interface while trying to ping the server IPv6 address, what do you see?

Someone said I should be using 6in4 vice 6to4.

I know how 6in4 works, and I know how 6to4 works. Of those two, I recommend 6in4, because it is more reliable. But a setup with both and choosing between the two intelligently, would be even more reliable.

Using 6to4 alone with no other IPv6 connectivity will work reliable as long as both endpoints are using 6to4 and has it configured correctly. As soon as a 6to4 user is communicating with somebody using native IPv6, it will be unreliable. So using 6to4 alone really can't be recommended.

Unfortunately your router appears to not have any decent tunnelling support. Those screenshots you posted shows no support for anything other than 6to4. That means you are not going to have that router use HE or any other tunnel broker unless you replace the firmware.

You can configure it with 6to4, but in that case you need to switch the relay router setting back to auto (which is equivalent to static address 192.88.99.1). In that configuration you will only get a good experience if your software (browser etc.) can fall back to IPv4 in a split second, if IPv6 is slow or broken. And yes, it literally has to fall back in a split second. If it takes a full second to fall back, the Internet connection will feel very slow at some sites.

I have a test page, that you can try to see how your 6to4 connectivity is working: http://ipv4.test-ipv6.netiter.dk/ (Sorry I haven't gotten around to translate it to English yet, but observing how many of the tiles in the picture loads give a very visual indication of the connectivity.)

might switch to opendns for the time being then

Given opendns' history of hijacking some requests by handing out their own IP address instead of the correct IP address for the domain, I wouldn't consider them. How about using the HE anycast DNS address as your primary DNS server, I think geolocation is done correctly for the HE DNS servers.

I did a bit more digging into the problem. The problem is not only with google.co.uk. I could reproduce the problem with google.com as well. Moreover I found that there was only a problem if I send requests to Google Public DNS over IPv6. If I did it over IPv4, I got a proper address back.

I tried from my laptop through two different tunnel brokers and 6to4. I also tried over native IPv6 from my VPS. I could only reproduce the problem through the HE tunnel. That means either the HE tunnel is reaching a different instance of Google Public DNS, or they are doing geolocation based on client IP. My guess was that it was based on client IP.

To verify this I needed to query DNS using different client addresses, but in a way that uses the same network path from my computer to the DNS server. Due to ingress filtering, that is not trivial to do. But I happen to know a trick that allows me to send IPv6 packets through my ISP with arbitrary source address. (This works in spite of this ISP not even offering IPv6 yet). That way I was able to send queries to the same DNS server with different source addresses.

I found that the DNS server I reached would only give me an IP address in Sydney, if my client address was from the HE range. So Google appears to be doing the geolocation based on client IP rather than proximity to the DNS server.

I don't know if the geolocation as Sydney applies to all HE addresses or only some of them. For now we know that users of the London and Frankfurt tunnel servers are affected. This problem is BTW completely unrelated to the problem, which was being asked at the start of this thread. That question remains unanswered.

Using google public DNS

It is pretty messed up, if Google can't keep track of where in the world their own DNS servers are.

When both the recursors and the authoritative DNS servers are operated by Google, they can take advantage of that in order to have more data to use in the geolocation. In that case they could actually base it on both the client IPv6 address and the location of the DNS recursor.

Since Google Public DNS is using anycast IP addresses, it is almost guaranteed, that clients will be using a DNS recursor close to themselves. Thus which DNS server you are using would be a more reliable indication of your location than your IP address (because the later relies on the accuracy of the geolocation database).

I managed to reproduce the problem myself. This is sufficiently messed up, that I'll try to email one of my contacts at Google directly. Hopefully that way we can find out, what is going on.

any ideas?

My first guess is you got something wrong in the configuration. If you post a screenshot of the configuration, we can probably figure it out.

I am seeing a very high latency to google also, I am in the UK and connected to London tunnel server but I believe that Google is geo-locating by the IPv6 address and sending us to a US server

Reverse DNS on the IP sounds like Sydney.

Also, notice that this has nothing to do with geolocation of any IPv6 address. Until Google gets full IPv6 support, they cannot direct you to a server based on IPv6 geolocation.

Your problem is, that you are using a DNS server, which Google thinks is in Sydney. Try using another DNS server.

[7]

The IP that I'm seen at has been 71.89.156.145 in the past but right now it's 71.89.156.147.

For the record, I did a traceroute to each of those IPs, and this is what I saw.

Code:

traceroute to 71.89.156.145 (71.89.156.145), 30 hops max, 60 byte packets
 1  10.9.255.254  8.338 ms  8.348 ms  8.407 ms
 2  212.10.10.1  8.459 ms  8.497 ms  12.154 ms
 3  194.255.53.29  12.896 ms  13.315 ms  13.768 ms
 4  * * 213.248.66.146  15.683 ms
 5  213.248.66.145  15.450 ms  15.416 ms  15.411 ms
 6  80.91.253.244  14.855 ms 80.91.254.222  10.816 ms 213.155.130.96  11.165 ms
 7  80.91.254.89  96.838 ms 213.155.134.52  107.497 ms 213.248.64.22  97.596 ms
 8  213.155.136.19  127.407 ms 80.91.249.110  126.429 ms 80.91.246.166  126.696 ms
 9  62.115.14.42  133.588 ms  132.438 ms  132.122 ms
10  96.34.0.98  140.557 ms  140.514 ms  140.040 ms
11  96.34.2.11  137.133 ms  137.272 ms  134.050 ms
12  96.34.36.16  144.003 ms  134.582 ms  135.368 ms
13  96.34.34.9  141.022 ms  140.383 ms  134.445 ms
14  96.34.38.165  134.256 ms  138.718 ms  134.275 ms
15  96.34.33.134  130.251 ms  130.719 ms  131.677 ms
16  96.34.32.185  136.249 ms 96.34.32.181  131.499 ms *

Code:

traceroute to 71.89.156.147 (71.89.156.147), 30 hops max, 60 byte packets
 1  10.9.255.254  7.836 ms  12.008 ms  12.600 ms
 2  212.10.10.1  12.660 ms  12.759 ms  12.783 ms
 3  194.255.53.29  12.935 ms  13.573 ms  14.112 ms
 4  * * *
 5  213.248.66.145  15.036 ms  15.485 ms  15.469 ms
 6  213.155.130.96  15.433 ms  11.022 ms 213.155.135.182  10.534 ms
 7  213.155.134.52  106.029 ms 80.91.254.89  95.195 ms 213.155.134.50  98.141 ms
 8  80.91.249.110  126.350 ms 80.91.246.164  128.110 ms  127.092 ms
 9  213.248.104.198  139.108 ms  137.691 ms 62.115.14.42  127.828 ms
10  96.34.0.98  131.669 ms  132.149 ms  140.643 ms
11  96.34.2.11  133.231 ms  132.057 ms  132.390 ms
12  96.34.32.26  144.327 ms  143.692 ms  142.343 ms
13  96.34.32.99  129.364 ms  139.045 ms  134.630 ms
14  96.34.32.55  140.475 ms  135.006 ms  146.366 ms
15  96.34.32.186  134.191 ms  135.972 ms  135.143 ms
16  96.34.32.181  134.722 ms 96.34.32.185  162.567 ms  155.093 ms
17  71.89.156.147  134.538 ms  135.427 ms  137.000 ms

One could try to figure out a bit more about the network from this. But whatever we make from these, it won't change your situation.

unfortunately I'm under contract for a year

Is the contract binding, if they cannot deliver the service, you signed up for? If they called the product an Internet connection, I would say an IP address is part of the service you were promised, unless the conditions didn't clearly stated otherwise.

A reasonable minimum to expect today is either one public IPv4 address, or NATed IPv4 access plus a static routed IPv6 prefix.

Before you try to get out of the contract, you should of course ensure that you can get better service somewhere else. If you consider switching to another ISP, ask the new ISP about what addresses they will give you.

It might even be that your current ISP fixes the problem once you call them. Giving NATed access by default and a public address to anybody who ask for it would make sense for an ISP, as that would probably reduce their usage of IP addresses significantly. If they additionally give only one public address to those who ask for one, but multiple local addresses to those going through carrier grade NAT, then those who don't ask for a public address don't have to buy their own router.

I'll try SixXS.  I actually still have a tunnel through them, though I disabled it when I moved to HE.  My main issue with them was that the setup was quite a bit more difficult than HE's.

Supporting different protocols will of course add to the complexity. Though it could be setting up SixXS access is more complicated than it needed to be.

Please update this thread and let us know how it turns out, both with your ISP and with SixXS configuration, if you give it a try.

Options are:
Disabled
Autodetect
6to4
Passthrough
Fixed
DHCP
PPPoE
AutoConfig

None of them sound promising. But I am not sure what all of them mean, so maybe something useful is hidden on one of them. You could post a screenshot of the configuration page for each of them, so we can see if there is anything useful.