[arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers

Wed Jan 24 14:38:36 EST 2018

>From the free pool (assuming we had one or the waitlist)

___Jason

On Wed, Jan 24, 2018 at 1:17 PM, John Curran <jcurran at arin.net> wrote:

> Jason -
>
>    Your query below is with regard to ARIN allocations from the free pool,
> or with regard to approval of the transfer of IPv4 number resources?
>
> /John
>
>
> On 24 Jan 2018, at 8:06 AM, Jason Schiller <jschiller at google.com> wrote:
>
> ARIN staff,
>
> After the implementation of 2009-8
> and post  IANA IPv4 depletion
> (say 02/03/2011)
>
> If an ISP wanted more than a 90 day supply would
> that have been limited to only a 90 day supply?
> Is that because of both:
> 4.2.4.3. Subscriber Members Less Than One Year
> 4.2.4.4. Subscriber Members After One Year ?
>
>
> Does that also apply to an ISP asking for IP space
> 4.2.1.6. Immediate Need?
>
> Does that also apply to an ISP asking for IP space
> 4.2.1.4. Slow start?
>
> Does this also apply to ISP asking for IP space
> under 4.2.2. Initial allocation to ISPs?
>
>
> After the implementation of 2013-7
> (say September 2014)
>
> Did any of this change?
>
> Did 4.2.4.3 Request size simply
> replace 4.2.4.3 and 4.2.4.4 and
> do essentially the same limit?
>
> After the implementation of 2016-4
> (say March 2017)
>
> Did any of this change?
> Is that because of 4.2.4.3 Request size
> still limits the maximum an ISP can get?
>
> Then after 2016-2
> (say April 20, 2017)
>
> Would all of the above change to a 2 year supply?
>
>
> Owen,
>
> responses in line
>
> __Jason
>
> On Wed, Jan 24, 2018 at 10:38 AM, Owen DeLong <owen at delong.com> wrote:
>
>> While there’s some truth to that, it was also the reality under which we
>> operated when that /21 was coming from the free pool rather than from the
>> transfer market.
>>
>> Admittedly, the price penalty was a bit higher because that was under an
>> older fee structure which had higher prices for ISPs, but, as the old
>> Churchill joke ends… “Madam, the first question established what you are,
>> now we are merely haggling over price.”
>>
>> So, given that, do you really believe we need to place additional limits
>> on transfers that didn’t exist on the free pool?
>>
>
> I don't believe this limit is new or additional...
> My understanding of the policy that existed between 09/18/2012 and
> 04/20/2017
> was that an ISP could only get a 3 month supply of addresses.
>
> This was established under 2009-8 (01/13/2010 and triggered 02/03/2011)
> and modified by 2016-2 (04/20/2017)
>
> https://www.arin.net/vault/announcements/2011/20110203.html
> https://www.arin.net/resources/request/ipv4_countdown_plan.html
>
> Post 04/20/2017, and ISP can only get a 2 year supply.
>
> I believe you need to show that the initial /21 you are asking for is a
> 90 day supply or less during the 09/2010-04/2012 time period, which
> subsequently reverted to a two year window.
>
> Hopefully staff questions above will clarify this.
>
> At the very least it was never my expectation that passing 2016-4
> would exclude the initial /21 from needing to meet the requirement
> of 4.2.2.1.3. Three Months.
>
>
>>
>> Also, even with the /24 limit, under current policy, they can immediately
>> turn around, claim they’ve used that /24 and with officer attestation get
>> an additional /23, then turn around again and get an additional /22 which
>> would leave them only 1 /24 short of a /21 (which they could turn around
>> and immediately obtain unto an additional /21 under the same policy). So we
>> essentially already allow this transaction, but the question is how many
>> hoops do we want to add to the process.
>>
>>
> Assuming there is no fraud in the transaction you describe, then
> they would essentially be doing slow start.
> Get a block press it into service, show it is being used, and double.
>
> That is exactly how it is supposed to work.
> That is exactly what we did under slow start with no history of use:
> 1. get a /24 (or more up to a /21 from an upstream) show it is being used,
> 2. trade it out for ARIN space that replaces, and doubles the size
> 3. re number into the new space
> 4. press the unused new space into service
> 5. double you previous allocation if you do it in less than half the 90
> day window
> 6. get the same size as your previous allocation if you do it in less that
> 90 days
> 7. fall back to a smaller next allocation if you do it in more than 90
> days.
>
> The transfer version is more liberal in that it allows a straight doubling
> of all
> your holdings as opposed to only your last allocation doubling, and there
> is
> no time horizon, you can double even if it take you 3 years to press your
> address space into service.
>
> So, less silly than slow start with a 1 year window, and much less silly
> than
> slow start with a 3 month window.
>
>
>
>> I’m usually the one on the other side of this argument, but under the
>> current circumstances, even I think it’s kind of silly.
>>
>>
> What am I missing?  What is so silly with this approach?
>
>
>> Owen
>>
>> On Jan 24, 2018, at 7:17 AM, Jason Schiller <jschiller at google.com> wrote:
>>
>> I oppose.
>>
>> 2016-4 was an attempt to replace the slow-start boot strap of get a /24
>> (or more)
>> from your upstream, put it into use, then use that to qualify to get your
>> own IP space from ARIN.
>>
>> The transfer slow-start boot strapping is to give the first /24 with no
>> justification,
>> put it to use, then double (just as you did under slow start).
>>
>> Essentially changing this to a /21 allows roughly 80% of ARIN members
>> to be able to get all the IPv4 address space they could even need with
>> no justification if they are willing to call themselves an ISP, and pay
>> the
>> appropriate fees.
>>
>> I oppose a non-needs based (or simply put a money based) justification
>> system on the grounds that does not provide IP addresses to those who need
>> them, but rather to those who are more willing to spend, favoring
>> services that
>> generate the most revenue per IP.
>>
>> I even more strongly oppose a non-needs based justification that only
>> benifits
>> some small portion of the community.  This proposal is essentially a
>> non-needs
>> based justification for anyone who needs a /21 or less and is willing to
>> pay an
>> extra $400 annually for up to a /22 or, and extra $900 annually for up to
>> a /21.
>>
>>
>> Under NRPM version 2016.2 - 13 July 2016
>> https://www.arin.net/vault/policy/archive/nrpm_20160713.pdf
>>
>> For an ISP request for ARIN IP space, 4.2.2.1.1 required them to
>> show utilization of currently held IPv4 space.
>>
>> 1. They could use the utilization of their provider's /24 along with
>> the promise of renumbering to justify getting their own /24
>>
>> An ISP could meet the 4.2.2.1.1 demonstration of utilization and
>> get additional space by showing the 3 month growth projection under
>> 4.2.2.1.3.
>>
>> (replacing their provider supplied addressing can be
>> included in the ask if they promose to return under 4.2.2.1.4)
>>
>> Or doubling under slow start 4.2.1.4.
>>
>>
>> 2016-4 came along to remove the need to get IPs from your upstream.
>>
>> https://www.arin.net/policy/proposals/2016_4.html
>>
>>
>> Replace Section 4.2.2 with:
>>
>> 4.2.2. Initial allocation to ISPs
>>
>> "All ISP organizations without direct assignments or allocations from
>> ARIN
>> qualify for an initial allocation of up to a /21, subject to ARIN's
>> minimum allocation size. Organizations may qualify for a larger initial
>> allocation by documenting how the requested allocation will be utilized
>> within 24 months for specified transfers, or three months otherwise.
>> ISPs renumbering out of their previous address space will be given a
>> reasonable amount of time to do so, and any blocks they are returning
>> will not count against their utilization."
>>
>> At that time the difference between ARIN IP space was a 90 day supply
>> versus a two tear supply on the transfer market.
>>
>> It also seemingly removed the following sections:
>> 4.2.2.1. ISP Requirements
>> 4.2.2.1.1. Use of /24
>> 4.2.2.1.2. Efficient Utilization
>> 4.2.2.1.3. Three Months
>> 4.2.2.1.4. Renumber and Return
>>
>> It was my impression that ARIN would not issue a /21 if it was more than
>> a 90 day
>> supply.
>>
>> 2016-2 came along and changes the time frame to sync pre-approval for
>> transfers
>> and approval for the waiting list.
>>
>> It seeming updates the non-existant section 4.2.2.1.3 from 3 months to 24.
>> and 4.2.4.3 to 24 months.
>>
>> This is what creates the problem where now an initial ISP can request a
>> /21
>> without requiring
>>
>> I do not believe the intent was to give ISPs a /21 even if it is larger
>> than a, then
>> 90 day, or now two year supply.  I suggest that if more than a /24 is
>> desired, they can get up
>> to a /21 if it is less than a 2 year supply, and subsequently need to
>> show utilization.
>> That means a /21 is not entirely justification free like the /24 is.
>>
>> __Jason
>>
>>
>>
>>
>>
>>
>> On Mon, Jan 22, 2018 at 6:35 PM, Owen DeLong <owen at delong.com> wrote:
>>
>>> Fully support the direction you are now taking this.
>>>
>>> Owen
>>>
>>> On Jan 20, 2018, at 9:16 AM, David Farmer <farmer at umn.edu> wrote:
>>>
>>> I think the burden is the potential to have to rejustify an ISP's
>>> initial allocation when being fulfilled by transfer.  The
>>> inconsistency seems inefficient and creates confusion; there appears to
>>> be support for eliminating the inconsistency.  With slightly more support
>>> for changing section 8 to be consistent with section 4, rather than the
>>> other way around.
>>>
>>> On Thu, Jan 18, 2018 at 6:07 PM, Scott Leibrand <scottleibrand at gmail.com
>>> > wrote:
>>>
>>>> Quoting myself:
>>>>
>>>> If there are organizations transferring blocks larger than a /24 for
>>>> whom officer-attested justification is burdensome (to them or to ARIN) I’d
>>>> like to understand what is burdensome, so we can figure out how to reduce
>>>> that burden. If not, then implementing section 8 as written seems
>>>> appropriate until we identify a reason to change it.
>>>>
>>>>
>>>> Do you know of any organizations transferring blocks larger than a /24
>>>> for whom officer-attested justification is burdensome (to them or to ARIN)?
>>>>
>>>> Scott
>>>>
>>>
>>> --
>>> ===============================================
>>> David Farmer               Email:farmer at umn.edu
>>> Networking & Telecommunication Services
>>> Office of Information Technology
>>> University of Minnesota
>>> 2218 University Ave SE
>>> <https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g>
>>>       Phone: 612-626-0815 <(612)%20626-0815>
>>> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
>>> ===============================================
>>>
>>>
>>>
>>> _______________________________________________
>>> 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.
>>>
>>
>>
>>
>> --
>> _______________________________________________________
>> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
>> <(571)%20266-0006>
>>
>>
>>
>
>
> --
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-0006>
>
> _______________________________________________
> 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.
>
>
>

-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20180124/82bb55a3/attachment.htm>