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

[William Herrin]

On Mon, Jul 14, 2025 at 7:49 AM Owen DeLong <owen at delong.com> wrote:
> 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.

Hi Owen,

As the primary AC shepherd on 2025-6, I dug into the information you
presented here and it is my assessment that you are correct. ARIN
misimplemented NRPM section 6.5.2.1. Specifically, the policy calls
for ARIN to inquire into the ISP's intended default downstream IPv6
assignment size and to scale the ISP's entitlement accordingly.
Reviewing the debate around the proposal that established the policy,
this was very clearly its intent. ARIN does not do so. Instead, ARIN
assumes this assignment size is /48. In my experience, this is usually
incorrect. The default is rarely more than /56 which should, according
to the policy, result in an entitlement that is at least 8 bits
smaller.

I want to be very clear: this is my assessment as one member of the
AC. It should not be construed to reflect ARIN's position as an
organization nor the AC's position as a group.

With that, I want to pose the question to you and to the rest of the
community: what would you like done about this?

Some obvious options include:

1. Make ARIN's implementation conform to the written policy. I.e.
start asking ISPs what size assignment they've selected as their
default.

2. Make the policy conform to ARIN's implementation. This would
involve removing the Provider Allocation Unit language from 6.5.2.1c
as well as removing it from the section 2 definitions since the term
is only used in 6.5.2.1c.

3. Do nothing. The implementation continues in non-conformance.

4. Do a broad rewrite of section 6.5.2.1, which will result in ARIN
creating an implementation of the new policy. We do, after all, have a
decade more experience with the practical operation of IPv6 than we
did when this policy was written. Surely we can improve it.

5. Some combination of the above, e.g. ask ARIN to conform pending a
general rewrite or do nothing pending a general rewrite.

So, with this in mind, I ask all of you in the community: what do you
think is the best thing to do here?

Regards,
Bill Herrin