[arin-ppml] Draft Policy ARIN-2025-6: Fix formula in 6.5.2.1c

Fri Aug 22 10:59:02 EDT 2025

We’ve been working on what amounts to an editorial change for 15 months.
Someone should just make a decision.

HTH,

-M<

On Fri, Aug 22, 2025 at 10:31 Kat Hunter <takokat81 at gmail.com> wrote:

> There were a lot of questions during our meeting from the advisory council
> and at the June NANOG from members that received v6 space and did not use
> the formula at all when requesting IP space. They followed the text
> requirements. (as the formula was off anyway) Staff has stated they use the
> text only. Is the formula necessary? I'd be curious what the community
> thinks given it isn't being used. Could we just eliminate the formula?
>
> Kat Hunter
> AC Chair
>
> On Fri, Aug 22, 2025 at 5:03 AM Owen DeLong via ARIN-PPML <
> arin-ppml at arin.net> wrote:
>
>> I don’t think the formula is particularly difficult to understand once it
>> is corrected, and I’d argue that change could go via the editorial process
>> since it amounts to correcting a typo. Admittedly it’s a mathematical typo,
>> but it’s an obvious error (confirmed by the author even) with an obvious
>> correction.
>>
>> Owen
>>
>>
>> > On Aug 21, 2025, at 14:38, William Herrin <bill at herrin.us> wrote:
>> >
>> > Hi Folks,
>> >
>> > I have three followup questions for you on the proposal to correct the
>> > formula used to determine the maximum qualification for ISP IPv6
>> > addresses.
>> >
>> >> From the current PPML discussion, it sounds like folks agree that the
>> > revised formula correctly aligns with the text. Does anyone disagree?
>> >
>> > There's a misalignment between the terms "provider allocation unit" in
>> > NRPM 6.5.2.1c and "provider assignment unit" in 2.15 and 2.16. As far
>> > as I can tell, these are the only places in the NRPM that either term
>> > is used. One of these should be changed to match the other so that
>> > folks trying to understand 6.5.2.1.c can actually find the term's
>> > definition. Does anyone have a preference for which?
>> >
>> > Now the big question: if we don't abandon it for non-interest, there
>> > are probably three ways we can proceed with this proposal:
>> >
>> > 1. Change the formula as proposed.
>> >
>> > 2. Drop the formula and rely on the now-identical text.
>> >
>> > 3. Drop the formula and rewrite the text for clarity, without changing
>> > the formula the text describes.
>> >
>> > Option 1 makes the minimum change to the policy, but leaves behind a
>> > formula that may be difficult to understand.
>> >
>> > Option 3 theoretically leaves IPv6 allocation and the NRPM in more
>> > comprehensible state, but it would require the largest change to the
>> > policy text and carries a risk of unintentionally changing what the
>> > policy calls for.
>> >
>> > What are your thoughts on the best choice here?
>> >
>> > Regards,
>> > Bill Herrin
>> >
>> >
>> >> On Wed, Jul 2, 2025 at 2:53 PM William Herrin <bill at herrin.us> wrote:
>> >>
>> >>> On Tue, Jul 1, 2025 at 11:34 AM ARIN <info at arin.net> wrote:
>> >>> Draft Policy ARIN-2025-6: Fix formula in 6.5.2.1c
>> >>>
>> >>> Problem Statement:
>> >>>
>> >>> Sections 6.5.2.1 explains the initial IPv6 ISP/LIR allocation in a
>> way that is difficult to follow and the formula in section (c) does not
>> match the remainder of the text.
>> >>>
>> >>> Policy Statement:
>> >>>
>> >>> In 6.5.2.1c, replace:
>> >>>
>> >>> "This calculation can be summarized as /N where N = P-(X+Y) and P is
>> the organization’s Provider Allocation Unit X is a multiple of 4 greater
>> than 4/3*serving sites and Y is a multiple of 4 greater than 4/3*end sites
>> served by largest serving site."
>> >>>
>> >>> with:
>> >>>
>> >>> "This calculation can be summarized as /N where N = P-(X+Y) and P is
>> the organization’s Provider Allocation Unit, X is a multiple of 4 greater
>> than 4/3*log_2(serving sites) and Y is a multiple of 4 greater than
>> 4/3*log_2(end sites served by largest serving site).
>> >>
>> >>
>> >> FYI, I'm the primary Advisory Council shepherd for this draft policy.
>> >> Here's some explanation:
>> >>
>> >> Section 6.5.2.1c holds the criteria for the _maximum_ initial IPv6
>> >> allocation for ISPs. They qualify for the number of IPv6 addresses
>> >> described here and may request that much or a smaller block. The
>> >> section is frankly hard to read. Here's what that part of the NRPM
>> >> currently says:
>> >>
>> >> "c. The maximum allowable allocation shall be the smallest
>> >> nibble-boundary aligned block that can provide an equally sized
>> >> nibble-boundary aligned block to each of the requesters serving sites
>> >> large enough to satisfy the needs of the requesters largest single
>> >> serving site using no more than 75% of the available addresses.
>> >> This calculation can be summarized as /N where N = P-(X+Y) and P is
>> >> the organization’s Provider Allocation Unit X is a multiple of 4
>> >> greater than 4/3*serving sites and Y is a multiple of 4 greater than
>> >> 4/3*end sites served by largest serving site.
>> >>
>> >> d. For purposes of the calculation in (c), an end site which can
>> >> justify more than a /48 under the end-user assignment criteria in
>> >> 6.5.8 shall count as the appropriate number of /48s that would be
>> >> assigned under that policy.
>> >>
>> >> e. For purposes of the calculation in (c), an LIR which has
>> >> subordinate LIRs shall make such reallocations according to the same
>> >> policies and criteria as ARIN. In such a case, the prefixes necessary
>> >> for such a reallocation should be treated as fully utilized in
>> >> determining the block sizing for the parent LIR. LIRs which do not
>> >> receive resources directly from ARIN will not be able to make such
>> >> reallocations to subordinate LIRs and subordinate LIRs which need more
>> >> than a /32 shall apply directly to ARIN."
>> >>
>> >>
>> >> Here's how ARIN staff explained the current implementation of NRPM
>> 6.5.2.1c:
>> >>
>> >> "ARIN staff implements 6.5.2.1.c based on the text. The summarized
>> >> formula is overly complex and inaccurate for your typical IPv6
>> >> requestor. The text alone is more easily understood by customers and
>> >> implemented by ARIN staff.
>> >>
>> >> ARIN staff calculates Initial allocation sizes by verifying how many
>> >> serving sites the ISP has in the ARIN region, and how many customers
>> >> are served at the largest serving site. ARIN assumes each customer
>> >> will receive a /48 for simplicity and to promote IPv6 transition.
>> >>
>> >> Once the sites and customers are provided by the requestor, ARIN staff
>> >> confirms what size is justified at the largest serving site based on
>> >> the 75% rule. That size is applied to all sites, then checked against
>> >> the 75% rule for the overall allocation justified by the ISP. The ISP
>> >> can opt to request a smaller size. They are not required to request
>> >> the largest justified size, though it is recommended to avoid future
>> >> renumbering.
>> >>
>> >> For example:
>> >> An ISP has 7 sites and 30,000 customers at the largest site.
>> >>
>> >> ARIN assumes each of the 30,000 customers receives a /48. There are
>> >> only 4,096 /48s in a /36, so a /36 is too small. The next
>> >> nibble-boundary aligned subnet is a /32 which has 65,536 /48s. 30,000
>> >> is less than 75% of 65,536, so the ISP’s largest serving site
>> >> justifies a /32.
>> >>
>> >> Thus, each of the 7 sites receives a /32. The next nibble-boundary
>> >> after /32 is a /28. There are 16 /32s in a /28. 7 /32s of the total 16
>> >> /32s is less than 75%, so the organization justifies a total
>> >> allocation of a /28. 7 /32s for immediate allocation to each of their
>> >> 7 sites and 9 additional /32s for future growth.
>> >>
>> >> Example 2:
>> >>
>> >> Building off the previous example, if the largest serving site had
>> >> 60,000 customers, then a /32 would be too small. 60,000 is greater
>> >> than 75% of the available 65,536 /48s in a /32. The next
>> >> nibble-boundary aligned subnet is a /28, so the largest serving site
>> >> justifies a /28. Thus, each of the 7 sites receives a /28, so the
>> >> organization justifies a /24."
>> >>
>> >>
>> >> Regards,
>> >> Bill Herrin
>> >>
>> >> --
>> >> William Herrin
>> >> bill at herrin.us
>> >> https://bill.herrin.us/
>> >
>> >
>> >
>> > --
>> > William Herrin
>> > bill at herrin.us
>> > https://bill.herrin.us/
>> > _______________________________________________
>> > 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/20250822/67094d21/attachment.htm>