[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.htm>
-------------- 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.pdf>
More information about the ARIN-PPML
mailing list