<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 23, 2017 at 12:02 PM, William Herrin <span dir="ltr"><<a href="mailto:bill@herrin.us" target="_blank">bill@herrin.us</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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">On Tue, May 23, 2017 at 2:35 PM, ARIN <span dir="ltr"><<a href="mailto:info@arin.net" target="_blank">info@arin.net</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6<br>
<br></span><span class="gmail-">
Policy statement:<br>
<br>
Amend 4.2.3.7.1 of the policy manual to strike "/29 or more" and change to "more than a /28".<br></span></blockquote><div><br></div><div>Hello,<br><br></div><div>In my opinion...<br></div><div><br></div><div>Leave /29 alone or change it to "more than a single IP address." In these days of IPv4 shortage, substantial networks sit behind small blocks of public addresses. These networks should be documented with reachable POCs lest the anti-spam/virus/malware folks slam down /24 filters for lack of information about how misbehaving networks are partitioned.<br></div><span class="gmail-"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Amend 6.5.5.1 of the policy manual to strike "/64 or more" and change to "more than a /60".<br></blockquote><div><br></div></span><div>Change this to "more than a /56." Service providers should NOT be assigning /64's to end users. If you're doing that, you're doing it wrong. An IPv6 customer should be able to have more than one /64 subnet without resorting to NAT so /60 should be the absolute minimum end-user assignment, equivalent for all intents and purposes to an IPv4 /32. If we then want "equivalence" to the /29 policy so that individuals with the minimum and near-minimum assignment do not need to be SWIPed, it makes sense to move the next subnetting level up. In IPv6, assignment is strongly recommended on nibble boundaries, so that means /56.<br></div><div><br></div></div></div></div></blockquote>+1<div><br></div><div>I believe this policy, as written, is misleadingly titled.  I support the intent expressed in the title, and support either the <span style="font-size:12.8px">"more than a /60" language or (preferentially) Bill's "</span>more than a /56" language below for equalizing assignment registration requirements between IPv4 and IPv6.</div><div><br></div><div>However, I definitely do not support also relaxing the "/29 or more" requirement for IPv4 without a significant revision of the problem statement to indicate why such a change is justified, and a retitling of the proposal.  And even with those changes, I likely would not support relaxing the "/29 or more" requirement.  For context, my employer currently has a large number of /29 networks reassigned from our upstream transit providers (one for each link for unique routing purposes).  Those currently are not reassigned to us in whois (in contravention of ARIN policy), but it would be better for us (for geolocation purposes, for example) if they were properly reassigned.</div><div><br></div><div>-Scott</div></div></div></div>