Correct. *BUT*, lets take: Your host with 2001:db8::1 and 2002::1 A website on 2fff::1 Your OS has to pick a source address to use to make the connection to 2fff::1. Source Address Selection rules then determines to use 2002::1 as it much closer (bit wise). 2fff::1 doesn't have a route back to your 6to4 address or the route is broken, and you have your problem as the return packets are getting lost in cyberspace, causing at least a large connection delay before your stack notices that it is failing and if you are lucky, but most OS's don't do this, it might try the other address. Debugging these things is thus very hard and using 1 source address makes things much more visible. Next to that, what do you stick in DNS? 2fff::1 or 2002::1 ? You want to optimise the traffic from 6to4 sites, but when you use 2fff::1 return traffic should still go over the tunnel and not over 6to4 because of reverse filtering and 6to4 interface should not carry non-6to4 traffic, which makes it all sort of pretty broken and inconvienent. OCCAID is there to your rescue, at least they have planned to deploy a PoP in Seattle WA, which should be very near your endpoint. That you read completely correct. Indeed I don't like 6to4, especially because it is a corner-case and it is very hard, if not impossible, to debug because of the many loops it can take. Though it is good for boot-strapping IPv6 deployment in some places.