<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body dir="auto">
<div>+1 I strongly agree!<br>
<br>
Sent from my iPhone</div>
<div><br>
On Nov 24, 2013, at 5:01 PM, "Andrew Dul" <<a href="mailto:andrew.dul@quark.net">andrew.dul@quark.net</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div class="moz-cite-prefix">I believe we need to be thinking about a much simpler IPv4 policy after run-out occurs. Initial allocation/assignment criteria could be as simple as, "Do you have 64 IP devices?" (e.g. 25% of a /24). If answer is yes, you are
approved for a /24. I'm suggesting the removal of section 4.2.2.1.1 and loosening the language of 4.2.2.1.2.
<br>
<br>
I'm also in favor of moving to a /24 minimum for ISPs and end-users.<br>
<br>
Also, I'd also like to point out that the ARIN community set aside a /10 worth of small blocks (/24-/28) to be used for new entrants after run-out occurs. This block was intended to be used by new entrants after run-out.
<br>
<br>
<a class="moz-txt-link-freetext" href="https://www.arin.net/policy/nrpm.html#four10">https://www.arin.net/policy/nrpm.html#four10</a><br>
<br>
The attached redline is Scott's version just formatted with revisions inline, which was helpful to me in considering what Scott was proposing.<br>
<br>
Andrew<br>
<br>
On 11/22/2013 5:05 PM, Scott Leibrand wrote:<br>
</div>
<blockquote cite="mid:CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com" type="cite">
<div dir="ltr">I suppose I should provide some explanation for my various changes, too:
<div><br>
</div>
<div>To address Randy's point that "the requirement of having space before you can get space seems a little ridiculous", I updated the requirement for single-homed ISPs to efficiently utilize space from upstream(s) that "total at least half the size of the
block being requested", which is in line what we already require from multihomed ISPs.</div>
<div><br>
</div>
<div>Per the original suggestion that most people seem to like, I changed the minimum allocation sizes to /22 for single-homed and /24 for multihomed orgs (both ISPs and end-users).</div>
<div><br>
</div>
<div>To address Owen's point about "<span style="font-family:arial,sans-serif;font-size:12.727272033691406px">allowing ARIN to issue down to /24 to single-homed organizations that can document their inability to get space from their upstream provider</span>",
I also included language that "If the [org] demonstrates that it cannot obtain sufficient IPv4 space from an upstream ISP, it can instead receive a /24 or larger via 8.3 transfer to the extent it can demonstrate an immediate need for the space." I didn't
go quite as far as Owen suggested in allowing orgs that only need a /28 to get a /24 if they can't get the /28 from their upstream.</div>
<div><br>
</div>
<div>I consolidated the single-homed and multi-homed ISP requirements into a single set (differing only in minimum allocation size), and threaded the needle on the multihomed "Renumber and return" requirement by making it a "should" in both cases.</div>
<div><br>
</div>
<div>I struck the reference to the now-deprecated RFC 2050. IMO if there are any requirements from it we still want enforced, we should put them in policy.</div>
<div><br>
</div>
<div>Feedback appreciated: thanks in advance!</div>
<div><br>
</div>
<div>-Scott</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Nov 22, 2013 at 4:44 PM, Scott Leibrand <span dir="ltr">
<<a moz-do-not-send="true" href="mailto:scottleibrand@gmail.com" target="_blank">scottleibrand@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>Below is a first attempt at updating 4.2.2 and 4.3 based on the feedback y'all have provided so far (thanks!). I've also attached the original text, new text, and diff if you want to see exactly what I I'm suggesting we change.<br>
</div>
<div><br>
</div>
<div>Thoughts?</div>
<div><br>
</div>
<div>Thanks,<br>
Scott</div>
<div><br>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:14pt;font-family:'Times New
Roman',serif">4.2.2. Initial allocation to ISPs</span></b></p>
<h6><a moz-do-not-send="true" name="142826a719cc42ee_four221"></a><a moz-do-not-send="true" name="142826a719cc42ee_four2211"></a><span style="font-size:12pt">4.2.2.1. General requirements</span></h6>
<p class="MsoNormal"><span style="font-size:12pt;font-family:'Times New
Roman',serif">In order to receive an initial allocation from ARIN, organizations must:</span></p>
<h6><span style="font-size:12pt">4.2.2.1.1. Demonstrate use of existing space</span></h6>
<p class="MsoNormal"><span style="font-size:12pt;font-family:'Times New
Roman',serif">Demonstrate the efficient utilization of existing IPv4 block(s) from an upstream ISP that total at least half the size of the block being requested. If
the ISP demonstrates that it cannot obtain sufficient IPv4 space from an upstream ISP, it can instead receive a /24 or larger via 8.3 transfer to the extent it can demonstrate an immediate need for the space.</span></p>
<h6><a moz-do-not-send="true" name="142826a719cc42ee_four2212"></a><span style="font-size:12pt">4.2.2.1.2. Demonstrate efficient utilization</span></h6>
<p class="MsoNormal"><span style="font-size:12pt;font-family:'Times New
Roman',serif">Demonstrate efficient use of IPv4 address space allocations by providing appropriate documentation, including assignment histories, showing their efficient
use. ISPs must provide reassignment information on the entire previously allocated block(s) via SWIP or RWhois server for /29 or larger blocks. For blocks smaller than /29 and for internal space, ISPs should provide utilization data either via SWIP or RWhois
server or by providing detailed utilization information.</span></p>
<h6><a moz-do-not-send="true" name="142826a719cc42ee_four2213"></a><span style="font-size:12pt">4.2.2.1.3. Utilize requested space within three months</span></h6>
<p class="MsoNormal"><span style="font-size:12pt;font-family:'Times New
Roman',serif">Provide detailed information showing specifically how the requested IPv4 space will be utilized within three months.</span></p>
<h6><a moz-do-not-send="true" name="142826a719cc42ee_four2214"></a><span style="font-size:12pt">4.2.2.1.4. Renumber and return</span></h6>
<p class="MsoNormal"><span style="font-size:12pt;font-family:'Times New
Roman',serif">ISPs receiving IP space from ARIN should renumber out of their previously allocated space if possible. If able to do so, an ISP should use the new IPv4
block to renumber out of that previously allocated block of address space and must return the space to its upstream provider.</span></p>
<h6><a moz-do-not-send="true" name="142826a719cc42ee_four222"></a><span style="font-size:12pt">4.2.2.2. Initial allocation sizes</span></h6>
<h6><span style="font-size:12pt">4.2.2.2.1 Single-homed</span></h6>
<p class="MsoNormal"><span style="font-size:12pt;font-family:'Times New
Roman',serif">Single-homed organizations meeting the requirements listed above may request an initial allocation from ARIN between /20 and /22 in size.
</span></p>
<h6><span style="font-size:12pt">4.2.2.2.2 Multi-homed</span></h6>
<p class="MsoNormal"><span style="font-size:12pt;font-family:'Times New
Roman',serif">Multi-homed organizations meeting the requirements listed above and demonstrating an intent to announce the requested space in a multihomed fashion may
request an initial allocation from ARIN between /20 and /24 in size. </span><a moz-do-not-send="true" name="142826a719cc42ee_four2221"></a><br clear="all">
</p>
<p class="MsoNormal"><b><span style="font-size:14pt;font-family:'Times New
Roman',serif"><br>
</span></b></p>
<p class="MsoNormal"><b><span style="font-size:14pt;font-family:'Times New
Roman',serif"><br>
</span></b></p>
<p class="MsoNormal"><b><span style="font-size:14pt;font-family:'Times New
Roman',serif"><br>
</span></b></p>
<p class="MsoNormal"><b><span style="font-size:14pt;font-family:'Times New
Roman',serif"><br>
</span></b></p>
<p class="MsoNormal"><b><span style="font-size:14pt;font-family:'Times New
Roman',serif">4.3.1. End-users</span></b></p>
<p>ARIN assigns blocks of IP addresses to end-users who request address space for their internal use in running their own networks, but not for sub-delegation of those addresses outside their organization. End-users must meet the requirements described in these
guidelines for justifying the assignment of an address block.</p>
<p class="MsoNormal"><b><span style="font-size:14pt;font-family:'Times New
Roman',serif">4.3.2. Minimum assignment</span></b></p>
<h6><a moz-do-not-send="true" name="142826a719cc42ee_four321"></a><span style="font-size:12pt">4.3.2.1 Single Connection</span></h6>
<p>The minimum block of IP address space assigned by ARIN to end-users is a /22. If assignments smaller than /22 are needed, end-users should contact their upstream provider. If the end-user demonstrates that it cannot obtain sufficient IPv4 space from an
upstream ISP, it can instead receive a /24 or larger via 8.3 transfer to the extent it can demonstrate an immediate need for the space.</p>
<h6><a moz-do-not-send="true" name="142826a719cc42ee_four322"></a><span style="font-size:12pt">4.3.2.2 Multihomed Connection</span></h6>
<p>For multihomed end-users who demonstrate an intent to announce the requested space in a multihomed fashion to two or more distinct ASNs not owned or controlled by the end-user, the minimum block of IP address space assigned is a /24. If assignments smaller
than a /24 are needed, multihomed end-users should contact their upstream providers. When prefixes are assigned which are smaller than /22, they will be from a block reserved for that purpose so long as that is feasible.</p>
<h6><span style="font-size:12pt">4.3.3. Utilization rate</span></h6>
<p class="MsoNormal"><span style="font-size:12pt;font-family:'Times New
Roman',serif">Utilization rate of address space is a key factor in justifying a new assignment of IP address space. Requesters must show exactly how previous address
assignments have been utilized and must provide appropriate details to verify their one-year growth projection. The basic criteria that must be met are:</span></p>
<ul type="disc">
<li class="MsoNormal"><span style="font-size:12pt;font-family:'Times New
Roman',serif">A 25% immediate utilization rate, and</span>
</li><li class="MsoNormal"><span style="font-size:12pt;font-family:'Times New
Roman',serif">A 50% utilization rate within one year.</span>
</li></ul>
<p class="MsoNormal"><span style="font-size:12pt;font-family:'Times New
Roman',serif">A greater utilization rate may be required based on individual network requirements.</span></p>
<p class="MsoNormal"> </p>
</div>
<div>
<div class="h5"><br>
<div class="gmail_quote">---------- Forwarded message ----------<br>
From: <b class="gmail_sendername">Scott Leibrand</b> <span dir="ltr"><<a moz-do-not-send="true" href="mailto:scottleibrand@gmail.com" target="_blank">scottleibrand@gmail.com</a>></span><br>
Date: Thu, Nov 21, 2013 at 3:03 PM<br>
Subject: Bootstrapping new entrants after IPv4 exhaustion<br>
To: ARIN-PPML List <<a moz-do-not-send="true" href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a>><br>
<br>
<br>
<div dir="ltr">During the discussion in Phoenix of Draft Policy 2013-7 (which I've since updated and will be sending back out to PPML shortly), and in other discussions before and since, it has become apparent that small networks may not qualify for transfers
and be unable to get space from their upstreams after RIR and ISP IPv4 free pools run out.
<div><br>
</div>
<div>In order to address this issue, a few different ideas have come up, so I wanted to bring some of them up to the community for discussion and see which possible solutions might have community support.</div>
<div><br>
</div>
<div>Here are a couple of the ideas that've come up so far:</div>
<div><br>
</div>
<div><br>
<div>
<div>1) For smaller allocations than ARIN’s minimum, orgs “should request space from their upstream provider _<u>or another LIR</u>_” (add underlined text to <a moz-do-not-send="true" href="https://www.arin.net/policy/nrpm.html#four215" target="_blank">NRPM
4.2.1.5</a>).</div>
<div><br>
</div>
<div>This would clarify that it's fine for organizations to get space reassigned to them by any other LIR if their upstream ISPs are no longer able to provide them the space they need.</div>
<div><br>
</div>
<div><br>
</div>
<div>2) Lower the minimum allocation sizes to /22 single-homed and /24 multihomed for both ISPs and end-users. This would mean updating <a moz-do-not-send="true" href="https://www.arin.net/policy/nrpm.html#four22" target="_blank">NRPM 4.2.2</a> and
<a moz-do-not-send="true" href="https://www.arin.net/policy/nrpm.html#four32" target="_blank">
4.3.2</a> (and would allow removal of <a moz-do-not-send="true" href="https://www.arin.net/policy/nrpm.html#four9" target="_blank">NRPM 4.9</a> as redundant.)</div>
</div>
</div>
<div><br>
</div>
<div>Before the implementation of CIDR, many /24 allocations were made to organizations that are no longer using them. <a moz-do-not-send="true" href="https://www.arin.net/policy/nrpm.html#eight3" target="_blank">Current ARIN transfer policy
</a>states that the minimum transfer size is a /24, but it's not clear in policy whether an single-homed organization that needs a small block (/24 to /21) would actually qualify to receive such a block via transfer. (Perhaps staff input here would be useful.)
In any event, reducing the minimum allocation sizes would allow organizations of all types to receive the size of address block they actually need, either via transfer or from ARIN's inventory of returned space.<br>
</div>
<div><br>
</div>
<div>Thoughts? Do you support either or both of these ideas? Would one or both of them be worth submitting as a policy proposal?</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Scott</div>
</div>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset> <br>
<pre wrap="">_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.</pre>
</blockquote>
<br>
</div>
</blockquote>
<blockquote type="cite">
<div><Bootstrapping_new_entrants_redline_diff.pdf></div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>PPML</span><br>
<span>You are receiving this message because you are subscribed to</span><br>
<span>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).</span><br>
<span>Unsubscribe or manage your mailing list subscription at:</span><br>
<span><a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a></span><br>
<span>Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.</span></div>
</blockquote>
</body>
</html>