Summary

  • A RIPE 93 research abstract reports 786 observed prefix-origin pairs with an exact IRR match that remained RPKI Invalid throughout 8–14 August 2026.
  • Of those conflicts, 371 failed the ROA's maximum prefix length and 415 named a different origin. The operator changing a route filter needs to know which problem is on the desk.

A route can arrive with convincing paperwork and still fail the signed check. In the RIPE 93 abstract, Antonis Chariton and Usama Ejaz report 786 such exact IRR matches that stayed RPKI Invalid throughout a seven-day observation. The talk is scheduled for Tuesday, 27 October; these numbers come from its published abstract, ahead of the session.

The split matters more than the headline count. For 371 pairs, the announced prefix was longer than the ROA's maximum length allowed. For 415, the origin ASN differed. Both can produce Invalid, but they send an engineer to different places: prefix granularity in the first case, origin authorization in the second. The RIPE NCC's origin-validation guide describes those two failure modes. A matching IRR route object answers a different question: whether a registry source contains that prefix-origin assertion.

The authors aligned observations from 8–14 August across 57 RIPE RIS and RouteViews collectors, 19 IRR sources and 17 RPKI relying-party views present throughout the week. Across the observed weekly union, 64.4% of prefix-origin pairs had an exact IRR match. Of that matched group, 79.9% appeared in just one IRR source. One source can supply a record; it cannot supply a second vote by being looked up twice.

There is a second trap inside customer filters. In a separate 8 August replay, expanding PeeringDB-declared AS-SETs retained 99.27% of exact IRR matches. The abstract says incomplete and unresolved expansions still require review. A missing member in an unfinished expansion is a question for the operator, not an instruction to erase a customer route.

RFC 6811 defines the validation result and leaves filtering to explicit local policy. That is the control point. Put the exact prefix and origin, IRR source, ROA length or origin mismatch, observation time and AS-SET expansion state on one decision record. Then the network carrying the consequence can decide what its filter will do.