Announce Leased IPv4: LOA, Route Object and ROA Checklist

BGP RPKI IPv4

To announce leased IPv4 from your own ASN in the RIPE region, three records have to agree: a signed letter of authorisation (LOA) from the address holder, a route object in the RIPE Database with your ASN as origin, and a ROA (route origin authorisation) for your ASN whose maximum length equals the length of the prefix you announce. The holder creates the route object and the ROA, because both hang off its registry account, and your ASN does not have to approve anything: the RIPE Database stopped asking the ASN holder in September 2018.

Get all three right and upstream filters have what they need to let the prefix through. Our network, AS213900, announces three leased /24s this way, and every check below ran against them in October 2026. For the BGP session itself, our IP transit in Skopje and Amsterdam accepts leased space when the route object and ROA name your ASN.

Key facts, checked on 17 October 2026:

The RIPE Database authorises a new route object through the address space's maintainer: "You do not need to authenticate against the origin AS Number" (RIPE Database docs). The rule took effect on 4 September 2018, according to a RIPE NCC reply under the RIPE Labs announcement of 9 May 2018.
The RIPE NCC's RPKI dashboard sets a ROA's maximum length to the prefix length by default and says "the use of the Maximum Length field is discouraged" (RIPE NCC). RFC 9319 (BCP 185, October 2022) says operators SHOULD avoid it.
Hurricane Electric's filter rejects RPKI-invalid routes and accepts IPv4 prefixes only from /8 to /24, IPv6 from /16 to /48 (HE filtering algorithm).
ROAs covered 77% of IPv4 and 45% of IPv6 address space in the RIPE NCC's statistics of 6 October 2026 (Member Update).
A RIPE Labs study of DE-CIX and AMS-IX traffic (1 September 2026) finds that ROAs can largely replace third-party route objects, while third-party AS-SETs "remain essential for BGP filter generation" (RIPE Labs).

How to announce leased IPv4: the order that works

Seven steps, in the order that keeps the prefix from being dropped on day one:

Check the block before you sign: its RIPE Database entry, its routing history and leftover route objects.
Get an LOA from the holder the RIPE Database shows, naming the prefix, your ASN and the lease dates.
Have the holder create a route object with your ASN as origin:, or delegate mnt-routes to your maintainer.
Have the holder's LIR create a ROA for your ASN with a maximum length equal to the prefix length, and delete ROAs left by earlier tenants.
Make sure your as-set or PeeringDB entry leads to your ASN, and that bgpq4 lists the prefix.
Send the LOA to your upstream, wait for its filters to rebuild, then bring up the session and check visibility.
When the lease ends, withdraw the prefix and ask the holder to delete the route object and ROA.

LOA vs route object vs ROA: who creates each record

Most failed announcements of leased space come down to who was supposed to create which record. Three terms first:

An IRR (Internet Routing Registry) is a public database of which ASN may originate which prefix. The RIPE Database is one, and a route object is one entry in it.
RPKI is the signed version of that claim. A ROA is one signed record: a prefix, an ASN and a maximum length.
Route origin validation (ROV) checks every route against the ROAs and marks it valid, invalid or not found. Most large networks drop the invalid ones.

Record	What it says	Who creates it	Where it lives	Who reads it
LOA	The holder lets a named company originate the prefix from an ASN until a date	The address holder	A signed PDF, in no registry	Your upstream's staff, once
Assignment (inetnum)	Who the block is registered to	The holder	RIPE Database	Anyone running whois
Route object	This ASN may originate this prefix	The holder, or you if it adds your maintainer to `mnt-routes`	RIPE Database (IRR)	Upstream filter scripts such as bgpq4
ROA	The same, signed, up to a maximum length	The holder's LIR	RIPE NCC RPKI repository	Every validating network
aut-num, as-set, PeeringDB entry	Your ASN, its customers and its policy	You, or the LIR sponsoring your ASN	RIPE Database, PeeringDB	Upstreams building filters

No ASN yet? Start with our guide to getting your own ASN and IP addresses. For what a /24 costs to lease, see our guide to IPv4 prices in 2026.

Before you sign: check the block's registry entry and routing history

Every check here uses free public data. We ran them read-only in October 2026, in a Debian 13 container limited to 1 GiB of RAM on our Amsterdam test server. Install the tools:

# as root
apt update
apt install -y whois curl jq bgpq4

Then read the assignment. This is one of our leased blocks:

# as a normal user
whois -h whois.ripe.net -r -T inetnum 217.60.194.0/24

What we saw, trimmed:

inetnum:        217.60.194.0 - 217.60.194.255
netname:        RS_Computers
country:        AL
status:         ASSIGNED PA
created:        2026-05-18T11:50:46Z
mnt-by:         lir-ae-goldip-1-MNT
mnt-by:         GOLD-MNT

ASSIGNED PA means another RIPE NCC member assigned this /24 out of its own allocation and registered our name on it. Both maintainers are the holder's, and its remarks say it administers only the addresses while the customer runs BGP and transit.

Add -L to see the covering 217.60.0.0/16, ALLOCATED PA to the holder's LIR. That LIR signs your LOA and creates your ROA. The -r flag hides personal contact data.

Next, who announced this /24 before you? RIPEstat keeps the routing history:

# as a normal user
curl -s "https://stat.ripe.net/data/routing-history/data.json?resource=217.60.194.0/24&min_peers=10" | jq -r '.data.by_origin[] | select(.origin != "213900") | .origin as $o | .prefixes[] | select(.prefix == "217.60.194.0/24") | "AS\($o) \(.timelines[0].starttime[:10]) to \(.timelines[-1].endtime[:10])"'

AS18811 2025-04-18 to 2025-07-22
AS31549 2024-11-13 to 2025-01-11
AS215228 2026-05-19 to 2026-06-23
AS398704 2025-07-11 to 2025-08-03

Four other networks originated it between November 2024 and June 2026. That is normal for leased space. What matters is that earlier tenants left no ROA, route object or blocklist entry behind. Our IPv4 price guide has a command for the Spamhaus DROP list. For other registries, IRR Explorer from NLNOG compares every IRR with BGP and RPKI:

# as a normal user
curl -s https://irrexplorer.nlnog.net/api/prefixes/prefix/217.60.194.0/24 | jq -r '.[] | "\(.prefix) \(.categoryOverall): \(.messages | map(.text) | join("; "))"'

217.60.194.0/24 success: Everything looks good
217.60.0.0/16 warning: Expected route object in RIPE, but only found in other IRRs; Route objects exist, but prefix not seen in DFZ; No (covering) RPKI ROA found for route objects

Our /24 is clean. The warning concerns a RADB route object for the whole /16, created in 2016 for another network's ASN. It does not block our route, but raise leftovers like this before you sign, because only the holder can get them removed.

What an LOA for leased IPv4 must say, and who signs it

An LOA is a signed letter in which the address holder lets a named company originate a named prefix from a named ASN. It is not a RIPE NCC document; upstreams and exchanges ask for it.

It must come from the holder the RIPE Database shows: the LIR holding the allocation for PA space, or the end user for PI space. A broker or leasing platform can sign only if it is that holder or attaches the holder's written mandate. A template, with documentation numbers:

# LOA template, on the holder's letterhead, signed by the holder
Date: 2026-10-01
To: [upstream name and ASN, or "to whom it may concern"]

[Holder legal name], holder of 203.0.113.0/24 in the RIPE Database
(organisation ORG-EXAMPLE1-RIPE), authorises [lessee legal name]
to originate 203.0.113.0/24 from AS64500.
More specific prefixes: none.
Valid from 2026-10-01 until 2027-09-30, or until withdrawn in writing.
The holder maintains a route object and a ROA for AS64500 for this period.

Name, title, signature
Verification contact: [address that also appears in the RIPE Database]

Match the end date to your lease and list any more specifics you plan to announce, since the ROA must match them. Careful upstreams confirm the letter through a contact they find in the RIPE Database.

Some providers originate customer space from their own ASN instead. Leaseweb's knowledge base asks for a ROA authorising Leaseweb's ASNs and a route object with mnt-routes delegated to Leaseweb, and accepts only compliant prefixes from September 2026. This article covers the other model, where your ASN is the origin.

Route object for leased IPv4: does your ASN have to approve it?

No. A RIPE route object has four mandatory lines: route: (the prefix), origin: (your ASN), mnt-by: and source: RIPE. Ours, as an exact match:

# as a normal user
whois -h whois.ripe.net -r -x -T route 217.60.194.0/24

route:          217.60.194.0/24
origin:         AS213900
descr:          RS Computers
created:        2026-06-27T12:21:43Z
source:         RIPE
mnt-by:         lir-ae-goldip-1-MNT
mnt-by:         GOLD-MNT

Both maintainers belong to the holder, which is typical for leased space. Since September 2018 the RIPE Database authorises a new route object like this:

It finds an existing route object for the same or a less specific prefix, or else the inetnum.
It asks that object's mnt-routes maintainer, or failing that mnt-lower, then mnt-by.
The new object's own mnt-by must agree too.
The ASN holder is not asked. It only gets an email if its aut-num has a notify: address.

Guides that say both sides must authorise describe the rules before September 2018. The contrast shows when you list everything that names our ASN:

# as a normal user
whois -h whois.ripe.net -r -i origin -T route,route6 AS213900 | grep -E '^(route6?|mnt-by):'

Three IPv4 route objects carry the holder's GOLD-MNT; five IPv6 route6 objects carry our own LIR's lir-al-rscomputers-1-MNT. For our own IPv6 we create everything; for leased IPv4 we depend on the holder. To fix route objects without waiting, ask the holder to add your maintainer as mnt-routes on your assignment.

One trap: always check with -x. Without it, a query for 217.60.194.0/25 quietly returns the /24 object, as if a more specific were registered. With -x it returns %ERROR:101: no entries found.

How to get a ROA for a leased IP block

You cannot create it yourself. The RIPE NCC's hosted RPKI opens from a RIPE NCC Access account linked to an LIR, and the certificate for PA space belongs to the LIR holding the allocation, so the holder's LIR creates your ROA. PI end users can request a hosted or delegated certification authority of their own, or go through their sponsoring LIR.

Per the RIPE NCC's documentation, the holder opens "BGP Announcements and ROAs", creates the ROA from a seen announcement or by hand, and applies it at once or batches several under pending changes. We have not seen these screens ourselves; they need the holder's login.

Ask for a ROA with your ASN, your prefix and a maximum length equal to the prefix length. Then check from outside with RIPEstat:

# as a normal user
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS213900&prefix=217.60.194.0/24" | jq -r '"\(.data.resource) \(.data.prefix) \(.data.status)"'
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS64500&prefix=217.60.194.0/24" | jq -r '"\(.data.resource) \(.data.prefix) \(.data.status)"'

213900 217.60.194.0/24 valid
64500 217.60.194.0/24 invalid_asn

invalid_asn is what you see while the ROA names someone else, and ROV networks drop that route.

When a prefix carries several ROAs

A route is valid if any one ROA matches it, so every ROA is a permission. Our leased 31.57.56.0/24 has three:

# as a normal user
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS213900&prefix=31.57.56.0/24" | jq -r '.data.validating_roas[] | "AS\(.origin) \(.prefix) maxLength \(.max_length) -> \(.validity)"'

AS213900 31.57.56.0/24 maxLength 24 -> valid
AS210464 31.57.56.0/24 maxLength 24 -> invalid_asn
AS834 31.57.56.0/22 maxLength 24 -> invalid_asn

Ours is valid. invalid_asn on the other two only means they do not match our origin; each of those ASNs may also originate this /24 validly. Ask the holder about any you cannot explain. The third line shows the most common ROA mistake.

ROA maxLength explained: one /22 or four /24s

maxLength is the longest prefix a ROA allows. A ROA for a /22 with maxLength 24 covers the /22, its two /23s and its four /24s; with maxLength 22 it covers the /22 alone.

Two mistakes follow from that. If the holder leaves the default maxLength 22 and you announce four /24s, all four are invalid_length and vanish from networks that drop invalid routes. If the ROA allows /24s while only the /22 is announced, anyone can announce a /24 with a forged path ending in your ASN and pass validation. RFC 9319 calls this a forged-origin sub-prefix hijack and asks for "minimal ROAs" that cover only what is announced.

ROA from the holder	You announce	Result
/22, maxLength 22	The /22	Valid, correct
/22, maxLength 22	Four /24s	All four invalid_length, dropped
/22, maxLength 24	Only the /22	Valid, but every /23 and /24 inside is open to a forged-origin hijack
/22 plus four /24 ROAs, each maxLength equal to its length	The /22 and four /24s	All valid, correct and tight
/24, maxLength 24	A /25 out of it	invalid_length, and most networks drop IPv4 longer than /24 anyway

The AS834 ROA above is the loose kind: it covers 31.57.56.0/22 up to /24. In October 2026 the /22 was not announced, and its four /24s came from four different networks, ours among them and AS834 not. So:

# as a normal user
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS213900&prefix=217.60.194.0/25" | jq -r .data.status
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS834&prefix=31.57.57.0/24" | jq -r .data.status

The first prints invalid_length, because our ROA stops at /24. The second prints valid, although another network was announcing 31.57.57.0/24 at the time.

RFC 9319 names one common case where a wider ROA is hard to avoid: a DDoS scrubbing service that announces your prefix only during an attack, so its ROA has to exist in advance. Our guide to remote DDoS protection over a GRE tunnel covers that setup.

How upstreams filter a leased prefix, and why a ROA alone is not enough

A transit provider does not trust your router. It expands your as-set, a named IRR list of your ASN and your customers' ASNs, into a prefix list and loads it on your session. Anything missing is dropped, even with a perfect ROA. Build the same list with bgpq4:

# as a normal user
bgpq4 -4 -S RIPE -l AS213900-IN AS213900

no ip prefix-list AS213900-IN
ip prefix-list AS213900-IN permit 31.57.56.0/24
ip prefix-list AS213900-IN permit 217.60.96.0/24
ip prefix-list AS213900-IN permit 217.60.194.0/24

That is Cisco syntax; -b prints BIRD and -J Juniper. If your leased prefix is missing here, it is missing on your upstream's filter too.

Which as-set gets expanded? Hurricane Electric's algorithm looks first in your PeeringDB record, then in your aut-num's export lines towards AS6939 or ANY, then in HE's own NOC lists, and otherwise uses your ASN alone. It accepts a prefix that matches your IRR policy, or one that is RPKI-valid with your own ASN as the origin. Not every upstream accepts a ROA alone, so keep route objects for every prefix. Check your PeeringDB entry:

# as a normal user
curl -s "https://www.peeringdb.com/api/net?asn=213900" | jq -r '.data[0].irr_as_set'

Ours prints AS213900:AS-DOWNSTREAMS. Filters are rebuilt on a schedule, so ask your upstream how long a new route object takes to reach your session. See our comparison of Hurricane Electric and Cogent as upstreams, and for a router far from the upstream, our guide to BGP over GRE, WireGuard, IPsec or VXLAN tunnels.

On our IP transit, a leased prefix is accepted when its route object and ROA match your ASN, so these are the same checks you need to pass with us.

How to check that a leased prefix is announced correctly

Is the prefix visible worldwide? RIPEstat counts the RIPE NCC route collector (RIS) peers that see it:

# as a normal user
curl -s "https://stat.ripe.net/data/routing-status/data.json?resource=217.60.194.0/24" | jq -r '.data | "origin AS\(.origins[0].origin), seen by \(.visibility.v4.ris_peers_seeing) of \(.visibility.v4.total_ris_peers) RIS peers"'

We saw origin AS213900, seen by 327 of 328 RIS peers. Partial visibility usually means an upstream has not rebuilt its filter yet. bgp.tools answers whois queries too:

# as a normal user; the space before -v matters
whois -h bgp.tools " -v 217.60.194.1"

AS      | IP               | BGP Prefix          | CC | Registry | Allocated  | AS Name
213900  | 217.60.194.1     | 217.60.194.0/24     | AL | RIPE     | 2026-05-18 | RS Computers L.L.C

Your own validator: rpki-client in 1 GiB

rpki-client is OpenBSD's RPKI validator, packaged in Debian 13 as version 9.5. We limited it to the RIPE NCC's trust anchor:

# as root; results go to /var/lib/rpki-client/json
apt install -y rpki-client
systemctl stop rpki-client.timer
rpki-client -t /etc/tals/ripe.tal -j
jq -r '.roas[] | select(.prefix == "217.60.194.0/24") | "\(.prefix) maxLength \(.maxLength) AS\(.asn) ta \(.ta)"' /var/lib/rpki-client/json

The run took 175 seconds and validated 63,696 ROAs, 368,719 unique VRPs (checked prefix, maximum length and ASN combinations) and 2,159 ASPA objects. The largest process used 364 MiB. The last command printed 217.60.194.0/24 maxLength 24 AS213900 ta ripe.

Why stop the timer? The package enables a systemd timer that runs rpki-client two minutes after boot and 15 minutes after each run, so on a machine that has been up a while, a full run with all five regional trust anchors starts right after the install. In our 1 GiB container that run was killed by the out-of-memory killer after three minutes, at a peak of 1,007 MiB.

Where to announce it: transit PoP, plan and city by situation

RS Computers (AS213900) is a RIPE NCC member (LIR) and sponsors ASNs for clients directly. Transit is flat rate and unmetered at 1, 5 or 10 Gbit/s, month to month, with the BGP session free, by cross-connect or over a GRE, IPsec, WireGuard, VXLAN, L2TPv3, EoIP, OpenVPN or IPIP tunnel. Upstreams include Hurricane Electric and GSL, which provides DDoS-protected transit.

Your situation	What to take	City	Why
Network in Kosovo, North Macedonia or Albania	IP transit in Skopje	Skopje, Neocom DC	A 100G port on IXP.mk with open peering; Prishtina to Skopje is about 3 ms on our own network
Users mostly in Western Europe	IP transit in Amsterdam	Amsterdam, Qupra DC	Hand-off at Nikhef
No ASN yet	An ASN sponsored from our LIR, plus a transit port	Skopje or Amsterdam	One party for the ASN request, the route object and ROA check, and the session
Routers in another data centre	A transit port over a tunnel	Skopje or Amsterdam, whichever is closer to your routers	No cross-connect needed
A small box for these checks	VPS Nano: 1 shared vCPU, 1 GB RAM, 20 GB NVMe, 1 Gb/s	Amsterdam, Dublin or Prishtina	Every check above, including RIPE-only rpki-client, ran in 1 GiB; our lab had 2 cores, so expect a slower validator run on one
Your own validator for all five trust anchors	VPS Mini (4 shared vCPU, 4 GB, 80 GB NVMe, 1 Gb/s) or VDS Small (4 dedicated vCPU, 8 GB, 240 GB NVMe, 10 Gb/s)	Amsterdam, Dublin or Prishtina	The full run failed at 1 GiB; we did not test larger sizes, so watch memory on the first run

Leased IPv4 pairs well with IPv6 in your own name, where you create every object yourself; see our guide to using a /48 of IPv6. Availability by city is on the plans page.

Frequently asked questions

Who signs the LOA for leased IPv4?

The holder the RIPE Database shows: the LIR holding the allocation for PA space, or the end user for PI space. A broker can sign only if it is the holder or attaches the holder's mandate. The letter names the prefix, the lessee, the origin ASN and the dates.

Do I need both a route object and a ROA to announce leased IPv4?

Yes, in practice. Upstreams build prefix filters from IRR route objects, and most large networks drop RPKI-invalid routes. Hurricane Electric accepts an RPKI-valid route originated by your own ASN even without an IRR match, but not every upstream does, so keep both.

Does the ASN holder have to approve a route object in the RIPE Database?

No. Since September 2018 the RIPE Database checks only the address space maintainer (mnt-routes, then mnt-lower, then mnt-by) and the new object's own maintainer. The ASN holder is emailed only if its aut-num has a notify address.

What maxLength should a ROA for a leased /24 have?

24, the same as the prefix length. That is the RIPE NCC dashboard's default and what RFC 9319 recommends. A /24 is also the longest IPv4 prefix Hurricane Electric's filter accepts, and most networks drop anything longer.

Can I announce leased IPv4 without my own ASN?

Only through someone else's ASN. Some providers, Leaseweb among them, originate customer space from their own ASN, and the holder's ROA and route object then name that ASN. To be the origin yourself you need an ASN, which an LIR such as RS Computers can sponsor.

Why does my leased prefix show as RPKI invalid?

Usually the ROA still names the holder's or an earlier tenant's ASN (invalid_asn), or you announce a longer prefix than its maxLength allows (invalid_length). The holder fixes either one in its RPKI dashboard, or you announce only what the ROA allows; check with RIPEstat before the session starts.

Send us the prefix before the session

An LOA from the real holder, a route object with your ASN and a ROA with an exact maximum length: fix what the commands above show, then bring the block to a network that checks them too. Start at our IP transit page for Skopje and Amsterdam, or send us the prefix and your ASN on Telegram and we will go through the route object and ROA with you before the session goes up.

← All articles