IPv4 Inter-RIR Legacy Resource Transfers

Proposal

1. Summary of the problem being addressed by this proposal

This proposal allows establishing the mechanism to allow transfers of legacy 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.

                                

2. Summary of how this proposal addresses the problem

In recent years, and with the exhaustion of IPv4, several regions have solved this problem, not only through transfers within the region itself, but between different regions. This allows to facilitate a dynamic in the market and by increasing the offer, reducing prices.

However, an inter-RIR mechanism has not been established in AFRINIC, 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, which avoids even that new businesses can be established in the region, due to the lack of addresses. 

On the other hand, the fact that there is no inter-RIR policy does not prevent transfers "under the table" and, therefore, assumes that there are resources from which the history of their registration is lost, which is one of the main functions of AFRINIC.

As a protection measure, it is considered that these transfers should only be allowed from AFRINIC to other regions if they are legacy resources, regardless of the origin of the resources that come from other regions. This also has the advantage of allowing these resources to emerge and incorporate them into the RIRs system.

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 in serious disadvantage if they do not have access to a global market, as it is currently the case.

There is no doubt that accepting this type of transfer also has its risks, and it is possible that an initial price increase will be generated, which would quickly be aligned with the rest of the global market, as is usually the case with equivalent markets.

This proposal would allow bidirectional transfers with LACNIC and RIPE. However, because the legacy-only, it will limit the transfers with APNIC to also legacy-only, and will not allow transfers with ARIN, as their policy wording limits the transfers to other regions with “reciprocal” policies.

 

3. Proposal

Amend 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 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 justified need, for IPv4 resources that cannot be satisfied by AFRINIC. 5.7.1 Recognized transfer types Two types of transfers are recognized: Intra-RIR. Both parties are within the AFRINIC service region. Inter-RIR. One of the parties is within the AFRINIC service region, while the other is in another RIR service region. In the Inter-RIR case, if the source of the resources is located in AFRINIC and the destination is another RIR, only legacy resources can be transferred.
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 The source must be the current rightful holder of the IPv4 address resources in the relevant RIR, and not be involved in any dispute as to the status of those resources. 5.7.2.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.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 For an organization within the AFRINIC service region, AFRINIC must approve the recipient's need for the IPv4 number resources, following existing relevant policies. 5.7.3.2 For an organization in another RIR service region the relevant criterion will depend on the relevant policies in the destination RIR. 5.7.3.3 The recipient must be a member of the relevant RIR, subjected to its policies and legal documents/service agreements.
5.7.4.3 Transferred IPv4 legacy resources will no longer be regarded as legacy resources.	5.7.3.4 IPv4 legacy resources will no longer be regarded as legacy resources: In the case of intra-RIR transfers. In the case of inter-RIR, when incoming to AFRINIC service region.

 

4. References

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

LACNIC reached consensus on an equivalent proposal in their last meeting:

• LAC-2018-14: https://politicas.lacnic.net/politicas/detail/id/LAC-2018-14?language=en

 

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

 

Staff Assessment

 

Proposal	AFPUB-2019-v4-001-DRAFT01
Title	IPv4 Inter-RIR Legacy Resource Transfers
Proposal URL	https://afrinic.net/policy/proposals/2019-v4-001-d1#proposal
Assessed	20 July

 

1.0 Staff Understanding of the Proposal 

a) Amends CPM 5.7 that currently provides for Intra-RIR transfers to allow for both Intra and Inter-RIR transfers.

b) Intra-RIR transfers will happen under the following conditions :-

1. Both parties (source and recipient) are within the AFRINIC service region. 
2. The source shall be the current rightful holder of the resources (Legacy Resource Holder or Resource Member) and not subject to any disputes at the time of the transfer request being submitted/executed.
3. The source entity (Legacy Resource Holder or Resource Member) shall not be eligible to receive IPv4 addresses (allocations or assignments) from AFRINIC for a period of 12 months after a transfer approval.
4. The recipient organisation will be a Resource Member or apply to be a resource member to receive the resources being transferred. They shall be subject to AFRINIC policies , legal documents and service agreements and will undergo a needs evaluation so that AFRINIC could determine their needs for the resources to be received as part of the transfer, in compliance with existing policies.
5. If legacy space is transferred, it will lose legacy status after the transfer.
6. Section 5.7.3.3 present in current policy  is now removed from the new policy proposal ("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.  This means that a Resource member who just received delegated resources from AFRINIC can transfer the resources right after. 

c) Inter-RIR transfers will happen under the following conditions :-

1. If source  is in  the AFRINIC service region , the recipient shall be in another RIR, and likewise.
2. The source RIR shall have an inter-RIR transfer policy compatible with AFRINIC’s.
3. Only legacy IPv4 resources  are allowed to be transferred from AFRINIC to receiving RIRs.
4. The source shall be the current rightful holder of the resources (Legacy Resource Holder or Resource Member holding some legacy resources)  and not subject to any disputes at the time of the transfer request being submitted/executed.
5. The recipient criteria will depend on the relevant policies in the RIR where it is registered as a member.
6. The recipient shall be subject to its RIR’s legal documents/ service agreements
7. 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
8. AFRINIC can receive both legacy and non-legacy IPv4 space from other RIRs.
9. Legacy space once transferred falls under RSA and loses legacy status.
10. The recipient organisation will be a Resource Member or apply to be a resource member to receive the resources being transferred. They shall undergo a needs evaluation so that AFRINIC could determine their needs for the resources to be received as part of the transfer, in compliance with existing policies.

 

2.0  Staff Comments

2.1 Intra-RIR transfers

1. The proposal only caters for transfers of  IPv4 space. Some organisations may want to transfer ASNs that hold legacy status at source. Is the author’s intent to restrict transfers to IPv4 only & exclude ASNs from this policy proposal?
2. Section 5.7.3.3 is now removed from the new policy proposal ("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. Removal of this clause will open the way for companies to set up in the AFRINIC service region, get resources and transfer them out of the region - that is, new members will be able to immediately sell/transfer their resources as soon as received - paving way for serious abuse and at the same time conflicts with the soft-landing policy clause that requires a demonstration of need for next 8 months (CPM 5.4.5).

1. Is it the author's intent to amend the intra-RIR policy by removing this clause?
2.  How will the conflict with CPM 5.4.5 be dealt with?

2.2   Inter-RIR transfers

1. It is not clear when inter-RIR transfers become effective  (Phase 1 or Phase 2 of soft-landing).
2. Proposed 5.7.2.2 reads "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".  This could imply that Legacy Resource Holders that transferred resources out may not be able to become AFRINIC members and request for resources within the 12 months.

 

3.0 Comments from Legal Adviser 

None

 

4.0  Implementation 

4.1   Timeline & Impact

- Minimum impact to AFRINIC operations are foreseen should the conflicting policy clauses be addressed.

- The policy can be implemented within 6 months from last call .

 

4.2 Implementation Requirements

-  Amendment of intra-RIR rules will require AFRINIC to rework the automated  transfer tool

-  Collaboration with the other RIRs to implement inter-RIR transfers and automate related services (such as rDNS).

 

Revision History

 Revision History

Date	Details
13th May 2019	Version 1: AFPUB-2019-IPv4-001-DRAFT01 Initial Draft Posted to rpd