One-way interregional transfers to LACNIC

LAC-2017-2-v2 LAC-2017-2-v3 Vs
References:
New
Deleted
Modified
Authors

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

Name: Daniel Miroli
Email: daniel@iptrading.com
Organization: IP Trading
Name: Edmundo Caceres
Email: edmundo.cazarez@nic.mx
Organization: NIC Mexico

Summary

Allow one-way IPv4 address transfers originating in other regional registries towards LACNIC

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 (Describe the problem you intend to solve)

With the exception of AFRINIC, all RIRs have exhausted their available IPv4 address pools. The only solution to this pro
blem is replacing them with IPv6 addresses. However, the reality is that IPv6 implementation in commercial networks is t
aking longer than expected. This situation has an economic and developmental impact on operators of all sizes, who are s
eeking solutions to this problem, such as implementing NAT or purchasing IPv4 resources under the transfer policies in f
orce at each RIR.
Recent studies conducted by RIPE and ARIN demonstrate that operators that acquire IPv4 resources exhibit greater growth
in terms of IPv6 utilization, which indicates that the more an operator grows its IPv4 network, the more it uses IPv6. T
hus, an operator which manages to increase its IPv4 resources is not delaying but rather increasing the use of IPv6.
LACNIC's current transfer policies (intra-regional transfers) provide minimum relief to the need for IPv4 addresses, as
they rely on the availability of LACNIC members willing to transfer their excess resources.
Reality makes it clear that there are very few resources available for transfer in the LACNIC region, and this translate
s into less Internet growth and economic development.
A policy of one-way interregional transfers towards LACNIC would allow a large number of operators throughout the region
to acquire resources and have them duly registered within LACNIC, while at the same time growing their networks and acc
elerating IPv6 use and penetration.

IPv4 address exhaustion has brought about different scenarios for network operators in the LAC region and in regions whe
re 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 trans
fers 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 easi
er to maintain the Registry information, while temporarily alleviating some of the problems faced by operators transferr
ing addresses into the region.

Current text

Current text:
2.3.2.18.3.- Upon receiving an IPv4 address block transfer request, LACNIC shall verify that the organization transferri
ng the block is in fact the holder of said block according to LACNIC's records. The approved applicant and the organizat
ion transferring the resources must present before LACNIC a copy of the legal document supporting the transfer.
Proposed text:
2.3.2.18.3.(v.1)-.Upon receiving an IPv4 address block transfer request where the transferring organization is located i
n the LACNIC region, LACNIC shall verify that the organization transferring the block is in fact the holder of said bloc
k according to LACNIC's records. If the transferring organization is located in the region of an RIR with policies in fo
rce that allow address transfers to LACNIC, LACNIC shall accept the RIR's verification that the transferring organizatio
n is the holder of said block. The approved applicant and the organization transferring the resources must present befor
e 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 bef
ore LACNIC. Said log shall specify the date on which each transaction took place, the organization from which the transf
er originated, the receiving organization, and the block that was transferred.
Proposed text:
2.3.2.18.4 (v.1).- LACNIC shall maintain a publicly accessible transfer log of all IPv4 address block transfers register
ed before LACNIC. This log shall specify the date on which each transaction took place, the transferring organization, t
he origin RIR, the receiving organization and the block that was transferred.
Current text:
2.3.2.18.6.- A block that has been previously transferred may not be transferred again for a period of one year as of th
e transaction date registered in the transfer log. The same applies to its sub-blocks, i.e., blocks consisting of a subs
et of the IPv4 addresses contained in the block.
Proposed text:
2.3.2.18.6.(v.1)- A block previously transferred under this policy may not subsequently be transferred for a period of o
ne 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.

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 transferrin
g the block is in fact the holder of said block according to LACNIC's records. The approved applicant and the organizati
on 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 acco
rding to LACNIC's records. If the transferring organization is located in the region of an RIR with policies in force th
at allow address transfers to LACNIC, LACNIC shall accept the RIR's verification that the transferring organization is t
he holder of said block. The approved applicant and the organization transferring the resources must present before LACN
IC 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 befo
re LACNIC. Said log shall specify the date on which each transaction took place, the organization from which the transfe
r 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 befo
re 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 yea
r 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.

New text

Current text:
2.3.2.18.3.- Upon receiving an IPv4 address block transfer request, LACNIC shall verify that the organization transferri
ng the block is in fact the holder of said block according to LACNIC's records. The approved applicant and the organizat
ion transferring the resources must present before LACNIC a copy of the legal document supporting the transfer.
Proposed text:
2.3.2.18.3.(v.1)-.Upon receiving an IPv4 address block transfer request where the transferring organization is located i
n the LACNIC region, LACNIC shall verify that the organization transferring the block is in fact the holder of said bloc
k according to LACNIC's records. If the transferring organization is located in the region of an RIR with policies in fo
rce that allow address transfers to LACNIC, LACNIC shall accept the RIR's verification that the transferring organizatio
n is the holder of said block. The approved applicant and the organization transferring the resources must present befor
e 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 bef
ore LACNIC. Said log shall specify the date on which each transaction took place, the organization from which the transf
er originated, the receiving organization, and the block that was transferred.
Proposed text:
2.3.2.18.4 (v.1).- LACNIC shall maintain a publicly accessible transfer log of all IPv4 address block transfers register
ed before LACNIC. This log shall specify the date on which each transaction took place, the transferring organization, t
he origin RIR, the receiving organization and the block that was transferred.
Current text:
2.3.2.18.6.- A block that has been previously transferred may not be transferred again for a period of one year as of th
e transaction date registered in the transfer log. The same applies to its sub-blocks, i.e., blocks consisting of a subs
et of the IPv4 addresses contained in the block.
Proposed text:
2.3.2.18.6.(v.1)- A block previously transferred under this policy may not subsequently be transferred for a period of o
ne 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.

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 transferrin
g the block is in fact the holder of said block according to LACNIC's records. The approved applicant and the organizati
on 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 acco
rding to LACNIC's records. If the transferring organization is located in the region of an RIR with policies in force th
at allow address transfers to LACNIC, LACNIC shall accept the RIR's verification that the transferring organization is t
he holder of said block. The approved applicant and the organization transferring the resources must present before LACN
IC 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 befo
re LACNIC. Said log shall specify the date on which each transaction took place, the organization from which the transfe
r 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 befo
re 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 yea
r 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 i
ncoming transfers.
Everything seems to indicate that RIPE would allow one-way transfers to LACNIC members.

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 i
ncoming transfers.
Everything seems to indicate that RIPE would allow one-way transfers to LACNIC members.

References

In reference to an exchange with AFRINIC, when a member of RIPE was asked about his views on one-way transfer policies,
Sander Steffan said the following: Without issuing an opinion on the current policy proposal, I can say it would be comp
atible with RIPE transfer policies. Address space can be re-allocated to another resource holder who is a member of a re
gistry 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 (Click on Next Message in Thread to read ARIN communi
ty responses)
RIPE statement on inbound transfers on AFRINIC mailing list:
https://lists.afrinic.net/pipermail/rpd/2017/006323.html

In reference to an exchange with AFRINIC, RIPE member Sander Steffan was asked about his views on one-way transfer polic
ies, 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 AF
RINIC 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