[ppml] NANOG IPv4 Exhaustion BoF

[Scott Leibrand]

David Conrad wrote:
> Scott,
> 
> 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 
unnecessary deaggregation.

> 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.

-Scott