Hi Quantum - I think there may be some confusion about what exactly that proposed language is bringing about.
In the example you have built, you said that the change forbids you from getting any space for out of region use. I don’t believe that interpretation is correct. The language in this proposal only applies to what resources you can use to count towards the required justifications to receive the space under 4.1.8, 4.4, or 4.10. There is no explicit prohibition on where to use that space (though, separately Recommended Draft policy 2025-8 will modify 4.10 to explicitly state it is to be used in the ARIN region.) For each section, here is the practical change as I can discern it: 4.1.8 Waitlist - As currently written, if you have a /20 or more of space already, you would not be able to access the waitlist anyhow. But, if you have less than that you are subject to the clause in 4.1.8.3 about other applicable policies, which takes you to 4.2.4.1 Utilization percentage (80%.) Currently, that /21 or below can be in any region and still qualify for justification to get on the waitlist. The new restriction will limit the justification to get on the waitlist to being able to demonstrate an entity is using 80% of their current allocations in the ARIN region (as opposed to their total global allocation.) 4.4 Micro-allocation - There is currently no written space-based qualification criteria in 4.4 that is evaluated, the justification is whether or not an entity is critical infrastructure, regardless of their space usage and where it is located. The new restriction does not explicitly appear to change the materiality of how to qualify and would not currently impact this section. 4.10 v4 -> v6 Deployment - 4.10 has criteria outlining who qualifies but the only time a usage justification comes up is if you get less than a /22 initially and wanted the remainder to be allocated later. Bullet 3 says if you received smaller than a /22 (ie, /24) and wanted more (ie, another /24) you have to demonstrate 80% usage of what you have - so the new language would require that usage to be in the ARIN region. That is a nominal change, because its unclear you could use the initial /24 outside the region and obtain the next /24 anyhow. So the new restriction does not explicitly appear to materially change the initial qualification, but it could have a marginal impact on the second step in an corner case scenario. To summarize all of the above (hopefully) succinctly: The language of this policy proposal is speaking only to the criteria to justify qualifying for sections 4.1.8, 4.4, and 4.10. This language will not add restrictions to how you can utilize the space. The language will have an impact on how entities can qualify for 4.1.8, and will not have an impact on how they qualify for 4.4 or 4.10 space. The additional language was added based on input from the community requesting those clauses be added, and has been in line with the trend in recent years to explicitly clarify that any remaining allocations of v4 space from ARIN are expected to be used in the ARIN region. These changes do not impact the ability of an entity to get space from the transfer market and use it as they see fit. Note this is an analysis intended to help clarify the conversation and understanding about the change, and not an advocacy for any particular position on the policy. Hope that helps - Doug — Douglas J. Camin Vice Chair, ARIN Advisory Council [email protected] On Sep 25, 2026, at 2:18 AM, Quantum via ARIN-PPML <[email protected]> wrote: Hi Owen, On 2026-09-24 21:36, Owen DeLong wrote: That opposition is specious unless the vast majority of your utilization. Is out of region. For example, let’s say you have a /21 from ARIN. You are using a /24 out of region and the other 7 /24s within the ARIN region. The 80+% utilization in region would still count towards qualifying, but the extra-regional utilization would not. I think you are a victim of the confusing way this policy is written, with the justification and summary completely different from the implementation detail. I don't think you understand what the draft policy is actually proposing after the latest amendment, because your example doesn't make sense in context. Let's use something similar to your example. Let's say you have a /21 from ARIN, used entirely with the ARIN region. Now, you want a new /24 from ARIN to use out-of-region, because it's just a /24 and it doesn't make sense to sign up with a whole new RIR just for one /24 when you have /21 with ARIN. Under the current version of the NRPM section 9: ARIN registered resources may be used outside the ARIN service region. 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 /22 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. This is a valid justification for additional resources from ARIN since you have a /21 in region, and ARIN will issue it to you via the waiting list eventually. However, let's examine the current text of the 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. This is fine and will not affect this example at all. Out-of-Region Usage Justification may not be used to receive IPv4 address space from the ARIN Waiting List (4.1.8), the Micro-allocation Pool (4.4), or the Dedicated IPv4 Block to Facilitate IPv6 Deployment (4.10). Any organization already on the Waiting List at the time this policy is implemented will be exempted and shall remain eligible under the rules in effect at the time of its placement on the Waiting List. This part, which is the newly added amendment, forbids you from getting any space from ARIN at all for out-of-region use, since all valid mechanisms of requesting space from ARIN are blocked, leaving only section 8 transfers as valid. So if you want that extra /24 after having a /21 with ARIN, your only options are: 1. sign up with a different RIR; or 2. buy it from IPv4 brokers. Why are we doing this? Has there been any abuse in out-of-region IPv4 requests? No one has ever shown any evidence of this to justify adding new restrictions for IPv4 this late in the game. This is precisely why I hate the way the amendment is packaged into this policy. It tricks people into believing the policy does something completely different, because the amendment doesn't align with what the policy is purported to do. It causes confusion and muddies the debate to get such an amendment snuck in under the radar. I support the policy as currently written. Further, any belief that ARIN is likely to be a continuing source of IPv4 addresses is ill-advised at best. Move on to IPv6. It’s long overdue. I agree that the right thing to do is moving to IPv6. I myself have everything available dual-stack. The amendment is adding a pointless restriction to the waiting list for no reason, perhaps in an attempt to conserve the waiting list. If we are convinced that ARIN being a continuing source of IPv4 addresses is ill-advised, why are we slapping new restrictions on IPv4? Best regards, Quantum _______________________________________________ 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.
_______________________________________________ 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.
