Hi Martin, NANOG, Thanks for sharing a guide how to locally set up IRR mirroring. Running IRRd v4 yourself is a good way to reduce external dependencies and ensure external inputs are scrubbed to some degree (e.g., using RPKI data). On Fri, Oct 23, 2026 at 12:44:19PM +0300, Martin Tonusoo via NANOG wrote:
* With possible temporary exceptions related to inter-RIR transfers, there are no route objects with overlapping prefixes in APNIC, LACNIC, RIPE, AFRINIC, ARIN and REGISTROBR. That is, RIR-operated authoritative IRR databases do not have out-of-region route objects. Adding any other source, including NIR-operated JPIRR, introduces overlaps with authoritative databases. According to study [2] using IRR data from 2021 to 2023 there were route objects with overlapping prefixes in RIR-operated authoritative databases.
I don't think overlapping prefixes in RIR-operated authoritative databases will make a comeback. I have some historic background to share as I invested quite some effort to help bring the industry to the point that RIR-operated authoritative IRR databases no longer contain any out-of-region route objects (and even if they do, ensure that any IRR objects conflicting with RPKI information do not propagate). Timeline how we got here: * RIPE NCC split its auth and non-auth contents into 'RIPE' and 'RIPE-NONAUTH' in 2018 https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implem... * RIPE NCC starts cleaning up RIPE-NONAUTH in November 2019 https://www.ripe.net/publications/docs/ripe-731/ * LACNIC launched its IRR database as 'auth only' from the get-go in 2020 https://blog.lacnic.net/en/lacnics-irr-begins-operating/ * ARIN split its auth and non-auth into 'ARIN' and 'ARIN-NONAUTH' in 2020 https://lists.arin.net/pipermail/arin-announce/2020-June/002439.html * ARIN then deprecated ARIN-NONAUTH in 2022 https://lists.arin.net/pipermail/arin-announce/2022-April/002637.html [[ But, there was a parallel effort, a "plan B" so to speak: weeding out non-authoritative information at the "bgpq3/bgpq4 layer" by having the world's most popular IRR mirrors use RPKI-ROA based filtering. Slide #16 & #17 briefly explain & visualize the filter attachment point: https://iepg.org/2018-11-04-ietf103/IETF103_Snijders_Routing_security_roadma... ]] * In 2022 NTT enabled "RPKI-aware mode" in their IRRd v4 instance for security and to seamlessly integrate IRR and RPKI. Then, inspired by NTT's example and encouraged by many, RADB also deployed RPKI-based filtering on whois.radb.net in Q4 2023: https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Z34BLVUS... And with that, a multi-year effort came to a fantastic conclusion: RPKI ROAs actively hamper propagation of invalid IRR objects throughout the IRR replication ecosystem nowadays. Consequently, non-authoritative information, if any, is either aligned with RPKI ROAs, or filtered out. A new world order! :-)
* RIPE is an only RIR-operated authoritative IRR which provides NRTMv4 access.
NRTMv4 has been standardized and is about to be published as RFC-to-be 10063. Hopefully this will encourage more parties to invest in offering NRTM v4.
* virtual machine spec for running such IRRd installation: 4x vCPU, 96 GiB of RAM, 200 GB of disk space; /etc/redis/redis.conf has "maxmemory 6gb" configured
I suspect this is why rr.ntt.net & whois.radb.net remain popular services! :-) Kind regards, Job