[arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations
David Farmer
farmer at umn.edu
Thu Mar 26 19:08:30 EDT 2020
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.
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?
Thanks
On Tue, Mar 24, 2020 at 12:22 PM ARIN <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).
> 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.
>
--
===============================================
David Farmer Email:farmer 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
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20200326/8417a40e/attachment.htm>
More information about the ARIN-PPML
mailing list