[arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations
Andrew Dul
andrew.dul at quark.net
Mon Apr 13 11:55:07 EDT 2020
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 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.
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.
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
> 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).
> 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/20200413/b419ea48/attachment.htm>
More information about the ARIN-PPML
mailing list