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

[Owen DeLong]

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 <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/
> _______________________________________________
> 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.