How to Create RPKI ROAs at the RIPE NCC (Step by Step)

How do you create an RPKI ROA at the RIPE NCC? Sign in to the RIPE NCC RPKI dashboard (dashboard.rpki.ripe.net) with your RIPE NCC Access account and, on first use, choose the hosted certificate authority. On the BGP Announcements tab, select each route you originate and click Create ROA: the dashboard pairs the prefix with its origin AS and sets maxLength equal to the prefix length, as RFC 9319 recommends. ROAs are signed objects published in the RPKI repository, not RIPE Database objects (route and route6 objects are). Check the result in RIPEstat before you rely on it.

That is the happy path. The rest of this guide covers the maxLength decision and the checks that prove a new ROA works.

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 RPKI explainer covers route origin validation in depth). The ROA is the authoritative statement; without one, your prefixes stay in the unknown state and get no protection.

About two thirds of IPv4 route announcements (68.6%) and three quarters of IPv6 announcements (77.3%) were RPKI-valid on 1 August 2026 (NIST RPKI Monitor).

Per RFC 9582, the profile that defines the object (it obsoletes the earlier RFC 6482), a ROA names one origin AS and one or more prefixes, each with an optional maxLength. The RIPE NCC dashboard works one prefix per entry, in line with RFC 9455 (BCP 238), which recommends a single prefix per ROA. So each entry you create has three fields:

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.

What do you need before you can create a ROA?

Three prerequisites, in order:

1. You hold the prefix. A ROA is signed by the certificate authority that holds the prefix; the origin AS can belong to anyone. An LIR certifies its own allocations. A PI End User gets a separate End User CA, hosted or delegated, once it has a signed End User Assignment Agreement and a RIPE NCC Access account authorized to maintain its organisation object (RIPE NCC: certifying PI resources); otherwise the sponsoring LIR asks the RIPE NCC to set it up.
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, ASN registration through a sponsoring LIR costs €130 per year (as of September 2026), and our complete ASN registration guide covers the process.
3. Hosted RPKI is enabled. The 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 the RIPE NCC's servers, the cryptography is handled automatically, and, as the RIPE NCC 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?

• You are an LIR with your own allocation: you create ROAs yourself in the RIPE NCC RPKI dashboard.
• You hold PI space through a sponsoring LIR: the ROAs live in your End User CA. Whether you or your sponsoring LIR clicks the buttons depends on who maintains your organisation object in the RIPE Database. A change of sponsoring LIR keeps those ROAs in your own hosted CA; only sponsoring-org: changes.

If you lease a /48 from us as a PA sub-assignment, we create its ROA for you. The ROA names your ASN as origin and authorizes exactly the /48, so there is nothing to log into. It goes live with the block: at ASN assignment for a bundled order, or right after payment if you already hold an ASN. IPv6 PI is different: the block is registered to your organisation, so its ROAs live in your own End User hosted CA, never in ours. For the difference between the two, 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 dashboard.rpki.ripe.net and sign in with your RIPE NCC Access account.
2. The Resource Certification (RPKI) dashboard opens on your resources (RIPE NCC: using the hosted CA).
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. If you do run one, keep it publishing: since 8 June 2026 the RIPE NCC revokes a delegated CA after 90 days without a valid manifest and CRL (ripe-847).
4. Confirm. The 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 RIPE 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.

Since December 2025 the same dashboard also creates ASPA objects: an ASPA lists the upstream providers of your AS and helps networks reject route leaks (RIPE Labs, 15 December 2025). The profile is still an IETF draft and the dashboard does not suggest providers, so read what ASPA is before you sign one.

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 NCC 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 the routes you announce today.
2. For routes already visible in BGP, tick them and click Create ROA. The dashboard fills in the prefix and origin AS and sets maxLength equal to the prefix length. Several announcements can be handled in one operation.
3. For a prefix you do not announce yet, open the ROAs tab and add the entry by hand. Enter the exact block you will announce, with its real length, for example 2001:db8:1000::/36 or 203.0.113.0/24, not the parent allocation. Enter the origin AS that will originate it.
4. 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.
5. Read the confirmation pop-up. If the new ROA would turn one of your known announcements invalid, the dashboard asks you to confirm. Do not click past it without understanding why. It usually means a typo in the AS number, the prefix length or the maxLength.
6. Use Pending Changes when one prefix has several origins. Add all the ROAs to Pending Changes and apply them as one set, so no announcement goes invalid in between.
7. Save. The ROA is signed and published into the RPKI repository, where relying-party software worldwide picks 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; the announcements tab can create them in one operation.

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 left with a forged-origin prefix hijack: a route for your whole /24 with one AS hop more than yours, which competes with your announcement instead of overriding 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.
• Pre-provisioning for a DDoS mitigation service: create a ROA for each more-specific the provider may announce, with the provider's AS if it originates them, rather than widening maxLength on the covering prefix. RFC 9319 section 5.1 gives the two-ROA example.

How do you check the ROA actually works?

A published ROA can still be wrong. 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. Our free RPKI checker runs the same prefix-and-origin check from a form, without an API call.

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 that your ROA 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. The dashboard can also e-mail you, daily or weekly, about announcements of your space that are RPKI-invalid or not covered; turn that on under alert configuration.

What are the most common ROA mistakes?

These are the mistakes that turn a correct announcement invalid.

• 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 confirmation pop-up. The dashboard warns you when a new ROA would invalidate an announcement it sees. 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. A transfer, or a change of the holder's organisation, replaces the certificate and removes the ROAs under it, which must be recreated (RIPE NCC: using the RPKI system). A ROA does not replace the route or route6 object your upstreams filter on; see what a route object is.

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

It depends on the block. For a /48 leased from us as PA space, we create and maintain the ROA: origin set to your ASN, exactly the /48, nothing for you to configure. Our daily ASN health checks flag any of your blocks announced without a ROA. If we manage your ASN, you also publish its ASPA from the Via-Registry dashboard, without opening the RIPE NCC portal. For IPv6 PI we sponsor (€435 the first year, then €135 per year, as of September 2026), you create the ROAs in your own End User hosted CA once your maintainer is on the inet6num; the steps above apply unchanged. The same goes for any prefix you announce that we did not assign. For how ASN sponsorship pricing works around all of this, the ASN registration cost breakdown has the full picture.

If you run your own LIR, the routine is short. Mirror your real BGP announcements into minimal ROAs, read the confirmation pop-up before you save, and check each new ROA in RIPEstat. Networks that filter RPKI-invalid routes will then drop sub-prefix hijacks of your space: APNIC measured 26.92% of users behind such filtering on 29 July 2026 (APNIC Blog).

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)
• RIPE NCC: Using the Hosted Certification Authority
• RIPE NCC: Certifying PI Resources
• RFC 9455: Avoiding ROAs Containing Multiple IP Prefixes (BCP 238)