The Role of IP Address Prefixes in RPKI

The Role of IP Address Prefixes in RPKI

IP address prefixes are fundamental to Internet routing.

Border Gateway Protocol, or BGP, does not normally advertise individual public IP addresses one by one. Instead, networks announce groups of addresses represented as prefixes, such as203.0.113.0/24.

Resource Public Key Infrastructure, or RPKI, uses those same routing prefixes as part of a cryptographically verifiable system for route-origin authorization.

Through a Route Origin Authorization, or ROA, a resource holder can publish information specifying which Autonomous System Number is authorized to originate routes for one or more IP prefixes.

In RPKI, the IP prefix defines the address space covered by the authorization, while the origin ASN identifies the Autonomous System authorized to originate it.

This distinction matters. RPKI helps validate route-origin authorization. It does not establish conventional property ownership, validate the entire BGP path, or eliminate every possible routing incident.

IP Address Prefixes in RPKI: Quick Answer

An IP address prefix identifies a block of IPv4 or IPv6 addresses using CIDR notation.

Within RPKI, prefixes appear in Route Origin Authorizations. A ROA specifies:

• an authorized origin ASN;
• one or more IP prefixes; and
• optionally, a maximum prefix length for each authorization.

Networks performing Route Origin Validation can compare BGP announcements with validated RPKI information and classify the route origin as Valid, Invalid or NotFound/Unknown.

The important question is:

Does the observed BGP origin match the authorization published for this IP prefix?

That is different from asking who legally owns the addresses.

What Is an IP Address Prefix?

An IP address prefix represents a contiguous block of IP addresses.

Prefixes are normally written using CIDR notation.

For example:

203.0.113.0/24

The/24means that the first 24 bits identify the network prefix.

An IPv4 /24 contains 256 addresses.

Other common IPv4 prefix sizes include:

IPv6 uses the same general concept with a much larger address space.

For routing purposes, the prefix is important because BGP announcements describe reachability to prefixes rather than simply identifying individual devices.

What Is RPKI?

Resource Public Key Infrastructure is a cryptographic framework designed to improve Internet routing security.

One of its most widely deployed uses is Route Origin Validation.

RPKI allows holders of Internet number resources to publish cryptographically verifiable authorization information describing which Autonomous Systems may originate their IP prefixes.

The mechanism most commonly associated with this function is the Route Origin Authorization.

The current IETF specification for ROAs is RFC 9582 — A Profile for Route Origin Authorizations .

RFC 9582 replaced the earlier RFC 6482 specification.

For a broader introduction, read What Is RPKI? How RPKI and ROA Secure BGP .

What Role Does the IP Prefix Play in a ROA?

The prefix defines the scope of the routing authorization.

A ROA essentially expresses a relationship between:

IP prefix + authorized origin ASN + permitted prefix length

Consider a simplified example.

Suppose an organization uses:

• Prefix:203.0.113.0/24
• Origin ASN:AS64500

A suitable ROA can express that AS64500 is authorized to originate the relevant prefix.

Networks performing RPKI Route Origin Validation can then compare observed BGP announcements with that authorization.

RPKI Validates Route-Origin Authorization, Not Prefix Ownership

It is important to use precise terminology when describing RPKI.

RPKI should not be described simply as a system that “verifies who owns an IP prefix.”

The principal routing function of a ROA is more specific: it provides cryptographically verifiable information indicating that an ASN has been authorized to originate one or more prefixes.

RPKI helps answer: “Is this ASN authorized to originate this prefix?”

It does not by itself answer:

“Who legally owns every right associated with this IP address block?”

Those are different questions.

A useful framework is:

legal and commercial rights → registry state → routing authorization → operational use

RPKI primarily operates in the routing-authorization layer.

How Prefixes, ASNs and ROAs Work Together

Three elements are especially important when understanding route-origin authorization.

What Is maxLength in a ROA?

Prefix length is one of the most important details in ROA configuration.

A ROA can authorize an exact prefix, or it can allow the same ASN to originate permitted more-specific prefixes through the optionalmaxLengthvalue.

For example, imagine the authorized resource is:

203.0.113.0/24

If the network should announce only the /24, the authorization can be limited accordingly.

If the network legitimately needs to advertise /25 more-specific routes, the ROA can permit a maximum length of /25.

The authorization should reflect the real routing design.

A broader maxLength should not be configured simply for convenience. Authorize only the prefix lengths the network actually expects to originate.

Why Prefix Length Matters for Route Origin Validation

RPKI validation checks more than whether the origin ASN appears in a ROA.

The announced prefix length must also fall within the authorization.

Suppose a ROA covers:

• Prefix:203.0.113.0/24
• ASN:AS64500
• Maximum length:/24

An announcement of203.0.113.0/24from AS64500 can match that authorization.

But an announcement of a /25 inside the same block would exceed the permitted prefix length.

That route could therefore receive an Invalid origin-validation state, even though it originates from the expected ASN.

Valid, Invalid and NotFound RPKI States

When a BGP announcement is compared with validated RPKI authorization data, it is commonly classified into one of three origin-validation states.

The RIPE NCC provides additional information about these states in BGP Origin Validation .

Valid Does Not Mean “Everything About the Route Is Safe”

A Valid origin-validation state has a specific meaning.

It means the observed prefix and origin ASN are consistent with validated RPKI authorization information.

It does not necessarily mean:

• the complete AS path is legitimate;
• the route cannot be leaked;
• the path is optimal;
• the operator has no configuration problems;
• the prefix has clean reputation;
• the route represents legal ownership; or
• the announcement cannot participate in another routing incident.

Route Origin Validation validates the origin relationship, not the complete path that BGP traffic follows.

Invalid Does Not Automatically Mean BGP Hijacking

An Invalid route should be investigated, but it should not automatically be described as proof of malicious hijacking.

A legitimate route can become Invalid because of:

• an outdated ROA;
• an ASN migration;
• a provider change;
• an incorrect origin ASN;
• a missing authorization for a new ASN;
• an overly restrictive maximum length;
• a new more-specific announcement; or
• poorly coordinated change management.

Malicious or unauthorized announcements can also be Invalid.

The validation state is therefore a routing-security signal, not a complete diagnosis of intent.

NotFound Is Different From Invalid

If a BGP announcement is not covered by an applicable validated ROA, its origin-validation state is commonly described as NotFound or Unknown.

This is not the same as Invalid.

NotFound means the RPKI system does not currently provide a covering authorization against which that route can be validated.

It does not by itself mean that:

• the route is malicious;
• the prefix is illegitimate;
• the ASN is hijacking the resource; or
• the route must automatically be rejected.

Network operators decide how RPKI validation states influence their local routing policy.

How RPKI Helps Reduce Certain BGP Hijacking Risks

BGP traditionally does not provide a cryptographic mechanism proving that an origin ASN has been authorized to originate a prefix.

This creates an opportunity for accidental or unauthorized announcements.

RPKI adds a verifiable authorization signal.

Imagine:

• 203.0.113.0/24is authorized for AS64500;
• a different ASN, AS64501, announces the same covered prefix;
• the published ROA does not authorize AS64501.

Networks performing Route Origin Validation can identify that announcement as inconsistent with the published authorization.

They can then apply their own routing policy to the Invalid result.

This can reduce exposure to certain accidental and unauthorized route-origin announcements.

RPKI Does Not Prevent Every Route Leak

Route leaks require an important technical distinction.

A route leak can involve propagation of otherwise legitimate routing information beyond its intended scope.

The originating ASN may still be correctly authorized by a ROA.

In that case, Route Origin Validation can still classify the route origin as Valid even though the broader propagation path is undesirable.

RPKI origin validation helps validate the origin. It does not currently validate the complete BGP AS path.

RPKI should therefore be one component of a broader routing-security strategy, rather than treated as a complete solution to all BGP incidents.

Why More-Specific Prefixes Matter

Networks commonly announce more-specific prefixes for legitimate operational reasons.

These can include:

• traffic engineering;
• multihoming;
• DDoS mitigation;
• regional routing;
• network migration;
• anycast design; and
• customer routing arrangements.

RPKI configuration needs to account for these legitimate announcements.

If a network authorizes only an aggregate prefix but later announces more-specific prefixes outside the permitted length, those routes can become Invalid.

This is why ROA configuration should follow actual routing architecture.

One Prefix Can Be Authorized for Multiple Origin ASNs

Some network architectures require the same address space to be legitimately originated by more than one ASN.

Examples can occur during:

• network migration;
• multi-origin routing;
• DDoS mitigation;
• infrastructure transitions; or
• other supported operational designs.

RFC 9582 defines a ROA as identifying a single authorized AS.

If the same prefixes need legitimate authorization for multiple ASNs, separate appropriate ROAs can be created for those ASNs.

RPKI Resource Certificates and Prefix Authorization

RPKI uses a hierarchy of resource certificates associated with Internet number resources.

The certificate structure allows the RPKI system to verify that the entity creating a ROA has appropriate resource authority within the RPKI certification framework for the prefixes covered by that object.

This provides a cryptographically verifiable authorization chain for routing-security purposes.

It should still not be described as a universal legal property system.

RPKI certification establishes authorization relevant to the RPKI system. It does not replace contracts, registry records, applicable law or broader operational relationships.

RPKI, Registry State and BGP Are Different Layers

RPKI is most useful when understood as part of a broader Internet-resource system.

These systems are related, but one should not be used as a substitute for another.

RPKI vs IRR Route Objects

RPKI ROAs and IRR route objects can both associate an IP prefix with an origin ASN, but they do so through different systems.

The two mechanisms can complement each other.

For more detail, read What Is an IRR Route Object? A Guide for Network Operators .

Why Prefixes Must Stay Aligned Across RPKI, IRR and BGP

Production routing works best when the relevant systems describe the same intended operational reality.

For example:

• BGP should announce the intended prefix from the intended ASN;
• the ROA should authorize that origin and required prefix length;
• IRR objects should reflect expected routing policy where they are used;
• registry information should remain accurate; and
• network operators should know who is responsible for updates.

Misalignment can create routing problems even when each individual system is functioning correctly.

Common RPKI Prefix Configuration Mistakes

1. Authorizing the Wrong Origin ASN

If the ROA specifies an ASN different from the ASN actually originating the prefix, a legitimate route can become Invalid.

2. Using the Wrong Prefix Length

A network may create authorization for an aggregate but later advertise more-specific routes that are not permitted.

Those announcements can become Invalid.

3. Using an Overly Broad maxLength

Operators should avoid automatically permitting substantially more-specific routes than their network design requires.

Authorization should be as precise as practical.

4. Forgetting ROAs During ASN Migration

If a prefix moves from one origin ASN to another, RPKI changes should be coordinated with the BGP migration.

Otherwise, the new legitimate route can temporarily become Invalid.

5. Removing Old Authorization Too Early

During a controlled migration, deleting an old authorization before the old route has fully disappeared can create avoidable validation problems.

RPKI and BGP changes should follow a deliberate sequence.

6. Treating ROA Creation as a One-Time Task

Routing architecture changes.

ASNs change, providers change, DDoS mitigation may be introduced, and prefixes may be restructured.

ROAs therefore need lifecycle management rather than one-time configuration.

IP Prefixes, RPKI and Network Migration

RPKI becomes particularly important during network changes.

Imagine an organization migrating a prefix from AS64500 to AS64501.

If the existing ROA authorizes only AS64500 and the organization begins announcing from AS64501, the new route may become Invalid.

A safer migration requires coordination between:

• the intended BGP change;
• ROA updates;
• IRR updates where applicable;
• upstream routing policies;
• monitoring; and
• removal of obsolete authorization after the transition.

Routing authorization should follow operational reality, but authorization changes should be sequenced carefully so that legitimate routes remain valid throughout the migration.

IP Prefixes, RPKI and IPv4 Leasing

RPKI is also relevant when IPv4 addresses are leased.

A customer may receive the right to use a prefix while another organization maintains the underlying resource relationship.

The customer's own ASN may then originate the leased prefix.

In this situation, the operational questions include:

• Which ASN will originate the prefix?
• Who can create or update the relevant ROA?
• What prefix lengths need to be authorized?
• How quickly can authorization changes be made?
• What happens if the customer changes ASN?
• How are ROAs updated when the lease ends?

RPKI therefore illustrates an important separation:

The party operating the network, the party carrying the underlying resource relationship and the party responsible for registry-facing administration do not always need to be the same organization.

What matters operationally is that responsibilities are clear and routing authorization accurately reflects legitimate use.

RPKI Should Support Operator Autonomy

RPKI provides a common routing-security signal, but individual network operators still determine how that signal affects their routing policy.

This distinction is important.

The common system can provide cryptographically validated information about route-origin authorization.

Independent networks then use that information according to their own routing and risk-management policies.

RPKI provides a shared authorization signal. BGP policy remains an operator decision.

RPKI Is Important, but It Is Not the Entire Routing-Security System

RPKI should be used as part of a broader operational approach.

Network operators may also rely on:

• BGP monitoring;
• IRR-based filtering;
• prefix limits;
• routing-policy controls;
• peer and transit filtering;
• change management;
• incident response;
• route-leak mitigation mechanisms; and
• operational monitoring.

RPKI improves one important part of the routing-security problem: verifying route-origin authorization.

It should not be expected to solve every BGP security issue by itself.

RPKI and Network Continuity

Correct RPKI configuration is not only a security issue. It can also become a continuity issue.

A production prefix may support:

• customer services;
• APIs;
• VPN infrastructure;
• hosting platforms;
• SaaS applications;
• payment systems;
• enterprise allowlists; and
• other long-running infrastructure.

If a legitimate route becomes Invalid because RPKI state was not updated during a routing change, networks applying strict Route Origin Validation policy may stop accepting that route.

This is why RPKI should be integrated into operational change-management procedures.

Routing security and network continuity are strongest when BGP configuration and authorization state remain aligned.

RPKI Does Not Replace Registry Accuracy

RPKI and registry information serve different functions.

Accurate number-resource registration remains important for resource coordination, contacts and administrative processes.

RPKI adds a cryptographically verifiable authorization layer relevant to routing.

Neither should be confused with the complete legal, commercial or operational reality of a network.

A useful separation remains:

commercial rights + registry state + routing authorization + operational use

Best Practices for Managing Prefixes in RPKI

Network operators managing IPv4 or IPv6 prefixes should consider the following practices:

1. Inventory the prefixes you actually announce. Understand which aggregates and more-specific routes appear in BGP.
2. Confirm the correct origin ASN. ROAs should reflect the intended production origin.
3. Authorize only necessary prefix lengths. Avoid unnecessarily broad maxLength settings.
4. Review RPKI before routing changes. ASN migrations and provider changes should include ROA planning.
5. Monitor validation state after deployment. Confirm that expected routes remain Valid.
6. Coordinate IRR and BGP state. Relevant routing systems should describe the same intended origin.
7. Remove obsolete authorization carefully. Do not invalidate routes that are still legitimately operating.
8. Document responsibility. Know who can request and implement RPKI changes.

RPKI Prefix Checklist for IPv4 Operators

How This Applies to LARUS IPv4 Services

For LARUS customers using public IPv4 address space, routing usability depends on more than simply receiving a prefix.

Production deployment may require alignment between:

• the IPv4 prefix;
• the customer's ASN;
• BGP configuration;
• RPKI ROAs;
• IRR records;
• reverse DNS;
• address reputation; and
• the customer's operational requirements.

In a leased IPv4 environment, the customer should retain control over its network and routing policy while the service provider carries clearly defined upstream and registry-facing responsibilities where applicable.

The objective is not to centralize network control. It is to keep routing authorization, resource administration and operational use accurately aligned.

For organizations that require long-term IPv4 continuity, see LARUS IPv4 Leasing Continuity Assurance .

Frequently Asked Questions

What is an IP address prefix in RPKI?

An IP address prefix represents a block of IPv4 or IPv6 addresses. Within a ROA, the prefix identifies address space for which a particular ASN is authorized to originate routes.

Does RPKI verify ownership of an IP prefix?

RPKI should not be treated as a universal property-ownership system. Its principal routing function is to provide cryptographically verifiable information about route-origin authorization.

What does a ROA authorize?

A ROA authorizes a particular Autonomous System to originate routes for one or more specified IP prefixes. It can also constrain the maximum permitted prefix length.

What does maxLength mean in RPKI?

maxLength specifies how specific an authorized BGP announcement may be relative to the prefix contained in the ROA. It should reflect the network's actual routing requirements.

What is RPKI Valid?

Valid means the route announcement is covered by validated authorization that permits the observed origin ASN and prefix length.

What is RPKI Invalid?

Invalid means that a covering authorization exists, but the observed origin ASN or prefix length does not match the applicable authorization.

Does Invalid always mean BGP hijacking?

No. An Invalid route can result from malicious activity, but it can also result from an outdated ROA, ASN migration, configuration mistake or incorrect maximum prefix length.

What does RPKI NotFound mean?

NotFound, sometimes displayed as Unknown, means there is no applicable validated ROA covering the announcement. It is different from Invalid.

Does RPKI prevent all BGP hijacking?

No. Route Origin Validation can help identify certain unauthorized or incorrect route origins, but RPKI origin validation does not secure every aspect of BGP.

Does RPKI prevent route leaks?

Not necessarily. A route leak may still have an authorized origin ASN and therefore appear Valid under Route Origin Validation. Origin validation does not validate the complete AS path.

Can the same prefix be authorized for multiple ASNs?

Yes, where the routing design legitimately requires multiple origins. Separate appropriate ROAs can authorize different ASNs for the relevant prefix or prefixes.

Can an incorrect ROA cause an outage?

It can contribute to reachability problems. If a legitimate route becomes Invalid, networks whose local policy rejects Invalid announcements may no longer accept the route.

Is RPKI important when leasing IPv4?

Yes. If leased IPv4 is originated from the customer's ASN, the routing authorization should accurately reflect that prefix, ASN and required prefix length.

What is the difference between RPKI and IRR?

RPKI provides cryptographically verifiable route-origin authorization. IRR databases publish routing-policy information and may be used by network operators to construct routing filters. The two systems can complement each other.

Conclusion

IP address prefixes are at the center of RPKI Route Origin Authorization.

The prefix identifies the address space covered by an authorization, while the ASN identifies the network authorized to originate it.

Prefix length also matters, because a ROA can restrict how specific legitimate announcements may be.

This allows networks performing Route Origin Validation to compare observed BGP announcements with cryptographically validated route-origin authorization information.

But RPKI has a specific scope.

RPKI validates route-origin authorization. It does not prove conventional ownership, validate the complete BGP path, or replace operator routing policy.

That distinction is important for both routing security and Internet governance.

A useful model remains:

legal and commercial rights + registry state + routing authorization + operational use

RPKI strengthens the routing-authorization layer. Network operators still operate their own networks, select routing policies and manage the operational consequences of changes to their infrastructure.

For a complete introduction to the technology, read What Is RPKI? How RPKI and ROA Secure BGP .

For a deeper explanation of Route Origin Authorization, read What Is Route Origin Authorization (ROA)? .

For more about IRR-based routing information, read What Is an IRR Route Object? .

For organizations using IPv4 in long-term production infrastructure, explore LARUS IPv4 Leasing Continuity Assurance .