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

[William Herrin]

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 <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."




-- 
William Herrin
bill at herrin.us
https://bill.herrin.us/