Migrate IPv4 Blocks Without Downtime

For network architects and IT managers, IPv4 block migration between cloud providers is a high-stakes operation. Maybe you’re driven by cost, or perhaps compliance needs are pushing you. It could just be that you need specific geographic features. Whatever the reason, moving your address space requires a rigorous approach to avoid service disruption. Downtime isn’t an option in today’s always-on economy. A misconfiguration during a migration can lead to packet loss, blackholing, and reputational damage. This guide provides a comprehensive pathway to transferring your IP assets securely and efficiently.

The Planning Phase: Prerequisites and Governance

Before initiating the technical configuration, you must ensure administrative and regulatory compliance. The most critical hurdle in IPv4 block migration is proving ownership. Cloud providers are strict about accepting IP blocks to prevent hijacking and fraud.

Verify Registration and RIR Status

Ensure your IP blocks are registered with your Regional Internet Registry (RIR)—such as ARIN, RIPE NCC, or APNIC—under your organization’s legal name. If the blocks are registered through a previous ISP, you must create a maintenance account with the RIR and have the sponsor reassign the blocks to your account directly. You simply cannot migrate blocks that are not officially tied to your corporate entity.

Preparing the Letter of Authorization (LOA)

Cloud providers require a notarized Letter of Authorization (LOA). This document serves as proof that you, the IP owner, authorize the specific cloud provider to announce your prefixes. The LOA must include:

• The exact IP prefixes (CIDR notation) being moved.
• The ASNs (Autonomous System Numbers) involved—both the source and the destination.
• Company contact details matching the RIR records.
• A signature from an authorized officer.

Technical Strategy: BGP and Multi-Homing

The technical backbone of a seamless migration is Border Gateway Protocol (BGP). To achieve zero downtime, you must leverage a multi-homing strategy where the IP block is announced simultaneously from both the source and destination environments for a brief period.

Understanding BGP Announcement

Simply pointing DNS records to new IPs is often insufficient for enterprise applications reliant on strict whitelisting or direct IP access. You must announce the IP prefix from the new cloud provider while it is still active on the old provider. This creates a “dual-homed” state.

By manipulating the BGP attributes—specifically AS-PATH prepending and Multi-Exit Discriminator (MED)—you can influence inbound traffic flow. Initially, you configure the new cloud provider to announce the prefix with a less preferred attribute set, ensuring traffic continues to flow through the legacy provider. Once the new route is visible globally (verified via Looking Glass servers), you gradually shift preference to the new provider.

Step-by-Step Execution Process

Execution requires coordination between your network operations team, the source provider, the destination provider, and potentially your upstream carriers if you bring your own IPs (BYOIP).

1. Route Object Creation

Before the cloud provider will accept your routes, you must create a route object in the RIR database (e.g., RADB or IRR) that authorizes the destination cloud ASN to originate your prefixes. Without this, the cloud provider’s filters will reject your announcements.

2. Establish the Tunnel and Initial Announcement

Set up the connectivity (Direct Connect, ExpressRoute, or VPN) to the new cloud provider. Configure your edge router or the cloud provider’s BGP endpoint to announce the prefixes. Initially, use AS-PATH prepending to make the path via the new cloud provider longer (less attractive) than the current path.

3. Global Propagation Check

Use tools like BGP HE.NET or RIPE Stat to verify that the new prefix is visible from multiple vantage points globally. Do not proceed until the route is propagated.

4. Shift Traffic Preference

Remove the AS-PATH prepending on the new cloud announcement or increase the local preference. Simultaneously, prepend the AS-PATH on the source provider or withdraw the route entirely. Monitor traffic graphs closely.

Validation and Verification

After the traffic shift, validation is crucial to ensure integrity.

• Connectivity Testing: Ping and traceroute from external monitoring nodes to ensure the new path is latency-optimized.
• Reverse DNS (rDNS): Update PTR records immediately. If rDNS breaks, email deliverability may suffer.
• Security Groups: Verify that firewall rules in the new cloud environment match the legacy setup to prevent dropped packets.

Acquiring Blocks for Migration

Sometimes, the requirement to migrate is driven by the need to own portable address space that is not tied to a specific ISP. If your current IP allocation is provider-assigned (PI) rather than provider-aggregatable (PA), you may need to purchase portable blocks to facilitate a move between clouds.

Acquiring IPv4 blocks in the current market requires diligence. Prices fluctuate based on block size and regional availability. It is vital to use a trusted marketplace to ensure that the blocks are clean, free of blacklists, and legally transferable. IP4 Market offers a secure platform for such transactions, connecting buyers with verified sellers and ensuring the RIR transfer documentation is handled correctly. By sourcing your blocks through IP4 Market, you eliminate the risk of purchasing encumbered address space, ensuring a smooth IPv4 block migration process.