<div dir="ltr">The rewrite is a pretty good step forward, and I support this policy as written, but I also would like to see some additional changes. <div><br><div>The following is a summary of what I would like to see the overall policy look like, it is not in policy language but provided as list of requirement, with some additional notes, then I note what I think is missing from the current proposed policy text;<br><div><br></div><div><div>Reallocations:<br></div><div>- All reallocations* MUST have a SWIP provided regardless of size.</div><div><br></div><div>Reassignments: </div><div>- For prefixes shorter than /48 a SWIP MUST be provided.<br></div>- For prefixes at /48 or longer a SWIP is provided at the discretion** of the ISP, except; <div> - If requested by the end-user, then a SWIP MUST be provided, or;</div><div> - If intended to appear in global routing table, then a SWIP SHOULD*** be provided.</div><div><br></div><div>* Reallocations are made to other ISPs which then can make reassignments, for IPv6 it is RECOMMENDED that all ISPs obtain an allocation directly from ARIN, however reallocations are still permitted. Further, reallocations for prefixes /48 or longer are NOT RECOMMENDED. SWIPs for reallocations need to be required because the abuse and other POC for the down stream ISP need to be know.</div><div><br></div><div>** There should be some guidance (NOT policy enforced by ARIN) to ISPs making reassignments at /48 or longer: SWIPs for business customers, especially those with information technology(IT) operations sophisticated enough to handle their own abuse and/or technical incidents, are of interest to the community. SWIPs for residential customers (individual persons) are NOT normally of interest to the community.</div><div><br></div><div>*** This might be more appropriate as MUST, however as ARIN does not define routing policy, therefore SHOULD seems more appropriate.<br clear="all"></div></div><div><br></div></div><div class="gmail_extra">So, I think the following is missing from the current proposed policy text;</div><div class="gmail_extra"><br></div><div class="gmail_extra">1. Any mention of reallocations, but this wasn't in the original policy either </div><div class="gmail_extra">2. A requirement that SWIP is provided if requested by end-user</div><div class="gmail_extra">3. Guidance for SWIPs for /48 or longer, while these SWIPs aren't required, some guidance still might be useful.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 21, 2017 at 11:44 AM, Leif Sawyer <span dir="ltr"><<a href="mailto:lsawyer@gci.com" target="_blank">lsawyer@gci.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div class="m_6082568554250308722gmail-m_-5987481514736829148m_3058502738913032091m_-6401781302861646328WordSection1">
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)">Happy Friday, everybody.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)">As promised, here is the latest rewrite of the draft policy below, and it will soon be updated at:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"><a href="https://www.arin.net/policy/proposals/2017_5.html" target="_blank">https://www.arin.net/policy/pr<wbr>oposals/2017_5.html</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)">There are two changes noted in the policy statement: the first of which reflects what seems to be the current<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)">consensus of the PPML regarding netblock sizing; the second is to strike language that may be read as either restrictive<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)">or non-operational.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)">----<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)">Problem Statement:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"> Current ARIN policy has different WHOIS directory registration requirements for IPv4 vs IPv6 address assignments.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"> IPv4 registration is triggered for an assignment of any address block equal to or greater than a /29 (i.e., eight IPv4 addresses).<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"> In the case of IPv6, registration occurs for an assignment of any block equal to or greater than a /64, which constitutes one entire IPv6 subnet and
is the minimum block size for an allocation.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"> Accordingly, there is a significant disparity between IPv4 and IPv6 WHOIS registration thresholds in the case of assignments, resulting in more work
in the case of IPv6 than is the case for IPv4.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"> There is no technical or policy rationale for the disparity, which could serve as a deterrent to more rapid IPv6 adoption.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"> The purpose of this proposal is to eliminate the disparity and corresponding adverse consequences.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)">Policy statement:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"> 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike "/64 or more addresses" and change to "/47 or more addresses, or sub-delegation
of any size that will be individually announced,"<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)">and
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"> 2) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by deleting the phrase "holding /64 and larger blocks"<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)">Comments:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)">a. Timetable for implementation:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"> Policy should be adopted as soon as possible.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)">b. Anything else:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"> Author Comments:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"> IPv6 should not be more burdensome than the equivalent IPv4 network size.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"> Currently, assignments of /29 or more of IPv4 space (8 addresses) require registration<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"> The greatest majority of ISP customers who have assignments of IPv4 space are of a single IPv4 address which do not trigger any ARIN registration requirement
when using IPv4.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"> This is NOT true when these same exact customers use IPv6, as assignments of /64 or more of IPv6 space require registration.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"> Beginning with RFC 3177, it has been standard practice to assign a minimum assignment of /64 to every customer end user site, and less is never used.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"> This means that ALL IPv6 assignments, including those customers that only use a single IPv4 address must be registered with ARIN if they are given
the minimum assignment of /64 of IPv6 space. <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"> This additional effort may prevent ISP's from giving IPv6 addresses because of the additional expense of registering those addresses with ARIN, which
is not required for IPv4.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"> The administrative burden of 100% customer registration of IPv6 customers is unreasonable, when such is not required for those customers receiving
only IPv4 connections.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)">---<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)">Leif Sawyer<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)">Advisory Council<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(153,51,102)"><u></u> <u></u></span></p>
</div>
</div>
<br>______________________________<wbr>_________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_6082568554250308722gmail-m_-5987481514736829148m_3058502738913032091gmail_signature">==============================<wbr>=================<br>David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <br>2218 University Ave SE Phone: <a href="tel:(612)%20626-0815" value="+16126260815" target="_blank">612-626-0815</a><br>Minneapolis, MN 55414-3029 Cell: <a href="tel:(612)%20812-9952" value="+16128129952" target="_blank">612-812-9952</a><br>==============================<wbr>================= </div>
</div></div></div>