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 <[email protected]> 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 <[email protected]> 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 < >> [email protected]> 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 <[email protected]> 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 <[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." >>> >> >>> >> >>> >> Regards, >>> >> Bill Herrin >>> >> >>> >> -- >>> >> William Herrin >>> >> [email protected] >>> >> https://bill.herrin.us/ >>> > >>> > >>> > >>> > -- >>> > 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. >> >
_______________________________________________ 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.
