I have two questions. I am a Comcast customer, using an Airport Extreme wireless router; I've been using 6to4 for a few weeks with Comcast's relays, but since it's 6to4, my computer would always prefer IPv4 to v6 when connecting to dual stack hosts. So I set up a tunnelbroker.net account to try out a more complete IPv6 experience.
So far, I'm running into two problems. One may be based on my own confusion, I'm not sure. I wasn't quite sure how to map from the addresses given to me by the tunnel broker to the ones to use for my Airport configuration. The tunnel broker lists "Server IPv4 address", "Server IPv6 address", "Client IPv4 address", "Client IPv6 address", and "Routed /64" (as well as some DNS addresses that I'm not using at the moment, to reduce the number of variables). The Airport configuration utility has fields for "Remote IPv4 Address", "WAN IPv6 Address", "IPv6 Default Route", and "LAN IPv6 Address". After some experimentation and Googling, I wound up putting the "Server IPv4 address" in the "Remote IPv4 Address" field, the "Server IPv6 address" in the "WAN IPv6 Address" field, the "Client IPv6 address" in the "IPv6 Default Route" field, and the "Routed /64" in the "LAN IPv6 Address" field. This appears to work—I can connect to v6 only hosts, I can connect to dual stack hosts which report that I'm using my v6 address, and traceroute6 shows packets going over my tunnel. But for some reason, my router has a blinking amber light and when I use the configuration utility reports a problem with tunnel configuration. It is not any more specific than that; it just says that there is a problem. Is there any way to get more information about what the problem may be, or are there any tests I can run to determine what issues might come up? Was I correct in my mapping between the parameters provided by tunnelbroker.net and what my Airport configuration is looking for?
The second issue is that when I try to connect to occaid.org via IPv6 (which is used by default now when I'm browsing the web), the packets are lost. My browser will wait a while sending SYN packets into the void, before giving up and switching to v4. Here's what I get from a traceroute:
$ traceroute6 occaid.org
traceroute6 to occaid.org (2001:4830:100:20::6) from 2001:470:1f07:189:21c:b3ff:febc:c615, 64 hops max, 12 byte packets
1 2001:470:1f07:189:9284:dff:fed3:15d4 0.973 ms 1.016 ms 0.639 ms
2 annodomini-1.tunnel.tserv4.nyc4.ipv6.he.net 52.941 ms 53.028 ms 59.149 ms
3 gige-g3-8.core1.nyc4.he.net 60.327 ms 54.854 ms 52.728 ms
4 10gigabitethernet2-3.core1.ash1.he.net 57.723 ms 67.492 ms 57.755 ms
5 ibr01-ve96.asbn01.occaid.net 57.927 ms 59.586 ms 57.502 ms
6 bbr01-p2-1.whkn01.occaid.net 65.395 ms 64.813 ms 66.598 ms
7 bbr01-t1-0.bstn01.occaid.net 72.465 ms 73.069 ms 74.634 ms
8 towardex-ic-1135-bos.customer.occaid.net 73.393 ms 74.972 ms 74.832 ms
9 23.te3-1.bb2.bos.twdx.net 73.825 ms 73.194 ms 73.470 ms
10 * * *
I don't have access to any other IPv6 hosts, so I can't test if this issue is unique to my setup or if this is their problem (though Googling for "IPv6 ping" brings me http://www.berkom.blazing.de/tools/ping.cgi (http://www.berkom.blazing.de/tools/ping.cgi) which also seems to indicated that they aren't pingable). Any tips on debugging or reporting this problem? Also, until it's resolved, are there any good ways to blacklist IPv6 for particular hosts, so I don't have to wait for connection attempts to time out before reverting back to IPv4?
Not an error on your end
[carl@mars ~]$ traceroute6 occaid.org
traceroute6 to occaid.org (2001:4830:100:20::6) from 2001:470:c27d:e000:20c:29ff:fe8a:1618, 64 hops max, 12 byte packets
1 2001:470:c27d:d000:2e0:81ff:fe79:f4c4 1.102 ms 0.659 ms 0.614 ms
2 servicespring-1.tunnel.tserv9.chi1.ipv6.he.net 51.538 ms 49.661 ms 50.348 ms
3 gige-g3-4.core1.chi1.he.net 54.316 ms 166.525 ms 121.065 ms
4 10gigabitethernet2-4.core1.nyc4.he.net 111.571 ms 111.337 ms 123.456 ms
5 10gigabitethernet2-3.core1.ash1.he.net 120.685 ms 135.863 ms 146.880 ms
6 ibr01-ve96.asbn01.occaid.net 141.824 ms 143.895 ms 153.786 ms
7 bbr01-p2-1.whkn01.occaid.net 165.181 ms 176.548 ms 181.542 ms
8 bbr01-t1-0.bstn01.occaid.net 189.128 ms 182.159 ms 201.534 ms
9 towardex-ic-1135-bos.customer.occaid.net 201.400 ms 140.568 ms 137.775 ms
10 23.te3-1.bb2.bos.twdx.net 153.880 ms 156.410 ms 156.740 ms
11 * * *
^C
[carl@mars ~]$
I haven't heard of the amber light thing before, and it's strange, because as you say, your tunnel appears to be working
Aaaand another traceroute to help with triangulation:
marcus@bt:~$ traceroute6 occaid.org
traceroute to occaid.org (2001:4830:100:20::6) from 2001:470:8:a0c:4a5d:60ff:fe10:be08, 30 hops max, 24 byte packets
1 marcusw-1-pt.tunnel.tserv13.ash1.ipv6.he.net (2001:470:7:a0c::2) 0.869 ms 0.843 ms 0.724 ms
2 marcusw-1.tunnel.tserv13.ash1.ipv6.he.net (2001:470:7:a0c::1) 22.349 ms 20.908 ms 19.707 ms
3 gige-g4-12.core1.ash1.he.net (2001:470:0:90::1) 29.929 ms 19.925 ms 19.787 ms
4 ibr01-ve96.asbn01.occaid.net (2001:504:0:2:0:3:71:1) 19.847 ms 19.373 ms 18.119 ms
5 bbr01-p2-1.nwrk01.occaid.net (2001:4830:ff:f150::1) 26.711 ms 29.262 ms 26.078 ms
6 bbr01-t1-0.bstn01.occaid.net (2001:4830:ff:15c4::2) 32.461 ms 33.4 ms 31.543 ms
7 towardex-ic-1135-bos.customer.occaid.net (2001:4830:e1::2) 32.943 ms 33.577 ms 34.456 ms
8 23.te3-1.bb2.bos.twdx.net (2001:4830:1ff:224::225) 32.927 ms 33.422 ms 32.553 ms
9 * * *
10 * * *
(etc.)