[arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations
Owen DeLong
owen at delong.com
Mon Apr 13 23:48:19 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.
Yes, though I’m not 100% sure that the conversation settled on consensus for those particular approaches.
Personally, I think that when we are discussing amount of address space, we should use “More than”, “Less than”, “Larger than”, “Smaller than”, and refer not to “/24”, but “equivalent of /24” or “/24 equivalent(s)”.
However, when we are specifically talking about prefix length (i.e. exactly a specific prefix, not some collection of 1 or more blocks adding up to X amount of address space), we should use the terms “longer” or “shorter” (e.g. "The longest prefix ARIN will issue in IPv4 is a /24”, “Requests for IPv6 prefixes shorter than /16 will be treated as multiple /16s”).
>> 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 think this is actually a good idea. I suggest checking with RS on whether he’s amenable to amending the problem statement.
If not, I will work with David off line to create a second proposal to address this issue. The reason we have /36s in the first place is sort of the next rung up of the same problem, so applying the same automation to that situation really does make a lot of sense and, in my mind is within scope of the spirit of the problem statement, even if not within the letter of the law for same.
> 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.
>
We/ve tried to ask the board to take this approach in the past with zero success.
> 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.
>
Mr. Quixote, Windmill… Windmill, Mr. Quixote.
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 <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20200413/e4b0a568/attachment.htm>
More information about the ARIN-PPML
mailing list