I would support either your suggestion or Leif’s.

Thank you for your thoughts!

-r


> On Jul 21, 2020, at 12:10 PM, [email protected] wrote:
> 
> How about "Downgrades of any IPv6 allocation to less than a /36 OTHER THAN A 
> RETURN OF ALL IPv6 RESOURCES are not permitted regardless of the ISP’s 
> current or former IPv4 number resource holdings."
> 
> At least this avoids the "Hotel California" issue.
> 
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
> 
> 
> On Tue, 21 Jul 2020, Rob Seastrom wrote:
> 
>> 
>> Hi Albert,
>> 
>> As a practical matter, I don’t think the NRPM overrides your ability to 
>> terminate your contract with ARIN should that become a business requirement.
>> 
>> Do you have alternative language to suggest that is clear, concise, and 
>> preserves the intent of narrowly boxing in nano-allocations for the tiniest 
>> of providers with IPv4 rather than incenting undersizing IPv6 allocations?  
>> Remember that the whole reason for the default /32 allocation is that we 
>> wish for IPv6 allocations to be the polar opposite of IPv4 slow-start - a 
>> one-and-done approach that minimizes both unnecessary routing table growth 
>> and the need to come back to ARIN for more space.
>> 
>> Thanks,
>> 
>> -r
>> 
>> 
>> 
>> 
>>> On Jul 21, 2020, at 11:26 AM, [email protected] wrote:
>>> 
>>> I have a problem with this language:
>>> 
>>> "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."
>>> 
>>> Downgrades include in my mind a return, and thus a downgrade to 0.  This 
>>> language seems to lock in anyone who has ever requested IPv6 space.
>>> 
>>> Does this make a request for IPv6 space from ARIN like the Hotel 
>>> California, where you can never leave....
>>> 
>>> If I were one of those ISP's with a /24 of IPv4, and I took the minimum 
>>> allocation of IPv6 which raised my fees to $500 from $250, does this 
>>> language make me continue to pay $500/yr even if I decide to return all my 
>>> IPv6 resources to ARIN, and either get IPv6 space from my upstream or forgo 
>>> use of IPv6?
>>> 
>>> Albert Erdmann
>>> Network Administrator
>>> Paradise On Line Inc.
>>> 
>>> 
>>> On Tue, 21 Jul 2020, ARIN wrote:
>>> 
>>>> On 16 July 2020, the ARIN Advisory Council (AC) advanced the following 
>>>> Draft Policy to Recommended Draft Policy status:
>>>> 
>>>> ARIN-2020-3: IPv6 Nano-allocations
>>>> 
>>>> The text of the Recommended Draft Policy is below, and may also be found 
>>>> at:
>>>> 
>>>> https://www.arin.net/participate/policy/drafts/2020_3/
>>>> 
>>>> You are encouraged to discuss all Recommended Draft Policies on PPML prior 
>>>> to their presentation at the next ARIN Public Policy Consultation (PPC). 
>>>> PPML and PPC discussions are invaluable to the AC when determining 
>>>> community consensus.
>>>> 
>>>> 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
>>>> 
>>>> 
>>>> 
>>>> Recommended 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. 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> _______________________________________________
>>>> ARIN-PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List ([email protected]).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> https://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact [email protected] if you experience any issues.
>>> _______________________________________________
>>> ARIN-PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List ([email protected]).
>>> Unsubscribe or manage your mailing list subscription at:
>>> https://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact [email protected] if you experience any issues.
>> 

_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.

Reply via email to