Proposal

1. Summary of the problem being addressed by this proposal

The 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 addresses from other members solely within the AFRINIC region, based on justified needs.

Considering the limited IPv4 space initially made available to AFRINIC (AFRINIC manages only 7.23 /8s with a very low ratio of IPv4 addresses per Internet user), there will therefore be a need to allow for unused IPv4 from other regions to move into the 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 the transfer of IPv4 addresses and ASNs within the AFRINIC service region; and between the 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 resources into different categories and defines which transfer rules apply to each category.

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

The policy also makes the following provisions:

• Number resources are non-transferable 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 this policy.
• AFRINIC does not recognize transfers outside of approved transfer policies and requires organizations 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 organizations that need the resources, but cannot obtain them from the AFRINIC free pools.

AFRINIC recognizes the following types of transfers:

• merger, acquisition, takeover or consolidation,
• between AFRINIC members,
• between an AFRINIC member and an organization in another region,
• between a Legacy resource holder and an AFRINIC member,
• between a Legacy resource holder and an organization in another region.

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. Currently, the other regions are APNIC, ARIN, LACNIC, RIPE NCC.

3. Proposal

Insert the following text into the CPM (numbering to be changed by staff as appropriate):

3.1 Definitions

3.1.1 “Resource” refers to "scarce resource"

3.1.2 "Scarce resource" are IPv4 Address space and Autonomous System Numbers. "AFRINIC pool" means the AFRINIC managed pool of IPv4 and ASNs, obtained from IANA (allocated and recovered) or through the ERX (Early registration transfers).

3.1.3 "Special-Purpose pool" means the pool of resources currently reserved for Critical Internet Infrastructures (section 5.6.4 of CPM) and resources distributed during the Exhaustion phases of the soft landing policy (section 5.4 of CPM).

3.1.4 "Legacy resources" refer to resources allocated prior to the RIR system and tagged as Legacy by AFRINIC.

3.1.5 "Others" means resources transferred from other regions through Inter-RIR transfers.

3.1.6 "Inter-RIR transfer" means the transfer of resources from a resource holder in the AFRINIC service region to an organization in another region or vice-versa.

3.2 Marking of the resources

1. AFRINIC pool == Regional
2. Special-Purpose pool == Reserved
3. Legacy == Legacy
4. 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 the source is a Legacy holder and the recipient is AFRINIC member, then allow "Legacy" for transfer and mark transferred resources as "Global".

3.3.3 If the source is a Legacy holder and the recipient is in another region, then allow "Legacy" for transfer.

3.3.4 If the source is AFRINIC member and the recipient is in another region, then allow "Global" for transfer.

3.3.5 If the source is from another region and the 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 the resource to be transferred is "Reserved" then deny the transfer. This restriction excludes mergers, acquisitions and takeover transfers.

3.4 Conditions on resources to be transferred

• The size of the IPv4 address prefix should be a minimum of /24.
• The resource must qualify for the 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 the 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.
• The recipient that does not have prior resources must:
  
  • demonstrate a detailed plan for the use of the transferred resources(in the case of ASN, the recipient must meet the criteria for the assignment of ASN).
• The recipient with prior resources must:
  
  • demonstrate a detailed plan for the use of the transferred resources(in the case of ASN, the recipient must meet the criteria for the 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. References

• https://www.nro.net/about/rirs/statistics/ (section ‘Internet Number Status Reports’)
• https://www.potaroo.net/tools/ipv4/
• https://bgp.potaroo.net/iso3166/v4cc.html
  
• https://resources.potaroo.net/iso3166/ascc.html
• ftp://ftp.afrinic.net/stats/afrinic/transfers/

Revision History

Revision History

AFRINIC Policy Impact Assessment

AFRINIC Staff Assessment

Date of Assessment: 27 October 2021

1.0 Staff Interpretation & Understanding of the proposal

• The proposal will replace the current transfer section 5.7 of the CPM
• It allows the transfer of IPv4 and ASN resources within the region and between AFRINIC and other RIRs that permits the transfer of IPv4 address space and ASNs between its own region and AFRINIC
• It introduces the categorization of resources and a set of transfer rules and specifies the resource categories eligible for transfer. These Categories are for the resource policy administrative purposes and shall not reflect in the WHOIS. The Categorization of resources is as follows:
  
  • AFRINIC pool == Regional
  • Special-Purpose pool == Reserved
  • Legacy == Legacy
  • Others == Global
• Policy rules and procedures are:
  
  • Only Legacy resources and resources transferred in from other regions will be transferable out of the AFRINIC service region
  • Intra region transfers shall permit "Regional", "Global" or "Legacy"
  • Outward Inter region transfers shall permit Legacy and Global(resources that have been transferred into the AFRINIC region)
  • Inward Inter region transfers shall permit "any" as long as they are compliant with the policies of the source RIR
  • The size of the IPv4 address prefix should be a minimum of /24
  • The resource transferred will be covered by AFRINIC policies after transfer into the region
• Resources from the Special-Purpose pool shall not be transferable on basis of this policy
• The source must be the rightful holder of the resources to be transferred with no disputes
• The recipient must meet the conditions of the AFRINIC policies in force
• The recipient must sign RSA and transferred legacy space will no longer be considered legacy (become category Global)
• A new member recipient that does not have prior resources must demonstrate justifiable needs to receive the resource and in the case of ASN, the recipient must meet the criteria for the assignment of ASN according to the policies in force.
• An existing member recipient with prior resources must:
  
  • Demonstrate justifiable needs to receive the resource and in the case of ASN, the recipient must meet the criteria for the assignment of ASN according to the policies in force.
  • Show past usage rate and evidence of compliance with AFRINIC policies with respect to past allocations/ assignments.
• The policy has no resource hold-down time.
• Resources deemed to be transferred without AFRINIC's prior approval will be deemed non-compliant with the policy and shall be reclaimed

2.0 AFRINIC Staff Comments and Recommendations

• Staff notes that the statement in the summary section of the proposal “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.” doesn't align with section 5.2 of the billing policy https://afrinic.net/membership/cost#resource , where it is mentioned that resources delegated for critical infrastructure cannot be transferred .

Suggest a rewording to

• The intra-RIR transfer policy does not explicitly disallow transfers of IPv4 from special-purpose blocks (reserved blocks for IXPs and DNS root ops, Last /8, etc.
• Since "Resource" means IPv4, IPv6, and ASN in general, it is suggested that ;3.1 Definitions to be reworded to 3.1 Definitions applicable to this section of the proposal
• Under the heading “Definitions”, more precisely under sub-paragraph 3.1.5, the term “Others” appears to be vague. The authors may wish to reformulate so that the definition also mentions that incoming legacy resources lose their legacy status after the transfer .
• Under the heading “Rules and procedures for selecting resources eligible for transfers”, more precisely under sub-paragraph 3.3.5, the term “Any” appears to be vague ; to avoid present assumptions and potential future misinterpretation, it would be important to have a specific definition.
• Bullet point 2 of Section 3.4 of the proposal reads "The resource must qualify for the type of transfer requested." This use of "type of transfer" is ambiguous since there are no transfer types defined in the proposal and is open to misinterpretation. Since a definition exists in Section 2 , the authors may consider to include the types of transfers in Section 3 of the proposal.
• Absence of “hold down” time of new allocations/assignments and transferred resources may lead to abuse of the registry before a resource can be put to an effective justified need.
• Under the under heading “Conditions on the source”, more precisely with respect to the first bullet under paragraph 3.5 of the policy proposal, same to be rephrased as follows “The source holder must be the rightful holder of the resources being the subject of the transfer and that the resources must not be the subject of any dispute, known or contemplated.
• The author may wish to update Section 3 of the proposal with “ Resources deemed to be transferred without AFRINIC's prior approval will be deemed non-compliant with the policy and shall be reclaimed” .

3.0 Staff Comments On Areas of Impact

Impact on Registry Functions:

Myafrinicv2 (Member Portal)

• Request dashboard
  1. Changes in preconditions and checks
  2. New workflow for Inter RIR transfer
• Resource Tagging

Resource Tagging currently being implemented will be updated to include the requirements of this policy

• Handling Legacy and resulting statuses
• Transfer Logs updates
• Changes to transfer requests forms to include ASNs

Member Services Operations

• Impact on Processes and procedure
  • Complete process and procedural reviews will be undertaken including the handling of inter-rir transfer and ASNs.

Impact on staffing/human resources

• Resource transfer evaluations are resource-intensive and expanding the scope to include inter-rir will necessity need for additional Hostmasters to effectively process requests as per conditions of section 3.6 of the proposal

Contractual agreements

• Revision of transfer Agreement & Registration Services Agreement may be required.
• Challenges
• Member services note that the policy doesn't enforce any hold-down time period and it may lead to abuse of the registry where a resource may undergo multiple transfers within a short period of time without being put to use in accordance with the needs justification demonstrated during the earlier transfersearlier transfer

Member Services Tool/Systems

• Hostmasters Portal
  • There will be a major code review required to integrate the marking/categorisation proposed
• Automated resource transfer tool
  • The automated transfer tool will require code rewrite to accommodate the ASN resources and integration with external systems for other RIR'

Legal Assessment

1. Coming back to the present proposed policy (i.e. Draft 2), the authors aim at achieving 2 objectives:
   1. intra-RIR transfers of ASNs, presently not covered in clause 5.7 of the CPM; and
   2. inter-RIR transfers of IPv4 resources from and to the AFRINIC region.
2. The second objective will be addressed first before dealing with the objective regarding the intra-RIR transfers of ASNs.
3. The decision of allowing, or not, an inter-RIR transfers of IPv4 resources from and to the AFRINIC region is not strictly a legal one. In fact, it is purely and simply a business decision to be taken judiciously and prudently both by the PDWG and the Board of Directors having regard to the directors’ duties provided in the Companies Act, i.e. to act in the best interests of the company. Acting in the best interests of the company in this context means considering the real financial impact of such policy for AFRINIC so that the sustainability and business continuity of AFRINIC, both as a company and RIR, is not compromised.
4. The first objective regarding intra-RIR transfers of ASNs shall now be addressed. It is observed that the scope of the proposed policy is not limited to non-legacy IPv4 resources, but also extends to legacy resources.
5. It is important to highlight that, as a matter of law, legacy resource holders existing within the AFRINIC’s service region are not contractually bound by AFRINIC’s adopted policies such that these policies have no direct effect on legacy resource holders, and it is up to those legacy-holders to adhere to AFRINIC’s policies. Thus, the authors should bear in mind that obligations impacting on legacy resource holders may not necessarily achieve the intended results if the legacy resource holders refuse to opt for voluntary registration of the transfer with AFRINIC.
6. The other question arising relates to outbound transfers of resources. It is understood that the intended transfers will be channelled through AFRINIC. Therefore, other than simply setting out the conditions for transfers, AFRINIC’s role in the whole process must also be adequately defined. In particular, it is unclear as to whether AFRINIC’s role in the whole process would be limited to facilitating the administrative aspect of the intended transfers only with or without such legal responsibilities attached thereto, more so that AFRINIC will be relying on representation made to it when attending to similar requests. Accordingly, it is proposed that the burden of conducting such adequate due diligence with respect to the source holder or the concerned IPv4 number resources be borne by the intended recipient, and that AFRINIC’s role should be limited to act as facilitator only without bearing any legal responsibility whatsoever in that process.
7. In regard to inbound transfer of legacy resources into the AFRINIC’s region and whilst clause 3.6 of the proposed policy will require the recipient to sign an RSA, it is not clear in the proposed policy whether the concerned IPv4 legacy resource will lose its legacy status upon transfer into the AFRINIC’s service region in as much as the current RSA is not presently tailored for that purpose.
8. Further, it is also important to clarify whether, in case of inbound transfers of legacy resources, AFRINIC will be able to execute its RSA with the obvious risk of the concerned IP number resources being reclaimed by AFRINIC in case of subsequent breach of the RSA, despite that the recipient organisation would have most probably paid good consideration (financial value) for such transfers.

Financial Assessment

Since IPv4 & ASN resources from the AFRINIC Pool can only be transferred in-region(Intra), AFRINIC will not lose its current resource members to other RIRs in outgoing transfers. This proposal will therefore have a minimal financial impact on AFRINIC’s revenue.

4.0 Implementation

Timeline - Earliest we can implement same will be in Q4 2022 on MyAFRINIC V2 based on the updated plan

5.0 Reciprocity with the other RIRs

• APNIC - This version of the proposal is Fully reciprocal and bi-directional
• ARIN - This proposal continues to allow general inward transfer of number resources from ARIN-region entities but prohibits the transfer out of some categories. Thus, this proposal is not reciprocal with ARIN, as ARIN does not have a restriction on outgoing Inter-RIR transfers (apart from those resources in our reserved pools.)
• LACNIC - The compatibility for version 2 is yet to be confirmed. (In the case of a previous version of the proposal AFPUB-2019-GEN-002-DRAFT02 , LACNIC indicated that its inter-RIR policy does not demand reciprocity.
• RIPE NCC - compatible with the RIPE NCC’s inter-RIR transfer policy - reciprocity with other RIRs policies is not a requirement in our inter-RIR Policy