Resource Transfer Policy (Draft-2) Archived

Proposal

1. Summary of the problem being addressed by this proposal

The current policy fails to support a two-way Inter-RIR policy, thereby hindering smooth business operation, development, and growth in the region. This proposal aims to establish an efficient and business-friendly mechanism to allow a number of resources to be transferred from/to other regions. This proposal outlines a model in which AFRINIC can freely transfer number resources to/from other regions, i.e. RIPE NCC, APNIC, ARIN and LACNIC. This includes both IPv4 addresses and AS numbers.

 

2. Summary of how this proposal addresses the problem

With the exhaustion of IPv4, several regions have adopted transfer policy to accommodate the shortage of resources. Number resources are allowed to transfer within the region itself, as well as with other regions.

Such practice is effective and necessary when we are facing a shortage of resources. This helps facilitate business operation while reducing prices.

Such Inter-RIR transfer, however, is not yet established in AFRINIC. This hinders business operation and development within the African region. The current proposal aims to establish an efficient and business-friendly mechanism to allow a number of resources to be transferred from/to other regions. Before moving to illustrate how this new mechanism works, let’s take a quick look at the situation of the current Consolidated Policy Manual:

In Consolidated Policy Manual updated on 22 Feb 2019, only “IPv4 resources transfer within the AFRINIC region” is mentioned.

Regarding resource transfer to other regions, only the following is mentioned:

5.5.1.1.3 If an LIR plans to exchange or transfer address space, it needs to contact AFRINIC so that the changes are properly registered.

The LIR remains responsible for all the allocations registered in the AFRINIC database until they have been transferred to another LIR or returned to AFRINIC. LIR's must ensure that all policies are applied.

The lack of a clear guideline of resources transfer is detrimental to the continent’s development. It makes business operation difficult and it also hinders new business from establishing in the region.

Also, as Inter RIR policy is enforced in other regions, it is important that AFRINIC keeps up with other RIRs to ensure smooth operation and coordination.

 

3. Proposal

CPM 5.7 will be modified by this proposal as follows: 

Current	Proposed
5.7  IPv4 Resources transfer within the AFRINIC Region Like the other Regional Internet Registries, AFRINIC will soon exhaust its IPv4 pool. In order to meet the needs of late resource requestors, a transfer policy for IPv4 resources within the region is needed. The goal of this policy is to define conditions under which transfers must occur. The policy solves the issue of an African organization needing IPv4 number resources after the exhaustion of the AFRINIC IPv4 pool or when AFRINIC can no longer satisfy the needs of such an organization.	5.7 IPv4 Resources resource transfer Like the other Regional Internet Registries, AFRINIC will soon exhaust its IPv4 pool. In order to meet the needs of late resource requestors, a transfer policy for IPv4 resources within and outside the region is needed. The goal of this policy is to define conditions under which transfers must occur. The policy solves the issue of an African organization needing IPv4 number resources after the exhaustion of the AFRINIC IPv4 pool or when AFRINIC can no longer satisfy the needs of such an organization.
5.7.1 Summary of the policy This policy applies to an organization with a justified need for IPv4 resources that cannot be satisfied by AFRINIC.	5.7.1 Summary of the policy This policy applies to any transfer request raised by a resource holder for resource transfer to and from the AFRINIC region.
5.7.2 IPv4 resources to be transferred - must be from an existing AFRINIC member's account or from a Legacy Resource Holder in the AFRINIC service region.	5.7.2 IPv4 resources to be transferred – any resource holder who posts a transfer request to another party. An agreement of resource transfer shall be provided.
5.7.3. Conditions on the source of the transfer 5.7.3.1 The source must be the current rights holder of the IPv4 address resources recognized by AFRINIC, and not be involved in any dispute as to the status of those resources.	5.7.3. Conditions on the source of the transfer 5.7.3.1 The source must be the current rights holder of the IPv4 address resources registered with any RIR and shall be in compliance with the policies of the receiving RIR.
5.7.3.2 Source entities will not be eligible to receive any further IPv4 address allocations or assignments from AFRINIC for a period of 12 months after a transfer approval.	5.7.3.2  Source entities are eligible to receive further IPv4 allocations or assignments from AFRINIC as long as it complies with current policy.
5.7.3.3 Source entities must not have received a transfer, allocation, or assignment of IPv4 number resources from AFRINIC for the 12 months prior to the approval of transfer request. This restriction excludes mergers and acquisitions transfers.	5.7.3.3 There is no upper limit regarding the amount of transfer, allocation and assignment of IPv4 number resources a source entity can receive as long as the transfer request is carried out under a mutual agreement between the sender and the recipient.
5.7.4. Conditions on the recipient of the transfer 5.7.4.1 AFRINIC must approve the recipient's need for the IPv4 number resources. In order for an organization to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 resource needs before AFRINIC. That is to say, the organization must justify and demonstrate before AFRINIC its initial/additional allocation/assignment usage, as applicable, according to the policies in force.	5.7.4. Conditions on the recipient of the transfer 5.7.4.1 A transfer from another RIR to AFRINIC requires a need-based evaluation. AFRINIC must approve the recipient's need for the IPv4 number resources. In order for an organization to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 resource needs before AFRINIC. That is to say, the organization must justify and demonstrate before AFRINIC its initial/additional allocation/assignment usage, as applicable, according to the policies in force.  A transfer from AFRINIC to another RIR must follow the policy of the receiving RIR.
5.7.4.2 The recipient must be an AFRINIC member, subject to current AFRINIC policies and must sign the Registration Services Agreement for resources being received.	5.7.4.2 The recipient can be any party who reaches an agreement of resource transfer with the sender.
5.7.4.3 Transferred IPv4 legacy resources will no longer be regarded as legacy resources.	5.7.4.3 Transferred IPv4 legacy resources will no longer be regarded as legacy resources.
	5.7.5  Procedure of the resource transfer 5.7.5.1 The transferring party who holds the resources can initiate a transfer request between itself and an external party. If the two parties agree, the transferring party will send a request to the receiving RIR, using a standard template and submit an official agreement of resource transfer to the involved RIR(s). The transfer shall be in compliance with the policies of the receiving RIR. 5.7.5.2 After the receiving RIR approves the transfer, it will notify the transferring RIR, the transferring party and the recipient. The resources will be transferred to the recipient. 5.7.5.3  When the receiving RIR approves the transfer, the resources will be transferred to the recipient.

 

4. References

Inter RIR-policies are adopted in RIPE, APNIC, LACNIC and ARIN. The record of these regions shows that Inter RIR facilitates smooth coordination and operation between RIRs.

The current proposal’s model is based on RIPE’s Inter RIR policy at :

https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/inter-rir-transfers

 

Revision History

Revision History

Date	Details
13 Aug 2020	Version 2:  AFPUB-2019-V4-003-DRAFT02 - Section 5.7.3.1, 5.7.4.1 and 5.7.4.3 have been updated.
30 Oct 2019	Version 1:  AFPUB-2019-V4-003-DRAFT01 - Submitted for discussion

 

AFRINIC Policy Impact Assessment

 

AFRINIC Staff Assessment

 

Date of Assessment	Relevant to Proposal
Aug 2020	AFPUB-2019-V4-003-DRAFT02

 

1.0 Staff Understanding of the Proposal

This policy proposal introduces a two-way inter-RIR transfer policy, thereby allowing IPv4 resources to be transferred within, into and out of the AFRINIC service region.

The conditions are interpreted as follows:-

 

A. for transfers within the region, i.e intra-RIR transfer

• The source entity must be the current holder of the IPv4 resource that is to be transferred.
• The source entity who is posting a transfer request must also provide a resource transfer agreement
• The source entity shall comply with the policies of the receiving RIR.
• There is no limit to the size of the resources transferred
• The Source entity is eligible to receive further IPv4 allocations or assignments from AFRINIC as long as it complies with current policy. There is no upper limit regarding the amount of transfer, allocation and assignment of IPv4 number resources a source entity can receive as long as the transfer request is carried out under a mutual agreement between the sender and the recipient.
• The Recipient of a transfer must justify the IPv4 needs
• The recipient of a transfer in the AFRINIC service region is required to be an AFRINIC member.
• Therefore the recipient of a transfer if not yet an AFRINIC member shall have to apply for membership and undergo a needs-based assessment before a transfer is approved.

 

B. for transfers from AFRINIC to another RIR (inter-RIR transfer)

• The source entity must be the current holder of the IPv4 resource that is to be transferred.
• The source entity who is posting a transfer request must also provide a resource transfer agreement
• The source entity shall comply with the policies of the receiving RIR(see clarification request)
• There is no limit to the size of the resources transferred
• The Source entity is eligible to receive further IPv4 allocations or assignments from AFRINIC as long as it complies with current policy. There is no upper limit regarding the amount of transfer, allocation and assignment of IPv4 number resources a source entity can receive as long as the transfer request is carried out under a mutual agreement between the sender and the recipient. 
• The transferring (Source) party will send a request to the receiving RIR, using a standard template and submit an official agreement of resource transfer to the involved RIR(s). 
• The recipient of the transfer shall be in compliance with the policies of the receiving RIR.
• The receiving RIR shall notify the source entity and the source RIR and recipient if the transfer is approved and the source RIR will then transfer the resources.

It is not clear as to why the source entity shall comply with the policies of the receiving RIR when it operates in the service region of the source RIR.

The recipient entity is interpreted to be different from the source entity and bound to comply with the policies of the receiving RIRs.

By submitting a transfer request to the receiving the RIR and not its RIR, the verification about whether the source entity is the current holder of the resources cannot be done.

 

C. for transfers from another RIR to AFRINIC (inter-RIR transfer)

• The source entity must be the current holder of the IPv4 resource that is to be transferred.
• The source entity who is posting a transfer request must also provide a resource transfer agreement
• The source entity shall comply with the policies of the receiving RIR
• There is no limit to the size of the resources transferred
• The transferring(Source) party will send a request to the receiving RIR, using a standard template and submit an official agreement of resource transfer to the involved RIR(s). The receiving RIR shall notify the source entity and the source RIR and recipient if the transfer is approved and the source RIR will then transfer the resources.
• The recipient of the transfer shall be in compliance with the policies of AFRINIC and be a member

Since AFRINIC has no relationship with the source of a transfer that exists outside its service region, it will not accept any communication from the source organisation(resource holder). It recommends that the latter correspond with its RIR who shall conduct the appropriate vetting of the transfer request received from its resource holder(member or legacy) according to its policies and established business practices. The source RIR shall then communicate with AFRINIC.

AFRINIC will then evaluate the request of the recipient organisation in accordance with its policies and if successful, coordinate the transfer with the source RIR.

 

1.2 Staff Need more clarification from Authors

1. 5.7.3.1 - The source must be the current rights holder of the IPv4 address resources registered with any RIR and shall be in compliance with the policies of the receiving RIR?
   • This statement is not clear as source entities exist in and subject to the policies of either AFRINIC (intra) or another RIR (inter), which are the source RIRs. The source entity has no relationship with the receiving RIR. Can the authors clarify as to what they exactly mean here?
2. 2. 5.7.5.1 speaks of using a standard template. Clarification is needed on this standard template - Is it a globally accepted standard template across all regions?
3. 3. The proposal lacks a guideline on disputed resources - Can the authors clarify how AFRINIC shall handle any resources involved in transfers that are in dispute?

 

1.3 Perceived Implementation challenges

1. "5.7.3.2 Source entities are eligible to receive further IPv4 allocations or assignments from AFRINIC as long as it complies with current policy". is bound to lead to abuse 
2. 5.7.4.2 practically conflicting with 5.7.4.1.
3. ASN transfer is mentioned only in the summary of the problem but all text in the policy clauses refers to IPv4 only, this is confusing and will lead to misinterpretation. It is important to have ASN inclusion clearly stated in the policy text

 

2.0 Staff Comments On Areas of Impact

If the proposal reaches consensus:

2.1 Impact on Systems

1. The Transfer tool on MyAFRINIC will require further adjustments to accommodate inter-RIR transfers
2. Reverse DNS impacts to be considered (for majority /8s)
3. RPKI ROAs
4. Transfer logs
5. RT (AFRINIC Ticketing System)

2.2 Impact on Processes and procedure

1. Processes and procedures will require a review.
2. Coordination with the RIRs who have compatible inter-RIR transfer policies will also be required

2.3 Impact on Operations

1. Resource Transfer evaluation are resource-intensive and MS department would require additional staffing needs to facilitate officiate and timely evaluations
2. Resources will also be required in the software engineering team to implement the transfer on the AFRINIC systems.