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 Thu, Jun 9, 2011 at 10:57 AM, Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote:
So the existence of 6to4 is in itself a significant barrier for IPv6 deployment for server operators and content providers.
non sequitur.   Existing server operators and content providers can easily provide 6to4 addresses for their servers and content, which will be used in preference to native v6 addresses.

No. According to Geoff's data, one of the main reasons 6to4 fails is a firewall that blocks IPv4 protocol 41 traffic. Even if content providers published 6to4 addresses, those connections would still fail.
 
Application developers should develop using manually configured tunnels, not 6to4. At least they don't have a 20% failure rate.
How do you know?  How do you even measure the failure rate of manually configured tunnels in the aggregate?

In a similar way as Geoff measured 6to4 - looking at SYNs. I suspect that the answer will be that much fewer users have configured tunnels than 6to4, and that the failure rate is much lower.
 
 I don't think you can monitor that kind of traffic the way you can 6to4, because the traffic patterns are much more constrained.   It's been awhile since I used manually configured tunnels (from a well-known tunnel broker).  But the one time I did try them, 6to4 worked better overall - lower latency and lower failure rate.

Please try again. You will be pleasantly surprised. 
_______________________________________________
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]