[ppml] Solicing comments: IPv4 to IPv6 Migration Incentive Address Space

[Scott Leibrand]

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." 
(http://www.pbs.org/newshour/@capitol/forum/april97/2000_4-28e.html)  In 
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.

-Scott