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

John Santos john at egh.com
Thu May 10 11:00:20 EDT 2018


I find the word "temporarily" even more obvious than "non-permanently".  
If those two words don't mean the same thing, then we definitely need a 
definition.


On 5/10/2018 5:08 AM, JORDI PALET MARTINEZ wrote:
>
> What will be your opinion if I amend this proposal, so it works for 
> both IPv4 and IPv6, having this text in section 2.5 (Allocate and 
> Assign), make it shorter and more generic:
>
> “A unique IPv4 or IPv6 address or a unique IPv6 /64 prefix, which is 
> non-permanently provided to third parties, shall not be considered an 
> assignment”
>
> Alternatively, if we don’t want to go so far as to define the “size”:
>
> “An IPv4 or IPv6 block of address, which is non-permanently provided 
> to third parties, shall not be considered an assignment”
>
> I didn’t found short-term defined in the NRPM. Do you still think we 
> need to define “permanently” ? I think saying non-permanently it is 
> quite obvious, but maybe folks disagree …
>
>
> Regards,
>
> Jordi
>
> *De: *ARIN-PPML <arin-ppml-bounces at arin.net> en nombre de Jo Rhett 
> <jrhett at netconsonance.com>
> *Fecha: *miércoles, 9 de mayo de 2018, 20:37
> *Para: *<andrew.dul at quark.net>
> *CC: *<arin-ppml at arin.net>
> *Asunto: *Re: [arin-ppml] Draft Policy ARIN-2018-4: Clarification on 
> IPv6 Sub-Assignments
>
> "Nominative, verb indirect" isn't English ;) Clean english structure 
> would be:
>
> "A unique address or a unique /64 prefix that is non-permanently 
> provided to third parties shall not be considered an assignment. "
>
>
> Or if you really want a descriptive phrase that modifies the 
> nominative you can get commas like so:
>
>
>
> "A unique address or a unique /64 prefix, which is non-permanently 
> provided to third parties, shall not be considered an assignment."
>
> I would also argue that this phrase is very vague unless "permanently" 
> is defined elsewhere in the document. Wasn't there some phrasing 
> around short-term assignment? (sorry, too busy/too lazy to grab the 
> entire doc right now)
>
> On Fri, May 4, 2018 at 6:40 PM Andrew Dul 
> <andrew.dul at quark.net<mailto: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<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
>
>             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<mailto: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<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<mailto: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<mailto: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<mailto: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<mailto: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.
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
>
> This electronic message contains information which may be privileged 
> or confidential. The information is intended to be for the exclusive 
> use of the individual(s) named above and further non-explicilty 
> authorized disclosure, copying, distribution or use of the contents of 
> this information, even if partially, including attached files, is 
> strictly prohibited and will be considered a criminal offense. If you 
> are not the intended recipient be aware that any disclosure, copying, 
> distribution or use of the contents of this information, even if 
> partially, including attached files, is strictly prohibited, will be 
> considered a criminal offense, so you must reply to the original 
> sender to inform about this communication and delete it.
>
>
>
> _______________________________________________
> 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.

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20180510/044f2c22/attachment.html>


More information about the ARIN-PPML mailing list