On Jun 10, 2011, at 9:34 AM, Brian E Carpenter wrote:
Michel,
On 2011-06-10 15:38, Michel Py wrote:
...
On that one I agree with Keith; where's the rush? Although imperfect,
6to4 was an obvious path and its demise would be the failure of the
IETF, following a long list of things that have been killed prematurely.
Who's talking about its demise? Really all that the 6to4-historic draft
does is say that it should no longer be considered as a default solution
to the problem of ISPs that don't support IPv6.
Actually it says more than that. For instance, it specifically says that new
implementations shouldn't support 6to4.
That, and if passed, this would be the first time I can recall that IETF has
taken the "symbolic" step of declaring something Historic that people actually
use, and for which there is not a readily available replacement that works
better. Historic has historically been used for things that aren't used
anymore, or for things for which there's an obvious and readily available
replacement.
That, and the 'no compromise' position of this draft's proponents - their
unwillingness to try to build a strong consensus position - makes this look
suspiciously like a denial-of-service attack.
Changing the formal status of the RFCs is a symbolic step, but the real point
is that it's now time for the reluctant ISPs to get their heads out of the
sand.
It's a step in the wrong direction. Not only does this "symbolic step" bring
with it the potential for harm to current users of 6to4, it actually takes away
some of the incentive for ISPs to get their heads out of the sand. Meanwhile,
it discourages the development of IPv6-based applications.
You're correct that some ISPs will try to get monopoly rents out of
the IPv4 shortage, and use CGN to capture customers in walled gardens,
but fortunately capitalism provides a solution to such misbehaviour:
other ISPs can deploy IPv6 as a competitive advantage.
Last mile (kilometer?) problems limit the ability of other ISPs to compete with
established players, especially for consumer services. But IETF can't do much
about that.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf