<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">
On Fri, Apr 9, 2021 at 3:38 PM ARIN <info at <a href="http://arin.net/" class="">arin.net</a>> wrote:
<br class="">
<br class="">
<blockquote type="cite" style="color: #007cff;" class="">We are consulting with the community regarding changes to the
<br class="">
ARIN Fee Schedule that are intended for implementation in January <br class="">
of 2022. These changes are: <br class="">
<br class="">
* Transitioning End Users from annual per-resource maintenance <br class="">
fees to the RSP (Registration Services Plan) Fee Schedule <br class="">
</blockquote>
<br class="">
Largely I'm OK with this as I recently converted to a registration <br class="">
services plan myself as I was wanting to get IPv6 space as well so <br class="">
it made more sense to have both and full voting membership under a <br class="">
single $250 fee. (I just submitted a ticket asking about getting <br class="">
a /40 yesterday morning,) <br class="">
<br class="">
As one of "the smallest end users" I don't need more than a /24 of IPv4 <br class="">
space and a /40 of IPv6 space. If the nature of what I do changed <br class="">
enough that I needed more space than that I would probably by that <br class="">
point be a big enough organization that I could handle the higher <br class="">
fees for the larger chunks of IP space under the Registration <br class="">
services plan. <br class="">
<br class="">
Really this will only raise costs for end user organizations with <br class="">
very large singular chunks of space. Generally an organization big <br class="">
enough to actually need even a /22 is big enough it can afford to <br class="">
pay the Registration Services Plan fees for it. <br class=""></div></div></blockquote></div></div></div></div></blockquote><div><br class=""></div>Yes, but the reality is that as soon as you have a /23 + 1 address</div><div>(e.g. a /23 + a /24), you get jacked.</div><div><br class=""></div><div>To make matters worse, if you have LRSA and RSA resources, you</div><div>get double-jacked because ARIN can’t figure out how to bill you for</div><div>the MAX you owe under either of the two contracts, so they bill you</div><div>for both. You can consolidate under an RSA, but then your LRSA</div><div>resources no longer have the protection of the $25/year cap on</div><div>increases.</div><div><br class=""></div><div>As a result, you get converted not to a single RSP, but to two RSPs.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="">
It won't impact us "smallest end users" with the possible exception <br class="">
of holders of a single IP block. This could maybe be addressed by <br class="">
making the "ASN-only" category in the proposed new fee structure a <br class="">
"single resource only" category which would apply whether that single <br class="">
resource was an AS, a /24 of IPv4 or a /40 or smaller of IPv6. <br class="">
<br class="">
The IPv4 only holders will eventually realize one day that they <br class="">
need IPv6 as well to be visible to the whole internet and they <br class="">
will upgrade then at their own pace. I'm pretty sure that anyone <br class="">
that at this point has their own IPv6 space and no IPv4 space is <br class="">
either running a hobby/experimental network or is thinking very <br class="">
very long term about larger plans and is thinking it's easier to <br class="">
get their resources now than down the road, either way they <br class="">
probably aren't generating revenue with that IPv6 block right <br class="">
now so for them every penny counts. <br class=""></div></div></blockquote></div></div></div></div></blockquote><div><br class=""></div>In reality (and this might be worth considering), the current fee structure</div><div>plan creates an economic incentive for LRSA holders to abandon any</div><div>IPv6 resources they have in favor of preserving their LRSA fee increase</div><div>protection.</div><div><br class=""></div><div>Do we really want to create an even bigger economic incentive to not only avoid</div><div>implementing IPv6, but to reverse some of the deployments that have already</div><div>been made?</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="">
Finally having everyone under the registration services plan will <br class="">
be simpler for new sign ups than having 2 different fee schedules. <br class="">
<br class="">
<blockquote type="cite" style="color: #007cff;" class=""> * Transitioning Legacy resource holders from annual per-resource
<br class="">
maintenance fees to the RSP Fee Schedule while maintaining the <br class="">
annual cap of total maintenance fees (which will increase $25 <br class="">
per year) <br class="">
</blockquote>
<br class="">
As long as the fee cap on LRSA holders remains (which I agree it <br class="">
should for all of them and not just the early signers) that would <br class="">
override the difference between the 2 current fee schedules anyways <br class="">
which makes this change immaterial to them. <br class=""></div></div></blockquote></div></div></div></div></blockquote><div><br class=""></div>Until those LRSA holders need IPv6.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="">
Legacy holders (including those that never signed an LRSA) will all <br class="">
at some point need IPv6, so either they'll have to get it through <br class="">
their ISPs or they'll have to pay RIR fees on those when the point <br class="">
comes that they decide they need it. <br class=""></div></div></blockquote></div></div></div></div></blockquote><div><br class=""></div>And here’s where the real rub comes in… If you want to keep your</div><div>LRSA fee protection on your LRSA holdings, you get double-billed.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="">
<blockquote type="cite" style="color: #007cff;" class=""> * Providing a temporary IPv6 fee waiver for organizations in
<br class="">
the 3X-Small category that desire a larger address block <br class="">
</blockquote>
<br class="">
Generally I think this is a gimmick, it expires at the end of 2026. <br class="">
Really if I needed more than a /40 of IPv6 space between now and <br class="">
the end of 2026 I'd probably also need more IPv4 space and have <br class="">
to move up size categories anyways. It almost looks like a trap <br class="">
as anyone who takes the bigger space now but doesn't really need <br class="">
it is baking in a doubling of fees when they renew in 2027 but if <br class="">
their organization is still a very small one that doubling of fees <br class="">
could be a strain on them. I myself did hold out for the 2020-3 <br class="">
to be implemented before requesting IPv6 space as $250/year I can <br class="">
handle but $500 per year would be a strain. <br class=""></div></div></blockquote></div></div></div></div></blockquote><div><br class=""></div>So consider that same strain absolutely applies to every LRSA holder</div><div>that also holds RSA resources due to the double-billing issue described</div><div>above.</div><div><br class=""></div><div>Owen</div><div><br class=""></div><br class=""></body></html>