How IRR Records Support Clean IPv4 Transfers

An IPv4 transfer changes the party that controls an address resource, but it does not automatically update every routing record associated with that prefix. If IRR still points to an old origin ASN, the new holder can face filtering problems even after the transfer is complete.

IRR records for an IPv4 transfer are routing objects that connect an IP prefix with the autonomous system expected to originate it. Their purpose is to keep routing-policy data aligned with the real announcement before, during, and after a transfer.

Why should IRR records be reviewed before an IPv4 transfer?

The pre-transfer review establishes the current routing state before ownership changes. A prefix may have route objects created for the current ASN, previous providers, temporary migrations, or more-specific announcements.

The review should identify:

route objects for the transferred prefix;
origin ASN listed in each object;
records matching active BGP announcements;
maintainer or authorization required for changes;
more-specific route objects;
records that must remain until cutover.

The goal is to understand which records remain valid and which need to change when the new holder activates its routing plan.

How does a route object connect a prefix with an origin ASN?

An IPv4 route object associates a prefix with the ASN expected to originate it. Network operators can use this information when building routing filters for peers or customers.

If the buyer plans to use a different origin ASN, the existing object should not remain the only routing reference after migration. New IRR data should match the actual announcement when traffic moves to the new origin.

Which IRR records should remain until routing cutover?

An old object is not automatically stale because ownership changed. If the previous holder or provider still announces the prefix during a transition period, the corresponding route object may still describe valid routing.

Removing it too early can affect networks that generate filters from IRR data. The cutover plan should define when the old ASN stops announcing the prefix and when the new records become operational.

Why does IRR accuracy matter for routing filters?

Some networks use IRR data when generating accepted prefix lists. If BGP shows a new origin ASN while IRR still points to the previous ASN, the announcement may not match those filters.

The consistency review should compare:

active BGP prefix and origin ASN;
relevant IRR route objects;
planned origin after transfer;
ROA and authorized origin ASN;
resource registry information.

Conflicting data does not always cause an outage, but it increases operational risk during a routing change.

How should IRR and RPKI be coordinated during a transfer?

IRR route objects and ROAs can both contain prefix and origin ASN information, but they serve different purposes. A ROA provides RPKI-based origin authorization, while IRR data can support routing-policy documentation and filter generation.

If the buyer changes the origin ASN, BGP, IRR, and ROA updates should be coordinated. Updating one system while leaving another stale can create inconsistent routing information.

What cleanup is needed when the routing design changes?

Cleanup should remove records that no longer represent a valid routing relationship, but only after their operational role ends. Typical examples include objects for decommissioned ASNs, former transit providers, temporary migrations, or unused more-specific prefixes.

The review should confirm:

whether the object still matches an active route;
who controls the required maintainer;
when the old origin stops announcing the prefix;
whether replacement records are ready;
whether another system still depends on the object.

This prevents a gap between removing old routing data and making the new routing policy usable.

When should new IRR records become active after a transfer?

The timing should follow routing cutover rather than the commercial closing date alone. If the buyer uses a new ASN, the required route object should be available when that ASN begins announcing the range.

After cutover, the team should confirm that the correct origin is registered, obsolete objects are removed when no longer needed, and the prefix is visible through the expected BGP paths.

Why should IRR review be part of the commercial transfer process?

A technically transferable block can still require additional work if its route objects do not match the buyer’s deployment plan. Routing readiness therefore matters before the resource changes operational control.

A company preparing to sell IPv4 addresses should identify records the buyer may need to replace. A company planning to buy IPv4 addresses should verify the current IRR state before deciding how the prefix will be announced.

Which IRR transfer cases require extra attention?

Can a route object for the old ASN remain after the transaction?

Yes. It can remain while that ASN still legitimately announces the range.

Does IRR need to change if the origin ASN stays the same?

Not always. The existing route object and its control should still be reviewed.

Does a ROA replace an IRR route object?

No. RPKI origin authorization and IRR routing-policy data serve different purposes.

When should the final IRR review happen?

After routing cutover, when the active BGP state can be compared with the updated records.

Where can an IPv4 transfer proceed after IRR records are ready?

Once the routing review confirms that IRR data supports the planned cutover, InterLIR can be used to arrange the purchase or sale of the IPv4 block. Routing updates can then be coordinated with the operational handover.