Keith & John are hitting the crux of the issue here. The entire point of the
automated tunneling technologies was to enable application development and
deployment in the face of lethargic ISPs, that will refuse to move until
they see a set of credible applications running in the wild. None of them
will take the risk that the leap-of-faith requires without serious
competitive threat, and that simply doesn't exist.
I am in the 'enviable' position where both ISP options available to me are
clueful and actually actively working on IPv6 deployments. That said, I am
still stuck with tunneling because the one option that could get me service
today can't keep their basic access network running (the other
work-from-home neighbors around me struggle with it regularly for IPv4), and
the one I use for service has decided to start their deployment of IPv6 in
larger markets (imagine that). 6to4 continues to serve me well for all but
the bone-headed places that have decided to boycott that prefix.
There is no real problem with 6to4, despite the BS being propagated about
failure rates. The fundamental problem is that those complaining have their
heads firmly stuck in IPv4-think, and are refusing to add a second 6to4
prefix to their service. If they would simply install their own 6to4 router
and be the tunnel endpoint, there would be no 3rd party in the path for
either direction. The technology is simply creating an opportunity. Those
complaining about it are refusing to take advantage of it because that would
be a different operational practice than they do for IPv4.
The herd mentality of kill-what-we-don't-like is not helping with
deployment. In fact the ability to document which ISPs have customers that
are trying to use IPv6 despite the edge lethargy is a very useful thing to
drive deployment through blame-&-shame. Put the 6to4-to-historic effort on
the shelf for at least 5 years. Then it will be time to talk.
Tony
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
John C Klensin
Sent: Friday, June 10, 2011 7:44 AM
To: Brian E Carpenter
Cc: IETF Discussion
Subject: Re: one data point regarding native IPv6 support
--On Saturday, June 11, 2011 01:34 +1200 Brian E Carpenter
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> wrote:
...
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.
Sure. Assuming that there is realistic competition, or a
realistic possibility of competition, in the relevant market.
Keith, Ned, and others have described a situation in which there
are few realistic choices of ISPs and the attitude of all of
them toward getting IPv6 deployed to endpoints runs from bad to
worse. In that marketplace situation, capitalism is as likely
to predict a "no one goes first" outcome as it is to predict
that one of the ISPs will suddenly decide that deploying IPv6
will give them a competitive advantage... and give that
competitive advantage even after the additional training costs
for their own staffs, support costs for customers, equipment and
software, etc., are considered.
That situation really isn't much different than it was several
years ago. If I'm in an area where competition is permitted,
I'm a large enough customer to be talking about dedicated fiber
to my premises in the multiple DS3 range or above, and I call up
my ISP (or my router vendors, or...) and say "sell me IPv6 or
I'm going to find it somewhere else", the threat is credible and
I'll probably set either them or their competitors scrambling.
If I'm in a situation that is closer to a SOHO one, in much of
the world there is no effective competition, I'm not seen as
having much leverage, and the scenario for my getting native
IPv6 is a lot more dependent on internal strategic decisions (or
wishful thinking) in those ISPs and not on competition issues
except very indirectly or at all.
john
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf