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 incorrect and unacceptable practices of address “leasing” with no record of the transaction, resulting in various issues, including the potential leak of resources 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 establishes a transparent mechanism that allows resource holders in the region, who maintain a current contractual relationship with LACNIC or with its NIR, to sub-assign IPv4 addresses to third parties outside their own infrastructure, providing a regulated and traceable alternative.

The proposal also seeks to leverage existing definitions and mechanisms in the Manual in order to maintain consistency with definitions previously accepted by the community.

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 leaked to other RIRs.

We are aware that we cannot cover every potential scenario, so we are proposing a mechanism that will allow those who wish to comply with the policies to regularize their situation.

Furthermore, without excluding others, 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 offering a formal framework that prevents opaque agreements.
- Prevention of speculation, by establishing detailed restrictions in section 2.3.2.19.5.

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.

Modification to (existing) Section 0.9

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 operate within said infrastructure.

Sub-assignments to third parties outside the original recipient's infrastructure (for example, the use of end-user assignments for an ISP’s customers or other similar uses) and providing addresses to third parties in data centers (and others) are not allowed, except as provided 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
a. Sub-assignments under section 2.3.2.19 apply exclusively to IPv4 resources.
b. IPv4 resources assigned by LACNIC for critical infrastructure under the policies in force are excluded from this type of sub-assignment.

2.3.2.19.2. Terms and Conditions
a. Sub-assignments under this modality must be used exclusively within the LACNIC service region.
b. The receiving organization must hold at least one ASN and IPv6 address space assigned by LACNIC.
c. The organization making the sub-assignment must hold resources in the LACNIC region and maintain a current service contract with LACNIC or with its corresponding NIR in the region.
d. The minimum size is a /24 and the maximum a /22, in line with the initial distribution mechanism to ISPs defined in Section 2.3.3.1.1 of this Manual.
e. The receiving organization must justify the need for the requested block by describing its current and intended use, demonstrating current utilization or immediate need of at least 25% of the requested space and projecting the use of at least 50% of the block within a reasonable timeframe, which in no case may exceed one (1) year, in accordance with the mechanisms defined in Section 2.3.3.1.1 of the Manual. LACNIC may request additional information or conduct periodic reviews to verify effective utilization of the block, in accordance with its current procedures.

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 for the start and end events of each sub-assignment. This log must include the sub-assigned block, the recipient's ASN, the date of the event, and the type of event (start/end). No sensitive data or operational information will be included beyond what is strictly necessary to ensure transparency and traceability.

2.3.2.19.4. Responsibility for the Resources
a. Final responsibility for the use of IP addresses will always rest with the LACNIC member organization that makes the sub-assignment, who will be responsible for terminating the sub-assignment if the receiving party fails to comply with the obligations defined in this Manual.
b. Failure to do so may result in the revocation of resources by LACNIC, in accordance with the policies in force for its members.

2.3.2.19.5. Restrictions associated with the sub-assignment of IPv4 addresses to third parties
a. Recipients of blocks sub-assigned under this modality may not sub-assign these resources under the same modality.
b. IPv4 blocks obtained directly from LACNIC through assignment or allocation or via transfer may not be sub-assigned under this modality for a period of three (3) years from their receipt.
c. Organizations that sub-assign IPv4 addresses under this modality may not request new IPv4 blocks or receive IPv4 block transfers for a period of three (3) years from the date of their last sub-assignment.

As members of this mailing list know, version 1 of our proposal did not reach consensus. Thus, the authors reviewed the comments received via the mailing list and during the Public Policy Forum and tried to incorporate the suggestions, always respecting the initial spirit of our proposal.

We believe we have found a balance between that original spirit and the contributions of the community, which is why we proceeded to publish the new version.

This was not an easy task. Putting ourselves in the place of those who contributed has been enriching. We hope this new version will be well received by those who contributed their perspectives.

Finally, while this version introduces several changes, these are mainly clarifications and details added to the original text. Neither the spirit nor the structure of the proposal have been altered.

The main changes are highlighted below:
1- Section 0.9 was rewritten respecting the original content of the Manual.
2- Resources belonging to the pool reserved for critical infrastructure were explicitly excluded from the scope of this proposal.
3- It was explicitly stated that the use of resources under this type of sub-assignment must be entirely within the LACNIC region.
4- Under Terms and Conditions, we incorporated the concept of resource holder and the explicit requirement of having a service contract with LACNIC or the corresponding NIR.
5- The maximum block size was changed from a /21 to a /22 to align with Section 2.3.3.1.1 of the Manual, from which the justification mechanism is also derived.
7- The information required for the log was specified.
8- We improved the anti-speculation mechanisms, which we now call restrictions, a change we believe improves the wording.

-

-

-