[arin-ppml] [Fwd: Re: [arin-announce] Policy Proposal: Waiting list for unmet IPv4 requests]
tedm at ipinc.net
Fri Jun 12 13:50:20 EDT 2009
I'm sorry to report that I'm against this proposal as written.
I like the idea of a waiting list, and I had assumed ARIN would
do this post-IPv4 runout.
However, I feel that if the number resources become available
more than 3 months AFTER the date of the initial request, that
the waiting org must be re-qualified.
They should be allows to "keep their place in line" but they should
not be allowed to qualify then keep the qualification as good for
an indefinite period.
Keep in mind that once ARIN issues a qualification to an org,
that qualification becomes an asset. Supposing for example the
ISP is purchased by another ISP with adequate IPv4. Why should
they be able to get even more?
Or, if you think that scenario is unlikely, then suppose the
ISP puts in a IPv4 request, is denied, goes on the waiting list,
then 3 months later executes a "private buy" with another org
for a directed IPv4 transfer, and gets more numbers. Then, 3
months after that, IPv4 becomes available for the next org up
on the wait list, and this ISP is the next in line.
They no longer meet utilization requirements because they paid
money out for the directed transfer 3 months earlier - but since
they are prequalifed on the wait list, they can now get even more
IPv4 under the rules. Which of course they are going to want to
do so they can turn around and "sell it" on the open market - to
cover their cost from 3 months earlier of paying for IPv4 on the
If the proposal was rewritten to force re qualification I'd probably
Member Services wrote:
> Please be advised that the following policy proposal has been posted to
> the ARIN Public Policy Mailing List. All discussion of the proposal must
> take place on the PPML
> Member Services
> American Registry for Internet Numbers (ARIN)
> ## * ##
> 1. Policy Proposal Name: Waiting list for unmet IPv4 requests
> 2. Proposal Originator: Scott Leibrand
> 3. Proposal Version: 1.0
> 4. Date: 6/11/2009
> 5. Proposal type: new
> 6. Policy term: permanent
> 7. Policy statement:
> 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.
> 126.96.36.199 Waiting list
> The position of each qualified request on the waiting list will be
> determined by the date it was approved. ARIN may provide a validity
> duration on each qualification, in which case the requester may renew
> their request prior to its expiration to preserve their position on the
> waiting list. Each organization may have one approved request on the
> waiting list at a time. Any requests met through a transfer will be
> removed from the waiting list.
> 188.8.131.52 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. Requests will not be partially filled.
> 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.
> 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.
> 9. Timetable for implementation: Immediate.
> You are receiving this message because you are subscribed to
> the ARIN Announce Mailing List (ARIN-announce at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML