RPKI best practices and lessons learned

This document describes 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, organisational, 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.

Best practices for ROA creation

Just about to enable RPKI for your organisation and wondering whether you should select Hosted mode or Delegated mode?

If just getting started with RPKI, use Hosted RPKI. [1]

Using Delegated mode?

If you are using the Delegated mode (or self-hosted), it is highly recommended to use an RPKI publication server provided by your parent Certification Authority, if available, to simplify operations. [2]

Note: Publication as a service is available to members of ARIN, APNIC and RIPE NCC.

What prefixes should I create ROAs for?

Ideally, you should create ROAs that exactly match what you are announcing in BGP and nothing more. [1][3][4]

However, there may be circumstances in which it is necessary to create ROAs for space that is not currently visible on BGP. E.g. Black-holing services for mitigation of DDoS attacks may require the creation of specific ROAs which may not match what you are announcing in BGP.

What value should I enter in the Max Length field?

Max Length is an optional field in a ROA which represents the maximum length of the IP prefix that the origin AS is authorised to advertise.

Ideally, you should use a Max Length value that will make the ROA being created cover the prefixes announced in BGP and nothing more. The use of Max Length is considered harmful in case you don’t also announce each most specific prefix thus allowed. [5] Liberal use of Max Length in ROAs exposes you to a Forged-Origin sub-Prefix Hijack. [1]

More information on the use of Max Length can be found in RFC 9319

How should I create ROAs for overlapping prefixes?

If you are announcing overlapping prefixes in BGP, you should create ROAs for the most specific prefixes first, and work back to your aggregates. [1]

My organisation does not have a public 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. [1]

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’s BGPalerter, LACNIC’s origin validation tool (For LACNIC Members. Login required), LACNIC Tools, IRR explorer, PacketVis, or equivalent tool. [4] [6]

Best practices for deploying Route Origin Validation (ROV)

How should I approach the deployment of ROV in my network?

If you are just getting started with ROV, a cautious approach can be to start by monitoring route validity statuses. Validate the BGP announcements from your customers against RPKI ROAs. [3]

You can then start tagging BGP announcements, optionally modifying preference values, and start communicating to your customers that you will soon start dropping invalid BGP announcements. Once you are confident enough about your set-up, you can start dropping invalids. [4]

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. [4] [8]

AS0 ROAs for unallocated space

Some RIRs have AS0 TAs for unallocated space (As of July 2025, APNIC and LACNIC). 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. [9]

More information about how to deploy and operate ROV can be found in RFC 7115

Note: The RPKI best practices and lessons learned described in this document have been consolidated from a variety of sources. We welcome input from the technical community to further improve the relevance and clarity of this resource. You can share your feedback by completing the form below or by emailing us at rpki_program [at] nro.net

Your contributions are highly valued and will help ensure that future updates reflect a wide range of operational perspectives and evolving best practices.

Provide your input