Every few months we get the same ticket: a customer already holds their own IPv4 or IPv6 allocation — sometimes inherited from a legacy ASN, sometimes assigned directly by RIPE — and they're tired of renting IP space from whatever provider they're colocating with. They want to announce their own block from a network they can actually work with. This is a byoip hosting walkthrough written from the NOC side of that request: the paperwork RIPE and our routing team actually check, how the BGP session against AS60982 gets built, and which dedicated server tier makes sense to sit behind it.
What BYOIP Means on Our Network
Bring-your-own-IP is exactly what it sounds like: instead of taking IP space from our pool, you announce a prefix you already control through our autonomous system. We operate our own network under AS60982 — we are not reselling someone else's upstream allocation — which means we can accept your announcement, filter it properly, and carry it across our own peering rather than passing it through a third party's routing policy. That distinction matters more than it sounds: a reseller network often can't offer BGP sessions at all, because they don't control the AS the traffic actually rides on.
Full program details, minimum prefix sizes, and the request form live on our BYOIP page; this post is the step-by-step version for people who want to understand what happens before they click submit.
Do You Qualify? Minimum Prefix and RIR Status
Before we open a ticket, check the basics:
- You must be the registered resource holder (or an authorized subdelegate) in RIPE, ARIN, or the relevant RIR — not just a downstream lessee.
- Minimum announceable block is a /24 for IPv4 and a /48 for IPv6. Smaller fragments generally won't propagate cleanly through upstream filters regardless of whose network they're on.
- The prefix needs to be free of conflicting existing announcements — if another network is already originating it, that has to be withdrawn first.
If your block is smaller than a /24 and was never meant to be announced independently, BYOIP usually isn't the right fit — that's a case for standard allocated IPs instead, which is worth flagging before you start the RIR paperwork below.
The Paperwork: LOA, IRR, and RIPE Authorization
This is the part that trips people up, not the BGP config. A byoip setup guide that skips the compliance side isn't complete, so here's the sequence we actually walk customers through:
- Letter of Authorization (LOA) — a signed document confirming you authorize AS60982 to originate your prefix. We provide the template; it needs to be signed by whoever is listed as the resource holder in the RIR database, not just a technical contact.
- IRR route object — a route/route6 object registered in the appropriate Internet Routing Registry, listing AS60982 as an authorized origin for your prefix. Without this, many upstream networks will filter your announcement even after we accept it on our side.
- RIPE database updates — if your allocation is RIPE-managed, the maintainer object needs updating to reflect the new origin AS, and abuse-c/admin-c contacts should be current since RIPE and our own abuse desk will both reference them.
We handle the LOA and IRR coordination directly rather than leaving you to figure out RIPE's interface cold — that's part of what "BYOIP on our network" is supposed to mean in practice, not just a routing feature.
Setting Up the BGP Session on AS60982
Once paperwork clears, the technical side is a fairly standard eBGP session:
- We assign a point-to-point interconnect (or a session over an existing dedicated server's uplink, depending on your setup) and exchange the session parameters — our AS60982 side and your ASN.
- You configure your router to originate the prefix and establish the session; we apply inbound and outbound filters matching the IRR object registered in the step above, so the session only accepts what's actually authorized.
- Once the session is up and the route is being accepted, we verify propagation and confirm the prefix is visible from our upstreams and peers, not just locally on our network.
BGP is on request rather than self-service by default, since every session gets a manual filter review — that's a deliberate tradeoff between speed and not letting a misconfigured announcement leak somewhere it shouldn't. More on how our peering and transit setup is built on the network page.
Which Dedicated Server to Pair It With
A BYOIP announcement needs to sit on hardware that can actually carry the route and the traffic behind it — this isn't something we offer on VPS or game hosting products. It's a dedicated server play. Sizing depends mostly on what you're running behind the prefix (a small NAT/routing box versus a full multi-service platform), but here's the range:
| Tier | Spec | Starting Price | Port Speed |
|---|---|---|---|
| Entry | Dual Xeon E5-2630v4, 16c/32t, 128GB RAM | from EUR209/mo | 1–200 Gbps symmetric (tier-dependent) |
| Top-end | Dual EPYC 9754, 256c/512t, 1TB RAM | quote-based | up to 200 Gbps symmetric |
Every dedicated server ships with an included /29 IPv4 block regardless of BYOIP status — that stays yours for management interfaces and out-of-band access even after your own prefix is announced. Full specs and configurator are on the dedicated servers page.
RPKI, ROAs, and Keeping the Route Clean
We support RPKI and expect a valid ROA (Route Origin Authorization) for prefixes announced through AS60982. If you haven't created one yet, it's created against your resource holder account with your RIR and lists AS60982 as a valid origin — this is separate from the IRR route object and increasingly required by upstream networks doing RPKI validation. Getting this right before go-live avoids the awkward situation where your prefix is technically announced but gets dropped by validating peers anyway.
Common Mistakes We See
- LOA signed by the wrong contact. If the signer doesn't match the RIR-listed resource holder, the request stalls until it's re-signed.
- No IRR object, or one pointing at the old origin AS. The session comes up but the route doesn't propagate past the first hop.
- Announcing a fragment smaller than /24 or /48. Even if we accept it locally, expect spotty visibility upstream.
- Treating BYOIP as a VPS feature. It's a dedicated server / BGP-session product — size hardware accordingly before requesting the session.
How Noded Can Help
We built the BYOIP process the way we'd want to use it ourselves — we handle the LOA and IRR coordination directly instead of pointing you at a portal, we review every session's filters by hand before it goes live, and once your prefix is announced it gets the same free 1 Tbps DDoS protection (L3/4/7, detection in under 8 seconds) as every other range on our network, at no extra cost. Pair your announcement with one of our dedicated tiers, from the entry 16c/32t/128GB box up to dual EPYC 9754 configurations, all riding our own AS60982 across 13 EU points of presence, 15 IXs, and 34+ carrier interconnects. If you're ready to bring your own IP block over, start with the BYOIP request form and we'll walk the paperwork with you from there.
FAQ
What is the minimum IP block size for BYOIP?
A /24 for IPv4 and a /48 for IPv6. Smaller announcements are generally filtered by upstream networks regardless of which provider carries them.
Do I need my own ASN to bring my own IP range?
Yes — the BGP session is established between your ASN and our AS60982, and the LOA/IRR paperwork is filed against your ASN as the authorized announcer.
Can I run BYOIP on a VPS instead of a dedicated server?
No, BYOIP is offered on dedicated servers only. The BGP session and route filtering are set up at the network interconnect level, which isn't available on shared or virtualized products.
Is BGP available by default on every dedicated server?
BGP is available on request rather than enabled by default, since each session goes through a manual filter review tied to your LOA and IRR object before it's turned up.
Does RPKI affect whether my announced prefix is accepted?
We expect a valid ROA listing AS60982 as an authorized origin. Without one, some validating upstream peers may drop the route even though our own network accepts it.