[ppml] Motivating migration to IPv6 -> IPV4 deprecation

[Owen DeLong]

On Jul 31, 2007, at 11:27 AM, Mark Beland wrote:

> I'd do that and take it a step further,
>
> IPV4 deprecation:
> In tandem with a measure like this, make a press release that after a
> certain date,
> "IPV4 will be obsolete" (I'm probably ruffling feathers here by saying
> this)
> After said date, Arin will no longer publish or maintain any ipv4  
> whois
> information,
> remove the in-addr.arpa zone. After all, the goal here is to have an
> ipv6 only global
> network - right?! (maybe we don't even agree on that objective)
>
I don't see any reason that is the goal.  I think the goal is to have a
network which allows generally ubiquitous IPv6 connectivity at least
to all devices that need to participate in the "global" internet.  I do
not think that IPv4 deprecation is something that should be helped
along by anything other than market forces and the costs of
maintaining it.

As IPv6 gains ubiquity, ISPs will want to terminate IPv4 services due
to cost.  If there is customer demand to keep it running, then, the ISPs
will start charging more to cover those costs.  This will shrink the
customer base for IPv4, causing further price increases for IPv4
services until such time as some form of balance between the demand
and the cost is reached.
> Arin can't force people not to use IPV4, but by publicly declaring it
> 'obsolete', I would surmise
> that it would create a certain marketing push to entice migration.  
> Make
> users think that
> the Internet is going to stop working unless their on IPV6.
>
IPv4 deprecation will not encourage IPv6 adoption.  In fact, I think  
that
such an announcement from ARIN would merely serve to create an
array of competing IPv4 registries to offer "replacement" services.

Oh, and, in case you hadn't noticed, ARIN doesn't control in-addr.arpa.
They only control several of the third level zones within in-addr.arpa.

> Of course, this would make more sense if IANA and everyone else did
> this.....
>
It could only work if IANA did it in terms of deprecating the in- 
addr.arpa
zone.  Fortunately, I think the IANA is smarter than this.

> I really don't understand the talk about resource reclamation,  
> legacy or
> otherwise,
> we're just delaying the inevitable... I just see us (the internet
> community as a whole)
> being stuck running dual ipv4 + ipv6 networks to the detriment of  
> all...
>
As an author and proponent of at least one of the resource reclamation
proposals on the table, I can assure you it is not intended to delay the
inevitable.  There is no intent in the proposal, nor, on my side any  
belief
that it will in any way extend the useful life of IPv4 or increase  
the IPv4
free pool in a meaningful way.  The intent of reclamation proposals, to
my knowledge, is to get those blocks which are deprecated marked as
such so that they can not be used  so easily for abuse.

Owen

>
>
>
>
>
> Robert Bonomi wrote:
>> I'm sure the following idea has to have occured to better minds  
>> than mine,
>> but I _cannot_ see what the downside to it is --
>>
>> Given that:
>>   1) it is policy to 'encourage' migration to IPv6
>>   2) there is a looming shortage of IPv4 addresses available for  
>> assignment
>>   3) _At_present_ IPv4 address-space *is* viewed by requestors as  
>> 'preferable'
>>      to IPv6 space.
>>   4) more than 95% of address-space assignments are to entities  
>> for which there
>>      is a reasonable expectation they will be making _additional_  
>> address-
>>      space requests in the 'not too distant' future.
>>
>> Proposed:
>>   A) every IPv4 block assignment includes the assignment of an  
>> 'equivalent-
>>      size'  IPv6 address block ( e.g. assuming '1 IPv4 /32' == '1  
>> IPv6 /64)
>>   B) _subsequent_ v4 requests must show the required utilization  
>> levels of
>>      *both* the allocated IPv4 *and* IPv6 space.  With  
>> "utilization" of IPv6
>>      space requiring the actual deployment of functional machines  
>> in that
>>      address-space.
>>   C) As the pool of available IPv4 addresses gets smaller, the  
>> ratio of  the
>>      relative size of the IPv6 allocation vs the IPv4 allocation  
>> _increases_.
>>
>> For 'revenue' purposes, the 'paired' IPv4 and IPv6 allocations are  
>> counted
>> as single block, as long as both are allocated.  IF the requestor  
>> _returns_
>> the IPv4 block, they get a significant discount on the IPv6 space  
>> for some
>> period of time. (50% off for 5 years, maybe?)
>>
>>
>> If the 'sliding ratio' described in 'C' is anounced well in  
>> advance, there
>> is clear self-interest incentive for the larger requestors to  
>> start deploying
>> IPv6 promptly.  It is obviously easier to 'start small' _now_,  
>> than to be
>> forced into 'massive' deployment at a later date.
>>
>> If that 'sliding scale' is based on the (total) quantity of IPv4  
>> space
>> remaining, not on fixed calendar dates, the incentive to "start  
>> now" is
>> even greater -- one doesn't know 'how high' the price will be  
>> "when we
>> _need_ it" later.  Just that it will be much cheaper -then-, if  
>> one does
>> the groundwork _now_.
>>
>>
>>  ++++
>>
>> Another possible 'motivator' for IPv6 migration -- tie the  
>> requirements
>> for getting _additional_ IPv4 space to the ratio of IPv6 vs IPv4  
>> space
>> that the requestor _already_ has "in verified use".  The less IPv6  
>> space
>> they have in use relative to their IPv4 space the *higher* the  
>> utilization
>> of the IPv4 space they have to show to get any additional IPv4 space.
>>
>> Again, if this is "scaled" to remaining IPv4 space availability,  
>> matters
>> should be 'self-correcting' due to simple market forces.
>>
>>
>>
>> An _absolutely_ effective way of driving migration to IPv6 would  
>> be to
>> condition additional IPv4 address-space allocations on the percentage
>> of IPv6 traffic that transits the boundaries of the requestor's  
>> network.
>> That requires that not only does the requestor deploy IPv6  
>> internally,
>> but that they _use_ it with external parties as well.  Nobody can  
>> argue
>> the efectiveness of such an approach; however I suspect there are  
>> a number
>> of significant obstacles to actual implementation.
>>
>>
>> As I said at the top of things, I'm sure things like this have  
>> already
>> occured to far brighter people than me -- I await, with some  
>> trepidation,
>> being shown  'the **** obvious facts' that I have overlooked, that  
>> kill
>> such an approach. :)
>>
>>
>> _______________________________________________
>> This message sent to you through the ARIN Public Policy Mailing List
>> (PPML at arin.net).
>> Manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml
>>
>
>
> _______________________________________________
> This message sent to you through the ARIN Public Policy Mailing List
> (PPML at arin.net).
> Manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml