[arin-ppml] Bootstrapping new entrants after IPv4 exhaustion

Andrew Dul andrew.dul at quark.net
Sun Nov 24 16:52:58 EST 2013


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. 

I'm also in favor of moving to a /24 minimum for ISPs and end-users.

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. 

https://www.arin.net/policy/nrpm.html#four10

The attached redline is Scott's version just formatted with revisions
inline, which was helpful to me in considering what Scott was proposing.

Andrew

On 11/22/2013 5:05 PM, Scott Leibrand wrote:
> I suppose I should provide some explanation for my various changes, too:
>
> 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.
>
> 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).
>
> To address Owen's point about "allowing ARIN to issue down to /24 to
> single-homed organizations that can document their inability to get
> space from their upstream provider", 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.
>
> 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.
>
> 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.
>
> Feedback appreciated: thanks in advance!
>
> -Scott
>
>
> On Fri, Nov 22, 2013 at 4:44 PM, Scott Leibrand
> <scottleibrand at gmail.com <mailto:scottleibrand at gmail.com>> wrote:
>
>     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.
>
>     Thoughts?
>
>     Thanks,
>     Scott
>
>     *4.2.2. Initial allocation to ISPs*
>
>
>                 4.2.2.1. General requirements
>
>     In order to receive an initial allocation from ARIN, organizations
>     must:
>
>
>                 4.2.2.1.1. Demonstrate use of existing space
>
>     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.
>
>
>                 4.2.2.1.2. Demonstrate efficient utilization
>
>     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.
>
>
>                 4.2.2.1.3. Utilize requested space within three months
>
>     Provide detailed information showing specifically how the
>     requested IPv4 space will be utilized within three months.
>
>
>                 4.2.2.1.4. Renumber and return
>
>     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.
>
>
>                 4.2.2.2. Initial allocation sizes
>
>
>                 4.2.2.2.1 Single-homed
>
>     Single-homed organizations meeting the requirements listed above
>     may request an initial allocation from ARIN between /20 and /22 in
>     size. 
>
>
>                 4.2.2.2.2 Multi-homed
>
>     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. 
>
>     *
>     *
>
>     *
>     *
>
>     *
>     *
>
>     *
>     *
>
>     *4.3.1. End-users*
>
>     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.
>
>     *4.3.2. Minimum assignment*
>
>
>                 4.3.2.1 Single Connection
>
>     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.
>
>
>                 4.3.2.2 Multihomed Connection
>
>     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.
>
>
>                 4.3.3. Utilization rate
>
>     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:
>
>       * A 25% immediate utilization rate, and
>       * A 50% utilization rate within one year.
>
>     A greater utilization rate may be required based on individual
>     network requirements.
>
>      
>
>
>     ---------- Forwarded message ----------
>     From: *Scott Leibrand* <scottleibrand at gmail.com
>     <mailto:scottleibrand at gmail.com>>
>     Date: Thu, Nov 21, 2013 at 3:03 PM
>     Subject: Bootstrapping new entrants after IPv4 exhaustion
>     To: ARIN-PPML List <arin-ppml at arin.net <mailto:arin-ppml at arin.net>>
>
>
>     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.
>
>     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.
>
>     Here are a couple of the ideas that've come up so far:
>
>
>     1) For smaller allocations than ARIN's minimum, orgs "should
>     request space from their upstream provider __or another LIR__"
>     (add underlined text to NRPM 4.2.1.5
>     <https://www.arin.net/policy/nrpm.html#four215>).
>
>     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.
>
>
>     2) Lower the minimum allocation sizes to /22 single-homed and /24
>     multihomed for both ISPs and end-users.  This would mean
>     updating NRPM 4.2.2
>     <https://www.arin.net/policy/nrpm.html#four22> and 4.3.2
>     <https://www.arin.net/policy/nrpm.html#four32> (and would allow
>     removal of NRPM 4.9
>     <https://www.arin.net/policy/nrpm.html#four9> as redundant.)
>
>     Before the implementation of CIDR, many /24 allocations were made
>     to organizations that are no longer using them.  Current ARIN
>     transfer policy
>     <https://www.arin.net/policy/nrpm.html#eight3>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.
>
>     Thoughts?  Do you support either or both of these ideas?  Would
>     one or both of them be worth submitting as a policy proposal?
>
>     Thanks,
>     Scott
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131124/dd2c8d75/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bootstrapping_new_entrants_redline_diff.pdf
Type: application/pdf
Size: 93289 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131124/dd2c8d75/attachment-0001.pdf>


More information about the ARIN-PPML mailing list