RPKI-ROA Planner

Important Disclaimer

This service is provided by Internet2 on an "as is" and "as available" basis, without any warranties—express or implied—including, but not to, warranties of accuracy, completeness, merchantability, or fitness for a particular purpose.

The information and recommendations produced by this tool are intended for informational purposes only. You are solely responsible for verifying the accuracy and suitability of any RPKI Route Origin Authorizations (ROAs) you create or modify based on the output of this service.

Incorrect ROAs can result in partial or complete loss of connectivity for your organization's networks.

Internet2 accepts no liability for any direct, indirect, incidental, or consequential damages arising from the use of, or reliance upon, this service.

By using this service, you acknowledge and agree to these terms.

RPKI-ROA Planner: Simplify Your Route Origin Authorization

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.

🔍 How the Planner Gathers Data

To generate a 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).

💡 Generating ROA Recommendations

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.

The Planner is intelligent—it excludes any candidate routes that are already covered by an existing, valid ROA, ensuring you only focus on what's missing.

Refining Candidates: 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.
Preferred Output: The Planner prioritizes generating multi-prefix ROAs (covering multiple routes with one authorization) over single-prefix ROAs. Using multi-prefix ROAs is recommended for maintaining more efficient RPKI records.

⚠️ Important Considerations

It is essential to understand the Planner's limitations to ensure your final ROA set is complete and accurate:

DDoS Scrubbing Services: The Planner may not see all necessary routing data if your network is protected by a DDoS scrubbing service. These services often temporarily introduce highly specific routes during an attack. If you use a scrubbing service, you must consult with your provider to identify any additional, non-visible ROAs they require.
Final Review: The Planner is an aid, not a final authority. Always double-check its results against your operational knowledge before creating and publishing your final ROAs!

Multi-prefix ROAs: Operational Rationale

IETF RFC 9455 (BCP 238) Guidance

The current IETF guidance, published as RFC 9455 (BCP 238), recommends that operators create single-prefix ROAs (one IP prefix per ROA). The intent of this guidance is to reduce the chance of operational errors—particularly incorrect maxLength values—and to make each ROA's meaning unambiguous.

However, this recommendation has been called into question by many network operators. Creating one ROA per prefix can dramatically increase the number of ROA objects an organization must maintain. Large ROA sets can:

Increase publication-point size
Raise validator CPU, I/O, and memory costs
Create unnecessary churn in RPKI repositories
Hit RIR object limits for some operators
Complicate routine updates, especially during operational events such as failover or DDoS mitigation

In practice, these issues can outweigh the theoretical benefits of single-prefix ROAs—especially for organizations with many prefixes or frequent updates.

Why This Planner Recommends Multi-Prefix ROAs

Multi-prefix ROAs remain fully standards-compliant under RPKI validation rules, and for many operators provide a more scalable, operationally efficient approach.

This application presents both options, but recommends multi-prefix ROAs when appropriate because they:

Reduce the total number of ROA objects
Lower the load on RPKI validators
Minimize operational churn and update overhead
Provide a cleaner, more manageable ROA set for many networks

Ultimately, this tool enables operators to choose the model that best fits their environment—but highlights multi-prefix ROAs when they offer clear operational advantages.

RPKI-ROA Planner

Enter IP Prefix

Test RPKI-ROA Data

Important Disclaimer

DDoS Mitigation Service Information

RPKI-ROA Planner: Simplify Your Route Origin Authorization

🔍 How the Planner Gathers Data

💡 Generating ROA Recommendations

⚠️ Important Considerations

Multi-prefix ROAs: Operational Rationale

IETF RFC 9455 (BCP 238) Guidance

Why This Planner Recommends Multi-Prefix ROAs

Data Sources

American Registry for Internet Numbers (ARIN)

University of Oregon RouteViews Project

Center for Applied Internet Data Analysis (CAIDA)

RIPEstat

Regional Internet Registry (RIR) Technical Contacts

RPKI-ROA Planner

Enter IP Prefix

Test RPKI-ROA Data