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 <[email protected]> wrote:
On 7 Apr 2022, at 1:16 PM, Owen DeLong <[email protected]> wrote:
Moved to ARIN-PPML per your previous advice and your request below...
On Apr 7, 2022, at 09:25 , John Curran <[email protected]> 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
_______________________________________________
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.
