<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>