Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests
Status: NRPM Sections 4.1.6, 4.1.8
Formal introduction on PPML on 21 January 2010
Origin - Policy Proposal 97
Draft Policy - 21 January 2010 (with staff assessment)
Revised - 22 March 2010
Remains on AC's docket - 28 April 2010
Last Call - 22 June through 12 July 2010
AC recommended adoption - 20 July 2010
Adopted and implemented - 12 January 2011Public Policy Mailing List
ARIN Public Policy Meeting:ARIN XXV
ARIN Advisory Council:
Scott Leibrand and Dan Alexander
- 20 August 2009
- 17 December 2009
- 15 January 2010
- 18 February 2010
- 18 March 2010
- 21 April 2010
- 20 May 2010
- 17 June 2010
- 15 July 2010
- 19 August 2010
ARIN Board of Trustees:10 August 2010
Revisions:2010-1 previous versions
Implementation:12 January 2010
Draft Policy 2010-1
Waiting List for Unmet IPv4 Requests
Version/Date: 22 June 2010
Replace 4.1.6 with:
In order to preserve aggregation, ARIN attempts to issue blocks of
addresses on appropriate "CIDR-supported" bit boundaries. ARIN may
reserve space to maximize aggregation possibilities until the
implementation of section 10.4.2.2, at which time 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 specify the smallest block
size they'd be willing to accept, equal to or larger than the applicable
minimum size specified elsewhere in ARIN policy. If such a smaller block
is available, ARIN will fulfill the request with the largest single
block available that fulfills the request. If no such block is
available, the organization will be provided the option to be placed on
a waiting list of pre-qualified recipients, listing both the block size
qualified for and the smallest block size acceptable.
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 a change in circumstances
since their last request that could not have been reasonably foreseen at
the time of the original request, and which now justifies additional
space. 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.
18.104.22.168 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.
22.214.171.124 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.
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
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 126.96.36.199, 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.