It’s still linear, but the log is because we are computing the number of bits to represent the sites. It was an error I made in writing the original formula and the shift does not change the clear intent of the policy text, it merely corrects my rather long lived math error.
Owen > On Jul 12, 2025, at 16:34, Martin Hannigan <[email protected]> wrote: > > I think it works mathematically? https://pastebin.com/r24VdGTy > > Please spell out log_2 as "log base 2" or subscript 2 to avoid any > doubts. I don't see any reason why subscripts wouldn't work on the > ARIN website. > > Why shift from linear to log? > > Warm regards, > > -M< > > > > >> On Sat, Jul 12, 2025 at 7:09 AM William Herrin <[email protected]> wrote: >> >> Hi folks, >> >> Just a reminder - the ARIN public policy process runs on positive >> consensus not silent assent. If you're okay with this policy draft as >> written, we need to hear you say it. If you agree there's a problem >> but want to see a different solution, we need to hear you say that >> too. If the advisory council hears nothing, we will eventually abandon >> the draft and the problematic section of the NRPM will persist until >> someone figures out how to abuse it. >> >> Regards, >> Bill Herrin >> >> >>> On Wed, Jul 2, 2025 at 2:53 PM William Herrin <[email protected]> wrote: >>> On Tue, Jul 1, 2025 at 11:34 AM ARIN <[email protected]> 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." >> >> >> >> >> -- >> William Herrin >> [email protected] >> https://bill.herrin.us/ >> _______________________________________________ >> ARIN-PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List ([email protected]). >> Unsubscribe or manage your mailing list subscription at: >> https://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact [email protected] if you experience any issues. > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. _______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
