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

[ARIN]

All,

This previous message did not include the correct Recommended Draft 
Policy status of ARIN-2020-3.

To be clear, this is a Recommended Draft Policy with a completed Staff 
and Legal Review, visible at:

https://www.arin.net/participate/policy/drafts/2020_3/

As always you are encouraged to discuss all Draft and Recommended Draft 
Policies to inform Advisory Council decision making.

Regards,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)



On 8/18/20 5:57 PM, 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
> 
> AC Assessment of Conformance with the Principles of Internet Number 
> Resource Policy:
> 
> Recommended Draft Policy ARIN-2020-3 provides for small IPv6 allocations 
> to ISPs. This policy would allow the smallest ISP organizations to 
> obtain a /40 of IPv6 addresses. This recommended draft is technically 
> sound, supported by the community and enables fair and impartial 
> administration of number resources by providing the smallest 
> organizations the opportunity to obtain an IPv6 allocation without a fee 
> increase under the current fee schedule.
> 
> 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. 
> Partial returns of any IPv6 allocation that results in less than a /36 
> of holding are not permitted regardless of the ISP’s current or former 
> IPv4 number resource holdings.
> 
> Timetable for Implementation: Immediate
> 
> 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: ImmediateARIN’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.
> 
> 
>