RPKI: Why Is My More-Specific Route Invalid Despite the Correct ASN?

The origin ASN is correct, yet a new, more-specific BGP route is RPKI-Invalid? Check the prefix and permitted prefix length as well as the ASN. Authorisation for an aggregate does not automatically permit every subnet it contains. If you plan to announce additional prefixes for traffic engineering or a backup path, prepare the matching ROAs before changing routing and check their effect.

What maxLength actually permits

A Route Origin Authorization (ROA) identifies an origin ASN and authorised prefixes. For each prefix, maxLength can specify how long a more-specific prefix may be. Without this optional field, only the exact prefix is authorised. RFC 9582 defines this meaning for IPv4 and IPv6. A larger number after the slash denotes a smaller, more-specific network, not a larger address range.

An interface may display exact authorisation using identical prefix and maximum lengths. What matters is the published permission, not a field's label. maxLength also does not dictate which prefix lengths an upstream accepts: its import filters and your agreed routing scope still apply.

Distinguish Valid, Invalid and NotFound

• Valid: at least one validated authorisation record matches the prefix, length and origin ASN.
• Invalid: at least one record covers the prefix, but none permits the combination of prefix length and origin ASN.
• NotFound: no record covers the announced prefix. This is not positive authorisation.

RFC 6811 defines this check using validated data known as VRPs. Here, Invalid describes the route relative to those records, not necessarily a broken ROA signature. Actual traffic delivery also depends on routing policy and reachability. A green Valid status proves neither the authenticity of the entire AS path nor that a service works.

Example: a /40 does not yet authorise a /48

The following scenario is purely illustrative. IPv6 addresses from 2001:db8::/32 and AS64496/AS64497 are used for documentation; these are not AS51202 routes or prefixes for a live test. Assume the validated data set being examined contains only an authorisation for 2001:db8:1200::/40 with origin AS64496 and no extended maximum length.

• 2001:db8:1200::/40, origin AS64496: Valid, because the exact prefix and ASN match.
• 2001:db8:1201::/48, origin AS64496: Invalid, because /48 is more specific than the permitted /40 length.
• 2001:db8:1200::/40, origin AS64497: Invalid, because the origin ASN is not authorised.
• 2001:db8:3400::/40, origin AS64496: NotFound, because this prefix lies outside the sole authorisation.

If precisely 2001:db8:1201::/48 is to be announced from AS64496, an additional exact authorisation can be prepared for it. The existing /40 authorisation remains in place. Once the validating data set contains both, that /48 announcement is also Valid. There is no need to authorise the entire /40 down to /48 indiscriminately.

Why not set a large maximum length just in case?

RFC 9319 recommends precise authorisations rather than unnecessarily permitting many subprefixes. A generous maxLength setting increases the attack surface for announcements with a forged origin: ROV does not validate the entire AS path. Rarely used backup or mitigation routes should therefore be planned explicitly. Pre-authorise only the intended prefix/origin combinations and review unused permissions regularly; emergency preparation does not justify unrestricted authorisation.

Overlapping ROAs are not an ordered firewall rule list. Adding a narrow authorisation does not cancel an existing broad one. As long as any matching validated record permits a route, it can be Valid. To narrow permissions, inspect all covering records and deliberately replace unnecessary broad authorisations.

A new ROA can also affect existing subnets

Before authorising a larger block, account for customer subnets already being announced. RFC 7115 notes that these need suitable ROAs: a previously uncovered announcement can change from NotFound to Invalid when a new covering ROA appears. Checking only your own aggregate misses this effect. Include subnets with a different origin ASN in the inventory.

Use a verifiable change procedure

1. 1Save the previous state: record actually announced prefixes, origin ASNs, all covering authorisations and observed validation states with timestamps.
2. 2Define the intended state: list normal operation, cutover and rollback separately. Add the required exact authorisations instead of increasing maxLength indiscriminately.
3. 3Check publication and distribution: a saved portal entry does not prove that a validator and router use it. Verify the intended data set at your own validator and with the upstream.
4. 4Only then make the planned BGP change. During an origin change, initially retain the old authorisation needed for the agreed rollback.
5. 5After cutover, compare validation states, visible routes and actual service reachability. If they diverge, use the prepared rollback rather than disabling ROV broadly.
6. 6After confirming completion, remove authorisations that are no longer needed and check the remaining records again. Record ownership and the change in your operations log.

This procedure is a practical planning aid, not a guarantee of a disruption-free cutover. RPKI data is distributed and cached; different validators can temporarily see different versions. RFC 9319 specifically cautions against waiting until a time-critical routing event to create a necessary authorisation. This does not establish a universal waiting period. Use the observed data state as the criterion.

What to include in a transit enquiry

Provide the planned IPv4/IPv6 prefixes, origin ASN, intended more-specific announcements and cutover scenario. For a specific Invalid result, also include the observation time, router or validator and covering ROA data. This lets authorisation, import filters and the actual announcement be checked separately. Do not include RPKI portal credentials in the enquiry.