ietf
[Top] [All Lists]

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

2011-06-09 12:41:34
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>