Policy Archive

Last Modified on -

 

Details
  • Ref. Name:
    AFPUB-2016-V4-001-DRAFT-01
  • Submission Date:
    04 February 2016
  • Old Ref:
    NA
  • Status:
    Under Discussion
  • Amends:
    AFPUB-2010-v4-005 (IPv4 soft landing policy)
  • Obsoletes:
    None
  • Author(s):
    a. Omo Oaiya, omo@wacren.net, WACREN
    b. Joe Kimaili, jkimaili@ubuntunet.net, Ubuntunet Alliance
    c. Alain P. AINA, aalain@trstech.net, TRS

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:

  1. Changing the value of the maximum allocation/assignment size during the exhaustion phase 1.
  2. Imposing IPv6 resources as a pre-condition to IPv4 resource requests during the exhaustion.
  3. Reserving address spaces for Critical Internet Infrastructure and new LIRs or End-Users.
  4. 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

9th 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 to read through some important frequently asked questions that guide understanding the proposal

 

 

 

Last Modified on -

 

Details
  • Ref. Name:
    AFPUB-2016-V4-002-DRAFT01
  • Draft Policy Version:
    01
  • Submitted:
    12 February 2016
  • Status:
    Withdrawn
  • Amends:
    AFPUB-2010-v4-005 (IPv4 soft landing policy)
  • Author(s):
    a. Andrew Alston, andrew.alston@liquidtelecom.com
    b. Kris Seeburn, seeburn.k@gmail.com
    c. Mark Elkins, mje@posix.co.za
    d. Michele McCann, michele@teraco.co.za
    e. John Walubengo, jwalu@yahoo.com
  • Staff Assessment and Comments (see bottom of proposal)

1.0) Introduction

At the time when the original soft landing policy was authored, there were many unknowns and circumstances that could not be foreseen, and as a result of this, the policy in its current form may actually damage the interests of the AFRINIC community rather than assist.

Primary among these, it was not known when the rest of the world would run out of IPv4 space, and the adoption rates of IPv6 were also an unknown quantity.

While it is acknowledged that there is a need to ensure that new entrants into the IP world may require some small amount of IPv4 space, beyond this, further delaying the depletion of IPv4 address space may well be holding the region back while the rest of the world moves on, leaving Africa at a significant disadvantage moving forward.

In the original policy replaced by this, the numbers and allocation levels were also not based on any fundamental justifications, because of the unknowns that existed at the time.

 

2.0) Summary of How this Proposal Addresses the Problem

This proposal still maintains a block of space reserved for new entrants, but beyond that, it allows for the natural depletion of IPv4 through standard demand, and hence encourages the uptake of IPv6 in a more aggressive manner.

 

3.0 Proposal

This policy (IPv4 Soft Landing), applies to the management of address space that will be available to AFRINIC after the current IPv4 pool is depleted.

The purpose of this document 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.

 

3.1 Policy Documents to be Affected

IPv4 Soft Landing Policy

 

3.2 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 assigned or allocated IPv4 address space by AFRINIC.
  • End User - An End User is an organization that receives assignments of IP addresses exclusively for use in its operational networks
  • New Entrant - Ether a member or new member that at the time of application had no previous IPv4 allocations or assignments made to them by AFRINIC, and were not holders of legacy IPv4 space or other IPv4 space sourced either through a potential transfer market or other RIR.
  • New Entrant Block - A /13 block of IPv4 space, reserved in entirety, for allocations of space to members of AFRINIC that at the time of application have no previous IPv4 address allocations.  A /13 was chosen based on historical member growth numbers within AFRINIC, including a certain increase in those allocations to provide sufficient space to allocate to new members for a period of 2 years.
  • Additional and Reclaimed Space - All IPv4 address blocks recovered from non-paying members, as well as all allocations of address space made to AFRINIC by IANA or a replacement organisation.

 

3.3 Summary

This proposal replaces AFPUB-2010-v4-005 with the effect of repealing most of the original policy and replacing it with a policy that deals only with the final /13 worth of space and new entrants, as defined in the definition above.

 

3.4 Current Phase

The "Current Phase" is the status-quo at the time of the adoption of this policy.  During this phase, AFRINIC will continue allocating or assigning IPv4 address space to LIRs and End Users using current IPv4 allocation policies as determined by the community through the policy development working group.

 

The current phase will continue until the depletion of IPv4 address space occurs, with the exception of IPv4 reservations as defined by this and other currently in force policies.

 

3.5 New Entrant Specification

At the time where an application is made that cannot be fulfilled out of the AFRINIC pool, with the exclusion of space reserved by this and other policies, the only applications for IPv4 space which will be further considered by AFRINIC will be for New Entrants. The maximum size of a New Entrant allocation will be a /22.

 

New Entrant applications will be processed on a first in first out (FIFO) basis, that is to say that applications will be processed in the order in which they are received. New Entrant applications with regards to justifications must conform to current IPv4 allocation policies as defined by the community.

 

3.5.1 Clarifications and Other Points

All space falling under the definition of Additional and reclaimed space, as from the time of ratification of this policy, will become part of the new entrant block and will be reserved for members who meet the New Entrant definition.

For the sake of clarity, the policy will be triggered by the application, however, should an application be declared invalid, further processing may continue until once again another application is made that cannot be fulfilled. 

In the event of the final application before depletion of all space outside of the New Entrant Block being too large to fill from the available space, the applicant shall be offered whatever remaining space is available as an alternative.

 

4.0 Revision History

12.02.2016 Proposal in its initial form posted to the mailing list by Andrew Alston
13.02.2016 Proposal in new form with modifications resubmitted to the PDWG Chairs and posted to the mailing list by Andrew Alston
For all but the very first draft; Version 1 - Modified to show a full text rather than purely amendment text against the old policy
Section 3.3 was modified to replace the original summary from the old policy Section 3.5.1 was renamed to CLARIFICATIONS AND OTHER POINTS, and in addition added clarity on the process to trigger the new entrant block.
29.11.2016 Proposal withdrawn by Authors

 

5.0 References

None

 

 

Staff Assessment and Comments

3.0 Proposal

This policy (IPv4 Soft Landing), applies to the management of address space that will be available to AFRINIC after the current IPv4 pool is depleted.”

The current pool consists of available resources from AFRINIC /8s as well as other minority space received from IANA. It is unclear as to what the author means by this statement.

2. Policy will be triggered by an application from new entrant. Current RS processes have to be modified to cater for this. The new entrant block will initially contain a /13, to which shall be added any additional (from IANA)reclaimed resources (from closure process).

3. AFRINIC shall reserve a /13(+ Additional and Reclaimed Space) for new entrants after policy is ratified and all issuance for new registrations will be made out of this reservation. We shall continue evaluation of additional resource requests as it is currently being done. Additional resources (including allocations/assignments to Legacy v4 holders) shall be issued from “(All available resources) - ((Reserved for new entrants) + (Reserved for other policies))”

4. The maximum size of a New Entrant allocation will be a /22 andwill be processed on a first in first out (FIFO) basis.

5. Where anew Entrant Block being too large to fill from the available space, the applicant shall be offered whatever remaining space is available as an alternative.

6. Not clear what is "depletion" means in the sentence “The current phase will continue until the depletion of IPv4 address space occurs".

7. The following sentence is not clear/ambiguous“For the sake of clarity, the policy will be triggered by the application, however, should an application be declared invalid, further processing may continue until once again another application is made that cannot be fulfilled".

8. There is no reservation of resources for unforeseen developments on the internet as in the current softlanding policy.

9. Once this policy is ratified, it automatically unlocks the currently reserved /8 and locks only a /13 for new entrants. Current IP management practices will continue until there is only the last /13, then the provisions in this policy will come into effect.

10. “New Entrant Block - A /13 block of IPv4 space, reserved in entirety, “Does this mean thatthis policy be ratified, its implementation will start with the reservation of a /13 IPv4 prefix?

11. If proposal is ratified when current soft landing (CPM 5.4) is already active - and which may be the case probably Q1 2017, shall we roll back to needs based issuance (pre soft landing), only with the provision for new entrants?

12. Insert explicit sentence for reservation size for new entrants in 3.5

13. Should the /13 for new entrants be reserved ONLY from the last /8? (since there will not be a soft landing policy, as this proposal overhauls it)

14. Proposal should be clear on how it replaces or repeals CPM 5.4 and provide clear text with sub-numbering on how it will be inserted into the CPM

Page 53 of 55