Summary

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.

Current text

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 text
Analyze diff

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

Additional information

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.

Timetable

-

References

-

Presented at:

-