The capture is stored at: http://www.north-winds.org/unix/traceroute6.pcap
You did not include icmp packets like I suggested. Thus we cannot see what sort of icmp errors you get back in response to some of the 6in4 packets you send. However your pcap file did contain enough information for me to figure out why all your traceroutes are looking strange.
It is a bug or perhaps a poorly implemented feature in your tunnel endpoint. It will make any traceroute6 almost useless to you. The good news is, it doesn't break anything else.
What your tunnel endpoint does differently from most other 6in4 implementations is in the way it constructs the IPv4 header. It does not use a fixed TTL value in that IPv4 header, rather it copies the hop limit from the IPv6 header to the TTL value in the IPv4 header. Doing that could be a useful debugging feature, if a lot of other things were in place.
First of all your tunnel endpoint would have to make use of the ICMP time exceeded messages it gets back and turn those into corresponding ICMPv6 time exceeded messages for the encapsulated IPv6 packet. Additionally the HE tunnel server would have to not just remove the IPv4 header, but at that point replace the hop limit in the IPv6 header with the minimum of the hop limit in the IPv6 header and the TTL from the IPv4 header.
If both of the above were in place, then it would make sense for your tunnel endpoint to copy the hop limit to the TTL field. However none of the HE tunnel servers I have tested does what I describe, which means you are better off having your tunnel endpoint use a fixed value for the IPv4 TTL field.
The lack of ICMPv6 errors for those packets that exceed the IPv4 TTL field can be caused by a few different reasons:
- The IPv4 router did not send an ICMP error at all
- The IPv4 router send an ICMP error that was too short to contain the full IPv6 header
- Your tunnel endpoint just cannot convert them.
Since we are talking about seven different routers, and none of them produced a useful result, I guess it is probably because your tunnel endpoint cannot convert the responses.
However ultimately fixing that problem in your tunnel endpoint won't help you much unless HE changes the tunnel server as well, so in order to make traceroute useful, you would have to change the setup of your tunnel endpoint. Now we should probably get back to the original problem and see if we can debug that without needing traceroute.