<div dir="ltr">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? <div><br></div><div>Kat Hunter</div><div>AC Chair</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Aug 22, 2025 at 5:03 AM Owen DeLong via ARIN-PPML <<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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. <br>
<br>
Owen<br>
<br>
<br>
> On Aug 21, 2025, at 14:38, William Herrin <<a href="mailto:bill@herrin.us" target="_blank">bill@herrin.us</a>> wrote:<br>
> <br>
> Hi Folks,<br>
> <br>
> I have three followup questions for you on the proposal to correct the<br>
> formula used to determine the maximum qualification for ISP IPv6<br>
> addresses.<br>
> <br>
>> From the current PPML discussion, it sounds like folks agree that the<br>
> revised formula correctly aligns with the text. Does anyone disagree?<br>
> <br>
> There's a misalignment between the terms "provider allocation unit" in<br>
> NRPM 6.5.2.1c and "provider assignment unit" in 2.15 and 2.16. As far<br>
> as I can tell, these are the only places in the NRPM that either term<br>
> is used. One of these should be changed to match the other so that<br>
> folks trying to understand 6.5.2.1.c can actually find the term's<br>
> definition. Does anyone have a preference for which?<br>
> <br>
> Now the big question: if we don't abandon it for non-interest, there<br>
> are probably three ways we can proceed with this proposal:<br>
> <br>
> 1. Change the formula as proposed.<br>
> <br>
> 2. Drop the formula and rely on the now-identical text.<br>
> <br>
> 3. Drop the formula and rewrite the text for clarity, without changing<br>
> the formula the text describes.<br>
> <br>
> Option 1 makes the minimum change to the policy, but leaves behind a<br>
> formula that may be difficult to understand.<br>
> <br>
> Option 3 theoretically leaves IPv6 allocation and the NRPM in more<br>
> comprehensible state, but it would require the largest change to the<br>
> policy text and carries a risk of unintentionally changing what the<br>
> policy calls for.<br>
> <br>
> What are your thoughts on the best choice here?<br>
> <br>
> Regards,<br>
> Bill Herrin<br>
> <br>
> <br>
>> On Wed, Jul 2, 2025 at 2:53 PM William Herrin <<a href="mailto:bill@herrin.us" target="_blank">bill@herrin.us</a>> wrote:<br>
>> <br>
>>> On Tue, Jul 1, 2025 at 11:34 AM ARIN <<a href="mailto:info@arin.net" target="_blank">info@arin.net</a>> wrote:<br>
>>> Draft Policy ARIN-2025-6: Fix formula in 6.5.2.1c<br>
>>> <br>
>>> Problem Statement:<br>
>>> <br>
>>> 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.<br>
>>> <br>
>>> Policy Statement:<br>
>>> <br>
>>> In 6.5.2.1c, replace:<br>
>>> <br>
>>> "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."<br>
>>> <br>
>>> with:<br>
>>> <br>
>>> "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).<br>
>> <br>
>> <br>
>> FYI, I'm the primary Advisory Council shepherd for this draft policy.<br>
>> Here's some explanation:<br>
>> <br>
>> Section 6.5.2.1c holds the criteria for the _maximum_ initial IPv6<br>
>> allocation for ISPs. They qualify for the number of IPv6 addresses<br>
>> described here and may request that much or a smaller block. The<br>
>> section is frankly hard to read. Here's what that part of the NRPM<br>
>> currently says:<br>
>> <br>
>> "c. The maximum allowable allocation shall be the smallest<br>
>> nibble-boundary aligned block that can provide an equally sized<br>
>> nibble-boundary aligned block to each of the requesters serving sites<br>
>> large enough to satisfy the needs of the requesters largest single<br>
>> serving site using no more than 75% of the available addresses.<br>
>> This calculation can be summarized as /N where N = P-(X+Y) and P is<br>
>> the organization’s Provider Allocation Unit X is a multiple of 4<br>
>> greater than 4/3*serving sites and Y is a multiple of 4 greater than<br>
>> 4/3*end sites served by largest serving site.<br>
>> <br>
>> d. For purposes of the calculation in (c), an end site which can<br>
>> justify more than a /48 under the end-user assignment criteria in<br>
>> 6.5.8 shall count as the appropriate number of /48s that would be<br>
>> assigned under that policy.<br>
>> <br>
>> e. For purposes of the calculation in (c), an LIR which has<br>
>> subordinate LIRs shall make such reallocations according to the same<br>
>> policies and criteria as ARIN. In such a case, the prefixes necessary<br>
>> for such a reallocation should be treated as fully utilized in<br>
>> determining the block sizing for the parent LIR. LIRs which do not<br>
>> receive resources directly from ARIN will not be able to make such<br>
>> reallocations to subordinate LIRs and subordinate LIRs which need more<br>
>> than a /32 shall apply directly to ARIN."<br>
>> <br>
>> <br>
>> Here's how ARIN staff explained the current implementation of NRPM 6.5.2.1c:<br>
>> <br>
>> "ARIN staff implements 6.5.2.1.c based on the text. The summarized<br>
>> formula is overly complex and inaccurate for your typical IPv6<br>
>> requestor. The text alone is more easily understood by customers and<br>
>> implemented by ARIN staff.<br>
>> <br>
>> ARIN staff calculates Initial allocation sizes by verifying how many<br>
>> serving sites the ISP has in the ARIN region, and how many customers<br>
>> are served at the largest serving site. ARIN assumes each customer<br>
>> will receive a /48 for simplicity and to promote IPv6 transition.<br>
>> <br>
>> Once the sites and customers are provided by the requestor, ARIN staff<br>
>> confirms what size is justified at the largest serving site based on<br>
>> the 75% rule. That size is applied to all sites, then checked against<br>
>> the 75% rule for the overall allocation justified by the ISP. The ISP<br>
>> can opt to request a smaller size. They are not required to request<br>
>> the largest justified size, though it is recommended to avoid future<br>
>> renumbering.<br>
>> <br>
>> For example:<br>
>> An ISP has 7 sites and 30,000 customers at the largest site.<br>
>> <br>
>> ARIN assumes each of the 30,000 customers receives a /48. There are<br>
>> only 4,096 /48s in a /36, so a /36 is too small. The next<br>
>> nibble-boundary aligned subnet is a /32 which has 65,536 /48s. 30,000<br>
>> is less than 75% of 65,536, so the ISP’s largest serving site<br>
>> justifies a /32.<br>
>> <br>
>> Thus, each of the 7 sites receives a /32. The next nibble-boundary<br>
>> after /32 is a /28. There are 16 /32s in a /28. 7 /32s of the total 16<br>
>> /32s is less than 75%, so the organization justifies a total<br>
>> allocation of a /28. 7 /32s for immediate allocation to each of their<br>
>> 7 sites and 9 additional /32s for future growth.<br>
>> <br>
>> Example 2:<br>
>> <br>
>> Building off the previous example, if the largest serving site had<br>
>> 60,000 customers, then a /32 would be too small. 60,000 is greater<br>
>> than 75% of the available 65,536 /48s in a /32. The next<br>
>> nibble-boundary aligned subnet is a /28, so the largest serving site<br>
>> justifies a /28. Thus, each of the 7 sites receives a /28, so the<br>
>> organization justifies a /24."<br>
>> <br>
>> <br>
>> Regards,<br>
>> Bill Herrin<br>
>> <br>
>> --<br>
>> William Herrin<br>
>> <a href="mailto:bill@herrin.us" target="_blank">bill@herrin.us</a><br>
>> <a href="https://bill.herrin.us/" rel="noreferrer" target="_blank">https://bill.herrin.us/</a><br>
> <br>
> <br>
> <br>
> --<br>
> William Herrin<br>
> <a href="mailto:bill@herrin.us" target="_blank">bill@herrin.us</a><br>
> <a href="https://bill.herrin.us/" rel="noreferrer" target="_blank">https://bill.herrin.us/</a><br>
> _______________________________________________<br>
> ARIN-PPML<br>
> You are receiving this message because you are subscribed to<br>
> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
<br>
_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div>