[arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks to Regional Internet Registries

[Martin Hannigan]

On Tue, Jan 13, 2009 at 2:15 PM, Member Services <info at arin.net> wrote:



> Policy statement:
>
> This document describes the policy governing the allocation of IPv4


I think that they may mean "a policy governing" instead of "the". There
could be more than one global policy governing the recovery and subsequent
return of v4 address space.

[ clip]


> This policy is to be implemented in two phases.
>
> A. Phase I: Recovery of IPv4 Address Space
>
> Upon ratification of this policy by the ICANN Board of Directors the
> IANA shall establish a mechanism to receive IPv4 address space which is
> returned to it by the RIRs, and hold that address space in a 'recovered
> IPv4 pool'.
>
> Each RIR through their respective chosen policies and strategies may

recover IPv4 address space which is under their administration. Each RIR
> shall at quarterly intervals return any such recovered address space to
> the IANA in aggregated blocks of /24 or larger, for inclusion in the
> recovered IPv4 pool.
>
> During Phase I, no allocations will be made from the recovered IPv4 pool.
>
> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>
> Upon ratification of this policy by the ICANN Board of Directors and a
> declaration by the IANA that its existing free pool of unallocated IPv4
> addresses space is depleted; Global Addressing Policy ASO-001-2 (adopted
> by ICANN Board 8 April 2005) is rescinded. IANA will then commence to
> allocate the IPv4 address space from the recovered IPv4 pool.


>
> 1. Allocation of IPv4 Address Space
>
> a. For the purposes of this policy, an 'IPv4 allocation period' is
> defined as a 6-month period following 1 March or 1 September in each year.
>
> b. At the beginning of each IPv4 allocation period, the IANA will
> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
> IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary.
>
> c. In each allocation period, each RIR may issue one IPv4 request to the
> IANA.  Providing that the RIR satisfies the allocation criteria
> described in paragraph B.2, the IANA will allocate a single allocation
> unit, composed of the smallest possible number of blocks available in
> its IPv4 address pool.
>
> 2. IPv4 Address Space Allocation Criteria
>
> A RIR is eligible to receive additional IPv4 address space from the IANA
> when the total of its IPv4 address holdings is less than 50% of the
> current IPv4 allocation unit, and providing that it has not already
> received an IPv4 allocation from the IANA during the current IPv4
> allocation period.
>
> 3. Initial Allocation of IPv4 Address Space
>
> Each new RIR shall, at the moment of recognition, be allocated one (1)
> allocation unit by the IANA. If an allocation unit is not available,
> then the IANA will issue this block as soon as one is available. This
> allocation will be made regardless of the newly formed RIR's projected
> utilization figures and shall be independent of the IPv4 address space
> that may have been transferred to the new RIR by the already existing
> RIRs as part of the formal transition process.
>
> 4. Reporting
>
> a. All returned space is to be recorded in an IANA-published log of IPv4
> address space transactions, with each log entry detailing the returned
> address block, the date of the return, and the returning RIR.
>
> b. All allocated space is also to be recorded in this IANA-published log
> of IPv4 address space transactions, with each log entry detailing the
> address blocks, the date of the allocation and the recipient RIR.
>
> c. The IANA will maintain a public registry of the current disposition
> of all IPv4 address space, detailing all reservations and current
> allocations and current IANA-held address space that is unallocated.
>
> d) The IANA may make public announcements of IPv4 address block
> transactions
> that occur under this policy. The IANA will make appropriate
> modifications to the "Internet Protocol V4 Address Space" page of the
> IANA website and may make announcements to its own appropriate
> announcement lists. The IANA announcements will be limited to which
> address ranges, the time of allocation and to which Registry they have
> been allocated.
>
> Rationale:
>
> With the depletion of the IANA free pool of IPv4 address space, the
> current policy regarding the allocation of IPv4 address space to the
> RIRs will become moot. The RIRs may, according to their individual
> policies and procedures, recover IPv4 address space. This policy
> provides a mechanism for the RIRs to retro allocate the recovered IPv4
> address space to the IANA and provides the IANA the policy by which it
> can allocate it back to the RIRs on a needs basis. This policy creates a
> new global pool of IPv4 address space that can be allocated where it is
> needed on a global basis without a transfer of address space between the
> RIRs.
>
>
>


As it's written, I am not in favor of this policy.

If the author(s) would make the following change, I'd reconsider:

Section A, Para 2, line 3:

shall voluntarily, at quarterly intervals, return any such recovered address
space to
        --------------

This would allow us to comply if local conditions permitted, and if this
policy didnt work out as planned, opt out and stave off any potentially
serious damage. Phase B allocation routine seems speculative. Who knows what
the pool size will be at any given time and who will get the most benefit?
IT doesn't sound like it supports a needs based system in a fair manner.

Undoing or changing a global policy takes *years* and can be thwarted by a
single RIR under the current system. If there were a disagreement related to
any flaw, any RIR could be left holding the bag and out in the cold.

This policy reminded me of TARP, the big bank bailout. There should also
potentially be restrictions on what this returned space could be used for
and for how long..


Best Regards,

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090210/ab17c9b9/attachment.htm>