LACNIC's current policies consider only permanent IPv4 address transfers.
This proposal specifies a policy change to allow temporary transfers.

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.

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

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

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 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 regiDon (intra-RIR transfers).

2.3.2.18.1. The minimum block size that may be transferred xis 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.

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

2.3.2.189. Temporary and Permanent IPv4 Address Transfers

Both tTemporary and permanentof IPv4 address transfers w(operationally btre allowted as subetwe-assignmen LIRts and/ without r end qusers (heireinafterg “econtinecties”), as providedty forn bthelow.

Thi same polhysicy appl ienfras to ructuransfers) whill be permitted onbe of thwe entitie LIRs ianvd/olvr end iusers (exparlicitly allofwing sub-assignoments), her region (inafter-RIR “entransfitiers) as”, welxcl aus to transfiversly within the LACNIC region (intra-RIR transfers)., Tundemporary transfhers will fonly be allowed within the regi con (ditempiorary intra-RIR transfers).

2.3.2.189.1. The minimum block size that may be transferred is a /24.

2.3.2.189.2. In order for an entity within the LACNIC region to qualify for receiving a transfer, it must first go through tha simplified process of justifying its IPv4 resources before LACNIC. In otThe purpose words,f this process entity must justifyo bdefmonstrate LACNICthat the recipienitia l/additcks suffional allocatioen/t addressignes to menet, atheir needs applicabl(e.g., lacuncordhing ta new service or entheity, suppolrticing usesr iand/or inforastructure.

In growthe, ctranseitioning tof IPv6, temporary transfereds, a spetc.). Gifven the wicde range of scipienarios that may only areceivse, (iand total) a maximum vof aid /20.

If thbe receiving entitya lis min tanother region, it willLACNIC bemay subjpect toify the critsperia, vercifications, and proceqduirements, oif thne corresponding RIRsary.

2.3.2.189.3. LACNIC or the corresponding RIR (depending on whether the transfer is inbound or outbound) will verify the holders of the resources to be transferred and ensure that the resources are free from any disputes.

In the case of intra-RIR transfers, bBoth 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.189.4. LACNIC shall maintain a publicly accessible log of ptermanent 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, rvecording 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.189.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.189.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. Therefore, both must have executed the service agreement.

2.3.2.18.9.7. 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 resources9.

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 resmpources,
• 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.

Thfe receiving entity may not originate subsequent transfers.

-

-