On 3 Jul 2011, at 12:10, Gert Doering wrote:
On Sat, Jul 02, 2011 at 11:11:43PM -0400, Keith Moore wrote:
There's clearly a lack of consensus to support it.
There's two very vocal persons opposing it and a much larger number of
people that support it, but have not the time to write a similarily
large amount of e-mails. For me, this is enough for "rough consensus".
(And I second everything Lorenzo, Randy and Cameron said - there's
theoretical possibilities, and real world. 6to4 fails the real-world
test. Get over it, instead of attacking people that run real-world
networks for the decisions they need to do to keep the networks running
in a world without enough IPv4 addresses).
I'm with Gert, Lorenzo, Randy and others here.
It seemed that both the -advisory and -historic drafts had strong support in
v6ops, which isn't just any WG, it's the WG that anyone with a vested interest
in IPv6 deployment takes part. Thus its view on IPv6 deployment practices
should be given due regard. The opposition on the IETF list seemed to be a
vocal minority, and of course one person seemed to post a disproportionate
number of replies.
The problems with 6to4 (20% minimum failure rate, and poor performance when it
does connect) are well documented and have led to various 'counter measures'
from the IETF, including:
a) 6to4 off by default, as per 6to4-advisory
b) IPv4 being preferred to 6to4 transport, as per 3484-bis (widely implemented
already)
c) a fast fallback mechanism from IPv6 to IPv4, as per happy eyeballs (a
simplistic version is already in Chrome)
Those measures indicate how bad a problem 6to4 creates. If we're going to the
trouble of coming up with all these measures, there seems to be a good case for
6to4 to Historic, which would be a steer to implementors to no longer include
6to4 support at all. I do agree however that the most important point is
publishing the -advisory text.
As a provider of a (not large) enterprise, I know that a fraction of 1% of
connections to our site suffer a 10 second+ delay to a dual-stack web site
where they suffer no delay to an IPv4-only one. There's no way to know for
sure how much of that 'IPv6 brokenness' is 6to4, but measures (a), (b), and (c)
should minimise that figure. Having said that, less than 1% of users who
connect to our site over IPv6 use 6to4, so we wouldn't be aggrieved to see it
disappear in terms of loss of users, as those users could almost certainly
still reach us over IPv4. Our own users who want IPv6 connectivity when
offsite use tunnel brokers, which provide a much better (and more predictable)
service, one that also works from behind a NAT, which in the reality of home,
hotel, and other hotspot networks is quite important.
As for operators 'fixing' 6to4, well, I'd rather see operators invest that
effort in deploying IPv6, rather than making 6to4 work better, for some value
of 'better'.
Tim
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf