[rpd] Proposal Update received: IPv4 Soft Landing-bis

Wed Apr 19 19:29:29 UTC 2017

Hello again brother Dewole,

So it means the IP address will not get finished in time for others to also
get something. This means its a good thing and also IPv6 is there.

I read another proposal it says some people which the Afrinic given the IP
addresses not using them fully. This means a lot more IPs is there and
shall be given to others who need some IP.

So the softlanding will keep some the IP address to exhaust slowly but i
think every person will come to get immediately and finish it?

Ok how will the Afrinic make more money when the IPv4 is finish?

Sorry if i ask to many questions bra...

Best Regards,

Tutu Ngcaba
Kwazulu Techno Hubs
South Africa

On 19 Apr 2017 1:46 a.m., "Dewole Ajao" <dewole at forum.org.ng> wrote:

> Dear PDWG members,
>
> This is to inform you that authors of the policy proposal named " IPv4
> Soft Landing-bis" have submitted an updated version as displayed below and
> online at https://afrinic.net/en/community/policy-development/
> policy-proposals/2075-ipv4-soft-landing-bis
> <https://afrinic.net/en/community/policy-development/policy-proposals/2073-internet-number-resources-review-by-afrinic>
>
> Please take some time to go through the proposal contents and provide your
> feedback.
> Thank you.
> PDWG Co-Chairs
>
> ----------
> Unique identifier (assigned by AFRINIC):AFPUB-2016-V4-001-DRAFT-01
>
> Draft Policy Name: IPv4 Soft Landing-bis
> Author(s)
>      (a) Omo Oaiya | Omo.Oaiya at wacren.net| WACREN
>      (b) Joe Kimaili  | jkimaili at ubuntunet.net  | Ubuntunet Alliance
>      (c) Alain P. AINA  | aalain at trstech.net | Technologies Reseaux et
> Solutions
>
>
> Draft Policy Version 4.0
>
> Submission Date  04/14/2017
>
> Related Policies (where applicable)
>
> Obsoletes :Section 5.4 of the Policy manual  - https://www.afrinic.net/
> library/policies/1829-afrinic-consolidated-policy-manual#s5_4
>
>
> 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 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.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
> Removing minimum allocation size as this may evolve over time during the
> exhaustion period
> Reserving a dedicated block to facilitate IPv6 deployment
>
> 3.0 The Proposal
> 3.1 Policy Manual section to be affected:
> Section 5.4 of the CPM will be replaced as follows:
>
> 5.4 Soft Landing
> 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.
>
> 5.4.1 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 a LIR that assigns address space to
> 'end-users' and has already been 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 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 member of
> AFRINIC, but has not been assigned any IPv4 address space 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
>
> Core DNS service provider:  A core DNS service provider is an organisation
> that provides DNS service for the root level of the DNS tree
> (ICANN-sanctioned root operators) or for an ICANN-sanctioned African ccTLD
> operating in AFRINIC service Region.
>
> 5.4.2 Pre-Exhaustion Phase
> The "Pre-Exhaustion phase" was the period during which AFRINIC allocated
> or assigned IPv4 addresses to LIRs and End Users using the section 5.0 of
> the policy manual and before the Exhaustion phase was triggered.
> This phase ended when AFRINIC publicly announced that the Exhaustion Phase
> has begun.
>
> 5.4.3 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:
>
> 5.4.3.1 Exhaustion Phase 1
> During this phase, allocation/assignment of address space will continue as
> in the Pre-Exhaustion 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 in the process at this point
> will be evaluated as per the new policy
>
> 5.4.3.2 Exhaustion Phase 2
> During this phase the maximum allocation/assignment size will be /22.
> There is no explicit limit on the number of times an organisation may
> request additional IPv4 address space during the Exhaustion Period
>
> 5.4.4 The allocation and assignment period shall be of 8 months.
> The allocation and assignment period shall be of 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 life span of this Policy
>
> 5.4.5 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
> Pre-Exhaustion 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 solely in support of connectivity back to the AFRINIC
> region
>
> 5.4.6 IPv6 deployment reserve
> A contiguous /12 IPv4 address block will be reserved out of the Final /8
> to facilitate IPv6 deployment. When AFRINIC, can no longer meet any more
> requests for address space (from the Final /8 or from any other available
> address space), allocations and assignments from this block must be
> justified by needs for IPv4 addresses space to support IPv6 deployment.
> Examples of such needs include: [IPv4 addresses for Core DNS service
> providers dual stack DNS servers, 464XLAT translators or any other
> translators as defined by the IETF. This block will be subject to a maximum
> size allocation of /24.
>
> AFRINIC staff will use their discretion when evaluating justifications and
> should use sparse allocation when possible within that /12 block.
>
> In order to receive an allocation or assignment from the IPv6 deployment
> reserve:
> The applicant may not have received resources under this policy in the
> preceding six (6) months;
> The applicant must demonstrate that no other allocations or assignments
> will meet this need.
>
> 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):
> A complete new version of the section 3 and so the policy proposal now
> obsoletes the existing IPv4 Soft landing policy instead of amending it.
>
> 22 JUL 2016
> AFPUB-2016-V4-001-DRAFT03 (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.
>
> 14 APR 2017
> AFPUB-2016-V4-001-DRAFT04 (Version 4.0)
> Updated version based on consensus from online and AFRINIC-25 discussions.
> Formatted for direct insertion to CPM
> “current Phase” replaced by “Pre-exhaustion Phase”
>  No more direct reserve for critical Internet Infrastructures
> No more direct reserve for New entrants
> A dedicated reserve to facilitate IPv6 deployment
>
> 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
>
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20170419/e8dd2e67/attachment-0001.html>