Before we started mucking around with lowering the minimum size block, it was a /20 for ISPs (/22 for multi-homed ISPs). /20 became the defacto ISP slow start. Post 2014-13, it was reduced for to a /24 as the minimum for ISPs, but the slow start initial block was between a /24 and a /20 at the ISP's request.
For end users it was /20 or /24 for multi-homed. https://www.arin.net/policy/proposals/2014_13.html Slow start of between /24 and /20 is consistent with automatic transfer pre-approval for ISPs holding no IPv4 addresses, or for ISPs whose IPv4 holding are at or above 80% used, and have no previous history in the past year to support a larger transfer. We have never had a slow start for end-users, but could imagine a block between /24 and /22 as the right size based on the fact that most assignments are within that size, and it lines up with other region's soft landing. Anti 2 year flip / revert to ARIN free pool is a good provision. I have a few more thoughts for this policy. 1. At any time, an org can opt to revert back to justified need based on their past 3-12 months (the org chooses the window size) run rate they can get a two year supply. [this is useful for orgs growing at faster than the slow start size] 2. Orgs disolved due to corporate restructuring less than 24 months after creation can keep their IP space if they meet traditional needs justification. ___Jason On Wed, Sep 30, 2015 at 10:42 PM, Owen DeLong <[email protected]> wrote: > Dani, > > In fairness to Bill, I think he may also have chosen them because I > suggested that those would be boundaries I would consider livable. > > I believe they represent a good size to guarantee that small organizations > are not shut out of the transfer market based on size, but still ensure > that need assessment is preserved in order to prevent acquisition of > addresses without intended use thereof. > > While a /20 is a fair quantity of addresses (4096), it’s a pretty small > number of customers for an ISP in most cases and I think anything smaller > would be somewhat punitive. > > It does also line up well with transfer history and other ARIN data about > small-ish organizations and address issuance over the last several years. > > Owen > > On Sep 30, 2015, at 03:52 , Dani Roisman <[email protected]> wrote: > > Hi Bill, > > I’m interested to learn how you came up with the below proposed netblock > sizes “/20 if a ISP or /22 for an end user” ? Is there data behind that? > If not, does it make sense to ask ARIN to supply data regarding sizes of > transfers which have occurred in the past 12 - 18 months? > > -- > Dani Roisman > > ________________________________ > From: "Bill Buhler" <[email protected]<mailto:[email protected]>> > To: "owen" <[email protected]<mailto:[email protected]>> > Cc: [email protected]<mailto:[email protected]> > Sent: Monday, September 28, 2015 12:59:30 PM > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based > evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > OK, how about this: > > Small end users and ISPs are allowed to obtain IPv4 address blocks without > a needs test as long as the following criteria are met: > > > a. The total size of their ARIN allocations at any time of the > process does not exceed a /20 if a ISP or /22 for an end user. > > b. They cannot purchase IP address from the transfer market more than > three total times to reach this size, including the initial operation. > > c. None of the addresses purchased can be transferred to any other > entity for twenty-four months following the date of the last transfer. > > d. If the company ceases operations within the twenty-four month > window the addresses are automatically transferred to the ARIN free pool. > After that period of time regular transfer rights exist. > > e. All subsequent allocations / transfers require regular needs > testing after the initial twenty-four month allocation window. > > f. Eligible entities for this policy consist of ISPs and End users > who have a unique physical address in the ARIN region at the suite level. > Meaning if two companies share the same suite they are not eligible to both > have ARIN allocations. > > ------------------- > > I believe that meets all of your concerns. I would prefer companies get > everything they think they will need in one operation, but I don?t want to > have fear drive them into buying the max amount just in case. > > Best regards, > > Bill Buhler > > _______________________________________________ > 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. > -- _______________________________________________________ Jason Schiller|NetOps|[email protected]|571-266-0006
_______________________________________________ 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.
