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

Wed Jan 24 13:17:24 EST 2018

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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:Email%3Afarmer 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<tel:(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952<tel:(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<mailto: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<mailto:info at arin.net> if you experience any issues.

--
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com<mailto:jschiller at google.com>|571-266-0006<tel:(571)%20266-0006>

--
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com<mailto:jschiller at google.com>|571-266-0006

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20180124/ea84d80c/attachment.htm>