I support the policy as written.
I have seen a handful of cases where companies based in the ARIN region just
require a /24 for their main office and another /24 in a branch office in
Europe or Asia. Currently, these companies have to either seek resources from
2 separate RIRs, or forego ARIN entirely and obtain all their resources from
RIPE, where the out-of-region use requirements are less stringent.
This policy addresses that issue.
Regards,
Tom Fantacone
From: Gerry E.. George <[email protected]>
To: "ARIN PPML"<[email protected]>
Date: Tue, 17 Mar 2026 04:54:23 -0400
Subject: [arin-ppml] Request for Comment & Feedback: Draft Policy ARIN-2025-3:
Change Section 9 Out Of Region Use Minimum Criteria
Hello & Good day to PPML Community.
As assigned shepherds, Matthew Wilder & myself are seeking feedback & comments
on the current version of the Draft Policy ARIN-2025-3: Change Section 9 Out Of
Region Use Minimum Criteria.
I have summarized the key points below, but the full policy can be accessed
here:
https://www.arin.net/participate/policy/drafts/2025_3/
ARIN-prop-341 (ARIN-2025-3) - Change Section 9 Out Of Region Use Minimum
Criteria
In brief:
Section 9 of the NRPM, Out of Region Use, requires organizations to use at
least a /22 in the ARIN region before they can justify out of region use. This
harms smaller organizations that have less than a /22 in region but do require
some out of region use.
Proposal:
Modify the following text in Section 9:
FROM: IPv4: At least a /22 used in region.
TO: IPv4: At least a /24 used in region.
RESULT:
Out of region use of ARIN registered resources are valid justification for
additional number resources, provided that the applicant has a real and
substantial connection with the ARIN region which applicant must prove (as
described below) and is using the same type of resources (with a delegation
lineage back to an ARIN allocation or assignment) within the ARIN service
region as follows:
IPv4: At least a /24 used in region
IPv6: At least a /44 used in region
ASN: At least one ASN present on one or more peering sessions and/or routers
within the region
At issue:
When a company needs address space outside of the ARIN region without at least
a /22 in region, they go to RIPE and acquire either PI or Legacy space (the
least expensive option), often acquiring the space from ARIN sources.
In the case of an inter-regional ARIN to RIPE transfer, RIPE does require the
recipient to demonstrate need, as required by ARIN. ARIN is losing
registration of the block and annual fees, as well as the recipient transfer
fee. Most of these recipients would much rather keep everything together in
one ARIN account instead of having to go to another registry.
While there are no material legal issues, it is anticipated that this change in
policy would significantly increase the volume of IPv4 waitlist requests and
could lead to an increase to staff ticket workload.
Because the policy requirements for an organization to justify an initial /24
are generally straightforward to meet, it is expected that more organizations
may request a /24 primarily to qualify for additional ARIN-issued IPv4
addresses for out-of-region use. It is expected that this would result in more
ARIN IPv4 space being used out of region.
Concern regarding possible abuse of the reduced requirement in order to obtain
ARIN resources, particularly for blocks larger than the minimum (/24) for OOR
use.
Considerations:
- How much of an issue could this be? Does it matter to the community?
- Should there be a requirement for the OOR use be not more/greater than the
in-ARIN region use?
- Can this unfavorably impact companies having more growth OOR, and drive them
to other RIRs and away from ARIN in such instances?
- Is there a probability for potential abuse via the Waitlist, and if so,
should there be consideration for limitations to the designated region use for
4.1.8. requests?
- Is the "real and substantial connection" requirement in Section 9 be
sufficient to prohibit or reduce the potential for abuse?
Questions:
Are you in support of the policy?
Are there any additional issues which should be considered?
Should the AC continue working on the policy as written?
And remember, the ARIN public policy process runs on positive consensus not
silent assent, so please weigh in. We look forward to your engagement.
Thanks.
Gerry E. George
ICT Consultant and Business Solutions Architect;
DigiSolv, Inc. [P.O. Box 1677, Castries, Saint Lucia]
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ( mailto:[email protected] ).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact mailto:[email protected] if you experience any issues.
_______________________________________________
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.
