[ppml] Solicing comments: IPv4 to IPv6 Migration Incentive Address Space
sleibrand at internap.com
Wed Jun 27 18:13:34 EDT 2007
William Herrin wrote:
> Yet IPv6 uptake increases at a pace which won't meet the 10%
> deployment mark before IPv4 exhaustion.
You assume a continued linear pace...
> Three years from now, that will be a real problem for Internap. You
> sell a high value service with cleverly optimized routes. Without IPv6
> in place, no more IPv4 addresses means no new customers despite your
> technology. Cogent gets them instead because this week Cogent is the
> one with spare IP addresses. Next week it'll be someone else, Level 3
> maybe, but not you. You're stuck until a customer leaves and forfeits
> his IP addresses.
In our case, we intend to be fully ready to offer IPv6 services before
our customers require them, which means before IPv4 space is exhausted.
We know what needs to happen to offer IPv6 support (and have known that
for a few years now). On the hardware side, all the new hardware we've
purchased in the last several years has supported IPv6 forwarding in
hardware, and we have been gradually replacing much of the hardware that
doesn't support IPv6 through our normal equipment refresh projects. On
the software and systems side of things, we have to time our IPv6
investments such that we take the necessary steps in time, but not allow
it to delay more urgent needs that have a more immediate effect on revenue.
> That's why I've proposed an -Incentive- space, not merely a migration
> space. We have maybe three years to get IPv6 to a point where dialup
> users, dsl users and folks with wifi laptops at Starbucks receive IPv6
> addresses automatically alongside the IPv4 addresses. That's three
> years to get IPv6 in the hands of the end users and every network
> admin in the path from us to them. If we can't bring Mohammad to the
> mountain, maybe its in our interest for the mountain to make a trip.
I think an appropriate historical analogy for IPv6 readiness is y2k
compliance. As with IPv4 exhaustion, insiders knew the y2k bug would be
a problem years or decades before y2k. As with y2k, the benefits of
IPv6 readiness come mostly from avoiding problems when the century /
IPv4 space runs out. Most of the benefits of being y2k compliant came
on January 1st, 2000, and most of the benefit of being IPv6 ready will
come when IPv4 space is exhausted.
I think it's worth comparing the two scenarios on a timeline basis as
well: How much legacy code had been y2k-patched as of June 1997? A
Google news archive search confirms that in 1997, while most major news
organizations were running stories on the y2k bug, analysts were looking
at the efforts to date and predicting that "companies are not acting
expeditiously enough to be fully year 2000 compliant by the close of the
decade" and "more than one-half of all organizations world-wide will not
fully complete their year 2000 effort."
fact, what happened was that companies first focused on ensuring that
new hardware and software was y2k compliant, enabling normal or
slightly-accelerated upgrade/refresh cycles to take care of a lot of the
problem. For the legacy applications that couldn't be easily replaced
by 01/01/2000, efforts to patch things mostly got rolling in 1998 and
early 1999. (Office Space was released 02/19/1999.)
So the lesson I would draw from the y2k/IPv4 comparison is that if we
can educate stakeholders on the problem, most of them will make pretty
good decisions and make the necessary preparations. And since the
impacts of IPv4 exhaustion will be more gradual than the y2k bug (the
IPv4 Internet will keep working long after every RIR exhausts their free
IPv4 pools), there will be varying degrees of preparedness for IPv4
exhaustion: that's fine.
More information about the ARIN-PPML