Author(s):! Omo Oaiya, WACREN ! Joe Kimaili, Ubuntunet Alliance! Alain P. AINA, WACREN
AFRINIC-24
History: 2007 - 2011
IPv4 Global Soft landing! AFPUB-2009-v4-001 Global Policy for the Allocation of the Remaining IPv4 Address Space 2) Incentive
The exhaustion of IPv4 address space is projected to take place within
This proposal seeks to focus on measures that should be taken globally in the address management area in order to prepare for this situation in all RIR regions and to assure the equal distribution of the IANA remaining IPv4 address space across RIR regions, this policy proposal the next few years.
describes a process for the distribution of the remaining IPv4 space from IANA to the existing RIRs
IPv4 Global Soft landing(2) Global Policy for the Allocation of the Remaining IPv4 Address Space
3) Proposal
This policy describes the process for the allocation of the remaining IPv4 space from IANA to the RIRs. When a minimum amount of available space is reached, one /8 will be allocated from IANA to each RIR, replacing the current IPv4 allocation policy. In order to fulfill the requirements of this policy, at the time it is adopted, one /8 will be reserved by IANA for each RIR. The reserved allocation units will no longer be part of the available space at the IANA pool. IANA will also reserve one /8 to any new RIR at the time it is recognized. The process for the allocation of the remaining IPv4 space is divided in two consecutive phases
IPv4 Global Soft landing(3) Global Policy for the Allocation of the Remaining IPv4 Address Space
Rationale
The IANA pool of allocation units of IPv4 addresses (/8s) is decreasing rapidly; and to continue applying a global coordinated policy for distribution of the last piece(s) of each RIR's unallocated address block does not match the reality of
Issues each RIR region will face during the exhaustion period vary by region as the level of development of IPv4 and IPv6 are widely different. As the situation in each RIR region.
a result, applying a global coordinated policy may adequately address issues in a certain region while it could not be work for the others.
IPv4 Global Soft landing(4) Global Policy for the Allocation of the Remaining IPv4 Address Space
Rationale
For example, in a region where late comers desperately need even small blocks of IPv4 addresses to access to the IPv4 Internet, a policy that defines the target of allocations/assignments of IPv4 address space to the late comers would be appropriate in such region. This would allow availability of IPv4 address space for such requirements for more years.
Another example comes from difference in IPv6 deployment rate. For a region where IPv6 deployment rate is low, measures may be necessary to prolong IPv4 address life for the existing business as well as for new businesses until networks are IPv6 ready. Some regions may have strong needs to secure IPv4 address space for translators.
IPv4 Global Soft landing(5) Global Policy for the Allocation of the Remaining IPv4 Address Space
Global IPv4 Soft landing(6)
103/8
102/8
179/8
02/02/2011
185/8
104/8
IPv4 Soft landing policy ! AFPUB-2010-v4-005 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 a strategy for allocation period. This document proposes and Assignment and maintenance of AfriNIC's IPv4 pool post exhaustion. This policy begins when AfriNIC starts to allocation space from the Final /8
Problem statement 1) 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 set the maximum to be /13 instead of /10 and in phase 2, the maximum to /22 and the minimum to /24. It makes no difference between existing LIRs or End-Users and new ones. The policy also did not impose 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.
Total allocation/assignment
Allocation by length: /14 - /11
20 18 16 14 '"/14"'
12
'"/13"'
10
'"/12"'
8
'"/11"'
6 4 2 0 11
12
13
14
15
2016
Allocation by length: /22 - /15 250
200
'"/24"' '"/23"'
150
'"/22"' '"/21"' '"/20"'
100
'"/19"' '"/18"'
50
'"/17"' '"/16"' '"/15"'
0 11
12
13
14
15 2016
Members with both v4 & v6
Proposals 2) 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)
Current Allocations/Assignment rules Pool: All IPv4 space except 102/8
ü max allocation/assignment:/10 ü min allocation/assignment:/22 LIR &/24 EU ü Reserved /16 for IXPs
• allocation period: 12 months • 80% utilization before additional
Soft landing (current/proposal) Phase1:(allocation from 102/8) Pool: 102/8 and any others
max alloc/assign: from /10 to /13 min alloc/assign: /22 LIR & /24 EU • allocation period from 12 to 8 months • 90% utilization before additional • no limit on number of requests or total allocation • no difference between new and old members • IPv4 policies requirements
Phase1: (allocation from 102/8) Pool: 102/8 and any others
max alloc/assign: from /10 to /15 min alloc/assign: N/A • allocation period from 12 to 8 months • 90% utilization before additional • no limit on number of requests or total allocation • no difference between new and old members • IPv4 policies requirements
