Comcast's 6to4 Relays

Wed Apr 20 01:43:48 UTC 2011

Butch,

On Tue, Apr 19, 2011 at 8:52 PM, Butch Evans <butche at 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