Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] Resources transfer policy Proposal

ALAIN AINA aalain at
Thu Aug 29 11:36:28 UTC 2019

Dear community

A new policy proposal named "AFRINIC resources transfer policy" is submitted for discussions. This proposal obsoletes the current IPv4 transfer within AFRINIC service region policy, defines rules for transfers of IPv4 and ASNs within the region and between AFRINIC service region and other regions.

The policy allows a category of resources to be transferred out of the region, another category of resources to be transferred inside and denies the transfer of certain resources.

We expect this to be a response to a harmonised policy which addresses some of the limitations of the intra-rir policy and proposes a solution for an inter-rir transfer which minimizes the foreseen risks of uncontrolled outflow of resources.

The co-authors

Draft Policy Name: AFRINIC Number resources transfer policy
ID: (Assigned by AFRINIC)
Submission Date: 29 August 2019
Version: 1.0
Author(s): (a) Name, (b) Email address, (c) Affiliation, if applicable
Gregoire Olaotan Ehoumi, gregoire at, independent
Mukhangou Noah Maina, noah.maina at, SEACOM
Komi Elitcha, kelitcha at, Independent
Adeola A. P. Aina, alain.aina at, WACREN

Sections of Policy Manual affected

Obsoletes: IPv4 Resources transfer within the AFRINIC Region (Section 5.7 of the CPM)

1. Summary of the problem being addressed by this proposal

AFRINIC IPv4 pool is expected to run out soon. Some entities may need IPv4 space to support their IPv6 deployments, especially to support transition mechanisms, which AFRINIC may not meet. The current Intra-RIR policy in force at AFRINIC allows entities to receive unused IPv4 address from other members solely within the AFRINIC region, based on justified needs. Considering the limited IPv4 space initially made available to AFRINIC (AFRINIC managing only 7.23 /8 with a very low ratio of IPv4 addresses per Internet users), there will therefore be a need to allow for unused IPv4 from other regions to move into AFRINIC service region – this without necessarily depleting AFRINIC's slim amount of IPv4 addresses by transferring space out of the region.

The current Intra-RIR transfer policy allows all types of IPv4 allocations/assignments to be transferred, including IPv4 from special purpose blocks (reserved blocks for IXPs and DNS root ops, Last /8, etc.)

The current intra-RIR transfer policy does not cover ASNs while there are cases where transfers of ASNs among AFRINIC members is desirable.

2. Summary of how this proposal addresses the problem

This new policy defines a set of rules to allow transfer of IPv4 addresses and ASNs within AFRINIC service region and between AFRINIC service region and other regions by specifying what categories of resources are eligible for transfer, the location of parties (sources and recipients) and the conditions to be met.
The policy segregates the resources in different categories and defines which transfer rules applied to each category.

Only Legacy resources and resources previously transferred from other regions will be transferable out of the AFRINIC service region.

It also states the following:

Number resources are non-transferable and are not assignable to any other organisation unless AFRINIC has expressly and in writing approved a request for transfer. AFRINIC is tasked with making prudent decisions on whether to approve the transfer of number resources.

IPv4 addresses and ASNs can be transferred only in accordance with the following policy. AFRINIC does not recognise transfers outside of this policy and its predecessor and requires organisations holding such resources to return them to the appropriate registries.

The goal of this transfer policy is to help distribute resources from those who no longer need them to organisations that need the resources, but cannot obtain them from the AFRINIC free pools.

AFRINIC recognizes the following types of transfers:
- merger, acquisition or takeover,
- between AFRINIC members,
- between an AFRINIC member and a member of another RIR,
- between a Legacy holder and an AFRINIC member,
- between a Legacy holder and a member of another RIR.

AFRINIC will process and record Inter-RIR resource transfers only when the counterpart RIR has an Inter-RIR transfer policy that permits the transfer of IPv4 address space and ASNs between its own region and AFRINIC.

3. Proposal

3.1 Definitions

3.1.1 “Resource” refers to IPv4 Address space or Autonomous System Numbers.
“AFRINIC pool” means AFRINIC managed pool of IPv4 and ASNs, obtained from IANA (allocated and recovered) or through the ERX (Early registration transfers).

3.1.2 “Special-Purpose pool” means the pool of resources currently reserved for Critical Internet Infrastructures (section 5.6.4 of CPM) and last /8 (section 5.4.1 of CPM).

3.1.3 “Legacy resources” refer to resources allocated prior to the RIR system and tagged as Legacy by AFRINIC.

3.1.4 “Others” means resources transferred from other regions through Inter-RIR transfer.

3.1.5 “Inter-RIR transfer” means the transfer of resources from an AFRINIC member to a member of another RIR or vice-versa.

3.2 Marking of the resources

AFRINIC pool == Regional
Special-Purpose pool == Reserved
Legacy == Legacy
Others == Global

3.3 Rules and procedures for selecting resources eligible for transfers

3.3.1 If source and recipient are AFRINIC members, then allow “Regional”, “Global” or “Legacy” for transfer and mark transferred “Legacy” as “Global”

3.3.2 If source is Legacy holder and recipient is AFRINIC member, then allow “Legacy” for transfer and mark transferred resources as ”Global”

3.3.3 If source is Legacy holder and recipient is in another region, then allow “Legacy” for transfer

3.3.4 If source is AFRINIC member and recipient is in another region, then allow “Global” for transfer

3.3.5 If source is from another region and recipient is AFRINIC member, then allow “Any”, and then mark the transferred resources as “Global”

3.3.6 Irrespective of the source and recipient, if resource to be transferred is “Reserved” then deny transfer.

3.4 Conditions on resources to be transferred

- The size of the IPv4 address should be a minimum of /24.
- The resource must qualify for type of transfer requested.
- The resource will be covered by AFRINIC policies after transfer into the region.

3.5 Conditions on the source

- Must be right holder of the resources to be transferred with no disputes.
- If the source is from other regions, conditions on the source are defined in the counterpart RIRs transfer policy.

3.6 Conditions on the recipient

- Will be subject to current AFRINIC policies.
- Must sign RSA.
- Recipient that does not have prior resources must:
++ demonstrate a detailed plan for the use of the transferred resources
(in the case of ASN, recipient must meet the criteria for assignment of ASN).
- Recipient with prior resources must:
++ demonstrate a detailed plan for the use of the transferred resources
(in the case of ASN, recipient must meet the criteria for assignment of ASN).
++ Show past usage rate.
++ Provide evidence of compliance with AFRINIC policies with respect to past allocations/assignments.
- If the recipient is in another region, the conditions on the recipient are defined in the counterpart’s RIR transfer policy.

4. Revision History

v1 submitted on 29/08/2019 for discussions

5. References


More information about the RPD mailing list