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-10 11:17:30
On Thu, Jun 9, 2011 at 10:57 AM, Keith Moore 
<moore(_at_)network-heretics(_dot_)com>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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
<Prev in Thread] Current Thread [Next in Thread>