As you might know already, on May 24, 2024, at the RIPE NCC General Meeting, model C for the 2025 charging scheme was adopted. I will not go into the details here, such as the lack of an option to preserve the status quo1, but model C involved adding an annual fee of 50 EUR per ASN, billed to the sponsoring LIR. This meant that the sponsoring LIR for AS200351 would be forced to bill me annually for at least 50 EUR for the ASN, plus some administrative overhead and fees for payment processing2.

To protest against this fee and save myself some money, I decided to transfer AS200351 to ARIN, which charges no extra for me to hold an additional ASN, given that my current service category at ARIN allows up to 3 ASNs, and I only had one ASN already with ARIN: AS54148.

And so, on June 2nd, I decided to initiate the process to transfer AS200351, which was in active use, to ARIN. As it turned out, this became an ordeal, especially on the RIPE NCC end. Since I’ve been asked many times about the process, I am writing this post to share my experience, so that you know what to expect.

Initiating the process

The inter-RIR transfer process is deceptively simple and documented on this page on the RIPE website. In essence, ASNs can be transferred from RIPE to ARIN and APNIC3. For “scarce resources” like 16-bit ASNs, you must wait for 2 years after it was issued to you before you can initiate the transfer. Since AS200351 wasn’t deemed a “scarce resource”, I wasn’t subjected to the waiting period, so that wasn’t a blocker.

Then, if you are an LIR, you can deal directly with the RIPE NCC, but if your ASN is sponsored by an LIR, you must do all communication through that LIR. The process is the same either way, the only difference being whether someone has to forward the messages between you and the RIPE NCC. Since I wasn’t an LIR and AS200351 was sponsored, I was forced to play the game of telephone.

To initiate the transfer, I simply followed the instructions and filled in the inter-RIR transfer template. It should be pretty self-explanatory, but contains quite a bit of PII so I won’t be sharing the exact template I filled in.

While RIPE lists the confirmation letter as something to be done later, to save time I also completed and signed it while preparing the inter-RIR transfer template. I simply downloaded the confirmation letter template from the RIPE website, filled out everything between square brackets, and generated a signed PDF.

I then sent the prepared transfer template and the confirmation letter to my LIR sponsor, who simply sent the information to [email protected], following the documented procedure. So far so good.

Demands from the RIPE NCC

Then, my LIR reached out to me with two requests from the RIPE NCC.

The first was simple: I needed to perform identity verification to ensure that I was who I claimed to be and I wasn’t stealing someone else’s ASN. This is the same procedure that RIPE uses during the initial ASN allocation. Essentially, as a natural person, I had to complete an ID verification from this third-party company named iDenfy. This was easy. If you are doing this as a legal entity, you would instead need to present a recent registration document from the relevant authorities, such as a certificate of incorporation.

However, the second request is quite troubling, because the RIPE NCC demanded that I delete every single route and route6 objects in the RIPE database with origin: AS200351. What the !@(#?

Deleting route objects

For those of you who haven’t read my post on route authorization, you should read it for a better understanding. Essentially, for AS200351 to be allowed to announce an IP prefix, a route object has to exist in a trusted IRR database with AS200351 as the allowed origin. Most people these days will only accept authenticated IRR sources, which effectively means the IRR database of the RIR who controls the IP prefix. The lack of a route object means that you can’t announce the prefix.

Let’s take a look at 2a07:54c1:dead::/48, which AS200351 was announcing when I initiated the inter-RIR transfer. For that route to be accepted, I had to create a route6 object for 2a07:54c1:dead::/48 with origin: AS200351. Since 2a07:54c1:dead::/48 was managed by RIPE, I had nowhere else to create the route6 object, and RIPE demanded that I delete it from their database before they’d let the transfer proceed.

What does this mean for my network? It means I couldn’t announce any RIPE prefixes from AS200351 while the inter-RIR transfer was ongoing. Effectively, RIPE told me to dismantle my entire network before they’d let me transfer the ASN.

This is ridiculous, especially since you can, in fact, announce RIPE prefixes from non-RIPE ASNs. You can simply create a route6 object for 2a07:54c1:dead::/48 with origin: AS54148 and RIPE won’t even bat an eye. So it makes absolutely no sense to demand that I remove route objects from the RIPE database, since I intended to announce the same prefixes from the same ASN after the transfer.

Worse, this wasn’t even documented in the inter-RIR resource transfer process, so it came straight out of the blue.

Fortunately for me, I’d already renumbered most of my network to use my ARIN prefixes, which use the ARIN IRR. This meant that I didn’t actually have to dismantle most of my network just to do this. I “simply” had to deal with the few remaining RIPE prefixes.

Sorting out RIPE prefixes

So what do I do with the few RIPE prefixes I have? I decided to move them to AS54148 instead. This is also easier said than done, especially since I am using RPKI.

For all the prefixes I owned, I simply created route6 objects for them with origin: AS54148. For the ones whose RPKI was delegated to me, I just created an ROA authorizing AS54148 to announce the prefix. However, this wasn’t the case for all the prefixes.

For some, I had to track down the actual owners of the IP space and bug them to create ROAs or route objects on my behalf, which wasn’t fun…

Once that was sorted, I simply started announcing the prefixes from AS54148 and withdrew them from AS200351. Surprisingly, at the time of writing, some routes from AS200351 are still stuck and visible in route collectors, even though basically all the traffic is going to AS54148.

Then, I deleted all the route objects… that I could.

Undeletable prefixes

You see, a bunch of people created route objects pointing to my ASN, but without giving me any control over those objects. Since I lacked mnt-by on the route objects, I was unable to delete them. Surely the RIPE NCC didn’t expect me to magically delete those?

So I told my LIR that I deleted all the route objects that I could, but had difficulties with deleting the ones on which I had no mnt-by to delete. The RIPE NCC unsympathetically demanded that I delete them anyway, through whatever magical power they expected me to have. So I had no choice but to reach out to those people creating route objects to delete them, and surprisingly, they all did.

So this effectively means that if you create a route object in the RIPE database pointing to someone else’s ASN and then refuse to delete it, the victim will never be able to transfer their ASN away from RIPE. This seems terribly broken.

Dealing with ARIN

At this point, while I was struggling to get all the route object owners to delete them, ARIN reached out to me, saying that RIPE has approved the transfer of AS200351, and that I must open a ticket on the ARIN end to process the reception. This raised more questions, such as why RIPE apparently “approved the transfer” before the route deletion game was finished. I unfortunately don’t have a satisfactory answer to this…

Back to ARIN. Under their policy, an inter-RIR transfer is called an NRPM section 8.4 transfer, and to receive any resource this way, I must open an “8.4 recipient transfer request”. ARIN helpfully gave me the instructions in the email (transcribed verbatim):

-select Transfer Resources from the menu on the left

Answer the questions under 'About Your Transfer', as follows:

1. Are both the source and recipient organizations within the ARIN Region? - No
2. Will you be receiving or supplying resources? - Receiving
3. Have you identified the other party involved in this transfer? - Yes

You will be directed to the 8.4 Recipient Transfer request, select CONTINUE located in the lower right corner.

4. Have you received an email from ARIN containing a linked ticket identifier? Yes

Linked Ticket Identifier: [redacted]

-select Organization Identifier (ORG ID): [redacted]
-select ‘Next Step’ located in the lower right corner
-select ‘Next Step’ located in the lower right corner
-select ‘Submit’

Note that you could have opened this ticket on the ARIN end before the RIPE NCC reached out to them. In that case, simply say you didn’t have a linked ticket identifier. The procedure is the same.

Once I opened the ticket, ARIN took some time to review the request. Here’s the timeline:

  • June 4th: I received the email from ARIN and opened the ticket.
  • June 6th: ARIN replied to my ticket, requesting justification for owning a second ASN. This is because ARIN operates based on a “needs-based” policy, which requires every resource you own to have a valid justification, even for transfers.
  • June 6th: I replied to ARIN with my justification for AS200351.
  • June 10th: ARIN approved the transfer and stated that they are working with the RIPE NCC to complete the transfer.
  • June 12th: the ASN was actually transferred. The aut-num object was deleted from the RIPE NCC database and AS200351 showed up in ARIN’s database.

Ripple effects

For the next little while, a bunch of places, such as bgp.tools, were displaying the name of AS200351 as ASN block not managed by the RIPE NCC. This took a while to clear up.

Then, the RIPE NCC reached out to the maintainer of every AS-set in the RIPE database, asking them to remove AS200351. This is ridiculous, since AS200351 still remains the downstream of all its upstreams pre-transfer, and there is no reason why anyone should be removing the ASN from AS-sets. Fortunately, all my upstreams appeared to have ignored the email, but this still created a lot of additional toil for a bunch of random people…

Also fun fact: at the time of writing, on RIPE’s inter-RIR ASN transfer stats page (see the “transfers from the RIPE NCC” tab), it claims that AS200351 was transferred to APNIC, despite it having clearly been transferred to ARIN. Furthermore, the table is sorted by day first instead of year first, which is… less than useful. Hopefully by the time you’ve read this, they’ve fixed their bookkeeping, but here’s what I see at the time of writing:

A screenshot of RIPE claiming that AS200351 was transferred to APNIC

Conclusion

The RIPE NCC’s handling of outgoing inter-RIR transfers of ASNs leaves much to be desired, including effectively forcing people to dismantle their networks. To their credit, they handled the transfer on their end in 2 days, which was much quicker than ARIN.

What should I have done?

In retrospect, I think it probably would have been easier and less painful for me to simply do a full renumber to AS54148 instead. Then, I could just delete all the routes and then transfer the ASN without any active routes or upstreams to ARIN, which would greatly reduce the headache for myself and all my upstreams. I’d still have a ton of problems with the random route objects that I couldn’t delete, so maybe the smarter thing for me to do would be just returning AS200351 back to RIPE’s free pool, but I am rather attached to the number…

Notes

  1. Essentially, all three options for the vote are “hike fees”, just in different ways. Model A hikes just the annual fee, while model B hikes the PI resource sponsorship annual fee, and model C adds the annual ASN fee on top of the PI resource hike. RIPE NCC was not receptive to a petition by over 700 LIRs to keep the fees the same for 2025. ↩

  2. Yes, this means that anyone who offers you an ASN for a one-time fee will be forced to charge you an annual fee, and anyone still offering that after May 24th hasn’t updated pricing. Expect to pay at least 50 EUR per RIPE ASN per year from now on. ↩

  3. If you are transferring to APNIC, I expect the procedure to be the same on the RIPE end, but I have no experience with APNIC to say what happens on that end. ↩