[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.htm>
More information about the ARIN-PPML
mailing list