What Is a ROA and How Is It Different From an IRR Route Object?

ROAs and IRR route objects both connect an IP prefix with an autonomous system, but they provide different types of routing assurance. Treating them as interchangeable can create problems during routing changes.

A ROA is a cryptographically signed RPKI object that authorizes an origin ASN to announce a specified IP prefix. An IRR route object is a routing registry record that associates a prefix with an origin ASN for routing-policy publication and filter generation.

What information does a ROA publish through RPKI?

A Route Origin Authorization identifies which ASN the address holder authorizes to originate a prefix. It is created within RPKI, allowing the authorization to be validated through the associated certificate chain.

A ROA normally defines:

authorized origin ASN;
one or more IPv4 or IPv6 prefixes;
optional maximum prefix length;
authorization linked to the underlying address resource.

The maxLength value determines whether more-specific announcements are also authorized. Covering a larger prefix does not automatically authorize every more-specific route.

What does an IRR route object record?

An IRR route object is stored in an Internet Routing Registry. For IPv4, the route attribute identifies the prefix and the origin attribute identifies the ASN expected to originate it.

Operators can use these records to describe routing intentions and build prefix filters. Unlike a ROA, an IRR route object is not validated through the RPKI certificate chain and depends on the controls of the IRR source.

What are the main differences between a ROA and an IRR route object?

The largest difference is the trust and validation model.

A ROA is cryptographically verifiable through RPKI, while IRR relies on registry controls.
A ROA supports route origin validation, while IRR is commonly used for policy publication and filter generation.
A ROA can authorize more-specifics through maxLength, while an IRR route object describes a specific prefix-origin relationship.
RPKI validation can determine whether a BGP announcement matches the available authorization.

The two systems may contain similar prefix and ASN data, but they do not provide the same assurance.

How does route origin validation use a ROA?

Route origin validation compares a BGP announcement with validated RPKI data. If the prefix, origin ASN, and prefix length match the authorization, the route can be classified as Valid.

An announcement can become Invalid when the origin ASN is not authorized or a more-specific exceeds the permitted maximum length. If no relevant authorization exists, the route receives the corresponding no-authorization state.

ROV validates the route origin, not the complete AS path. A valid origin therefore does not prove that every part of the BGP path is legitimate.

Why do operators still use IRR when RPKI exists?

RPKI and IRR solve different operational problems. RPKI provides cryptographically verifiable origin authorization, while IRR remains useful for routing-policy records and filter generation.

Many operators therefore use both. RPKI strengthens origin validation, while IRR continues to support routing-policy automation.

What should be compared before changing an origin ASN?

A routing change can leave external systems with conflicting information if BGP, ROA, and IRR are updated independently.

The review should include:

prefix visible in BGP;
origin ASN in relevant IRR objects;
ASN authorized by the ROA;
prefix length and ROA maxLength;
stale route objects;
planned origin after the change.

This comparison helps identify conflicts before peers or upstreams consume inconsistent routing data.

Which ROA and IRR mismatches create operational risk?

A common problem occurs when the IRR route object is updated for a new ASN while the ROA still authorizes only the previous origin. The new BGP route can then become RPKI Invalid even though the IRR data appears correct.

The reverse can also happen: RPKI authorizes the new origin while stale IRR records still generate filters for the old ASN. BGP, RPKI, and IRR should therefore be coordinated during migrations and transfers.

When can more than one origin ASN be valid?

A routing design can temporarily or permanently require more than one origin, for example during migration. ROA and IRR records should reflect that design deliberately.

After the transition, obsolete origins should be removed so they do not remain authorized or continue influencing routing filters.

Which ROA and IRR questions require separate attention?

Does a ROA announce a route in BGP?

No. It authorizes an origin ASN; the BGP announcement is created separately.

Does an IRR route object prove cryptographic ownership of a prefix?

No. It does not provide RPKI certificate-based validation.

Can the same prefix have multiple authorized origin ASNs?

Yes, when the routing design requires them.

Should IRR and RPKI show the same origin ASN?

For an active route, consistency is generally desirable. A migration can temporarily require multiple valid records.

How can IPv4 transactions stay aligned with ROA and IRR changes?

When an IPv4 block is purchased, sold, or leased, routing authorization may need to change with the handover. InterLIR can support the IPv4 transaction while the parties coordinate ROA, IRR, and origin ASN updates with the routing transition.