<div dir="ltr">I would support something along these lines, either something that takes effect after ARIN's IPv4 free pool is exhausted (no more /24s are available), or something that takes effect sooner but only applies to transfers. I don't want to change the rules this late in the game for the remaining free pool.<div>
<br></div><div>Again, a question for everyone else on the list: do you think we should be making incremental changes to the minimum allocation requirements and tweaks to make needs qualification a bit simpler and easier? Or should we be looking at a *much* simpler and easier policy?</div>
<div><br></div><div>Thanks,</div><div>Scott</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Nov 24, 2013 at 1:52 PM, Andrew Dul <span dir="ltr"><<a href="mailto:andrew.dul@quark.net" target="_blank">andrew.dul@quark.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>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 href="https://www.arin.net/policy/nrpm.html#four10" target="_blank">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.<span class="HOEnZb"><font color="#888888"><br>
<br>
Andrew</font></span><div><div class="h5"><br>
<br>
On 11/22/2013 5:05 PM, Scott Leibrand wrote:<br>
</div></div></div>
<blockquote type="cite"><div><div class="h5">
<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>4.2.2. Initial allocation to ISPs</span></b></p>
<h6><a name="1428c21dbcdb77df_142826a719cc42ee_four221"></a><a name="1428c21dbcdb77df_142826a719cc42ee_four2211"></a><span style="font-size:12pt">4.2.2.1.
General requirements</span></h6>
<p class="MsoNormal"><span>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>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="1428c21dbcdb77df_142826a719cc42ee_four2212"></a><span style="font-size:12pt">4.2.2.1.2. Demonstrate
efficient utilization</span></h6>
<p class="MsoNormal"><span>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="1428c21dbcdb77df_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>Provide detailed information showing
specifically how the requested IPv4 space will be
utilized within three months.</span></p>
<h6><a name="1428c21dbcdb77df_142826a719cc42ee_four2214"></a><span style="font-size:12pt">4.2.2.1.4. Renumber and
return</span></h6>
<p class="MsoNormal"><span>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="1428c21dbcdb77df_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>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>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="1428c21dbcdb77df_142826a719cc42ee_four2221"></a><br clear="all">
</p>
<p class="MsoNormal"><b><span><br>
</span></b></p>
<p class="MsoNormal"><b><span><br>
</span></b></p>
<p class="MsoNormal"><b><span><br>
</span></b></p>
<p class="MsoNormal"><b><span><br>
</span></b></p>
<p class="MsoNormal"><b><span>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>4.3.2. Minimum assignment</span></b></p>
<h6><a name="1428c21dbcdb77df_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="1428c21dbcdb77df_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>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>A 25% immediate utilization rate,
and</span></li>
<li class="MsoNormal"><span>A 50% utilization rate within one
year.</span></li>
</ul>
<p class="MsoNormal"><span>A greater utilization rate may be
required based on individual network requirements.</span></p>
<p class="MsoNormal"> </p>
</div>
<div>
<div><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>
<br>
<fieldset></fieldset>
<br>
</div></div><div class="im"><pre>_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.</pre>
</div></blockquote>
<br>
</div>
<br>_______________________________________________<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">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/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br></blockquote></div><br></div>