LACNIC's current policies consider only permanent IPv4 address transfers.
This proposal specifies a policy change to allow temporary transfers.
Rationale (Describe the problem you intend to solve)Mixed feelings exist among the community when we discuss the need to allow the leasing of addresses (broadly understood as any of its possible modalities) as a mechanism for transitioning to IPv6 or to allow new entrants. However, we are forgetting that a community-accepted mechanism already exists. This mechanism could be slightly modified to be equivalent to leasing, and yet have multiple advantages for both parties: temporary transfers.
The goal is to guarantee compliance with the policies through a system equivalent to leasing, which allows avoiding security issues, control by the RIR/NIR, and the guarantee that the addresses will be returned at the conclusion of the lease period.
At the same time, the proposal seeks to address the need for flexibility without excessive operational burden for the RIR/NIR, so that the lease period can simply be extended, in the understanding that there may be situations where the initially agreed-upon term is not sufficient to cover the initial need.
It is important to stress that those who need these transfers by way of a “lease” tend to be smaller entities or entities where initial investments are more moderate and, consequently, financially weaker. Therefore, given that the ultimate goal must be IPv6 deployment, using IPv6-only and IPv4aaS, the number of IPv4 addresses that may be needed will be actually reduced.
Finally, the proposal seeks to prioritize regional benefit, which is why it makes sense that it should apply only to transactions carried out in the region. Furthermore, this prevents permanent transfers from losing reciprocity with those regions that require reciprocity.
The Board could establish specific rates for this type of transfer and/or for their extension.
Current text2.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.
This policy applies both to transfers where one of the organizations involved is part of another region (inter-RIR transfers) as well as to 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 entities 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 three years as of their allocation or assignment date.
2.3.2.18.10. Legacy resources transferred into the LACNIC region will no longer be considered legacy resources.
New text2.3.2.18. Temporary and Permanent IPv4 Address Transfers
Both temporary and permanent IPv4 address transfers will be allowed between LIRs and/or end users (hereinafter “entities”), under the conditions below.
This policy applies both to transfers where one of the entities involved is part of another region (inter-RIR transfers) as well as to transfers within the LACNIC region (intra-RIR transfers). However, temporary transfers will only be allowed within the region (temporary 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 entity within the LACNIC region to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 resources before LACNIC. In other words, the entity must justify before LACNIC the initial/additional allocation/assignment, as applicable, according to the policies in force.
However, in the case of temporary transfers, a specific recipient may only receive (in total) a maximum of a /20.
If the receiving entity is in 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 entities 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 transaction 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 initial date on which the transaction took place, the entity that originated the transfer, the receiving entity, the transferred addresses, the end date of the transaction, and in the case of inter-RIR transfers, the source and destination RIRs.
In the case of permanent transfers, the end date of the transaction will be left blank. For temporary transfers, the specific end date of the transfer will be specified. This value shall be updated in the event of an agreement to extend the initially agreed-upon term, a decision that must be formally endorsed by both parties and verified by LACNIC.
An extension of the term must be requested at least 30 days before the end date of the previously agreed-upon transaction.
2.3.2.18.5. The entity 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 recorded in the transfer log.
2.3.2.18.6. In the case of permanent transfers, 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 recorded 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.
In the case of temporary transfers, LACNIC shall restore this information to its original values (the values prior to the transfer) on the transaction’s end date.
2.3.2.18.8. Both the transferring and the receiving entities 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 three years as of their allocation or assignment date.
2.3.2.18.10. Legacy resources transferred into the LACNIC region will no longer be considered legacy resources.
2.3.2.18.11. Temporary transfers must meet additional conditions. Failure to adhere to these conditions will serve as immediate grounds for the revocation of the transfer:
• The agreement must include clauses for revoking the transfer in case of misuse or abuse of the resources.
• Having an ASN to announce these resources.
• Having operational IPv6 at the time of announcing the transferred IPv4 resources.
• Having RPKI for these resources.
• Updating geolocation and IRR data.
Complying with the best practices established by MANRS.
As far as we know, only the RIPE NCC allows temporary transfers. At the same time, the RIPE NCC does not consider leasing, but does not explicitly prohibit the practice.
APNIC and AFRINIC do not consider leasing or temporary transfers.
ARIN does not consider temporary transfers, and leasing is not a valid justification of need. Once addresses are leased, no additional addresses may be requested. Additionally, certain blocks cannot be leased.
Timetable-
References-
Presented at:-
LACNIC's current policies consider only permanent IPv4 address transfers.
This proposal specifies a policy change to allow temporary transfers.
Rationale (Describe the problem you intend to solve)Mixed feelings exist among the community when we discuss the need to allow the leasing of addresses (broadly understood as any of its possible modalities) as a mechanism for transitioning to IPv6 or to allow new entrants. However, we are forgetting that a community-accepted mechanism already exists. This mechanism could be slightly modified to be equivalent to leasing, but have multiple advantages for both parties: temporary transfers.
The goal is to guarantee compliance with the policies through a system equivalent to leasing, which allows avoiding security issues, control by the RIR/NIR, and the guarantee that the addresses will be returned at the conclusion of the lease period.
At the same time, the proposal seeks to address the need for flexibility without excessive operational burden for the RIR/NIR, so that the lease period can simply be extended, in the understanding that there may be situations where the initially agreed-upon term is not sufficient to cover the initial need.
It is important to stress that those who need these transfers by way of a “lease” tend to be smaller entities or entities with more moderate initial investments and, consequently, financially weaker. Therefore, given that the ultimate goal must be IPv6 deployment, using IPv6-only and IPv4aaS, the number of necessary IPv4 addresses will actually decrease.
Finally, the proposal seeks to prioritize regional benefit, which is why it makes sense that it should apply only to transactions within the region. Furthermore, it prevents permanent transfers from losing reciprocity with those regions that require it.
The Board might establish specific rates for this type of transfer and/or for their extension.
Current text2.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.
This policy applies both to transfers where one of the organizations involved is part of another region (inter-RIR transfers) as well as to 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 entities 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 three years as of their allocation or assignment date.
2.3.2.18.10. Legacy resources transferred into the LACNIC region will no longer be considered legacy resources.
New text2.3.2.18. Temporary and Permanent IPv4 Address Transfers
Both temporary and permanent IPv4 address transfers will be allowed between LIRs and/or end users (hereinafter “entities”), as provided for below.
This policy applies to transfers where one of the entities involved is part of another region (inter-RIR transfers) as well as to transfers within the LACNIC region (intra-RIR transfers). However, temporary transfers will only be allowed within the region (temporary 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 entity within the LACNIC region to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 resources before LACNIC. In other words, the entity must justify before LACNIC the initial/additional allocation/assignment, as applicable, according to the policies in force.
However, in the case of temporary transfers, a specific recipient may only receive (in total) a maximum of a /20.
If the receiving entity is in 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 ensure that the resources are free from any disputes.
In the case of intra-RIR transfers, both entities 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 transaction will be agreed between both RIRs.
2.3.2.18.4. LACNIC shall maintain a publicly accessible transfer log of all permanent IPv4 address block transfers. This log will be used to record the date on which the transaction took place, the entity that originated the transfer, the receiving entity, the transferred addresses, and, in the case of inter-RIR transfers, the source and destination RIRs.
LACNIC will maintain another publicly accessible log equivalent to the one described above for temporary transfers, where the start and end dates of the transfers will also be recorded.
The end date of a temporary transfer is the date on which the transfer finalizes. This date shall be updated in the event of an agreement to extend the initially agreed-upon term, a decision that must be formally endorsed by both parties and verified by LACNIC.
2.3.2.18.5. The entity 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 recorded in the transfer log.
2.3.2.18.6. In the case of permanent transfers, addresses that have already been transferred may not subsequently be transferred again (in full or in part) for a period of one year as of the transaction date recorded in the transfer log.
2.3.2.18.7. Once the transfer is complete, LACNIC shall modify the information on the transferred resource to reflect the change of holder.
In the case of temporary transfers, LACNIC shall restore this information to its original values (the values prior to the transfer) on the transaction’s end date.
2.3.2.18.8. Both the transferring and the receiving entities will be subject to the policies and membership terms and conditions of the corresponding RIR.
2.3.2.18.9. Addresses received as allocations or assignments from LACNIC, whether initial or additional, may not be transferred (in full or in part) for a period of three years as of their allocation or assignment date.
2.3.2.18.10. Legacy resources transferred into the LACNIC region will no longer be considered legacy resources.
2.3.2.18.11. Temporary transfers are subject to additional conditions that must be guaranteed by the agreement between both parties:
• The agreement must include clauses for revoking the transfer in case of misuse or abuse of the resources.
• The receiving entity must have an ASN to announce the resources.
• The receiving entity must have operational IPv6 at the time of announcing the transferred IPv4 resources.
• The receiving entity must have RPKI for the resources.
• The receiving entity must update the geolocation and IRR information.
• The receiving entity must comply with the best practices established by MANRS.
The entity originating the transfer is responsible for overseeing that these conditions are met. LACNIC may establish operational practices to ensure compliance.
If the originating entity fails to exercise due diligence, even with different temporary transfers or receiving entities, LACNIC may issue a warning. Ignoring such warning may result in the immediate revocation of the resources involved.
Additional informationAs far as we know, only the RIPE NCC allows temporary transfers. At the same time, the RIPE NCC does not consider leasing, but does not explicitly prohibit the practice.
APNIC and AFRINIC do not consider leasing or temporary transfers.
ARIN does not consider temporary transfers, and leasing is not a valid justification of need. Once addresses are leased, no additional addresses may be requested. Additionally, certain blocks cannot be leased.
Timetable-
References-
Presented at:LACNIC 41 (08/05/2024)
LACNIC's current policies consider only permanent IPv4 address transfers.
This proposal specifies a policy change to allow temporary transfers.
Rationale (Describe the problem you intend to solve)The community expresses mixed feelings when discussing the need to allow the lease of addresses (broadly understood as any of its possible modalities) as a mechanism for transitioning to IPv6 or to allow new entrants. However, we are forgetting that a community-accepted mechanism already exists. This mechanism could be slightly modified to be equivalent to leasing but with multiple advantages for both parties: temporary transfers.
The goal is to guarantee compliance with the policies through a system equivalent to leasing, which allows avoiding security issues, control by the RIR/NIR, and the guarantee that the addresses will be returned at the conclusion of the lease period.
At the same time, the proposal seeks to address the need for flexibility without excessive operational burden for the RIR/NIR, so that the lease period can simply be extended, in the understanding that there may be situations where the initially agreed-upon term is not sufficient to cover the initial need.
It is important to stress that those who need these transfers by way of a “lease” tend to be smaller entities or entities with more moderate initial investments and, consequently, financially weaker. Therefore, given that the ultimate goal must be IPv6 deployment, using IPv6-only and IPv4aaS, the number of necessary IPv4 addresses will actually decrease.
Finally, the proposal seeks to prioritize regional benefit, which is why it makes sense that it should apply only to transactions within the region. Furthermore, it prevents permanent transfers from losing reciprocity with those regions that require it.
The Board might establish specific rates for this type of transfer and/or for their extension.
Current text2.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.
This policy applies both to transfers where one of the entities involved is part of another region (inter-RIR transfers) as well as to 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 entity within the LACNIC region to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 resources before LACNIC. In other words, the entity must justify before LACNIC the initial/additional allocation/assignment, as applicable, according to the policies in force.
If the receiving entity is in 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 entities 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 transaction 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 entity that originated the transfer, the receiving entity, the transferred addresses, and, in the case of inter-RIR transfers, the source and destination RIRs.
2.3.2.18.5. The entity 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 recorded 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 to reflect the change of holder.
2.3.2.18.8. Both the transferring and the receiving entities will be subject to the policies and membership terms and conditions of the corresponding RIR.
2.3.2.18.9. Addresses received as allocations or assignments from LACNIC, whether initial or additional, may not be transferred (in full or in part) for a period of three years as of their allocation or assignment date.
2.3.2.18.10. Legacy resources transferred into the LACNIC region will no longer be considered legacy resources.
New text2.3.2.18. Temporary and Permanent IPv4 Address Transfers
Both temporary and permanent IPv4 address transfers will be allowed between LIRs and/or end users (hereinafter “entities”), as provided for below.
This policy applies to transfers where one of the entities involved is part of another region (inter-RIR transfers) as well as to transfers within the LACNIC region (intra-RIR transfers). Temporary transfers will only be allowed within the region (temporary 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 entity within the LACNIC region to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 resources before LACNIC. In other words, the entity must justify before LACNIC the initial/additional allocation/assignment, as applicable, according to the policies in force.
In the case of temporary transfers, a specific recipient may only receive (in total) a maximum of a /20.
If the receiving entity is in 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 ensure that the resources are free from any disputes.
In the case of intra-RIR transfers, both entities 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 transaction will be agreed between both RIRs.
2.3.2.18.4. LACNIC shall maintain a publicly accessible log of permanent IPv4 address block transfers. This log will be used to record the date on which the transaction took place, the entity that originated the transfer, the receiving entity, the transferred addresses, and, in the case of inter-RIR transfers, the source and destination RIRs.
LACNIC shall maintain a publicly accessible log of temporary transfers, recording the same information as for permanent transfers, with the addition of the start and end dates of each transfer.
The end date of a temporary transfer shall be updated if the parties agree to extend its initial duration, a decision that must be formally endorsed by both parties and verified by LACNIC.
2.3.2.18.5. The entity 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 recorded in the transfer log.
2.3.2.18.6. In the case of permanent transfers, addresses that have already been transferred may not subsequently be transferred again (in full or in part) for a period of one year as of the transaction date recorded in the transfer log.
2.3.2.18.7. Once the transfer is complete, LACNIC shall modify the information for the transferred resource to reflect the change of holder.
In the case of temporary transfers, LACNIC shall restore this information to its original values (the values prior to the transfer) on the transaction’s end date.
2.3.2.18.8. Both the transferring and the receiving entities will be subject to the policies and membership terms and conditions of the corresponding RIR.
2.3.2.18.9. Addresses received as allocations or assignments from LACNIC, whether initial or additional, may not be transferred (in full or in part) for a period of three years as of their allocation or assignment date.
2.3.2.18.10. Legacy resources transferred into the LACNIC region will no longer be considered legacy resources.
2.3.2.18.11. Temporary transfers are subject to additional conditions that must be guaranteed by the agreement between both parties:
• The agreement must include clauses for revoking the transfer in case of misuse or abuse of the resources.
• The receiving entity must have an ASN to announce the resources.
• The receiving entity must have operational IPv6 or an IPv6 deployment plan.
• The receiving entity must have RPKI for the resources.
• The receiving entity must update the geolocation and IRR information.
• The receiving organization must comply with the best practices established by MANRS.
The entity originating the transfer is responsible for overseeing that these conditions are met. LACNIC may establish operational practices to ensure compliance.
The receiving entity is not a valid source for subsequent transfers.
Additional informationAs far as we know, only the RIPE NCC allows temporary transfers. The RIPE NCC does not consider leasing but does not explicitly prohibit the practice.
APNIC and AFRINIC do not consider leasing or temporary transfers.
ARIN does not consider temporary transfers, and leasing is not a valid justification of need. Once addresses are leased, no additional addresses may be requested. Additionally, certain blocks cannot be leased.
Timetable-
References-
Presented at:LACNIC 42 (09/10/2024)
LACNIC's current policies consider only permanent IPv4 address transfers.
This proposal specifies a policy change to allow temporary transfers.
The community expresses mixed feelings when discussing the need to allow the lease of addresses (broadly understood as any of its possible modalities) as a mechanism for transitioning to IPv6 or to allow new entrants. However, we forget that a community-accepted mechanism already exists. This mechanism could be slightly modified to be equivalent to leasing but with multiple advantages for both parties: temporary transfers.
The goal is to guarantee compliance with the policies through a system equivalent to leasing, which would avoid security issues, control by the RIR/NIR, and guarantee that the addresses will be returned at the conclusion of the lease period.
At the same time, the proposal seeks to address the need for flexibility without excessive operational burden for the RIR/NIR, so that the lease period can simply be extended, in the understanding that there may be situations where the initially agreed-upon term is not sufficient to cover the initial need.
It is important to stress that those who need these transfers by way of a “lease” tend to be smaller entities or entities with more moderate initial investments and, consequently, financially weaker. Therefore, given that the ultimate goal must be IPv6 deployment, using IPv6-only and IPv4aaS, the number of necessary IPv4 addresses will actually decrease.
Finally, the proposal seeks to prioritize regional benefit, which is why it makes sense that it should apply only to transactions within the region. Furthermore, it prevents permanent transfers from losing reciprocity with those regions that require it.
The Board might establish specific rates for this type of transfer and/or for their extension.
Current text2.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.
This policy applies both to transfers where one of the entities involved is part of another region (inter-RIR transfers) as well as to 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 entity within the LACNIC region to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 resources before LACNIC. In other words, the entity must justify before LACNIC the initial/additional allocation/assignment, as applicable, according to the policies in force.
If the receiving entity is in 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 ensure that the resources are free from any dispute.
In the case of intra-RIR transfers, both entities 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 transaction will be agreed between both 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 entity that originated the transfer, the receiving entity, the transferred addresses, and, in the case of inter-RIR transfers, the source and destination RIRs.
2.3.2.18.5. The entity 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 recorded 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 to reflect the change of holder.
2.3.2.18.8. Both the transferring and the receiving entities will be subject to the policies and membership terms and conditions of the corresponding RIR.
2.3.2.18.9. Addresses received as allocations or assignments from LACNIC, whether initial or additional, may not be transferred (in full or in part) for a period of three years as of their allocation or assignment date.
2.3.2.18.10. Legacy resources transferred into the LACNIC region will no longer be considered legacy resources.
New text2.3.2.18. Temporary and Permanent IPv4 Address Transfers
Both temporary and permanent IPv4 address transfers will be allowed between LIRs and/or end users (hereinafter “entities”), as provided for below.
This policy applies to transfers where one of the entities involved is part of another region (inter-RIR transfers) as well as to transfers within the LACNIC region (intra-RIR transfers). Temporary transfers will only be allowed within the region (temporary 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 entity within the LACNIC region to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 resources before LACNIC. In other words, the entity must justify before LACNIC the initial/additional allocation/assignment, as applicable, according to the policies in force.
In the case of temporary transfers, a specific recipient may only receive (in total) a maximum of a /20.
If the receiving entity is in 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 ensure that the resources are free from any dispute.
In the case of intra-RIR transfers, both entities 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 transaction will be agreed between both RIRs.
2.3.2.18.4. LACNIC shall maintain a publicly accessible log of permanent IPv4 address block transfers. This log will be used to record the date on which the transaction took place, the entity that originated the transfer, the receiving entity, the transferred addresses, and, in the case of inter-RIR transfers, the source and destination RIRs.
LACNIC shall maintain a publicly accessible log of temporary transfers, recording the same information as for permanent transfers, with the addition of the start and end dates of each transfer.
The end date of a temporary transfer shall be updated if the parties agree to extend its initial duration, a decision that must be formally endorsed by both parties and verified by LACNIC.
2.3.2.18.5. The entity 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 recorded in the transfer log.
2.3.2.18.6. In the case of permanent transfers, addresses that have already been transferred may not subsequently be transferred again (in full or in part) for a period of one year as of the transaction date recorded in the transfer log.
2.3.2.18.7. Once the transfer is complete, LACNIC shall modify the information for the transferred resource to reflect the change of holder.
In the case of temporary transfers, LACNIC shall restore this information to its original values (the values prior to the transfer) on the transaction’s end date.
2.3.2.18.8. Both the transferring and the receiving entities will be subject to the policies and membership terms and conditions of the corresponding RIR.
2.3.2.18.9. Addresses received as allocations or assignments from LACNIC, whether initial or additional, may not be transferred (in full or in part) for a period of three years as of their allocation or assignment date.
2.3.2.18.10. Legacy resources transferred into the LACNIC region will no longer be considered legacy resources.
2.3.2.18.11. Temporary transfers must include revocation clauses to address the abuse of resources or other policy violations, protecting the original holder from any repercussions.
It is advisable to establish requirements for the receiving entity, such as:
• Having an ASN to announce the resources,
• Having IPv6 or an IPv6 deployment plan,
• Having RPKI for the resources,
• Updating the geolocation and IRR information, and
• Adhering to the best practices established by MANRS.
The receiving entity may not originate subsequent transfers.
Additional informationFrom an operational point of view, temporary transfers may be treated as sub-assignments and therefore ‘enjoy’ all their inherent properties. However, it should be possible to clearly distinguish ‘regular’ sub-assignments and ‘temporary transfers,’ as in some cases, a sub-assignment that is not a temporary transfer may not be permitted under the definition of assignment/sub-assignment.
To the best of our knowledge, only the RIPE NCC allows temporary transfers. The RIPE NCC does not consider leasing but does not explicitly prohibit the practice.
APNIC and AFRINIC do not consider leasing or temporary transfers.
ARIN does not consider temporary transfers, and leasing is not a valid justification of need. Once addresses are leased, no additional addresses may be requested. Additionally, certain blocks cannot be leased.
Timetable-
References-
Presented at:LACNIC 43 (07/05/2025)
Las políticas actuales de LACNIC solo contemplan transferencias de direcciones IPv4 de forma permanente.
Esta propuesta especifica un cambio en dicha política para permitir transferencias temporales.
Rationale (Describe the problem you intend to solve)Cuando en la comunidad discutimos la necesidad del alquiler, entendido de forma amplia en cualquiera de sus posibles modalidades, como uno de los mecanismos para realizar la transición a IPv6, o la implantación de nuevos actores, hay sentimientos encontrados acerca de aceptar o no el alquiler. Sin embargo, estamos olvidando que ya existe un mecanismo, ya aceptado por la comunidad, que podría modificarse ligeramente para ser equivalente a un alquiler, y sin embargo tener muchas ventajas para ambas partes: las transferencias temporales.
Se trata de garantizar el cumplimiento de las políticas con un sistema equivalente al alquiler, y que facilite evitar problemas de seguridad, el control por parte del RIR/NIR, y la seguridad de la devolución de direcciones cuando el período de alquiler termina.
Al mismo tiempo se busca cubrir la necesidad de ser flexibles sin excesiva carga operacional para el RIR/NIR, de forma que el período de alquiler pueda ser extendido sencillamente, pues se sobreentiende que puede haber situaciones en las que el pactado inicialmente no sea suficiente para cubrir la necesidad inicial.
Es importante recalcar que aquellos que necesitan estas transferencias, a modo de “alquiler”, suelen ser entidades más pequeñas o con inversiones iniciales más moderadas y consecuentemente son financieramente más débiles. Por lo tanto, dado que el objetivo final ha de ser el despliegue de IPv6, utilizando IPv6-only e IPv4aaS, el número de direcciones IPv4 que puedan necesitar será realmente reducido.
Finalmente, se busca primar el beneficio de la región y por ello tiene sentido que sólo sea aplicable a las operaciones realizadas en la región. Además, así se evita que las transferencias permanentes pierdan reciprocidad con aquellas regiones que la exigen.
El Directorio podría establecer tarifas específicas para este tipo de transferencias y/o sus extensiones.
Current text(no existe, formato similar al de transferencias permanentes)
New text2.3.2.19. Transferencias temporales de direcciones IPv4
Se permitirán transferencias temporales de direcciones IPv4 (operativamente tratadas como subasignaciones y sin requerir conectividad en la misma infraestructura), entre LIRs y/o usuarios finales (permitiendo explícitamente las subasignaciones), en adelante entidades, exclusivamente dentro de la región de LACNIC (intra-RIR), bajo las siguientes condiciones.
2.3.2.19.1. El tamaño mínimo de bloque que se permite transferir es un /24.
2.3.2.19.2. Para que una entidad dentro de LACNIC, pueda ser el destinatario de una transferencia, debe pasar primero por un proceso simplificado de justificación de recursos IPv4 ante LACNIC. Este proceso tiene como objetivo demostrar que el destinatario efectivamente no dispone de direcciones suficientes para cumplir con su necesidad (por ejemplo, nuevo servicio o entidad, crecimiento de usuarios y/o infraestructura, transición a IPv6, necesidades temporales, etc.). Dada la gran casuística que podría darse, y con el fin de no ser una limitante, LACNIC podrá detallar, si fuera preciso, la operativa concreta.
2.3.2.19.3. LACNIC verificará la titularidad del recurso a transferir y que esté libre de disputas.
Ambas entidades deberán presentar a LACNIC una copia firmada del documento legal que respalde la transferencia.
2.3.2.19.4. LACNIC mantendrá una bitácora de transferencias temporales, accesible públicamente, de tal forma que permita la trazabilidad de todos los eventos.
2.3.2.19.5. La entidad fuente de la transferencia quedará automáticamente inelegible para recibir distribuciones y/o asignaciones de recursos IPv4 por parte de LACNIC durante un año, a partir de la fecha de operación registrada en la bitácora de transferencias.
2.3.2.19.6. Cada entidad, tanto la que transfiere como la que recibe, quedará sujeta a las políticas y condiciones de membresía, y por ende, deben haber firmado el acuerdo de servicios.
2.3.2.19.7. Las direcciones provenientes de distribuciones o asignaciones de LACNIC, ya sean iniciales o adicionales, no podrán ser sujetos a transferencias (ni totales ni parciales) durante un periodo de tres años a partir de su fecha de distribución o asignación.
2.3.2.19.8. El destinatario de una transferencia temporal no puede realizar transferencias subsiguientes.
Additional informationLas transferencias temporales serán operativamente tratadas como subasignaciones y por tanto “disfrutar” de todas las propiedades que les son inherentes. Sin embargo, hay que tener en cuenta que, de forma clara, ha de ser posible diferenciar subasignaciones “regulares” de “transferencias temporales”, ya que en algunos casos una subasignación que no sea una transferencia temporal no es posible según la definición de asignación/subasignación. Por ello se realiza una excepción explícita con esta propuesta sólo válida para las transferencias temporales.
Hasta donde sabemos, solo en RIPE NCC están permitidas las transferencias temporales. Al mismo tiempo RIPE NCC no contempla el alquiler, pero tampoco lo prohíbe explícitamente.
En APNIC y AFRINIC, no se contempla ni el alquiler ni las transferencias temporales.
En ARIN no se contemplan las transferencias temporales, y el alquiler no es una justificación válida de la necesidad. Cuando se alquilan direcciones, no se pueden solicitar más. Además, determinados bloques no pueden ser alquilados.
Timetable-
References-
Presented at:-