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

[Owen DeLong]

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 <hannigan at gmail.com> 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 <bill at herrin.us> 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 <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/
>> _______________________________________________
>> 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.
> _______________________________________________
> 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.