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

Fri Aug 22 11:13:00 EDT 2025

Might help to put the glasses on. :-)

We’re still spending too much time on this minor change and we should just
get it over with.

I’m a plus one for proceeding with the Mathematical fix and updating the
text to make sure it matches, including using subscript for log base two.

+1

On Fri, Aug 22, 2025 at 10:59 Martin Hannigan <hannigan at gmail.com> wrote:

>
> 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/23633026/attachment-0001.htm>