Info! Please note that this translation has been provided at best effort, for your convenience. The English page remains the official version.

IPv4 Resources transfer within the AFRINIC Region v3

Details
  • Ref. Name:
    AFPUB-2016-V4-003-DRAFT03
  • Submitted:
    23 December 2016
  • Versions: 3
  • Status:
    Last Call
  • Author:
    - Ali HADJI, Comores Telecoms
    - Komi ELITCHA 
    - Damnam Kanlanfei BAGOLIBE
    - Serge Patrick GHANSAH-GNONKOTO, NIC CIS 
    - Nicholas Mbonimpa, RENU
    - Alain P. AINA, WACREN

1.0 Summary of the Problem Being Addressed by this Policy Proposal

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.

 

2.0 Summary of How this Proposal Addresses the Problem

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.

 

3.0 Proposal

This proposal modifies the CPM by introducing an article 5.7 as follows:

 

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.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.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 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.4.3 Transferred IPv4 legacy resources will no longer be regarded as legacy resources.

  

4.0 Revision History

 

24 May 2016 First Version 1.0 posted to list for discussion.
22 Jul 2016

Version 2.0

  • Addition of Acknowledgement section (5.0)
  • Amendment of the policy's numbering
  • Modification of section 3.2.2 which becomes 3.4.2 
23 Dec 2016

Version 3.0 

  • Rewording of 3.1 [currently 5.7.1]: The policy proposal is no more subject to phase 2 of the current IPv4 Soft Landing policy
  • Rewording of 3.2 [currently 5.7.2]: The policy proposal accommodates IPv4 Legacy resources
  • Removal of old 3.4.2: The statement is already covered by 3.4.1 [currently 5.7.4.1]
  • Rewording of old 3.4.3 that become 3.4.2 [currently 5.7.4.2]: Fix membership condition of recipient following rewording of 3.2 [currently 5.7.2] Addition of new 3.4.3 [currently 5.7.4.3]: About the change of the status of transferred IPv4 legacy space
  • Removal of old 3.4.4; No need for the requirement on recipients of the transfer to demonstrate a need up to 12-month supply of IPv4 address space. Justification based on policies in force.
  • Removal of 6.0 (References)

 

5.0 Acknowledgements

The authors would like to thank Owen Delong and Mark Elkins for their insights. They also thank all those who contributed actively in the discussions around this proposal.

 

 

Print Friendly, PDF & Email
Last Modified on -