[AfriNIC-rpd] Global Policy Proposal for the Allocation of IPv4 Blocks to Regional Internet Registries

Tue Mar 10 13:19:10 UTC 2009

Dear Members,

Attached (and inline), please find a revised version of the above policy.
Revisions on the initial draft have been made to suit the AfriNIC region.

Regards,

Vincent Ngundi
Chair, AfriNIC PDP-MG

####### Global Policy Proposal for the Allocation of IPv4 Blocks to Regional
Internet Registries #######

Proposed by: Adiel A. Akplogan (on behalf of the Drafting committee)

Authors: 

   Adiel A. Akplogan, AfriNIC

   Raul Echeberria, LACNIC

   Maemura Akinori, APNIC

   Geoff Huston, APNIC

   Axel Pawlik, RIPE NCC

   Ray Plzak, ARIN

   Oscar A. Robles-Garay, LACNIC

   Nigel Titley, RIPE NCC

   Paul Wilson, APNIC

Your Organisation: AfriNIC

Policy Affected:   N/A

Date:             09/03/2009

Proposal Version: 3.0

Proposal: Allocation of IPv4 Blocks to Regional Internet Registries

A. Incentive: 

-------------

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

irrelevant. The RIRs may, according to their individual policies and
procedures,

recover IPv4 address space. This policy provides a mechanism for the RIRs to
put

the recovered IPv4 address space back to the the IANA central pool and
provides 

the IANA the policy by which it can allocate them 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.

B. Proposal 

------------

This document describes the policy governing the allocation of IPv4 address

space from the IANA to the Regional Internet Registries (RIRs). This
document

does not stipulate performance requirements in the provision of services by
IANA

to an RIR in accordance with this policy. Such requirements should be
specified

by appropriate agreements among the RIRs and ICANN.

This policy is to be implemented in two phases.

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

2. 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 address space is

depleted; Global Addressing Policy ASO-001-2 (adopted by ICANN Board 8 April
2005 

[1]) is rescinded. IANA will then commence to allocate the IPv4 address
space from 

the recovered IPv4 pool.

The following definitions apply to this policy:

a. Recovered Address Space.  Recovered address space is that address space

   that is returned to an RIR as a result of any activity that seeks to

  reclaim unused address space or is voluntarily returned to the RIR or is

  reclaimed by the RIR as a result of legal action or abuse determination.

  Recovered address space does not include that address space that is
reclaimed

  because of non-payment of contractual fees whose reclamation date is less
than 

   1 year at the time of the report.

b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4

  address space held by an RIR to include recovered address space not yet
returned

   less that address space that is committed in accordance with the RIR's

  reservation policy and practices.

c. Aggregated address blocks. Aggregated address blocks are contiguous

  prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24 and

  10.0.1.0/24 are two contiguous prefixes that can be combined to form an

  aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two contiguous

  prefixes that cannot be combined on a natural bit boundary to form an
aggregated

  block.

2.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. The minimum 'IPv4

  allocation unit' size will be a /24.

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 2.2, the IANA will allocate a single allocation unit, composed
of the

  smallest possible number of blocks available in its IPv4 address pool.

An example of how allocations would be made in practice is included as
Appendix A.

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

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

2.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" [2] 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.

C. Situation in other RIRs

--------------------------

This proposal has been adopted in APNIC region and is being submitted in all
other 

RIR regions, with a view to becoming a global policy [3].

D. References

--------------

[1] Global Addressing Policy ASO-001-2

http://aso.icann.org/docs/aso-001-2.pdf

[2] Internet Protocol v4 Address Space

http://www.iana.org/assignments/ipv4-address-space

[3] ICANN Address Supporting Organization (ASO) MoU

http://aso.icann.org/docs/aso-mou2004.html

Appendix A 

-----------

Example 1:

On 1 March 2020, IANA has the equivalent of a /17 (32,768 addresses) worth
of IPv4 

addresses.

a. IANA calculates that 1/10 of this space is 3,276 addresses.

b. IANA rounds this down to the next bit boundary, which creates a minimum

  allocation size of /21 (2,048 addresses).

c. Each RIR can request and receive a single allocation unit equivalent to a

   /21 worth of addresses.

d. IANA may not be able to allocate a contiguous /21 and may allocate

  discontinuous smaller blocks equivalent to a /21 worth of addresses.

Example 2:

On 1 March 2020, IANA has the equivalent of a /20 (4,096 addresses) worth of
IPv4 

addresses.

a. IANA calculates that 1/10 of this space is 409 addresses.

b. IANA rounds this down to the next bit boundary, which creates a minimum

  allocation size of /24 (256 addresses).

c. Each RIR can request and receive a single allocation unit equivalent to a

   /24 worth of addresses.

d. As the minimum size of address space returned to IANA is /24, IANA can

  allocate a contiguous range of addresses that amount to a /24.

Example 3:

On 1 March 2020, IANA has the equivalent of a /21 (2,048 addresses) worth of
IPv4 

addresses.

a. IANA calculates that 1/10 of this space is 204 addresses.

b. IANA rounds this down to the next bit boundary, which creates a minimum

  allocation size of /25 (128 addresses).

c. A /25 is smaller than the minimum permissible allocation size under this

  policy. Therefore, IANA is unable to make an allocation until more address

   space is received.

####### /Global Policy Proposal for the Allocation of IPv4 Blocks to
Regional Internet Registries #######

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20090310/710ef2ec/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: afpol-v4gb200903.txt
Type: application/msword
Size: 9032 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20090310/710ef2ec/attachment.doc>