On 4/09/2008, at 6:32 PM, Glen Eustace wrote:
At present we have not put AAAAs on any web resources. Until I get 6to4 setup and confirm that our miredo server is behaving as expected I don't want to get complaints about poor response because all external v6 traffic goes via an offshore relay. There are more problems than this - put a Windows Vista machine on a filtered non-RFC1918 address, and you'll get breakage with 6to4.
Please expand on the above and anything else that comes to mind. I need to know about things that are likely to break when I do 'turn it all on'
6to4 has no qualification mechanism - that is, it cannot test whether it is working or not as the interface comes up. The MS 6to4 stack assumes that if it has an RFC1918 address, it should run ISATAP or Teredo (in order of preference). If it has a non-RFC1918 address, it assumes it should run ISATAP or 6to4 (in order of preference). So, for those networks that have non-RFC1918 addresses on end nodes, but filter or NAT those end nodes, 6to4 will not function. In many cases (I need to test this some more), it means that TCP connection set up will time out (90sec or so). Unfortunately, these sort of networks are common in academia, as academia has long had lots of IPv4 space available, so why bother with RFC1918? Student connects to student wifi network, gets a public address, and is NATed or filtered at the border = broken 6to4. This was a problem at Auckland Uni until some time ago when they put RFC1918 on their student wifi network. This is not a problem for hosts that are part of a Windows domain - only ISATAP is used in that case, which does not have these problems. Note that many other automatic 6to4 boxes (Apple Airport Extreme) behave similarly, I believe. It's not me bashing on Windows IPv6 this time, I save that for Teredo default settings :-) -- Nathan Ward