[arin-ppml] The annual limit on total maintenance fees for legacy number resources under the ARIN fee schedule

hostmaster at uneedus.com hostmaster at uneedus.com
Wed Apr 13 01:05:04 EDT 2022


Does there not still exist some legacy addresses that pay NO fees?  While 
there are those legacy blocks without contact addresses, there also appear 
to be addresses who have updated contacts, but are not paying fees to 
ARIN.

For example, 192.168.112.0/24 is a legacy block controled by Berea 
College. To the best of my knowledge, they do not pay for this block. I 
became aware of this block because this school, like myself does not have 
a street address, a problem I ran into in the past when a major ISP was 
insisting on a unique street address for every public transit bus with a 
static address assignment be provided in SWIP, which of course is not 
possible. They would not accept all busses being registered to the street 
address of administrative entity that ran the bus system, as they wanted a 
unique street address for all 500+ busses, and not one address for all.

How much legacy space is like this /24 that does not pay, but still has 
valid contact information on file?

How much legacy space is like other blocks discussed that have NO valid 
contact addresses at all, and therefore is not paying either?

I personally think this great search for IPv4 space is becoming more 
pointless every day.  4 billion IPv4 addresses with a world population of 
7+ billion alone shows the pointlessness of IPv4 space recovery.

I would hope that eventually this fixed address shortage will be dealt 
with by most operators by the simple act of using IPv6.  So much effort 
has been done toward the recovery of every possible IPv4 address, which 
effort would be better placed toward using a protocol that is available 
today, supported by nearly every operating system and router on the 
planet, and provides even the smallest network with more addresses than 
they can ever use.

ARIN has made IPv6 available for no extra charge for all but some corner 
cases.  Even then, most of those corner cases can still join the IPv6 
community by obtaining a block of IPv6 addresses from their upstream at 
little to no charge. Those cases appear to be mostly legacy IPv4 holders 
like Berea College who can receive IPv6 space with their circuits for 
little or no additional cost.

To me, it looks like certain parties do not want to move to IPv6 because 
wide spread adoption will crash the values of their IPv4 holdings that 
they keep expanding, like it is some kind of investment.

However it is time to adopt, as trying to continue to build networks on 
IPv4 with CALEA requirements with less than 1 address per person on the 
earth cannot be sustainable. All kinds of effort and money are being spent 
to remain IP4 only such as CGnat and Logging, rather than simply using 
this money to move to IPv6.

We have the tools for network address growth, and it is called IPv6.  Lets 
use it.

Albert Erdmann
Network Administrator
Paradise On Line Inc.



On Fri, 8 Apr 2022, Owen DeLong via ARIN-PPML wrote:

> 
>
>       On Apr 7, 2022, at 14:54 , John Curran <jcurran at arin.net> wrote:
> 
> On 7 Apr 2022, at 1:16 PM, Owen DeLong <owen at delong.com> wrote:
>
>       Moved to ARIN-PPML per your previous advice and your request below...
>
>             On Apr 7, 2022, at 09:25 , John Curran <jcurran at arin.net> wrote:
>
>       ...
>
>       However, the “Fee Cap on IPv4 maintenance fees” provided to IPv4 legacy resource holders does not apply to such an amount invoiced because the
>       customer is being invoiced for a registration services plan that contains multiple items [services for IPv4, IPv6, and ASN resources] that are
>       more than just "IPv4 maintenance fees”.    Customers can keep their IPv4 resources in a separate billing relationship and then the “Fee Cap on
>       IPv4 maintenance fees” will continue to be applied to their “IPv4 registry maintenance fees”, exactly as expected. 
> 
> 
> It is not a “fee cap” as you express it. It is a rate of increase cap.
> 
> 
> Mr. Delong - 
> 
> You are Incorrect: as noted in the 2018 Fee Consultation - <https://www.arin.net/vault/announcements/2018/20180606_feeschedule.html>
>
>        o  Legacy resource holders pay the same annual registry maintenance fees as End User organizations ($150 USD for each IPv4 address block and $150
>           USD for each ASN assigned to the organization.) However, there is an annual limit on total maintenance fees applicable to legacy resource holder
>           organizations, and as of 1 July 2018, the annual limit of total maintenance fees for legacy resource holders is set to $125 USD, regardless of
>           the number of legacy resources held or version of their Legacy Registration Services Agreement (LRSA.)
> 
> 
> 
> The "annual limit on total maintenance fees applicable to legacy resource holder organizations” is the “fee cap” to which I have been referring, and it is only
> applicable to registry maintenance fees for legacy number resources – regardless of the number of legacy resources held.  
> 
> 
> While ARIN may have implemented it that way (because they kind of made a hash of it initially), the contractual language in the LRSA referred to a maximum increase in
> the amount paid under the LRSA of $25/year. Admittedly, this language was removed from later versions of the LRSA and ARIN botched the billing (to the detriment of
> many LRSA signatories). When called out on this, the board decided to reset the increase clock (for all LRSA signatories) and apply the same cap to all LRSA
> signatories. You can consider that a total fee cap if you want, but the bottom line is that it increases by $25/year until any given organization reaches parity with
> the current fee structure and then it stops increasing for that organization (until things change and they start going up by $25/year again).
> 
> The language in LRSAs with the limitation on increase DOES NOT permit ARIN to do a large jump in a single year just because it’s been several years since such an
> organization received an increase. (For example, an organization paying $250/year for a single /24 under the current fee structure in (e.g.) 2026 cannot be charged
> $350/year in 2030 unless the fee structure unless ARIN raises the annual subscription for a single /24 prior to their 2027 billing cycle. So it really is a rate of
> increase cap in terms of the contractual language.
> 
> Consider the following LRSA scenarios:
> 
> The annual limit on LRSA total maintenance fees goes up by $25/year until it reaches parity with non-LRSA organizations under an equivalent fee structure (dating back
> to when ARIN had separate structures for end-user and ISP/LIR/Subscriber organizations.
> 
> Pre-2013 2013 - 2016 2016 - 2018 2018 - 2022 2022 forward
> Single /24 End User Org $100 $100 $100 $100+$25/yr->$150 $150+$25/yr->$250
> End User Org holding 16 /24s $100 $100+$25/yr-> $100+$25/yr->$1600 $100+$25/yr->$1600 $150+$25/yr->$1000
> $1600
> End User Org holding a /20 $100 $100 $100 $100+$25/yr->$150 $150+$25/yr->$1000
> 
> 
> 
> I signed the LRSA _BEFORE_ the 2018 Fee consultation. I was a fairly early LRSA signatory.
> 
> From ARIN XI —
> 
> MAINTENANCE FEE DISCUSSION
> 
> Presentation (Read-only): PDF 
> Moderator: John Curran
> 
> John Curran reminded those present of the discussion from last meeting regarding maintenance fees. He stated that at that time consensus was to institute a $100 total
> cap fee for maintenance fees. We want to make sure the cost of keeping ARIN going is adequately handled. 
> 
> There were no questions.
> 
> ===========
> 
> Fees came up again here:
> https://www.arin.net/vault/participate/meetings/reports/ARIN_XIII/ppm_minutes_day2.html#12
> 
> https://www.arin.net/vault/participate/meetings/reports/ARIN_XIII/PDF/Tuesday/Maint_Howard.pdf
> 
> Pretty sure that’s the fee structure that was in place when I signed the LRSA some time around November, 2007.
> 
> As you can see from the slides — Single maintenance fee $100. I believe that persisted until some time around 2013, so I was wrong about the time between signing the
> LRSA and the change to the fee structure to make it fee-per resource instead of fee-per-organization.
> 
> Consider also that prior to 2013, an LRSA signatory that also had an end user IPv6 block paid $100 total annual maintenance and was a single organization.
> 
> The creation of bifurcated organizations due to RSA differences was foisted upon LRSA signatories as part of the 2031 Fee structure change.
> 
> Additional data sources:
> ARIN Fee Schedule July 1 2013 to July 1 2016: https://www.arin.net/vault/fees/fee_schedule_2013.html
> ARIN Fee Schedule July 1 2016 to July 1 2018: https://www.arin.net/vault/fees/fee_schedule_2016.html
> ARIN Fee Schedule Announcement for July 1 2018: https://www.arin.net/vault/announcements/2018/20180606_feeschedule.html
> Current ARIN Fee Schedule: https://www.arin.net/resources/fees/fee_schedule/
> 
>
>       So, to be clear – 
>
>  1. Organizations can put their IPv4 resources and IPv6 number resources under a single registration services plan and be invoiced one amount based on the
>     higher of the two categories of resources (IPv4 or IPv6) – but then the "annual limit on total maintenance fees for legacy resource holders regardless of
>     the number of legacy resources held” does not apply to that amount (since there’s more than just IPv4 legacy resources being provided services under that
>     plan),  _or_
>  2. Organizations can maintain a separate billing relationship for their IPv4 legacy resources and then the “annual limit on total maintenance fees for legacy
>     resource holders regardless of the number of legacy resources held” (aka “fee cap”) continues to be applied to their “IPv4 legacy maintenance fees”, exactly
>     as expected. 
> 
> The choice is entirely the customer’s –  either have one billing relationship and gain the benefit of being charged only one amount based the larger of the two
> resource size categories, or maintain separate relations for the IPv4 legacy resources and gain the benefit of annual total limit on maintenance fees for legacy
> resources.  
>
>       I don’t have questions in this process at all. I’ve had opinions and we disagree. I’ve expressed my opinions and you’ve expressed yours.
> 
> 
> I have not been expressing an opinion, but rather explaining how the ARIN fee schedule is actually defined and the fact that there is no “double billing”
> involved.  Customers can’t claim the legacy maintenance “fee cap” for registration service plans with IPv6 resources in them because the "fee cap" as defined is
> only applicable the registry fees for legacy resources held. 
> 
> 
> And I’ve been expressing both the facts of how the ARIN fee schedule has evolved to the detriment of end users and opinions as to whether that is fair to end users or
> not.
> 
> Further, as outlined above, I think you have some of your facts a bit off the mark.
> 
> Owen
> 
> 
>


More information about the ARIN-PPML mailing list