Two questions: Airport Extreme error light & occaid.org routing

[annodomini]

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:

Code Select Expand

$ 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 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?

[cholzhauer]

Not an error on your end

Code Select Expand



[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

[marcusw]

Aaaand another traceroute to help with triangulation:

Code Select Expand

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.)