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 <[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 > > 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 > <[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 <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 ([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. >
_______________________________________________ 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.
