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 <[email protected] > <mailto:[email protected]>> 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 ([email protected] > <mailto:[email protected]>). > 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 [email protected] <mailto:[email protected]> if you > experience any issues. > > > > > -- > =============================================== > David Farmer Email:[email protected] > <mailto:email%[email protected]> > 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 ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues.
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
