IPv4 Inter-RIR Resource Transfers (Comprehensive Scope) Draft-4 | Archived
- Last Modified on -
Details
|
IPv4 Inter-RIR Resource Transfers (Comprehensive Scope) |
|||
|
ID: |
AFPUB-2019-IPv4-002-DRAFT04 |
Date Submitted: |
12 August 2020 |
|
Author: |
Jordi Palet Martinez jordi.palet at theipv6company.com The IPv6 Company |
Version: |
4.0 |
|
Obsoletes: |
Amends: |
CPM, amend art. 5.7 |
|
Proposal
1. Summary of the problem being addressed by this proposal
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.
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 facilitating 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.
This proposal considers that such transfers should be allowed for both legacy and non-legacy IPv4 addresses. In the case of legacy resources, this 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 all the other RIRs.
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 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).
5.7.1 Recognized transfer types Two types of transfers are recognized:
|
|
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 which has received IPv4 resources from AFRINIC within 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 outgoing inter-RIR, the resulting status will depend on the policies in the receiving RIR. |
|
5.7.4 Transfer of ASN with IPv4 Resources At the AFRINIC discretion, in the case where over 50% of the IPv4 resources associated with an ASN are being transferred, that ASN may also be transferred at the same time. |
|
|
5.7.5 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:
This doesn’t exclude the publication of the same or other information as a result of the operating agreement among the RIRs. |
|
|
5.7.6 Provisions for Suspensions of Transfers 5.7.6.1 The inter-RIR transfers will be suspended in case the number of outgoing IPv4 addresses exceeds the incoming ones for 6 consecutive months. 5.7.6.2 Staff may request additional information from parties for any transfer deemed suspicious by staff. Afterwards, all available information shall be escalated to the board for a decision to approve the transfer or not.
|
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 |
| 12th Aug 2020 | Version 4: AFPUB-2019-IPv4-002-DRAFT04 - Changes to accommodate IPv4 exhaustion phase 2 - Corrected typo in 'Details' (2020/09/16) |
| 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 unbalance 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 | Relevant to Proposal |
|---|---|
| Aug 2020 | AFPUB-2019-IPv4-002-DRAFT04 |
1.0 Staff Understanding of the policy 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:
- 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.
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) which has received IPv4 resources from AFRINIC within 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.
Section 5.7.4 mentions that ASNs can be transferred but subject to some conditions, i.e more than 50% of resources are being transferred. Staff understand that if they receive one request for transfer of resources exceeding 50% of resources held from a source to one recipient, the recipient is allowed to also request for the transfer of its ASN to that recipient.
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 which has received IPv4 resources from AFRINIC within 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.
In case staff deem that some transfers are suspicious, they may request for additional parties concerned, before escalating to the AFRINIC Board for a decision to approve the transfer or not
AFRINIC will publish all related information permitted by the source or recipient primary indicating the following: Date of the transfer, transferred resources, Source RIR and organization and Recipient RIR and organization. This will be done as follows:- the AFRINIC transfer log will be updated after each transfer executed and the transfer log syntax is the one adopted by all the RIRs and includes the specifications in this policy proposal.
The policy proposal accepts that transfers also have some risks and proposes that The inter-RIR transfers will be suspended in case the number of outgoing IPv4 addresses exceeds the incoming ones for 6 consecutive months. This means that AFRINIC shall monitor the amount of incoming and outgoing IPv4 addresses transfers and the AFRINIC Board shall take the decision to suspend the inter-RIR transfers based on the input of AFRINIC staff and in alignment with this policy
1.1. Staff Need more clarification from Authors
- Since the policy text does not explicitly mention that resources can be transferred as a result of mergers and acquisitions, staff assume that this policy proposal excludes transfers of IPv4 addresses due to mergers and acquisitions. Author's input is required in this case.
- Once the decision to suspend the inter-RIR policy is taken by the AFRINIC Board, in accordance with the bylaws, how shall AFRINIC implement the Board's decision in the CPM? To be noted that the policy proposal covers both intra and inter RIR transfers. Author's input is required in this case.
- Recommend that Section 5.7.4 is updated to remove " "At the AFRINIC discretion" and a section depicting in detail the conditions of an ASN transfer included. In addition, the scope of the proposal to allow both IPv4 and ASN transfers to be amended.
2.0 Staff Comments On Areas of Impact
If the proposal reaches consensus:
2.1 Impact on Systems
- The transfer tool on MyAFRINIC and NMRP will require further adjustments to accommodate inter-RIR transfers
- Introduce an automated tool to monitor the direction of the resources in order to easily manage 5.7.6
- RPKI ROAs
- Reverse DNS (majority /8s)
- Internal Ticketing system
2.2 Impact on Processes and procedure
Processes and procedures will require a review.
2.3 Impact on MS Operations
Resource Transfer evaluation are resource-intensive and MS department would require additional staffing needs to facilitate officiate and timely evaluations