> On Feb 16, 2026, at 06:09, William Herrin <[email protected]> wrote:
> 
> On Mon, Jul 14, 2025 at 7:49 AM Owen DeLong <[email protected]> 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.

As the policy author, I can assure you that was the clear intent of the policy 
language and I have repeatedly informed ARIN staff of this fact and been blown 
off each and every time. 


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

I would like ARIN to begin following the policy as written. The policy intent 
was to encourage ISPs to be not stingy about their allocations and to 
discourage damaging practices like issuing /60s to residential customers. 

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

It’s not default… it’s minimum. If they issue /48s by default to business 
customers and /60s to residential, for example, the policy calls for a PAU of 
/60. 

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

I am opposed to this solution, personally. 
> 
> 3. Do nothing. The implementation continues in non-conformance.

This is even less desirable, imho. 

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

That’s certainly an option, but it should be a separate proposal and will 
reserve comment on such a rewrite until I have seen it. 

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

IMHO, ARIN should immediately begin conforming. I think the policy language is 
clear. You seem to agree, so at least I am not alone. 
> 
> So, with this in mind, I ask all of you in the community: what do you
> think is the best thing to do here?

I’m pretty sure you knew my thoughts before this writing, but just in case, I 
present them here again on the record for all to see. 

Owen


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

Reply via email to