|
tracerouting does not work
![[fr]](/s/countries/fr.gif) Shadow Hawkins on Thursday, 06 January 2011 11:01:50
Hello,
When I try to use traceroute6, with my IPv6 tunnel, I get no reply from the first hosts:
$ traceroute6 -n www.kame.net
traceroute to www.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7), 30 hops max, 40 byte packets
1 2a01:240:fe87:1::1 0.399 ms 0.437 ms 0.534 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 2001:200:0:10::141 321.668 ms 323.240 ms 325.707 ms
12 2001:200:0:11::66 332.556 ms 333.586 ms 315.989 ms
13 2001:200:0:1c0a:218:8bff:fe43:d1d0 319.762 ms 320.268 ms 319.516 ms
14 2001:200:dff:fff1:216:3eff:feb1:44d7 309.530 ms 309.540 ms 310.520 ms
Hence, even the remote end of the tunnel does not sent the expected "time exceeded" replies.
On the other hand, when I try to trace the route from outside to my tunneled subnet, for example using http://lg.he.net/, all the hosts seem to answer as expected, including both tunnel endpoints (mine and the remote one)...
Any idea why tracerouting does not work for me, while it works fine from outside?
Note that I checked my IPv6 routes, and they really go through the tunnel. Also note, in case it matters, that I am connected to the frmrs01 PoP.
Does tracerouting work for other users, using either the same or a different PoP?
tracerouting does not work
Check the 'ttl' on your tunnel interface, this should be 64 and not inherit from the IPv4 interface below it.
tracerouting does not work
Shadow Hawkins on Sunday, 09 January 2011 21:31:41
Oh, thanks a lot for the hint.
You're absolutely right, the tunnel did inherit its TTL; I just forced it to 64, and now it works perfectly.
I feel stupid for not having the idea to check the TTL of the IPv4 packets.
Thanks for your help.
tracerouting does not work
You mean the TTL of the IPv6 packets. Note that the ttl argument is noted in (afaik) all the FAQ examples.
tracerouting does not work
Shadow Hawkins on Monday, 10 January 2011 00:54:29
About the FAQ examples, you're absolutely right, at least as for the Debian example. I have no idea why/how I messed it, but it certainly was my fault...
As for the TTL, there must be something I'm misunderstanding...
As I understand it, when my router decides to send an IPv6 packet through my tunnel, the IPv6 packet already has a Hop limit in the IPv6 header (defined when the packet was generated, and decreased by each IPv6 router that was traversed) and it would not change it. But it has to encapsulate the IPv6 packet within an IPv4 packet, and choose a "Time to live" for the IPv4 header.
As I understand it, with "ttl inherit", the "Time to live" in the IPv4 header is the same as the "Hop limit" in the IPv6 header, while, with "ttl 64", the "Time to live" in the IPv4 header is 64, whatever the "Hop limit" in the IPv6 header is...
That looks consistent with the hole I had with "ttl inherit". My remote endpoint is 10 routers away in IPv4. Then any IPv6 packet with a "Hop limit" lower than 10 will be encapsulated in an IPv4 packet with a "Time to live" to low to reach the endpoint, and traceroute6 sees nothing. And any IPv6 packet with a "Hop limit" of 10 or more will reach the enpoint, and then go at least 9 hops further. That would explain the 10-host hole in my traceroute6...
Is there something wrong with my understanding? Or did you mean something like "the IPv4 TTL of IPv4-encapsulated IPv6 packets"?
|
![[ch]](/s/countries/ch.gif)
on Sunday, 09 January 2011 16:20:53
Posting is only allowed when you are