Inter-RIR Transfer Policy

LAC-2018-14-v1 LAC-2018-14-v2 Vs
References:
New
Deleted
Modified
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

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

Summary

This proposal seeks to establish the mechanism to allow the transfer of resources (IPv4, IPv6, ASNs) between different r
egions and to align LACNIC with an existing market in which the region is not currently participating, something we cons
ider to be negative for the region.

This proposal allows extending the current mechanism for intra-RIR IPv4 address transfers to allow transferring resource
s 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 (Describe the problem you intend to solve)

In recent years and with the exhaustion of IPv4, several regions have solved this problem by allowing not only intra-reg
ional transfers but also transfers between different regions. This allows for market dynamics, as an increased offer red
uces prices.
However, an inter-RIR mechanism has not been established for LACNIC, and this is leading the region to a situation of di
scrimination and address scarcity, not only within the RIR itself, but also in the regional market. This the lack of add
resses 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.
As a protection measure, in the case of IPv4 and ASN, we believe such transfers should only be allowed from LACNIC to ot
her regions if the resources to be transferred are legacy resources, while inbound transfers should be allowed regardles
s of their status. 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 addre
sses for use by the 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 disadvanta
ge 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 occ
ur, but this would quickly align with the global market, as is usually the case with equivalent markets.

In recent years and with the exhaustion of IPv4, several regions have solved this problem by allowing not only intra-reg
ional transfers but also transfers between different regions. This allows for market dynamics, as an increased offer red
uces prices.
However, an inter-RIR mechanism has not been established for LACNIC, and this is leading the region to a situation of di
scrimination and address scarcity, not only within the RIR itself, but also in the regional market. This the lack of add
resses 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 additi
onal 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 addre
sses for their use by transition mechanisms or significantly increase their cost if such blocks are not available, so ma
ny 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 occ
ur, but this would quickly align with the global market, as is usually the case with equivalent markets.

Current text

Current text: –
New text:
(Note: The following text would be added as a new, separate section at the end of the current Policy Manual, with the nu
mbering that LACNIC sees fit and before the Appendixes.)
1. Inter-RIR Transfer Policy
1.1. In the case of IPv4, the minimum size that can be transferred is a /24.
1.2. In the case of IPv6, the minimum size that can be transferred is a /48.
1.3. IPv4 or ASN resources can only be transferred from LACNIC to another RIR if they are legacy resources.
1.4. Resources associated with IPv6 allocations or assignments made by LACNIC may not be transferred until two (2) ye
ars after their distribution or assignment, as appropriate.
1.5. In order for an entity to receive a transfer, it must first complete the process of justifying the need for the
resources, either before LACNIC or before the corresponding RIR (depending on whether the transfer is inbound or outboun
d), as appropriate, according to the policies in force.
1.6. LACNIC or the corresponding RIR (depending on whether the transfer is inbound or outbound) will verify the holde
r of the resources to be transferred and that they are not involved in any dispute.
1.7. Both the transferring and the receiving entities must submit to LACNIC a copy of the legal document supporting t
he operation.
1.8. Both the transferring and the receiving entities will be subject to the policies and membership terms and condit
ions of the corresponding RIR.
1.9. In its existing transfer log, LACNIC will record the date on which the operation took place, the transferring en
tity, the receiving entity, the corresponding RIR in each case, and other relevant data of the transferred resource.
1.10. Once the transfer is complete, LACNIC will modify the information on the transferred resource to reflect the ch
ange of holder.
1.11. Transferred blocks (as well as their sub-blocks) may not be subsequently transferred for a period of one year a
s of the date on which the transaction is registered in the transfer log.
1.12. Legacy resources transferred into the LACNIC region will no longer be considered legacy resources.

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 j
ustifying 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 transferri
ng 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 bef
ore 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 tran
sferred.
2.3.2.18.5.- The organization in which the transfer originated shall automatically be ineligible to receive IPv4 resourc
e allocations and/or assignments from LACNIC for a period of one year as of the transaction date registered in the trans
fer 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 tha
t 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 n
ot 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 c
onditions 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 transfer
s).
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 befor
e 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 requireme
nts 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 support
ing 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 bef
ore LACNIC. This log will be used to record the date on which the transaction took place, the organization that originat
ed the transfer, the receiving organization, the transferred addresses and, in the case of inter-RIR transfers, the sour
ce and destination RIRs.
2.3.2.18.5.- The organization that originated the transfer shall automatically be ineligible to receive IPv4 resource al
locations 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 pa
rt) 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 transferre
d (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.

New text

Current text: –
New text:
(Note: The following text would be added as a new, separate section at the end of the current Policy Manual, with the nu
mbering that LACNIC sees fit and before the Appendixes.)
1. Inter-RIR Transfer Policy
1.1. In the case of IPv4, the minimum size that can be transferred is a /24.
1.2. In the case of IPv6, the minimum size that can be transferred is a /48.
1.3. IPv4 or ASN resources can only be transferred from LACNIC to another RIR if they are legacy resources.
1.4. Resources associated with IPv6 allocations or assignments made by LACNIC may not be transferred until two (2) ye
ars after their distribution or assignment, as appropriate.
1.5. In order for an entity to receive a transfer, it must first complete the process of justifying the need for the
resources, either before LACNIC or before the corresponding RIR (depending on whether the transfer is inbound or outboun
d), as appropriate, according to the policies in force.
1.6. LACNIC or the corresponding RIR (depending on whether the transfer is inbound or outbound) will verify the holde
r of the resources to be transferred and that they are not involved in any dispute.
1.7. Both the transferring and the receiving entities must submit to LACNIC a copy of the legal document supporting t
he operation.
1.8. Both the transferring and the receiving entities will be subject to the policies and membership terms and condit
ions of the corresponding RIR.
1.9. In its existing transfer log, LACNIC will record the date on which the operation took place, the transferring en
tity, the receiving entity, the corresponding RIR in each case, and other relevant data of the transferred resource.
1.10. Once the transfer is complete, LACNIC will modify the information on the transferred resource to reflect the ch
ange of holder.
1.11. Transferred blocks (as well as their sub-blocks) may not be subsequently transferred for a period of one year a
s of the date on which the transaction is registered in the transfer log.
1.12. Legacy resources transferred into the LACNIC region will no longer be considered legacy resources.

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 j
ustifying 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 transferri
ng 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 bef
ore 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 tran
sferred.
2.3.2.18.5.- The organization in which the transfer originated shall automatically be ineligible to receive IPv4 resourc
e allocations and/or assignments from LACNIC for a period of one year as of the transaction date registered in the trans
fer 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 tha
t 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 n
ot 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 c
onditions 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 transfer
s).
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 befor
e 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 requireme
nts 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 support
ing 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 bef
ore LACNIC. This log will be used to record the date on which the transaction took place, the organization that originat
ed the transfer, the receiving organization, the transferred addresses and, in the case of inter-RIR transfers, the sour
ce and destination RIRs.
2.3.2.18.5.- The organization that originated the transfer shall automatically be ineligible to receive IPv4 resource al
locations 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 pa
rt) 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 transferre
d (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

Although it is still pending verification, it appears that this proposal would be compatible with the Inter-RIR transfer
policies of APNIC, ARIN and RIPE, as they are all bidirectional.

This proposal does not modify any aspect of the existing policy on intra-RIR transfers. Instead, it proposes adjusting t
he 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 wi
th the RIPE region (including RIPE to LACNIC transfers even in the case of non-legacy resources). Bidirectional transfer
s 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 t
his policy proposal.

References

There are Inter-RIR policies in place in APNIC, ARIN and RIPE. These have widely proven their efficiency and have not cr
eated 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 resou
rce transfer policies have originated.
• http://www.lacnic.net/innovaportal/file/3277/1/2-john-sweeting-arin.pdf
• https://ripe77.ripe.net/presentations/145-18-0903-NRO-Statistics-2018.pdf

There are inter-RIR transfer policies in place in APNIC, ARIN and RIPE. These have widely proven their efficiency and ha
ve 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 resou
rce 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