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:
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.