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

Wed Jul 22 16:37:32 EDT 2020

+1 Leif's recommended wording.
—
Brian
bjones at vt.edu

On Tue, Jul 21, 2020 at 12:34 PM Leif Sawyer <lsawyer at 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-bounces at arin.net> on behalf of
> hostmaster at uneedus.com <hostmaster at uneedus.com>
> *Sent:* Tuesday, July 21, 2020 8:10 AM
> *To:* Rob Seastrom
> *Cc:* arin-ppml at 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, hostmaster at 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 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.
> >> _______________________________________________
> >> 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.
> >
> >
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20200722/582c60e5/attachment.htm>