<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 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 name="142826a719cc42ee_four221"></a><a 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 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 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 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 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 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 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 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 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 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 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 href="https://www.arin.net/policy/nrpm.html#four22" target="_blank">NRPM 4.2.2</a> and <a href="https://www.arin.net/policy/nrpm.html#four32" target="_blank">4.3.2</a> (and would allow removal of <a 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 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>