This document describes Resource Public Key Infrastructure (RPKI) related best practices and lessons learned. It provides general recommendations aimed at supporting the implementation and operation of RPKI in diverse environments.
These insights are drawn from practical experience and collaborative discussions but are not intended to be prescriptive. Operators and stakeholders should adapt the guidance according to their specific technical, organizational, and policy contexts.
The recommendations presented here should be viewed as a starting point for informed decision making rather than a definitive or one-size-fits-all approach.
If you are using the delegated mode (sometimes called self-hosted), it is highly recommended to use an RPKI publication server provided by your parent Certification Authority (CA), if available, to simplify operations.
Note: Publication as a service is available to Members of ARIN, APNIC and the RIPE NCC.
What prefixes should I create Route Origin Authorizations (ROAs) for?
Ideally, you should create ROAs that exactly match what you are announcing in the Border Gateway Protocol (BGP) and nothing more (see the ARIN RPKI FAQ, RIPE MANRS Implementation Guide, and APNIC Academy RPKI Deployment training).
However, there may be circumstances in which it is necessary to create ROAs for space that is not currently visible on the BGP. For instance, black-holing services for mitigation of Distributed Denial of Service (DDoS) attacks may require the creation of specific ROAs that may not match what you are announcing in the BGP.
What value should I enter in the maxLength field?
maxLength is an optional field in a ROA that represents the maximum length of the IP prefix that the origin Autonomous System (AS) is authorized to advertise.
Ideally, you should use a maxLength value that will make the ROA being created cover the prefixes announced in the BGP and nothing more. The use of maxLength is considered harmful if you don’t also announce each most specific prefix thus allowed. Liberal use of maxLength in ROAs exposes you to a forged-origin sub-prefix hijack.
See RFC 9319 for more information on the use of maxLength.
How should I create ROAs for overlapping prefixes?
If you are announcing overlapping prefixes in the BGP, you should create ROAs for the most specific prefixes first, and work back to your aggregates.
My organization does not have a public AS Number (ASN). Our prefixes are originated by our upstream provider.
If your prefixes are originated by your upstream provider, you can use hosted RPKI services and create ROAs using your upstream provider’s ASN as the Origin AS.
How do I verify the impact of the ROA I just created?
After creating a ROA, it is recommended to verify that your prefixes have been properly signed and that no BGP routes have been invalidated. To do this, use a validator, NTT monitor, BGPmon, LACNIC’s origin validation tool, or equivalent tool (see APNIC Academy RPKI Deployment training and the LACNIC RPKI FAQ).
Best practices for deploying ROV
How should I approach the deployment of Route Origin Validation (ROV) in my network?
If you are just getting started with ROV, you can begin cautiously by monitoring route validity statuses. Validate the BGP announcements from your customers against RPKI ROAs.
You can then start tagging BGP announcements, optionally modifying preference values, and start communicating to your customers that you will soon begin dropping invalid BGP announcements. Once you are confident enough about your set-up, you can start dropping invalids.
It’s recommended to use multiple RPKI validators.
All routers that support ROV allow you to specify multiple RPKI validators for redundancy. It is recommended that you run multiple instances, preferably from independent publishers and on separate subnets. This way you rely on multiple caches (see APNIC Academy RPKI Deployment training, and the RPKI FAQ on ReadTheDocs).
AS0 ROAs for unallocated space.
Some Regional Internet Registers (RIRs) have AS0 Trust Anchors (TAs) for unallocated space (APNIC and LACNIC as of July 2025). It is strongly recommended that these TAs are used for advisory and/or alerting purposes only, and not for automatic filtering, due to potential risks.
See RFC 7115 for more information about how to deploy and operate ROV.
Share your feedback
The RPKI best practices and lessons learned described in this document have been consolidated from different sources. We welcome input from the technical community to help improve the relevance and clarity of this document. If you have any comments, questions, or suggestions, please don’t hesitate to get in touch. You can share your feedback by emailing us at rpki_program [at] nro.net
Your contributions are valuable and will help ensure that future updates reflect a broad range of operational perspectives and evolving best practices.
