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

[John Santos]

While I support this in principle, what is to prevent someone from violating the 
intent by getting a /40 and assigning /56's to 40,000 customers, instead of 
/48's to no more than 250 customers?


On 6/23/2020 10:24 AM, ARIN wrote:
> The following Draft Policy has been revised:
>
> * ARIN-2020-3: IPv6 Nano-allocations
>
> Revised text 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 ISP registration services fee structure has graduated fee categories 
> based upon the total amount of number resources held within the ARIN registry.
>
> 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.1(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.1(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.1(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.1(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.

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539