[arin-ppml] Draft Policy ARIN-2018-4: Clarification on IPv6 Sub-Assignments
Andrew Dul
andrew.dul at quark.net
Fri May 4 21:40:11 EDT 2018
I'd like to suggest that the proposed policy text be shorted and
clarified. I don't believe all the examples are necessary in the
definition section.
Add to the end of NRPM Section 2.5 -
https://www.arin.net/policy/nrpm.html#two5
Current draft text:
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. 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.
My suggested rewrite:
A unique address or a unique /64 prefix that is non-permanently provided
to third parties, shall not be considered an assignment.
On 4/24/2018 11:57 AM, David Farmer wrote:
> I note that the text in question is the subject of an editorial change
> that the AC has recently forwarded to Board for review, at a minimum
> the policy text need to be updated to account for this editorial
> change. Further, I do not support the text as written.
>
> I support a change to section 2 that is not quite so IPv6 specific and
> focused more on the idea that providing hotspot, guest access, or
> other such temporary access does not necessitate the making of
> re-assignments from a policy perspective. Furthermore, such uses are
> not in conflict with the conditions of an assignment (made by ARIN) or
> re-assignment (made by an ISP or LIR). Also, If the details of RFC8273
> need to be mentioned at all, they should be someplace in section 6,
> not in section 2, the definitions of assign, allocate, re-assign and
> re-allocate should remain agnostic about IP version.
>
> Thanks.
>
> On Mon, Apr 23, 2018 at 2:22 PM, ARIN <info at arin.net
> <mailto:info at arin.net>> wrote:
>
> On 18 April 2018 the ARIN Advisory Council (AC) accepted
> "ARIN-prop-254: Clarification on IPv6 Sub-Assignments" as a Draft
> Policy.
>
> Draft Policy ARIN-2018-4 is below and can be found at:
> https://www.arin.net/policy/proposals/2018_4.html
> <https://www.arin.net/policy/proposals/2018_4.html>
>
> You are encouraged to discuss all Draft Policies on PPML. The AC
> will evaluate the discussion in order to assess the conformance of
> this draft policy with ARIN's Principles of Internet number
> resource policy as stated in the Policy Development Process (PDP).
> Specifically, these principles are:
>
> * Enabling Fair and Impartial Number Resource Administration
> * Technically Sound
> * Supported by the Community
>
> The PDP can be found at:
> https://www.arin.net/policy/pdp.html
> <https://www.arin.net/policy/pdp.html>
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
> <https://www.arin.net/policy/proposals/index.html>
>
> Regards,
>
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
>
>
>
> Draft Policy ARIN-2018-4: Clarification on IPv6 Sub-Assignments
>
> 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
> (RFC8273), by means of a new paragraph.
>
> 5. 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 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. 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.
>
>
>
> 6. Comments
>
> a. Timetable for implementation:
>
> Immediate
>
> b. 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.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
> <mailto:ARIN-PPML at arin.net>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> <http://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact info at arin.net <mailto:info at arin.net> if you
> experience any issues.
>
>
>
>
> --
> ===============================================
> David Farmer Email:farmer at umn.edu
> <mailto:Email%3Afarmer at umn.edu>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE Phone: 612-626-0815
> Minneapolis, MN 55414-3029 Cell: 612-812-9952
> ===============================================
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20180504/1972c81b/attachment.htm>
More information about the ARIN-PPML
mailing list