FWIW, I prefer the language proposed by Leif. Owen
> On Jul 21, 2020, at 10:27 , Rob Seastrom <[email protected]> wrote: > > > 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. _______________________________________________ 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.
