+1 On Fri, May 4, 2018 at 9:40 PM Andrew Dul <[email protected]> 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 <[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 >> >> 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 ([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. >> > > > > -- > =============================================== > David Farmer 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. >
_______________________________________________ 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.
