Currently, the LACNIC Policy Manual (section 0.9) prohibits the sub-assignment of IPv4 addresses to third parties outside the original recipient's own infrastructure.
In the context of IPv4 exhaustion, this restriction has led to informal practices of address “leasing” with no record of the transaction, resulting in various issues, including the potential leak of resource to other RIRs through transfers.
While small ISPs are the most affected, they are not the only ones impacted by the current situation.
This proposal creates a transparent mechanism with clearly defined responsibilities for the sub-assignment of IPv4 addresses. This alternative complies with our policies and provides a regulated framework for currently unregulated practices.
The original draft was shared on the mailing list in August 2025 and has been revised: to a greater or lesser extent, most of the community's comments have been incorporated into the proposal.
A modification of section 0.9 is proposed, as well as the addition of a new section addressing this type of sub-assignment.
Rationale (Describe the problem you intend to solve)While the authors do not endorse address leasing, we believe it is essential to address this issue, as it has become a reality with unintended consequences such as outdated registries and addresses leaking to other RIRs.
We are aware that we cannot cover every potential scenario, so we are proposing a mechanism that provides an incentive for regularization among those who wish to comply with the policies, even though we know that not everyone will adopt it. Nonetheless, this scenario is preferable to the current state of affairs.
Furthermore, the proposed change seeks to facilitate access to IPv4 resources for small ISPs in the region, under conditions that we hope will be more affordable.
Adopting this policy will bring tangible benefits to the community:
• Transparency, through registration in the WHOIS.
• Traceability, through a public log of movements.
• Security, by providing a formal framework in our policies.
• Preventing speculation, by restricting the sub-assignment of newly transferred or recovered blocks for an initial period of three (3) years.
0.9 Assign
To assign means to delegate address space to an end user, to be exclusively used within the infrastructure operated by said end user, as well as for interconnection purposes.
The assigned address space must only be used by the original recipient of the assignment, as well as for third-party devices provided they are operating within said infrastructure.
Therefore, sub-assignments to third parties outside said infrastructure (for example, the use of end-user assignments for ISPs or similar clients) and providing addresses to third parties in data centers (and others) are not allowed.
New textModification to section 0.9 (existing)
0.9 Assign
To assign means to delegate address space to an end user, to be exclusively used within the infrastructure operated by said end user, as well as for interconnection purposes.
The assigned address space must only be used by the original recipient of the assignment, as well as for third-party devices provided they are operating within said infrastructure.
Sub-assignment to third parties outside the original recipient's own infrastructure is not permitted, except in the cases provided for in section 2.3.2.19.
New Text (New Section)
2.3.2.19. Sub-Assignment of IPv4 Resources to Third Parties
2.3.2.19.1. Scope
This policy applies exclusively to the sub-assignment of IPv4 resources.
2.3.2.19.2. Terms and Conditions
a. The receiving organization must have at least one ASN and IPv6 addresses assigned by LACNIC.
b. The minimum block size is a /24, and the maximum is a /21.
c. The receiving organization must demonstrate current utilization or immediate need of at least 25% of the sub-assigned block and present a detailed plan to reach 50% utilization within one year. LACNIC may request additional information if deemed necessary to validate the justification.
2.3.2.19.3. Transparency and Traceability
a. Identification in the WHOIS: Each sub-assignment must be recorded in the LACNIC WHOIS database, linking the address block to the recipient's ASN.
b. Public Movement Log: A public log will be created and maintained to provide traceability to the start and end events of each sub-assignment, identifying the address block, the recipient's ASN, the date, and the type of event (start or end of a sub-assignment).
2.3.2.19.4. Responsibility for the Resources
Final responsibility for the use of IP addresses will always rest with the LACNIC member organization that makes the sub-assignment. In the event of misuse by the recipient, the member organization shall terminate the sub-assignment; failure to do so may result in the revocation of resources by LACNIC in accordance with the policies in force.
2.3.2.19.5. Anti-Speculation Mechanism
IPv4 blocks received through transfer (section 2.3.2.18) or from the LACNIC pool of recovered resources may not be sub-assigned under this modality for a period of three (3) years from their receipt.
The initial draft for this proposal was shared on the mailing list in early August. There, we received several comments, which we took into consideration.
Some suggestions were incorporated directly, others were submitted in a new proposal, while still others were not included because they were not considered appropriate. Nevertheless, each contribution was analyzed, and we appreciate the community's input.
- The restriction was reduced from 5 years to 3 years.
- A /21 was added as the maximum size for this type of sub-allocation.
- A requirement was added that the recipient must have received an IPv6 assignment to be eligible for this type of sub-assignment.
- No references to legacy resources were included in the text.
- The justification mechanism was modified to align with a mechanism already included in the Manual.
-
References-
Presented at:LACNIC 44 (08/10/2025)
El Manual de Políticas de LACNIC (sección 0.9) prohíbe actualmente la subasignación de direcciones IPv4 a terceros fuera de la infraestructura propia del receptor.
En el contexto de agotamiento de IPv4, esta restricción ha derivado en prácticas incorrectas y no aceptables de “alquiler” de direcciones sin dejar registro de la operación, con los consecuentes inconvenientes que esto acarrea, incluyendo la posibilidad de fuga de recursos hacia otros RIRs a través de transferencias.
Los pequeños ISPs son, aunque no exclusivamente, los principales perjudicados bajo el esquema actual.
Esta propuesta crea un mecanismo transparente para realizar subasignaciones de direcciones IPv4 a terceros fuera de la infraestructura propia para los titulares de recursos en la región, que mantengan una relación contractual vigente con LACNIC o su NIR, ofreciendo una alternativa regulada y trazable.
La propuesta busca además apelar a definiciones y mecanismo ya preexistentes en el manual con el objetivo de mantener consistencia con las definiciones previamente aceptadas por la comunidad.
Si bien los autores no estamos a favor del alquiler de direcciones, consideramos imprescindible abordar este tema dado que constituye una realidad con efectos no deseados, como la desactualización del registro y la fuga de direcciones hacia otros RIRs.
Somos conscientes de que no podemos abarcar todos los posibles escenarios, por lo que proponemos un mecanismo que permita la regularización de quienes deseen cumplir con las políticas.
Adicionalmente, el esquema busca, sin por ello excluir a otros, facilitar el acceso de los pequeños ISPs a recursos IPv4 dentro de la región, en condiciones que esperamos sean más asequibles.
La adopción de esta política aportará beneficios concretos a la comunidad:
- Transparencia, mediante el registro en WHOIS.
- Trazabilidad, a través de una bitácora pública de movimientos.
- Seguridad, ofreciendo un marco formal que evite acuerdos opacos.
- Prevención de la especulación, al establecer restricciones detalladas en el punto 2.3.2.19.5
0.9.Asignar
Asignar significa delegar espacio de direcciones a un usuario final, para su uso exclusivamente dentro de la infraestructura que opera, así como para fines de interconexión.
La asignación de espacio de direcciones es sólo para el uso por el receptor original de dicha asignación, así como para dispositivos de terceros, siempre y cuando estén operando dentro de dicha infraestructura.
No está permitida, por tanto, la subasignación a terceros, fuera de dicha infraestructura (por ejemplo, el uso de asignaciones de usuario final para clientes de un ISP o similares), ni proporcionar direccionamiento a terceros en data-centers (y similares).
Modificación de punto 0.9 (existente)
0.9.Asignar
Asignar significa delegar espacio de direcciones a un usuario final, para su uso exclusivamente dentro de la infraestructura que opera, así como para fines de interconexión.
La asignación de espacio de direcciones es sólo para el uso por el receptor original de dicha asignación, así como para dispositivos de terceros, siempre y cuando estén operando dentro de dicha infraestructura.
No está permitida la subasignación a terceros fuera de la infraestructura propia del receptor original (por ejemplo, el uso de asignaciones de usuario final para clientes de un ISP o similares), ni proporcionar direccionamiento a terceros en data-centers (y similares), excepto en los casos previstos en la sección 2.3.2.19
Texto Nuevo (Nueva sección)
2.3.2.19 – Sub-asignación de Recursos IPv4 a Terceros
2.3.2.19.1. Ámbito de Aplicación
a. Las subasisgnaciones bajo el apartado 2.3.2.19 aplican exclusivamente a subasignaciones de recursos IPv4.
b. Quedan excluidos de este tipo de subasignaciones todos los recursos IPv4 asignados por LACNIC para infraestructura crítica según las políticas vigentes.
2.3.2.19.2. Condiciones y Requisitos
a. Las subasignaciones bajo esta modalidad deberán destinarse exclusivamente al uso dentro de la región de cobertura de LACNIC.
b. La organización receptora deberá contar al menos con un ASN y direccionamiento IPv6 asignado por LACNIC.
c. La organización que realice la subasignación deberá ser titular de recursos en la región de LACNIC y tener contrato de servicio vigente con LACNIC o su NIR correspondiente de la región.
d. El tamaño mínimo será un /24 y el máximo un /22, alineado al mecanismo de distribución inicial a ISPs del punto 2.3.3.1.1 del presente manual.
e. La organización receptora deberá justificar la necesidad del bloque solicitado mediante una descripción de su uso actual y previsto, demostrando la utilización o necesidad inmediata de al menos el 25% del espacio solicitado y la proyección de uso de al menos el 50% del bloque dentro de un plazo razonable que, en ningún caso, podrá exceder de un (1) año, alineado a los mecanismos definidos en el manual bajo el punto 2.3.3.1.1. LACNIC podrá requerir información adicional o establecer revisiones periódicas para verificar el uso efectivo del bloque, conforme a sus procedimientos vigentes.
2.3.2.19.3. Transparencia y Trazabilidad
a. Identificación en WHOIS: Cada sub-asignación deberá registrarse en la base WHOIS de LACNIC, vinculando el bloque de direcciones con el ASN del receptor.
b. Bitácora Pública de Movimientos: Se creará y mantendrá una bitácora pública para dar trazabilidad a los eventos de inicio y fin de cada subasignación. Deberá incluir el bloque subasignado, el ASN del receptor, la fecha del evento y el tipo de evento (inicio/fin). No se incluirán datos sensibles ni información operativa fuera de lo estrictamente necesario para garantizar los objetivos de transparencia y trazabilidad.
2.3.2.19.4. Responsabilidad sobre los Recursos
a. La responsabilidad final sobre el uso de las direcciones IP recaerá siempre en la organización miembro de LACNIC que realiza la sub-asignación. siendo esta responsable de terminar con la subasignación si la parte receptora incumpliera con las obligaciones que este manual define.
b.. De no hacerlo, será susceptible de revocación de recursos por parte de LACNIC, según las políticas vigentes para sus miembros.
2.3.2.19.5. Restricciones asociadas a la subasignación de IPv4 a terceros.
a. Los bloques subasignados bajo esta modalidad no podrán ser subasignados nuevamente bajo esta misma modalidad por el receptor.
b. Los bloques IPv4 obtenidos mediante asignación o distribución directa desde LACNIC o mediante una transferencia no podrán ser objeto de subasignación bajo esta modalidad durante un período de tres (3) años a partir de su recepción.
c. Las organizaciones que subasignen direcciones IPv4 bajo esta modalidad no podrán solicitar nuevos bloques IPv4 ni ser destinatarios de transferencias de bloques IPv4 durante un período de tres (3) años desde la fecha de su última subasignación.
Como es de conocimiento de los integrantes de esta lista, la versión 1 de nuestra propuesta no alcanzó consenso, En virtud de ello, los autores decidimos revisar los comentarios de la lista y del foro público y tratar de incorporar las sugerencias, siempre respetando el espíritu inicial de nuestra propuesta.
Creemos haber encontrado un equilibrio entre ese espíritu original y sus aportes, y es por ello que procedimos a publicar la nueva versión.
El trabajo no fue fácil. Ponernos en los zapatos de los que aportaron ha sido enriquecedor. Esperamos que esta nueva versión sea valorada por aquellos que con sus comentarios aportaron a la misma.
Finalmente, si bien los cambios son varios, todos ellos han resultado en incorporar detalles al texto original y no hemos cambiado ni el espíritu ni la estructura de la propuesta.
A continuación destacamos los cambios principales:
1- Se reescribió la cláusula 0.9 respetando el contenido original del manual.
2- Se excluyeron de esta propuesta en forma explícita los recursos pertenecientes al pool reservado para infraestructura crítica
3- Se incorporó explícitamente que el uso de los recursos considerados en este tipo de subasignación debe ser usado 100% dentro de la región,
4- En condiciones y requisitos hemos incorporado el concepto de titular de recursos y la necesidad explícita de tener contrato de servicio con LACNIC o el NIR.
5- Se cambió el tamaño máximo de /21 a /22 para alinear al punto 2.3.3.1.1 del manual del cual también se desprende el mecanismo de justificación.
7- Se especificó la información requerida para la bitácora.
8- Hemos mejorado los mecanismos anti especulación, los cuales pasamos a llamarlos restricciones que creemos que mejora la redacción.
-
References-
Presented at:-