On Nov 22, 2013, at 5:05 PM, Scott Leibrand <[email protected]> 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. > Given that the minimum you can transfer is a /24, I really think that allowing anyone to get a minimum assignment through the transfer process is necessary. > 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. I believe that effort is underway in policy that was on the agenda for yesterdays AC call. I will refrain from prematurely publishing the outcome of that discussion here. Owen > > 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.
