RPKI can replace some IRR data, but AS-SET dependencies remain

Research published on RIPE Labs on 1 September 2026 offers an important distinction for routing-database cleanup: replacing some third-party route objects is a different exercise from removing the AS-SETs used to generate filters. The study by Matthias Wichtlhuber and coauthors examines that distinction using AMS-IX and DE-CIX route-server data.

What the research found

The authors compared simulated configurations that removed third-party Internet Routing Registry (IRR) data with a less restrictive approach retaining AS-SET information. Keeping those sets substantially reduced the observed impact. Their results support reducing reliance on third-party route objects while preserving information needed to build customer-cone filters.

The findings concern the exchanges and configurations studied. They do not establish that all networks can delete the same records safely. The traffic estimates also have a stated limitation: the analysis cannot isolate traffic exchanged through bilateral peering, so the calculated impact can exceed the actual disruption.

This is original community research hosted by RIPE Labs, not a newly enacted registry policy.

Why it matters for BYOIP

Two different kinds of routing information are involved. As ARIN's IRR guide explains, route and route6 objects associate prefixes with origin ASNs, while an as-set can contain ASNs and other sets. APNIC's RPKI guidance describes a ROA as authorizing an origin ASN for a prefix, subject to its maximum length.

For an operator moving an address block between providers, the practical question is therefore broader than whether a valid ROA exists. Ask the receiving provider which registry records and AS-SET references its filter generation actually consumes.

Our editorial recommendation is to treat IRR cleanup as a dependency migration. A record that looks redundant when inspecting one prefix may still be referenced by a provider's automation. Confirm the dependency before removing the record, and compare the generated policy before and after the proposed change.

What to check

• Inventory route objects and AS-SET references separately. Record their maintainers and the networks relying on them.
• Ask upstreams and exchange operators which sources they accept and how frequently filters are regenerated.
• Generate a candidate filter using the proposed source selection, then compare accepted prefixes and origin ASNs with the current output.
• Investigate differences individually. Keep a rollback plan and arrange a monitored change window before removing live dependencies.
• During a BYOIP move, confirm the intended new origin authorization and the receiving provider's registry requirements together.

Sources and further reading

Read the linked research for its methodology and limits. Our RPKI and ROA guide explains origin authorization and helps separate it from other routing-policy inputs.