Responses in line below. From: Tony Tauber via NANOG <nanog@lists.nanog.org> Date: Friday, December 12, 2025 at 2:50 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Chase <chase@galaxygate.net>, John Curran <jcurran@arin.net>, Tony Tauber <ttauber@1-4-5.net> Subject: Re: Accidental ARIN Reallocation 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.... ---- - [ARIN] This is a reserved IPv4 block set aside to facilitate IPv6 deployment under NRPM 4.10. Allocations and assignments from this space must be justified by an immediate IPv6 deployment need. Only one /24 can be requested per organization every 6 months if all policy conditions are met. What exact space falls in this category? -[ARIN] The community set aside 23.128.0.0/10 as the NRPM 4.10 IPv4 reserve for IPv6 transition. This /10 represents 0.3% of our total IPv4 inventory. Total starting pool: 23.128.0.0/10 (16,384 /24s) Remaining in the pool: 13,167 /24s Average Issuance: ~55 /24s a month Customers with 4.10 space: 2,386 unique Org IDs, 2,116 (89%) of which have only a single 4.10 /24 How is it used? - [ARIN] NRPM 4.10 space is issued to support organizations' IPv6 transition and translation services. Of the 16,384 /24s in the reserve, 3,217 (about 20%) have been issued to 2,386 customers. These 4.10 allocations represent roughly 0.05% of ARIN's total allocated IPv4 space. How likely or not are the problems/fixes applicable to other things that ARIN is doing on behalf of its members? - [ARIN] The issues and fixes we identified are mostly specific to the way NRPM 4.10 space is issued. However, the same delete function is used in a small number of other workflows, such as Inter-RIR transfers, the IPv4 Waiting List, cleanup of outdated SWIPs, and certain Ask ARIN requests to merge or split networks. This delete function is used infrequently and is only authorized for designated senior analysts and management. ARIN has strengthened the related review controls as part of our corrective actions.- 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...