The Internet depends on a global routing system that allows networks, data centers, cloud platforms, Internet service providers, and enterprises to exchange traffic. One of the most important protocols in this system is the Border Gateway Protocol, commonly known as BGP. BGP allows independent networks to announce which IP address ranges they can reach. Without BGP, the modern Internet would not be able to connect millions of networks across different countries and providers.However, BGP was originally designed to exchange routing information based largely on trust. When a network announces an IP prefix, other networks may accept the announcement without having a strong cryptographic method to confirm whether that network is actually authorized to use the prefix. This creates a security problem. An incorrect or malicious route announcement can redirect traffic, interrupt services, or expose data to unwanted paths.
RPKI was developed to improve the security of Internet routing. The name stands for Resource Public Key Infrastructure. It provides a way to connect Internet number resources, such as IPv4 and IPv6 prefixes, with the Autonomous System Number authorized to originate them. Network operators can then use this information to determine whether a BGP announcement is consistent with the recorded authorization.
For businesses operating their own ASN, managing IP resources, using multiple upstream providers, or planning to announce IPv4 or IPv6 space, understanding RPKI is becoming increasingly important. RPKI does not replace BGP, and it does not solve every routing problem. Instead, it provides an additional layer of verification that helps networks make safer routing decisions.
What Is RPKI?
RPKI is a security framework that uses digital certificates and cryptographic records to verify the relationship between an IP address prefix and an origin ASN. An IP prefix is a block of addresses, such as an IPv4 /24 or an IPv6 /48. An ASN identifies an independent network that participates in BGP routing.
The basic idea is simple. An organization that is authorized to use an IP prefix publishes a signed statement identifying which ASN is allowed to originate that prefix in BGP. Networks that receive BGP announcements can compare the announcement with the published information. If the announcement matches, it can be treated as authorized. If it conflicts with the information, the announcement may be considered suspicious or invalid.
The records used to express this authorization are commonly called Route Origin Authorizations, or ROAs. A ROA identifies an IP prefix, an authorized origin ASN, and, when applicable, the maximum prefix length that the ASN is permitted to announce. Although ROAs are an important part of RPKI, this article focuses on the broader purpose of RPKI and how it improves routing security.
RPKI is generally operated through the Regional Internet Registries, including RIPE NCC, ARIN, APNIC, LACNIC, and AFRINIC. Depending on the region and resource type, the resource holder or sponsoring organization can create and manage the relevant authorization records through the registry’s systems.
Why Does BGP Need RPKI?
BGP was created at a time when the Internet was smaller and the number of participating networks was limited. Its primary purpose was to exchange reachability information between autonomous systems. BGP can select paths based on policy, path length, local preference, and other attributes, but the protocol itself does not automatically verify whether an ASN is authorized to originate a particular IP prefix.
This means that a configuration mistake can sometimes look similar to a malicious announcement. If a network accidentally announces a prefix belonging to another organization, other networks may initially accept the route. The result can be traffic going to the wrong destination, loss of connectivity, or unstable routing.
A well-known example is a route leak or prefix hijack. In a hijack, an ASN announces a prefix that it does not control or that it is not supposed to originate. The announcement may be more specific than the legitimate route, or it may reach enough networks to affect traffic. Even when the incident is accidental, the operational impact can be significant.
RPKI helps by giving network operators an external source of authorization information. Instead of relying only on the content of a BGP announcement, a router or routing security system can check whether the origin ASN has been authorized by the holder of the address space. This does not prevent every routing incident, but it makes one important class of routing errors easier to identify and filter.
How Does RPKI Work?
RPKI works through a chain of trust. Internet number resources are managed by Regional Internet Registries, and those registries provide the foundation for the relevant digital certificates. The holder of an IP resource can create an authorization record stating which ASN may originate the prefix.
The signed records are collected into repositories that can be accessed by routing security software. A network operator runs an RPKI validator, or uses a service that performs validation on its behalf. The validator downloads the available records, verifies their signatures, checks whether they are current, and produces a validated dataset.
The validated dataset is then connected to the network’s routing infrastructure. When a BGP route is received, the router or routing policy system compares the announced prefix and origin ASN with the validated RPKI information. The result is normally classified as Valid, Invalid, or Not Found.
This process happens separately from the BGP session itself. BGP continues to exchange routing information, while RPKI supplies additional authorization data that can be used in routing policy. A network can decide how to handle each validation result. For example, it may reject Invalid routes, assign them a lower preference, or generate alerts for further review.
The process is designed to be distributed and scalable. Large networks can validate many thousands of prefixes without requiring every organization to establish a direct relationship with every other network. This is important because the Internet includes a huge number of independent operators with different policies and technical environments.
What Is a Route Origin Authorization?
A Route Origin Authorization is a signed record that states which ASN is authorized to originate a specific IP prefix. It is one of the most visible and practical parts of RPKI deployment.
For example, an organization may control the IPv4 prefix 192.0.2.0/24 and use ASN AS64500 to announce it. The organization can create an authorization that allows AS64500 to originate 192.0.2.0/24. If another ASN later announces the same prefix, networks performing RPKI validation can detect that the origin does not match the authorization.
The authorization can also specify a maximum prefix length. This is important because a network may want to permit the origin ASN to announce the exact aggregate prefix but not smaller, more-specific prefixes. A carefully selected maximum length can reduce the risk of an unexpected announcement being treated as authorized.
ROA configuration requires attention because an incorrect record can make a legitimate route appear invalid. If an organization changes its transit provider, moves a prefix to a different ASN, splits an announcement into more-specific prefixes, or transfers resources to another holder, the authorization records may need to be updated. A stale record can cause an outage even when the BGP configuration itself is correct.
A future article can explain how to create a ROA, how to choose a maximum length, and how to update authorizations during an ASN or IP resource migration.
What Do Valid, Invalid, and Not Found Mean?
A Valid result means that a BGP announcement is covered by an applicable RPKI authorization and that the origin ASN is permitted to announce the prefix. It generally indicates that the announced prefix, prefix length, and origin ASN are consistent with the published authorization.
An Invalid result means that an authorization exists, but the BGP announcement does not comply with it. This may happen because the origin ASN is not authorized, because the announcement is more specific than the permitted maximum length, or because the prefix overlaps an authorization for a different origin. Invalid routes deserve immediate attention because they may represent a hijack, an accidental configuration, or an incomplete migration.
A Not Found result means that no applicable authorization was found for the announcement. It does not automatically mean that the route is malicious or incorrect. It simply means that RPKI cannot confirm the origin using the currently published records. Many legitimate routes remain Not Found because the resource holder has not created an authorization.
The distinction between Invalid and Not Found is important. Invalid indicates a conflict with existing authorization data, while Not Found indicates a lack of authorization data. Network operators often treat Invalid routes more seriously, but their exact routing policy depends on their risk tolerance, service requirements, and operational procedures.
Why RPKI Matters for IPv4 Networks
IPv4 address space is limited, and many IPv4 prefixes are now used across complex arrangements involving providers, data centers, cloud platforms, leasing companies, and transfer transactions. These arrangements make routing accuracy especially important.
When an IPv4 prefix is transferred or moved between organizations, the BGP origin may also change. If the previous owner’s authorization remains active while the new owner announces the prefix from a different ASN, the route can become RPKI Invalid. This is one reason that RPKI planning should be included in IPv4 transfer and migration work.
Before accepting or announcing an IPv4 prefix, an organization should confirm which entity controls the resource, which ASN is expected to originate it, and whether the relevant authorization records reflect the planned routing design. The public registry record, BGP announcements, and RPKI information should be reviewed together.RPKI is particularly useful when a company uses multiple transit providers. A consistent origin authorization can help protect the prefix regardless of which upstream provider carries the route. However, the organization still needs to make sure that all providers are using the correct ASN and prefix length.
Businesses evaluating an IPv4 block can also use public tools to review current registration data, origin ASN information, RPKI status, and BGP visibility. These checks do not replace contractual due diligence or reputation screening, but they can reveal obvious routing inconsistencies before a transaction or deployment.
Why RPKI Matters for IPv6 Networks
IPv6 networks benefit from the same origin validation principles as IPv4 networks. IPv6 prefixes are announced through BGP, and an incorrect origin can create similar risks, including traffic interruption, route leaks, and unauthorized announcements.
IPv6 deployments often involve larger address blocks and more structured addressing plans. An organization may receive a broad allocation and announce an aggregate while using smaller internal subnets for sites, data centers, or services. RPKI authorization should match the prefixes that are actually intended for public routing.
A common mistake is to assume that IPv6 routing is automatically safer because IPv6 has a much larger address space. The size of the address space does not remove the need to verify route origin. If an IPv6 prefix is announced by an incorrect ASN and no authorization exists, other networks may have limited ability to distinguish the announcement from a legitimate route.Organizations deploying IPv6 should include RPKI in their initial routing design rather than waiting until the network is fully operational. This makes it easier to coordinate the address plan, ASN usage, upstream providers, and authorization records before production traffic depends on the announcement.
What Are the Main Benefits of RPKI?
The main benefit of RPKI is that it provides a widely recognized method for validating the origin of a BGP route. This gives network operators a stronger basis for filtering and monitoring announcements than BGP information alone.
RPKI can reduce the risk of accepting routes that are clearly inconsistent with the resource holder’s stated authorization. It can also help identify operational mistakes during network migrations, provider changes, ASN sponsorship changes, and IPv4 or IPv6 resource transfers.
For IP resource holders, RPKI demonstrates that the organization is actively managing the routing security of its address space. This can improve coordination with transit providers and reduce confusion when multiple parties are involved in announcing the same prefix.
For transit providers and hosting companies, RPKI validation can become part of a broader routing security program. Providers can use validation results alongside prefix filters, IRR data, BGP monitoring, and internal routing policies. No single data source is perfect, but combining several signals provides better operational visibility.
RPKI also improves incident response. When an unexpected BGP announcement appears, the network team can quickly check whether the origin is authorized. This can help distinguish a potential hijack from a legitimate but undocumented routing change.
What RPKI Cannot Do
RPKI is valuable, but it is not a complete replacement for routing security. It validates the relationship between a prefix and an origin ASN. It does not prove that every hop in the BGP path is trustworthy, and it does not guarantee that traffic will follow the best or safest physical route.
RPKI does not encrypt application traffic. It does not protect web sessions, DNS queries, email, or private data from interception. Encryption technologies such as TLS, VPNs, and secure application protocols are still required for those purposes.
RPKI also does not automatically prevent every route leak. A route can be originated by the correct ASN but still be propagated to places where it should not appear. Origin validation may classify such a route as Valid because the origin is authorized, even though the broader path is operationally wrong.
RPKI does not prove legal ownership by itself. Registry records, contracts, transfer documents, and organizational authorization remain important. A Valid result indicates that the route matches a published authorization; it does not confirm that every commercial or legal requirement has been satisfied.
Finally, RPKI only works effectively when records are maintained. An organization that creates authorizations and then forgets to update them after a provider or ASN change can create its own routing outage.
How Can a Business Start Using RPKI?
The first step is to create an inventory of all IPv4 and IPv6 prefixes that the organization owns, leases, sponsors, or expects to announce. For each prefix, record the intended origin ASN, the announcing providers, the prefix length, and whether the prefix is currently visible in BGP.
The next step is to confirm the registry and resource records. The organization should verify that the address space is associated with the correct account, organization, sponsoring LIR, or resource holder. If the public registration data is outdated, it should be corrected before creating new routing authorizations.After the resource inventory is confirmed, the organization can create the appropriate authorization records through its Regional Internet Registry or sponsoring provider. The origin ASN and maximum prefix length should reflect the real routing plan. If several ASNs are legitimately used, the design should be documented carefully rather than adding broad authorizations without a clear reason.
The organization should then validate the records using an RPKI validator or an established monitoring service. It is important to confirm that the intended announcements return a Valid result before applying strict filtering policies to customer or production traffic.
Deployment should be treated as an operational process, not a one-time configuration task. Changes to upstream providers, ASN sponsorship, prefix aggregation, data center locations, and IPv4 transfer arrangements can all affect RPKI records. Monitoring and change management should be part of the normal network workflow.
Common RPKI Deployment Mistakes
One common mistake is creating an authorization for the wrong origin ASN. This often happens during a provider migration when the old ASN remains in the record while the network begins announcing from a new ASN.
Another mistake is setting the maximum prefix length incorrectly. If an organization authorizes only an aggregate but announces a more-specific route, the more-specific announcement may become Invalid. If the maximum length is made too broad, the authorization may permit announcements that the organization did not intend to allow.
Stale records are also a major problem. An authorization that was correct several years ago may no longer match the organization’s current network design. Regular reviews are especially important after an IPv4 transfer, merger, change of sponsoring LIR, or ASN renumbering.
Some organizations also assume that a Not Found result means a route should be rejected. In most cases, Not Found means that no authorization exists. It should be handled according to the network’s policy and risk model, rather than being treated as automatically malicious.
RPKI, IRR, and BGP Monitoring
RPKI is one part of a broader routing security approach. IRR databases contain routing policy objects that can be used by network operators to generate filters. These objects can describe which ASN is expected to originate a prefix, but they use a different trust and validation model from RPKI.
BGP monitoring shows what is actually being announced and where the announcement is visible. It can reveal route changes, unexpected origins, path changes, and periods of instability. RPKI shows whether the origin is authorized, but it does not provide the complete operational history of a route.
For this reason, RPKI, IRR, and BGP monitoring are often used together. A strong routing review may compare the registry record, the expected ASN, the IRR object, the RPKI authorization, and live BGP observations. When these sources agree, the routing position is easier to understand. When they disagree, the difference should be investigated before a migration or transfer is completed.
How Should RPKI Be Maintained?
RPKI maintenance should be connected to network change management. When an organization plans to change its origin ASN, upstream provider, prefix length, or announcement location, it should review the expected effect on authorization records before the change is made.
Monitoring should alert the network team when an expected prefix becomes Invalid, when an authorization is removed, or when a previously unseen origin appears. Alerts are most useful when they include the affected prefix, origin ASN, current validation state, and time of the change.
Organizations should also document who is responsible for managing RPKI. In some companies, the network engineering team manages the records. In others, the sponsoring LIR, managed service provider, or security team handles them. Clear ownership helps prevent delays during incidents and provider migrations.
A periodic review can be scheduled monthly, quarterly, or whenever a major routing change occurs. The appropriate frequency depends on the size and complexity of the network. The important point is that RPKI should be treated as a living part of the routing system.
Frequently Asked Questions About RPKI
Is RPKI required to use BGP?
No. A network can use BGP without publishing RPKI authorization records. However, RPKI is increasingly recommended because it gives other networks a way to validate the origin of the routes that the organization announces.
Does RPKI prevent a BGP hijack?
RPKI does not physically prevent another network from sending an unauthorized BGP announcement. It allows receiving networks to identify announcements that do not match published authorization. Networks can then reject, de-preference, or monitor those routes according to their policies.
Is RPKI only for IPv4?
No. RPKI supports both IPv4 and IPv6 prefixes. The same basic origin validation concept applies to both address families.
Is an RPKI Not Found result dangerous?
Not necessarily. Not Found means that no applicable authorization was found. It does not prove that the route is wrong. However, resource holders should consider publishing accurate authorizations so that other networks can validate their announcements.
Can RPKI replace an IRR route object?
No. RPKI and IRR serve different purposes and are often used together. Some providers use both systems when building routing filters and reviewing announcements.
What happens if an RPKI record is wrong?
A wrong record can cause a legitimate BGP announcement to be classified as Invalid. The organization should review the origin ASN, prefix length, and maximum length, then update the authorization before applying strict route filtering.
RPKI is an important improvement to the security of Internet routing. It gives IP resource holders a way to publish cryptographic authorization for the ASNs that are allowed to originate their IPv4 and IPv6 prefixes. It also gives network operators a practical method for checking whether BGP announcements match that authorization.
The concept is straightforward: the holder of an IP prefix publishes the intended origin, and other networks validate the announcement against that information. The result can help identify authorized routes, conflicting routes, and routes for which no authorization has been published.RPKI does not replace careful network engineering, registry management, IRR records, BGP monitoring, or contractual due diligence. It also does not guarantee that every route is safe or that every routing incident will be prevented. Its value comes from adding a reliable authorization signal to the routing process.
For organizations managing an ASN, IPv4 space, IPv6 space, or multiple upstream providers, RPKI should be included in the normal routing design. Before announcing a prefix, changing providers, completing an IPv4 transfer, or deploying a new IPv6 network, review the registry data, origin ASN, authorization records, and live BGP state together. That simple process can prevent avoidable mistakes and improve the overall reliability of Internet connectivity.