<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7653.38">
<TITLE>RE: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Definitely like the IPv6 as inventory during transition analogy.<BR>
But you state that the movement toward IPv6 will start with customer demand precipitated by ISPs running out of v6 space to deploy.<BR>
That is demand for communication services...that without v6 cannot be satisfied, but is not demand for v6 itself.<BR>
Otherwise, I believe your analysis of how things will move and why is accurate.<BR>
<BR>
bd<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: arin-ppml-bounces@arin.net on behalf of Leo Bicknell<BR>
Sent: Fri 1/2/2009 7:38 PM<BR>
To: arin-ppml@arin.net<BR>
Subject: Re: [arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call<BR>
<BR>
In a message written on Fri, Jan 02, 2009 at 03:07:47PM -0500, John Schnizlein wrote:<BR>
> On 2009Jan1, at 3:45 PM, Leo Bicknell wrote:<BR>
> >The status quo ends, however, when it does I have a markedly different<BR>
> >view of the world than you do. I believe that:<BR>
> ><BR>
> > - IPv6 is deployed fairly rapidly, and with limited pain.<BR>
><BR>
> What would prompt this sort of radical change from the deplorably slow <BR>
> deployment over the last several years?<BR>
<BR>
Here's the interesting dynamic; there is almost no first-mover<BR>
advantage to deploying IPv6 first. You want to deploy it before<BR>
your customers want it, so you don't have to turn them away; and<BR>
you want your engineers to have experience with it. However, beyond<BR>
that it doesn't get you extra revenue, and may make you purchase<BR>
equipment you would not otherwise purchase, run newer software with<BR>
more bugs, etc.<BR>
<BR>
We see ISP's state this over and over, the customers do not want<BR>
it, so we're not doing it.<BR>
<BR>
However, there is also no incentive to drag your feet once the move<BR>
starts. The industry will move quikly to IPv6 once the move starts<BR>
because running transition boxes (NAT, 6to4, whatever) is expensive,<BR>
so most ISP's will want to be as dual-stack as possible and do as<BR>
little transition as possible. ISP's will also move to push the<BR>
transition costs to their competitors, last one with a transition<BR>
box looses.<BR>
<BR>
What will start the move is customer demand, and it will be driven<BR>
by the lack of IPv4 resources for large ISP's. Cox/Comcast/Time<BR>
Warner/Verizon (FIOS/DSL)/Cablevision will run out. They will<BR>
provision IPv6 (I believe). I think most will roll it out to their<BR>
existing customers as well, in a dual-stack situation. Eyeballs<BR>
will go first, and content having generally much fewer systems, a<BR>
higher IQ per IP, and generally depending on protocols well tested<BR>
over IPv6 will move second, and at an amazingly rapid pace. Akamai's<BR>
and Limelight's I suspect could offer IPv6 services worldwide in a<BR>
matter of a few weeks, if there was a reason to do so.<BR>
<BR>
In short, the least effort, least cost path is to delay as long as<BR>
possible, then for everyone to leap forward at a brisk pace;<BR>
essentially as fast as possible without paying money just to "speed<BR>
it up."<BR>
<BR>
It is the service industry equivilent of the manufacturing industry's<BR>
"just in time" delivery. You don't want inventory sitting in<BR>
warehouses, which is what IPv6 configured on your network before people<BR>
want it appears to be. However, if the part/service is late, it<BR>
disrupts the entire line and causes a mess.<BR>
<BR>
> something happens soon to change the current slow progress, I fear the <BR>
> IPv4-translation approaches might become so well entrenched that they <BR>
> become yet another obstacle to deployment of a network-layer Internet <BR>
> protocol with sufficient addresses for the globe.<BR>
<BR>
Translation may be a short term solution. However translation will<BR>
always be more costly than native, and ISP's love to cut costs out<BR>
of anything they can get their hands on. I have no fear of translation<BR>
boxes becoming a long term solution.<BR>
<BR>
--<BR>
Leo Bicknell - bicknell@ufp.org - CCIE 3440<BR>
PGP keys at <A HREF="http://www.ufp.org/~bicknell/">http://www.ufp.org/~bicknell/</A><BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>