So, I just spent over an hour beating my head against a fairly obvious (at least it should have been) IPv6 networking problem. I figure I'll share it ...
Yesterday evening I upgraded my router here to 2.6.6-rc2 from 2.4.23, a needed upgrade, considering I have other users on that system. As predicted, eth0 and eth1 swapped, and the outside interface connected to RPI was now the inside interface. I swapped the cables, rebooted again, and all was well.
Today, realizing some of my Xload apps (I watch load averages on some of my machines via Xload) had been disconnected due to last night's router upgrade, I fired up the script and waited to see the graphs pop back up. However, there was a long delay (45 seconds) before each of the Xload apps displayed on the screen. During that time, any kind of connection with that host (happened to be two hops away) did not respond. This only happened for IPv6 hosts not on the local link and only configured with a EUI-64 interface identifier.
Now, this was all being done from my workstation (tacolinux), my laptop apparently was unaffected. I also noticed when I would ping6 the host in question, I would get a host unreachable from ip6-localhost. This didn't make sense, since the router local to the remote host should reply with that error if the remote host was actually having connectivity issues.
I would blame this on the Linux 2.6 upgrade on the router, but it still didn't make sense that my laptop could connect fine. Eventually, upon observing the IPv6 routes on my workstation, I had two default routes: fe80::201:3ff:fe69:8b77 and fe80::201:3ff:fede:64d6. There was the problem ... I forgot that I had swapped network cards, and the MAC address (and the EUI-64 portion of the router's link-local address) of the internal NIC had changed. I removed the route via fe80::201:3ff:fede:64d6, and everything worked again.
So, yea, I spent an hour debugging that, isn't that sad? Goodnight ...
