Assuming /48 as the PAU is not true to the policy. The policy was intended to encourage LIR/ISPs to implement /48 PAUs by limiting the size of allocations to providers that issued smaller end site allocations.
It saddens me to learn that ARIN has implemented the policy in a manner that contravenes the clear language of the policy defining PAUs. I sincerely hope ARIN will correct this, though at this point, it’s likely too late to have meaningful impact. For example, a certain large $CABLECO in the US issued /60s to their residential customers, so their PAU should be assumed to be /60 and not /48. Owen > On Jul 2, 2025, at 14:54, 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/ > _______________________________________________ > 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.
