Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA

Summary of proposal:

This proposal describes the process that IANA will follow to allocate IPv4 resources to Regional Internet Registries (RIRs) after the central pool of addresses is exhausted.

The processes for how IPv4 space may be placed in the IANA Recovered IPv4 Pool is out of the scope of this proposal.

Policy text:

New policy text

[Following text will result in a new RIPE Policy Document “Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA”]

Abstract

Upon adoption of this IPv4 address policy by the ICANN Board of Directors, the IANA shall establish a Recovered IPv4 Pool to be utilized post RIR IPv4 exhaustion as defined in Section 1. The Recovered IPv4 Pool will initially contain any fragments that may be left over in the IANA. It will also hold any space returned to the IANA by any other means.

1.0 Recovered IPv4 Pool

The Recovered IPv4 Pool will be administered by the IANA. It will contain:

1. Any fragments left over in the IANA inventory after the last /8s of IPv4 space are delegated to the RIRs

   • The IANA inventory excludes "Special use IPv4 addresses" as defined in BCP 153 and any addresses allocated by the IANA for experimental use.
2. Any IPv4 space returned to the IANA by any means.

The Recovered IPv4 Pool will stay inactive until the first RIR has less than a total of a /9 in its inventory of IPv4 address space.

When one of the RIRs declares it has less than a total of a /9 in its inventory, the Recovered IPv4 pool will be declared active, and IP addresses from the Recovered IPv4 Pool will be allocated as stated in Section 2.0 below.

2.0 Allocation of returned IPv4 address space by the IANA

1. Allocations from the IANA may begin once the pool is declared active.
2. In each "IPv4 allocation period", each RIR will receive a single “IPv4 allocation unit” from the IANA.
3. An "IPv4 allocation period" is defined as a 6-month period following 1 March or 1 September in each year

4. The IANA will calculate the size of the "IPv4 allocation unit” at the following times:

   • When the Recovered IPv4 Pool is first activated
   • At the beginning of each IPv4 allocation period

To calculate the "IPv4 allocation unit" at these times, the IANA will use the following formula:

IPv4 allocation unit = 1/5 of Recovered IPv4 pool, rounded down to the next CIDR (power-of-2) boundary.

No RIR may get more than this calculation used to determine the IPv4 allocation unit even when they can justify a need for it.

The minimum "IPv4 allocation unit" size will be a /24. If the calculation used to determine the IPv4 allocation unit results in a block smaller than a /24, the IANA will not distribute any addresses in that IPv4 allocation period.

3.0 Reporting

The IANA may make public announcements of IPv4 address transactions that occur under this policy. The IANA will make appropriate modifications to the "Internet Protocol V4 Address Space" page of the IANA website [1] 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.

4.0 Attribution

This document is compiled from policies developed by the RIPE community.

The following people actively contributed by making proposals through the RIPE Policy Development Process:

Alejandro Acosta, Nicolas Antoniello, S. Moonesamy, Douglas Onyango, Medel Ramirez, Philip Smith, Masato Yamanishi.

5.0 References

[1] "IANA IPv4 Address Space Registry", February 2011 http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml

Rationale

a. Arguments supporting the proposal

The policy provides a mechanism for the ongoing distribution of IPv4 address space, while removing the areas of 2009-01 that were problematic for the ARIN community, and removing the problematic areas of 2010-05. That is, the proposal:

• Permits regional variation in runout policy amongst RIRs to be accounted for in the distribution of the Recovered IPv4 Pool
• Prevents the possibility of a single RIR being eligible to be allocated the entire Recovered IPv4 Pool in the first (and perhaps only) allocation period

• Removes two areas of policy that have failed to reach agreement in previous attempts at this proposal:

  • How addresses should be placed in the Recovered IPv4 Pool
  • References to how transfers should or should not take place
    
    

b. Arguments opposing the proposal

This proposal does not provide details of how address space may be returned to the IANA IPv4 Recovered Pool.

Note: In order to provide additional information related to the proposal, details of an impact analysis carried out by the RIPE NCC are documented below. The projections presented in this analysis are based on existing data and should be viewed only as an indication of the possible impact that the policy might have if the proposal is accepted and implemented.

A. RIPE NCC's Understanding of the Proposed Policy

The RIPE NCC understands this policy as follows:

• It describes how the IANA will distribute IPv4 addresses to RIRs post-depletion, it does not describe how RIRs may or may not return IPv4 addresses to the IANA post-depletion. There is currently no RIPE policy concerning returning address space to the IANA.
• The IANA will declare the Recovered IPv4 Pool active once the first RIR has less than a /9 in its inventory of IPv4 space. This includes any "last /8" space as defined in the RIR's "soft landing" policies.
• Due to the fixed schedule for allocating space from the Recovered IPv4 Pool and the way the "IPv4 allocation unit" is calculated, there may be unused address space in the Recovered IPv4 Pool that cannot be allocated until the next "IPv4 allocation period" happens, even though there may be RIRs who have fully depleted their entire IPv4 inventory.

B. Impact of Policy on Registry and Addressing System

Address/Internet Number Resource Consumption:

Not applicable. There are no data to foresee the amount of IPv4 address space available in the Recovered IPv4 Pool.

Fragmentation/Aggregation:

There is not enough data to perform a reliable analysis for the proposed policy regarding its fragmentation/aggregation impact. A list of unknown factors that could affect the consequences of it is as follows:

- Number, size and the possibility of aggregation of fragments in the IANA pool

- The size of requests received after this proposed policy is in place, and their relation of the sizes of blocks the RIPE NCC will receive from IANA due to this policy

C. Impact of Policy on RIPE NCC Operations/Services

Registration Services:

After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.

Billing/Finance Department:

After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.

RIPE Database:

After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.

D. Legal Impact of Policy

After analysing the data that is currently available, the RIPE NCC does not anticipate that the implementation of this proposed policy will cause any significant legal implications