How to Check Who Is Announcing an IP Prefix in BGP

How Do You Check Who Is Announcing an IP Prefix?

To check who is announcing an IP prefix, look up the prefix in a BGP routing-data service and identify the origin Autonomous System Number (ASN) shown at the end of the observed AS path.

For example:

IP Prefix: 203.0.113.0/24
Observed BGP Origin: AS64500

This tells you that AS64500 is currently observed originating the route.

But that does not, by itself, tell you:

• who the IP range is registered to;
• whether AS64500 is authorized to originate it;
• whether the route is RPKI Valid;
• whether the announcement is expected;
• or whether the organization legally owns the address space.

A reliable investigation should therefore compare at least four layers:

1. BGP — Who is actually announcing the prefix?
2. RDAP / registry data — Which organization is associated with the resource?
3. RPKI — Which ASN is cryptographically authorized to originate it?
4. IRR — What routing information has been registered?

The most important principle is:

Registry state, authorization state and live routing state are related, but they are not the same thing.

 

What Does It Mean to “Announce” an IP Prefix?

Public IP prefixes are made reachable across the Internet largely through the Border Gateway Protocol, or BGP.

BGP allows independently operated networks, known as Autonomous Systems, to exchange information about which IP prefixes they can reach.

The IETF defines BGP in RFC 4271 as an inter-Autonomous System routing protocol used to exchange network reachability information.

A simplified BGP announcement might look like:

203.0.113.0/24
AS64510 AS64520 AS64500

The sequence represents the AS path through which the route is being propagated.

For a normal AS sequence, the ASN closest to the originating end of the path represents the origin AS.

In this example:

Origin ASN: AS64500

That ASN is the network presenting the prefix into BGP.

This is one reason understanding the distinction between an IP address and an ASN is important. NRS explains that relationship in ASN vs IP Address: What Is the Difference?.

What Is an Origin ASN?

The origin ASN is the Autonomous System observed originating a route for an IP prefix into BGP.

For example:

Prefix: 192.0.2.0/24
Origin ASN: AS64500

This means routing data currently associates that prefix with an announcement originating from AS64500.

An origin ASN can belong to:

• an ISP;
• cloud provider;
• hosting company;
• enterprise;
• university;
• telecom operator;
• content network;
• data centre;
• infrastructure provider.

However, the origin ASN does not automatically identify the organization recorded as the holder or registrant of the IP block.

A company may own or administer address space while another network announces it on its behalf.

That is common in arrangements involving:

• upstream providers;
• managed routing;
• colocation;
• DDoS mitigation;
• anycast;
• cloud infrastructure;
• transitional network migrations.

Step 1: Identify the IP Prefix You Want to Check

Before looking at BGP, determine the relevant prefix.

If you start with a single IP address such as:

203.0.113.45

the actual BGP announcement may cover a larger network, for example:

203.0.113.0/24

A single address is not necessarily announced independently.

You can first use RDAP or registry information to understand the address range.

NRS explains the process in How to Read an RDAP Record for an IP Address.

But be careful.

The registry range and the announced BGP prefix may not be identical.

For example:

Registered range:
203.0.112.0/23

The network might announce:

203.0.112.0/24
203.0.113.0/24

or perhaps the full:

203.0.112.0/23

That is why BGP should be checked separately.

Step 2: Look Up the Prefix in BGP Data

Once you know the prefix, search a routing-data platform.

Useful sources include:

• RIPEstat
• RIPE Routing Information Service
• RouteViews

RIPEstat combines data from multiple sources, including live and historical BGP information from RIPE RIS, registry data, IRR information and other Internet datasets.

A BGP lookup should help answer:

• Is the prefix currently visible?
• Which ASN originates it?
• Which AS paths are observed?
• Are multiple origins visible?
• Are more-specific prefixes being announced?
• Has the origin changed historically?

For an operational investigation, do not rely only on whether a route exists.

Look at how it is being announced.

Step 3: Find the Origin ASN

Suppose a BGP lookup returns:

203.0.113.0/24
AS3356 AS1299 AS64500

The relevant origin in this simplified example is:

AS64500

That tells you which Autonomous System is observed originating the prefix.

You should then record:

This becomes your routing-state baseline.

Step 4: Compare the BGP Origin With RDAP

The next question is:

Who is associated with the address range in registry data?

Use RDAP to examine:

• registered range;
• organization;
• network name;
• registry;
• status;
• contacts;
• update information.

For example:

RDAP:
Prefix: 203.0.113.0/24
Organization: Example Network Ltd.

BGP:
Origin ASN: AS64500

These two records answer different questions.

RDAP tells you about registration.

BGP tells you about routing.

They may point to the same organization.

They may also point to different organizations for legitimate reasons.

NRS explains the broader registry function in What Is an IP Address Registry and How Does It Work?.

RDAP Does Not Tell You Who Is Currently Routing the Prefix

This is one of the most common mistakes in IP investigations.

An RDAP record can identify an organization associated with an address range.

It does not prove that the organization itself is currently announcing the prefix.

For example:

RDAP organization:
Example Enterprise Ltd.

BGP origin:
AS64496 — Example Transit Provider

That may be entirely legitimate.

The enterprise could be using the provider to announce its address space.

The correct question is therefore not:

Why are the records different?

It is:

Is there a documented and expected reason for the difference?

 

Step 5: Check RPKI Authorization

After identifying the observed BGP origin, check whether that ASN is authorized through RPKI.

A Route Origin Authorization, or ROA, can state that a particular ASN is authorized to originate a particular prefix.

For example:

ROA:
Prefix: 203.0.113.0/24
Authorized ASN: AS64500

BGP shows:

203.0.113.0/24 → AS64500

In that case, the observed origin may be classified as RPKI Valid, assuming the prefix length is also permitted.

The current ROA profile is defined in RFC 9582.

Route Origin Validation compares the observed origin with validated authorization data. The mechanism is described in RFC 6811.

The basic comparison is:

Expected origin
        ↓
ROA authorization
        ↓
Observed BGP origin

When they align, the route can be Valid.

When they do not, further investigation is needed.

What Does RPKI Valid Mean?

A Valid route means the applicable RPKI authorization permits the observed origin and prefix length.

Example:

ROA:
203.0.113.0/24 → AS64500

BGP:
203.0.113.0/24 → AS64500

Result:

Valid

This is a useful security signal.

But Valid does not mean:

• the entire AS path is trustworthy;
• the route is optimal;
• every upstream relationship is correct;
• the registry data is current;
• the IP reputation is clean.

RPKI origin validation addresses one specific question:

Is this ASN authorized to originate this prefix?

What Does RPKI Invalid Mean?

An Invalid state can occur when a covering ROA exists but the live route does not match it.

Example:

ROA:
203.0.113.0/24 → AS64500

Observed BGP:
203.0.113.0/24 → AS64501

This deserves investigation.

Possible causes include:

• unauthorized origination;
• stale ROA;
• ASN migration;
• provider change;
• configuration error;
• incorrect maxLength;
• incomplete change management.

An Invalid route should not automatically be described as malicious.

Legitimate routing changes can become Invalid when authorization records are not updated.

NRS examines this wider issue in ROA Coverage vs ROV Adoption in 2026: Why the Routing Security Gap Matters.

What Does RPKI Not Found Mean?

Not Found means no applicable validated ROA covers the route.

For example:

BGP:
203.0.113.0/24 → AS64500

ROA:
None found

That does not mean the route is automatically illegitimate.

It means RPKI cannot provide origin authorization for that announcement.

You therefore need to examine other information.

Step 6: Check IRR Routing Information

The Internet Routing Registry, or IRR, provides another source of routing-policy information.

An IRR route object might contain:

route: 203.0.113.0/24
origin: AS64500

This can support the expectation that AS64500 should originate the prefix.

But IRR data and BGP data serve different functions.

IRR describes registered routing information.

BGP shows what networks are actually announcing.

An IRR object may be:

• current;
• outdated;
• duplicated;
• missing;
• inconsistent with production routing.

That is why IRR should be treated as supporting evidence rather than a complete representation of live network state.

Step 7: Look for More-Specific Prefixes

Checking only the aggregate prefix can miss important routing information.

Suppose:

203.0.112.0/23 → AS64500

appears normal.

But you also discover:

203.0.113.0/24 → AS64501

The /24 is more specific than the /23.

In normal Internet routing, a more-specific route can attract traffic for the addresses it covers.

This means investigating only the aggregate may hide:

• traffic engineering;
• multi-provider routing;
• DDoS mitigation;
• accidental leaks;
• unexpected origination;
• potentially unauthorized announcements.

Always check for more-specific routes when investigating a prefix.

Step 8: Check for Multiple-Origin AS Announcements

Sometimes the same prefix is observed originating from more than one ASN.

This is often called a MOAS, or Multiple-Origin Autonomous System, situation.

Example:

203.0.113.0/24 → AS64500
203.0.113.0/24 → AS64501

A MOAS is not automatically an attack.

Legitimate reasons can include:

• migration between providers;
• anycast;
• DDoS mitigation;
• multihoming architecture;
• operational transition.

But it should be understood.

Ask:

• Are both ASNs expected?
• Are both authorized?
• Does the organization know about both?
• Is the situation temporary?
• Do the ROAs permit both origins?
• Has the route recently changed?

Step 9: Compare Multiple BGP Views

One routing collector does not necessarily see every route in exactly the same way.

Different networks can receive different paths.

Therefore, important investigations should compare multiple views.

This is especially useful when investigating:

• partial reachability;
• suspected route leaks;
• unusual regional behavior;
• recent origin changes;
• intermittent routing.

A prefix might appear normally from one observation point while another shows a different path.

That is why BGP investigation should not rely on a single local router when the issue affects global reachability.

Step 10: Check Routing History

Current routing is only part of the story.

Historical BGP data can help answer:

• When did this ASN begin announcing the prefix?
• Was a different ASN used previously?
• Did the change happen during a migration?
• Did an unexpected origin appear briefly?
• Has the prefix been unstable?
• Was the prefix previously unannounced?

Consider:

January:
203.0.113.0/24 → AS64500

May:
203.0.113.0/24 → AS64501

That change may be legitimate.

But it should correspond to something explainable:

• provider migration;
• corporate restructuring;
• new ASN;
• network acquisition;
• DDoS mitigation service;
• routing incident.

Historical context often makes current BGP data much easier to interpret.

Registry State vs Routing State vs Authorization State

One of the most useful ways to investigate Internet number resources is to think in layers.

These layers should often align.

But they are not interchangeable.

For example:

Registry:
Example Company Ltd.

Expected ASN:
AS64500

RPKI:
AS64500 authorized

Live BGP:
AS64501

This immediately tells you something deserves investigation.

The problem may be:

• BGP;
• stale authorization;
• incomplete migration;
• internal documentation;
• or a legitimate change not yet reflected elsewhere.

The comparison reveals the inconsistency.

It does not automatically tell you which layer is wrong.

Does the Origin ASN Tell You Who Owns the IP Address?

No.

An origin ASN tells you which Autonomous System is observed originating a route.

It does not automatically prove legal ownership or contractual rights to the IP address space.

The prefix may be announced by:

• a transit provider;
• hosting provider;
• cloud operator;
• mitigation service;
• infrastructure partner.

Likewise, an organization appearing in RDAP should not automatically be described as the legal owner in every jurisdiction or contractual context.

Registration information can be important evidence.

Legal and contractual questions may also depend on:

• allocation or assignment history;
• transfer documents;
• contracts;
• corporate records;
• applicable RIR procedures;
• applicable law.

This distinction helps prevent technical observations from being overstated.

Does BGP Prove That an Announcement Is Authorized?

No.

BGP distributes reachability information.

It does not independently prove that the origin has permission to announce the prefix.

That is one reason RPKI exists.

RFC 6811 describes origin validation specifically as a way to assess whether the ASN claiming to originate a prefix is authorized to do so.

So:

BGP asks:

Who is announcing it?

RPKI asks:

Is that origin authorized?

Those are different questions.

Can a Prefix Be Registered but Not Announced?

Yes.

A prefix can appear in registry data while not being visible in the global BGP table.

Possible reasons include:

• unused address space;
• future deployment;
• internal-only use;
• temporary withdrawal;
• routing outage;
• migration;
• incorrect BGP configuration.

This is why a successful RDAP lookup should never be used as proof that a prefix is globally reachable.

Can a Prefix Be Announced by a Different Organization?

Yes.

A resource holder or registrant may use another organization to provide routing.

For example:

Registered organization:
Enterprise A

Origin ASN:
Transit Provider B

This can be completely legitimate.

What matters is whether:

• the relationship is expected;
• authorization is correct;
• records are maintained;
• operational responsibility is understood.

Why Unexpected Origin Changes Matter

An unexpected origin ASN can indicate a range of situations.

Some are routine.

Others deserve immediate investigation.

Possible explanations include:

Provider Migration

The network has moved to a new provider but internal records have not been updated.

ASN Migration

The organization has changed the ASN used to originate the route.

DDoS Mitigation

A mitigation provider temporarily announces the prefix.

Anycast

Multiple locations or networks intentionally originate the same address space.

Configuration Error

A provider or customer announces an incorrect prefix.

Route Leak

Routing information propagates beyond its intended scope.

Unauthorized Announcement

Another ASN originates the prefix without expected authorization.

Context determines which explanation is correct.

What Should You Do If the BGP Origin Looks Wrong?

Use a structured investigation.

1. Confirm the Prefix

Make sure you are checking the correct CIDR range.

2. Verify Multiple Routing Views

Do not depend on one BGP observation point.

3. Compare Registry Data

Check whether the RDAP information matches the organization and resource you expect.

4. Check RPKI

Compare:

Observed ASN
vs
Authorized ASN

5. Review IRR Objects

Look for the expected route and origin.

6. Check Recent Changes

Ask whether there was:

• a provider change;
• ASN migration;
• DDoS event;
• transfer;
• infrastructure change.

7. Check More-Specific Routes

An unexpected more-specific may be attracting only part of the traffic.

8. Contact the Relevant Network

Provide precise technical information:

• prefix;
• observed ASN;
• expected ASN;
• RPKI status;
• timestamp;
• affected geography;
• routing evidence.

NRS provides a broader incident framework in What Happens When Internet Routing Goes Wrong?.

Why Companies Should Monitor Their Own BGP Announcements

BGP monitoring should not begin only after an outage.

Organizations with important public IP resources should know:

• which prefixes they expect to announce;
• which ASN should originate each prefix;
• where those routes should appear;
• whether RPKI authorizations remain correct;
• whether unexpected origins appear.

A basic inventory might look like:

This turns routing from an invisible dependency into something auditable.

When Should You Check BGP?

BGP verification is particularly useful during:

• IPv4 transfers;
• ASN changes;
• provider migrations;
• mergers and acquisitions;
• data-centre migrations;
• RPKI changes;
• DDoS events;
• unexplained reachability problems;
• network audits.

NRS recommends checking routing as part of a wider Internet number resource audit.

BGP Monitoring During IPv4 Transfers

IPv4 transfers deserve particular attention.

A registry transfer can update the administrative relationship around the resource.

But network routing must still be configured separately.

After a transfer, an operator may need to update:

• BGP origin;
• ROA;
• IRR route objects;
• reverse DNS;
• contacts;
• internal inventory;
• upstream filters.

This is another reason registry completion should not be confused with network deployment.

Administrative change and operational change need to remain coordinated.

The Most Important Verification Pattern

A useful operational workflow is:

1. Identify the prefix
        ↓
2. Check RDAP
        ↓
3. Check live BGP
        ↓
4. Identify origin ASN
        ↓
5. Check RPKI
        ↓
6. Review IRR
        ↓
7. Compare with internal records

Do not assume one system provides the whole answer.

Each layer answers a different question.

A Practical BGP Prefix Verification Checklist

Why This Matters for Internet Number Resource Management

IP addresses and ASNs are not only database entries.

They are part of a running network.

A well-managed organization should understand both:

Administrative reality

and

Operational reality

Registry data supports coordination.

RPKI supports origin authorization.

IRR supports routing-policy information.

BGP shows actual routing behavior.

None of these layers should be expected to replace the others.

The strongest operational model is one in which each layer can be independently checked and inconsistencies can be detected quickly.

That supports:

• routing resilience;
• security;
• auditability;
• troubleshooting;
• portability;
• operational continuity.

Final Takeaway

Checking who is announcing an IP prefix is fundamentally a BGP question.

Start by finding the current origin ASN in routing data.

Then verify the surrounding context.

Check:

1. BGP — Who is actually announcing the prefix?
2. RDAP — Which organization is associated with the resource?
3. RPKI — Which ASN is authorized?
4. IRR — What routing information is registered?
5. Internal records — What should the network be doing?

Do not treat one database as the complete source of truth.

A registry record does not route the prefix.

A BGP announcement does not prove authorization.

A ROA does not describe the entire AS path.

An IRR object does not guarantee current production routing.

Reliable network operations depend on understanding how these layers relate.

The objective is not merely to know who appears in a database.

It is to verify that registration, authorization and the running network remain aligned.