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

[Gerry E.. George]

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; 
Digi Solv , Inc. [P.O. Box 1677, Castries, Saint Lucia] 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20260317/4fdaab38/attachment.htm>