How to Create RPKI ROAs in the RIPE Database (Step by Step)

How do you create an RPKI ROA in the RIPE database? Log in to my.ripe.net with your LIR or resource-holder account, enable the RIPE NCC hosted certificate authority, open the RPKI dashboard, and add a new Route Origin Authorization (ROA) that pairs each prefix you announce with the origin AS number that announces it. Set the maxLength equal to the prefix length unless you deliberately announce more-specific routes, then verify the result against what you actually see in BGP.

That single paragraph covers the happy path. The details are where routing incidents come from, so this guide walks through prerequisites, the exact portal steps, the maxLength decision that trips up most people, and the checks that confirm your ROA does what you meant it to do.

What is a ROA and why does it need creating at all?

A Route Origin Authorization is a small, cryptographically signed object that says one thing: "this AS number is allowed to originate BGP routes for this IP prefix." Nothing in BGP does this by default. Anyone can announce your prefix, and historically the internet just believed them, which is how route hijacks (accidental and malicious) knock services offline.

RPKI fixes that by letting the legitimate holder publish a ROA. Routers running Route Origin Validation then mark any announcement that contradicts your ROA as invalid and can drop it. The ROA is the authoritative statement; without one, your prefixes stay in the unknown state and get no protection.

Per RFC 9582, the profile that defines the object (it obsoletes the earlier RFC 6482), a ROA carries exactly three pieces of information:

Creating a ROA is the act of filling in those three fields correctly and signing them. Two of the three are obvious. The third, maxLength, is the one that causes trouble, and we cover it in depth below.

What do you need before you can create a ROA?

Three prerequisites, in order:

1. You hold the resource, or your sponsor does. ROAs can only be issued by the party that holds the resource certificate. If you are a RIPE NCC member (an LIR) with your own allocation, that is you. If you hold Provider Independent (PI) space or an ASN under a sponsoring LIR, the certificate sits with whoever holds the resource in the RIPE database.

2. You know your origin AS. You need the AS number that actually originates the prefix in BGP. If you do not have one yet, an ASN is the prerequisite for most real-world routing, and our complete ASN registration guide covers how to get one.

3. Hosted RPKI is enabled. RIPE NCC lets you either run your own certificate authority or let the NCC host it for you. For the vast majority of holders, hosted is the right call: the private key lives on RIPE's servers, the cryptography is handled automatically, and, as RIPE puts it, "there is nothing you have to manage except making sure that your ROAs match your intended BGP routing."

Who actually clicks the buttons?

This is worth being clear about, because it is a common point of confusion.

• You are an LIR with your own allocation: you create ROAs yourself in your LIR portal.
• You hold PI space or an ASN through a sponsoring LIR: ROA management follows the resource certificate. In many sponsorship arrangements the sponsoring LIR handles RPKI on your behalf.

Via-Registry customers fall into the second group, and this step is already done. When we assign an IPv6 /48 as a PA sub-assignment from our allocation, the matching RPKI ROA is configured automatically at assignment. There is no portal to log into and no maxLength to reason about, because it is set correctly from the start. The rest of this guide is still useful to understand what is happening under the hood, and it is exactly what you need if you run your own LIR. For the distinction between the resource types, see PI versus PA resources.

How do you enable hosted RPKI in the RIPE portal?

The certificate authority is a one-time setup per resource holder.

1. Go to my.ripe.net and sign in with your RIPE NCC Access account.
2. Open the RPKI dashboard (my.ripe.net/#/rpki).
3. If you have not certified before, you will be prompted to choose between hosted and delegated (your-own-CA) modes. Select hosted unless you have a specific operational reason to run Krill or another delegated CA yourself.
4. Confirm. RIPE NCC provisions your resource certificate covering the number resources registered to you.

Once the certificate exists, the dashboard shows two things you will use constantly: a BGP Announcements view (what the NCC currently sees originating your resources in the routing table) and the ROAs view (what you have authorized). Keeping those two in agreement is the whole job.

How do you create a ROA step by step?

With hosted RPKI active, creating a ROA is a short sequence. The portal gives you a web form; the same operations are available through the RIPE RPKI API if you prefer automation.

1. Open the BGP Announcements tab first. It lists every AS number currently announcing your IP resources, with the prefixes and lengths as observed. This is your ground truth. Read it before you author anything, because your ROAs should describe reality, not aspiration.

2. Open the Route Origin Authorisations (ROAs) tab and click New ROA.

3. Enter the prefix. Type the exact block you announce, with its real length, for example 2001:db8:1000::/36 or 203.0.113.0/24. Do not enter the parent allocation if you announce a smaller piece of it.

4. Enter the origin AS. This is the AS number that originates that prefix in BGP. It is the AS… you saw in the BGP Announcements tab.

5. Set the maxLength. This is the decision that matters. The default and safest choice is to leave it equal to the prefix length, which authorizes only the exact prefix. Only raise it if you genuinely announce more-specific routes from that block. See the next section before you touch this field.

6. Watch for the mismatch alert. RIPE improved the dashboard so that if you are about to publish a ROA that does not match what the NCC sees in BGP, you get a warning before it goes live. Do not click past it without understanding why. A mismatch alert usually means you fat-fingered the AS number, the prefix length, or the maxLength.

7. Save. The ROA is signed and published into the RPKI repository, where relying-party software worldwide will pick it up on its next refresh.

Repeat for every prefix and origin-AS pair you announce. If you originate three prefixes from one AS, that is three ROA entries (or one multi-prefix action, depending on the portal flow), not one.

What maxLength should you set, and why be strict?

Here is the rule, backed by the IETF: set maxLength as tightly as your actual announcements allow, and prefer to omit it entirely.

Per RFC 9582, the current ROA profile that obsoletes RFC 6482, when maxLength is absent the AS is authorized to advertise only the exact prefix in the ROA. When present, it must be greater than or equal to the prefix length and no longer than 32 (IPv4) or 128 (IPv6). So 203.0.113.0/24 with maxLength 26 authorizes /24, /25, and /26 announcements inside that block, but not a /27.

That flexibility feels convenient. It is also a documented security hazard. RFC 9319, published as Best Current Practice (BCP 185) and titled The Use of maxLength in the Resource Public Key Infrastructure (RPKI), is unambiguous:

"Operators SHOULD use minimal ROAs whenever possible. A minimal ROA contains only those IP prefixes that are actually originated by an AS in BGP and no other IP prefixes."

and

"operators SHOULD avoid using the maxLength attribute in their ROAs, since its inclusion will usually make the ROA non-minimal."

Why a loose maxLength is dangerous

The threat RFC 9319 describes is the forged-origin sub-prefix hijack. Suppose you hold 192.0.2.0/24 and announce only that /24, so the correct minimal ROA sets maxLength 24, authorizing the exact /24 and nothing more specific. Now widen it: publish maxLength 32 out of laziness. You never announce 192.0.2.128/25, but your own ROA now says that announcement is valid.

An attacker announces 192.0.2.128/25 with your AS number forged as the origin. Because a more-specific route wins in BGP, and because your own loose ROA marks it valid, routers accept it and pull traffic for that half of your block straight to the attacker. You authorized the hijack yourself.

With a minimal ROA (maxLength equal to the prefix length, or omitted), that same forged sub-prefix is invalid and gets dropped by validating routers. The attacker is forced into a far weaker forged-origin whole-prefix hijack, which competes on equal footing with your legitimate announcement instead of trumping it.

The practical guidance:

• Announce one static prefix per block: omit maxLength, or set it equal to the prefix length. This is the common case.
• Announce several fixed more-specifics: create a separate ROA entry for each one you actually announce. More entries, but each is minimal and precise.
• Only use a wide maxLength if you have a real, dynamic need to announce arbitrary more-specifics (rare, and usually a sign of a design worth revisiting).

How do you check the ROA actually works?

Publishing a ROA is not the same as it being correct. Verify it three ways.

1. RIPEstat RPKI validation lookup

The fastest external check. The RIPEstat RPKI Validation data call takes a resource (your AS number) and a prefix, runs the lookup, and returns one of four states:

Query your own AS and prefix. If it says valid, your ROA and your announcement agree. If it says invalid_length, your maxLength is too tight for what you announce (or you are announcing something you should not). If it says unknown, your ROA has not propagated yet or you missed the prefix entirely.

2. Relying-party software

RPKI is only meaningful because validators around the world consume it. Routinator, the open-source relying-party software from NLnet Labs, fetches and cryptographically validates all RPKI data and can tell you the validity of a given prefix and origin AS. Running it (or querying an instance) confirms your ROA is not just published but actually resolves to valid through the same validation path a real network uses. This is the ground truth RIPEstat itself relies on.

3. Give it time, then recheck BGP

Relying parties refresh on a schedule, so a freshly published ROA is not enforced instantly across the internet. Recheck the RIPEstat lookup and your BGP Announcements tab after propagation, and confirm the two still agree.

What are the most common ROA mistakes?

Nearly every ROA-related outage traces back to one of these.

• Forgotten prefixes. You create ROAs for your main blocks and forget a smaller assignment or a secondary announcement. That prefix stays unknown, or worse, becomes invalid because a covering ROA excludes it. Cross-check the BGP Announcements tab against your ROA list and make sure every announced prefix is accounted for.

• Over-broad maxLength. Covered above. This is the one that turns your own security tool into an attack surface. Default to minimal.

• ROAs that do not match what you announce. You announce a /22 but wrote a ROA for the /24, or you changed origin AS during a migration and never updated the ROA. Result: invalid_asn or invalid_length, and validating networks drop your traffic. Every time your announcements change, your ROAs must change with them.

• Wrong origin AS. A typo in the AS number, or listing your upstream's AS instead of your own origin. The prefix goes invalid for its real origin.

• Ignoring the mismatch alert. RIPE warns you when a ROA contradicts observed BGP. Clicking through it is how a self-inflicted invalid reaches production.

• Set-and-forget. ROAs are not a one-time task. A prefix moved to a new AS, a new more-specific added for traffic engineering, a block returned or transferred: each needs the ROAs revisited. Treat ROA review as part of any routing change.

Do Via-Registry customers need to do any of this?

No. When we assign IPv6 space as a PA sub-assignment from our allocation, the RPKI ROA is created automatically at ASN assignment, matched to the origin AS and set minimal by default. Customers get validated, hijack-resistant routing with zero configuration on their side, which is the whole point of us being the LIR of record. If you also need Provider Independent IPv6 with your own RPKI footprint, we sponsor that too. For how ASN sponsorship pricing works around all of this, the ASN registration cost breakdown has the full picture.

For everyone running their own LIR: the steps above are the whole job. Enable hosted RPKI, mirror your real BGP announcements into minimal ROAs, watch the mismatch alerts, and verify with RIPEstat and Routinator. Do that, and a route hijack against your prefixes stops being something you hope never happens and becomes something the routing system rejects on your behalf.

Official References

• RFC 9319: The Use of maxLength in the Resource Public Key Infrastructure (RPKI) (BCP 185)
• RFC 9582: A Profile for Route Origin Authorizations (ROAs) (obsoletes RFC 6482)
• RIPE NCC: Resource Certification (RPKI)
• RIPE NCC: Using the RPKI System
• RIPEstat RPKI Validation data call
• Routinator documentation (NLnet Labs)

Facts checked July 2026.