Re: [v6ops] Last Call: <draft-ietf-v6ops-6to4-to-historic-04.txt> (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Jun 9, 2011, at 12:01 PM, Christian Huitema wrote:

> Arguably, transitions technologies like 6to4 and Teredo have already achieved their purpose. My goal at the time, more than 10 years ago, was to break the "chicken and egg" deadlock between application developers and network administrators. That's why I spent such energy on making 6to4 easy to deploy, or defining Teredo. Transitions technologies convinced developers that applications could be developed for IPv6 without waiting for every network to be ready, and applications were indeed developed by Microsoft and others. Network administrators in the meantime started deploying IPv6, and the presence of applications arguably helped somewhat -- although I am sure network administrators add many other motivations.
> 
> We are now observing a strong pushback, because massive use of tunneling technologies makes networks harder to manage. Wide scale deployment of self-configuring technologies makes levels of services less predictable, and errors are hard to correct. Self-configuring technologies rely largely on the good will of others, which is easier to find during a pioneering phase. Arguably, we are beyond the pioneering phase for IPv6.

It's hard to argue that we're beyond the pioneering phase of IPv6 when native IPv6 is still not widely available.  The pushback was predictable, for the very reasons you cite.  But it's premature and counterproductive to cave in to it.  If pain associated with 6to4 provides an additional incentive for ISPs to deploy native v6, and for users to use native v6 when it becomes available, that's a Good Thing.  (Not that I want to cause them pain, but neither do I want the Internet to be stuck with 6to4 and Teredo forever.)

> I understand Keith's point of view, but it is probably time to start progressively rolling back the transition technologies. 6to4 is the weakest of these technologies. It does not traverse NAT, it does not include configuration verification tests, and it uses asymmetric paths. It makes sense to start the rollback with 6to4.

The time to start rolling back the transition technologies is when v6 support is available off the shelf.  Because there is some pain associated with them, there's a built in incentive to do so. 

And I disagree that 6to4 is the weakest of the technologies.   They all have strengths and weaknesses.  6to4 is very widely implemented, is automatically configurable, needs no central server, and routing is near-optimal for 6to4-to-6to4 traffic.  But there's a community learning curve associated with using anycast addresses for relay routers.  Configured tunnels take a latency hit on every packet, no matter where it's going.  Teredo works through NATs (good), but also requires routing packets through third party servers, with the corresponding implications for latency, privacy, etc.  And in practice, it's pretty much a Microsoft-only solution - it doesn't ship with either Mac or Linux.

(If we could have developed a universal best-of-breed transition technology, I think we would have done so.   But the solution space really didn't permit that, so we ended up with a hodgepodge of different tools that are applicable in different  situations.)

Keith

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]