<NOTE> | This draft is an archived version. Click here to check the latest draft/version
Details
| Details |
|
Proposal
1.0) Summary of the Problem Being Addressed by this Policy Proposal
The soft landing policy ratified by the board on the 11/11/2011 describes how AFRINIC should manage allocations/assignments from the last /8:
- It defines 2 phases for the IPv4 exhaustion:
- During phase 1, it sets the maximum to be /13 instead of /10
- During phase 2, it sets the maximum to /22 and the minimum to /24.
- It makes no difference between existing LIRs or End-Users and new ones.
- The policy does nothing to encourage IPv6 deployment.
- The IPv4 exhaustion in other regions combined with other factors has imposed huge pressure on AFRINIC IPv4 pool with requests for large IPv4 blocks, with very little IPv6 deployment.
- The pressure on AFRINIC IPv4 pool has led to some policy proposals to reserve some blocks for certain sub-communities.
2.0) Summary of How this Proposal Addresses the Problem
This policy proposal solves the problem described above by:
- Changing the value of the maximum of allocations/assignment size during the exhaustion phase 1(section 3.5.1)
- Imposing IPv6 resources as pre-conditions to IPv4 resources requests during the exhaustion (section 3.8)
- Reserving address spaces for Critical Internet Infrastructures and new LIRs or End-Users (section 3.9.1 & 3.9.2)
- Removing minimum allocation size as this may evolve over time during the exhaustion period (section 3.5.1 & 3.5.2)
3.0) 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
- IPv4 Allocation Policy
- Proposal to Change the Allocation & Assignment Period to 12 months
- Proposal for End User Assignments in the AFRINIC service region.
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 an LIR that assigns address space to 'end-users' and has already been allocated IPv4 address space by AFRINIC.
- New LIR - A New LIR, is an LIR that assigns address space to 'end-users' and is a member of AFRINIC, but has not been allocated any IPv4 address space prior to the Exhaustion phase.
- Existing “End User” - An “End User” is an organisation that has already been assigned IPv4 space by AFRINIC for use in its operational networks.
- New “End User” - A new “End User” is an End User who is a member of AFRINIC, but has not been assigned an IPv4 address space prior to the Exhaustion phase.
- New Internet Exchange Point - A New Internet Exchange Point is an Internet Exchange Point who is a member of AFRINIC, but has not been assigned or allocated any IPv4 address space to the peering LAN prior to the Exhaustion phase.
- 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 the 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
- cannot be fulfilled with the IPv4 address space available in the AFRINIC pool (with the exception of the Final /8), or
- 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 publicly 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 with no explicit minimum but the maximum will change from /10 to /18.
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, the maximum allocation/assignment size will be /22.
3.6 If any LIR or End User requesting IPv4 address space during the Exhaustion:
During exhaustion Phase 2, new LIRs or End-Users can receive only one allocation/assignment from the new LIRs or End-Users reserved pool.
During exhaustion Phase 2, Critical Infrastructure can receive only one allocation/assignment from the Critical Internet Infrastructure reserved pool.
There is no explicit limit on the number of times an organisation 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 allocation/assignment period will remain the same throughout the lifespan 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 meet IPv4 allocations or assignment policies requirements and 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.
LIR and End users requesting IPv4 must have IPv6 resources from AFRINIC (or request concomitantly with the IPv4) or from their upstream.
AFRINIC resources are for AFRINIC service region and any use outside the region should be solely in support of connectivity back to the AFRINIC region
3.9 IPv4 Address space for Critical Internet infrastructures, new LIRs or End-Users and unforeseen circumstances
During exhaustion phase 2, allocations/assignments to critical Internet infrastructures and new LIRs and End-Users will be as below:
3.9.1 Assignments to Critical Internet Infrastructures
A /16 from the final /11 will be held in reserve for exclusive use by critical Internet infrastructures. On application for IPv4 resources, a critical Internet Infrastructure may receive one allocation or assignment (maximum /22).
Critical infrastructures are: ICANN-sanctioned DNS root server operators, IXPs, TLD (Top Level Domain) operators, IANA RIRs
On application for IPv4 resources, an Internet Exchange Point (IXP) will receive one allocation or assignment (maximum /23) according to the following:
- This space will be used to run an Internet Exchange Point peering LAN; other uses are forbidden.
- New Internet Exchange Points will be assigned a maximum of /24. Internet exchange points may return this assignment (or existing PI used as an IXP peering LAN) should they run out of space and receive a larger ( a maximum of/23 if utilisation requires) assignment.
- IP space returned by Internet Exchange Points will be added to the reserved pool maintained for Internet Exchange Point use.
3.9.2 Allocation/Assignments to new LIRs or End-Users
A /14 from the final /11 will be held in reserve for exclusive use by new LIRs or End-Users with no prior IPv4 address space from AFRINIC. On application for IPv4 resources, a new LIR or End-User may receive one allocation or assignment(maximum /22).
3.9.3 Reserve for unforeseen situations
A /13 IPv4 address block will be in reserve out of the Final /8. This /13 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), AFRINIC in consultation with the community via the Policy Discussion Mailing list 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.
4.0 Revision History
| 09 FEB 2016 |
AFPUB-2016-V4-001-DRAFT01 (Version 1.0) Version 1 posted to the rpd mailing list |
| 16 FEB 2016 |
AFPUB-2016-V4-001-DRAFT02 (Version 2.0): |
| 22 JUL 2016 |
AFPUB-2016-V4-001-DRAFT02 (Version 3.0): Maximum Allocation/Assignment size changed from /15 to /18 in phase 1 as per discussions at AFRINC-24 public policy meeting and follow-on discussions on RPD. |
5.0 References
Global Policy for the Allocation of the remaining IPv4 address pool: http://www.AFRINIC.net/en/library/policies/135-afpub-2009-v4-001
6.0 Frequently Asked Questions
Please click here to read through some important frequently asked questions that guide understanding the proposal
Staff Assessment
Staff & Legal Assessment and Comments
Staff Comments:
- The reference to "after the current IPv4 pool is depleted" is not clear. The corresponding phrase in the existing soft landing policy (CPM 5.4) is much more clear: "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"
- The definition of "critical infrastructure" in section 3.9.1 of the proposal is different from that in existing policies (CPM 5.6.4.1 and CPM 6..8.1).
- It will be confusing for staff to deal with several different definitions of critical infrastructure, and we suggest that similar changes be made in other policies that refer to critical infrastructure, or that the definition is given in one place and referred to from other policies.
- Is it really the intent of this policy proposal to include the thousands of new TLDs as critical infrastructure?
- We note that the /16 reserved for critical infrastructure will contain only 64 /22s, and this is much less than the number of DNS TLDs.
- Current active IXP policy not included as the affected policy raising a potential cause of confusion as the approaches in the two policies are not synchronized. The CPM needs not to have any conflicts moving forward.
- Section 3, what is a valid request? Is it a request created (not evaluated or approved) complete with all information required as per our evaluation criteria or an approved request?
- Exhaustion Phase 2: mentions that all existing requests under evaluation shall be evaluated as per new policy. Does it really relate to new policy or new phase that kicks off (exhaustion phase 2)?
- Do we still maintain /24 as a minimum since this is the smallest prefix that can be routed on BGP?
- There is no explicit limit on the number of times an organisation may request additional IPv4 address space during the Exhaustion Period. This statement contradicts the previous 2 statements in the same section 3.6 where it mentions that CI and new members can only receive one allocation/assignment
- No details/guidelines on prefix size or rules provided for other Critical infrastructure mentioned apart from IXP.
Legal: None