I'm not even using any SixXs tunnel/subnet yet (just got an account), though I've been using 6to4 and Unique Local Addresses (fd00::/8) for a few weeks. My question is partly conceptual. If a host had an interface with three IPv6 addresses: - fe80 link local - fd00::/8 Unique Local ( http://en.wikipedia.org/wiki/Unique_local_address ) (RFC 4193) - 2002::/16 6to4 ( http://en.wikipedia.org/wiki/6to4 ) ... and that host was asked to connect to http://ipv6.google.com , shouldn't the host necessarily choose the 6to4 address as the source address for the connection? I thought the answer was a clear "yes", because my understanding of fd00::/8 is that they are not globally routable. However, Windows XP and Windows Vista are both choosing fd00 instead of 2002 as the source address. Unsurprisingly, the connection fails. Is this a Windows bug? If not, maybe my radvd config is to blame. Perhaps this short prefix advertisement config block: prefix fd28:6A42:E044:87CC::/64 {AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; }; Above, fd00::/8 is implemented through a fd...::/64 prefix. Does it look right and proper to you? Windows uses the /64 prefix and then generates its somewhat random "temporary" lower 64 bits, which seems correct. I got around the problem of fd00::/8 being chosen as the source address when connecting to ipv6.google.com by modifying the "prefix policy" tables, making the "label" of the 2002::/16 prefix to be the same as the "label" of the ::/0 prefix, both equal to 1, in the lines of what's suggested on this wiki: http://oldwiki.openwrt.org/IPv6_howto.html Once I did that, maybe 2002 was selected on the basis of longest matching prefix... I don't know. It felt like a hacked/broken solution to a problem I didn't completely understand. I also found this nice article that goes into details of the Windows IPv6 Source Address Selection: http://technet.microsoft.com/en-us/library/bb877985.aspx In the rather complex algorithm described in the article, I would have thought that the selection of fd00::/8 as a source address should have been prevented in step 2, "Prefer the source address that has a scope appropriate for the destination address" (source is Unique Local, destination is public). The 2002::/16 should then have been preferred over the fd00::/8. Other than Windows, a Mac OS X 10.6.4 host in the same network properly selects 2002::/16 instead of fd00::/8 as the source address. It is also auto-configured based on the same radvd advertisement. But this alone doesn't prove that Windows is broken. Have you ever tried adding fd00::/8 to your network? Does it work with Windows? Should I file a bug with Microsoft?... Cheers, Paulo Castro