2010-1 Previous Version [Archived]

OUT OF DATE?

Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.

View the current policy proposal text.

The following version was archived on 22 June 2010.

Draft Policy 2010-1
Waiting List for Unmet IPv4 Requests

Version/Date: 22 March 2010

Policy statement:
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: an organization may only receive one allocation, assignment, or transfer every 3 months, but ARIN, at its sole discretion, may waive this requirement if the requester can document an unforeseen change in circumstances since their last request.
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 timely 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.

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.

FAQ:

Q1: The effect of 2009-8, if implemented by the Board, is to allow transfers to be up to a 12 month supply of resources and up to a 3 month supply for resource from the ARIN free pool. Does that jive with your intent for this policy?

A1: Correct. After we get to the last /8, you can request up to a 3-month supply from the free pool, but only every 3 months unless you can document an unforeseen change in circumstances since your last request. However, if you get the space via transfer, you can get a block big enough for 12 month’s need, and if you end up using it up faster, you can submit another request after 3 months.

Q2: If I were on the waiting list, and subsequently received a transfer via 8.3, would I be removed from the waiting list?

A2: Yes. In 4.1.8.2, it says that “Any requests met through a transfer will be considered fulfilled and removed from the waiting list.”

Q3: Would receipt of an M&A transfer remove you from the waiting list, too?

A3: I think that depends on how the M&A is justified. If you acquire a company that is already efficiently utilizing all its IP space, I don’t think that would count toward fulfilling an outstanding need that you have a request on the waiting list for. However, if your justification for keeping the space held by the acquired company is that you plan to use it for new stuff, then that would meet an outstanding need, and a request for that same need would be considered fulfilled and removed from the waiting list.

Q4: What about Multiple Discrete Networks?

A4: Allocations and assignments to organizations using the Multiple Discrete Networks policy must still be made as a single continuous range of addresses. This preserves future aggregatability of the space, and ensures fairness between MDN and ordinary requests.

Q5: What would constitute “an unforeseen change in circumstances since their last request” that would allow ARIN to waive the 3-month delay to receive a second block?

A5: This would, of course, be a matter of discretion for ARIN, but the idea here is that the burden of proof is on the requester to document some change in circumstances, that could not have been reasonably foreseen at the time of the original request, that now justifies additional space. This is intended to be a rarely used safety valve.

Q6: What if an organization goes out of business or no longer needs the space when they get to the top of the waiting list?

A6: When a block becomes available to fulfill a request on the waiting list, ARIN will do “a re-validation of the original request”. If the original requester cannot be contacted, or their original need is no longer justified, they will be removed from the waiting list, and ARIN will move on to the next qualified requester.

Timetable for implementation: Immediate.

The following version was archived on 22 March 2010.