[arin-ppml] Bootstrapping new entrants after IPv4 exhaustion

[Scott Leibrand]

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>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>
> 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>
>
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131122/5235fb7d/attachment.htm>