The IPv4 policy on direct assignments by LACNIC to end users mentions sub-delegation (2.3.3.4) and specifically prohibits sub-delegating to third parties.
The IPv6 policy contains no such explicit prohibition, except in the case of micro-assignments (LACNIC shall not make micro-assignments, 4.5.5).
However, section 1.9 (Definitions) – which applies to all LACNIC policies – explicitly prohibits such assignments, stating 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 considering new uses of IPv6 (RFC 8273).
Rationale (Describe the problem you intend to solve)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.
In the case of IPv6, instead of unique addresses, the use of unique prefixes (/64) is increasingly common.
Likewise, the policy failed to consider the use of IP addresses in hotspots, or the use of IP addresses by guests or employees 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).
Current textCurrent text: No such text exists.
New text:
New paragraph after existing paragraph 4.5.4. (Direct Assignments to End Sites).
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 (example, RFC8273) is temporarily provided to third parties, on a link operated by the original receiver of the assignment, shall not be considered a sub-assignment. This includes, for example, guests or employees (BYOD, devices or servers), hotspots, and point-to-point links or VPNs. The provision of non-temporary connectivity or broadband services, is still considered a sub-assignment and is therefore not allowed.
New textCurrent text: No such text exists.
New text:
New paragraph after existing paragraph 4.5.4. (Direct Assignments to End Sites).
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 (example, RFC8273) is temporarily provided to third parties, on a link operated by the original receiver of the assignment, shall not be considered a sub-assignment. This includes, for example, guests or employees (BYOD, devices or servers), hotspots, and point-to-point links or VPNs. The provision of non-temporary connectivity or broadband services, is still considered a sub-assignment and is therefore not allowed.
Additional information-
TimetableImmediate implementation
ReferencesA similar proposal has been discussed in the RIPE region and is waiting for forum chairs to declare consensus.
Presented at:-
The IPv4 policy on direct assignments from LACNIC to end users mentions sub-delegation (2.3.3.4) and specifically prohibits sub-delegating to third parties.
The IPv6 policy contains no such explicit prohibition, except in the case of micro-assignments (LACNIC shall not make micro-assignments, 4.5.5).
However, section 1.9 (Definitions) – which applies to all LACNIC policies – explicitly prohibits such assignments, stating 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 considering new uses of IPv6 (RFC8273).
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.
In the case of IPv6, instead of unique addresses, the use of unique prefixes (/64) is increasingly common.
Likewise, the policy failed to consider the use of IP addresses in hotspots, or the use of IP addresses by guests or employees 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).
Current text: No such text exists.
New text:
New paragraph after existing paragraph 4.5.4. (Direct Assignments to End Sites).
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 operated by the original receiver of the assignment, shall not be considered a sub-assignment. This includes, for example, guests 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.
New text:
New paragraph after existing paragraph 4.5.4. (Direct Assignments to End Sites).
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 operated by the original receiver of the assignment, shall not be considered a sub-assignment. This includes, for example, guests 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.
-
TimetableImmediate implementation
ReferencesA similar proposal has been discussed in the RIPE region and is waiting for forum chairs to declare consensus.
Presented at:LACNIC 29 (30/04/2018)
The IPv4 policy on direct assignments by LACNIC to end users addresses sub-delegations (2.3.3.4) and specifically prohibits sub-delegating to third parties.
The IPv6 policy contains no such explicit prohibition, except in the case of micro-assignments (LACNIC shall not make micro-assignments, 4.5.5).
However, section 1.9 “Definitions” – which applies to all LACNIC policies – explicitly prohibits such assignments, stating 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 considering new uses for IPv6 (RFC 8273).
Rationale (Describe the problem you intend to solve)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.
In the case of IPv6, instead of unique addresses, the use of unique prefixes (/64) is increasingly common.
Likewise, the policy failed to consider the use of IP addresses in hotspots, the use of IP addresses by guests or employees (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 require 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 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).
Current textCurrent text:
No such text exists.
New text:
New paragraph after existing paragraph 4.5.4. (Direct Assignments to End Sites).
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-permanent address space to third parties for use in a network managed and operated by the original recipient of the assignment will not be considered a sub-assignment.
Providing address space for (semi-) permanent connectivity services, such as broadband services, is still considered a sub-assignment.
New textCurrent text:
No such text exists.
New text:
New paragraph after existing paragraph 4.5.4. (Direct Assignments to End Sites).
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-permanent address space to third parties for use in a network managed and operated by the original recipient of the assignment will not be considered a sub-assignment.
Providing address space for (semi-) permanent connectivity services, such as broadband services, is still considered a sub-assignment.
Additional information-
TimetableImmediate implementation
ReferencesRIPE has debated a similar proposal and is waiting for the chairs to declare that consensus has been reached.
Presented at:LACNIC 30 (24/09/2018)
The IPv4 policy on direct assignments by LACNIC to end users addresses sub-delegations (2.3.3.4) and specifically prohibits sub-delegating to third parties.
The IPv6 policy contains no such explicit prohibition, except in the case of micro-assignments (LACNIC shall not make micro-assignments, 4.5.5).
However, section 1.9 “Definitions” – which applies to all LACNIC policies – explicitly prohibits such assignments, stating 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 considering new uses for IPv6 (RFC 8273).
Finally, the proposal seeks to harmonize the spelling of certain terms formed with the prefixes “micro", “macro", “sub” and others, specifically in the Spanish version of the Manual.
Rationale (Describe the problem you intend to solve)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.
In the case of IPv4, the use of NAT is widespread, so there are no implications. However, institutions not using NAT have the same problem as in IPv6.
In the case of IPv6, instead of unique addresses, the use of unique prefixes (/64) is increasingly common.
Likewise, the policy failed to consider the use of IP addresses in hotspots, the use of IP addresses by guests or employees (Bring Your Own Device, BYOD) and other similar cases.
Another example is the case of an end user who 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 require 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 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).
In the Spanish version of the manual, words beginning with the prefixes “micro”, “macro”, “sub” and others are sometimes spelled with a hyphen and others without. The idea is to try to harmonize the spelling of these words.
Current textCurrent text:
1.9 Assignments
To assign means to delegate address space to an end user, to be specifically used within the Internet infrastructure said end user operates. Assignments must only be made for specific purposes documented by specific organizations, and are not to be sub-assigned to other parties.
New text:
1.9 Assignments
To assign means to delegate address space to an end user, to be specifically used within the Internet infrastructure said end user operates.
Point-to-point links, VPNs and the like are considered part of said infrastructure and, therefore, the assignment of addresses to both endpoints of said link is allowed.
The assigned address space must only be used by the original recipient of the assignment, as well as for third-party devices, as long as they are operating within the infrastructure of said original recipient.
Sub-assigning address space to other parties, for example, for broadband services, to be used in place of LIR/ISP space is a sub-assignment and is therefore not allowed.
To avoid duplications and confusion, the last sentence of the first paragraph of section 2.3.3.4 is deleted. Assignments to End Users:
“...but not for sub-delegation outside their organization.”
To avoid duplications and confusion, the last paragraph of section 4.5.5 is deleted. IPv6 Micro-Assignments:
“Organizations receiving micro-assignments shall not sub-assign these IP addresses.”
Likewise, LACNIC staff will harmonize the spelling of words beginning with the prefixes “micro”, “sub” or others throughout the Spanish version of the manual.
New textCurrent text:
1.9 Assignments
To assign means to delegate address space to an end user, to be specifically used within the Internet infrastructure said end user operates. Assignments must only be made for specific purposes documented by specific organizations, and are not to be sub-assigned to other parties.
New text:
1.9 Assignments
To assign means to delegate address space to an end user, to be specifically used within the Internet infrastructure said end user operates.
Point-to-point links, VPNs and the like are considered part of said infrastructure and, therefore, the assignment of addresses to both endpoints of said link is allowed.
The assigned address space must only be used by the original recipient of the assignment, as well as for third-party devices, as long as they are operating within the infrastructure of said original recipient.
Sub-assigning address space to other parties, for example, for broadband services, to be used in place of LIR/ISP space is a sub-assignment and is therefore not allowed.
To avoid duplications and confusion, the last sentence of the first paragraph of section 2.3.3.4 is deleted. Assignments to End Users:
“...but not for sub-delegation outside their organization.”
To avoid duplications and confusion, the last paragraph of section 4.5.5 is deleted. IPv6 Micro-Assignments:
“Organizations receiving micro-assignments shall not sub-assign these IP addresses.”
Likewise, LACNIC staff will harmonize the spelling of words beginning with the prefixes “micro”, “sub” or others throughout the Spanish version of the manual.
Additional information-
TimetableImmediate implementation
ReferencesA similar proposal was discussed in the RIPE region and the change was approved, although there is no consensus regarding the changes specified in this proposal, as they are different.
Presented at:-
The IPv4 policy on direct assignments by LACNIC to end users addresses sub-delegations (2.3.3.4) and specifically prohibits sub-delegating to third parties.
The IPv6 policy contains no such explicit prohibition, except in the case of micro-assignments (LACNIC shall not make micro-assignments, 4.5.5).
However, section 1.9 “Definitions” – which applies to all LACNIC policies – explicitly prohibits such assignments, stating 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 considering new uses for IPv6 (RFC 8273).
It also clarifies that the use of sub-assignments for ISPs, datacenters and similar organizations is not allowed.
Finally, in Spanish, prefixes (e.g., sub, micro, etc.) should not be hyphenated. The policy Policy Manual, however, contains cases where they are hyphenated and others where they are not. The proposal seeks to harmonize the Spanish spelling of the Manual, removing all unnecessary hyphens.
Rationale (Describe the problem you intend to solve)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.
In the case of IPv4, the use of NAT is widespread, so there are no implications. However, institutions not using NAT have the same problem as in IPv6.
In the case of IPv6, instead of unique addresses, the use of unique prefixes (/64) is increasingly common.
Likewise, the policy failed to consider the use of IP addresses in hotspots (when these are not ISPs, e.g., when they are associations or community networks), the use of IP addresses by guests or employees (Bring Your Own Device, BYOD), and other similar cases.
Another example is the case of an end user who 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 require 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 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).
In addition, hyphenation of prefixes is used in parts of the Spanish version of the Manual (“-sub”, “-micro” and others). The idea is to harmonize the spelling.
Current textCurrent text:
1.9 Assignments
To assign means to delegate address space to an end user, to be specifically used within the Internet infrastructure said end user operates. Assignments must only be made for specific purposes documented by specific organizations, and are not to be sub-assigned to other parties.
New text:
1.9 Assignments
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.
To avoid duplications and confusion, the last sentence of the first paragraph of section 2.3.3.4 (Assignments to End-Users) is deleted: “...but not for sub-delegation outside their organization.”
To avoid duplications and confusion, the last paragraph of section 4.5.5 (Micro-Assignments in IPv6) is deleted: “Organizations receiving micro-assignments shall not sub-assign these IP addresses.”
Likewise, LACNIC staff will harmonize the spelling (hyphenation) of words beginning with the prefixes “micro”, “sub” and others throughout the Spanish version of the manual.
New textCurrent text:
1.9 Assignments
To assign means to delegate address space to an end user, to be specifically used within the Internet infrastructure said end user operates. Assignments must only be made for specific purposes documented by specific organizations, and are not to be sub-assigned to other parties.
New text:
1.9 Assignments
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.
To avoid duplications and confusion, the last sentence of the first paragraph of section 2.3.3.4 (Assignments to End-Users) is deleted: “...but not for sub-delegation outside their organization.”
To avoid duplications and confusion, the last paragraph of section 4.5.5 (Micro-Assignments in IPv6) is deleted: “Organizations receiving micro-assignments shall not sub-assign these IP addresses.”
Likewise, LACNIC staff will harmonize the spelling (hyphenation) of words beginning with the prefixes “micro”, “sub” and others throughout the Spanish version of the manual.
Additional information-
TimetableImmediate implementation
ReferencesA similar proposal was discussed in the RIPE region and the change was approved, although there is no consensus regarding the changes specified in this proposal, as the texts are different. However, a version equivalent to this proposal is under discussion. Likewise, equivalent texts are being discussed in the AfrtiNIC and APNIC regions
Presented at:LACNIC 31 (06/05/2019)