ARIN-prop-254: Clarification on IPv6 Sub-assignments [Archived]

OUT OF DATE?

Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.

Date: 21 March 2018

Proposal Originator: Jordi Palet Martínez

Problem Statement:

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

Section 2.5 (Definitions/Allocate and Assign), explicitly prohibits such assignments, stating that “Assignments… are not to be sub-assigned to other parties”.

This proposal clarifies this situation in this regard and better define the concept, particularly considering new uses of IPv6 (RFC 8273), by means of a new paragraph.

Policy Statement:

Actual Text

Assign - To assign means to delegate address space to an ISP or end-user, for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organizations and are not to be sub-assigned to other parties.

New Text

Assign - To assign means to delegate address space to an ISP or end-user, for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organizations and are not to be sub-assigned to other parties.

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.

Comments:

Timetable for implementation: Immediate

Anything else:

Situation in other regions:

This situation, has already been corrected in RIPE, and the policy was updated in a similar way, even if right now there is a small discrepancy between the policy text that reached consensus and the RIPE NCC Impact Analysis. A new policy proposal has been submitted to amend that, and the text is the same as presented by this proposal at ARIN. Same text has also been submitted to AfriNIC, LACNIC and APNIC.