BGP Rehoming: Why an IPv4 Prefix Changes Origin ASN
Why an IPv4 prefix can change origin ASN without changing holder, and how to check BGP, RPKI, IRR and registry state.
An IPv4 prefix can keep the same numbers and still appear to move to a different network. In BGP, that change is usually visible as a new origin ASN.
This is called BGP rehoming. It is an observation about routing state. It is not, by itself, proof that the registered holder changed, that the prefix moved countries, or that an address transfer occurred.
Start with the route
If a collector observes 203.0.113.0/24 → AS64500, it is seeing AS64500 originate the route at that moment. If the same prefix later appears as 203.0.113.0/24 → AS64550, the origin ASN changed.
The term origin ASN here means the ASN at the origin end of the observed AS path. It should not be confused with the BGP ORIGIN attribute, which is a separate attribute defined by RFC 4271.
What recent data shows
In its comparison of routing snapshots from the beginning of 2025 and the beginning of 2026, APNIC counted 29,699 IPv4 prefixes whose originating ASN changed. The same analysis found that approximately 1,991 appeared in the compared transfer records while 26,722 did not.
The comparison is not evidence that the unmatched prefixes were improperly transferred. It shows why routing history and registry history must not be treated as the same dataset. Many legitimate network changes do not require a change in the registered holder.
Why an origin ASN changes
There are several ordinary operational explanations:
- a company changes transit or hosting provider;
- infrastructure moves to another data center or cloud network;
- a customer begins originating through its own newly obtained ASN;
- a corporate network is merged, split or restructured;
- a holder delegates routing to another operator or hosting provider; or
- the routing architecture changes while the registry relationship remains stable.
Each explanation needs evidence. The route alone shows what is being announced, not why it changed or who authorized it.
Rehoming and IPv4 transfer answer different questions
BGP rehoming asks: which ASN is originating this prefix?
An IPv4 transfer asks: has the recognized registry relationship changed?
The events may happen at the same time. They may also happen separately. A holder can change provider without transferring the resource, and a registry relationship can change while the same provider continues to originate the route.
BGP is routing evidence, not complete control evidence
Seeing AS64550 originate a prefix does not automatically prove that AS64550 owns it, is the registered holder, may transfer it, or has permanent authority to announce it. A lease, customer arrangement, temporary migration or mistake could produce the same observation.
To understand control, compare the route with registry records, operational authorization and the evidence that explains the relationship. This is the practical reason to keep routing control, registry control and commercial relationships distinct.
RPKI adds authorization
A Route Origin Authorization states that a particular ASN is authorized to originate a prefix within the RPKI system. RFC 9582 defines the current ROA profile.
When the origin changes from AS64500 to AS64550, the intended new state should be reflected in the relevant ROA. A valid ROA does not prove that the route is currently announced, and an observed route does not prove that the announcement is authorized. BGP and RPKI are complementary evidence.
IRR and reverse DNS are part of the migration
Providers may use IRR route objects to build filters. Customers may depend on reverse DNS, allowlists, monitoring and reputation systems. A routing migration can therefore require several coordinated updates even when the registry holder stays the same.
The useful operational record names each layer: registry state, BGP origin, RPKI authorization, IRR policy, reverse-DNS responsibility, contacts and the internal change record.
What to check when the origin changes
Before the change
- record the exact prefixes and current origin ASN;
- confirm the intended new ASN and the authorized operator;
- review ROAs, IRR objects, reverse DNS and provider readiness; and
- preserve the current BGP and registry evidence.
During the migration
- watch propagation and origin changes from multiple networks;
- check RPKI validation and more-specific announcements; and
- look for the old route to disappear where the change requires it.
After the migration
- verify the expected ASN is originating the prefix;
- confirm ROAs, IRR and reverse DNS match the intended state;
- check registry data and contacts; and
- save the evidence so the next operator can reconstruct the change.
Does an unexpected origin mean a hijack?
Not necessarily. It deserves investigation, but the first question should be whether the change was authorized. Possible explanations include a provider migration, temporary maintenance, customer routing, a new ASN, operational delegation, a configuration mistake or an unauthorized announcement.
Use BGP history together with registry records, ROAs, IRR information, provider documentation and internal change records before assigning a cause. A fast label can hide the actual operational problem.
Why this matters for portability
IPv4 resources increasingly survive changes in providers, data centers, corporate structures, ASNs and operational users. Portability is therefore more than allowing the address number to remain the same. The surrounding systems must preserve uniqueness, authorization, accurate records, security and continuity while the network changes.
Public IP continuity depends on this practical layer. DNS, access controls, partner allowlists, VPNs and monitoring can all depend on an address even when the registry and routing changes look administrative.
The running network is the final test
Registry records, RPKI, IRR objects and BGP observations are different instruments around a running network. The goal of a legitimate rehoming is simple: make the required routing change while keeping the network reachable, authorized and explainable.