IPv4 Inter-RIR Resource Transfers (Comprehensive Scope) Draft 3 | Archived

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.1 Summary of the policy

This policy applies to an organization with justified need for IPv4 resources that cannot be satisfied by AFRINIC.

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 IPv4 Resources transfers

This policy applies to an organization with a justified need for IPv4 resources (recipient) and organizations with IPv4 resources that are no longer needed by that organization (source).

5.7.1 Recognized transfer types

Two types of transfers are recognized:

a)     Intra-RIR. Both parties are within the AFRINIC service region.

b)     Inter-RIR. One of the parties is within the AFRINIC service region, while the other is in the service region of another RIR.

5.7.3. Conditions on the source of the transfer

5.7.3.1 The source must be the current rightful 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.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.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.2 Conditions on the source of the transfer

5.7.2.1 A source must be validated by the applicable source RIR according to their policies and procedures. A source within AFRINIC must be in good standing, be the rightful registrant of the resources to be transferred and there must be no disputes as to the status of said resources.

5.7.2.2 Source entities will not be eligible to receive any further IPv4 address allocations or assignments from AFRINIC. Source entities may, if they can show justified need, receive resources via transfer after a period of not less than 24 months has elapsed from their last outbound transfer.

5.7.2.3 An organization which has received IPv4 resources from AFRINIC within the preceding 12 months will not be approved as a transfer source.

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.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.3 Conditions on the recipient of the transfer

5.7.3.1 Recipient organizations within the AFRINIC service region must be approved with the same policies and procedures as if the request were being satisfied from the AFRINIC pool.

5.7.3.2 Recipients in other RIRs must be approved according to that RIR’s policies and procedures.

5.7.4.3 Transferred IPv4 legacy resources will no longer be regarded as legacy resources. 

5.7.3.3 IPv4 legacy resources will no longer be regarded as legacy resources:

• In the case of intra-RIR transfers.
• In the case of incoming inter-RIR treansfers.

In the case of outgoing inter-RIR transfers, the resulting status will depend on the policies in the receiving RIR.

5.7.4 Transfer of ASN with IPv4 Resources

In the case where the majority of the IPv4 resources are being transferred, any relevant ASN(s) may also be transferred at the same time, if the relevant policies are fulfilled.

5.7.5 Timing for Applicability of Inter-RIR transfers

Inter-RIR transfers will be triggered only once AFRINIC enters Exhaustion Phase 2 (as defined in CPM 5.4.3.2).

5.7.6 Required Disclosure for Transfers

Each time a transfer is completed, AFRINIC will publish all related information permitted by the source or recipient, including at least:

• Date of the transfer.
• Transferred resources.
• Source RIR and organization
• Recipient RIR and organization.

5.7.7 Provisions for Suspensions of Transfers

5.7.7.1 Inter-RIR transfers will be suspended in case the number of outgoing IPv4 addresses exceeds the incoming ones for 6 consecutive months. 

5.7.7.2 Staff may request additional information from parties for any transfer deemed suspicious by staff. Afterwards, all available information shall be escalated to the board for a decision to approve the transfer or not.

Date

Details

14th May 2019

Version 1: AFPUB-2019-IPv4-002-DRAFT01

Initial Draft Posted to rpd

2nd Nov 2019

Version 2: AFPUB-2019-IPv4-002-DRAFT02

• Followed suggestions from impact analysis and discussions in the list.
• Included support for ASN.
• Included existing 5.7.3.3 (renumbered as 5.7.2.3).
• Stating when inter-RIR transfers are enabled.
• Ensuring there is no unbalance or strange operations in transfers once the proposal is implemented.

26th Nov 2019

Version 3: AFPUB-2019-IPv4-002-DRAFT03

• Changes as per RPD list discussion.