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

Sun Feb 21 18:38:04 UTC 2016

Dear members,

This is to inform that an update has been published for this proposal.

Details can be found at the following URL:

http://afrinic.net/en/community/policy-development/policy-proposals/1625-soft-landing-bis-draft-02-

ID: AFPUB-2016-V4-001-DRAFT-02

Regards
On 9 Feb 2016 2:46 p.m., "Seun Ojedeji" <seun.ojedeji at gmail.com> 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.net, WACREN
> b. Joe Kimaili, jkimaili at ubuntunet.net, Ubuntunet Alliance
> c. Alain P. AINA, aalain at trstech.net, TRS
>
> Url:
> https://afrinic.net/en/community/policy-development/policy-proposals/1609-soft-landing-bis
> <http://www.afrinic.net/en/community/policy-development/policy-proposals/1157-out-of-region-use-of-afrinic-internet-number-resources>
>
> 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:
> http://www.afrinic.net/en/library/policies/135-afpub-2009-v4-001
>
>
>
> *6.0) Frequently Asked Questions*
> Please click here
> <https://afrinic.net/en/community/policy-development/policy-proposals/1611-soft-landing-bis-policy-faq>
> to read through some important frequently asked questions behind
> understanding the content in this proposal.
>
> Best Regards
> Relevant Url:
> 1. Policy Development process:
> http://afrinic.net/en/community/policy-development
> --
> ------------------------------------------------------------------------
>
> Sami Salih & Seun Ojedeji
> PDWG Co-Chairs
>
> Bringing another down does not take you up - think about your action!
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20160221/bc683af7/attachment.html>