Policy Pre-CPM

Last Modified on -

 

Details

Ref. Name:
AFPUB-2010-v4-005

 Old Ref:
NA		 Status:
Ratified		 Date:
29 July 2011		 Author:
Douglas Onyango | ondouglas@yahoo.com

 

1) Introduction

Because the Global IPv4 free pool has run out, the IANA has implemented the Global Policy for the Allocation of the Remaining IPv4 Address Space, meaning after the Final /8, RIRs will no longer receive Address space from the IANA as in the past. This puts AFRINIC in a precarious situation as the current allocation and assignment Policy cannot be sustained in the mid to longterm.

 

2) Summary of How this Proposal Addresses the Problem

In order to ensure a smooth transition to IPv6, AfriNIC's pool should be managed to provide members with address space after the IPv4 pool is depleted. This will help in maintaining IPv4 networks while deploying IPv6 networks - a practice that characterizes the transition period. This document proposes a strategy for allocation and Assignment and maintenance of AfriNIC's IPv4 pool post exhaustion. This policy begins when AfriNIC starts to allocation space from the Final /8

 

3) The Proposal

This policy (IPv4 Soft Landing), applies to the management of address space that will be available to AfriNIC after the current IPv4 pool is depleted. The purpose of this document is to ensure that address space is assigned and/or allocated in a manner that is acceptable to the AfriNIC community especially during this time of IPv4 exhaustion.

 

3.1) Policy Documents to be affected

 

3.2) Definitions

  • Local Internet Registry (LIR) - A Local Internet Registry (LIR) is an Internet Registry (IR) that receives allocations from an RIR and assigns address space to customers who use its services. LIRs are generally ISPs and their customers are end-users and possibly other ISPs. LIRs must be members of an RIR like AfriNIC; which serves the Africa Region and part of the Indian Ocean (Comoros, Madagascar, Mauritius, and Seychelles).
  • Existing LIR's - An Existing LIR is a LIR that assigns address space to 'end-users' and has already been assigned or allocated IPv4 address space by AfriNIC.
  • New LIR - A New LIR, is a LIR that assigns address space to 'end-users' and is a member of AfriNIC but has not been assigned or allocated any IPv4 address space prior to the Exhaustion phase.
  • End User - An End User is an organization that receives assignments of IP addresses exclusively for use in its operational networks
  • Final /8 block of IPv4 address space, or "Final /8" - The Final /8 block of IPv4 address space, or "Final /8", is the /8 block of IPv4 address space that has been allocated by the IANA to AfriNIC in terms of section 2.2 C of the Global Policy for the Allocation of the Remaining IPv4 Address Space <http://www.icann.org/en/general/allocation-remaining-ipv4-space.html> at the time of exhaustion of the IANA pool of IPv4 address space. AfriNIC's version of the Global Policy for the Allocation of the Remaining IPv4 Address Space is also known as AFPUB-2009-v4-001.

 

3.3) Summary

This proposal describes how AfriNIC shall assign, allocate, and manage IPv4 resources during the "Exhaustion Phase" which begins when AfriNIC first needs to assign or allocate IP addresses from the Final /8 block of IPv4 address space.

 

3.4) Current Phase

The "Current Phase" is the status-quo at the time of adoption of this policy. During this phase, AfriNIC will continue allocating or assigning IPv4 addresses to LIRs and End Users using the current policies, including:

  • AFPUB-2005-v4-001 : http://www.afrinic.net/docs/policies/AFPUB-2005-v4-001.htm
  • AFPUB-2006-GEN-001 <http://www.afrinic.net/docs/policies/AFPUB-2006-GEN-001.htm>, and any future amended versions of such policies.

The current phase will continue until an otherwise-valid request for IPv4 address space from any LIR or end user to AfriNIC either

(a) cannot be fulfilled with the IPv4 address space available in the AfriNIC pool (with the exception of the Final /8), or

(b) can be fulfilled, but would leave the AfriNIC IPv4 address pool empty (with the exception of the Final /8).

 

The request that results in either of the above conditions being fulfilled will be the last IPv4 address space request that AfriNIC will accept from any LIR or End User in the Current Phase. If the request can be processed in terms of the Current Phase policies, then it will be so processed; otherwise, it will be processed in terms of Exhaustion Phase policies.

AfriNIC will publically announce that the Exhaustion Phase has begun at this point. For the avoidance of doubt all applications that are currently in the process at this point will be evaluated as per the new policy

 

3.5) Exhaustion Phase

During the Exhaustion Phase, the following allocation and assignment policy will be used. This policy applies to both LIRs and End Users, and applies to all IPv4 address space allocated, assigned, or otherwise managed by AfriNIC during the transition to and after the beginning of the Exhaustion Phase, regardless of whether or not such IPv4 address space is a part of the Final /8. The exhaustion phase will be divided into two parts:-

 

3.5.1) Exhaustion Phase 1

During this phase, allocation/assignment of address space will continue as in the Current phase (/24 for a EU and /22 for a LIR) but the maximum will change from /10 to /13.

Allocations and assignments will be made from the Final /8 or from any other IPv4 address space available to AfriNIC, until no more than a /11 of non-reserved space is available in the Final /8. At this point the Exhaustion Phase 2 will begin. For the avoidance of doubt all applications will be in the process at this point will be evaluated as per the new policy

 

3.5.2) Exhaustion Phase 2

During this phase a minimum allocation/assignment size will be /24, and the maximum will be /22 per allocation/assignment.

 

3.6) If any LIR or End User requesting IPv4 address space during the Exhaustion

There is no explicit limit on the number of times an organization may request additional IPv4 address space during the Exhaustion Period

 

3.7) The current allocation and assignment period of 12 months shall be changed to 8 months.

The current allocation and assignment period of 12 months shall be changed to 8 months. This will help to ensure that LIRs request only for resources they need in the short to medium term, and promote fairness in the equitable distribution of the last IPv4 address pool. This assignment period will remain the same throughout the life span of this Policy

 

3.8) Allocation Criteria

In order to receive IPv4 allocations or assignments during the Exhaustion Phase, the LIR or End User must have used at least 90% of all previous allocations or assignments (including those made during both the Current Phase and the Exhaustion Phase). In the case of new LIRs or End Users with no previous allocations or assignments, this requirement does not apply to their first allocation or assignment request.

AfriNIC resources are for AfriNIC service region and any use outside the region should be soley in support of connectivity back to the AfriNIC region

 

3.9) IPv4 Address Space Reserve

  • A /12 IPv4 address block will be in reserved out of the Final /8. This /12 IPv4 address block shall be preserved by AfriNIC for some future uses, as yet unforeseen. The Internet is innovative and we cannot predict with certainty what might happen. Therefore, it is prudent to keep this block in reserve, just in case some future requirement creates a demand for IPv4 addresses.
  • When AfriNIC, can no longer meet any more requests for address space (from the Final /8 or from any other available address space), the Board may at its discretion and considering the demand and other factors at the time replenish the exhaustion pool with whatever address space (or part thereof) that may be available to AfriNIC at the time, in a manner that is in the best interest of the community.

 

Acknowledgments - Thanks to RPD-ML and especially Alain Aina and Alan Barrett for their contributions.

 

 

4) History

Date Revision
07.01.2009 Proposal first posted to the mailing list by PDP-MG chair.
13.01.2009 Updated version of proposal is posted to mailing list by author.
13.05.2009 Updated version of proposal is posted to mailing list by author
23.05.2009 Proposal fails to reach consensus at AfriNIC-10 (21.05.2009, Cairo-Egypt)
28.09.2009 Updated version of proposal is posted to mailing list by author.
27.11.2009 Proposal fails to reach consensus at AfriNIC-11
12.05.2010 Author posts updated text of proposal to mailing list. New reference now AFPUB-2010-v4-001
03.06.2010 Proposal reached consensus during AfriNIC-12 in Kigali - Rwanda with some modifications
25.06.2010 15 Days Last Call for Comments period starts
14.07.2010 15 Days Last Call for Comments period ends. Due to objections on during the period, proposal now goes back to mailing list for discussion.
07.11.2010 Author posts updated copy of proposal to mailing list.
08.11.2010 Updated copy of policy proposal posted online.
18.11.2010 Author posts updated copy of proposal to mailing list.
25.11.2010 Proposal finds consensus during AfriNIC-13 in Johannesburg, South Africa
14.11.2010 Staff Comments and Implementation Analysis by AfriNIC is posted to the mailing list
25.01.2011 Author posts updated copy of proposal online, making modifications agreed upon during last public meeting. New reference now AFPUB-2010-v4-005-draft-01
21.02.2011 Updates posted to website and rpd mailing list
10.05.2011 Updated version draft-03 of proposal posted to website and rpd mailing list
28.05.2011 15 Days Last Call for Comments ends. PDWG co-chairs declare No Consensus
30.05.2011 Draft 04 posted to rpd.
10.06.2011 Draft 04 gains consensus at AFRINIC14 subject to some changes
05.08.2011 Updated version draft-05 posted to website and rpd mailing list
05.09.2011 Last Call on draft-05 of the proposal
14.11.2011 Declaration of concensus after last call.
21.11.2011 Ratified by Board (Resolution RESOLUTION [201111.138])

 

 History of modifications:
  • Version 1 - Removed IPv6 Adoption plans and deployment as requirements for receiving IPv4 address space in this policy as Members Technology choices are outside AfriNIC's purview
  • Version 3 - Changed the scope of the document to cover IPv4 address space outside the /8 to avoid writing a new policy for IPv4 address space that AfriNIC might have outside the /8
  • Version 5 - Removed 4 blocks as maximum possible allocation blocks in policy To eliminate the possibility of remaining with unusable space in the pool
  • Version 8 - Changed the Minimum and Maximum Allocation sizes to /24 and /22 respectively to cater for small requests by members transitioning who only need small blocks for interoperability
  • Version 9 - Made all the allocation/assignments only usable within the AfriNIC region to curb Black Market practices that could crop up post exhaustion)
  • Version 10 - Changed the Problem Statement due to Global IPv4 free pool running out
  • Version 11 - Changed the phase names from "Modified status-quo" and "IPv6 Transition" to "Exhaustion Phase 1" and "Exhaustion Phase 2" in response to comments at the AriNIC-13 meeting. Changed wording in 3.5 Exhaustion Phase to cover Address space outside the Final /8 - in response to comments at the AriNIC-13 meeting
  • Version 12 - Change 3 to include "assigned and/or allocated" for clarity.
  • Version 13 - Change Minimum allocation/assignment size to /24 for Exhaustion Phase 1
  • Version 14 - Remove Percentage size on 3.8

Last Modified on -

Details
  • Ref. Name:
    AFPUB-2011-v4-004-draft-01(GPP-IPv4-2011)
  • Old Ref:
    NA
  • Status:
    Implemented
  • Date:
    29 Apr 2011
  • Author:
    • Douglas Onyango
      ondouglas[at]yahoo.com
    • Alejandro Acosta
      alejandro.acosta[at]bt.com | British Telecom
    • S. Moonesamy
      sm+AFRINIC[at]elandsys.com
    • Nicolas Antoniello
      nantoniello[at]gmail.com
    • Medel Ramirez
      medel[at]globetel.com.ph | Globe Telecom, Inc
    • Masato Yamanishi
      myamanis[at]bb.softbank.co.jp | Softbank BB Corp
    • Philip Smith
      pfs[at]cisco.com | Cisco Systems

 

1) Summary of the Problem 

The IANA has now exhausted its pool of IPv4 /8 blocks, having distributed its remaining IPv4 addresses according to the "Global Policy for the Allocation of the Remaining IPv4 Address Space".[1] However, there is the possibility that IANA will receive returned addresses post-exhaustion of its pool of /8s.

An earlier global policy proposal authored by a team consisting of people from each of the five RIRs reached consensus at four RIRs, and was subsequently endorsed by these RIRs' Boards. In the AFRINIC region, this was AFPUB-2009-v4-002, "Global policy proposal for the allocation of IPv4 blocks to Regional Internet Registries". To see the proposal reference number for this proposal in all five RIRs, see Appendix A.

The version approved in the fifth region was substantially rewritten by the ARIN community to meet some of their concerns. However, given the nature of the rewrites, it would have been difficult to reconcile that version with the version that reached concensus in the other four RIRs. Therefore, some members of the ARIN community wrote a new global proposal, "Global Policy for IPv4 Allocations by the IANA Post Exhaustion", which has been adopted in the ARIN region. it is AFPUB-2010-v4-003-draft-02. To see the proposal reference number for this proposal in all five RIRs, see Appendix A. However, there are significant issues with AFPUB-2010-v4-003-draft-02. These are:

The reclamation pool could be exhausted by RIR(s) with high allocation rates after the first (or first few) allocation period(s). There are two main reasons RIRs will have differing allocation rates after the IANA pool is exhausted:

  1. Rate of Internet growth in the region
  2. Policies developed by different regions governing how the last part of their IPv4 addresses are to be managed.

In response to IPv4 exhaustion, some RIR communities have chosen to apply policies to a part of their last IPv4 addresses that aim to assist with a smooth transition to IPv6. An effect of such policies is that it can slow down the consumption of IPv4 addresses allocated under these policies. This side effect would put RIRs that have chosen to adopt such policies at a disadvantage, as they will take far longer to qualify for space under AFPUB-2010-v4-003-draft-02 compared to RIRs that have chosen not to adopt such policies. Therefore, to ensure that regional variation in runout policy amongst RIRs is accounted for, it is important to have an IANA redistribution method that can continue to provide resources to RIRs over more than one (or only a few) allocation periods.

- The definitions of when an RIR is considered to be "exhausted", and therefore eligible for space from IANA, should be more flexible given the very different RIR policy environments and the number of addresses available at any given time.

- Under the redistribution formula proposed in AFPUB-2010-v4-003-draft-02, it is possible for one RIR to be the single eligible RIR in the first IANA allocation period and for that RIR to claim the entire reclamation pool. It is also possible that only one RIR could be eligible during subsequent allocation periods, and take the total IANA pool available at that time.

To prevent this from happening, it is better to have a formula that would allow RIRs to take only a certain fraction of the IANA pool at each allocation period.

A problem with both AFPUB-2009-v4-002 and AFPUB-2010-v4-003-draft-02 is related to the policy for the return of addresses by the RIRs to IANA:

- In AFPUB-2009-v4-002, the return of addresses to the reclamation pool was mandatory. This restriction was of significant concern to the ARIN community.

- In AFPUB-2010-v4-003-draft-02, return of addresses by RIRs is optional, but there is nothing to prevent an RIR which has contributed nothing towards IANA's return pool from claiming part, or indeed all, of the return pool.

 

2) Summary of How this Policy Addresses the Problem

This policy 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.

- Because of the two above issues, this new proposal separates the return of address space to the IANA from the redistribution of that space by the IANA. Instead, the authors of this new proposal treat the return and redistribution as two separate issues that should be treated as separate policies.

A problem with AFPUB-2009-v4-002, AFPUB-2010-v4-003-draft-02, and the first version of AFPUB-2011-v4-004-draft-01 is that attempts to find ways to make "eligibility" and "exhaustion" meet the differing needs of all five RIRs caused problems for at least of the RIRs.

- To avoid this situation, this second version of AFPUB-2011-v4-004-draft-01 invokes the precedent of last global policy for IPv4 distribution by the IANA[1] to propose an alternative way to distribute space from the IANA. That is, that there be an equal distribution of addresses between all RIRs

 

3) Policy

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.

3.1) Recovered IPv4 Pool:

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

a) 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.

b) 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 4.2 below.

3.2) Allocation of returned IPv4 address space by the IANA:

a) Allocations from the IANA may begin once the pool is declared active.

b) In each "IPv4 allocation period", each RIR will receive a single "IPv4 allocation unit" from the IANA.

c) An "IPv4 allocation period" is defined as a 6-month period following 1 March or 1 September in each year.

d) 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.3) 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 [2] 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) Pros/Cons

Advantages:

The policy provides a mechanism for the ongoing distribution of IPv4 address space, while removing the areas of AFPUB-2009-v4-002 that were problematic for the ARIN community, and removing the problematic areas of AFPUB-2010-v4-003-draft-02. 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

Disadvantages:

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

 

5) Timetable for implementation

Once consensus has been reached in each of the five RIR regions, the policy will be forwarded to ICANN for approval and then implemented by the IANA

 

6) References

  1. "Global Policy for the Allocation of the Remaining IPv4 Address Space" http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm
  2. "IANA IPv4 Address Space Registry", February 2011 http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml

 

7) Appendix A

Proposal number given to "Global policy proposal for the allocation of IPv4 blocks to Regional Internet Registries" in each of the five regions:

  • AFRINIC: AFPUB-2009-v4-002
  • APNIC: prop-069
  • ARIN: ARIN-2009-3
  • LACNIC: LAC-2009-01
  • RIPE: RIPE 2009-01

Proposal number given to "Global Policy for IPv4 Allocations by the IANA Post Exhaustion" in each of the five regions:

 

 

History
2011-02-11 RPD mailing list first informed of the proposal’s submission to the ASO-AC. <https://lists.AFRINIC.net/pipermail/rpd/2011/001258.html>
2011-04-28 Proposal formally submitted into the AFRINIC policy process. <https://lists.AFRINIC.net/pipermail/rpd/2011/001481.html>
2011-05-06 Proposal posted to the AFRINIC website. <https://lists.AFRINIC.net/pipermail/rpd/2011/001560.html>
2011-06-08 Proposal discussed at AFRINIC-14 in Dar es Salaam and gains consensus. <https://lists.AFRINIC.net/pipermail/rpd/2011/001759.html>
2011-07-29 Last Call starts <https://lists.AFRINIC.net/pipermail/rpd/2011/001840.html>
2011-08-03 Last Call ends
2011-09-09 PDWG co-chairs declare consensus <https://lists.AFRINIC.net/pipermail/rpd/2011/001853.html>

Page 4 of 12