RPKI validation is now an important part of modern BGP routing security. It helps network operators determine whether an Autonomous System Number is authorized to originate a particular IPv4 or IPv6 prefix. When a router receives a route announcement, it can compare the announcement with the published RPKI authorization for that address range.
The result is normally shown as Valid, Invalid, or Not Found. These three labels are simple, but they are often misunderstood. A Valid result does not mean that every part of the route is perfect. An Invalid result does not always mean that someone is attacking the network. A Not Found result does not automatically mean that the announcement is unsafe.
The labels only describe the relationship between a BGP announcement and the available Route Origin Authorization data. To understand the result correctly, you need to compare three details: the announced IP prefix, the origin ASN, and the maximum prefix length allowed by the authorization.
This article explains each RPKI status in practical terms, shows why legitimate routes can become Invalid, and provides a troubleshooting process for network operators managing their own ASN, IPv4 resources, IPv6 allocations, or upstream routing. If you are new to the subject, start with our guide to What Is RPKI? and then read What Is a ROA in RPKI? for a detailed explanation of the authorization record itself.
What Is RPKI Validation?
RPKI stands for Resource Public Key Infrastructure. It connects Internet number resources with cryptographically signed authorization records. The holder or authorized manager of an IP prefix can publish a ROA stating that a particular ASN is allowed to originate that prefix in BGP.
A validator collects these signed records, checks their authenticity, and creates a validated dataset for network operators. When a BGP route is received, the operator’s routing system compares the route with that dataset. The comparison asks three basic questions: Is the announced prefix covered by an authorization? Is the origin ASN the one listed in that authorization? Is the announced prefix length within the permitted maximum length?
The answer to those questions produces the RPKI status. The status applies to route origin authorization, not to every attribute of the BGP path. RPKI does not prove that all intermediate networks are correct, that traffic will follow the best path, or that the address resource is legally available for sale. It is a focused security signal that improves confidence in the origin of a route.
What Does RPKI Valid Mean?
A route is RPKI Valid when the BGP announcement is covered by at least one applicable ROA, the origin ASN matches the authorized ASN, and the announced prefix length is permitted by the ROA’s maximum length. In practical terms, the route is consistent with the routing authorization published by the resource holder.
For example, suppose a company controls 203.0.113.0/24 and publishes a ROA authorizing AS64500 to originate that /24. If the company announces 203.0.113.0/24 from AS64500, the announcement should return Valid. The same is true for an IPv6 example such as 2001:db8:1200::/48 when the correct ASN and permitted prefix length are used.
A Valid result is a positive signal, but it should not be interpreted as a complete guarantee. The route may still have an incorrect path, a poor business reputation, an outdated registry description, or an operational problem outside origin authorization. Network operators normally combine RPKI with BGP monitoring, prefix filtering, registry checks, and incident response procedures.
A Valid status can also change when the network changes. If a company moves a prefix to another ASN, begins announcing a more-specific route, or changes its address plan, the existing ROA may no longer match the new announcement. RPKI reflects the current authorization data, so it must be maintained as part of normal network operations.
What Does RPKI Invalid Mean?
A route is RPKI Invalid when an applicable authorization exists, but the BGP announcement conflicts with it. The conflict usually involves one of two things: the origin ASN is not authorized, or the announced prefix is more specific than the maximum length permitted by the ROA.
For example, a ROA may authorize AS64500 to originate 198.51.100.0/24. If AS64510 announces that same prefix, the origin ASN does not match and the route becomes Invalid. The result can also occur when AS64500 is authorized for the /24 but announces 198.51.100.0/25 while the ROA does not permit prefixes that specific.
Invalid does not necessarily mean that a malicious hijack is taking place. Many Invalid routes are caused by ordinary operational mistakes. An engineer may forget to update a ROA after an ASN migration, a provider may announce a customer prefix with the wrong origin, or the network may begin using more-specific prefixes without changing the maximum length.
At the same time, an Invalid result should not be ignored. It can indicate an unauthorized announcement, a route leak involving an unexpected origin, or a configuration error that may make the prefix unreachable through networks using strict RPKI filtering. The correct response is to investigate the result quickly and compare it with the intended routing design.
What Does RPKI Not Found Mean?
A route is RPKI Not Found when the validator cannot find an applicable ROA for the announced prefix. There is no published authorization that can confirm or deny the origin ASN for that route.
Not Found is sometimes called “unknown,” because the validation system does not have enough authorization information to reach a conclusion. It does not mean that the route is invalid, and it does not prove that the origin is unauthorized. Many legitimate prefixes on the Internet still have no ROA, either because the resource holder has not created one or because the authorization has not yet become visible to the validator.
The absence of a ROA does reduce the amount of information available to networks that want to validate the route. If an unauthorized ASN announces the same prefix, a network that sees both announcements may have difficulty distinguishing the legitimate route from the false one using RPKI alone.
Resource holders should normally publish accurate ROAs for prefixes they announce publicly, especially when the prefixes support important services. However, operators should avoid creating a rushed or overly broad authorization merely to change Not Found into Valid. A badly configured ROA can turn a legitimate route into Invalid, which may have a more immediate operational impact.
The Difference Between Invalid and Not Found
The most important distinction is that Invalid is a conflict, while Not Found is an absence of authorization data. Invalid means that the validator found a relevant ROA but the route does not comply with it. Not Found means that no applicable ROA was found.
Consider two examples. In the first, a company publishes a ROA authorizing AS64500 for 192.0.2.0/24, but AS64510 announces the prefix. The route is Invalid because the origin conflicts with the authorization. In the second, the company has not published any ROA, and AS64500 announces the prefix. The route is Not Found because there is no authorization to evaluate.
This difference matters when creating routing policy. Many networks give special treatment to Invalid routes because an existing authorization indicates that the resource holder has expressed a specific expectation. Not Found routes may be monitored, given a lower preference, or accepted according to local policy. Each network decides how to apply the result.
Network operators should also remember that validation results can vary temporarily while repositories and validators refresh. If a ROA was created or changed only a few minutes ago, different tools may display different states until the update has propagated through the validation system.
Why Can a Legitimate Route Become Invalid?
The most common cause is an ASN change. A company may originally announce a prefix from an ASN provided by an upstream or sponsoring organization and later move the prefix to its own ASN. If the ROA still authorizes the old origin, the new announcement becomes Invalid.
A second cause is an incorrect maximum prefix length. An organization may hold a /20, publish a ROA with a maximum length of /20, and later announce two /21 routes for traffic engineering. Those more-specific announcements may not be covered by the original authorization. The BGP configuration can be intentional, but the RPKI policy is too restrictive for the new design.
IPv4 transfers can create similar problems. During a transfer, the administrative holder and routing origin may change at different times. If the previous holder’s authorization remains active while the new holder announces the prefix from a different ASN, the transition can produce an Invalid state.
Stale records, incorrect network boundaries, and misunderstandings about the transit provider’s role are other frequent causes. A provider may carry a customer’s route without being the origin ASN. The ROA normally needs to authorize the ASN that appears as the route origin, not simply the carrier that transports the traffic.
How to Troubleshoot an RPKI Invalid Result
Begin by recording the exact prefix and origin ASN shown in the BGP announcement. Do not rely on a shortened display or a previous configuration document. Confirm the address family, prefix length, and origin observed by at least one reliable routing monitor.
Next, inspect the active ROAs for that prefix. Check the authorized ASN and maximum prefix length. If the origin ASN does not match, determine whether the route or the authorization is wrong. If the ASN is correct, check whether the announced prefix is more specific than the permitted maximum length.
Then review recent changes. Look for an ASN migration, upstream provider change, IPv4 transfer, IPv6 deployment, data center move, route aggregation change, or BGP policy update. Most legitimate Invalid results can be connected to a recent change that was not reflected in RPKI management.
If the ROA is wrong, update it through the relevant Regional Internet Registry, sponsoring LIR, or RPKI management system. If the BGP announcement is wrong, correct the route policy instead. Do not solve a routing mistake by publishing an unnecessarily broad ROA, because that may authorize announcements that were never intended.
After making the correction, allow time for the repository and validator to refresh. Check the result again using an external validation service and a BGP monitoring source. The route should return to Valid when the origin and prefix length match the published authorization.
How RPKI Results Affect BGP Routing
RPKI validation does not automatically withdraw a route from the Internet. The receiving network decides how to use the result in its routing policy. Some operators reject Invalid routes, while others mark them with a lower preference, generate alerts, or continue accepting them under specific conditions.
A Valid route may receive normal treatment, but it still competes with other routes according to local preference, path length, traffic engineering rules, and provider policy. A Not Found route may be accepted by one network and treated more cautiously by another. An Invalid route may remain visible through some providers while becoming unreachable through networks that enforce strict filtering.
This difference explains why an Invalid announcement can cause partial connectivity. A service may work from one region but fail from another because different networks apply different policies. When diagnosing an outage, it is therefore useful to compare validation status with BGP visibility from multiple locations.
RPKI should be viewed as one input to routing policy rather than a universal replacement for prefix filters or route monitoring. The strongest operational results usually come from combining accurate RPKI data with carefully maintained registry and routing records.
RPKI Validation for IPv4 and IPv6
The same three states apply to both IPv4 and IPv6. In each address family, the validator compares the announced prefix, the origin ASN, and the permitted prefix length with the available ROAs.
IPv4 operations often involve relatively small prefixes, transfers, leasing arrangements, and multiple providers. A change in the origin ASN or the use of more-specific announcements can quickly affect the validation result. IPv4 resource holders should review RPKI whenever a block is transferred, leased, moved between providers, or announced from a new location.
IPv6 networks commonly receive larger allocations and may announce an aggregate while using smaller internal subnets. The public ROA should match the prefixes that are actually announced to the Internet. If an IPv6 operator authorizes only an aggregate but later advertises more-specific routes, those routes may become Invalid unless the maximum length allows them.
A larger IPv6 address space does not remove the need for origin validation. IPv6 route hijacks and configuration mistakes can still interrupt services. Publishing precise ROAs during the initial IPv6 deployment makes future troubleshooting easier and gives upstream networks a clear authorization signal.
How to Check an RPKI Status Before a Network Change
Before changing an ASN, upstream provider, route aggregation plan, or address resource holder, record the current RPKI state. Confirm which ASN currently originates the prefix and whether the announcement is Valid, Invalid, or Not Found.
After preparing the new routing design, compare the expected origin and prefix lengths with the planned ROAs. If the origin will change, publish or update the authorization before announcing the new route whenever the operational schedule allows. During a controlled migration, temporary authorization for both origins may be appropriate, but the arrangement should be documented and the old authorization removed when the transition is complete.
A technical pre-check can also reveal related inconsistencies. The IP Resource Readiness Checker can help review public registry information, origin ASN data, route objects, RPKI status, and BGP visibility for a public IPv4 or IPv6 prefix. It is a technical check rather than proof of ownership or transfer eligibility, so contractual and registry verification remain necessary.
Frequently Asked Questions About RPKI Status
Is RPKI Not Found the same as Invalid?
No. Not Found means that no applicable ROA was found. Invalid means that a relevant ROA exists but the BGP announcement conflicts with it. Invalid usually requires more urgent investigation because it represents a direct mismatch with published authorization.
Can a Valid route still have a problem?
Yes. Valid only confirms that the origin ASN and prefix length match an applicable ROA. It does not verify every part of the BGP path, application security, IP reputation, legal ownership, or service availability.
Why is my route Invalid after changing providers?
Changing the carrier alone may not require a new ROA if the origin ASN remains the same. However, if the provider change also changes the origin ASN, or if the new provider announces a different prefix length, the ROA may need to be updated.
How long does it take for a ROA change to appear?
The change must be published by the relevant RPKI system and retrieved by validators. It is common for a short delay to occur. During a production change, check more than one validation source and allow time for refresh intervals.
Should I reject every Not Found route?
That depends on your network policy and risk model. Not Found does not prove that a route is wrong. Many legitimate routes have no ROA. Some networks accept Not Found routes while applying monitoring or lower preference; others use stricter policies for selected environments.
Can RPKI protect both IPv4 and IPv6?
Yes. RPKI supports origin authorization for both address families. The practical configuration must match the prefixes and prefix lengths that each network actually announces.
RPKI status labels become much easier to understand when you remember the basic difference between authorization and observation. A Valid result means the route matches a published authorization. An Invalid result means the route conflicts with an applicable authorization. A Not Found result means that no authorization was available for the validator to check.
These results are especially important during ASN migrations, provider changes, IPv4 transfers, IPv6 deployments, and network redesigns. A legitimate route can become Invalid when the BGP origin changes but the ROA is not updated, or when the network begins announcing prefixes more specific than the permitted maximum length.
For reliable operations, review the announced prefix, origin ASN, and maximum prefix length together. Keep RPKI records aligned with the real routing design, monitor changes after publication, and investigate Invalid results promptly. Use RPKI alongside registry records, BGP monitoring, IRR data, and documented change management rather than treating it as a complete replacement for those systems.
If you want to continue the series, the next useful article is How to Fix an RPKI Invalid Route, which can explain migration planning, overlapping authorizations, provider changes, and practical validation checks in more detail.