[arin-ppml] Post-exhaustion IPv4 policy

[Scott Leibrand]

William Herrin wrote:
>
> IMO, it's time now to think about what we do *beyond* the end of the
> free pool when IPv4 addressing policy changes to a zero-sum game.
> Where giving one org new addresses means taking them from someone
> else.
>
> The address market strategy might work. Ought to work. But we should
> probably make some contingency plans.
>   

Have you looked at proposal 97, Waiting List for Unmet IPv4 Requests?  
I'd be interested in your feedback on whether this would be helpful or not.

Here's my latest draft text.  It contains some minor updates to address 
staff concerns that haven't been published anywhere until now.

-Scott

Replace 4.1.6 with:

4.1.6. Aggregation

In order to preserve aggregation, ARIN attempts to issue blocks of 
addresses on appropriate "CIDR-supported" bit boundaries. As long as 
sufficient space is available, ARIN may reserve space to maximize 
aggregation possibilities. ARIN will make each allocation and assignment 
as a single continuous range of addresses.

Add new section 4.1.8:

4.1.8 Unmet requests

In the event that ARIN does not have a contiguous block of addresses of 
sufficient size to fulfill a qualified request, ARIN will provide the 
requesting organization with the option to either modify their request 
and request a smaller size block, or be placed on a waiting list of 
pre-qualified recipients. Repeated requests, in a manner that would 
circumvent 4.1.6, are not allowed. Qualified requesters whose request 
cannot be immediately met will also be advised of the availability of 
the transfer mechanism in section 8.3 as an alternative mechanism to 
obtain IPv4 addresses.

4.1.8.1 Waiting list

The position of each qualified request on the waiting list will be 
determined by the date it was approved. Each organization may have one 
approved request on the waiting list at a time.

4.1.8.2 Fulfilling unmet needs

As address blocks become available for allocation, ARIN will fulfill 
requests on a first-approved basis, subject to the size of each 
available address block and a re-validation of the original request. 
Requests will not be partially filled. Any requests met through a 
transfer will be considered fulfilled and removed from the waiting list.

8. Rationale:

ARIN will soon be unable to meet all approved requests for IPv4 address 
space. In the absence of a policy like this, it is unclear what ARIN 
should do with subsequent requests.

This policy would allocate reclaimed address blocks (and the last of the 
ARIN free pool) on a first-come-first-served basis, while preserving 
aggregation to the degree possible. As the free pool shrinks, requests 
larger than the largest block left would be placed on a waiting list, 
while smaller requests would use up the rest of it, until all requests 
have to go on the waiting list. As additional reclaimed addresses become 
available, the requests that have been waiting the longest would be met 
first. If a requester gets the addresses they need via transfer, then 
they would be removed from the waiting list and would need to wait and 
submit a new request for additional address space, either directly or 
via transfer.

This policy does not attempt to ration addresses, define maximum 
allocations, or otherwise manage how much address space any given 
organization may request. As such, it is completely independent of any 
"Predictable IPv4 Run Out" proposals.