I know this is probably something on my side, but for the life of me I can't seem to figure it out and would appreciate any thoughts. I recently switched from the NY tunnel broker to the new Miami tunnel broker and everything is working great except for outbound IPv6 trace routes. Using the new Miami tunnel, when I do an outbound trace route I do not receive back the intermediary hosts, just the final destination. What seems odd to me is that I am able to trace route to my host through the Miami tunnel as shown in the last trace route. I've tried disabling all iptable rules on the Linux host, but it didn't make a difference. At this point I can't say for sure if this was occurring using the NYC tunnel, I am assuming during the change over I forgot to reconfigure something on the host, but I can't seem to figure it out at the moment. Again, any thoughts are welcome. Thanks!
Example from Miami to HE:
traceroute to ipv6.tunnelbroker.net (2001:470:0:63::2), 30 hops max, 40 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 tunnelbroker.com (2001:470:0:63::2) 276.364 ms 173.176 ms 173.242 ms
Example from Newark to HE:
traceroute to ipv6.tunnelbroker.net (2001:470:0:63::2), 30 hops max, 40 byte packets
1 avongaussnj.tunnel.tserv4.nyc4.ipv6.he.net (2001:470:1f06:61d::1) 11.226 ms 13.153 ms 17.455 ms
2 gige-g3-8.core1.nyc4.he.net (2001:470:0:5d::1) 17.560 ms 17.553 ms 21.242 ms
3 10gigabitethernet3-1.core1.sjc2.he.net (2001:470:0:33::1) 98.529 ms 98.532 ms 98.527 ms
4 10gigabitethernet1-1.core1.fmt1.he.net (2001:470:0:2f::1) 98.582 ms 98.577 ms 98.608 ms
5 tunnelbroker.com (2001:470:0:63::2) 98.510 ms 98.504 ms 98.498 ms
Example from Newark to Miami:
traceroute to 2001:470:5:3::5 (2001:470:5:3::5), 30 hops max, 40 byte packets
1 avongaussnj.tunnel.tserv4.nyc4.ipv6.he.net (2001:470:1f06:61d::1) 14.380 ms 16.899 ms 18.333 ms
2 gige-g3-8.core1.nyc4.he.net (2001:470:0:5d::1) 18.825 ms 18.822 ms 20.609 ms
3 10gigabitethernet2-3.core1.ash1.he.net (2001:470:0:36::1) 24.599 ms 24.594 ms 24.621 ms
4 10gigabitethernet1-1.core1.mia1.he.net (2001:470:0:4b::2) 49.885 ms 49.879 ms 49.912 ms
5 2001:470:0:8c::2 (2001:470:0:8c::2) 49.907 ms 49.900 ms 49.934 ms
6 2001:470:5:3::5 (2001:470:5:3::5) 118.919 ms 107.232 ms 111.479 ms
Must be on your machine because a trace from the Miami tunnel-server to your side of a NYC tunnel reports every hop:
traceroute6 to 2001:470:1f06:61d::2 (2001:470:1f06:61d::2) from 2001:470:0:8c::2, 64 hops max, 12 byte packets
1 2001:470:0:8c::1 0.325 ms 0.254 ms 0.139 ms
2 10gigabitethernet5-4.core1.ash1.he.net 34.212 ms 28.057 ms 28.072 ms
3 10gigabitethernet1-2.core1.nyc4.he.net 34.213 ms 34.934 ms 34.215 ms
4 1g-bge0.tserv4.nyc4.ipv6.he.net 35.968 ms 35.960 ms 36.114 ms
5 avongaussnj-pt.tunnel.tserv4.nyc4.ipv6.he.net 37.684 ms 57.456 ms 45.183 ms
http://www.tunnelbroker.net/forums/index.php?topic=110.msg491#msg491 might be related.
Sam
Thank you both for responding. I definitely agree it is probably something on my side, I've just been having a dandy of a time trying to figure out what would allow inbound but not allow outbound other than iptables. I've tried reconnecting to the NYC broker with the same results and I did see the thread on TTL affecting trace routes. The TTL in the stanza has always been set, but I did try the command referenced in the thread with the same results.
Not an answer, but a little more information in case someone else runs in to this situation. It would seem that the default configuration of K/Ubuntu 8.04 is the source of this issue. The host in question was upgraded via fresh install from Ubuntu 7.10 to Ubuntu 8.04 about a month before the tunnel was switched and I probably did not try to do a trace route from the host during that period to realize it was no longer working. I have since restaged the host to openSuSE for other reasons and it does not exhibit the problem, however another workstation that is running Kubuntu 8.04 is still exhibiting the problem.