[arin-ppml] Draft Policy ARIN-2018-4: Clarification on IPv6 Sub-Assignments

Tue May 8 12:40:20 EDT 2018

+1

On Fri, May 4, 2018 at 9:40 PM Andrew Dul <andrew.dul at quark.net> wrote:

> 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> 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
>>
>> 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
>>
>> Draft Policies and Proposals under discussion can be found at:
>> 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).
>> 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.
>>
>
>
>
> --
> ===============================================
> David Farmer               Email:farmer 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.
>
>
> _______________________________________________
> ARIN-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:
> https://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/20180508/0e615b1b/attachment.htm>