[ppml] Motivating migration to IPv6

Scott Leibrand sleibrand at internap.com
Tue Jul 31 14:12:55 EDT 2007


Robert,

What you're describing sounds a lot like an "unfunded mandate" to me.  I 
don't think it's ARIN's job to force its members to deploy IPv6 in order 
to get more IPv4 space.

I would support previous proposals to require applicants for IPv4 space 
to document their plans for IPv6 deployment, but I don't think ARIN 
should be requiring applicants to meet binding IPv6 deployment targets.

-Scott

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
>   



More information about the ARIN-PPML mailing list