Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests - revised

[Member Services]

Draft Policy 2010-1
Waiting List for Unmet IPv4 Requests

2010-1 has been revised.

The word "timely" was added before re-validation in 4.1.8.2.

Two more questions/answers were added to the rationale.

This draft policy is open for discussion on this mailing list and will
be on the agenda at the upcoming ARIN Public Policy Meeting in Toronto.

Draft Policy 2010-1 is below and can be found at:
https://www.arin.net/policy/proposals/2010_1.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


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.