[arin-ppml] Request for Comment & Feedback: Draft Policy ARIN-2025-3: Change Section 9 Out Of Region Use Minimum Criteria

Douglas Camin doug at dougcamin.com
Wed Mar 18 14:21:14 EDT 2026


Chiming in here -

Eric, you made this as a suggestion at the mic at ARIN56 as well (adding language that stated most space had to be used in region.)

As the shepherd at the time with Gerry, we heard your suggestion and evaluated its viability to add to the policy but found it to have too many significant secondary implications. Tom’s response accurately captures the same understanding we came to.

It may not have been clear looking at the AC minutes (I just checked) that we heard and reviewed what you had brought forward, so I apologize for a gap in that information flow on our part.

Hope that helps -


Doug

--
Douglas J. Camin
Vice Chair, Advisory Council
doug at dougcamin.com
From: ARIN-PPML <arin-ppml-bounces at arin.net> on behalf of Tom Fantacone via ARIN-PPML <arin-ppml at arin.net>
Date: Wednesday, March 18, 2026 at 1:53 PM
To: Eric C. Landgraf <echarlie at vt.edu>
Cc: arin-ppml <arin-ppml at arin.net>
Subject: Re: [arin-ppml] Request for Comment & Feedback: Draft Policy ARIN-2025-3: Change Section 9 Out Of Region Use Minimum Criteria

On Mar 18 13:08, arin-ppml-request at arin.net<mailto:arin-ppml-request at arin.net> wrote:
Date: Wed, 18 Mar 2026 13:08:20 -0400
From: Eric C. Landgraf <echarlie at vt.edu<mailto:echarlie at vt.edu>>

>Should we rewrite the policy to allow any amount of out-of-region use so
>long as it is less than or equal to in-region use? (Obviously the usual
>needs-based rules also apply). In practice, this means if you use a /24
>in-region you can use up to a /24 out-of-region; for v6 that would
>probably be a /48 in and out-of-region. Personally, I don't even care
>what the limits are: if you want to use a directly-allocated /32 of v4
>space out-of-region instead of going through an LIR, that is up to you
>(provided your transit provider will accept the route and all).
>
>Using more addresses/prefixes in-region than out-of-region seems like
>sufficient evidence of "real and substantial connection with the ARIN
>region" and is far better than arbitrary length-based rules.

Eric,

The concept of restricting out-of-region use so that it's less than or equal to in-region use is interesting, and I suspect (but don't know) that this kind of scheme was considered during the initial drafting of the existing out-of-region use policy.

It does open a can of worms, however, in that for most organizations it's a far more restrictive policy than the active one, while the proposed policy is slightly less restrictive than the active one.  That doesn't mean we shouldn't consider it, but we should be aware of the ramifications.

Under current policy, as long as an organization has a /22 of ARIN space used in-region, they could have multiple large ARIN blocks used out-of-region.  The rewrite you're inquiring about would force those organizations to do some severe restructuring, and would most likely involve them having to join the other RIRs and transfer the space there.  There are large, multi-national organizations with a "real and substantial connection with the ARIN region" (i.e. headquartered here) but with large overseas data centers that require a lot more resources outside the ARIN region.  I think it's OK that these organizations get their resources from ARIN, pay their dues to ARIN, but use much of those resources wherever they need to.

Even under the current policy, it would be financially advantageous for these organizations to move all their space to RIPE, due to its flat-fee structure, but they choose not to because ARIN is their "home base".

I do like the proposed policy in that it has a very "light touch" and just addresses the issue of the discrimination against very small organizations under current policy without changing policy for everyone else.

Regards,
Tom Fantacone


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20260318/e7faaa4d/attachment-0001.htm>


More information about the ARIN-PPML mailing list