Inter-RIR Transfer Policy

Original Language Español Date Published 31/10/2018 Last Modified 27/02/2019
Last Call for Comments Period Does not apply Date Ratified Does not apply Implementation Date Does not apply
Status Under discussion Download TXT PDF XML DOCX
See other versions 1.0 2.0 (compare)

Authors

Name: Jordi Palet Martinez
Email: jordi.palet@theipv6company.com
Organization: The IPv6 Company

Name: Edwin Salazar
Email: edwin.salazar@wifitelecom.ec
Organization: Wifitelecom

Name: Edmundo Cázarez
Email: edmundo.cazarez@nic.mx
Organization: NIC.MX

Proposal Data

Policy Type: LACNIC
Id: LAC-2018-14
Last version: 2

Summary

This proposal allows extending the current mechanism for intra-RIR IPv4 address transfers to allow transferring resources between different regions and to align LACNIC with an existing market in which the region is lagging behind, something we consider to be negative for the region.

Rationale

In recent years and with the exhaustion of IPv4, several regions have solved this problem by allowing not only intra-regional transfers but also transfers between different regions. This allows for market dynamics, as an increased offer reduces prices.

However, an inter-RIR mechanism has not been established for LACNIC, and this is leading the region to a situation of discrimination and address scarcity, not only within the RIR itself, but also in the regional market. This the lack of addresses can even make it difficult to establish new businesses in the region.

Likewise, the lack of an inter-RIR transfer policy does not prevent “under-the-table” transfers and, therefore, involves the loss of certain resources’ registration history, the main function of an RIR.

This proposal considers that these transfers should only be allowed in the case of legacy resources. This has the additional advantage of allowing these resources to surface and incorporating them into the RIR system.

In addition, it is important to highlight that, in certain cases, IPv6 deployment may require small blocks of IPv4 addresses for their use by transition mechanisms or significantly increase their cost if such blocks are not available, so many organizations in the LACNIC region might be at a serious disadvantage if they do not have access to the global market, as is currently the case.
Accepting this type of transfers is certainly not without risks. It is possible that an initial price increase might occur, but this would quickly align with the global market, as is usually the case with equivalent markets.

Text

Current text

2.3.2.18.- Transfer of IPv4 Blocks within the LACNIC Region
IPv4 block transfers shall be allowed between LIRs and/or End Users within the LACNIC region (hereinafter organizations) in accordance with the conditions set forth in this section.

2.3.2.18.1.- The minimum block size that may be transferred is a /24.

2.3.2.18.2.- 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 LACNIC. That is to say, the organization must justify before LACNIC the initial/additional allocation/assignment, as applicable, according to
the policies in force.

2.3.2.18.3.- Upon receiving an IPv4 address block transfer request, LACNIC shall verify that the organization transferring the block is in fact the holder of said block according to LACNIC's
records. The approved applicant and the organization transferring the resources must present before LACNIC a copy of the legal document supporting the transfer.

2.3.2.18.4.- LACNIC shall maintain a publicly accessible transfer log of all IPv4 address block transfers registered before LACNIC. Said log shall specify the date on which each transaction
took place, the organization from which the transfer originated, the receiving organization, and the block that was transferred.

2.3.2.18.5.- The organization in which the transfer originated shall automatically be ineligible to receive IPv4 resource allocations and/or assignments from LACNIC for a period of one year as of the transaction date registered in the transfer log.

2.3.2.18.6.- A block that has previously been transferred may not subsequently be transferred again for a period of one year as of the transaction date registered in the transfer log. The same applies to its sub-blocks, which are blocks that group a subset of the IPv4 addresses contained in the block.

2.3.2.18.7.- Once the transfer is complete, LACNIC shall modify the information on the transferred resource in order to reflect the change of holder.

2.3.2.18.8.- The receiving organization must comply with all LACNIC policies in force.

2.3.2.18.9.- Blocks and their sub-blocks from allocations or assignments from LACNIC, being initial or additional, can not be transferred for a period of one year as of the allocation or assignment date.

2.3.2.18.10.- Transferred legacy resources will no longer be considered as such.

New text:

2.3.2.18.- IPv4 address transfers

IPv4 block transfers shall be allowed between LIRs and/or End Users (hereinafter organizations) in accordance with the conditions set forth in this section.

If one of the organizations involved is part of another region (inter-RIR transfers), transfers will only be allowed for legacy resources. This restriction does not apply in the case of transfers within the LACNIC region (intra-RIR transfers).

2.3.2.18.1.- The minimum block size that may be transferred is a /24.

2.3.2.18.2.- In order for an organization within the LACNIC region to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 resources before LACNIC. That is to say, the organization must justify before LACNIC the initial/additional allocation/assignment, as applicable, according to
the policies in force.

If the receiving organization is part of another region, it will be subject to the criteria, verifications and requirements of the corresponding RIR.

2.3.2.18.3.- LACNIC or the corresponding RIR (depending on whether the transfer is inbound or outbound) will verify the holder of the resources to be transferred and check that they are not involved in any dispute.

In the case of intra-RIR transfers, both organizations must submit to LACNIC a signed copy of the legal document supporting the transfer.

In the case of inter-RIR transfers, the documentation supporting the operation will be agreed between the two RIRs.

2.3.2.18.4.- LACNIC shall maintain a publicly accessible transfer log of all IPv4 address block transfers registered before LACNIC. This log will be used to record the date on which the transaction took place, the organization that originated the transfer, the receiving organization, the transferred addresses and, in the case of inter-RIR transfers, the source and destination RIRs.

2.3.2.18.5.- The organization that originated the transfer shall automatically be ineligible to receive IPv4 resource allocations and/or assignments from LACNIC for a period of one year as of the transaction date registered in the transfer log.

2.3.2.18.6.- Addresses that have previously been transferred may not subsequently be transferred again (in full or in part) for a period of one year as of the transaction date specified in the transfer log.

2.3.2.18.7.- Once the transfer is complete, LACNIC shall modify the information on the transferred resource in order to reflect the change of holder.

2.3.2.18.8.- Both the transferring and the receiving organizations will be subject to the policies and membership terms and conditions of the corresponding RIR.

2.3.2.18.9.- Addresses from allocations or assignments from LACNIC, whether initial or additional, may not be transferred (in full or in part) for a period of one year as of the allocation or assignment date.

2.3.2.18.10.- Legacy resources transferred into the LACNIC region will no longer be considered legacy resources.

Additional Information

This proposal does not modify any aspect of the existing policy on intra-RIR transfers. Instead, it proposes adjusting the wording to combine the two types of transfers (intra-RIR and inter-RIR transfers) into the same section.

According to LACNIC and based on conversations with the other RIRs, this proposal would allow bidirectional transfers with the RIPE region (including RIPE to LACNIC transfers even in the case of non-legacy resources). Bidirectional transfers with the APNIC and ARIN regions would be limited to legacy resources.

AfriNIC does not have an inter-RIR transfer policy, although a proposal has been submitted by one of the co-authors of this policy proposal.

Timetable

Immediate implementation

References

There are inter-RIR transfer policies in place in APNIC, ARIN and RIPE. These have widely proven their efficiency and have not created any issues for their respective communities, quite the contrary.

ARIN appears to be the region where the transfer of the largest number of addresses to the other regions that have resource transfer policies have originated.
• 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

Public Comments by LACNIC Staff

ACNIC STAFF´S IMPACT ANALYSIS - Proposal LAC-2018-14 - versión 1

LACNIC Staff's Interpretation of the Proposal
--------------------------------------------

Applicability
-------------
This policy would apply when an organization requests transferring resources to an organization in the LACNIC region or, in the case of legacy resources, from the LACNIC region to a different region.
The region in which the transfer originates must have policies in place that allow inter-RIR address transfers.
This may evolve if there are modifications to the policies in force in the different RIRs.

Modifications to the current text
---------------------------------
According the modifications proposed in LAC-2018-14, a new section would be added at the end of the Policy Manual: Inter-RIR Resource Transfer Policy.

LACNIC Staff Comments
-------------------------
IMPORTANT: The comments below are valid today, i.e., February 2019. This, however, may change if new policies are implemented in any of the RIRs.
Compatibility of inter-RIR transfers with each region:
• RIPE NCC: Transfers with the RIPE region would be allowed.
• APNIC: APNIC allows inter-RIR transfers, provided that the other RIR has a policy in place that allows transfers between APNIC and their own region.
Therefore, transfers with the APNIC region would only be allowed in the case of legacy resources.
• AFRINIC: There is currently no inter-RIR transfer policy in force in the AFRINIC region, so transfers between LACNIC and AFRINIC would not be allowed. A policy proposal on inter-RIR transfers is currently under discussion: https://afrinic.net/policy/proposals/2018-gen-003
• ARIN: ARIN's inter-RIR transfer policy specifies that inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies.
The word “reciprocal” means that the ARIN policy would not be compatible with the policy proposed for the LACNIC region, because, as written, the proposal is limited to legacy resources.

It is important to note that the legacy space declared by ARIN in September 2018 was 41 /8 blocks, which represents almost four times the space assigned by LACNIC in our region. In addition, close to 65% of the transfers originating in the ARIN region involve legacy space.

Recommendations
-------------------
• The proposal does not state that inter-RIR transfer would be allowed. The title is immediately followed by the requirements.
There is no text stating, for example, “inter-RIR IPv4 address block transfers shall be allowed...” as in the case of section 2.3.2.18, where this is clearly stated.
• We recommend removing subsection numbers, as these subsections are simply a list of requirements and do not warrant the creation of new subsections.
• We recommend organizing the sections of the manual that address resource transfers in a way that will maintain a logical order. By way of an example, we suggest two options:
o Having a single section covering all types of transfers (IPv4, IPv6 and ASN), which would include both intra- as well as inter-RIR transfers. This is how the policies are organized in the ARIN region.
o Having a subsection on transfers within each section:
 In section 2. IPv4 Address Policies
 In section 4. IPv6 Address Policies
 In section 3. ASN Policies
This is how the policies are organized in the APNIC region.

• As for item 1.7. “Both the transferring and the receiving entities must submit to LACNIC a copy of the legal document supporting the operation,” offering and receiving organizations have no legal documentation supporting the operation, as they are not the owners of the resources and therefore cannot sign a deed of assignment.
For intra-regional transfers (2.3.2.18), LACNIC prepared a transfer agreement which must be signed by the two parties.
However, in the case of inter-RIR transfers it is not clear which documents would need to be submitted. We recommend agreeing this item with the other RIRs. Consequently, it would be convenient not to specify which type of document should be submitted.

Interpretation:
• LACNIC understands that the organizations that have received resources directly from LACNIC or as a result of a prior transfer would be able to request a transfer as often as they wish.

Implementation of the proposal
--------------------------------
• Implementing this proposal would require implementing modifications to the systems in coordination with the other RIRs to ensure that their policies are compatible with transfers under this policy once it is implemented.

Impact of the policy on the registration system and address management
------------------------------------------------------------
• This proposal would require adjusting LACNIC's different systems.

Official Sources
----------------
• Inter-RIR Transfers in the APNIC Service Region:
https://www.apnic.net/manage-ip/manage-resources/transfer-resources/#conditions
• Inter-RIR Transfers in the RIPE NCC Service Region:
https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/inter-rir-transfers
o RIPE Resource Transfer Policy https://www.ripe.net/publications/docs/ripe-682#3-0-inter-rir-transfers
• Inter-RIR Transfers in the ARIN Service Region:
https://www.arin.net/policy/nrpm.html#eight4
• NRO Presentation on Inter-RIR Transfers:
Total number of IPv4 addresses transferred between RIRs. See slide 9
https://www.lacnic.net/innovaportal/file/3201/1/estadisticas_nro.pdf
• Presentation on Inter-RIR Transfers in the Arin Service Region, September 2018:
https://www.lacnic.net/innovaportal/file/3277/1/2-john-sweeting-arin.pdf

Privacy Policy