On Nov 24, 2013, at 1:52 PM, Andrew Dul <[email protected]> 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 > Yes, but it limits that use to strictly transitional technology deployment, not general IPv4 utilization. > The attached redline is Scott's version just formatted with revisions inline, > which was helpful to me in considering what Scott was proposing. > Thanks for the redline… These are very useful. Owen > 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 <[email protected]> >> 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 <[email protected]> >> Date: Thu, Nov 21, 2013 at 3:03 PM >> Subject: Bootstrapping new entrants after IPv4 exhaustion >> To: ARIN-PPML List <[email protected]> >> >> >> 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). >> >> 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 and 4.3.2 >> (and would allow removal of NRPM 4.9 as redundant.) >> >> Before the implementation of CIDR, many /24 allocations were made to >> organizations that are no longer using them. Current ARIN transfer policy >> 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 ([email protected]). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact [email protected] 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 ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues.
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
