DEV Community: Artem Kohanevich

IPv4 in 2026: Three Practical Positions for RIPE Operators

Artem Kohanevich — Tue, 02 Jun 2026 11:18:42 +0000

TL;DR: If you run a network in the RIPE region, you're probably either sitting on idle IPv4, short of it, or in a position to lease it to others under your own brand. Here's what each option looks like operationally.

Picture two operators at the same NOG meeting.

One runs a regional ISP that moved its core behind IPv6 and CGNAT a few years back. A legacy /18 is still announced - just enough to hold the allocation - but it carries no real traffic and has earned nothing since the redesign. Clean, registered, idle.

The other runs a growing access network and is out of address space. New subscribers sit behind CGNAT, and the support queue fills with the usual symptoms: broken inbound connections, IPsec and gaming complaints, mail reputation problems. Their only official supply option is a slot on the RIPE waiting list.

They're each other's answer. The thing standing between them is infrastructure - LOAs, ROAs, routing, reputation checks, billing, contracts. That's the IPv4 secondary market in one sentence.

If you operate in the RIPE region, you're probably closer to one of these two than you think - and often you're both. Three positions you can take:

1. Monetize idle IPv4

A lot of RIPE members hold legacy space that went quiet after a redesign or an IPv6 migration. At roughly $80/month for a /24 (about $0.31 per address), a dormant /20 brings in around $1,270/month and a /16 around $20,300 - on infrastructure you already own and pay the flat RIPE fee to register.

With sale prices at multi-year lows, leasing usually beats selling: income now, asset retained, no added registry cost. The common blockers - blacklist history, a messy RIPE/whois record, RPKI not configured - are routine cleanup, not dealbreakers. Typical sequence: audit and reputation check, then correct the records, set up RPKI with valid ROAs, and clear any blacklist entries. After that the subnet is ready to earn.

2. Lease the IPv4 you need

RIPE's free pool has been gone since November 2019. The waiting list isn't a real supply channel - a single /24, a 12-24 month wait, hundreds of LIRs queued, and no timing guarantee. For adding subscribers this quarter, it's not a plan.

CGNAT covers the gap but carries a real operational cost: port exhaustion, broken applications, abuse attribution headaches, geolocation problems, and the support load that follows.

Leasing is the standard OPEX answer now. On the wire, leased space behaves exactly like owned space: announce the prefix from your ASN with a valid ROA and a matching LOA, and RPKI-validating peers treat it no differently. There's no 24-month transfer hold, and no large up-front payment locked into an asset while prices are still moving.

3. Resell IPv4 leasing under your own brand

The one most operators overlook. If you already run a network, you have what an IP leasing business needs: client trust, working billing and support, regional relationships, and often your own address space. What's missing is the platform layer - listing and matching, compliance, reputation and delisting tooling.

A white-label setup supplies that layer behind your brand. You lease to your own customers, bundle space with connectivity or hosting, and keep the margin instead of referring it out. Data centers and hosting providers fit this cleanly - it's an extension of what they already sell to colocation and hosting tenants. You stop being a buyer or seller in someone else's marketplace and become the marketplace.

Across all three, the specialist work is the same - registry cleanup, compliance, routing, abuse monitoring - and it can sit with a platform partner rather than on your team. You don't have to become an IPv4 specialist to work this market.

The infrastructure to connect the two operators in that room finally exists. The only real question is whether you use it actively or keep reacting to the shortage.

Full write-up, with the complete breakdown of each path: ipbnb.com/blog/ipv4-for-nog-2026

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

Artem Kohanevich — Thu, 28 May 2026 10:47:37 +0000

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.

IPv4 Geolocation and Leasing: A Practical Guide for Network Operators

Artem Kohanevich — Thu, 21 May 2026 11:22:44 +0000

Geolocation questions come up regularly when operators start leasing IPv4 blocks. Does the subnet show up in the right country? How long until databases reflect the correct location? What's the fix if something is wrong?

The short answer: for most infrastructure workloads, geolocation is irrelevant. For a specific set of use cases, it requires deliberate setup. This post covers both.

Two Separate Systems Worth Distinguishing

"Geolocation" in the IPv4 context actually refers to two different things, and confusing them leads to wasted troubleshooting time.

RIR-registered location - what's recorded in the RIPE database via the geofeed: and geoloc: attributes on your inetnum object.

Commercial database location - what services like MaxMind, IPinfo, or Google display when they query your block. These databases pull from multiple signals:
RIR records, BGP routing data, latency measurements, user corrections. They operate independently and update on their own schedules.

When operators ask whether their subnet will appear as a specific country, they're almost always asking about the second category. The answer depends on which database, when it last crawled your block, and what signals it weighted.

RIPE Attributes: What Actually Works

Three attributes are relevant here, and they're not equally useful.

geofeed: - links to a structured CSV file (RFC 8805 format) hosted at a public HTTPS URL. Providers supporting RFC 9632 discovery ingest it automatically.

This is the mechanism with real adoption among commercial database providers and the recommended starting point.

geoloc: - records latitude/longitude coordinates directly in the RIPE database. Limited adoption among third-party providers. Worth setting, but don't rely on it to influence MaxMind or similar databases.

country: - an administrative registration field. RIPE's own documentation notes it was never formally specified what this field represents. Not a geolocation signal. Don't treat it as one.

RIPE doesn't verify any of this data. Publishing a correctly configured geofeed gives providers a structured, crawlable source - but each provider acts on it according to their own update cycle.

Use Cases Where Geolocation Is Operationally Critical

VPN and proxy services - if you're selling a country-specific endpoint, the IP block needs to register as that country in the databases your users' apps query.

Programmatic advertising - ad exchanges categorize traffic geographically. European inventory carries different pricing from traffic that appears to originate outside the EU. Miscategorized geolocation means mispriced inventory.

CDN configuration - routing decisions are based on IP location. A subnet appearing in the wrong region routes users to suboptimal edge nodes.

GDPR and data localization compliance - infrastructure processing EU data sometimes needs to be clearly identifiable as EU-based. An IP block appearing outside the EU creates compliance friction regardless of where the servers physically sit.

Web scraping and data collection - many platforms serve differentiated content, pricing, and availability by detected country. Your IP's geolocation determines the geographic view your infrastructure gets.

Use Cases Where It Doesn't Matter

General hosting, application servers, ISP infrastructure, internal networking, standard web traffic delivery - geolocation has no operational effect on any of it.

BGP routing operates on routing tables. Email deliverability depends on reputation signals - spam history, blacklist status, authentication records - not on geolocation.
A subnet geolocated in Amsterdam and one geolocated in Paris are treated identically by receiving mail servers.

Propagation Timelines

After lease activation, there's a normal window before all databases reflect the correct location.

MaxMind - the most widely used commercial database - updates the majority of its GeoIP databases every weekday. Correction requests via the GeoIP Exchange program (where geofeed submission is now the standard method) don't come with a committed review timeline.

Downstream services - CDN networks, ad exchange databases, streaming platform geolocation layers - typically take two to six weeks to fully propagate a change.

This is expected behavior, not a problem to solve.

If your deployment is geolocation-sensitive, build in a one-to-two week buffer after activation before relying on correct location data in production. For ad tech or CDN-critical workloads, two to four weeks is the safer margin.

Geolocation vs. Reputation: Not the Same Thing

These get conflated more than any other pair of concepts in IPv4 operations.

Geolocation - where your block appears to be located.
Reputation - the behavioral history associated with that block: spam records, blacklist entries, abuse flags.

Completely separate systems. A block can have accurate geolocation and a problematic reputation record, or an outdated geolocation entry and a perfectly clean history. Correcting one has no effect on the other.

If you're evaluating a subnet before leasing, run a reputation check. Not a geolocation lookup.

For a more detailed breakdown of how this applies to IPv4 leasing specifically, including how IPbnb handles geolocation validation at the listing stage, the full guide is on our blog: IPv4 Geolocation and Leasing - IPbnb

What VPN Providers Get Wrong About IPv4 (And How to Fix It)

Artem Kohanevich — Sat, 16 May 2026 06:19:52 +0000

I talk to a lot of VPN operators. And the conversation usually goes the same way - they're dealing with user complaints about blocked content, geo-errors that make no sense, or payment processors flagging transactions. They've checked their servers, their routing, their configs. Everything looks fine.

The problem is almost always the IPs.

Here's what I've seen trip people up most often.

Your IP's history travels with it

When you acquire an address block - whether you buy it or lease it - you inherit whatever happened on those IPs before you. Spam campaigns. Botnets. Port scanning. Credential stuffing. That history lives in threat intelligence databases, and platforms query those databases constantly.

For most services, a tainted IP is an inconvenience. For a VPN provider, it's a product failure. Every user routing through that address gets blocked, flagged, or restricted - and they have no idea why. They just know your service doesn't work.

Before you deploy any block, run it through multiple reputation databases. Not one. Several. Because they don't agree with each other, and the platform blocking your users might be querying a different one than you checked.

Geolocation data is wrong more often than you'd think

If your service promises users a German IP, that IP needs to actually geolocate to Germany in the databases streaming platforms and financial services query. Sounds obvious. In practice, it's a mess.

A block registered to a German organization might show up as Netherlands in MaxMind and France in IP2Location. Neither database is authoritative. They're all maintained independently, updated on their own schedules, and frequently out of sync.

The fix is straightforward but tedious: verify geolocation across multiple databases before deployment, submit correction requests where needed, and monitor for drift over time. Records change, especially when ownership or routing paths change.

The cleanest approach is to announce IP blocks from infrastructure physically located in the target region. When the server, the block registration, and the announcement origin all point to the same country, geolocation databases are much less likely to get it wrong.

Compliance is more complicated than "no-logs policy"

A no-logs policy is a product decision. Compliance is a legal one. They're not the same thing, and they can conflict.

Many jurisdictions require ISPs and network operators to retain connection metadata for defined periods. If your infrastructure runs through a country with mandatory retention laws, that obligation applies to you regardless of what your privacy policy says.

Then there's RIPE NCC policy if you're operating in the European region. Accurate WHOIS data isn't optional. Neither is responding to abuse reports. Failing to act on abuse complaints escalates fast - to your upstream provider, to RIPE NCC, and sometimes beyond.

The part operators underestimate most: abuse response is an operational requirement, not a legal nicety. Unaddressed abuse reports don't just create liability - they damage the reputation of the IP blocks you're using, which creates a direct problem for your service quality.

Leasing beats owning for most VPN use cases

Owning IPv4 gives you control. Leasing gives you flexibility. For VPN infrastructure specifically, flexibility usually wins.

Your IP pool needs change constantly - new markets, traffic spikes, blocks that need to be rotated out because of reputation issues. Buying address space locks you into a size and location that made sense at a specific point in time. Leasing lets you expand into a new region in days, scale back when demand drops, and swap out blocks that aren't working without taking a capital loss.

Most mature VPN operators end up with a hybrid: some owned blocks for their core infrastructure, leased space for regional expansion and flexibility.

The key thing to get right with leased blocks is due diligence before deployment - reputation check, routing history, geolocation verification. The time you put in upfront is significantly less than the time you'll spend dealing with user complaints after.

We wrote a longer breakdown of all of this on the IPbnb blog - covering IP reputation monitoring, geolocation management, compliance requirements, and how to build regional pools through leasing: IPv4 for VPN Providers: Clean IPs, Geolocation & Compliance Guide

If you're working on VPN infrastructure or have run into any of these issues, happy to discuss in the comments.

IPv4 Block Size Cheat Sheet: /24 to /16 with Lease Pricing

Artem Kohanevich — Fri, 15 May 2026 09:20:20 +0000

Picking the wrong IPv4 block size is a quiet, expensive mistake. You either over-lease and overpay, or under-lease and find yourself back in the market in six months. This is a quick reference to get the decision right the first time.

The Math, Fast

Every IPv4 block size follows the same formula: 2^(32 - prefix length) total addresses, minus 2 reserved (network + broadcast) = usable hosts.

CIDR	Total IPs	Usable IPs	/24 equivalents
/24	256	254	1
/23	512	510	2
/22	1,024	1,022	4
/21	2,048	2,046	8
/20	4,096	4,094	16
/19	8,192	8,190	32
/18	16,384	16,382	64
/17	32,768	32,766	128
/16	65,536	65,534	256

Hard floor to know: /24 is the minimum BGP-routable prefix in the RIPE NCC service region. Sub-/24 blocks are filtered by the vast majority of BGP peers and won't propagate across the public internet. If you only need 30 external IPs, you still lease a full /24.

Cost per IP by Block Size (RIPE Region)

Larger blocks = lower per-IP monthly rate, but the savings curve flattens fast:

Block	Total IPs	Est. monthly	Per IP/month
/24	256	from ~€180	~€0.70
/23	512	from ~€330	~€0.65
/22	1,024	from ~€620	~€0.61
/21	2,048	from ~€1,150	~€0.56
/20	4,096	from ~€2,050	~€0.50

Prices are illustrative. Actual rates vary by block reputation, availability, and lease term.

The per-IP delta between a /24 and a /22 is small. Lease term length often has a bigger impact on total cost - a 12-month /24 can undercut a month-to-month /22.

Which Block Size for Which Use Case

Shared/web hosting: Start with /24, segment customers per /24 for cleaner blacklist management and abuse isolation.

Dedicated servers (50-100 nodes, multiple IPs each): /22 or /21 - account for IPMI interfaces, management ranges, and customer allocations from the start.

Proxy/VPN rotation pools: Address diversity drives value here. /21 to /20 for production scale; /23 to /22 for pilots. Always check IP reputation history before leasing - it matters more here than anywhere else.

Enterprise multi-site: Minimum one /24 per physical site. Use /22 or /21 aggregates for clean BGP summarization across locations.

Three Things That Trip People Up

1. /22 ≠ guaranteed routing flexibility
A /22 can be announced as a single aggregate prefix. Deaggregating into /24s for traffic engineering is possible, but whether your upstream allows it is a different question. Verify before you commit.

2. Reputation travels with the block
Always check the block's abuse history on Spamhaus, Barracuda BRBL, or via MXToolbox before signing a lease. A cheap /22 with a dirty history will cost you more in operational pain than it saves in rent.

3. RIPE's 24-month transfer lock applies to purchases, not leases
If you buy rather than lease, transferred addresses can't be re-transferred for 24 months under RIPE policy. Leasing sidesteps this entirely.

For the full breakdown - including an interactive IPv4 CIDR calculator, a use-case decision framework, and detailed guidance on lease pricing - check out the complete guide on the IPbnb blog:

IPv4 Subnet Calculator: How to Choose the Right Block Size for Your Project →

How to Protect Your IP Prefixes from BGP Hijacking

Artem Kohanevich — Mon, 27 Apr 2026 08:04:57 +0000

BGP has no built-in mechanism to verify that the ASN announcing a prefix is actually authorized to do so. Any autonomous system can claim any address space. If the announcement propagates and downstream routers accept it, traffic follows.

This isn't academic. In 2008, Pakistan Telecom announced a more-specific /24 of YouTube's /22. It propagated globally through PCCW. YouTube traffic routed to a blackhole for two hours. In 2018, attackers hijacked Amazon's Route 53 DNS service — redirected queries for myetherwallet.com to a phishing site, drained ~$150,000 in Ethereum from users who logged in. Neither attack required compromising a single system. Both exploited the same BGP design assumption from 1989: that peers tell the truth.

RPKI fixes this. Here's how it works and what you need to do.

How RPKI works

Resource Public Key Infrastructure lets IP holders cryptographically prove that a specific ASN is authorized to originate a specific prefix. The core object is a Route Origin Authorization — a signed certificate containing three fields:

The protected prefix
The ASN permitted to announce it
The maximum prefix length allowed

The certificate chains back to your RIR (RIPE NCC for European and Middle Eastern operators) as the trust anchor. Routers check incoming BGP announcements against published ROAs and assign one of three validation states:

State	Meaning
Valid	Prefix and ASN match a ROA; length within max
Invalid	ROA exists but ASN doesn't match, or prefix exceeds max-length
Not Found	No ROA covers this prefix

Networks running Route Origin Validation (ROV) drop Invalid routes. As of May 2024, all but one transit-free tier-1 provider does this — reducing a hijacked route's propagation by one-half to two-thirds. Adoption across tier-2 and regional networks is still uneven, but the major transit providers enforcing ROV carry the majority of global internet traffic. An attack that would have propagated everywhere in 2010 now stalls at most of the networks that matter.

Creating a ROA in RIPE NCC

You need LIR access to my.ripe.net and the prefix must appear under your resource certificate before you start.

The process:

Log in to my.ripe.net → navigate to the RPKI section
Confirm your prefix appears in your resource certificate
Select the prefix, enter the announcing ASN, set max-length
Publish and verify with an external validator

ROAs reach relying parties within 15-30 minutes for RIPE NCC under normal conditions. Always verify with an external tool — don't rely on the portal's own confirmation.

Max-length: where most mistakes happen

Max-length is the most consequential parameter and the most commonly misconfigured.

Mistake 1: Too tight

You hold a /22. You set max-length to /22. You announce it as four /24s. Every /24 sub-announcement returns Invalid — including from your own ASN. You've caused your own outage.

Fix: if you plan to announce /24s from a /22, set max-length to /24.

Mistake 2: Too loose

You set max-length to /32 to avoid the above. You've now authorized any more-specific announcement down to a single host address — which is exactly what more-specific hijacking exploits. RPKI's prefix-length protection is disabled.

Fix: set max-length to match the most-specific prefix you actually intend to announce, nothing beyond that.

Other common mistakes:

Creating a ROA for a prefix that will be announced from multiple ASNs using a single ROA. One ROA covers exactly one prefix-ASN combination. You need a separate ROA per authorized ASN.
Forgetting to update ROAs when changing upstream providers, migrating ASNs, or onboarding to a cloud BYOIP program. The ROA needs updating before the new announcement goes live — not after.
Not verifying propagation after creation. A ROA in the portal that hasn't reached relying parties provides no protection.

RPKI with leased IPv4

ROAs can only be created by the resource certificate holder — the IP owner, not the user. In a leasing arrangement this means:

If you're announcing leased space from your own ASN: the lessor must create a ROA covering your ASN before you start announcing. Confirm this is in the leasing agreement and that it happens before go-live.
If the lessor is announcing on your behalf: the ROA covers their ASN. Confirm this explicitly — don't assume.
BYOIP on AWS, GCP, or Azure: cloud providers validate RPKI status during onboarding. A prefix that returns Invalid during validation stalls or blocks the onboarding process, and you can't retry quickly. RPKI status needs to be clean before you start the cloud provider's validation flow.

A leasing provider who can't clearly explain their ROA creation process for lessee ASNs is adding operational risk to your setup. It should be a standard part of onboarding, not an afterthought.

RPKI vs IRR — and why you need both

	IRR	RPKI
Cryptographic verification	No	Yes
Who can register	Anyone	Resource holder only
Data quality	Variable — stale/fraudulent entries common	Tied to RIR allocation
Filtering basis	Route objects	ROA validation states
Deployment	Widespread	Growing — near-complete at tier-1

IRR is the older system. Upstreams use route objects to build prefix filters. The weakness: no cryptographic enforcement. Anyone can register a route object for a prefix they don't own, and the databases have historically had significant stale and fraudulent data.

RPKI is cryptographically secured — a ROA can only be created by the actual resource holder.

They're complementary. Create RPKI ROAs as primary protection. Maintain IRR route objects in parallel for compatibility with networks that filter on IRR but haven't fully deployed ROV. If you're inheriting a prefix through a lease or transfer, check both — a valid ROA alongside an outdated IRR entry pointing to a previous ASN produces routing problems that take time to diagnose.

Minimum viable monitoring setup

RIPE Stat (stat.ripe.net) — BGP routing data, prefix announcements, AS path history, RPKI status. The routing history view catches announcements that appeared and disappeared, which is how most hijacking incidents present.
Cloudflare RPKI Validator (rpki.cloudflare.com) — quick ROA state check after creation or modification. Also useful for due diligence on a prefix before leasing it.
BGP.tools (bgp.tools) — fast prefix visibility and ASN data. Useful for checking what ASNs are currently announcing a given prefix.
Alerting — passive tooling isn't enough for production. You want real-time alerts when a prefix starts being announced from an unexpected ASN, not discovery after a service disruption.

Quick reference

Task	Where
Create ROA	my.ripe.net → RPKI
Check ROA state	rpki.cloudflare.com
BGP prefix visibility	stat.ripe.net, bgp.tools
BYOIP setup guide	ipbnb.com/blog
ROA creation walkthrough	ipbnb.com/help-center

Full guide with screenshots, BYOIP-specific requirements, and the leased IPv4 deep-dive: [https://ipbnb.com/blog/rpki-bgp-hijacking-prevention]

IPv4 Block Sizing for Operators Who Don't Want to Go Back to Market Mid-Project

Artem Kohanevich — Mon, 27 Apr 2026 05:12:25 +0000

Most IPv4 leasing mistakes aren't about finding a clean block or negotiating terms. They're about signing for the wrong size and paying for it two months in - either back on the market under time pressure, or sitting on a block at 30% utilization watching abuse reports accumulate on addresses nobody is using.

This is a practical sizing guide for network operators.

The one thing most operators get wrong

You're not sizing for today. You're sizing for the end of the lease term.

If you're signing a 12-month contract, size for month 10. A block that fits at signing and strains by month six isn't a utilization win - it's a planning failure. Going back to market mid-contract means urgency pricing on a second block, a second onboarding process, and potentially running at degraded capacity in the gap.

That combination costs more than sizing up from the start almost every time.

The four variables

Before matching a use case to a CIDR, get these four things clear.

Projected utilization rate

Not all IPs in a leased block will be active simultaneously. For some use cases, that's by design. Email operators deliberately keep active sending IP counts lower than total pool size - 50 active senders out of a /24 is normal practice, not waste. Hosting providers run 60-80% utilization intentionally.

The threshold that matters: if your expected steady-state utilization exceeds 85%, size up one increment. No headroom means no room to absorb traffic spikes without reputation or service impact.

Growth horizon vs. lease term

Size for the end of the contract, not the beginning. If that math produces a block that feels too large right now, a shorter initial term with a planned upgrade often makes more operational sense than locking into a long-term commitment on space you'll immediately strain.

Reputation management capacity

Larger blocks are harder to monitor. A /19 managed by a three-person infra team is 8,192 addresses that could be generating abuse activity without anyone noticing. Size to what your team can actively oversee. Block reputation directly affects renewal terms and future flexibility - neglect has compounding costs.

Budget discipline against both failure modes

Idle IPs aren't neutral. A block at 30% utilization is generating probe traffic and abuse exposure across 70% of its address space with no operational value to offset it. The goal isn't maximum capacity - it's right-sized.

Use case notes worth reading

Cloud / BYOIP
AWS, GCP, and Azure all enforce a /24 minimum for BYOIP. This is a hard constraint - a /25 or smaller gets rejected regardless of how clean the block is. No workaround exists.

Beyond the minimum: cloud BYOIP also has specific reputation requirements. AWS explicitly reserves the right to reject prefixes with poor history. Block reputation needs to be verifiable before you start the cloud provider's validation process - which can take one to two weeks for AWS and longer for GCP - and cannot be retried quickly if a block is rejected.

Starting with a dirty block means starting over.

If cloud growth is on your roadmap, size for 12 months from the start. A second BYOIP onboarding mid-project is slower and more painful than it sounds.

Email sending

Inbox providers evaluate reputation at the /24 level. The structural principle: one /24 per sending stream. Transactional mail (receipts, alerts, password resets) on one block, marketing on another. When a campaign triggers a complaint spike, it shouldn't touch transactional deliverability. Mixing them makes reputation management significantly harder and recovery slower.

VPN / proxy

VPN exit nodes structurally attract higher complaint rates - port scanning probes, user policy violations, automated false positives. This isn't an operator negligence problem; it's an architectural one. Your active IP pool needs buffer specifically to absorb reputation incidents without impacting users on clean addresses. A /24 with no buffer gets painful fast after a few incidents shrink the usable pool.

Hosting

At roughly one IP per account, a /23 covers 400-500 accounts at comfortable utilization. Hosting is one of the highest-abuse-risk environments for leased IPv4 - customers send email, run web applications, and occasionally violate AUPs in ways that affect neighboring IPs on the same /24. Per-/24 reputation monitoring isn't optional here. A problem with one tenant's behavior can affect everyone else on the same range.

If you have 150+ current customers, start with a /23. If you expect to reach that within six months, start with a /23 anyway.

A note on block quality vs. block size

These are separate decisions and they get conflated constantly. The cheapest /22 on the market may be cheap for a reason - abuse history, blacklist entries, routing irregularities. Don't trade quality for size to save on the monthly rate. The downstream cost of managing a dirty block - deliverability failures, abuse complaint handling, reputation recovery time - consistently exceeds the savings.

One operational gotcha

If your architecture depends on announcing a /23 as two separate /24s - for geographic diversity, traffic separation, or tenant isolation - verify upstream support before signing. Many networks filter prefixes more specific than /24. It's a valid configuration, but it requires upstream coordination that not all providers offer. Confirm it explicitly rather than assuming.

Quick sizing sanity check

Before committing to a block size, run through this:

Am I sizing for the end of the lease term, not today?
Does my utilization model stay below 85% at steady state?
If I hit 90%+ in month eight, what does going back to market actually cost?

Can my team actively monitor this many addresses?

Do I need IP diversity across customers or services - and would multiple /24s serve that better than one large block?

If any of those questions produce uncomfortable answers, adjust before signing rather than after.

Full use case breakdown, pricing estimates, and the internal justification framing (for when you need to explain this to a finance lead or CTO who doesn't speak CIDR): https://ipbnb.com/blog/ipv4-block-size-guide

IPv4 Leasing Platforms in 2026: An Infrastructure Engineer's Comparison

Artem Kohanevich — Wed, 15 Apr 2026 08:17:50 +0000

If you've ever had to provision a /24 under a deadline, you know the drill. You need clean space, valid ROA, LOA in hand, and geolocation updated before your upstream starts routing. The platform you use to get there matters more than most people admit until something goes wrong.

IPXO is where a lot of teams start. It's automated, it's documented, and it handles the RPKI layer without you having to babysit it. But it's not the only option in 2026 - and depending on your stack and your operational model, it might not be the right one.

This is a practical breakdown of five IPv4 platforms: what they actually do, how their models differ, and when each one makes sense from an infrastructure perspective.

The technical split that matters most

Before comparing platforms, it's worth understanding the structural difference that separates them.

Managed pool model - the platform aggregates IP inventory from multiple owners into a centralized pool. You lease from the pool; the platform handles RPKI, abuse, and documentation. You don't know whose space you're using, and the owner doesn't know who's using their space. IPXO operates this way.

Direct marketplace model - IP owners list their own subnets with defined terms. You see what you're leasing, from whom, under what conditions. RPKI and ROA are still handled, but the relationship is direct. IPbnb operates this way.

The practical difference: in a managed pool, subnet history and ownership chain are opaque. In a direct marketplace, you can verify the listing, the owner's LIR status, and the subnet's reputation before committing. For environments where IP provenance matters - abuse-sensitive workloads, compliance-heavy infrastructure, or anything that's been burned by dirty space before - that transparency has real operational value.

Platform breakdown

IPXO

The established option. Large inventory, multi-RIR coverage (RIPE, ARIN, APNIC), automated RPKI/ROA setup, and abuse handling baked into the platform. The self-service dashboard is functional and the delivery pipeline is reliable.

Technical notes:

ROA creation is automated on delivery
LOA issued within the platform
Abuse complaints routed through IPXO's own abuse desk
5% platform fee on transactions
No buy/sell capability - leasing only

Where it shows its limits: if you're working exclusively in the RIPE NCC space and need subnet-level provenance, the managed pool model gives you less visibility than a direct marketplace. And if you need to monetize your own address space rather than just access inventory, IPXO isn't the right fit.

IPbnb

A direct marketplace built specifically for the RIPE region, covering leasing, buying, selling, and transfers. IP owners list their own subnets; you transact directly with them. The full compliance layer - RPKI/ROA, LOA, ASN registration, IP reputation checks - is handled within the platform.

Technical notes:

ROA and RPKI configuration included on onboarding
Subnet reputation check before listing approval
LOA documentation provided per transaction
Subnets from /24 upward
Onboarding typically within 24 hours of verification
Transparent, listed fee structure

The direct marketplace model means you can verify subnet history before committing. For teams that have dealt with the fallout of leasing space with a bad reputation history, that pre-transaction visibility is worth something concrete.

InterLIR

RIPE NCC-registered marketplace and broker, with ARIN, LACNIC, and APNIC coverage as well. Supports leasing, buying, and selling, with blocks from /24 to /16.

Technical notes:

Incoming blocks scanned against 24+ blacklists at onboarding
Ongoing abuse monitoring post-delivery
ASN registration and sponsoring ORG services available
Useful for operators without their own LIR membership
Delivery typically within 24 hours
Fee structure not publicly listed - requires direct inquiry

The blacklist scanning at onboarding is genuinely useful for teams where IP reputation is a hard requirement. The sponsoring ORG service is a practical option if you're operating without full LIR membership and need someone to handle the RIPE NCC relationship.

IPv4.Global

The original secondary market platform, operated by Hilco Streambank. Covers ARIN and RIPE primarily. Three transaction modes: online auction marketplace, privately negotiated brokered sales, and a leasing hub.

Technical notes:

Auction-based pricing - final cost not known upfront
Private brokered sales available for large blocks (/20 and above)
Leasing hub operates alongside the buy/sell marketplace
Handles transfer paperwork across ARIN and RIPE
Longest track record in the market for completed transfers

The auction mechanism introduces pricing uncertainty that complicates procurement planning - not ideal if you're working against a fixed infrastructure budget. Where it shines is large-block transactions where competitive bidding can recover significantly more value than a fixed listing price.

Prefixx

Boutique broker operating since 2018, covering RIPE, ARIN, APNIC, and LACNIC. No-win-no-fee model, with escrow on all transactions.

Technical notes:

White-Glove service includes geolocation updates, rDNS management, abuse complaint handling
Long-term lease arrangements supported
Not a self-service platform - broker-managed process
Useful for complex transactions or operators without internal NOC capacity to handle the compliance layer

If your team doesn't have the bandwidth to manage geolocation updates, rDNS setup, and abuse handling in-house, having those included as standard in the lease package removes a real operational burden. The trade-off is that you're working through a broker rather than transacting directly.

LogicWeb

Direct IP leasing provider since 2004. Owns and manages its own inventory - over 500,000 addresses. Month-to-month, no contracts, no setup fees.

Technical notes:

Same-day LOA delivery
WHOIS and geolocation updates included
RPKI/ROA setup on non-legacy subnets
No marketplace - inventory is proprietary
No buying or selling capability
Client base includes major VPN providers

The no-contract monthly model is genuinely flexible for short-term provisioning needs or when you're not sure how long you'll need the space. The constraint is inventory ceiling - you're limited to what LogicWeb owns, and there's no path to acquisition if you need to permanently add to your address space.

Quick comparison

Platform	Model	RIPE focus	Buy / Sell	ROA/RPKI	Fee model
IPXO	Managed pool	Multi-RIR	No	Automated	5% platform fee
IPbnb	Direct marketplace	Primary	Yes	Included	Transparent, listed
InterLIR	Marketplace + broker	Yes	Yes	Yes	Not public
IPv4.Global	Auction + broker + leasing	Yes	Yes	Yes	No hidden fees
Prefixx	Broker	Yes	Yes	Via White-Glove	No-win-no-fee
LogicWeb	Direct provider	No	No	On non-legacy	No setup fee

Choosing based on your operational profile

You need clean space fast with a known reputation history - IPbnb or InterLIR. Both run reputation checks before subnets are listed or approved. Direct marketplace visibility lets you verify before committing.

You're provisioning month-to-month with no long-term plan - LogicWeb. No contracts, same-day LOA, flexible exit. Straightforward.

You have a large block to sell and want market pricing - IPv4.Global. The auction mechanism is the most efficient way to find market rate on a /16 or larger.

You need address space but don't have LIR membership - InterLIR. The sponsoring ORG service covers that gap without requiring you to set up your own LIR.

You want to offload compliance overhead entirely - Prefixx. rDNS, geolocation, abuse handling - all managed for you as part of the lease.

You're building on RIPE infrastructure and want full transaction capability - IPbnb. Leasing, buying, selling, and transfers on one platform, with the RPKI and ROA layer handled.

The IPv4 leasing market has matured considerably. The right platform depends less on brand recognition and more on which operational model fits how your infrastructure team actually works.

For a full breakdown including platform-by-platform analysis, pricing model comparison, and a detailed FAQ, read the original article on the IPbnb blog: https://ipbnb.com/blog/top-5-ipxo-alternatives

Stop Treating IPv4 as Technical Debt – Here's What the 2026 Data Actually Shows

Artem Kohanevich — Thu, 12 Mar 2026 11:16:54 +0000

There's a belief that's quietly distorting infrastructure decisions across the industry: that running IPv4 in 2026 means you're behind.

It doesn't. And the data makes a strong case for the opposite view.

Let's go through what's actually happening — not in theory, but in production networks running real workloads today.

First, the Numbers Nobody Leads With

Before diving into comparisons, here's the state of play:

IPv4 share of global internet traffic:     ~60%
Fortune 500 companies IPv4-primary:        76%
Enterprise IPv6 adoption:                  32%
IPv6 migrations that complete successfully: 21%
IPv4 address price (2026):                 $50–65/IP
IPv4 address price (2011):                 $5/IP
Annual IPv4 transfer market volume:        $1.2B

This is not a protocol in decline. This protocol has outperformed predictions of its imminent replacement for fifteen years.

What Makes IPv4 and IPv6 Fundamentally Different

The core distinction is address space. IPv4 uses 32-bit addresses (192.168.1.1) — about 4.3 billion total. IPv6 uses 128-bit addresses (2001:db8::1) — 340 undecillion total, which is a number so large it's practically meaningless to visualize.

IPv4 exhausted its pool at the RIR level years ago. ARIN and RIPE no longer issue fresh allocations. What that created wasn't a crisis — it created a transfer market. Addresses change hands, get leased, get reclaimed and reallocated. The market works.

IPv6 addresses are free from registries. That sounds like a straightforward win. But free allocation and free migration are very different things.

Latency: The Counterintuitive Finding

IPv6 should be faster. The theory is solid: no NAT translation overhead, fixed-length headers that routers process more efficiently, cleaner end-to-end routing without middleboxes. On paper, it wins.

In production, it often doesn't.

Data from LinkedIn Engineering, Akamai, and Cloudflare consistently show IPv4 delivering lower latency — typically 5–15ms — in real-world deployments. A streaming platform that ran a controlled IPv6 test observed a 12% higher buffering rate during peak hours. The culprit: IPv6 BGP path optimization isn't as mature, so traffic routes through suboptimal peering points.

The reason IPv4 outperforms comes down to time. Forty years of routing table tuning, CDN infrastructure built around IPv4 peering agreements, and hardware pipelines optimized for IPv4 packet processing — none of that transfers automatically to IPv6.

For most web applications, 10ms won't move the needle. For gaming backends, financial trading infrastructure, or live video delivery, it can.

Security: Protocol Features vs. Operational Reality

IPv6 ships with IPsec as a built-in capability. That's legitimately useful. But the "IPv6 is more secure" argument usually stops there, which is where it starts to mislead.

Security posture in practice depends on three things: tooling coverage, threat intelligence quality, and how fast your team can respond. On all three, IPv4 has a significant lead in 2026.

Security tool IPv4 support:          98%
Security tool IPv6 support:          68%

IPv4 threat intelligence sources:    80+
IPv6 threat intelligence sources:    8–12

Mean time to resolve IPv4 incident:  ~45 min
Mean time to resolve IPv6 incident:  ~78 min

The MTTR gap — 45 minutes versus 78 minutes — isn't a reflection of IPv6 being insecure. It's a reflection of SIEM rules, IDS signatures, firewall policies, and threat feeds that have been iterated on for decades for IPv4. Your team's troubleshooting instincts are IPv4-native. Your vendors' default detection logic is IPv4-first.

NAT is worth a separate mention. It was designed as a workaround for address scarcity, and IPv6 advocates rightly point out it breaks end-to-end connectivity. But NAT also hides internal topology from external observers, limits exposure of internal hosts, and adds an implicit segmentation layer. IPv6's end-to-end model is architecturally cleaner — it also removes that implicit protection. Neither is wrong. Both require deliberate compensating controls.

Compatibility: Where IPv6 Adoption Actually Stalls

The adoption numbers look reasonable at a global level — around 45–50% by Google's measurement. But break it down by sector and the picture changes:

Mobile networks:          72% IPv6
Hyperscalers (AWS/GCP):   82% IPv6
ISPs:                     67% IPv6
Enterprise:               32% IPv6
SMB:                      17% IPv6
Email infrastructure:     28% IPv6
Industrial IoT:           21% IPv6

The services that haven't moved are the ones with the highest compatibility stakes. Payment processors are mostly IPv4-primary — run IPv6-only and you risk breaking checkout. About 85% of spam filtering and IP reputation systems are built around IPv4 behavior, which creates real deliverability risk for IPv6-originated email. 72% of IoT devices manufactured in 2026 are IPv4-only because adding IPv6 support increases unit cost with no operational payoff for most deployments.

This is why 95% of IPv6 deployments run dual-stack (APNIC). Not because engineers are conservative — because going IPv6-only breaks things that matter.

The Real Cost of IPv6 Migration

Here's a /22 block (1,024 addresses) cost comparison, done honestly:

Lease IPv4

Rate:           $0.40–0.55/IP/month
Monthly cost:   $410–$563
Annual cost:    $4,920–$6,756
5-year total:   $24,600–$33,780

Buy IPv4

Purchase price (today):    $51,200–$66,560
Projected value (2030):    $71,680–$92,160
Sublease idle capacity to offset holding costs

Migrate to IPv6

Infrastructure work:       ~$180,000
Team training:             ~$25,000
Ongoing dual-stack OpEx:   ~$18,000/year
5-year total:              ~$295,000

Note: you still run IPv4 in parallel for compatibility

Leasing IPv4 costs less than migrating to IPv6 for 7–9 years under these numbers. That's not an argument that IPv6 migration is never worth it — it's an explanation for why 64% of organizations report they can't build a business case for it right now.

The opportunity cost is also real. $295,000 over five years is engineering capacity, product features, or infrastructure redundancy that doesn't get built.

Operational Overhead: The 2 AM Factor

Average resolution time for network issues:

IPv4:   ~23 minutes
IPv6:   ~52 minutes

The gap has a straightforward explanation. ping, traceroute, and tcpdump output for 192.168.1.1 is instantly readable. For 2001:0db8:85a3::8a2e:0370:7334, you're reading more carefully and making more errors. IPv4 documentation density — Stack Overflow answers, vendor KB articles, known failure modes — dwarfs IPv6 equivalents. Junior engineers reach IPv4 proficiency in about 3 months; IPv6 takes 6–9 months to reach equivalent comfort.

Dual-stack doubles the management surface: two routing tables, two firewall rule sets, two address schemes. It's workable, but the overhead is real and shows up in team capacity.

IPv6 is the clear choice when:

You're building mobile carrier infrastructure at scale
A government contract explicitly requires it
You're doing greenfield data center buildout with zero legacy constraints
Your IoT deployment exceeds 100K devices and address efficiency matters

Adoption Trajectory: The Honest Timeline

Global IPv6 adoption (2026):         ~45–50%
Annual growth rate (2015–2018):      ~8%
Annual growth rate (2023–2026):      ~2–3%

Projected 80% adoption:              2040–2045
Projected full transition:           2045–2050

The growth curve has flattened. The urgency case for rapid IPv6 migration relies on a trajectory that no longer exists. Full transition is measured in decades, not years. Dual-stack operation is the normal state of internet infrastructure through at least 2040.

Five Persistent Myths

"IPv6 is faster in production" — The theory holds. Production data from multiple independent sources says otherwise. Forty years of optimization isn't overcome by a cleaner protocol spec.

"IPv6 is inherently more secure" — Built-in IPsec is a real feature. It doesn't compensate for immature tooling, limited threat intel, and slower incident response across the security ecosystem.

"IPv4 addresses are unavailable" — RIR exhaustion is real. A $1.2B annual transfer market with 52 million recovered and reallocated addresses since 2020 suggests availability isn't the problem.

"Migration is straightforward" — Only 21% of started IPv6 migrations complete successfully. The failures aren't from lack of effort — they're from unexpected compatibility issues with critical business systems.

"IPv6 dominance is imminent" — Growth has slowed to 2–3% annually. Current projections push 80% adoption to 2040–2045. Infrastructure planning based on five-year IPv6 dominance is planning based on a prediction that has been wrong for fifteen years running.

What Good IP Strategy Looks Like in 2026

Audit actual requirements — Calculate the public IPs your services genuinely need, not theoretical maximums. NAT and CGNAT cover a lot of ground.
Lease for flexibility, buy for long-term baseline — Lease if your growth trajectory is uncertain or you need fewer than 1,024 addresses. Buy if you have a 10+ year horizon and want to treat it as infrastructure capital.
Enable IPv6 on public endpoints — Web, API, and CDN layers are the right place to start. Low risk, reaches mobile users, monitors actual IPv6 traffic share without touching critical internal paths.
Keep IPv4 on critical paths indefinitely — Email, payments, internal services, and anything with a security SLA. Until IPv6 traffic exceeds 90% of your total — which won't happen soon — there's no operational case for removing IPv4 from these paths.
Verify IP reputation before provisioning — Leased or purchased addresses with abuse history will cost more in deliverability and security remediation than you saved acquiring them cheap.

What does your current IPv4/IPv6 split look like in production? Especially curious about teams running dual-stack — what's actually moving over IPv6 versus staying on IPv4.

Read the full IPv4 vs IPv6 analysis on the IPbnb blog

IPv4 Leasing Without Losing Control

Artem Kohanevich — Mon, 09 Mar 2026 09:10:14 +0000

IPv4 leasing often gets dismissed as too risky by the people who actually hold the blocks. The concern usually sounds like this: "What if I can't get it back?"

Here's the short answer: you can. Here's the structural explanation of why.

Ownership lives in the registry. Routing lives in the config.
When you hold an IPv4 block, what you actually hold is an RIR registration — a WHOIS record that names your organization as the resource holder. That record does not update when someone else starts routing your space. BGP announcements change. Your registration does not.

A lease grants routing authority. That's it. The lessee can originate traffic from your addresses for the duration of the agreement. They cannot sublease without authorization, hold the block past expiry, or acquire any RIR standing over the space. RIPE, ARIN, and APNIC classify leasing as a utilization arrangement — not a transfer event.

The two controls that actually matter

LOA (Letter of Authorization) — the document you sign to allow routing. No valid LOA, no routing. Revoke it and the upstream provider pulls the announcement, typically within 24–72 hours. This requires zero cooperation from the lessee.

RPKI / ROA — you cryptographically authorize which ASN can originate your prefix. Revoke the ROA and RPKI-validating routers reject the announcement at the network level, not just contractually. This is the part most owners don't know about — it's a structural control, not just a legal one.
What reclaiming actually looks like

Revoke or expire the LOA

Update the ROA to deauthorize the lessee's ASN
Confirm de-announcement via looking glass
Run blacklist checks before reuse

Full sequence: typically two to five business days.

The bigger picture

IPv4 space is a finite, appreciating asset. Blocks that sit idle are a capital efficiency problem. The protections described above exist precisely because the market has matured around lessor interests — they're not theoretical, they're the operational baseline.

Full breakdown with contract term requirements and reputation management, you'll find here.

The IPv4 Secondary Market Is Mature. The Tooling Hasn't Caught Up

Artem Kohanevich — Thu, 05 Mar 2026 03:21:31 +0000

I've spent my career in infrastructure and cloud. I know what it costs to scale, what it means to plan capacity under pressure, and how much operational complexity lives inside decisions that look simple on paper.

When my co-founders – who have spent years in the IPv4 market as address holders, operators, and investors – described the state of the tooling, it was immediately recognisable. A fragmented market, opaque pricing, incomplete block data, and processes that create friction where there should be clarity.

That's the problem IPbnb is built to solve. Last month, we quietly launched

Why "quietly"?

Because the IPv4 market runs on trust. We didn't want to make noise before the platform was ready to back it up. We ran a beta period, collected real friction data, fixed what needed fixing, and opened for business when we were confident the product met the standard we'd set for ourselves.

What the market actually needs

Most platforms in this space give you a CIDR block and a price. That's not enough information to make a sound allocation decision. You need block history. Routing status. Abuse record indicators. RPKI status. Reputation context.

IPbnb listings include all of it – because that's what we wanted to see on the other side of the transaction.

There's also a market education problem worth naming. Many IPv4 address holders don't realise their blocks are income-generating assets. A lot of operators don't know that leasing is a practical alternative to acquisition. Part of what we're building is the context that helps both sides make better decisions.

The technical reality of IPv4 in 2026

IPv6 adoption is real and ongoing. It's also not replacing IPv4 in most production environments anytime soon. Dual-stack is the operational norm. That sustained coexistence is what keeps the secondary IPv4 market structurally relevant – and it's the market we're building for.

One thing I'm particularly proud of

We kept support human. IPv4 transactions have real complexity – transfer documentation, compliance edge cases, block history questions. When you contact IPbnb, you reach someone with actual market context. That was a deliberate product decision, not an afterthought.

If you're managing IPv4 capacity – leasing, acquiring, or monetising idle space – the catalogue is live.

The IPv4 Leasing Mistakes That Will Cost You Thousands

Artem Kohanevich — Fri, 12 Dec 2025 09:28:20 +0000

Every month, I hear the same story from different infrastructure teams: "We thought IPv4 leasing would be straightforward. It wasn't."

The pattern is predictable. A company needs IP addresses quickly. They find a provider, sign a contract, and start routing traffic. Then reality hits—blacklisted IPs, rejected BGP announcements, surprise fees, or emergency capacity issues.

The frustrating part? Almost all of these problems are preventable.

Here are the five mistakes that cause 90% of IPv4 leasing failures—and exactly how to avoid each one.

Mistake #1: The Reputation Blindspot

Approximately 70% of first-time renters never check IP reputation before signing. They're essentially buying used infrastructure without knowing its history.

What they discover too late:

IPs are on major blacklists (Spamhaus, SORBS, Barracuda)
Addresses flagged for past botnet activity or fraud
Negative trust scores from reputation engines
Historical association with spam campaigns or proxy abuse

The damage: Email delivery blocks, service rejections, weeks of cleanup work.

Your Pre-Lease Audit Checklist

Before signing anything, verify:

Blacklist status — Scan across 80+ DNS-based blacklists and RBLs. Free tools: MXToolbox, Spamhaus checker, IPVoid.

Abuse history — Pull historical reports from Spamhaus SBL/CSS, UCEPROTECT, Cloudmark. Check AbuseIPDB for crowd-sourced intelligence.

Fraud scores — Use IPQS or FraudGuard to assess spam/fraud risk ratings.

Past usage patterns — Was this block previously used for VPN services, web hosting, mobile networks, or residential proxies? Each has different reputation implications.

Neighboring addresses — IP pollution spreads across subnets. Check adjacent ranges for issues that might contaminate yours by association.

What Your Provider Should Guarantee

Don't accept vague promises. Demand specific protections:

Comprehensive reputation report provided automatically (not on request)
Written guarantee that addresses are clean
30-60 day quarantine period for newly assigned blocks
Continuous reputation monitoring throughout lease term

The best providers run proactive monitoring systems that automatically rotate out problematic addresses before they ever reach clients. This eliminates roughly 90% of reputation risks upfront.

Mistake #2: The LOA Gap

A Letter of Authorization (LOA) is the document that proves you have legal right to announce and route specific IP addresses.

Without it, you're dead in the water.

Your ISP will refuse to announce the subnet. Upstream providers will block BGP sessions. Cloud BYOIP programs (AWS, Azure, GCP) won't accept the addresses. Switching upstream networks becomes impossible.

What Makes a Valid LOA

A legitimate LOA must contain:

Legal name of IP holder (exactly as it appears in registry)
Authorized ASN that will announce the prefix
Precise CIDR notation (e.g., 203.0.113.0/24)
Authorization period with clear validity dates

Missing any element? You're sending it back for revision while your infrastructure plans sit on hold.

The Correct Sequence

Request LOA immediately after signing lease (not when you're ready to deploy)
Verify subnet and ASN match your actual configuration
Forward to ISP/cloud provider as soon as received
Wait for route object creation in IRR (Internet Routing Registry)
Only then announce your prefix

Red Flags That Scream "Walk Away"

Provider refuses to issue LOA or makes excuses about delays
LOA validity period shorter than lease term
No clear revocation procedure in contract
Provider insists you pay before receiving LOA

The protection rule is simple: Get the LOA before making your first payment, or get a written guarantee it will be delivered within 24-48 hours of payment.

Mistake #3: The RPKI Blindspot

More than 60% of companies leasing IPv4 never set up RPKI (Resource Public Key Infrastructure). They configure routers, announce prefixes, and assume everything's secure.

It's not.

What You're Actually Risking

Without RPKI, your routes are vulnerable to:

Accidental BGP leaks — Misconfigured routers suddenly announcing your prefixes globally

Malicious hijacking — Bad actors deliberately redirecting your traffic to intercept or manipulate it

Automatic rejection — Growing number of major networks drop BGP prefixes without valid Route Origin Authorizations (ROAs)

This isn't theoretical. Major Tier-1 providers are implementing policies that treat invalid/missing ROAs as rejection signals. No cryptographic verification = no route propagation.

How RPKI Works (Simplified)

RPKI creates a cryptographic binding between:

Your ASN (Autonomous System Number)
The specific IP prefix you're announcing
Maximum prefix length allowed

A Route Origin Authorization (ROA) is the signed object proving this binding.

Example ROA:

ASN: AS64512
Prefix: 192.0.2.0/24
Max Length: 24
Trust Anchor: ARIN

When your BGP announcement goes out, other networks validate it against this ROA. Match = accepted. Mismatch = flagged or dropped.

What Your Provider Should Handle

You shouldn't need to become an RPKI expert. Your provider should offer:

Hosted RPKI services (they manage certificates)
ROA creation within 24 hours of activation
Auto-renewal (certificates expire)
Quick ROA updates when routing configuration changes

If they can't provide this, their infrastructure hasn't caught up with modern routing security standards.

Verification Tools (All Free)

RIPE RPKI Validator — Clear validation status view
NLnetLabs Routinator — Open-source validator you can self-host
BGPStream — Real-time prefix monitoring

Five minutes with any of these tells you whether your routes are protected or vulnerable.

Critical Configuration Details

When setting up ROAs:

Use exact prefix matches (if announcing /24, set maxLength to 24)
Update ROA before making any routing changes
Coordinate ROA revocation when lease ends

RPKI isn't optional anymore. It's basic routing hygiene.

Mistake #4: Block Sizing Math Gone Wrong

Teams consistently fall into two traps:

Over-leasing — Paying for capacity you'll never use. A /22 (1,024 IPs) when you only need 300 wastes $15,000+ annually.

Under-leasing — Hitting capacity constraints within months, then scrambling for emergency expansion with fragmented non-contiguous ranges.

Both are avoidable with proper sizing calculations.

The Working Formula

Required IPs = (Current demand × 1.3-1.5 growth factor) + 10-20% operational overhead

Breaking it down:

Current demand: What you're using right now
Growth factor: Expansion over 12-24 month lease term
Overhead: Routing requirements, redundancy, testing environments

Real-World Examples

Small ISP (500 subscribers):

Current: 500
Growth factor: 1.4× = 700
Overhead: +15% = 805 total
Block size: /22 (1,024 IPs)

VPN Provider (2,000 concurrent users):

Current: 2,000 users
NAT ratio: 5:1 = 400 public IPs needed
Growth factor: 1.2× = 480
Block size: /23 (512 IPs)

Ecommerce Platform (50 servers, 3 PoPs):

Current: 50 servers
Infrastructure overhead: 1.2× = 60
Growth buffer: +20% = 72
Redundancy multiplier: ×3 PoPs = 216 total
Block size: /24 (256 IPs)

Standard CIDR Sizes and Costs

/24 (256 IPs): $500-800/month — Small ISP, SaaS
/23 (512 IPs): $900-1400/month — Medium ISP, VPN
/22 (1,024 IPs): $1,600-2,800/month — Large ISP

Note: /24 is minimum for global BGP announcements.

The Smarter Scaling Strategy

Instead of over-provisioning upfront, use phased approach:

Phase 1 (Months 1-6): Start with /24
Phase 2 (Months 7-12): Expand to /23 if needed
Phase 3 (Year 2+): Move to /22 based on actual utilization

This typically reduces total spend by 25-30% while maintaining flexibility.

Common Sizing Mistakes

Teams miscalculate because they:

Base sizing only on current active users
Forget routing, NAT, and infrastructure overhead
Ignore workload specifics (VPN concurrency, CGNAT strategies, burst patterns)
Skip the contingency buffer

Use actual demand + 20-30% buffer, apply expected growth, round to nearest standard CIDR. Validate with subnet calculator.

Mistake #5: The Contract Skimming Problem

Roughly 80% of companies never fully read their IPv4 leasing contracts. They check price, verify block size, sign, and move on.

Then months later they discover what they actually agreed to. By then, damage is done.

What Actually Matters

Lease duration and renewal:

Initial term (typically 6-36 months)
Renewal structure (opt-in vs. auto-renewal)
Notice period for cancellation (90 days is excessive)
Price adjustment clauses (5-10% annual increases compound)

Termination rights:

Lessor should give 90+ days notice for revocation
Lessee should have 30-60 days termination right
Early termination fees shouldn't exceed 1-2 months' rent

Hidden fees that inflate costs:

Setup: Should be free (typical: $0-500)
LOA: Should be free (typical: $0-200)
RPKI management: Should be included (typical: $0-100/mo)
Early termination: Max 1-2 months (typical: 1-6 months)

A seemingly affordable $800/month lease can become $1,200/month with all extras.

Technical support commitments:

IP replacement if blacklisted (not your fault)
LOA/ROA delivery within 24-48 hours
Response time commitment (4 hours excellent, 24 hours acceptable)
Uptime guarantee (minimum 99.9%)

Vague language like "best effort support" means you're on your own during outages.

Restriction clauses:

Sub-leasing prohibitions (reasonable)
Geographic announcement limitations (may not fit your needs)
Use-case restrictions on traffic types
Broad "abuse" definitions (could enable unfair termination)

The Protection Checklist

Before signing:

Read entire contract (not just pricing page)
Verify auto-renewal terms and notice periods
Check for hidden fees beyond monthly rate
Confirm technical support commitments are specific
Review restriction clauses for operational conflicts
Get legal review for enterprise/multi-year leases

Getting It Right From the Start

These five mistakes—reputation blindness, missing LOA, skipped RPKI, wrong block size, unread contracts—cause most expensive IPv4 leasing failures.

They're not edge cases. They're predictable traps that ambush unprepared teams.

The economics: A $500/month lease can become a $15,000 problem if you sign blind. Four hours of focused prep prevents hundreds of hours firefighting.

Your Pre-Lease Checklist

Before signing any IPv4 lease:

✓ Run comprehensive reputation checks on all IPs
✓ Verify LOA delivery guarantee (or get it before payment)
✓ Confirm provider offers hosted RPKI with ROA auto-renewal
✓ Calculate proper block size using demand + growth + overhead
✓ Read full contract including all fee schedules and restrictions
✓ Verify technical support commitments are specific and measurable

The Right Provider Makes All the Difference

What used to take weeks of manual work can fit into a single work session when your provider handles:

Pre-vetted blocks with reputation guarantees
Automated LOA issuance
Built-in RPKI management
Clear, human-readable contracts
Proper sizing consultation

Evaluating IPv4 leasing providers? ipbnb.com was built specifically to eliminate these common failure points—pre-vetted blocks, automated LOA/RPKI, transparent contracts, and proper sizing guidance.

What mistakes have you encountered in IPv4 leasing? How did you solve them? Share your experience in the comments.