The /24 plus ASN package: when a ready-to-route setup makes sense

A /24 on its own is a set of addresses; a /24 with an ASN, registry objects and RPKI in place is something you can announce to the internet with BGP. Ready-to-route packages bundle these pieces together. This article explains what such a package should include, when it makes sense, when it doesn’t, and what to check before you commit.

What “ready to route” actually means

Announcing a prefix yourself takes more than the addresses. A complete package covers:

• An ASN, registered in the RIPE Database with an aut-num object and correct contacts.
• A /24 IPv4 block, the smallest prefix widely accepted in the global routing table.
• A route object in the IRR linking the prefix to your ASN. Many upstreams build their prefix filters from this data.
• A ROA in RPKI authorising your ASN to originate the prefix, so networks that perform route origin validation treat your announcement as valid.
• Reverse DNS delegation, so you can manage your own PTR records.
• An LOA your upstreams can rely on when they check that you’re authorised to announce the block.
• An abuse contact registered against the range.

Some packages also include IPv6 space, which can be announced from the same ASN. When everything is in place before your first BGP session, turning up transit becomes a configuration task rather than a registry project.

When a package makes sense

A ready-to-route setup suits operators who want control over their own routing:

• Multihoming. If you want two or more upstreams for resilience, you need your own ASN and a prefix announced through both.
• Provider independence. Addresses you announce yourself move with you when you change transit provider or data centre, so your customers don’t have to renumber.
• Peering. Connecting to an internet exchange and peering with other networks generally requires your own ASN.
• Launching a hosting or ISP business. A package takes you from nothing to announcing in one step, instead of assembling the pieces from different parties and coordinating between them.

In each case, the value lies in the combination. An ASN without addresses has nothing to announce, and addresses without an ASN rely on someone else’s network to reach the internet.

When it doesn’t

A package isn’t always the right answer.

• Single-homed with no plans to change. If you have one upstream and are happy with it, addresses from that provider may be simpler.
• No BGP experience available. Running your own routing means maintaining sessions, filters and monitoring. Without that skill, you need to build it, buy it in, or wait.
• Cloud-only workloads. If everything runs in a public cloud, bringing a /24 alone may be enough. AWS BYOIP, for example, needs a /24 minimum and a ROA for Amazon’s ASNs, so your own ASN isn’t required for that route.

Bear in mind that RIPE NCC policy expects an ASN to serve a genuine routing need, such as multihoming. Check the current policy for the exact criteria before applying.

Leased, assigned or owned: know which you’re getting

“Package” can describe quite different arrangements, and the difference matters most when you leave.

• ASN assigned to you through a sponsoring LIR. You are the end user of record. If you change sponsoring LIR, the ASN can generally move with you under RIPE NCC procedures.
• ASN leased. The provider remains the holder and lets you use it; it goes back at the end of the contract.
• Leased /24. The block returns to the lessor at the end of the term, so plan for renumbering or renewal.
• Purchased /24. The block is yours to keep, subject to registry membership requirements.

Ask the provider to state in writing which model applies to each resource, and what happens to the ASN, the prefix and the RPKI objects when the contract ends.

What to check before you sign

1. The /24 is clean: no current blacklist listings and no suspicious routing history.
2. The ASN’s history, if it isn’t newly assigned: previous holders, past announcements and any links to abuse or sanctioned parties.
3. Registry responsibilities: who creates and maintains the route object, ROA and rDNS, and how quickly changes are made.
4. LOA scope: whether it names the upstreams you plan to use, and when it expires.
5. Geolocation: that the block geolocates to where you serve customers, or that the provider will correct it.
6. Room to grow: whether you can add another /24 later, ideally an adjacent, aligned one that aggregates into a /23.
7. Exit terms for each resource, including notice periods and handover of objects.

Upstreams typically check your IRR and RPKI data before accepting your routes, so getting these right on day one shortens turn-up. Ask the provider to show you the objects before your first session, and confirm in a looking glass that the announcement is seen as RPKI-valid once it is live.

How TACS can help

As a RIPE NCC member, we can register or lease the ASN, supply the /24 through Lease IPv4 and prepare every registry object so your first BGP session is simply configuration. If you would rather keep an existing ASN with a new sponsor, our LIR services cover sponsorship and transfers.