[arin-ppml] Policy Proposal: Dedicated IPv4 block to facilitate IPv6 deployment
tvest at pch.net
Tue Jul 15 19:46:43 EDT 2008
On Jul 15, 2008, at 9:50 AM, Matthew Pounsett wrote:
> On 27-Jun-2008, at 14:26 , Tom Vest wrote:
>> If it wasn't already obvious, I support this proposal.
>> However, I think that the reservation should envision a 20-year
>> transition timeframe, if not longer.
> In discussing this with Alain early on, we talked about how to
> figure out how large the block should be. I think a reasonable
> approach is to look at the growth curve of the number of unique
> organizations ARIN has, and then project out to whatever horizon we
> want from there. It shouldn't be too hard to figure out an average
> allocation per org under this policy, which should tell us the size
> of the reserve that's necessary.
>> I am assuming that a resource transfer proposal will advance in
>> parallel, and ultimately versions of both policies may be approved.
>> If that happens, some very risk-averse and/or very windfall-driven
>> IPv4 holders/users may still be tempted to hold out until the
>> pool too is exhausted. The size of the reserved pool is the only real
>> deterrent to discourage that kind of strategy.
> Agreed. I hadn't really considered this impact to transfers, but it
> certainly seems plausible... so setting the horizon a long way out
> seems like a good idea to me.
Thanks for the reply.
You should consider this to be the *single most important and
influential factor* that will impact transfers, hands down.
For example, if you think that only fringe elements are placing their
bets on no IPv6, ever, then I commend to your attention:
I've looked (and inquired directly) to see if this is still the
Renesys view; absent any evidence of a change of positions I assume
that it is.
Of course one could produce many op-eds and presentations that
champion the opposing view, including a few authored by equally
knowledgeable and well-connected sources. However, this alone should
make it plain enough that there's a credible commercial message and a
receptive commercial audience of some size for opinions, advice --
maybe even strategies and tools (note: this latter bit is purely
speculative) -- that build on the assumption that IPv6 will remain a
So, to clarify and reaffirm my position on this policy, I believe that
it will create a tension between the goal of extracting maximum rents
from legacy IPv4 resources (the "just business" default assumption),
and the goal of maintaining openness to new entrants -- which is good,
since if a resource transfer policy moves forward without any
accompanying policy like this, then the most likely outcome is no new
entrants, no problem! However, that tension could lead to a kind-of
waiting game, with incumbent IPv4 holders who cannot command a price
that they will accept choosing instead to hold onto all of the IPv4
that they have or could decommission until the reservation is
exhausted and the price of IPv4 is unbounded.To the degree that that
happens, then of course the whole goal of the resource transfer
proposals -- to create a liquid supply of IPv4 address space for
whatever future awaits -- could be undermined or thwarted entirely.
The best way to mitigate that risk while keeping the industry open and
the antitrust intervention risk low would be to make the reservation
large enough so no one could imagine holding out long enough to enjoy
that unbounded price opportunity.
A /8 per RIR would have a nice symmetry. It would leave the developing
regions especially well stocked for new entrants if IPv6 is ultimately
rejected. In the more advanced industrial regions, where the
aforementioned strategic considerations are more important, a /8
should suffice to deter all but the most patient and determined would-
be price maximizers.
Actually, once the substance of this policy is solidified, I would
strongly encourage the AC to consider revising 2008-2 so that it
*incorporates* the text.... Think of it as an earmark for the "future
network operators" special interest ;-)
More information about the ARIN-PPML