BYOIP Paperwork: LOA, ROA and Route Objects in the RIPE Database

Bringing your own IPv4 /24 to a new network is rarely held up by BGP. It stalls on three documents: the LOA, the RPKI ROA and the route object in the RIPE Database. Each has to name the right origin AS, come from the right party and agree with the other two. Get one wrong and the prefix is dropped further along the path, or never announced at all.

This post covers that BYOIP paperwork step by step for a /24 held at RIPE, with a note on ARIN: which origin AS goes where, what a usable Letter of Authorization contains, how to create the ROA and route object, how to check it all before you order, and why a /24 fails to propagate. The product side is on our BYOIP and BGP page.

First decide the origin AS

Every object below names an origin AS: the AS at the end of the AS path. On a Noded dedicated server there are two order options, both at no extra charge, and they put different numbers in the paperwork. Examples use documentation prefix 203.0.113.0/24 and ASN 64500 for "your ASN".

Order option	Who originates the /24	Origin AS in ROA and route object	Own ASN needed
Own /24 subnet	We announce it from AS60982	AS60982	No
Own ASN + /24 subnet	You, over a BGP session with AS60982	AS64500 (yours)	Yes

In the second case AS60982 is your upstream, not your origin, so do not add a ROA for it. Mixing the two up is the classic stall: a ROA for your ASN when we originate, or a route object for AS60982 when you do.

The LOA: a letter of authorization for the IP prefix

The LOA is not a RIPE Database object. It is a signed letter from the resource holder to the network that will carry the prefix, and we ask for one. A usable one has:

• The holder's legal name, exactly as in the org: object the inetnum references.
• The prefix in CIDR notation, for example 203.0.113.0/24.
• What is authorised. Own /24 subnet: AS60982 may originate the prefix. Own ASN + /24: AS64500 originates it and AS60982 may accept and propagate it as upstream.
• A signatory who can bind the holder: name, role, signature. For a leased /24 that is the lessor, not you.
• Date and validity: date signed, plus an end date or "valid until revoked in writing".
• A contact who can confirm the letter, ideally one listed for the holder in the database.

Creating the RPKI ROA at RIPE NCC

For RIPE space the simplest route is the RIPE NCC hosted RPKI, via the Resource Certification (RPKI) dashboard at dashboard.rpki.ripe.net, using a RIPE NCC Access account linked to the LIR. PI and legacy holders need the matching end-user or legacy agreement in place; otherwise their sponsoring LIR requests the certificate. The RIPE NCC ROA management guide shows the screens.

1. If there is no certification authority yet, create one and choose Hosted.
2. Use the ROAs tab: the announcements tab only covers routes RIPE RIS already sees.
3. Enter origin AS (AS60982 or AS64500), prefix (203.0.113.0/24) and maximum length (24). The origin AS does not have to be one you hold.
4. Apply it, or batch it in Pending Changes. Read the warning about announcements that would become invalid before confirming.

Set max length to 24

Max length is the most specific announcement the ROA still treats as valid. Keep it equal to the prefix length. A /24 ROA with max length 25 or more also approves /25s you never announce, and anyone can announce one with your authorised origin forged at the end of the path: RPKI calls it valid and the more specific route wins. RFC 9319 names this a forged-origin sub-prefix hijack and says operators should generally avoid max length; the RIPE NCC discourages the field too.

Existing ROAs decide whether you are invalid

Route origin validation has three outcomes. Valid: a covering ROA matches the origin and allows the length. Invalid: at least one ROA covers the prefix but none matches. NotFound: no ROA covers it. The trap is the middle one. If the /24 or a covering /22 already has a ROA for your old provider's AS, or an AS0 ROA, the new announcement is invalid until you add a ROA for the new origin, and networks that drop invalids will not carry it. Any matching ROA makes a route valid, so add the new one first and delete the old one after the old announcement is withdrawn. Our RPKI explainer covers the router side.

The IRR route object in the RIPE Database

Many networks build prefix filters from the IRR and look for a route object whose origin: matches the announcement. We ask for a valid ROA or a route object; doing both covers networks that check either. Mandatory attributes are route:, origin:, mnt-by: and source:.

route:    203.0.113.0/24
descr:    Example Ltd, announced via AS60982
origin:   AS60982
mnt-by:   EXAMPLE-MNT
source:   RIPE

For Own ASN + /24, use origin: AS64500.

Who has to authorise it

This rule changed, and older guides still describe the old one. Per the RIPE Database documentation:

• The origin AS holder no longer authorises. Any AS outside reserved space is accepted, even one not in the RIPE Database. Its holder is only notified, if the aut-num has a notify: attribute.
• The address space does. The database uses the first object it finds: an exact-match route object, then a less specific one, then an exact-match inetnum, then a less specific inetnum.
• On that object, mnt-routes: wins, then mnt-lower:, then mnt-by:.
• The new object's own mnt-by: must authorise as well.

So if an old route object exists for the /24 or a covering block, its maintainer is the gatekeeper. If the space is leased or sits in an LIR's allocation, the LIR usually controls those maintainers: they create the object or add yours to mnt-routes:. Our IPv4 leasing guide covers who holds what there.

ARIN and other non-RIPE space

The RIPE Database will not take a route object for a prefix the RIPE NCC does not manage. For ARIN space, in ARIN Online go to Routing Security, Manage RPKI, Create ROA; the resources must be covered by an ARIN agreement. ARIN then offers to create a matching route object in its own IRR, using the prefix only and ignoring max length. See the ARIN hosted RPKI page.

Check it before you order

Check all of it before you order, not on go-live day.

# Route objects for the /24 and anything covering it
whois -h whois.ripe.net -r -L -T route 203.0.113.0/24

# Who may authorise route objects (mnt-routes, mnt-lower, mnt-by)
whois -h whois.ripe.net -r -T inetnum 203.0.113.0/24

# Every route object naming your ASN as origin
whois -h whois.ripe.net -r -T route -i origin AS64500

The Linux whois client passes these flags through. On macOS, quote the query after a double dash: whois -h whois.ripe.net -- '-r -L -T route 203.0.113.0/24'. For RPKI, RIPEstat needs nothing installed:

curl -s 'https://stat.ripe.net/data/rpki-validation/data.json?resource=AS60982&prefix=203.0.113.0/24'

Its status is valid, invalid_asn (a covering ROA names another origin), invalid_length (longer than max length allows) or unknown (no ROA, the NotFound state). With NLnet Labs' Routinator you can ask your own validator; add --json to see the reason for an invalid, as or length:

routinator validate --asn 60982 --prefix 203.0.113.0/24

Validators pick up new ROAs on their own refresh cycle, so publish early and check again before go-live.

Why a /24 does not propagate

• The ROA names the wrong origin. Your ASN when we originate, or AS60982 when you do: invalid_asn.
• Max length is wrong. Too short on a covering ROA, typically an LIR's /22 at max length 22, makes your /24 invalid_length. Too long does not block propagation but leaves the sub-prefix hijack open.
• The only route object names the old origin. IRR-built filters for the new origin will not include your /24. Create the new object; delete the stale one after cutover.
• The LOA signer does not match the holder. A letter from the lessee or a technical contact stalls at any provider.
• The prefix is still announced elsewhere. Two origins compete and some traffic still lands there. Agree the cutover with the old network first.
• The block is smaller than a /24. We take a /24, and most networks filter IPv4 announcements longer than /24 anyway.

What this is not

BYOIP with us is IPv4 only and the block is a /24; IPv6 BYOIP is not offered. It is a dedicated server option: a VPS gets one free IPv4 and extra IPv4 at checkout, but cannot announce your space. Without a block of your own, a dedicated server includes one usable IPv4 (a /31), with /29, /28 and /27 subnets as add-ons.

AS60982 buys IP transit from a single upstream carrier today (see the network page). For more than one path, announce the /24 here alongside your other providers; Own ASN + /24 is cleaner for that, because your ASN stays the origin everywhere. The multi-homing guide covers the trade-offs. None of this is legal advice; your RIR's rules and any lease decide what you may authorise.

How Noded Can Help

Pick "Own /24 subnet" or "Own ASN + /24 subnet" when you configure a dedicated server; neither costs extra. Have the signed LOA ready, publish the ROA (ideally the route object too) with the origin from the table at the top, and rerun the RIPEstat check until it says valid. For Own ASN + /24, session details are agreed with you when the session is set up.

Both options are side by side on the BYOIP page. Unsure which origin to name? Ask us before anything is signed.

FAQ

Do I need my own ASN for BYOIP?

No. With Own /24 subnet we announce your /24 from AS60982, so the ROA and route object name AS60982. You need an ASN only for Own ASN + /24, where you run the BGP session.

What should a letter of authorization for an IP prefix include?

The holder's legal name as in the RIPE Database, the prefix, which AS may originate or carry it, a signatory who can bind the holder, date, validity and a contact. For leased space, the lessor signs.

What max length should a ROA for BYOIP have?

The prefix length: 24 for a /24. Anything longer authorises more specifics you do not announce, which RFC 9319 identifies as a hijack risk.

Do I need both a ROA and an IRR route object?

We ask for a valid ROA or a route object authorising the origin AS. Both is better, because some networks filter on IRR data and others drop RPKI-invalid routes.

Can I bring an IPv6 prefix or use BYOIP on a VPS?

No to both. BYOIP is IPv4 /24 only, on dedicated servers.