CAIDA and Internet2 are working on a tool to assist network operators plan their RPKI-ROAs
You can kick the tires here: https://rootbeer.testing.ns.internet2.edu/roa-planner/ The implementation remains fragile and will be unavailable intermittently, but we hope to improve it over the next couple of weeks. Please send me (ssw@internet2.edu) any suggestions, concerns, etc. From the help page: The RPKI-ROA Planner is a tool designed to help network operators efficiently plan their Route Origin Authorizations (ROAs), which are vital for securing BGP routing. To generate a comprehensive set of ROA recommendations for a user-supplied IP prefix, the Planner aggregates routing and registration information from four key sources: - Internet Routing Registry (IRR): Route Objects are gathered from services like https://stat.ripe.net/data/whois/. - Regional Internet Registries (RIRs): IP registration data is fetched from sources such as https://rdap.arin.net/registry/ip/. - Routing History: Historical routing data is analyzed using services like RIPEstat (https://stat.ripe.net/data/routing-history). - Global Route Views: The Planner includes routes observed in the global research and education community (via Routeviews). Crucially, these routes may be longer (more specific) than those typically seen in the Default-Free Zone (DFZ). Assumption: If a route was observed in the past, is currently visible, or is documented in an IRR object, it is a candidate for a new ROA. It excludes any candidate routes that are already covered by an existing, valid ROA, ensuring you only focus on what's missing. All candidate routes are presented to you in the table. You have full control to deselect individual routes or use age filters to exclude older, potentially stale data before the final ROA set is calculated. The Planner prioritizes generating multi-prefix ROAs (covering multiple routes with one authorization) over single-prefix ROAs. Using multi-prefix ROAs is the recommended best practice for maintaining cleaner, more efficient RPKI records. thanks! Steven Wallace Director - Routing Integrity Internet2 ssw@internet2.edu
* Steven Wallace [Thu 30 Oct 2025, 18:26 CET]:
You can kick the tires here: https://rootbeer.testing.ns.internet2.edu/roa-planner/
So basically you replicated https://irrexplorer.nlnog.net/ but in a more ARIN-like colour scheme? -- Niels.
Hi Niels and Steven, On 2025-10-31 04:17, niels=nanog--- via NANOG wrote:
So basically you replicated https://irrexplorer.nlnog.net/ but in a more ARIN-like colour scheme?
IRR explorer only shows the current state of the IRR/RPKI, whereas this tool also considers historical data, which might be useful if you are not permanently announcing your prefix? And I guess the main point is to give recommendations of what to do if ROAs are missing. I am more surprised by the "Best Practice" tag on the "Required Multi-prefix ROAs" tab, I assume this should be on the "Single Prefix ROAs" tab (see RFC9455 [0]). Nitpick: "Multi-prefix" vs. "Single Prefix" spelling consistency Malte [0] https://www.rfc-editor.org/rfc/rfc9455.html
Dear Malte, On Fri, Oct 31, 2025 at 06:11:09AM +0900, Malte Tashiro via NANOG wrote:
I am more surprised by the "Best Practice" tag on the "Required Multi-prefix ROAs" tab, I assume this should be on the "Single Prefix ROAs" tab (see RFC9455 [0]).
RFC 9455 essentially recommends to "maximally deaggregate" prefix information into distinct ROA objects, however, this practise results a massive overhead for the validation process in RPKI caches. I believe these effects previously were underestimated: this practise seems to result in non-linear growth of resource consumption. With progressive insight, BCP 238 is *NOT* the best practise for the general case. The growth patterns observed in the global RPKI in the last two years lead me to believe that RFC 9455 needs to be revised. When ROAs are created through RIR-hosted systems (ARIN Online, the RIPE NCC LIR Portal, MiLACNIC, etc), those systems SHOULD bundle as many prefixes into as few ROAs as possible in order to conserve resources (cpu/storage) in the RPKI caches around the planet. RFC 9455 Section 4 contains too little nuance and lacks guidance when exactly bundling or deaggregation are helpful, and the tiny warning about "may increase the file-fetch burden" in Section 5 turns out to be a lot more taxing than expected. Kind regards, Job
We’ve found that including routing history is invaluable when assisting network operators with their ROA planning. A few real-world examples illustrate how this context has helped: • Cold-site business continuity: Some organizations announce more specific prefixes from a different origin AS when activating a cold-site. Routing history reveals this behavior, ensuring the corresponding ROA is in place so the cold-site can operate as intended during an event. • Mobile/off-site operations: Enterprises that temporarily announce their IP space from off-site locations (e.g., conferences or remote events) often use a different origin AS. Without routing history, these temporary announcements are easily overlooked, resulting in missing ROAs. In both cases, routing history exposed announcement patterns the operators themselves had forgotten or were unaware of—and without it, they likely would have missed required ROAs. Beyond routing history, combining RIR allocation/assignment data with a visually indented prefix hierarchy helps operators quickly spot stale or unnecessary assignments and confirm the complete set of ROAs needed. The ROA Planner is modeled on an internal tool we developed to support operators in precisely these scenarios.
[sad] Ron Yokubaitis reacted to your message: ________________________________ From: Steven Wallace via NANOG <nanog@lists.nanog.org> Sent: Thursday, October 30, 2025 5:25:44 PM To: nanog@nanog.org <nanog@nanog.org>; North American Network Operators Group <nanog@lists.nanog.org> Cc: James Deaton <jdeaton@internet2.edu>; Matthew Luckie <mjl@caida.org>; Steven Wallace <ssw@internet2.edu> Subject: CAIDA and Internet2 are working on a tool to assist network operators plan their RPKI-ROAs You can kick the tires here: https://urldefense.proofpoint.com/v2/url?u=https-3A__rootbeer.testing.ns.internet2.edu_roa-2Dplanner_&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cGrDT0liF-gD_o4EJ7o_qg&m=wgmMkIOXEorDvhnLu0EJRyq7vJxH6Hnj012onAvwwg5ZVYQgmVs3NAIm0zh_7q7U&s=fRGzTIu9XgEHcCsmSt5vowLRVplth4M46c3JhOlU8s4&e= The implementation remains fragile and will be unavailable intermittently, but we hope to improve it over the next couple of weeks. Please send me (ssw@internet2.edu) any suggestions, concerns, etc. From the help page: The RPKI-ROA Planner is a tool designed to help network operators efficiently plan their Route Origin Authorizations (ROAs), which are vital for securing BGP routing. To generate a comprehensive set of ROA recommendations for a user-supplied IP prefix, the Planner aggregates routing and registration information from four key sources: - Internet Routing Registry (IRR): Route Objects are gathered from services like https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ripe.net_data_whois_&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cGrDT0liF-gD_o4EJ7o_qg&m=wgmMkIOXEorDvhnLu0EJRyq7vJxH6Hnj012onAvwwg5ZVYQgmVs3NAIm0zh_7q7U&s=_t175830ywF6B-Uhst1GMDbcXEvqcMOxiAkphHtjlDA&e=. - Regional Internet Registries (RIRs): IP registration data is fetched from sources such as https://urldefense.proofpoint.com/v2/url?u=https-3A__rdap.arin.net_registry_ip_&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cGrDT0liF-gD_o4EJ7o_qg&m=wgmMkIOXEorDvhnLu0EJRyq7vJxH6Hnj012onAvwwg5ZVYQgmVs3NAIm0zh_7q7U&s=m6dfLp0D89Cuzoq6K8yVAFNKuLq_PRfmMIw2gIUO6MI&e=. - Routing History: Historical routing data is analyzed using services like RIPEstat (https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ripe.net_data_routing-2Dhistory&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cGrDT0liF-gD_o4EJ7o_qg&m=wgmMkIOXEorDvhnLu0EJRyq7vJxH6Hnj012onAvwwg5ZVYQgmVs3NAIm0zh_7q7U&s=to3En-Oyq78eiAq3wxYqpsaI5FnBPcMxmrCqgYadZng&e=). - Global Route Views: The Planner includes routes observed in the global research and education community (via Routeviews). Crucially, these routes may be longer (more specific) than those typically seen in the Default-Free Zone (DFZ). Assumption: If a route was observed in the past, is currently visible, or is documented in an IRR object, it is a candidate for a new ROA. It excludes any candidate routes that are already covered by an existing, valid ROA, ensuring you only focus on what's missing. All candidate routes are presented to you in the table. You have full control to deselect individual routes or use age filters to exclude older, potentially stale data before the final ROA set is calculated. The Planner prioritizes generating multi-prefix ROAs (covering multiple routes with one authorization) over single-prefix ROAs. Using multi-prefix ROAs is the recommended best practice for maintaining cleaner, more efficient RPKI records. thanks! Steven Wallace Director - Routing Integrity Internet2 ssw@internet2.edu _______________________________________________ NANOG mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.nanog.org_archives_list_nanog-40lists.nanog.org_message_POCE6AEW6H4JWERF5TE5V3YLDBCS3WT6_&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cGrDT0liF-gD_o4EJ7o_qg&m=wgmMkIOXEorDvhnLu0EJRyq7vJxH6Hnj012onAvwwg5ZVYQgmVs3NAIm0zh_7q7U&s=3Ril4s1OcaHzkd4l_be6OvyBdMwdP5HmJGS5-Lumf0s&e=
"[sad] Ron Yokubaitis reacted to your message:" Why do we all need to care about a reaction to a msg? Also, I didn't deep dive into internet2 but from my understanding it's just leased light pathways from the same people we all use. What they do with the photons is the own thing. feels like a waste of $$ but perhaps I am wrong. - Javier
On 2025-10-31 11:19, Ron Yokubaitis via NANOG wrote:
[sad] Ron Yokubaitis reacted to your message:
FYI list-ops (and individual people): Outlook reactions can be disabled <https://meta.discourse.org/t/disallow-outlook-emoji-reactions/380418?u=supermathie> by adding a header: x-ms-reactions: disallow (this could be added to the list's config)
On 10/31/2025 12:13 PM, Michael Brown via NANOG wrote:
On 2025-10-31 11:19, Ron Yokubaitis via NANOG wrote:
[sad] Ron Yokubaitis reacted to your message:
FYI list-ops (and individual people): Outlook reactions can be disabled <https://meta.discourse.org/t/disallow-outlook-emoji-reactions/380418?u=supermathie> by adding a header:
Wow. Microsoft continues to make email worse. Remember inline threading? Lee
participants (9)
-
Javier J -
Job Snijders -
Lee Howard -
Malte Tashiro -
Michael Brown -
niels=nanog＠bakker.net -
Ron Yokubaitis -
ssw＠internet2.edu -
Steven Wallace