Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

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

Vincent Ngundi vincent at kenic.or.ke
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>


More information about the RPD mailing list