IPv4 Soft Landing Policy - AFPUB-2010-v4-005-draft-05
|Draft Policy Name||IPv4 Soft Landing|
|Draft Policy Version||14|
|Submission Date||14 Nov 2011|
1) Summary of the Problem Being Addressed by this Policy Proposal
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.
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
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:
- IPv4 Allocation Policy (AFPUB-2005-v4-001)
- Proposal to Change the Allocation & Assignment Period to 12 months (AFPUB-2007-GEN-001)
- 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 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
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:
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:-
a) Exhaustion Phase 1
b) Exhaustion Phase 2
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
3.9.1) 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.
3.9.2 )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.
Thanks to RPD-ML and especially Alain Aina and Alan Barrett for their contributions.
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
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
Removed 4 blocks as maximum possible allocation blocks in policy to eliminate the possibility of remaining with unusable space in the pool
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
Made all the allocation/assignments only usable within the AfriNIC region to curb Black Market practices that could crop up post exhaustion)
Changed the Problem Statement due to Global IPv4 free pool running out
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
Change 3 to include "assigned and/or allocated" for clarity.
Change Minimum allocation/assignment size to /24 for Exhaustion Phase 1
Remove Percentage size on 3.8
|13.05.2008||Similar proposal forwarded to rpd mailing list by Adiel.|
|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. New reference now AFPUB-2010-v4-004.|
|18.11.2010||Author posts updated copy of proposal to mailing list.|
|18.11.2010||Updated copy of policy proposal posted online. New reference now AFPUB-2010-v4-005.|
|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||Updated version of proposal posted to website and rpd mailing list [https://lists.afrinic.net/pipermail/rpd/2011/001382.html]|
|10.05.2011||Updated version of proposal posted to website and rpd mailing list [https://lists.afrinic.net/pipermail/rpd/2011/001628.html]|
|28.05.2011||15 Days Last Call for Comments ends. PDWG co-chairs declare No Consensus|
|05.08.2011||Updated version of proposal posted to website and rpd mailing list|
|05.09.2011||Last Call starts <https://lists.afrinic.net/pipermail/rpd/2011/001846.html>|
|21.09.2011||Last Call closed <https://lists.afrinic.net/pipermail/rpd/2011/001867.html>|
|14.11.2011||PDWG co-chairs declare consensus <https://lists.afrinic.net/pipermail/rpd/2011/001904.html>|
|22.11.2011||Proposal expires after one year of inactivity. *05.09.2011 - Last Call starts|
Le système hiérarchique des nom des domaines permet des noms de domaine à être associé à des adresses IP et la résolution inverse exécute la fonction contraire.