[ppml] NANOG IPv4 Exhaustion BoF
sleibrand at internap.com
Wed Mar 5 18:29:23 EST 2008
David Conrad wrote:
> On Mar 5, 2008, at 12:54 PM, Scott Leibrand wrote:
>> Do you have any suggestions for how we can improve the policy proposal
>> to eliminate unnecessary restrictions while avoiding the negative
>> impacts likely from a completely unrestricted transfer policy?
> What are 'negative impacts'?
I think you outlined a few of them earlier today, but they would include
the results of a number of different types of speculation (unnecessary
volatile prices, scarcity, etc.), hoarding of addresses for various
reasons (speculation, attempts to starve out competitors, etc.), and
> I have a couple more fundamental questions:
> a) What is the overarching goal the transfer policy is trying to achieve?
If there were just one goal, this would be easy. We're trying to ensure
the continued availability of IP resources after IPv4 free pool
exhaustion, minimizing disruption, minimizing unnecessary deaggregation,
preserving some level of fairness, etc...
> b) What tools exist (or can be expected to exist given reasonable
> time/resources) to enforce that policy?
The main tool is that, as the recognized authority in registration of
IPv4 addresses in North America, recognition as valid of any transfers
by ARIN has considerable value to both transferors and transferees.
> The answers to these questions would shape my answer.
> A couple of observations:
> - the 6 month restriction could force folks to go outside the policy in
> desperation (e.g., the amount of address space available via transfers
> is likely to be hard to predict. You could be in a situation where at
> one point in time, the only option is a small block even though you know
> it won't last 6 months. What option do you have?)
You could get PA space from your ISP or another LIR. The intent of a
the transfer policy is that it would ensure the availability of blocks
of all sizes legitimately demanded by transferees. Therefore, if we do
it right, there should always be an appropriately sized block available
at some price.
> - restrictions on sub-division beyond what is imposed within the routing
> system are unlikely to be effective
It is not our intention to prevent advertisements of deaggregates within
the routing system, as people do today down to /24, regardless of the
size of their allocation/assignment. Rather, we hope to prevent the
transfer of large numbers of small blocks when a larger one would do, as
we don't want networks to be cobbling together their IP space from
multiple sources and then being forced to announce extra routes for all
the different blocks.
FYI, we'll be posting version 1.1 of this policy shortly, which IMO
includes some improvements on this front.
More information about the ARIN-PPML