Make IP Space Portable With BYOIP, BGP And RPKI

The global border gateway protocol routing table now carries roughly 950,000–1,000,000 IPv4 prefixes, adding more than 50,000 new entries in 2024 alone.

In parallel, over half of all routes are now covered by RPKI Route Origin Authorisations (ROAs), and an estimated 74% of traffic flows toward prefixes protected by RPKI.

That scale and shift toward cryptographic validation are changing how serious operators think about address space. Public cloud egress still commonly costs $0.08–$0.12 per GB; a multi‑region database that replicates just 100 GB/day between three regions can burn through about $30,000 per year in transfer fees alone. Moving workloads between providers or regions without changing IPs—and without breaking reputation or access controls—starts to look less like a luxury and more like risk management.

Industry guidance on IP transit and addressing is clear: provider‑independent (PI) space + an autonomous system number (ASN) gives you portability and the ability to multi‑home; provider‑assigned space ties you directly to an ISP’s routing and commercial terms.

In this article, we combine those industry trends with what we at Melbicom see (running BGP sessions and dedicated servers across 21 Tier III/IV data centers, backed by 20+ transit providers, 25+ IXPs, and a CDN with 55+ PoPs. You’ll get a practical blueprint for:

• The prerequisites and workflow for BYOIP using border gateway protocol BGP
• How BYOIP compares to renting provider IPs
• The security controls that matter now that RPKI and IRR filtering are mainstream
• A concrete border gateway protocol configuration example you can adapt

What Is the Main Purpose of BGP in Computer Networks?

The border gateway protocol (BGP) is the Internet’s inter‑domain routing protocol. Its main purpose is to let autonomous systems exchange reachability information and select paths based on policy, not just distance. That’s what enables multi‑homing, traffic engineering across transit providers, and global reachability for your own IP space.

Under the hood, BGP is a policy engine. Each autonomous system (AS) advertises IP prefixes it can reach, attaching attributes like AS_PATH, local preference, and MED. These attributes let operators express business and technical policies—prefer cheaper transit, avoid certain countries, keep local traffic on local links vs. just “shortest path wins.”

In practical terms, border gateway routing protocol sessions between your ASN and your upstreams are how you turn address space into a globally reachable, multi‑homed asset. For BYOIP, that’s exactly the mechanism you use to make your own prefixes visible at scale.

BYOIP Prerequisites and Workflow: From Allocations to Global Reach

At a high level, BYOIP means: you own the addresses, you originate them from your ASN, and your infrastructure provider re‑announces them through its edge. Getting there is a four‑part workflow.

1. Own an ASN and Provider‑Independent Prefixes

You need:

• A public ASN from your regional internet registry
• Provider‑independent (PI) IP blocks, typically at least a /24 in IPv4 and /48 in IPv6

PI space is assigned directly to your organization by an RIR and is portable across providers; PA space is allocated by an ISP, is typically aggregated within their larger block, and can’t follow you when you change providers.

That portability is the foundation of BYOIP: the same prefixes can be originated from different data centers, different providers, or both. It does, however, commit you to running BGP border gateway protocol sessions somewhere in your stack—on your own routers, on dedicated servers, or both.

2. Publish IRR Route Objects and AS‑SETs

Internet Routing Registries (IRRs) are DBs that describe which AS is authorized to announce which prefixes (ROUTE/ROUTE6 objects), and which ASNs belong to a given organization (AS‑SETs). They’re still widely used by transit providers for prefix‑list and filter generation.

For BYOIP with Melbicom, the operational baseline is:

• Each prefix has a correct, current ROUTE/ROUTE6 object referencing your ASN
• You maintain an AS‑SET that lists your customer or internal ASNs
• IRR data is present in major DBs like RIPE, ARIN, APNIC, AFRINIC, LACNIC, RADB, or IDNIC

Melbicom validates customer prefixes against these IRRs and only accepts announcements that match published objects. It’s a straightforward step that dramatically reduces accidental route leaks and spoofed announcements.

3. Secure Routes with RPKI

IRRs are useful, but they’re essentially signed with a password. RPKI adds cryptographic proof that the holder of a prefix has authorized a specific ASN to originate it.

Using your resource certificate from the RIR, you create ROAs (Route Origin Authorisations) that state:

• Prefix (and maximum prefix length)
• Authorized origin ASN

When other networks perform BGP Origin Validation, each route targeting your prefix is classified as: VALID, INVALID, or UNKNOWN, depending on how it lines up with your ROAs.

RIPE and MANRS both now treat RPKI deployment as table‑stakes routing hygiene, and more than half of global IPv4 and IPv6 routes are RPKI‑covered. LACNIC’s guidance is clear: prefix holders—not transit providers—are responsible for creating ROAs, and multi‑homed prefixes can authorize multiple origin ASNs if needed.

Two practical rules for your RPKI setup:

• Keep max‑length fields tight (e.g., /24 on a /24) to avoid unintentionally blessing over‑specific hijacks
• Treat ROA management as part of change control whenever you add regions/providers

Melbicom enforces RPKI origin validation and rejects announcements with INVALID status, so ROAs are not optional in a BYOIP workflow.

4. Establish a BGP Session with Melbicom

With IRR and RPKI in place, the next step is to bring up one or more BGP sessions between your router and Melbicom’s edge.

Operationally, that means:

• You run a BGP daemon (BIRD or FRRouting are common choices) on a dedicated server or edge appliance
• We at Melbicom provision a BGP peering in the requested data center(s) for your ASN
• You export only your authorized prefixes; we import them after IRR and RPKI checks and propagate them to transit and peering neighbors

Melbicom offers free BGP sessions on dedicated servers, with IPv4 and IPv6 support and up to 16 prefixes per session by default. We also support full, default‑only, or partial route feeds, and BGP communities you can use to influence how we advertise your routes upstream, including which transit providers receive them and how they are prioritized.

5. Announce via Melbicom’s Global Edge

Once your prefixes are accepted, we re‑announces them from a globally distributed edge:

• 21 Tier III/IV data centers across the Americas, Europe, Asia, and Africa
• Per‑server bandwidth options up to 200 Gbps, depending on location
• A backbone with 20+ transit providers and 25+ IXPs, tuned for short, stable paths
• A CDN with 55+ PoPs in 35+ countries to keep content close to users

From your perspective, this means your PI space keeps its reputation and access lists while your workloads move between Melbicom locations or grow into multi‑region architectures. Combine that with BGP communities for provider and region preference (a pattern widely used in operator backbones), and you can dial in how traffic enters your network at a fairly granular level—without ever surrendering ownership of the addresses.

BYOIP vs. Provider‑Assigned IPs

From a distance, both BYOIP and renting IPs end in the same place: packets flow. But the economic and operational profiles are almost opposites. Guidance on PI vs. PA space from operator‑focused sources all lands on the same trade‑off: PA is simpler and cheaper; PI plus border gateway protocol buys you control and portability.

Here is a condensed comparison for planning purposes:

If you already operate an ASN and PI space, the marginal cost of BYOIP over Melbicom’s edge is almost entirely operational—getting the routing right once and keeping it clean.

What Are the Main Security Considerations for BGP?

BGP was designed for a smaller, more trusting Internet. The main security issues are route hijacks, route leaks, and plain misconfiguration that causes traffic to be mis‑routed or black‑holed. Modern best practice combines IRR filtering, RPKI origin validation, prefix‑limit controls, and careful policy design to mitigate these risks.

Even with RPKI adoption crossing the 50% mark, real‑world incidents show how fragile global routing can be. Datasets built from BGP‑monitoring tools record thousands of anomalies—many accidental, some malicious—impacting major technology firms and even government networks.

For BYOIP deployments, a secure posture typically includes:

• RPKI and IRR at the same time. IRR data is still widely used to build prefix filters; RPKI adds cryptographic checks and standardized VALID/INVALID/UNKNOWN states.
• Tight export policies. Your routers should only ever announce your PI prefixes and, where relevant, any customer prefixes you’ve explicitly agreed to originate.
• Inbound route filtering and max‑prefixes. Protect your own infrastructure from a misbehaving upstream and from accidental full‑table floods. Operator BCPs emphasize that the main scalability pressure on BGP is the growth of the routing table and churn from updates; enforcing sensible limits is table stakes.
• Conservative use of BGP communities. Communities are powerful for traffic engineering and provider selection; widespread measurement shows that most global prefixes now carry at least one community tag. Melbicom supports both our own and pass‑through communities but does not offer BGP blackhole services, keeping policies focused on routing rather than DDoS signaling.

For our part, Melbicom runs RPKI‑validated routing, strict IRR filtering across all major registries, and controlled acceptance of more‑specific routes (only /24s that are individually registered), which significantly reduces the risk of hijacks propagating through our edge.

BGP Configuration Example

At a high level, a BYOIP border gateway protocol configuration does three things: establishes a session with your provider, originates your prefixes, and applies import/export filters. The example below uses BIRD, which is what many Melbicom customers run on dedicated servers. It assumes you already have your PI prefix on eth0.

From there, you can extend the configuration with BGP communities for traffic engineering—tagging routes to prefer certain upstreams, limit propagation, or steer traffic via specific regions, mirroring the patterns documented in operator training materials.

Key Takeaways: Why BYOIP with BGP Is Worth the Effort

If you already hold PI space and an ASN, treating those addresses as a strategic asset rather than just plumbing changes how you build infrastructure. Based on industry data and what we see in production environments, a few practical recommendations emerge:

• Align IP strategy with multi‑region reality. Latency‑sensitive and regulated workloads increasingly span regions, and even small amounts of cross‑region traffic can become a major line item at public‑cloud egress prices. BYOIP over BGP lets you move or duplicate workloads without repeatedly paying in downtime and address churn.
• Make RPKI and IRR first‑class citizens. With more than half of global routes now RPKI‑covered, failing to publish ROAs and maintain IRR objects is no longer a harmless omission—it’s a security and reachability risk. Build ROA and IRR updates into your normal deployment and change‑management processes.
• Invest once in routing expertise, reap benefits for years. Standing up robust border gateway protocol routing—with filters, communities, prefix‑limits, and monitoring—takes time, but the payoff is cumulative: every future migration, new region, or new provider is easier because your IP space is already portable.
• Choose providers that amplify, not dilute, your control. BYOIP only delivers if upstreams respect RPKI and IRR, give you useful BGP community hooks, and operate a well‑peered, low‑latency edge. Look for clear documentation of filtering policies, RPKI support, and route‑control options—not just raw bandwidth numbers.

Turn Routing into a Strategic Capability

The combination of PI address space, an ASN, and a well‑designed border gateway routing protocol deployment turns IP addressing from a sunk cost into a strategic lever. Instead of re‑numbering every time you change providers, you re‑pin BGP sessions. Instead of accepting whatever path your upstream picks, you use communities and policy to shape how traffic enters and leaves your network.

As routing tables grow and RPKI deployment crosses critical thresholds, the gap between “best effort” and “engineered” Internet connectivity is widening. Operators who treat BGP as a first‑class system—complete with security controls, telemetry, and clear ownership—will be able to adopt new regions, hardware generations, and commercial models without renegotiating their identity on the network. BYOIP is the natural endpoint of that mindset.