[ppml] Motivating migration to IPv6 -> IPV4 deprecation

[Mark Beland]

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)

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.

Of course, this would make more sense if IANA and everyone else did 
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...






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
>