IPv4 Soft Landing BIS (Draft 5)

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 of 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 allocations/assignment sizes during exhaustion phases 1 and 2.
• 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 (102/8) of IPv4 address space. The purpose of this policy 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

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 period.

Enforcement of the “soft landing” policy begins when AFRINIC starts to allocate space from the final IANA allocated /8 (102/8).

 

5.4.1 The 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.2c of the Global Policy for the Allocation of the Remaining IPv4 Address Space - http://www.icann.org/en/general/allocation-remaining-ipv4-space.html.

In this Soft-Landing policy section, “last /8” and “102/8” shall be used interchangeably.

 

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 (https://www.afrinic.net/en/library/news/2053-afrinic-enters-ipv4-exhaustion-phase-1) that the Exhaustion Phase has begun.

 

5.4.3 Exhaustion Phases

During the Exhaustion Phase, the following allocation and assignment policy will be used. This 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.

During either of the phases below, all allocations and assignments of IPv4 space will be based on justified and demonstrated need.

The exhaustion phase will be divided into two parts:

 

5.4.3.1 Exhaustion Phase 1

5.4.3.1.1 During this phase, allocation/assignment of IPv4 address space will continue as in Pre-Exhaustion with the minimum set at /24, but the maximum will change from /10 to /18, subject to the provisions in 5.4.6

5.4.3.1.2 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.

5.4.3.1.3 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

Exhaustion Phase 2 will start when no more than a /11 of non-reserved space is available from the final /8. During this phase, the maximum allocation/assignment size will be /22, and the minimum shall remain at /24, subject to the provisions in 5.4.6

 

5.4.4 Eight (8) months planning window (Allocation and assignment period).

The allocation and assignment period shall be for 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

5.4.5.1 In order to receive IPv4 allocations or assignments during the Exhaustion Phase, the LIR or End User must meet IPv4 allocations or assignment policy requirements (by demonstrating and justifying the need for requested space) and must demonstrate to have efficiently used at least 90% of all previous allocations or assignments (including those made during both the Pre-Exhaustion and the Exhaustion Phase).

5.4.5.2 In the case of new LIRs or End Users (those that have no previous allocations or assignments prior to the Exhaustion phase), this requirement does not apply to their first allocation or assignment request.

5.4.5.3 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

5.4.6 Allowable Limits & Subsequence

 

5.4.6.1 When an organization requests additional IPv4 address space in both Phase 1 and Phase 2, such an organization’s total allocations/assignments must not exceed the maximum allowable prefix of /18 for Exhaustion Phase 1 and /22 for Exhaustion Phase 2.

5.4.6.2 Not withstanding 5.4.6.1, an organization that has received the maximum allowable prefix in each phase can only request for another round of allocation/assignment in the same phase (as per 5.4.6.1) after 24 calendar months waiting period.

 

5.4.7 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.

 

5.4.7.1 AFRINIC staff will use their discretion when evaluating justifications and should use sparse allocation when possible within that /12 block.

 

5.4.7.2 In order to receive an allocation or assignment from the IPv6 deployment reserve:

5.4.7.2.1 The applicant may not have received resources under this policy in the preceding six (6) months;

5.4.7.2.2 The applicant must demonstrate that no other allocations or assignments will meet this need.

5.4.7.2.3 Exceptionally for this IPv6 reserve, Core DNS Service providers as defined in 5.6.4.4.2 will also include ICANN sanctioned African ccTLDs operating in the AFRINIC service region.

 

4. Acknowledgements

We thank authors of the Soft Landing–SD policy proposal and the community for their contributions.

 

5. 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
27 JUN 2017	AFPUB-2016-V4-001-DRAFT05 (Version 5.0): Introduced “Allowable Limits & Recurrence” – clauses 5.4.6.1 and 5.4.6.2 (a 24-month waiting period for a member that has received the maximum allocation limit per phase to return for more space). Restored minimum assignment/allocation size in exhaustion to /24 Removed definition of “Core DNS Services provider” and other definitions that were not necessary. Addressed most issues in the staff assessment report of AFPUB-2016-V4-001-DRAFT04

 

6. References

Global Policy for the Allocation of the remaining IPv4 address pool:

http://www.AFRINIC.net/en/library/policies/135-afpub-2009-v4-001

 

Staff Assessment

Index: Staff Assessment Considerations

The following issues raised by AFRINIC staff in their assessment of Soft Landing BIS Version 4 have all been addressed in Version 5 as shown in the table:

Issue	Action
The definition of "exhaustion phase" is not clear. The current soft landing policy defines it, but the definition would be deleted if this proposal is passed, and that would leave us without a good definition.	Seems to be well defined in 5.4
HTML links should be expanded to be visible in text versions or printed versions of the proposal	N/A
In the introduction to 5.4, the existing policy has three paragraphs and the new one has one paragraph. There is no explanation for why the additional information was removed.	5.4 has been reworded to include omitted text.
In 5.4.1 "Definitions", why do we have a definition of LIR that is different from the one in CPM 2.3? We would prefer to see all (general) definitions in section 2 of the CPM - unless they are explicitly specific to the soft-landing section of the CPM	Done
The definitions of "existing LIR" and "existing end user" are not clear. It appears authors meant to refer to members who joined AFRINIC and received address space before exhaustion phase started. In any case, the remainder of the policy does not use these definitions, so the definitions could be deleted.	Both definitions have been removed
The definition of "new LIR" and "new end user" means that somebody who joins today will be classified as "new" and they will remain as "new" forever. Is that the authors' intent?  In any case the definition is used only once, in 5.4.5. There's no need for a definition if the text in 5.4.5 is written carefully.	New LIR/EU deleted from 5.4.1 and 5.4.5 reworded
In the definition of final /8, we suggest that authors could specify that it's 102.0.0.0/8.	Done
In 5.4.2 - note that the term "Current phase" from the old soft landing policy is being renamed to "Pre-exhaustion phase". The name "pre-exhaustion phase" is better, but we note that some other documents might need to be edited to take the change into account.	N/A
In 5.4.3.1, for consistency, please explicitly say IPv4 in "allocation/assignment of IPv4 address space"	Done
In 5.4.3.1 "allocation/assignment of address space will continue as in the Pre-Exhaustion ". We understand that existing requirements for justified need will remain. We suggest clarifying this, and lifting it from 5.4.3.1 to 5.4.3, so it applies to all phases. The text in 5.4.5 "must meet IPv4 allocations or assignment policies requirements" also implies justified need, but again it could be made clearer.	Justified need for all phases added to 5.4.3 (and also in 5.4.5)
In 4.5.3.1 "no explicit minimum" is a change from the old soft landing policy.  "No explicit minimum" implies that the minimum will be /32, but staff would prefer to retain a minimum of /24. Allocation or assignment of blocks smaller than /24 will cause operational difficulties for staff (as well as on the internet in general) and will require software changes.	Minimum adjusted to /24
In 5.4.3.2, authors should state when phase 2 begins. Currently, the start of phase 2 is implied by one of the bullet points under 5.4.3.1, but it would be better if 5.4.3.2 explicitly stated the conditions for phase 2 to begin.	Clarified in 5.4.3.2
In 5.4.3.1 "For the avoidance of doubt all applications in the process at this point will be evaluated as per the new policy".  This should probably apply to the beginning of phase 2 as well as to the beginning of phase 1.	N/A
In 5.4.3.2 "There is no explicit limit on the number of times an organisation may request additional IPv4 address space during the Exhaustion Period". Please clarify whether this applies only to phase 2, or also phase 1.  Staff are concerned about the possible increase in workload cause by repeated small requests from the same member, and suggest that some method of rate limiting should be added, such as a limit to the number of requests per year.	“Subject to the provisions of 5.4.6” has been added to both phases.
5.4.7 reserves a /12 to facilitate IPv6 deployment.  What happens to the /12 that was reserved by the old soft landing policy for "some future uses, as yet unforeseen"?  We think that the old reservation is cancelled and the new reservation replaces it, but we would like clarity.  We also understand that the reserved space would not be touched until no other space is available at all, and if address space is subsequently returned to AFRINIC (after the reserve starts being used) then the returned space would be handled under the rules of Phase 2.	Leave to staff. The old /12 can be carried over as the same reservation.
In 5.4.7, "AFRINIC staff will use their discretion when evaluating justifications and should use sparse allocation when possible within that /12 block." Please separate these two very different ideas into at least two sentences, but preferably two separate numbered sub-sections.	Done
Authors are generally advised to use numbered sections instead of bullet lists, for ease of reference in future discussion or correspondence.	N/A
Authors are also advised to generally make an effort to keep the numbering in the new proposed policy aligned with the numbering in the current policy in the CPM.	N/A

---

 

STAFF ASSESSMENT for AFPUB-2016-V4-001-DRAFT05: IPv4 Soft Landing BIS (v5)

Proposal	AFPUB-2016-V4-001-DRAFT05
Title	IPv4 Soft Landing BIS (v5)
URL	https://www.afrinic.net/fr/community/policy-development/policy-proposals/2153-ipv4-soft-landing-bis
Assessed	24th August 2017

 

1. Staff Understanding of the Proposal

1. Complete replacement for the current IPv4 Soft Landing policy (replaces entire CPM 5.4)
2. Makes resource provisions for new LIRs and End-Users, something lacking in current CPM 5.4.
3. Creates a reserved & dedicated (IPv4 /12) block for companies needing IPv4 space to support IPv6 deployment.
4. Introduces new values for the maximum allocation/assignment sizes as follows:
   1. Phase 1: Maximum /18, minimum /24
   2. Phase 2: Maximum /22, minimum /24
5. Puts in place a 24-month waiting period for a member that has received the maximum allocation limit per phase. (A member must wait 24 months before requesting another allocation in case such a member has consumed their maximum allocation in any given phase).

 

2. Staff Comments

1. The proposed new 5.4.3 that says "during either of the phases below, all allocations and assignments of IPv4 space will be based on justified and demonstrated need" could be further clarified to refer to "justified and demonstrated need according to policies in effect in the pre-exhaustion phase, in addition to restrictions that apply during the exhaustion phases".
2. The proposed new 5.4.6.1 says "When an organization requests additional IPv4 address space in both Phase 1 and Phase 2, such an organization’s total allocations/assignments must not exceed the maximum allowable prefix of /18 for Exhaustion Phase 1 and /22 for Exhaustion Phase 2."  This text refers to the organization’s total holdings, but we think the intention was to refer to the additional space that the organisation received during phase 1, or the additional space received during phase 2.
3. The way the proposed new 5.4.6.2 overrides 5.4.6.1 is difficult to understand.  We suggest the following text, which we hope expresses the authors' intent more clearly:

 

5.4.6.Allowable Limits 5.4.6.1 Within any 24-month period during Exhaustion Phase 1, an organisation may receive one or more allocations/assignments totaling the equivalent of a /18. 5.4.6.2 Within any 24-month period during Exhaustion Phase 2, an organisation may receive one or more allocations/assignments totaling the equivalent of a /22.

 

1. In 5.4.7, we suspect that the authors' intent is that the reservation under the existing 5.4.7.1 "for some future uses, as yet unforeseen" falls away, and is replaced by the new reservation under the proposed new 5.4.7 "to facilitate IPv6 deployment".  In other words, there is only one /12 reservation, not two /12 reservations (one from the old Soft-Landing policy and one from this new policy proposal). If this is indeed the authors' intent, then we suggest using text similar to:

 

"A contiguous /12 IPv4 address block will be reserved out of the Final /8 to facilitate IPv6 deployment.  For the avoidance of doubt, this replaces the /12 reservation for some future use that was present in a previous version of the IPv4 soft landing policy."

 

1. In 5.4.7, "This block will be subject to a maximum size allocation of /24" does not specify a minimum size. Please specify the minimum size.  If the minimum is smaller than /24 then implementation will be much more difficult.
2. In 5.4.7.2.3, please clarify whether ccTLDs are restricted to the two-letter country code TLDs, or whether IDN ccTLDs are alsoAccording to https://www.iana.org/domains/root/db and https://www.icann.org/resources/pages/fast-track-2012-02-25-en, ICANN uses the term "IDN ccTLD" for IDN TLDs associated with country names (such as “جزائر.” or "xn--lgbbat1ad8j" for Algeria).

 

3.Comments from Legal Adviser

None Observed

 

4.Implementation

 

4.1 Timeline & Impact

AFRINIC will take approximately 2 months to implement this proposal after ratification. (Implementation actions are listed in 4.2 below).

 

4.2 Implementation Requirements

• Codification of new minimum and maximum allocation sizes in MyAFRINIC and whois.
• Codification of "waiting period" into MyAFRINIC.
• Revision of Resource Request forms (in MyAFRINIC and NMRP).
• Updating of internal process documents.
• Updating CPM sec 5.4 as appropriate.