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

Thu Jan 25 10:17:56 EST 2018

The argument (as I understand it) is comparing justification
required for a transfer vs for ARIN free pool.

If ARIN does not permit a "no justification" approval
for a transfer of a /21 under ISP initial allocation
if they have no direct resources then,

There are extra requirements on transfers that
did not exist on getting that same approval for a /21
from the free pool.

My understanding is that there is a restriction
on the ISP initial allocation from the free pool.
It was show that this is not more than a 90 day
supply.  We changed that to two years.

My understanding is that ISPs with no direct IPv4
didn't get a free pass on the (then) 90 day restriction
when asking for their initial /21.

They got a free pass on demonstrating past utilization.
They got a free pass on starting with slow start at larger
than a /24 if they had some justification that something
larger (up to a /21) was less than a 90 day supply.

___Jason

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

> Jason -
>
>     The policy in question is with regard to transfers, but the
> limitations that you are asking about are with regard to allocations from
> the free pool?
>
>     Could you explain how the information sought is germane to the policy
> discussion regarding this proposed change to IPv4 transfer policy?
>
> Thanks!
> /John
>
> On 24 Jan 2018, at 9:38 AM, Jason Schiller <jschiller at google.com> wrote:
>
> 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 <(571)%20266-0006>
>
>
>

-- 
_______________________________________________________
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/20180125/04c0c20a/attachment.htm>