[arin-ppml] Policy Proposal: Predicable IPv4 Run Out by Prefix Size

[Pete Templin]

David Farmer wrote:
> On 8 Jun 2009 Pete Templin wrote:
> 
> You have the right idea, but not the right numbers,  with the proposed one 
> quarter (1/4) ratio and starting at /8,  a geometric progression is created, 
> such that if all allocations were of a maximum size available at the time, it 
> would take 24 separate requests to wipe out the pool.  A ratio of one half 
> (1/2) would require 13 maximum size requests, a ratio of one eighth (1/8) 
> would require 44 maximum size requests, and a ratio one sixteenth (1/16) 
> would require 80 maximum size requests.
> 
> See the following Google Docs spread sheet from more details, there are 
> separate tabs for one half, one quarter, one eighth, and one sixteenth;
> 
> http://spreadsheets.google.com/ccc?key=r2IDwxI-feUNacGABcvopnQ
> 
> Please realize all requests will not be of a maximum size, the numbers above 
> are purely the worst case scenario.  Also, exactly how much ARIN has in the 
> IPv4 pool when this policy is triggered depends on when 10.4.2.2 is triggered 
> and if it is a request form ARIN that triggers it or a request from one of the 
> other RIRs.  I think in theory it could be as much as three (3) /8s or as little 
> as three (3) /10s receptively in the best or worst possible timing.  I suspect 
> something a little more than /8 is probably about right.  But to make the math 
> in the spread sheet easier I went with an exact /8 scenario.

I'm simply not following your suggestion of the numbers, which includes 
looking at the spreadsheet you've provided.  I'll base my discussions on 
the one quarter (1/4) ratio since that's what's written into the Policy 
Proposal.

Case study #1: ARIN has a /13 of space, also known as 524,288 addresses. 
  Four large-enough requests happen to be at the head of the line, and 
based on the one-quarter ratio they're eligible for a /15 of space per 
request.  Each request is issued a /15, also known as 131,072 addresses. 
  These 524,288 addresses in four allocations would wipe out the pool, 
not the 24 allocations that you present above.

Case study #2: ARIN has a /17 of space, also known as 32,768 addresses. 
  Four large-enough requests happen to be at the head of the line, and 
based on the one-quarter ratio they're eligible for a /19 of space per 
request.  Each request is issued a /19, also known as 8,192 addresses. 
These 32,768 addresses in four allocations would wipe out the pool, not 
the 24 allocations that you present above.

I acknowledge that current policy allows one large-enough request to 
wipe out all available-at-the-moment free-pool IPv4 within ARIN's 
bucket, and that distribution across more-than-one recipient is in the 
interest of fairness, even though we don't know how yet best to achieve 
some form of equitable fairness.  That said, this policy doesn't appear 
to be achieving much of the desired goal; I suspect it needs to be on 
the order of 6-10 bits (64-1024 allocations) before we're really 
achieving "distribution".

Pete