[arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

Sun Apr 19 20:55:35 EDT 2020

> On Apr 13, 2020, at 08:55 , Andrew Dul <andrew.dul at quark.net> wrote:
> 
> David, Thanks for your comments.   
> 
> On 3/26/2020 4:08 PM, David Farmer wrote:
>> I support this policy as written. 
>> 
>> However, I recommend a minor editorial change and a small change to the policy;
>> 
>> 1. I would prefer to not use "smaller" or "less" when referring to /24 or longer prefixes, such use is somewhat ambiguous, this has been discussed many times on PPML.
> Noted.
>> 
>> 2. I really like the idea of automatically increasing the IPv6 allocation to /36 when the IPv4 allocation increases beyond /24. How about also automatically increasing the IPv6 allocation to /32 when the IPv4 allocation increases beyond /22?
> The goal of this policy is to create IPv6 allocation sizes such that a current IPv4 organization which is currently 3X-small can obtain an IPv6 allocation without their fees going up.  Today this issue only occurs with 3x-small.  If we were to implement this other change I believe this would cause the text to move beyond the current problem statement.  
> 

I don’t entirely agree. The goal of the /36 policy was very similar to the goal here for /40s. Prior to the implementation of the /36 policy, the situation was similar.

As such, I do think it makes sense to extend the auto-bump language up to /32 as part of this policy. TBH, the only reason it isn’t already there for /36s IMHO is that we didn’t think of it at the time.
> I will also like to note, that this issue could also be remedied by the board adopting a small change to the fee schedule such that the 3x-small IPv6 holdings do not force a change in category for 3x-small organizations. This would cause 3x-small organization's fees to be primarily determined by their IPv4 holdings not their IPv6 holdings.
> 
Yep… And I hope they’ll finally do something about this, but let’s see what happens. I think this policy proposal is a good backstop to that.

> While the community doesn't have purview over fees we have input into that process.  If this is something that we would strongly like to prefer as a solution to this problem.  We can make this as a strong suggestion to the board for their consideration.
> 
I believe this has been communicated to the board on more than one occasion.

Owen

> Andrew
> 
> 
> 
>> 
>> Thanks
>> 
>> On Tue, Mar 24, 2020 at 12:22 PM ARIN <info at arin.net <mailto:info at arin.net>> wrote:
>> Draft Policy ARIN-2020-3: IPv6 Nano-allocations
>> 
>> Problem Statement:
>> 
>> ARIN's fee structure provides a graduated system wherein organizations
>> pay based on the amount of number resources they consume.
>> 
>> In the case of the very smallest ISPs, if a 3X-Small ISP (with a /24 or 
>> smaller of IPv4) gets the present minimal-sized IPv6 allocation (a /36), 
>> its annual fees will double from $250 to $500/year.
>> 
>> According to a Policy Experience Report presented by Registration 
>> Services to the AC at its annual workshop in January 2020, this 
>> represents a disincentive to IPv6 adoption with a substantial fraction 
>> of so-situated ISPs saying "no thanks" and abandoning their request for 
>> IPv6 number resources when informed of the impact on their annual fees.
>> 
>> This can be addressed by rewriting subsection 6.5.2(b). Initial 
>> Allocation Size to allow allocation of a /40 to only the smallest ISPs 
>> upon request, and adding a new clause 6.5.2(g) to cause an automatic 
>> upgrade to at least a /36 in the case where the ISP is no longer 3X-Small.
>> 
>> Reserving /40s only for organizations initially expanding into IPv6 from 
>> an initial sliver of IPv4 space will help to narrowly address the 
>> problem observed by Registration Services while avoiding unintended 
>> consequences by accidentally giving a discount for undersized allocations.
>> 
>> Policy Statement:
>> 
>> Replace the current 6.5.2(b) with the following:
>> 
>> b. In no case shall an LIR receive smaller than a /32 unless they
>> specifically request a /36 or /40.
>> 
>> In order to be eligible for a /40, an ISP must meet the following 
>> requirements:
>>   * Hold IPv4 direct allocations totaling a /24 or less (to include zero)
>>   * Hold IPv4 reassignments/reallocations totaling a /22 or less (to 
>> include zero)
>> 
>> In no case shall an ISP receive more than a /16 initial allocation.
>> 
>> Add 6.5.2(g) as follows:
>> 
>> g. An LIR that requests a smaller /36 or /40 allocation is entitled to 
>> expand the allocation to any nibble aligned size up to /32 at any time 
>> without renumbering or additional justification.  /40 allocations shall 
>> be automatically upgraded to /36 if at any time said LIR's IPv4 direct 
>> allocations exceed a /24. Expansions up to and including a /32 are not 
>> considered subsequent allocations, however any expansions beyond /32 are 
>> considered subsequent allocations and must conform to section 6.5.3. 
>> Downgrades of any IPv6 allocation to less than a /36 are not permitted 
>> regardless of the ISP's current or former IPv4 number resource holdings.
>> 
>> Comments:
>> 
>> The intent of this policy proposal is to make IPv6 adoption at the very 
>> bottom end expense-neutral for the ISP and revenue-neutral for ARIN. The 
>> author looks forward to a future era wherein IPv6 is the dominant 
>> technology and IPv4 is well in decline and considered optional leading 
>> the Community to conclude that sunsetting this policy is prudent in the 
>> interests of avoiding an incentive to request undersized IPv6 allocations.
>> 
>> Timetable for implementation: Immediate
>> 
>> _______________________________________________
>> ARIN-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:
>> https://lists.arin.net/mailman/listinfo/arin-ppml <https://lists.arin.net/mailman/listinfo/arin-ppml>
>> Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.
>> 
>> 
>> -- 
>> ===============================================
>> 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        Phone: 612-626-0815
>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>> ===============================================
>> 
>> 
>> _______________________________________________
>> ARIN-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:
>> https://lists.arin.net/mailman/listinfo/arin-ppml <https://lists.arin.net/mailman/listinfo/arin-ppml>
>> Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.
> 
> _______________________________________________
> ARIN-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:
> https://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/20200419/e913d1d8/attachment.htm>