The IPv4 policy on direct assignments from LACNIC to end users mentions sub-delegation (2.3.3.4) and specifically prohib
its sub-delegating to third parties.

The IPv6 policy contains no such explicit prohibition, except in the case of micro-assignments (LACNIC shall not make mi
cro-assignments, 4.5.5).

However, section 1.9 (Definitions) – which applies to all LACNIC policies – explicitly prohibits such assignments, stati
ng that “Assignments... are not to be sub-assigned to other parties”.

This proposal seeks to clarify the text of the IPv6 policy in this regard and better define the concept, particularly co
nsidering new uses of IPv6 (RFC8273).

The IPv4 policy on direct assignments by LACNIC to end users addresses sub-delegations (2.3.3.4) and specifically prohib
its sub-delegating to third parties.

The IPv6 policy contains no such explicit prohibition, except in the case of micro-assignments (LACNIC shall not make mi
cro-assignments, 4.5.5).

However, section 1.9 “Definitions” – which applies to all LACNIC policies – explicitly prohibits such assignments, stati
ng that “Assignments... are not to be sub-assigned to other parties.”

This proposal seeks to clarify the text of the IPv6 policy in this regard and better define the concept, particularly co
nsidering new uses for IPv6 (RFC 8273).

When the policy was drafted, the concept of assignments/sub-assignments did not consider a practice very common in IPv4
which is replicated and even amplified in IPv6: the use of IP addresses for point-to-point links or VPNs.

Likewise, the policy failed to consider the use of IP addresses in hotspots, or the use of IP addresses by guests or emp
loyees in Bring Your Own Device (BYOD) and many other similar cases.

Finally, the IETF has recently approved the use of a unique /64 prefix per interface/host (RFC8273) instead of a unique
address. This, for example, allows users to connect to a hotspot, receive a /64 such that they are “isolated” from other
users (for reasons of security, regulatory requirements, etc.) and they can also use multiple virtual machines on their
devices with a unique address for each one (within the same /64).

When the policy was designed, the concept of assignments/sub-assignments did not consider a practice that is very common
in IPv4 and that is replicated and even amplified in IPv6: the use of IP addresses for point-to-point links or VPNs.

Likewise, the policy failed to consider the use of IP addresses in hotspots, the use of IP addresses by guests or employ
ees (Bring Your Own Device, BYOD) and other similar cases.

Another case occurs when an end user hires another company to provide certain services for which they must deploy their
own devices, including their own servers, network equipment, etc. For example, a security surveillance service might req
uire their clients to provide their own cameras, their own recording systems, and even their own firewalls and/or their
own router for a dedicated VPN, etc. Of course, in many cases, this video surveillance system may require using the end
user's address space.

Finally, the IETF has recently approved the use of a unique /64 prefix per interface/host (RFC8273) instead of a unique
address. This, for example, allows users to connect to a hotspot, receive a /64 such that they are “isolated” from othe
r users (for reasons of security, regulatory requirements, etc.) and they can also use multiple virtual machines on thei
r devices with a unique address for each one (within the same /64).

Current text: No such text exists.

The same paragraph after the final paragraph of 4.5.5. (IPv6 Micro-Assignments).

The fact that a unique address or even a unique /64 prefix is non-permanently provided to third parties, on a link opera
ted by the original receiver of the assignment, shall not be considered a sub-assignment. This includes, for example, gu
ests or employees (devices or servers), hotspots and point-to-point links or VPNs.

The provision of addressing for permanent connectivity or broadband services is still considered a sub-assignment and is
therefore not allowed. Only the addressing of the point-to-point link itself can be permanent and that addressing can't
be used (neither directly or indirectly) for the actual communication.

Current text:

No such text exists.

The same paragraph after the last paragraph of 4.5.5. (IPv6 Micro-Assignments).

Providing address space to third-party devices, including addresses for point-to-point links, and/or providing non-perma
nent address space to third parties for use in a network managed and operated by the original recipient of the assignmen
t will not be considered a sub-assignment.

Providing address space for (semi-) permanent connectivity services, such as broadband services, is still considered a s
ub-assignment.

Current text: No such text exists.

The same paragraph after the final paragraph of 4.5.5. (IPv6 Micro-Assignments).

The fact that a unique address or even a unique /64 prefix is non-permanently provided to third parties, on a link opera
ted by the original receiver of the assignment, shall not be considered a sub-assignment. This includes, for example, gu
ests or employees (devices or servers), hotspots and point-to-point links or VPNs.

The provision of addressing for permanent connectivity or broadband services is still considered a sub-assignment and is
therefore not allowed. Only the addressing of the point-to-point link itself can be permanent and that addressing can't
be used (neither directly or indirectly) for the actual communication.

Current text:

No such text exists.

The same paragraph after the last paragraph of 4.5.5. (IPv6 Micro-Assignments).

Providing address space to third-party devices, including addresses for point-to-point links, and/or providing non-perma
nent address space to third parties for use in a network managed and operated by the original recipient of the assignmen
t will not be considered a sub-assignment.

Providing address space for (semi-) permanent connectivity services, such as broadband services, is still considered a s
ub-assignment.

A similar proposal has been discussed in the RIPE region and is waiting for forum chairs to declare consensus.

RIPE has debated a similar proposal and is waiting for the chairs to declare that consensus has been reached.