[arin-ppml] Policy Proposal 97: Waiting List for Unmet IPv4 Requests - Deferred
Member Services
info at arin.net
Thu Aug 27 14:08:17 EDT 2009
Policy Proposal 97
Waiting List for Unmet IPv4 Requests
Member Services wrote:
> V. The AC decided to defer discussion of “Policy Proposal 97: Waiting
> List for Unmet IPv4 Requests” until after the October Public Policy
> Meeting.
The AC deferred Policy Proposal 97 based in part on feedback the AC
received from the ARIN staff and legal assessment. The AC asked that
staff post the assessment (below) to PPML.
Regards,
Member Services
American Registry for Internet Numbers (ARIN)
#####
Staff Assessment
Proposal: Waiting List for Unmet IPv4 Requests
Proposal Version (Date): 28 July 2009
Date of Assessment: 14 Aug 2009
1. Proposal Summary (Staff Understanding)
Staff understands that this proposal would alter ARIN's current address
issuing procedures and instead require the issuing of a single,
contiguous address prefix for each approved IPv4 request. It would
create a waiting list for requesters whose IPv4 address needs cannot be
fulfilled by ARIN at the time of the request approval and includes
policy text to prevent requesters from gaming the policy's intent by
forbidding requesters from making multiple requests of a small size.
2. Comments
A. ARIN Staff Comments
* 4.1.6 - As written, this would significantly change ARIN’s current
system of inventory management. Currently, allocations are issued
to ISPs, and where relevant, space is reserved to account for the
ISP's one-year need. This maximizes aggregation possibilities in
keeping with ARIN's primary mission of promoting both address
conservation and route aggregation. The text, as written, would
force staff to stop this practice, and likely cause more
de-aggregation (not less) in the immediate future.
In addition, the proposal would preclude utilization (where suitable) of
multiple smaller address blocks to meet a request, even if the requester
knows that such addresses will not be routed to the Internet. The hard
requirement for satisfying requests via a single, contiguous address
prefix can therefore result in a less efficient utilization of IPv4
address space than otherwise possible.
* 4.1.8 – The term "repeated requests" will need to be defined and
business procedures developed accordingly. The expected behavior
upon request denial would be for an ISP to submit a revised
request for smaller block, and this would naturally result in
having to apply again at a future date for the remainder of the
space. It is not clear under the present draft if this would be
considered “circumvention of 4.1.6” or not.
B. ARIN General Counsel
At the current time counsel cannot complete evaluation of this policy.
While avoiding de-aggregation can be an important value to the
community, from a legal standpoint it remains unclear whether this
policy inappropriately elevates that single virtue, i.e., preserving the
efficiency of routing while failing to address other simultaneous
aspects of run-out. This policy may create significant and serious
implementation problems that could lead to ‘gaming’ activity and a
multiplicity of requests designed to circumvent this policy at a time
when litigation may result from any real or perceived unfairness in
management of scarce IPv4 resources.
An alternative way of restating this concern is to focus on the
following statement at the end of the policy: “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.”
Counsel wishes to understand whether it is operationally and legally
necessary to integrate multiple policy concerns and community needs
simultaneously in an integrated proposal, i.e. it may not be possible to
create equitable policy for a waiting list which includes a single-block
assignment requirement without also considering these other policy
concerns.
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:
* Software developed to monitor allocations, and modifications to
the management web application
* Changes to current business processes
* Updated guidelines
* Staff training
4. Proposal Text
Waiting list for unmet IPv4 requests
Version: 28 July 2009
Replace 4.1.6 with:
4.1.6. Aggregation
In order to preserve aggregation, ARIN issues blocks of addresses on
appropriate "CIDR-supported" bit boundaries. ARIN will make all
allocations and assignments 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.
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.
Member Services wrote:
> In accordance with the ARIN Policy Development Process the ARIN Advisory
> Council (AC) held a meeting on 20 August 2009 and made decisions about
> several policy proposals and draft policies.
>
> I. The AC selected the following proposals and changed them into draft
> policies for adoption discussion online and at the upcoming Public
> Policy Meeting. The draft policies will be posted shortly to the PPML.
>
> Policy Proposal 89 (Global): Internet Assigned Numbers Authority (IANA)
> Policy for Allocation of ASN Blocks (ASNs) to Regional Internet
> Registries
>
> Policy Proposal 90: Open Access To IPv6
>
> Policy Proposal 93: Equitable IPv4 Run Out
>
> II. The AC selected the following draft policy for adoption discussion
> online and at the upcoming Public Policy Meeting. It will be posted
> shortly to the PPML.
>
> Draft Policy 2009-3: (Global): Allocation of IPv4 Blocks to Regional
> Internet Registries
>
> III. The AC used portions of “Policy Proposal 94: Predictable IPv4 Run
> Out by Allocation Window” to help with the creation of the “Equitable
> IPv4 Run Out.” The AC considers proposal 94 to be closed.
>
> IV. The AC abandoned “Policy Proposal 96: Transfer Listing Service.” The
> AC suggested that the President direct this matter through the ARIN
> Consultation and Suggestion Process.
>
> V. The AC decided to defer discussion of “Policy Proposal 97: Waiting
> List for Unmet IPv4 Requests” until after the October Public Policy
> Meeting.
>
> VI. The AC accepted the following proposals on to the AC's docket for
> development and evaluation. There is not an adequate amount of time to
> create and publish draft policies in time for the October Public Policy
> Meeting.
>
> Policy Proposal 98: Last Minute Assistance for Small ISPs
>
> Policy Proposal 99: /24 End User Minimum Allocation Unit
>
> VII. The AC abandoned “Policy Proposal 100: Multihomed Microallocations.”
>
> VIII. The AC sent a revised “2008-3: Community Networks IPv6 Assignment”
> to an extended last call. The text will be posted shortly to the PPML.
>
> The PDP states, “Any member of the community, including a proposal
> originator, may initiate a Discussion Petition if they are dissatisfied
> with the action taken by the Advisory Council regarding any specific
> policy proposal.” Several of the AC’s decisions above resulted in
> proposals not being selected for adoption discussion. The purpose of a
> petition would be to change a proposal into a draft policy for
> discussion on the Public Policy Mailing List and at the October meeting.
> The deadline to begin a petition is 2 September 2009.
>
> The following can be petitioned (status in parens):
>
> Policy Proposal 94: Predictable IPv4 Run Out by Allocation Window
> (merged and closed)
>
> Policy Proposal 96: Transfer Listing Service (abandoned)
>
> Policy Proposal 97: Waiting List for Unmet IPv4 Requests (delayed)
>
> Policy Proposal 98: Last Minute Assistance for Small ISPs (added to AC’s
> docket)
>
> Policy Proposal 99: /24 End User Minimum Allocation Unit (added to AC’s
> docket)
>
> Policy Proposal 100: Multihomed Microallocations (abandoned)
>
> For more information on starting and participating in petitions, see PDP
> Petitions at: https://www.arin.net/policy/pdp_petitions.html
>
> Draft Policy and Policy Proposal texts under discussion are available
> at: https://www.arin.net/policy/proposals/index.html
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
More information about the ARIN-PPML
mailing list