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]
<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.
