Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] Proposal Update (was: Re: New Proposal - "Soft Landing - BIS (AFPUB-2016-V4-001-DRAFT-02)"

McTim dogwallah at
Sun Feb 21 19:07:17 UTC 2016


I am generally supportive of this proposal, I think it is an improvement
over current policy.

I do question this sentence however:

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

Why no limit?



On Sun, Feb 21, 2016 at 1:38 PM, Seun Ojedeji <seun.ojedeji at>

> Dear members,
> This is to inform that an update has been published for this proposal.
> Details can be found at the following URL:
> ID: AFPUB-2016-V4-001-DRAFT-02
> Regards
> On 9 Feb 2016 2:46 p.m., "Seun Ojedeji" <seun.ojedeji at> wrote:
>> Dear Members,
>> We have received a new policy Proposal - "Soft Landing - BIS
>> (AFPUB-2016-V4-001-DRAFT-01)"
>> Draft Policy name: Soft Landing - BIS
>> Unique identifier: AFPUB-2016-V4-001-DRAFT-01
>> Status: Under Discussion
>> Submission Date 06 February 2016
>> Amends:
>> AFPUB-2010-v4-005 (IPv4 soft landing policy)
>> Authors:
>> a. Omo Oaiya, omo at, WACREN
>> b. Joe Kimaili, jkimaili at, Ubuntunet Alliance
>> c. Alain P. AINA, aalain at, TRS
>> Url:
>> <>
>> Text Below:
>> *1) Summary of the Problem Being Addressed by this Policy Proposal*
>> The soft landing policy ratified by the board on 11/11/2011 describes how
>> AFRINIC should manage allocations/assignments from the last /8. It defines
>> 2 phases for IPv4 exhaustion. During phase 1, it sets the maximum
>> allocation/assignment 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 does not impose IPv6 deployment.
>> IPv4 exhaustion in other regions combined with other factors has imposed
>> huge pressure on the AFRINIC IPv4 pool with requests for large IPv4 blocks,
>> with very little IPv6 deployment. The pressure on the AFRINIC IPv4 pool has
>> led to some policy proposals to reserve some blocks for certain
>> sub-communities.
>> *2) Summary of How this Proposal Addresses the Problem*
>> This policy proposal solves the problem described above by:
>>     Changing the value of the maximum allocation/assignment size during
>> the exhaustion phase 1.
>>     Imposing IPv6 resources as a pre-condition to IPv4 resource requests
>> during the exhaustion.
>>     Reserving address spaces for Critical Internet Infrastructure and new
>> LIRs or End-Users.
>>     Removing the minimum allocation size as this may evolve over time
>> during the exhaustion period.
>> *3) Proposal*
>> 3.1 The policy proposal changes clause/article 3.5.1 of the current IPv4
>> Soft Landing Policy to:
>> 3.5.1 EXHAUSTION PHASE 1During 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 /15.
>> 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, exhaustion
>> phase 2 will begin.
>> For the avoidance of doubt all applications that will be in process at
>> this point will be evaluated as per the new policy.
>> 3.2 This policy proposal changes Clauses/Articles 3.6, 3.8 and 3.9 of the
>> current IPv4 Soft Landing Policy to:
>> 3.6 If any LIR or End User requests IPv4 address space during Exhaustion:
>> There is no explicit limit on the number of times an organization may
>> request additional IPv4 address space during Exhaustion Phase 1. During
>> exhaustion Phase 2, new LIRs or End-Users can receive only one
>> allocation/assignment from the new LIRs or End-Users reserved pool.
>> 3.8 Allocation CriteriaIn order to receive IPv4 allocations or
>> assignments during the Exhaustion Phase, the LIR or
>> End User must meet IPv4 allocation or assignment policy requirements and
>> 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.
>> LIRs and End users requesting IPv4 space must have IPv6 resources from
>> AFRINIC (or request IPv6 concurrently with their IPv4 request), or from
>> their upstream providers.
>> AFRINIC resources are for the 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 [Internet Exchange Points (IXPs)], critical
>> Internet infrastructure, new LIRs or End-Users and unforeseen circumstances
>> During exhaustion phase 2, allocations/assignments to IXPs, Critical
>> Internet infrastructure and new LIRs and End-Users will be as follows:
>> 3.9.1 Assignments to critical infrastructure
>> A /16 from the final /11 will be held in reserve for exclusive use by
>> critical Internet infrastructure. On application for IPv4 resources, a
>> critical Internet Infrastructure operator may receive one number resource
>> (maximum /22).
>> Critical infrastructure are ICANN-sanctioned DNS root server operators,
>> IXPs, TLD (Top Level Domain) operators, IANA and RIRs.
>>     On application for IPv4 resources, an Internet Exchange Point (IXP)
>> will receive one number resource (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
>> in the IXP peering LAN) should they run out of space and receive a larger
>> (a maximum of /23 if utilization requires) assignment.
>>     IP space returned by Internet Exchange Points will be added to the
>> reserved pool maintained for use by Internet Exchange Points.
>> 3.9.2 Allocations/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
>> number resource (maximum /22).
>> 3.9.3 Reserve for unforeseen situations
>> A /13 IPv4 address block will be in reserved 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 will 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 interests
>> of the community.
>> *4.0) Revision History*
>> 4th February 2016 AFPUB-2016-V4-001-DRAFT01 (Version 1.0) Posted to the
>> rpd mailing list
>> *5.0) References*
>> Global Policy for the Allocation of the remaining IPv4 address pool:
>> *6.0) Frequently Asked Questions*
>> Please click here
>> <>
>> to read through some important frequently asked questions behind
>> understanding the content in this proposal.
>> Best Regards
>> Relevant Url:
>> 1. Policy Development process:
>> --
>> ------------------------------------------------------------------------
>> Sami Salih & Seun Ojedeji
>> PDWG Co-Chairs
>> Bringing another down does not take you up - think about your action!
> _______________________________________________
> RPD mailing list
> RPD at


"A name indicates what we seek. An address indicates where it is. A route
indicates how we get there."  Jon Postel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the RPD mailing list