<html aria-label="message body"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Sep 24, 2026, at 23:17, Quantum <arin@quantum5.ca> wrote:</div><br class="Apple-interchange-newline"><div>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div><p>Hi Owen,</p>
<div class="moz-cite-prefix">On 2026-09-24 21:36, Owen DeLong wrote:<br>
</div>
<blockquote type="cite" cite="mid:3716D57D-B3F9-4340-9047-17031F1572D3@delong.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">That opposition is specious unless the vast
majority of your utilization. Is out of region. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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. </div>
</blockquote><p>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.</p></div></div></blockquote><div><br></div>No, I think you are the one misunderstanding the situation, but let’s see how this pans out…</div><div><br><blockquote type="cite"><div><div><p>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.</p></div></div></blockquote><blockquote type="cite"><div><div><p>Under the current version of the NRPM section 9:</p><div>
<br class="webkit-block-placeholder"></div><blockquote type="cite"><p>ARIN registered resources may be used outside the ARIN
service region. <b>Out of region use of ARIN registered
resources are valid justification for additional number
resources</b>, 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:</p>
<ul>
<li><b>IPv4: At least a /22 used in region</b></li>
<li>IPv6: At least a /44 used in region</li>
<li>ASN: At least one ASN present on one or more peering
sessions and/or routers within the region.</li></ul></blockquote></div></div></blockquote>Yep… That’s saying that your existing usage out of region can be counted in your justification for more space.</div><div>Yep, this policy would change that fact. However, since your existing /21 is entirely within the region in your proposed example, this is a distinction without a difference.<br><blockquote type="cite"><div><div><blockquote type="cite"><ul>
</ul>
</blockquote><p>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.</p></div></div></blockquote>Well, maybe, assuming that something comes available on the waiting list, perhaps. But that’s a side issue which I’ve already addressed.<br><blockquote type="cite"><div><div><p>However, let's examine the current text of the proposal:</p><div>
<br class="webkit-block-placeholder"></div><blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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.</pre>
</blockquote>
This is fine and will not affect this example at all.<div><br class="webkit-block-placeholder"></div><div>
<br class="webkit-block-placeholder"></div><blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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.</pre>
</blockquote><div><br class="webkit-block-placeholder"></div></div></div></blockquote><div><br></div>Right, well, I agree that it does close that loophole and I guess I’m fine with closing that loophole for those particular classes of address space.</div><div>I suppose you are not. That’s a somewhat different argument from what I previously understood you to be saying when I responded.</div><div><br><blockquote type="cite"><div><div><p>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:</p>
<ol>
<li>sign up with a different RIR; or</li>
<li>buy it from IPv4 brokers.</li></ol></div></div></blockquote><div><br></div>or 3. Buy it from someone who has it without involving a broker</div><div>or 4. Lease it from some IPv4 leasing company</div><div>or 5. Transfer it through some other mechanism permitted under policy.</div><div><br></div><div>Ironically, you could actually use a combination of option 1 and section 8 to get the space and then consolidate it into your ARIN account via an inter-RIR transfer, if you can qualify with an RIR that will issue you space through some mechanism.</div><div><br></div><div>Again, perceiving RIRs as a continuing source of IPv4 addresses is folly to start with, so I’m really having a hard time getting fussed over policies that make that difficulty more visible.</div><div><br><blockquote type="cite"><div><div><ol>
</ol><p>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.</p></div></div></blockquote><div>Honestly, I don’t know. I also don’t much care. The ability to use out of region justification for acquisition of those classes of address space is, IMHO, an unintended loophole and closing it generally strikes me as a good thing.</div><blockquote type="cite"><div><div><p>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.</p></div></div></blockquote><div>Agree to disagree… I think closing those loopholes for those classes of address space is within what the policy is purported to do and I don’t have a problem with it.</div><div><br></div><blockquote type="cite"><div><div>
<blockquote type="cite" cite="mid:3716D57D-B3F9-4340-9047-17031F1572D3@delong.com">
<div dir="ltr">I support the policy as currently written. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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.</div>
</blockquote><p>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?</p></div></div></blockquote><div><br></div></div>Personally, I think the waiting list is an increasingly pointless illusion. Unfortunately, I don’t have a better way to deal with any IPv4 addresses that trickle back to ARIN (other than possibly dumping them into one of the post-exhaust pools or auctioning them through a broker to reduce member fees, both of which I suspect would be unpopular).<div><br></div><div>As to the latter, I think additional restrictions help make it more visible to some people that getting IPv4 addresses from ARIN is going to be increasingly difficult and less likely to succeed as time marches on. So I think you’ve just made one of the best arguments for this policy in your effort to oppose it.</div><div><br></div><div>Owen</div><div><br></div></body></html>