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

Fri Aug 22 05:02:54 EDT 2025

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.