Arin Public Incident Report – 4.10 Misissuance Error
Key topics
A recent misissuance error by ARIN, a regional internet registry, has sparked a lively discussion about the incident and its implications. Commenters are weighing in on the trade-offs between manual and automated processes, with some noting that automation is a necessary step forward, while others worry about the potential risks. The conversation is also touching on the topic of fees, with some pointing out that ARIN is now cheaper than RIPE for small entities, while others argue that many organizations are already paying reduced rates through sponsoring LIRs. As one commenter dryly notes, "The road to automation is always full of outages."
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
15m
Peak period
13
0-2h
Avg / period
5.4
Based on 38 loaded comments
Key moments
- 01Story posted
Dec 21, 2025 at 10:19 AM EST
15 days ago
Step 01 - 02First comment
Dec 21, 2025 at 10:34 AM EST
15m after posting
Step 02 - 03Peak activity
13 comments in 0-2h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 22, 2025 at 4:03 PM EST
13 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
On a sidenote, what I appreciate in both RIPE and ARIN is that you can have at least a proper discussion when you have valid arguments with their support teams.
- ARIN 2026 PDF: https://www.arin.net/resources/fees/images/2026feeschedule.p...
- RIPE 2026 : https://www.ripe.net/membership/payment/
Enthusiasts, trainees and small orgs are paying a lot more with RIPE.
You must have a sponsoring LIR for your resources or become a LIR yourself. The only exception is LEGACY resources (IPv4, no ASN) but that's a different story.
It’s also cheaper for me because I have legacy ARIN space. All I really needed was an ASN. The LIR gives me some PA v6 space for cheap, too.
As ARIN block owner this situation is kinda scary but reading this actually makes me think it's less likely to happen again .
> We have to automate the process.
to be ominous?
“Automate the process” doesn’t mean feeding everything to an LLM.
Having worked at a mom and pop ISP a couple of decades ago where we used Excel to track a lot of things, I can see how this might have happened.
To actually know who is allocated what is ultimately just a list.
And when there are only a few people who edit the list (and probably no more than 1 person at a time) you can get by with even a plain text file, but Excel is quite a bit nicer as you can do things like filtering and sorting easily, maybe even some formulas to help with things.
Building a program backed by a database might be nice, but hard to justify when the manual system has never been a problem before.
They’ve probably been thinking for a while they should, but it’s just never been enough of a pain point for them to invest the effort.
Looks like they see this incident as justification that they need a system with hard coded rules and constraints, no more manual checking.
I'm more surprised that a single person, apparently without seniority, could delete a block. IME deleting user data is usually a significant event; an IP block would especially be a big deal, especially for the IP block issuers. From the OP:
> RSD has implemented additional process controls that require a dual review for all ticketing type workflows that include a network delete.
> Only a limited set of experienced analysts are permitted to perform this function.
Great that they didn't blame the person who deleted it. ARIN seems to have put them in position where a failure was likely, eventually. Without any inside knowledge, I'd hope the culture would have any engineer leary about pressing that button without a second set of eyes reviewing it carefully and without clear authorization; I don't imagine they delete many blocks each day so it shouldn't interfere with productivity.
This is a really big egg on face moment for ARIN, but it sounds like they are responding appropriately.
Hey NANOG,
After receiving a BGPAlerter notification that one of our subnets (23.150.164.0/24) had been hijacked, I checked and noticed the prefix in question was missing RPKI. Assuming I had fat fingered something and butchered the ROA, I logged into ARIN and found that the prefix was missing from our resource list entirely, and had been reallocated to another organization and announced from their network. I created a ticket in ARIN and called immediately.
They confirmed that our subnet had been accidentally reallocated to another customer, and that they are currently working on returning it to us. After a couple hours, they told us the other organization will stop announcing the prefix, and WHOIS will be returned shortly.
I’m guessing there’s no way to prevent this kind of thing on our side if the RPKI ROA itself is removed along with the allocation? I’m planning on adding checks to look for missing ROAs (in addition to invalid/expiring ones), which I'm guessing would've caught this earlier.
Have any of you had anything like this happen with ARIN or another RIR? I’m especially curious what might have happened if we’d only noticed and reached out a few weeks later instead of within a few minutes.
I periodically see people showing up early in comment threads posted about things they've written or articles where they're the subject. Usually I figure they've got a Google alert or some other whatsit, or they've got something monitoring referers in their web traffic. But this is a case where neither would apply.
This is likely; I can't imagine a regular HN user would appreciate having their subnet publicly available in their comment history.
> The incorrect state persisted for approximately seven days before detection
However you're saying you've reached out "within a few minutes" ?
The "hijacking" happened later, when the IP prefix was announced via BGP by the registrant who it was incorrectly assigned to. Those are two different events.
What's scary is that IPv4 allocations are literally internet infrastructure. Having your /24 suddenly reassigned to someone else could be catastrophic for a business.
The fact that RPKI didn't catch this is interesting. The ROA was deleted along with the allocation, so from RPKI's perspective everything was valid. This is a good reminder that RPKI protects against hijacking but not against the RIR itself making mistakes.
Glad they're automating this. Anything involving copy-pasting IP ranges in Excel is an accident waiting to happen.
I just completed a fairly major reorganisation of resources with RIPE, and I’ve interacted with them for two decades, and my experience is they remain as steady and consistent as ever.
Sure, you may not like a particular policy at some moment, or may not agree with the charging structure at some point in time when it’s not advantageous to you, but they do at least do what they say and say what they do.
1 more comments available on Hacker News