Clarification on temporary resource usage

Proposal

1.0 Summary of the problem being addressed by this proposal

With IPv4 exhaustion coming, IPv4 resource assignments need better management because of scarcity. For instance, what happens if some entities request a /20 worth of IPv4 for temporary usage during soft landing phase 2? With current IPv6 evolution, we think entities requesting temporary resources should deploy more IPv6 prefixes than IPv4 prefixes.

2.0 Summary of how this proposal addresses the problem

This proposal aims to restrict the size of IPv4 resource requests for temporary use such as conferences and meetings and in addition, encourages IPv6 usage for those purposes. We believe that IPv6 is now mature enough to be deployed for this kind of usage.

Any IPv4 space requested for temporary usage should not be more than /22 - especially for meetings and events. The requesting entity should use IPv6-only on their networks and deploy IPv4 at the edge of the network using an IPv6 transition mechanism.

Lastly, we believe the title of this section of the CPM should reflect exactly the fact that we are dealing with assignments only and not allocations too.

3.0 Proposal

CPM 9.0 to be modified as follows:

4.0 References

Policy Implementation Experience Report presented during AFRINIC 27 - 30 Nov 2017:

https://youtu.be/YZq7pvUwWk0?t=35799

Revision History

Staff Assessment

Staff Assessment Report 

Download PDF

1.0 Staff Understanding of the Proposal

1. The proposal aims to encourage entities needing space for temporary usage (under current CPM 9.0) to use more IPv6 than IPv4 space, premised on the fact that in the current period of IPv4 space scarcity, IPv4 space needs better management especially during phase 2 where a request for temporary IPv4 space may be larger than the maximum allowable assignment.
2. The proposal puts a restriction to the size of IPv4 PI space that can be issued for temporary use, such as for conferences and meetings, to /22 (but can be less, if the need has not been demonstrated by the requesting entity).
3. Temporary resources are assigned (issued) for a maximum duration of one month.
4. The proposal suggests that IPv6 usage is encouraged for those temporary purposes,  since it's now mature enough to be deployed for this kind of usage (as stated in the problem statement: The requesting entity should use IPv6-only on their networks and deploy IPv4 at the edge of the network using an IPv6 transition mechanism).
5. Other noted changes to current policy:
   1. Rewords CPM 9.0 (title) from "9.0 Temporary Resource Allocations & Assignments"  to "9.0 Temporary Resource Assignments" to reflect the fact that we are dealing with assignments only and not allocations.
   2. Adds a requirement to 9.1 for the activity requiring temporary IP resources to be publicly documented and available on a website reachable at least during the entire period of the event. In the current policy, the text requires that the activity be publicly documented, but does not specify for how long the documentation should remain publicly available.

 2.0 Staff Comments

1. The text in 2.0 "How this proposal addresses the problem"  which reads "The requesting entity should use IPv6-only on their networks and deploy IPv4 at the edge of the network using an IPv6 transition mechanism."should be moved to preferably proposed 9.2, as it would not make it into the CPM - yet it seems to be a policy implementation action.
2. There are specific known events like AFNOG/AIS and possibly ICANN meetings which require much more than the stipulated /22. They could be adversely affected if restricted to use the /22 maximum.
3. After phase 2 of IPv4 exhaustion, there are no guarantees that IPv4 requests for temporary use will be satisfied, since there is no specific block reserved for this purpose.
4. It's desirable that the proposal stipulates the minimum timeframe before the event at which the temporary resource request should be submitted (say, 3 months before the event). 
5. Staff would ordinarily need to verify that the activity/event is documented on a public website before processing any related request. Therefore, the text' reachable at least during the entire period of the event.' could be reworded to 'reachable at least from the time of submission of the resource request and during the entire period of the event".

3.0 Comments from Legal Counsel 

None

4.0 Implementation

4.1 Timeline & Impact

The proposal will be implemented within the timelines provided for in the PDP.

4.2 Implementation Requirements

1. Updates to internal request evaluation processes, checklists
   1. Verifying that information about the event is documented on a website.
   2. Informing applicants of the technical recommendations in 9.3.
   3. Enforcing the new maximum size of temporary IPv4 assignments.
2. Publishing updated documentation related to temporary resource requests on the AFRINIC website
3. Creation of forms for requesting temporary resources.