Re: [v6ops] draft-ietf-v6ops-6to4-to-historic

[Tim Chown <[e-mail]>]

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