+1 Leif's recommended wording. — Brian bjo...@vt.edu
On Tue, Jul 21, 2020 at 12:34 PM Leif Sawyer <lsaw...@gci.com> wrote: > "Partial returns of any IPv6 allocation that results in less than a /36 of > holding are not permitted, [...]" > > > This would seem to address Albert's issue, and remove the uncertainty of > "downgrade" while allowing for a "complete return" of IPv6 space. > > > > *Leif Sawyer* > *GCI* | Enterprise Security Architect > *t:* 907-868-0116 | *w:* *www.gci.com* <https://www.gci.com> > > > > ------------------------------ > *From:* ARIN-PPML <arin-ppml-boun...@arin.net> on behalf of > hostmas...@uneedus.com <hostmas...@uneedus.com> > *Sent:* Tuesday, July 21, 2020 8:10 AM > *To:* Rob Seastrom > *Cc:* arin-ppml@arin.net > *Subject:* Re: [arin-ppml] Recommended Draft Policy ARIN-2020-3: IPv6 > Nano-allocations > > [*EXTERNAL EMAIL* - CAUTION: Do not open unexpected attachments or links.] > > 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, hostmas...@uneedus.com 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 (ARIN-PPML@arin.net). > >>> Unsubscribe or manage your mailing list subscription at: > >>> https://lists.arin.net/mailman/listinfo/arin-ppml > >>> Please contact i...@arin.net if you experience any issues. > >> _______________________________________________ > >> ARIN-PPML > >> You are receiving this message because you are subscribed to > >> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> https://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact i...@arin.net if you experience any issues. > > > > > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. >
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.