[arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests

[Member Services]

Draft Policy 2010-1
Waiting List for Unmet IPv4 Requests

On 15 January 2010 the ARIN Advisory Council (AC) selected "Waiting List
for Unmet IPv4 Requests" as a draft policy for adoption discussion on
the PPML and at the Public Policy Meeting in Toronto in April.

The draft was developed by the AC from Policy Proposal "97. Waiting List
for Unmet IPv4 Requests". Per the Policy Development Process the AC
submitted text to ARIN for a staff and legal assessment prior to its
selection as a draft policy. Below the draft policy is the ARIN staff
and legal assessment, including the original proposal text.

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

You are encouraged to discuss Draft Policy 2010-1 on the PPML prior to
the April Public Policy Meeting. Both the discussion on the list and
at the meeting will be used by the ARIN Advisory Council to determine
the community consensus for adopting this as policy.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2010-1
Waiting List for Unmet IPv4 Requests

Version/Date: 21 January 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 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.

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.

Timetable for implementation: Immediate.


#####


STAFF ASSESSMENT

Proposal: Waiting List for Unmet IPv4 Requests
Proposal Version: Updated by AC and given to staff for assessment on 29
Dec 2009

Date of Assessment: 12 January 2010

1. Proposal Summary (Staff Understanding)

Staff understands that this proposal would create a waiting list for
requestors whose IPv4 address needs cannot be fulfilled by ARIN at the
time of the request approval. The proposal includes text to prevent
requestors from gaming the policy's intent by forbidding requestors from
making multiple requests of a small size and limiting the issuance of
space to no more than once every 3 months.

2. Comments

A. ARIN Staff Comments

• In section 4.1.8, the author says “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”.

As written, the portion of the policy that starts with “but ARIN, at its
sole discretion” gives no concrete criteria for staff to use in its
assessment of the request. This “exception clause” is open to
interpretation and may not be applied consistently by staff if there are
no guidelines or rules for staff to follow. It essentially allows ARIN
staff to determine the policy criteria for who can or can’t qualify
under this waiver.

B. ARIN General Counsel

"At this time counsel has no significant legal comments. Any system to
order and prioritize requests for resources which may exceed the
available resources must permit consistent administration by ARIN."

3. Resource Impact

This policy would have moderate resource impact. It is estimated that
implementation would occur within 6 months after ratification by the
ARIN Board of Trustees. The following would be needed in order to 
implement:

• The development of software to monitor IPv4 returns, a “waiting list”
that will include request size as well as minimum size acceptable, and a
system that will match/compare returns with the waiting list
• Modifications to the management web application
• Changes to current business processes
• Updated guidelines
• Staff training



4. Proposal Text: Waiting list for unmet IPv4 requests

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 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.