[arin-ppml] Bootstrapping new entrants after IPv4 exhaustion

Sun Nov 24 20:16:52 EST 2013

+1 I strongly agree!

Sent from my iPhone

On Nov 24, 2013, at 5:01 PM, "Andrew Dul" <andrew.dul at quark.net<mailto: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<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<mailto: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<mailto:info at arin.net> if you experience any issues.

<Bootstrapping_new_entrants_redline_diff.pdf>
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto: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/3e6efb1e/attachment.htm>