[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.html>


More information about the ARIN-PPML mailing list