[arin-ppml] Bootstrapping new entrants after IPv4 exhaustion

Mon Nov 25 16:48:28 EST 2013

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.

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?

Thanks,
Scott

On Sun, Nov 24, 2013 at 1:52 PM, Andrew Dul <andrew.dul at quark.net> wrote:

>  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>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
>>
>>
>
>
> _______________________________________________
> 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.
>
>
>
> _______________________________________________
> 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/20131125/e0839fe2/attachment.htm>