I would agree with Aaron1 that it's gratifying to see a public and relatively quick and thorough report. However, the write-up <https://www.arin.net/announcements/20251212/> raises questions for me: - What is "NPRM 4.10 space"? - I looked it up and think I somewhat understand that it's NRPM 4.10 <https://www.arin.net/participate/policy/nrpm/#4-10-dedicated-ipv4-allocation-to-facilitate-ipv6-deployment> :Dedicated IPv4 Allocation to Facilitate IPv6 Deployment ARIN shall allocate a contiguous /10 from its last /8 IPv4 allocation from IANA. This IPv4 allocation will be set aside and dedicated to facilitate IPv6 deployment. Allocations and assignments from this block must be justified by immediate IPv6 deployment requirements.... ---- - What exact space falls in this category? - How is it used? - How likely or not are the problems/fixes applicable to other things that ARIN is doing on behalf of its members? All in all, the write-up smacks a bit of "inside baseball <https://en.wikipedia.org/wiki/Inside_baseball_(metaphor)>" (from Wikipedia, linked: In North American slang, the term *inside baseball* refers to the minutiae and detailed inner workings of a system that are only interesting to, or appreciated by, experts, insiders, and aficionados.) Again, I appreciate the willingness and effort by the ARIN Staff and Leadership, just wanted to give a little more feedback. Thanks, Tony On Fri, Dec 12, 2025 at 2:21 PM Aaron1 via NANOG <nanog@lists.nanog.org> wrote:
An unfortunate occurrence. Respect to ARIN for owning it completely, and being transparent enough to share it with us.
Aaron
On Dec 12, 2025, at 11:28 AM, John Curran via NANOG < nanog@lists.nanog.org> wrote:
Chase (and the NANOG operator community) –
Apologies for not replying earlier, but I wanted to make sure we understood exactly what went wrong and had that written up as an incident report (i.e., rather than responding piecemeal and without full clarity).
Short version – ARIN failed here (as you noted in your post). We’ve published a public incident report that lays out what happened, the impact, and what we’re changing: https://www.arin.net/announcements/20251212/
This came down to some remaining manual handling around NRPM 4.10 space, which uses a sparse allocation model and wasn’t yet fully integrated into our automated inventory. That gap allowed your already in-use IPv4 /24 block to be mistaken as available and reissued to another customer. When it was removed and reissued, your associated ROA was removed as well, along with reverse DNS services, etc.
We had plans to automate our NRPM 4.10 inventory management (largely for efficiency reasons), but this incident and subsequent review showed that the remaining manual steps pose more risk than is reasonable. As a result, we’ve moved that work well up the priority list for development. In the meantime, and as detailed in the incident report, we’ve put additional controls in place – including a mandatory second review on any resource deletion from an organization – to prevent this from happening again.
I will also be reviewing our number resource inventory management practices internally (and with the ARIN Board of Trustees) to ensure there are not any other similar situations that might pose such a risk. My deepest apologies for this incident; we are acutely aware that the integrity of Internet number resources is essential to network operators, and thus it must be inherent to ARIN’s performance at all times.
Sincerely, /John
John Curran President and CEO American Registry for Internet Numbers
On Dec 9, 2025, at 1:19 PM, Chase via NANOG <nanog@lists.nanog.org> wrote:
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.
Best,
Chase Lauer
GalaxyGate, AS397031
https://galaxygate.net _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5MCMSACQ...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/FY3SDD72...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JJ5IYY6I...