This proposal allows transferring IPv4 addresses between different regions.
Rationale (Describe the problem you intend to solve)This proposal allows transferring IPv4 addresses between different regions.
The authors believe that disallowing inter-RIR IPv4 address transfers creates a differential status for its members when most RIRs already have or are in the process of implementing policies that support them.
The arguments that justify allowing IPv4 address transfers between different regions and LACNIC include:
IPv4 address markets are already a reality: IPv4 address transfers may already be happening in the region without generating any records in LACNIC's database. The authors believe that LACNIC’s Registration function in maintaining an updated record of the holders of IPv4 resources is essential to the proper functioning of the Internet.
APNIC, RIPE and ARIN already have inter-RIR IPv4 address transfer policies in force or policy proposals seeking to allow such transfers. APNIC currently has an inter-RIR IPv4 address transfer policy. LACNIC needs to adapt its processes and tools to consider a future in which IPv4 address transfers –including inter-RIR transfers– will be frequent.
This proposal contains enough safeguards to allow an orderly inter-RIR IPv4 address market where transfers originate or terminate in the LACNIC region.
Current textAfriNIC, APNIC, ARIN and RIPE are considered foreign RIRs as long as they have a policy in place that allows transferring IPv4 resources between different regions.
A foreign entity is an entity that is part of a foreign RIR and is not part of LACNIC.
A local entity is an entity that is part of LACNIC.
IPv4 resources that may be transferred from LACNIC to a foreign RIR:
• The minimum block size that may be transferred is a /24.
• In order for a foreign organization to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 address needs before LACNIC. In other words, the foreign entity must justify before LACNIC the initial/additional allocation/assignment.
• Upon receiving an IPv4 address block transfer request, LACNIC shall verify that the local organization transferring the block is in fact the holder of said block according to LACNIC's records. The foreign entity and the local entity must present before LACNIC a copy of the legal document supporting the transfer.
• The local organization taking part in 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.
• Blocks and sub-blocks from initial or additional allocations or assignments received from LACNIC can not be transferred for a period of one year as of their date of allocation or assignment.
• Once the transfer is complete, LACNIC shall modify the information on the transferred resource in order to reflect the change of holder.
• Transferred legacy resources shall no longer be considered as such before completing the transfer; therefore, the foreign RIR shall receive the block as a non-legacy block.
IPv4 resources that may be transferred from a foreign RIR to LACNIC:
• The minimum block size that may be transferred is a /24.
• In order for a local organization to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 address needs before LACNIC. In other words, the local organization must justify before LACNIC the initial/additional allocation/assignment, as applicable, according to the policies in force.
• The foreign entity and the local entity must present before LACNIC a copy of the legal document supporting the transfer.
• 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, i.e. blocks consisting of a subset of the IPv4 addresses contained in the block.
• Once the transfer is complete, LACNIC shall modify the information on the transferred resource in order to reflect the change of holder.
• The local organization must comply with all LACNIC policies in force.
• Transferred legacy resources shall no longer be considered as such before completing the transfer; therefore, LACNIC shall receive the block as a non-legacy block.
New textAfriNIC, APNIC, ARIN and RIPE are considered foreign RIRs as long as they have a policy in place that allows transferring IPv4 resources between different regions.
A foreign entity is an entity that is part of a foreign RIR and is not part of LACNIC.
A local entity is an entity that is part of LACNIC.
IPv4 resources that may be transferred from LACNIC to a foreign RIR:
• The minimum block size that may be transferred is a /24.
• In order for a foreign organization to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 address needs before LACNIC. In other words, the foreign entity must justify before LACNIC the initial/additional allocation/assignment.
• Upon receiving an IPv4 address block transfer request, LACNIC shall verify that the local organization transferring the block is in fact the holder of said block according to LACNIC's records. The foreign entity and the local entity must present before LACNIC a copy of the legal document supporting the transfer.
• The local organization taking part in 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.
• Blocks and sub-blocks from initial or additional allocations or assignments received from LACNIC can not be transferred for a period of one year as of their date of allocation or assignment.
• Once the transfer is complete, LACNIC shall modify the information on the transferred resource in order to reflect the change of holder.
• Transferred legacy resources shall no longer be considered as such before completing the transfer; therefore, the foreign RIR shall receive the block as a non-legacy block.
IPv4 resources that may be transferred from a foreign RIR to LACNIC:
• The minimum block size that may be transferred is a /24.
• In order for a local organization to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 address needs before LACNIC. In other words, the local organization must justify before LACNIC the initial/additional allocation/assignment, as applicable, according to the policies in force.
• The foreign entity and the local entity must present before LACNIC a copy of the legal document supporting the transfer.
• 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, i.e. blocks consisting of a subset of the IPv4 addresses contained in the block.
• Once the transfer is complete, LACNIC shall modify the information on the transferred resource in order to reflect the change of holder.
• The local organization must comply with all LACNIC policies in force.
• Transferred legacy resources shall no longer be considered as such before completing the transfer; therefore, LACNIC shall receive the block as a non-legacy block.
Additional informationNO
TimetableImmediate
ReferencesNONE
Presented at:-
This proposal allows transferring IPv4 addresses between different regions.
Rationale (Describe the problem you intend to solve)This proposal allows transferring IPv4 addresses between different regions.
The authors believe that disallowing inter-RIR IPv4 address transfers creates a differential status for its members when most RIRs already have or are in the process of implementing policies that support them.
The arguments that justify allowing IPv4 address transfers between different regions and LACNIC include:
IPv4 address markets are already a reality: IPv4 address transfers may already be happening in the region without generating any records in LACNIC's database. The authors believe that LACNIC’s Registration function in maintaining an updated record of the holders of IPv4 resources is essential to the proper functioning of the Internet.
APNIC, RIPE and ARIN already have inter-RIR IPv4 address transfer policies in force or policy proposals seeking to allow such transfers. APNIC currently has an inter-RIR IPv4 address transfer policy. LACNIC needs to adapt its processes and tools to consider a future in which IPv4 address transfers –including inter-RIR transfers– will be frequent.
This proposal contains enough safeguards to allow an orderly inter-RIR IPv4 address market where transfers originate or terminate in the LACNIC region.
Current textAfriNIC, APNIC, ARIN and RIPE are considered foreign RIRs as long as they have a policy in place that allows transferring IPv4 resources between different regions.
A foreign entity is an entity that is part of a foreign RIR and is not part of LACNIC.
A local entity is an entity that is part of LACNIC.
IPv4 resources that may be transferred from LACNIC to a foreign RIR:
• The minimum block size that may be transferred is a /24.
• In order for a foreign entity to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 address needs before the RIR receiving the address space. In other words, the foreign entity must justify before its RIR the initial/additional allocation/assignment. If the receiving RIR approves the transfer, LACNIC shall proceed to transfer custody of the address space to that RIR.
• Upon receiving an IPv4 address block transfer request, LACNIC shall verify that the local entity transferring the block is in fact the holder of said block according to LACNIC's records. The foreign entity and the local entity must present before LACNIC a copy of the legal document supporting the transfer.
• The local entity 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.
• IPv4 resources assigned/allocated by LACNIC during the past year can not be transferred to a foreign RIR.
• Once the transfer is complete, LACNIC shall modify the information on the transferred resource in order to reflect the change of holder.
• Transferred legacy resources shall no longer be considered as such before completing the transfer; therefore, the foreign RIR shall receive the block as a non-legacy block.
IPv4 resources that may be transferred from a foreign RIR to LACNIC:
• The minimum block size that may be transferred is a /24.
• In order for a local entity to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 address needs before LACNIC. In other words, the local entity must justify before LACNIC the initial/additional allocation/assignment, as applicable, according to the policies in force.
• The local entity must comply with all LACNIC policies in force.
• The foreign entity and the local entity must present before LACNIC a copy of the legal document supporting the transfer.
• Once the transfer is complete, LACNIC shall modify the information on the transferred resource in order to reflect the change of holder.
• Transferred legacy resources shall no longer be considered as such; therefore, LACNIC shall receive the block as a non-legacy block.
• Transferred resources may not subsequently be transferred for a period of one year as of the transaction date registered 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.
AfriNIC, APNIC, ARIN and RIPE are considered foreign RIRs as long as they have a policy in place that allows transferring IPv4 resources between different regions.
A foreign entity is an entity that is part of a foreign RIR and is not part of LACNIC.
A local entity is an entity that is part of LACNIC.
IPv4 resources that may be transferred from LACNIC to a foreign RIR:
• The minimum block size that may be transferred is a /24.
• In order for a foreign entity to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 address needs before the RIR receiving the address space. In other words, the foreign entity must justify before its RIR the initial/additional allocation/assignment. If the receiving RIR approves the transfer, LACNIC shall proceed to transfer custody of the address space to that RIR.
• Upon receiving an IPv4 address block transfer request, LACNIC shall verify that the local entity transferring the block is in fact the holder of said block according to LACNIC's records. The foreign entity and the local entity must present before LACNIC a copy of the legal document supporting the transfer.
• The local entity 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.
• IPv4 resources assigned/allocated by LACNIC during the past year can not be transferred to a foreign RIR.
• Once the transfer is complete, LACNIC shall modify the information on the transferred resource in order to reflect the change of holder.
• Transferred legacy resources shall no longer be considered as such before completing the transfer; therefore, the foreign RIR shall receive the block as a non-legacy block.
IPv4 resources that may be transferred from a foreign RIR to LACNIC:
• The minimum block size that may be transferred is a /24.
• In order for a local entity to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 address needs before LACNIC. In other words, the local entity must justify before LACNIC the initial/additional allocation/assignment, as applicable, according to the policies in force.
• The local entity must comply with all LACNIC policies in force.
• The foreign entity and the local entity must present before LACNIC a copy of the legal document supporting the transfer.
• Once the transfer is complete, LACNIC shall modify the information on the transferred resource in order to reflect the change of holder.
• Transferred legacy resources shall no longer be considered as such; therefore, LACNIC shall receive the block as a non-legacy block.
• Transferred resources may not subsequently be transferred for a period of one year as of the transaction date registered 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.
NO
TimetableImmediata
ReferencesNO
Presented at:LACNIC 18 (28/10/2012)
This proposal allows transferring IPv4 addresses between different regions.
Rationale (Describe the problem you intend to solve)This proposal allows transferring IPv4 addresses between different regions.
The authors believe that disallowing inter-RIR IPv4 address transfers creates a differential status for its members, as most RIRs already have or are in the process of implementing policies that support these transfers.
The arguments that justify allowing IPv4 address transfers between different regions and Lacnic include:
IPv4 address markets are already a reality: IPv4 address transfers may already be happening in the region without generating any records in Lacnci's database. The authors believe that Lacnic’s Registry function in maintaining an updated record of the holders of IPv4 resources is essential to the proper functioning of the Internet.
APNIC, RIPE and ARIN already have inter-RIR IPv4 address transfer policies in force or policy proposals seeking to allow such transfers. APNIC currently has an inter-RIR IPv4 address transfer policy. Lacnic needs to adapt its processes and tools to consider a future in which IPv4 address transfers, including inter-RIR transfers, will be frequent.
This proposal contains enough provisions to allow an orderly inter-RIR IPv4 address market when transfers originate or terminate in the LACNIC region.
Current textNOTE: This section will come into force when Lacnic or any of its NIRs becomes unable, for the first time, to cover an IPv4 block allocation or assignment for lack of resources.
AfriNIC, APNIC, ARIN and RIPE are considered foreign RIRs as long as they have a policy in place that allows transferring IPv4 resources between different regions.
A foreign entity is an entity that is part of a foreign RIR and is not part of Lacnic.
A local entity is an entity that is part of Lacnic.
IPv4 resources transferred from Lacnic to a foreign RIR:
• The minimum block size that may be transferred is a /24.
• In order for a foreign entity to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 address needs before the RIR receiving the address space. In other words, the foreign entity must justify the initial/additional allocation/assignment before its RIR. If the receiving RIR approves the transfer, Lacnic shall proceed to transfer custody of the address space to said RIR.
• Upon receiving an IPv4 address block transfer request, Lacnic shall verify that the local entity transferring the block is in fact the holder of said block according to Lacnic's records. The foreign entity and the local entity must present before Lacnic a copy of the legal document supporting the transfer.
• The local entity 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.
• IPv4 resources assigned/allocated by Lacnic during the past year may not be transferred to a foreign RIR.
• Once the transfer is complete, Lacnic shall modify the information on the transferred resource to reflect the change of holder.
• Before completing the transfer, transferred legacy resources shall no longer be considered as such; therefore, the foreign RIR shall receive the block as a non-legacy block.
IPv4 resources transferred from a foreign RIR to Lacnic:
• The minimum block size that may be transferred is a /24.
• In order for a local entity to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 address needs before Lacnic. That is to say, the local entity must justify the initial/additional allocation/assignment, as applicable, before Lacnic according to the policies in force.
• The local entity must comply with all Lacnic policies in force.
• The foreign entity and the local entity must present before Lacnic a copy of the legal document supporting the transfer.
• Once the transfer is complete, Lacnic shall modify the information on the transferred resource to reflect the change of holder.
• Transferred legacy resources shall no longer be considered as such; therefore, Lacnic shall receive the block as non-legacy block.
• Transferred blocks may not subsequently be transferred for a period of one year as of the transaction date registered 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.
NOTE: This section will come into force when Lacnic or any of its NIRs becomes unable, for the first time, to cover an IPv4 block allocation or assignment for lack of resources.
AfriNIC, APNIC, ARIN and RIPE are considered foreign RIRs as long as they have a policy in place that allows transferring IPv4 resources between different regions.
A foreign entity is an entity that is part of a foreign RIR and is not part of Lacnic.
A local entity is an entity that is part of Lacnic.
IPv4 resources transferred from Lacnic to a foreign RIR:
• The minimum block size that may be transferred is a /24.
• In order for a foreign entity to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 address needs before the RIR receiving the address space. In other words, the foreign entity must justify the initial/additional allocation/assignment before its RIR. If the receiving RIR approves the transfer, Lacnic shall proceed to transfer custody of the address space to said RIR.
• Upon receiving an IPv4 address block transfer request, Lacnic shall verify that the local entity transferring the block is in fact the holder of said block according to Lacnic's records. The foreign entity and the local entity must present before Lacnic a copy of the legal document supporting the transfer.
• The local entity 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.
• IPv4 resources assigned/allocated by Lacnic during the past year may not be transferred to a foreign RIR.
• Once the transfer is complete, Lacnic shall modify the information on the transferred resource to reflect the change of holder.
• Before completing the transfer, transferred legacy resources shall no longer be considered as such; therefore, the foreign RIR shall receive the block as a non-legacy block.
IPv4 resources transferred from a foreign RIR to Lacnic:
• The minimum block size that may be transferred is a /24.
• In order for a local entity to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 address needs before Lacnic. That is to say, the local entity must justify the initial/additional allocation/assignment, as applicable, before Lacnic according to the policies in force.
• The local entity must comply with all Lacnic policies in force.
• The foreign entity and the local entity must present before Lacnic a copy of the legal document supporting the transfer.
• Once the transfer is complete, Lacnic shall modify the information on the transferred resource to reflect the change of holder.
• Transferred legacy resources shall no longer be considered as such; therefore, Lacnic shall receive the block as non-legacy block.
• Transferred blocks may not subsequently be transferred for a period of one year as of the transaction date registered 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.
NO
TimetableEsta sección entrará en vigor cuando LACNIC o alguno de sus NIRs sea incapaz, por primera vez, de cubrir una distribución o asignación de un bloque IPv4 por falta de recursos
ReferencesNO
Presented at:LACNIC 19 (05/05/2013)