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

Andrew Dul andrew.dul at quark.net
Wed Apr 15 11:30:26 EDT 2020


John,

Could you provide the community with a rough magnitude of this issue? 

Approximately how many of these 3x-small ISP organizations have come to
ARIN and requested IPv6?  How many accepted the block and how many
refused because of the fee issue?  How many 3x-small ISP organizations
does ARIN currently serve.

Thanks,
Andrew

On 4/14/2020 2:29 PM, John Sweeting wrote:
> All,
>
> For anyone interested in the content of the "Policy Experience Report presented by Registration 
> Services to the AC at its annual workshop in January 2020" referenced in the problem statement you can see that report here:
>
> https://www.arin.net/about/welcome/ac/meetings/2020_0124/policy_experience_report.pdf
>
> Thank you.
>
> On 3/24/20, 1:22 PM, "ARIN-PPML on behalf of ARIN" <arin-ppml-bounces at arin.net on behalf of info at arin.net> wrote:
>
>     On 19 March 2020, the ARIN Advisory Council (AC) accepted 
>     "ARIN-prop-285: IPv6 Nano-allocations" as a Draft Policy.
>     
>     Draft Policy ARIN-2020-3 is below and can be found at:
>     
>     https://www.arin.net/participate/policy/drafts/2020_3/
>     
>     You are encouraged to discuss all Draft Policies on PPML. The AC will 
>     evaluate the discussion in order to assess the conformance of this draft 
>     policy with ARIN's Principles of Internet number resource policy as 
>     stated in the Policy Development Process (PDP). Specifically, these 
>     principles are:
>     
>     * Enabling Fair and Impartial Number Resource Administration
>     * Technically Sound
>     * Supported by the Community
>     
>     The PDP can be found at:
>     https://www.arin.net/participate/policy/pdp/
>     
>     Draft Policies and Proposals under discussion can be found at:
>     https://www.arin.net/participate/policy/drafts/
>     
>     Regards,
>     
>     Sean Hopkins
>     Policy Analyst
>     American Registry for Internet Numbers (ARIN)
>     
>     
>     
>     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.
>     
>
> _______________________________________________
> 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.




More information about the ARIN-PPML mailing list