Butch, On Tue, Apr 19, 2011 at 8:52 PM, Butch Evans <butche@butchevans.com> wrote:
The drafts I saw posted earlier were discussing what is essentially toredo services (anycast tunnel) at least.
6to4 is significantly different from Teredo, since it: a) it does not hurt web deployments using DNS records for their resources (src/dst addr selection, and more) b) it works from behind a NAT,
If this is on by default, then that is only bad (in my opinion) IF there is no native IPv6 support on the LAN side of these networks. Maybe I am missing something, but this is my take.
In the case of 6to4, this is only true if your source/destination address selection works properly. Teredo adds extra safety to really make it a ipv4->ipv6 connection mechanism of last resort.
Either way, there certainly IS a place in networks for Toredo services, since SO MANY devices for the CPE end of the connectivity equation still have zero support for IPv6.
I must point you to Geoff Hustons most recent ISP posting: http://www.potaroo.net/ispcol/2011-04/teredo.html It gives a very good picture of the Teredo support out in the wild. It also makes it abundantly clear that Teredo is not a reliable auto-tunneling mechanism (if such a mechanism ever can exist): 6to4 looks like flawlessness in comparison with Teredo when it comes to connection success ratios. Yet, virtually nobody has so far been complaining over issues caused by Teredo being active on their hosts. And there are some situations where it is OK that only 2 out of 3 connections succeed, if it means your system can work better: Notably, peer-to-peer applications can make use of this to establish connections in a cloud, using DHT instead of DNS for peer propagation, and Teredo relays as the rendezvous mechanism. I would, however, not want to rely on this for calls in Skype, for example. My (current) personal opinion on the situation is that application developers who do not want to use the last-resort NAT-"trespassing" method of establishing connectivity that Teredo supplies, must decide in their code not to use it. Some peer-to-peer applications have been known for years to come with a "Enable IPv6"-button, because it improved the applications performance to do so. So, in a world where some applications will enable it, other applications will have to *not use it*, else the applications will end-up in a race-condition on whether the protocol is enabled or not.
It's not the best solution for sure, but the fact remains that most networks will be dual-stacked at least initially at the core, but the endpoints (customer networks) are outside of our administrative control and often are behind devices that we do not control/own. Maybe I'm missing something...
AFAIK, there's ongoing work in IETF to address this. I think one of the wg's is "softwire", http://tools.ietf.org/wg/softwire/ , but I have not followed this at all. Regards, Martin