One-way interregional transfers to LACNIC

Original Language Español Date Published 02/02/2017 Last Modified 16/08/2017
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 3.0 (compare)

Authors

Name: Daniel Miroli
Email: daniel@iptrading.com
Organization: IP Trading

Name: Edmundo Caceres
Email: edmundo.cazarez@nic.mx
Organization: NIC Mexico

Proposal Data

Policy Type: LACNIC
Id: LAC-2017-2
Last version: 3
Presentations:

Summary

This proposal seeks to create a mechanism that will only allow transferring addresses from the other regions towards the LAC region.

This proposal does not consider transfers from the LAC region to other regions.

Rationale

IPv4 address exhaustion has brought about different scenarios for network operators in the LAC region and in regions where the Regional Registry has run out of available addresses.

All solutions point to IPv6 adoption, which will solve the shortage of addresses, but even those organizations which are working on adopting the new protocol require IPv4 addresses to facilitate the transition.

At the moment, it is not possible to simply turn on IPv6 and shutdown IPv4 and thus change from one protocol to another.

It is also important to consider that the absence of a policy allowing inter-regional transfers does not mean such transfers do not occur. Instead, it simply means they these transfers not appear as such in the corresponding registries.

One of the key tasks of Regional Registries is maintain up-to-date and valid information, so that it will be useful for the purposes for which it is required.

The existence of a policy that allows transferring address blocks from other regions to the LAC region will make it easier to maintain the Registry information, while temporarily alleviating some of the problems faced by operators transferring addresses into the region.

Text

Current text:

2.3.2.18. Transfer of IPv4 Blocks within the LACNIC Region

Proposed Text:

2.3.2.18. Transfer of IPv4 Blocks within and towards the LACNIC Region

Current text:

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.

Proposed Text:

2.3.2.18.3. Upon receiving an IPv4 address block transfer request where the transferring organization is located in the LACNIC region, LACNIC shall verify that the organization transferring the block is in fact the holder of said block according to LACNIC's records. If the transferring organization is located in the region of an RIR with policies in force that allow address transfers to LACNIC, LACNIC shall accept the RIR's verification that the transferring organization is the holder of said block. The approved applicant and the organization transferring the resources must present before LACNIC a copy of the legal document supporting the transfer.

Current text
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.

Proposed Text:

2.3.2.18.4. LACNIC shall maintain a publicly accessible transfer log of all IPv4 address block transfers registered before the organization. This log shall specify the date on which each operation took place, the transferring organization, the origin RIR, the receiving organization, and the block that was transferred.

Current text

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 date on which the operation is recorded in the transfer log. The same applies to its sub-blocks, i.e. blocks consisting of a subset of the IPv4 addresses contained in the block.

Proposed text

2.3.2.18.6. A block previously transferred under this policy may not subsequently be transferred for a period of one year as of the date on which the operation is recorded in the transfer log. The same applies to its sub-blocks, i.e. blocks consisting of a subset of the IPv4 addresses contained in the block.

Additional Information

ARIN requires reciprocity, so this policy would not apply to transfers originating in the ARIN region.

APNIC requires a compatible policy and currently processes transfers with NIRs such as VNNIC and CNNIC which authorize incoming transfers.

Everything seems to indicate that RIPE would allow one-way transfers to LACNIC members.

Timetable

Urgent

References

In reference to an exchange with AFRINIC, RIPE member Sander Steffan was asked about his views on one-way transfer policies, he replied the following:
Without issuing an opinion on the current policy proposal, I can say it would be compatible with RIPE transfer policies. Address space can be re-allocated to another resource holder who is a member of a registry that allows transfers. If AFRINIC allows incoming transfers, RIPE allows outgoing transfers.

Studying the IPv4 Transfer Market: Reported Transfers
https://labs.ripe.net/Members/ioana_livadariu/studying-the-ipv4-transfer-market

ARIN Reciprocity requirement
http://lists.arin.net/pipermail/arin-ppml/2017-January/062351.html

RIPE statement on inbound transfers on AFRINIC's mailing list:
https://lists.afrinic.net/pipermail/rpd/2017/006323.html

Public Comments by LACNIC Staff

LACNIC STAFF´S IMPACT ANALYSIS - Proposal LAC-2017-2 - version 2

LACNIC Staff's Interpretation of the Proposal
---------------------------------------------
Application of Section 2.3.2.18
------------------------------
This section will be applied when a source organization submits a request to transfer an IPv4 block to an organization in the LACNIC region. The source organization may be part of our region or of a region whose RIR policies allow the transfer of addresses to the LACNIC region. This may evolve as the policies of each RIR are modified.
This policy does not apply to “Mergers, Acquisitions or Sales among ISPs or End Users (Section: 2.3.2.17)”.

Modification to the current text
-------------------------------
According to the modifications included in policy proposal 2017-2, the Policy Manual would change as follows:

• The text in Section 2.3.2.18.3 would be replaced by: “Upon receiving an IPv4 address block transfer request where the transferring organization is located in the LACNIC region, LACNIC shall verify that the organization transferring the block is in fact the holder of said block according to LACNIC's records. If the transferring organization is located in the region of an RIR with policies in force that allow address transfers to LACNIC, LACNIC shall accept the RIR's verification that the transferring organization is the holder of said block. The approved applicant and the organization transferring the resources must present before LACNIC a copy of the legal document supporting the transfer.”

• The text in Section 2.3.2.18.4 would be replaced by: “LACNIC shall maintain a publicly accessible transfer log of all IPv4 address block transfers registered before LACNIC. This log shall specify the date on which each transaction took place, the transferring organization, the origin RIR, the receiving organization and the block that was transferred.”

• The text in Section 2.3.2.18.6 would be replaced by: “A block previously transferred under this policy may not subsequently be transferred for a period of one year as of the date on which the operation is recorded in the transfer log. The same applies to its sub-blocks, i.e. blocks consisting of a subset of the IPv4 addresses contained in the block.”

Recommendation:
• The current title of Section 2.3.2.18 of the Policy Manual is: “Transfer of IPv4 Blocks within the LACNIC Region.” However, the proposed changes to the section mean that both transfers within the region as well as one-way transfers to the LACNIC region would be possible. We recommend modifying the title of this section so that it correctly represents its content or, alternately, creating a new section exclusively for inter-RIR (one-way) transfers.
• In Section 2.3.2.18.4 we recommend replacing the term “transaction” with “operation.”

COMMENTS FROM OTHER RIRS ABOUT THE IMPLEMENTATION OF THIS POLICY
---------------------------------------------------------------------------------
IMPORTANT: This comments are valid today (april, 2017). However, this might change due to new policies implemented in the future.

RIPE NCC: Transfers with RIPE region would be allowed.

APNIC: Transfers with APNIC region would be allowed.

AFRINIC: There is not a inter-RIR transfer policy, so it would not be allowed.

ARIN: ARIN’s inter-RIR transfer policy states "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies.”

The word “reciprocal” prevents ARIN from being compatible with either AFRINIC or LACNIC’s proposed one-way transfer policies.
There is a recent Draft Policy under discussion that addresses this, and as such may impact ARIN’s compatibility in the future. To keep up with this discussion:
https://www.arin.net/policy/proposals/2017_4.html

Implementation of the Proposal
-------------------------------
Implementing this proposal requires articulating changes in the systems in coordination with those RIRs which, at the time of implementing the proposal, have policies in force that are compatible with transfers as described in this proposal.

Impact of the Policy on the Registry System and the Addressing Pool
---------------------------------------------------------------------
This proposal would involve adjustments to LACNIC's various systems.