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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf