Re: Local Internet Routing Registry (IRR) server setup for route filtering

[Job Snijders via NANOG <nanog () lists nanog org>]

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-implementation/

* 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_roadmap-v2.pdf
]]

* 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/Z34BLVUSL2NRDCTTMO6IVLAAGVQUQXFO/

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
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/ZB6E2SNMOYK6EDZHJZ3CS3JJEGWQGAKJ/