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

[Keith Moore <[e-mail]>]

On Jul 3, 2011, at 12:09 PM, Tim Chown wrote:

> 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.

That's simply false.   For instance, both users and applications developers are drastically underrepresented in that group.   

The interests of operators are certainly important and should be given due regard, but they are not the only interests that need to be considered.

>  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.

One person's view should only be counted as one person's view, no matter how many messages he sends.     And yet, when even one person speaks up for the interests of an under-represented group, the merit of his arguments should be considered.

The reason we make decisions by consensus in IETF, rather than by voting, is that there's no way to have a representative sample of all interests.

And yes, a vocal minority can be sufficient to cause IETF to fail to reach consensus.  That's intentional.

> 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.

False.   The problems associated with 6to4 were not created by 6to4; they were created by dubious operational practices.  

But I note that all of the counter measures you cite are widely agreed on and well on their way to being reality.    Making 6to4 Historic in addition to these will not help; it will only hurt users who are successfully using it now.

>  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.

In other words, it's an attempt to sabotage 6to4 for those who are currently successfully using it, and without giving them a viable replacement.  It's an attempt to shift the pain from the operators to the users, for problems that were mostly caused by operators.

> 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'.

6to4 might need fixing, but it's not up to operators to fix it.    I think it's just fine if operators do things that they should normally be doing, i.e.: make a best effort to deliver all traffic (including protocol 41);  make sure that routers work properly; make sure that route advertisements are accurate.

Of course, if 6to4 could be replaced with something better, that would be a win for everyone.  For operators, I think that means deploying some form of v6 concurrently with LSN.   But I don't think the net can afford to trust that all operators will do this.

Keith