[arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyfor IPv4 Addresses - Last Call

[Leo Bicknell]

In a message written on Fri, Jan 02, 2009 at 03:07:47PM -0500, John Schnizlein wrote:
> On 2009Jan1, at 3:45 PM, Leo Bicknell wrote:
> >The status quo ends, however, when it does I have a markedly different
> >view of the world than you do.  I believe that:
> >
> > - IPv6 is deployed fairly rapidly, and with limited pain.
> 
> What would prompt this sort of radical change from the deplorably slow  
> deployment over the last several years?

Here's the interesting dynamic; there is almost no first-mover
advantage to deploying IPv6 first.  You want to deploy it before
your customers want it, so you don't have to turn them away; and
you want your engineers to have experience with it.  However, beyond
that it doesn't get you extra revenue, and may make you purchase
equipment you would not otherwise purchase, run newer software with
more bugs, etc.

We see ISP's state this over and over, the customers do not want
it, so we're not doing it.

However, there is also no incentive to drag your feet once the move
starts.  The industry will move quikly to IPv6 once the move starts
because running transition boxes (NAT, 6to4, whatever) is expensive,
so most ISP's will want to be as dual-stack as possible and do as
little transition as possible.  ISP's will also move to push the
transition costs to their competitors, last one with a transition
box looses.

What will start the move is customer demand, and it will be driven
by the lack of IPv4 resources for large ISP's.  Cox/Comcast/Time
Warner/Verizon (FIOS/DSL)/Cablevision will run out.  They will
provision IPv6 (I believe).  I think most will roll it out to their
existing customers as well, in a dual-stack situation.  Eyeballs
will go first, and content having generally much fewer systems, a
higher IQ per IP, and generally depending on protocols well tested
over IPv6 will move second, and at an amazingly rapid pace.  Akamai's
and Limelight's I suspect could offer IPv6 services worldwide in a
matter of a few weeks, if there was a reason to do so.

In short, the least effort, least cost path is to delay as long as
possible, then for everyone to leap forward at a brisk pace;
essentially as fast as possible without paying money just to "speed
it up."

It is the service industry equivilent of the manufacturing industry's
"just in time" delivery.  You don't want inventory sitting in
warehouses, which is what IPv6 configured on your network before people
want it appears to be.  However, if the part/service is late, it
disrupts the entire line and causes a mess.

> something happens soon to change the current slow progress, I fear the  
> IPv4-translation approaches might become so well entrenched that they  
> become yet another obstacle to deployment of a network-layer Internet  
> protocol with sufficient addresses for the globe.

Translation may be a short term solution.  However translation will
always be more costly than native, and ISP's love to cut costs out
of anything they can get their hands on.  I have no fear of translation
boxes becoming a long term solution.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090102/b7962d3b/attachment.sig>