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

[hostmaster at uneedus.com]

I am in favor of the proposal, as I think it is wrong to double someones 
fees simply for having the minimum amount of IPv6 while holding the 
minimum amount of IPv4. It appears that many at this level are currently 
saying no to IPv6 rather than have their fees double.  ARIN should not 
have a policy that prevents IPv6 adoption by more fees for having it.

Rather than giving out /40's, I would also not have an issue of giving 
them a /36 but not changing their fees because of the addition of IPv6.

As for 40,000 IPv6 customers on a /40, nothing in ARIN policy prevents 
assigning /56's or even less at this level or even at a higher level than 
3Xsmall. There are even operators that only provide a /64 to each node.

I know many operators that give out /60's or /56's by default and do not 
provide a /48 except upon request.  Some smarter ones actually do sparse 
allocation of these smaller sizes, so they can be expanded to /48 when a 
request is made.

However, if such an ISP, who must use CGnat with that /24 in order to 
serve more than 250 customers with IPv4 is going to effectively become an 
IPv6 only ISP, since 40,000 customers behind CGnat on a /24 is not 
workable at any real load.

I feel strongly about IPv6 adoption that 40,000 IPv6 customers on a /40 
would not give me heartburn. However, this ISP would likely go broke from 
the CGnat and the associated logging required by CALEA in order to offer 
any IPv4 access. Their ARIN fees seem very small by comparison.  On the 
other hand, if they can make money by offering IPv6 only access, a plan 
with 40,000 customers would be easy to do. However, I think it would be 
hard to sell an IPv6 only ISP until IPv6 adoption is higher.  Maybe a 
streaming device plan, since most of those have IPv6 currently in place.

In other words, it is not likely to happen because of the issues of CGnat 
combined with the current lack of a market for IPv6 only ISP's.

Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Tue, 23 Jun 2020, John Santos wrote:

> 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
>
> _______________________________________________
> 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.
>