nanog mailing list archives
Re: Comcast's 6to4 Relays
From: Martin Millnert <millnert () gmail com>
Date: Tue, 19 Apr 2011 21:43:48 -0400
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
Current thread:
- Comcast's 6to4 Relays Brzozowski, John (Apr 19)
- Re: Comcast's 6to4 Relays Doug Barton (Apr 19)
- Re: Comcast's 6to4 Relays Jared Mauch (Apr 19)
- Re: Comcast's 6to4 Relays Mikael Abrahamsson (Apr 19)
- Re: Comcast's 6to4 Relays Cameron Byrne (Apr 19)
- Re: Comcast's 6to4 Relays Butch Evans (Apr 19)
- Re: Comcast's 6to4 Relays Martin Millnert (Apr 19)
- Re: Comcast's 6to4 Relays Geoff Huston (Apr 20)
- Re: Comcast's 6to4 Relays Fred Baker (Apr 19)
- CIsco IOS bug info request Eric Parsonage (Apr 20)
- RE: CIsco IOS bug info request Erik Bais (Apr 20)
- Re: CIsco IOS bug info request Ingo Flaschberger (Apr 20)
- Re: CIsco IOS bug info request Randy Bush (Apr 20)
- Re: Comcast's 6to4 Relays Doug Barton (Apr 19)
- Re: Comcast's 6to4 Relays Brzozowski, John (Apr 20)
- Re: Comcast's 6to4 Relays Doug Barton (Apr 20)
- Re: Comcast's 6to4 Relays Owen DeLong (Apr 20)
- Re: Comcast's 6to4 Relays Steven Bellovin (Apr 20)