Temporary Transfers

This mechanism could be slightly modified to be equivalent to leasing, and yet have multiple advantages for both parties: temporary transfers.

This mechanism could be slightly modified to be equivalent to leasing, but have multiple advantages for both parties: temporary transfers.

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.

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 IPv4 addresses that may be needed will be actually reduced.

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 carried out in the region.

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, this prevents permanent transfers from losing reciprocity with those regions that require reciprocity.

Furthermore, it prevents permanent transfers from losing reciprocity with those regions that require it.

The Board could establish specific rates for this type of transfer and/or for their extension.

The Board might establish specific rates for this type of transfer and/or for their extension.

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.

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 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).

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).

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.

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 inter-RIR transfers, the documentation supporting the transaction will be agreed between the two RIRs.

In the case of inter-RIR transfers, the documentation supporting the transaction will be agreed between both RIRs.

LACNIC shall maintain a publicly accessible transfer log of all IPv4 address block transfers registered before LACNIC.

LACNIC shall maintain a publicly accessible transfer log of all permanent IPv4 address block transfers.

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.

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.

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.

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.

This mechanism could be slightly modified to be equivalent to leasing, but have multiple advantages for both parties: temporary transfers.

This mechanism could be slightly modified to be equivalent to leasing but with multiple advantages for both parties: temporary transfers.

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).

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).

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.

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.

That is to say, the organization must justify before LACNIC the initial/additional allocation/assignment, as applicable, according to the policies in force.

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 organization is part of another region, it will be subject to the criteria, verifications, and requirements of the corresponding RIR.

If the receiving entity is in another region, it will be subject to the criteria, verifications, and requirements of the corresponding RIR.

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 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 operation will be agreed between the two RIRs.

In the case of inter-RIR transfers, the documentation supporting the transaction will be agreed between the two RIRs.

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.

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.

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.

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.

Once the transfer is complete, LACNIC shall modify the information on the transferred resource in order to reflect the change of holder.

Once the transfer is complete, LACNIC shall modify the information on the transferred resource to reflect the change of holder.

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.

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.

However, we are forgetting that a community-accepted mechanism already exists.

However, we forget that a community-accepted mechanism already exists.

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.

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.

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.

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 inter-RIR transfers, the documentation supporting the transaction will be agreed between the two RIRs.

In the case of inter-RIR transfers, the documentation supporting the transaction will be agreed between both RIRs.

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.

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.

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.

Temporary transfers must include revocation clauses to address the abuse of resources or other policy violations, protecting the original holder from any repercussions.

• The receiving entity must have an ASN to announce the resources.

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 must have operational IPv6 or an IPv6 deployment plan.

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 must have RPKI for the resources.

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 must update the geolocation and IRR information.

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 organization must comply with the best practices established by MANRS.

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 entity originating the transfer is responsible for overseeing that these conditions are met.

The receiving entity may not originate subsequent transfers.

However, we forget that a community-accepted mechanism already exists.

However, we are forgetting that a community-accepted mechanism already exists.

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.

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.

Current text 2.3.2.18.

Current text (Does not exist, format similar to permanent transfers) New text Analyze diff 2.3.2.19.

Current text 2.3.2.18.

Current text (Does not exist, format similar to permanent transfers) New text Analyze diff 2.3.2.19. Temporary IPv4 Address Transfers Temporary of IPv4 address transfers (operationally treated as sub-assignments and without requiring connectivity on the same physical infrastructure) will be permitted between LIRs and/or end users (explicitly allowing sub-assignments), hereinafter “entities”, exclusively within the LACNIC region (intra-RIR), under the following conditions.

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.

Temporary IPv4 Address Transfers Temporary of IPv4 address transfers (operationally treated as sub-assignments and without requiring connectivity on the same physical infrastructure) will be permitted between LIRs and/or end users (explicitly allowing sub-assignments), hereinafter “entities”, exclusively within the LACNIC region (intra-RIR), under the following conditions.

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).

Temporary IPv4 Address Transfers Temporary of IPv4 address transfers (operationally treated as sub-assignments and without requiring connectivity on the same physical infrastructure) will be permitted between LIRs and/or end users (explicitly allowing sub-assignments), hereinafter “entities”, exclusively within the LACNIC region (intra-RIR), under the following conditions.

2.3.2.18.1.

2.3.2.19.1.

2.3.2.18.2.

2.3.2.19.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 order for an entity within the LACNIC region to qualify for receiving a transfer, it must first go through a simplified 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.

The purpose of this process is to demonstrate that the recipient lacks sufficient addresses to meet their needs (e.g., launching a new service or entity, supporting user and/or infrastructure growth, transitioning to IPv6, temporary needs, etc.).

In other words, the entity must justify before LACNIC the initial/additional allocation/assignment, as applicable, according to the policies in force.

Given the wide range of scenarios that may arise, and to avoid being a limitation, LACNIC may specify the specific procedure, if necessary.

If the receiving entity is in another region, it will be subject to the criteria, verifications, and requirements of the corresponding RIR.

Given the wide range of scenarios that may arise, and to avoid being a limitation, LACNIC may specify the specific procedure, if necessary.