AS58280

Membership costs in other RIRs

Max Stucchi — Wed, 24 Apr 2024 14:16:18 GMT

Membership costs in other RIRs. What would I pay somewhere else ?

During the upcoming RIPE88 Meeting in Krakow, there will be a RIPE NCC General Meeting, and a vote about the charging scheme for 2025 will be held.

The RIPE NCC has provided us with the options for voting, as set by the board. They are three, as follows:

Option A - Charging Scheme as is with 22.58% price increase for the annual contribution per LIR account (EUR 1,900) and a 0% price increase for Independent Internet number resource assignments* (EUR 50)
Option B - Charging Scheme as is with 20.97% price increase for the annual contribution per LIR account (EUR 1,875) and a 50% price increase for Independent Internet number resource assignments* (EUR 75)
Option C - Charging Scheme as is with 16.13% price increase for the annual contribution per LIR account (EUR 1,800), a 50% price increase for Independent Internet number resource assignments* (EUR 75) and a new AS Numbers fee of EUR 50 per assignment

This proposal has created a lot of discussions on both the RIPE Community Telegram Group and on the members-discuss mailing list.

On the ITNOG Telegram Group there were claims that RIPE NCC was the most expensive RIR to be a member of. This led me to start looking at what costs I would need to consider for my LIR if I ever wish to move it elsewhere.

My LIR has the following resources:

An ASN (AS58280, of course);
A /22 IPv4 (45.129.224.0/22);
Two /29 IPv6 (2a0e:5040::/29 and 2a0f:fd00::/29). The first one came as a direct allocation, while the second one came as a transfer, and has been used for research purposes for the last couple of years.

I have decided to check how much I would pay, with the same amount of resources, in other RIRs.

Just to set the tone, for RIPE NCC, my membership fees were 1550 euro plus VAT, so in total 1810.28 euro, as taken from my credit card statement.

AfriNIC

I headed to the AfriNIC fee calculator - https://afrinic.net/fee-calculator-nf, and filled it in as in the picture:

The total cost with current fees would be 3550 $. At first glance, this is around twice as much as the RIPE NCC fees, but there are only 1400 $ of recurring fees, while 2150 $ are for the "setup" and are non-recurring. I have asked on the ZANOG Discuss Telegram Group for more information about the proposed new fees, and was told that the initiative stalled when AfriNIC started having the issues we all know about.

APNIC

APNIC has a fee scheme where you pay based on the resources you hold. I went to the calculator for fees for Non-Members (https://www.apnic.net/get-ip/apnic-membership/how-much-does-it-cost/non-member-fees-calculator/), and filled it in as follows:

Which returned the following result:

There are some additional explanations:

If the resources specified above were held under a Member account, the base fee would be AUD $5,964, instead of AUD $6,858, yielding a saving of AUD $894.

IPv4 and IPv6 calculations are done separately. The fee charged is the greater of the two results.

Your Non-Member account renewal invoices will be calculated based on your resource holdings assessed as at the date of your Non-Member account anniversary.

 - Only applies to APNIC Non-Members
 - Estimated fees are based on the higher of IPv4 or IPv6 fees
 - Address holdings include current and historical resources
 - These estimates exclude Good and Services or consumption tax. This tax varies according to the Non-Member's economy and whether the organization is registered to pay such tax
 - Based on the 2024 Fee Schedule

Which means I would need to pay 6858 Australian Dollars, which amount roughly to 4458.39 $ on the day of writing.

If I were to become a member, I would pay 5964 Australian Dollars, about 3876.24 $.

As I said initially, my LIR could be a bit of an outlier, in the sense that the second /29 IPv6 allocation is not a normal condition. Without it, the costs would go down to 4552 Australian dollars (2961.12$) or 5235 Australian Dollars (3405.42$), wether I would decide to be a member or not.

ARIN

ARIN has a category-based model, which you can find at https://www.arin.net/resources/fees/fee_schedule/:

In my case, my LIR would fall into the "Small" category, mostly due to the IPv6 allocations, which amount to a /28. This would mean 2000 $ of recurring fees.

LACNIC

LACNIC is also based on categories, and you pay the highest amount between IPv4 and IPv6 and the category you end up in.

For IPv4 the categories are the following (from https://www.lacnic.net/5448/2/lacnic/):

There are more, bigger categories, but they are out of scope of this article.

As you can see, my LIR would fall into the Micro Category, which would have a renewal fee of 1000$, or 950$ if paid before the expiration date.

Looking at IPv6, we have the following categories (from https://www.lacnic.net/5450/2/lacnic/isp-ipv6-fees):

With 2x /29 - which account for a /28, my LIR would fall under the X Large category, which would mean having to pay 28000$, or 26600$ if paid before expiration date. As in the case of APNIC, my LIR is an outlier, but even with just a single /29 - which is the "most normal" allocation from the RIPE NCC, we would still be looking at 14000$, or 13300$ discounted.

Luckily, there is no fee for ASNs.

All in all, I would be billed 28000$, which is about 14 times what I pay at the RIPE NCC for the same amount of resources.

Summary

Here is a breakdown of what I would pay in all the RIRs, in a simple table. Everything in USD:

RIR	IPv4	IPv6	ASN	Payable Fee
AfriNIC	-	-	-	1.400,00
APNIC	1.515,04	4.458,39	-	4.458,39
ARIN	1.000 (X-Small)	2.000 (Small)	-	2.000,00
LACNIC	1.000 (Micro)	28.000 (X-Large)	-	28.000,00
RIPE NCC	-	-	-	1.657,11

For a better comparison, let's check what it would look like without the additional /29. Amounts are in USD:

RIR	IPv4	IPv6	ASN	Payable Fee
AfriNIC	-	-	-	1.400,00
APNIC	1.515,04	2.961,12	-	2.961,12
ARIN	1.000 (X-Small)	2.000 (Small)	-	2.000,00
LACNIC	1.000 (Micro)	14.000 (X-Large)	-	14.000,00
RIPE NCC	-	-	-	1.657,11

The two changes would be at APNIC and LACNIC, where LACNIC would see a 50% reduction in costs. Still, we are talking of almost 10x what I am actually paying at the RIPE NCC.

RIPE NCC scores as the second cheapest RIR to hold resources similar to what my LIR has. It is a simple fee that does not need any calculations. If the majority of voters were to choose option A, increasing fees to 1900 eur, that would bring RIPE NCC slightly above ARIN with actual exchange rate, at 2031.29$. With options B and C, it would still be below ARIN, albeit very close.

My LIR is a personal project, tied of course with AS58280, so of course I'm not particularly happy about increases in fees, but there are reasons for doing it at the moment. I will be participating in the BoF about building a stable future for the RIPE NCC at the upcoming RIPE88 meeting in Krakow, and I hope many other people will do as well, with the intent of creating a good discussion on how to keep the RIPE NCC running in these challenging times.

RPKI Origin Validation on Mikrotik

Max Stucchi — Tue, 17 Nov 2020 14:16:18 GMT

Configuring RPKI-based Route Origin Validation on Mikrotik

About a week ago, Mikrotik announced that the latest version of their OS - I mean, the beta version of RouterOSv7 - now has support for RPKI Origin Validation.

I have decided to try to configure it and report here.

Unfortunately, IPv6 BGP in RouterOSv7 Beta 8 is broken, in which it does not send any network announcement to the other peer in the BGP session. This means that at the time of this writing, my whole IPv6 configuration is broken, because I can't originate any IPv6 announcement from my network.

Anyway, on with the experiment. First of all we need to find our canary, a network that is covered by a ROA that makes it invalid. There is a route announced by Cloudflare that we can use, and it's all described in this article:

[admin@r1.btl.ch.as58280.net] /ipv6/route> print where dst-address="2606:4700:7000::/48"
Flags: D - DYNAMIC; I - INACTIVE, A - ACTIVE; b - BGP, m - MODEM
Columns: DST-ADDRESS, GATEWAY, DISTANCE
       DST-ADDRESS          GA  DI
  DIb  2606:4700:7000::/48  ::  20
  DIb  2606:4700:7000::/48  ::  20

As you can see, we are now receiving it. I am receiving a full IPv6 feed from OpenFactory - AS58299 at the moment.

We have to do work in three stages:

Install a validator. In this case we will use routinator from NLNetLabs. It's really easy to install, fast, and will fit here;
Set up a connection to the validator from the router. In this case I am running a RB4011;
Use the information we obtain from the validator to filter out the invalid networks.

1. Install routinator

I have been using FreeBSD for about 20 years, so I will go ahead with it. Routinator can also be installed on any Linux flavour.

On FreeBSD, we have a package, so I will go ahead with pkg.

root@routinator /root> pkg install routinator

Then configure to init it for the TALs

sudo -u routinator -g routinator routinator -c /usr/local/etc/routinator/routinator.conf init

sudo -u routinator -g routinator routinator -c /usr/local/etc/routinator/routinator.conf init --accept-arin-rpa

The first command actually errored out, so I first copy the config file manually, and then re-run those two commands.

root@routinator /root> cp /usr/local/etc/routinator/routinator.conf.example /usr/local/etc/routinator/routinator.conf

Additionally, I didn't have sudo, so I ran the commands as root and then I changed the owner of all the directories to be the routinator user.

I also changed the configuration so that the directory structure is more in line with what FreeBSD uses as standard hierarchy.

You can find the complete file here

The last thing to do is to configure routinator to run in rc.conf and then run it:

root@routinator /root> echo 'routinator_enable="YES"' >> /etc/rc.conf
root@routinator /root> /usr/local/etc/rc.d/routinator start

and now we have routinator running and listening on 45.129.224.37 port 3323.

This instance of routinator is available to use, and I'll soon setup a hostname for it.

2. Configure the RTR Session

Then, on to configuring our router. As you can see, we have a specific menu for RPKI:

[admin@r1.btl.ch.as58280.net] /routing/bgp>

.. -- go up to routing
advertisements --
connection --
peer-cache --
rpki --
template --

The work we have to do is divided in two parts:

Setting up communication to the routinator instance; and
Setting up our filters so that we filter based on RPKI.

First of all, we have to configure the RTR Session. We will connect to the routinator instance we have set up previously, so here:

[admin@r1.btl.ch.as58280.net] /routing/bgp/rpki> add address=45.129.224.37 port=3323 preference=1

and I got an error while trying to print the entries:

[admin@r1.btl.ch.as58280.net] /routing/bgp/rpki> print
Flags: X - disabled
 0   ;;; group name must be specified
     address=45.129.224.37 port=3323 preference=1
[admin@r1.btl.ch.as58280.net] /routing/bgp/rpki> set 0 group=

Group ::=


[admin@r1.btl.ch.as58280.net] /routing/bgp/rpki> set 0 group=validator
[admin@r1.btl.ch.as58280.net] /routing/bgp/rpki> print
Flags: X - disabled
 0   group=validator address=45.129.224.37 port=3323 preference=1
[admin@r1.btl.ch.as58280.net] /routing/bgp/rpki>

Turns out you can configure groups of validators to talk to, and I later on discovered that in your filters you can point to these specific groups. That looks like an interesting feature.

3. Configure the filters

Let's go ahead and see what we need to do next with the filters.

[admin@r1.btl.ch.as58280.net] /routing/filter/rule> add action=accept chain=in-v6 rpki-verify=validator rpki-match=valid
[admin@r1.btl.ch.as58280.net] /routing/filter/rule> add chain=in-v6 action=reject match-rpki=invalid

and then we need to add this filter chain to the template we use for BGP. In /routing/bgp/template/ I have the following:

[admin@r1.btl.ch.as58280.net] /routing/bgp/template> print
Flags: * - default, X - disabled, I - inactive
 0 * ;;; reserved AS value
     name="default" instance=default

 1   name="stucchinet4" routing-table=main as=58280 address-families=ip,ipv6
     output.filter=out-v4 .network=45.129.224.0/22

 2   name="stucchinet6" routing-table=main instance=default apply-changes=auto as=58280 address-families=ipv6 output.filter="" .network=""

And especially for the IPv6 template, I have no input.filter set, yet. So let's go ahead and add it:

[admin@r1.btl.ch.as58280.net] /routing/bgp/template> set 2 input.filter=in-v6
[admin@r1.btl.ch.as58280.net] /routing/bgp/template> print
Flags: * - default, X - disabled, I - inactive
 0 * ;;; reserved AS value
     name="default" instance=default

 1   name="stucchinet4" routing-table=main as=58280 address-families=ip,ipv6
     output.filter=out-v4 .network=45.129.224.0/22

 2   name="stucchinet6" routing-table=main instance=default apply-changes=auto as=58280 address-families=ipv6 output.filter="" .network=""
     input.filter=in-v6

and there it is.

4. Check the result

Let's now check if Origin Validation gets applied:

[admin@r1.btl.ch.as58280.net] /routing/bgp/template> /ipv6 route/
[admin@r1.btl.ch.as58280.net] /ipv6/route> print where dst-address="2606:4700:7000::/48"

[admin@r1.btl.ch.as58280.net] /ipv6/route>

Here we go! The prefix is not visible anymore and gets filtered out.

You might have to disable and re-enable the BGP Session for the filter to kick in.

This is the end. Besides the issues with IPv6 BGP, it seems that Mikrotik is going towards a nice result with this, so I hope they work quickly on making RouterOS v7 available for production, and hopefully this will increase RPKI adoption around the World, and will make Job Snijders happy... :)