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

Proposal

 

1. Summary of the problem being addressed by this proposal

1. AFRINIC is lagging behind in the IPv4 market and this is negative to the region which is leading the region to a situation of discrimination and scarcity of addresses, not only in the RIR itself but in the region's market.
2. New businesses can’t be established in the region, due to the lack of addresses.
3. Additionally, it is important to highlight that the deployment of IPv6, in some cases, may require
   small blocks of IPv4 addresses for transition mechanisms, or significantly increase the costs thereof, and many AFRINIC entities could, therefore, be at a serious disadvantage if they do not have access to a global market, as it is currently the case.
4. Legacy holders in AFRINIC region can’t transfer their resources out of the region and remain dormant.
5. Under the table agreements for transfers lead to the loss of the history of the registration.
6. Even if a member qualifies for the transfer of its resources, if the transfer fails due to the recipient not meeting stipulated policy conditions, the member can be penalized for stockpiling and the unused
   resources will be subjected to return to or recovery by AFRINIC.

 

This proposal allows establishing the mechanism to allow transfers of IPv4 resources to/from other regions and to align AFRINIC with a market that already exists and in which we are lagging behind, which is negative for the region.

At the same time, the proposal ensures that resources being transferred from an AFRINIC resource member have been used according to the documented justified needs as per the RSA/CPM conditions, and not stock-piled. There is also a grace period for justification of the usage of the resources, in case of a failed transfer due to the recipient's failure. Not including that, will actually disallow transfers, as it is obvious that a member willing to transfer is no longer justifying the resources and will be subjected to returning them or a recovery.

 

2. Summary of how this proposal addresses the problem

1. The proposal aims at maintaining the current intra-RIR transfers.
2. Enables bidirectional, compatible, and reciprocal transfers with all the other RIRs.
3. Facilitate a dynamic in the market and by increasing the offer and making it transparent, reduces
   prices.
4. Enables both legacy holders and resource members in the AFRINIC region to transfer resources.
5. At the same time, ensures that resources being transferred from an AFRINIC resource member
   have been used according to the documented justified needs as per the RSA/CPM conditions, and not stock-piled. There is also a grace period for justification of the usage of the resources, in case of a failed transfer due to the recipient's failure. Not including that will actually disallow transfers, as it is obvious that a member willing to transfer is no longer justifying the resources and will be subjected to returning them or a recovery

 

Exclusion/Out of scope:

• The proposal does not cover Mergers and Acquisitions in the AFRINIC service region as it is at this time covered by internal operational procedures.
• The proposal does not cover Merger and Acquisition between entities domiciled in different RIR service regions.

 

Notes:

It is suggested that, as an editorial CPM update, if this policy is adopted, section 5.7 is moved to a new section (possibly 13), which accommodates in the future, all the transfers-related policies in a single place. This editorial modification can be done by the staff, renumbering/reordering any relevant sections, even adjusting titles/subtitles for the new section to better match the adopted text.

 

3. Proposal

3.1 Amending article 5.7 of the CPM, 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.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.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 (recipients) and organizations with IPv4 resources which no longer need (sources). The resources to be transferred must be from an existing RIR member’s account or from a Legacy Resource Holder in the AFRINIC service region/other RIRs. 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 another RIR service region. Mergers and acquisitions (inter or intra) are not covered by this policy.
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.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 16 months (twice the window defined by 5.4.5) has elapsed from their last outbound transfer. 5.7.2.3 An organization that has received IPv4 resources from AFRINIC within the preceding 16 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. In the case of outgoing inter-RIR, the resulting status will depend on the policies in the receiving RIR.
	5.7.4 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. This doesn’t exclude the publication of the same or other information as a result of the operating agreement among the RIRs.
	5.7.5 Transfers pre-check Where the source of the transfer is a resource member, AFRINIC will run a pre-check to verify if the resources being transferred were allocated/assigned and used according to the RSA/CPM. The member has to pass the pre-check. It can happen that a transfer fails due to the recipient failing to be compliant because of the lack of proper documentation or non-compliance of the relevant rules, while the source passed the transfer pre-check. This proposal allows the successful transfer pre-check to be valid for up to 12 months after the failed transfer; i.e AFRINIC will not initiate a recovery/reclamation process in this period.

    

 4. References            

There are Inter-RIR policies in APNIC, ARIN, LACNIC, and RIPE, which have widely demonstrated their effectiveness and have not presented problems to the respective communities, quite the contrary.

According to the existing evidence, the ARIN region appears as the origin of the transfer of the largest number of addresses to the other regions that have resource transfer policies.

• https://www.nro.net/wp-content/uploads/NRO-Statistics-2018-Q4.pdf
• http://www.lacnic.net/innovaportal/file/3277/1/2-john-sweeting-arin.pdf

 

Revision History

Revision History

Date	Details
28th Sep 2021	Version 6: AFPUB-2019-IPv4-002-DRAFT06 Editorial modifications. Added pre-check of AFRINIC resource members. Added no-justification of need during a period of 12 months after a failed transfer.
27th Oct 2020	Version 5: AFPUB-2019-IPv4-002-DRAFT05 Clarified that it is not for M&A Removed text on ASN transfers, which will be a different proposal, so to concentrate on the most urgent problem by now Removed suspensions, as the board is already able to make that without the need of this text, and community discussion proved that they are no longer worried about this.
12th Aug 2020	Version 4: AFPUB-2019-IPv4-002-DRAFT04 Changes to accommodate IPv4 exhaustion phase 2
26th Nov 2019	Version 3: AFPUB-2019-IPv4-002-DRAFT03 Changes as per RPD list discussion.
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 unbalanced or strange operations in transfers once the proposal is implemented.
14th May 2019	Version 1: AFPUB-2019-IPv4-002-DRAFT01 Initial Draft Posted to rpd

 

AFRINIC Policy Impact Assessment

 

AFRINIC Staff Assessment

 

Date of Assessment: 27 October 2021

 

1.0) Staff Interpretation & Understanding of the proposal

This policy proposal, if adopted, allows staff to bring editorial modifications to the CPM and create a new section that shall contain all transfer related policies. Such editorial rights for staff shall be limited to only this policy. The contents of this policy proposal (which amends Section 5.7 of the CPM) shall then be updated in the new section of the CPM.

Currently, Section 5.7 of the CPM allows for Intra-RIR transfers of IPv4 resources only. Transfers due to Mergers and acquisitions are guided by the mergers and acquisitions guideline document, outside the Consolidated Policy Manual. In addition to intra-RIR transfers, This proposal would allow bidirectional transfers of IPv4 of both legacy and non-legacy status with all the other RIRs and amends Section 5.7 of the Consolidated Policy Manual.

For the purpose of clarity, two types of transfers are recognised:

1. Intra-RIR. Both parties are within the AFRINIC service region.
2. Inter-RIR. One of the parties is within the AFRINIC service region, while the other is in another RIR service region.

The recipient of the transfer, if in the AFRINIC service region, must justify its needs for the resources being transferred to it.

An organisation(recipient) that has received IPv4 resources from AFRINIC within the preceding 16 months will not be approved as a transfer source
Section 5.4.6.1 of the CPM ("In order to receive IPv4 allocations or assignments during the Exhaustion Phase, the LIR or End User must have used at least 90% of all previous allocations or assignments") shall remain effective on recipients based on Section 5.7.3.1 of the proposal that states "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.".

IPv4 legacy resources transferred in the case of Intra-RIR transfers or incoming inter-RIR will lose their legacy status.

The following conditions apply for the source organisation in the transfer:-

• 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.
• There is no limitation on the size and frequency a source can transfer out its resources.
• 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 16 months (twice the window defined by 5.4.5) has elapsed from their last outbound transfer.
• An organization that has received IPv4 resources from AFRINIC within the preceding 16 months will not be approved as a transfer source.
• Both legacy and non-legacy resources can be transferred. The status of legacy resources in the recipient RIR registry shall be determined by the policies prevalent in the recipient RIR.

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 and Recipient RIR and organization. This doesn’t exclude the publication of the same or other information as a result of the operating agreement among the RIRs.

AFRINIC will run a pre-check to verify if the resources being transferred were allocated/assigned and used according to the RSA/CPM. It can happen that a transfer fails due to the recipient failing to be compliant; This proposal allows the successful transfer pre-check to be valid for up to 12 months after the failed transfer; i.e AFRINIC will not initiate a recovery/reclamation process in this period.

 

2.0) AFRINIC Staff Comments on clarity of policy

1. This policy states that after a successful transfer pre-check AFRINIC can’t perform any reviews and audits on this member for a period of 12 months; this can be dangerous as members can decide to violate RSA/CPM within this time without consequences.
2. In case of pre-check failure, can the author clarify if AFRINIC can take the resources back as the member is not compliant

 

3.0) Staff Comments On Areas of Impact

3.1) Impact on Systems

1. The transfer tool on MyAFRINIC and NMRP will require further adjustments to accommodate inter-RIR transfers
2. Introduce an automated tool to monitor the direction of the resources in order to easily manage 5.7.6
3. RPKI ROAs
4. Reverse DNS (majority /8s)
5. Internal Ticketing system
6. Change transfer business rules to add the possibility of inter-RIR transfers.
7. Add cross-RIR verifications.
8. Update the status of Legacy Resources after a transfer in WHOIS and MyAFRINIC.
9. Keep an audit trail including pre-check results.

 

3.2) Impact on Processes and procedure

Complete process and procedural reviews will be undertaken including the handling of the inter-rir transfer of IPv4 resources

 

3.3) Impact on MS Operations

Resource Transfer evaluations are resource-intensive and MS department would require additional staffing needs to facilitate officiate and timely evaluations.

Member services note that the policy doesn't enforce any hold-down time period for the transferred resources 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 the needs justification demonstrated at earlier transfer

 

3.4) Contractual agreements

Revision of transfer Agreement & Registration Services Agreement may be required

 

3.5) Impact on Registry Functions

1. Implementation on the requested dashboard
   1. Changes in preconditions and checks
   2. New workflow for Inter RIR transfer
2. Coordination with other RIRs to enable incoming and outgoing transfers
   1. How the request shall be received and treated.
   2. How AFRINIC shall send the request to other RIRs for proper processing
3. Handling Legacy and resulting statuses

 

3.6) Legal Assessment

1. It is noted that the ToR of the Appeal Committee has been revoked and substituted by a new version such that henceforth, the mandate of the Appeal Committee is now limited to a review of the acts and doings of the PDWG only; and has no authority to reverse a declaration for consensus/lack of consensus made by the PDP Co-Chairs based on discussions held in connection thereof on the mailing list. This major change has an impact on the assessment made herein.
2. Coming back to the present proposed policy, the author aims at establishing the mechanism to allow transfers of IPv4 resources to/from other regions and to align AFRINIC with a market that purportedly already exists and in which, according to the author, AFRINIC is lagging.
3. The decision of allowing, or not, 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. Further, it is observed that the scope of the proposed policy is not limited to non-legacy IPv4 resources, but also extends to legacy resources. Therefore, 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 author must bear in mind that obligations impacting legacy resource holders may not necessarily achieve the intended results if the legacy resource holders refuse to opt for voluntary registration with AFRINIC.
5. 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 this respect, it is unclear as to whether AFRINIC’s role in the 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. To address this issue, it is proposed that the burden of conducting such adequate due diligence be placed on both the source holder and the intended recipient, and that AFRINIC’s role should be limited to acting as a facilitator only without bearing any legal responsibility whatsoever in that process.
6. Moreover, while it is observed that legacy resources will lose their status upon being registered with AFRINIC (viz inbound transfers), it is not clear as to whether the receiving party will be required to sign an RSA with AFRINIC. Although one may presume that this is the intent of the author, yet it is imperative that same be clarified as well as whether AFRINIC will still be able to execute its RSA with the obvious risk of the concerned IP number resources being reclaimed by AFRINIC in case of a subsequent breach of the RSA, despite that the recipient organisation would have most probably paid good consideration (financial value) for such transfers.

 

3.7) Financial Assessment

The financial impact is forecasted to be high and negative as:-

1. Resources from the AFRINIC Pool can be transferred in outgoing transfers to other RIRs. AFRINIC will lose members to other RIRs in outgoing transfers.
2. AFRINIC will gain revenue in incoming transfers from the other RIRs(including those with legacy status as the latter lose legacy status after being transferred)

 

4.0) Implementation

The earliest we can implement the same will be in Q4 2022 based on the updated plan.

 

5.0) Reciprocity with the other RIRs

To be confirmed