Migrating to Leased IPv4 Without Downtime - The Bits That Actually Matter published

I run a platform where IP owners lease IPv4 subnets to IP renters across the RIPE region. Which means I've watched a lot of migrations - clean ones and messy ones. The messy ones almost always fail for the same reasons.

This isn't a comprehensive guide. It's the list of things that trip people up when they know the basics but miss the details.

1. Lower TTL before you think you need to

If your DNS records have a TTL of 86400 (24 hours) and you lower it an hour before migration, you'll spend the next 23 hours with traffic split across two addresses. If the old subnet goes offline during that window, part of that traffic simply disappears.

Rule: lower TTL at least one full TTL cycle before your migration window.

# Check your current TTL before doing anything
dig A yourdomain.com | grep -A1 "ANSWER SECTION"

Target TTL for migration: 300 seconds. For critical records, go as low as 60.

After migration is stable, raise it back. Low TTL means more DNS queries hitting your nameservers - it's not a permanent setting.

2. PTR records don't update themselves

This one catches people off guard. Reverse DNS for leased IPv4 subnets is managed by the IP owner, not the IP renter.

In the RIPE region, the IP owner (or the LIR managing the resource) needs to create a domain object in the RIPE database that delegates the reverse zone to your nameservers. That's not something you can do yourself, and it doesn't happen automatically when you lease a subnet.

Coordinate this with your IP owner during pre-migration planning. Not on cutover day.

3. RPKI: UNKNOWN and INVALID are not the same problem

If you're announcing your leased prefix via BGP, you need a ROA (Route Origin Authorization). The ROA is created by the IP owner - not by you.

Two states worth knowing:

• UNKNOWN - no ROA exists for the prefix. Most networks accept this, but conservative peers may filter it.
• INVALID - a ROA exists but with the wrong ASN or wrong maximum prefix length. Networks actively drop INVALID prefixes.

Check your ROA status before migration:

# Using the RIPE NCC validator or Routinator
# Or check via Cloudflare's RPKI toolkit
# https://rpki.cloudflare.com

If your prefix is INVALID, you have a misconfiguration to fix. If it's UNKNOWN, you need a ROA created - talk to your IP owner.

4. The /24 rule - don't skip this

If your leased block is smaller than /24 (a /25, /26, or anything longer) - you cannot announce it independently via BGP to the internet.

Most upstream providers and IXP route servers filter prefixes longer than /24. The announcement won't be rejected with an error. It will just silently not propagate. Your ROA can be perfect, your IRR objects correct, your BGP session up - and the prefix still goes nowhere.

If your leased block is smaller than /24, talk to your IP owner about aggregate announcement options before planning a BGP-based migration.

5. Run parallel, not sequential

The safest migration is always: bring up the new subnet fully, validate everything, then drain traffic from the old one. Never the other way around.

Checklist before DNS cutover:

• [ ] Services responding on new IPs
• [ ] BGP prefix visible from multiple vantage points (check RIPE RIS or BGPView)
• [ ] Monitoring active on new subnet
• [ ] PTR delegation live

After DNS update, watch traffic on both subnets. Decommission the old one only when traffic has dropped to zero - and then wait another 24-48 hours before pulling it fully.

# Verify DNS propagation from multiple resolvers
dig A yourdomain.com @8.8.8.8
dig A yourdomain.com @1.1.1.1
dig A yourdomain.com @9.9.9.9

# Verify routing path to new subnet
mtr -rn yourdomain.com

6. Post-migration reputation monitoring

A clean leased subnet can pick up a blacklist entry fast if something on your infrastructure is misconfigured - an open relay, a proxy, a compromised service.

Check at 24h, 72h, and one week after migration:

• Spamhaus (SBL, XBL, PBL) - critical if you're sending email
• Talos Intelligence
• AbuseIPDB
• MXToolbox for a consolidated view

If you appear on a list, the cause is almost always something on your end - not a history problem with the block itself.

---

That's the short version. If you want the full breakdown - DNS TTL timing in detail, BGP announcement setup with RPKI and IRR specifics, step-by-step migration phases, and BYOIP configuration for AWS, GCP, and Azure - I wrote a longer guide on the IPbnb blog:

How to Migrate Your IP Infrastructure to Leased IPv4 Without Downtime

Happy to answer questions in the comments.