<p dir="ltr">Owen,</p>
<p dir="ltr">My experience suggests renumbering that much IP space that is actually in use is non-trivial.</p>
<p dir="ltr">However, if renumbering as a justification sounds insufficient to many how about demonstrated growth equal or greater than 50% of the transferred IP space. <br></p>
<p dir="ltr">Certainly an organization had to list the IP holdings and utilization at the time they requested transfer approval. Certainly they would have to do the same with their next request to demonstrate efficient utilization. Generating a delta of the count of things vs a delta of half of new addresses seems simple. </p>
<p dir="ltr">Would that be sufficient?</p>
<p dir="ltr">The nice thing about avoiding the traditional request path is avoiding future looking projections, speculation about business plans, and unpredictable outcomes. </p>
<p dir="ltr">___Jason</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Jan 31, 2017 9:38 PM, "Owen DeLong" <<a href="mailto:owen@delong.com">owen@delong.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">I argue that it is insufficient and that a 6-month moratorium on a second simplified transfer is easier for everyone to understand and implement.<div><br></div><div>The reason I feel it is insufficient is that renumbering a DHCP server handing out a /17 (or cobbling up a DHCP server handing out a /17) isn’t a particularly difficult barrier.</div><div><br></div><div>Given that the preponderance of addresses handed out by larger service providers these days are dynamic in nature, renumbering large swaths of address space to circumvent the intent of the /16 limit on this policy is relatively trivial.</div><div><br></div><div>Any organization that truly needs a larger transfer is free to get the approval through the conventional process and this simplified process is probably not a good fit as a result.</div><div><br></div><div>I believe that is congruent with your original intent and that the six-month recycle limit is a quite reasonable safeguard.</div><div><br></div><div>Owen</div><div><br><div><blockquote type="cite"><div>On Jan 31, 2017, at 08:04 , Jason Schiller <<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>> wrote:</div><br class="m_6977201144970151101Apple-interchange-newline"><div><div dir="ltr">As one of the originators of this policy change I welcome the rewrite, <div>with the exception the mechanism to avoid abuse.<div><br></div><div>Can someone explain the "abuse" concerns if I have not correctly captured it?</div><div><br></div><div><br></div><div>Abuse concern:</div><div>---------------------</div><div>As far as I can tell, the combination of 2016-5 and this proposal (2016-3) is where the issue comes from. </div><div>One of the goals of 2016-5 was to separate section 4 from transfers.</div><div><br></div><div>As a result, NRPM 4.2.4.1 & 4.3.6.1 which specifies that organizations must show efficient utilization of 80% in aggregate, and 50% for each allocation/assignment is no longer a restriction to transfers.</div><div><br></div><div>Without applying 4.2.4.1 & 4.3.6.1 an organization that is holding a /8 that is 90% utilized, could then use 8.5.7 to justify a specified transfer of a /16.  </div><div><br></div><div>Once completed, the total holding of a /16 and a /8 would be 89.65% utilized and could immediately use 8.5.7 to justify another specified transfer of a /16.  </div><div><br></div><div>This process could be used 33 times and could result in drawing down a /11 and a /16 without putting a single new address into service.</div><div><br></div><div><br></div><div>Basic idea of 2016-3 and 2016-4:</div><div>------------------------------<wbr>---------------</div><div><br></div><div>1. Make an easy to use process with an easily predictable outcome for </div><div>    "simplified" transfers</div><div>2. Modify slow start and make it applicable to transfers for end-sites and ISPs</div><div>3. Give blanket approval for a "first", "small" starter block</div><div>4. Show that you have used what you got and then double what you have</div><div>5. Can always get more than double following the non-simplified process</div><div><br></div><div><br></div><div>Intended Cap implementation:</div><div>------------------------------<wbr>----------</div><div><br></div><div>Doubling more than a /16 could provide way too much IP space</div><div>(consider an efficiently used org than is not growing)</div><div>Instead the doubling policy is limited at a /16.</div><div>However if an organization is growing and has legitimate need for more </div><div>than a /16, then it can get a /16 put it into service and then come back </div><div>and get another dip.</div><div><br></div><div><br></div><div>Suggested Anti-abuse text:</div><div>------------------------------<wbr>-------</div><div><br></div><div><div>To this, 2016-3 now adds a new paragraph:</div><div><br></div><div>8.5.7 Alternative Additional IPv4 Address Block Criteria</div><div>In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4 address blocks by demonstrating both </div><div>- 80% utilization of their currently allocated space </div><div>- at least 50% utilization of each allocation and assignment</div><div>If they do so, they qualify to receive one or more transfers up to the total size of their current ARIN IPv4 address holdings, with a maximum size of /16.</div></div><div><br></div><div>Taking the abuse example above of an organization with a /8 that is is 90% utilized, </div><div>the organization would need to transfer in a /16.  </div><div>Then the organization would need to put 32,768 of the new IPs into service, </div><div>or renumber the use of 32,768 of IPs from the older IP space to the new space.</div><div><br></div><div>I argue that need to show growth or the renumbering of usage into the new IP space </div><div>is of sufficient pain to avoid abuse by organizations that don't actually need the IP space.</div><div><br></div><div>__Jason</div><div><br></div><div> </div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 31, 2017 at 8:18 AM, David R Huberman <span dir="ltr"><<a href="mailto:daveid@panix.com" target="_blank">daveid@panix.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
TL;DR:  We updated 2016-3 to fit into the upcoming NRPM, and closed an abuse vector.  We kept the original text and just incorporated it in the new section 8.5 so it works, and time limited it to once every 6 months.<br>
<br>
Background:<br>
<br>
At the ARIN meeting in Dallas, there was a discussion about 2016-3, a policy which seeks to remove Needs Testing for smaller 8.3 and 8.4 transfers (with a cap of /16).  Some more work needed to be done on it, and a vote at the Dallas meeting had 27 people ask the AC to continue working on it, with 1 person against.<br>
<br>
We've done some work, and the new text is ready for your review and comment.<br>
<br>
<br>
New NRPM Coming Out Affects 2016-3:<br>
<br>
Policy 2016-5 was ratified by the board, and will be entering the NRPM shortly.  2016-5 adds a new section to section 8 -- it adds 8.5, which are the qualifying criteria for transfers.  It looks like this:<br>
<br>
8.5. Specified Transfer Recipient Requirements<br>
<br>
8.5.1. Registration Services Agreement<br>
The receiving entity must sign an RSA covering all resources to be transferred unless that entity has a current (within the last two versions) RSA on file.<br>
<br>
8.5.2. Operational Use<br>
ARIN allocates or assigns number resources to organizations via transfer solely for the purpose of use on an operational network.<br>
<br>
8.5.3. Minimum transfer size<br>
ARINs minimum IPv4 transfer size is a /24.<br>
<br>
8.5.4. Initial block<br>
Organizations without direct assignments or allocations from ARIN qualify for transfer of an initial IPv4 block of ARINs minimum transfer size.<br>
<br>
8.5.5. Block size<br>
Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN.<br>
<br>
8.5.6. Efficient utilization of previous blocks<br>
Organizations with direct assignments or allocations from ARIN must have efficiently utilized at least 50% of their cumulative IPv4 address blocks in order to receive additional space. This includes all space reassigned to their customers.<br>
<br>
<br>
To this, 2016-3 now adds a new paragraph:<br>
<br>
8.5.7 Alternative Additional IPv4 Address Block Criteria<br>
In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4 address blocks by demonstrating 80% utilization of their currently allocated space. If they do so, they qualify to receive one or more transfers up to the total size of their current ARIN IPv4 address holdings, with a maximum size of /16.<br>
<br>
An organization may only qualify under 8.5.7 once every 6 months.<br>
<br>
<br>
Conclusion:<br>
<br>
This text is pretty much the same text that was originally proposed in 2016-3, simply incorporated into the new NRPM language that's coming out.<br>
<br>
It also puts in a mechanism to avoid abuse -- people trying to get around the /16 cap -- by limiting it to once every 6 months.<br>
<br>
The AC welcomes your feedback.<br>
<br>
Thank you,<br>
David<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_6977201144970151101gmail_signature" data-smartmail="gmail_signature"><font color="#555555" face="'courier new', monospace"><div><span style="font-family:arial"><font color="#555555" face="'courier new', monospace">______________________________<wbr>_________________________<br></font><div><font face="'courier new', monospace">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank">jschiller@<wbr>google.com</a>|<a href="tel:(571)%20266-0006" value="+15712660006" target="_blank">571-266-0006</a></font></div><div><font face="'courier new', monospace"><br></font></div></span></div></font></div>
</div>
______________________________<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" 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.</div></blockquote></div><br></div></div></blockquote></div></div>