DEV Community: Artem Kohanevich

IP Transit: What Actually Happens Before Your Network Reaches the Internet

Artem Kohanevich — Wed, 08 Jul 2026 13:48:43 +0000

You can have racks, routers, servers, switches, and clean configs — but none of that makes your network reachable from the public internet by default.

For that, you need IP transit.

IP transit is the service that connects your autonomous system to the rest of the internet. Your upstream provider carries your traffic to other networks and announces your prefixes so return traffic knows how to find you.

In other words: transit is what turns your network from an isolated island into part of the global routing system.

How IP Transit Works

At the technical level, IP transit usually looks like this:

Your router connects to the transit provider’s router.
You establish a BGP session.
The provider sends you routes, often the full internet routing table.
You announce your own prefixes.
The provider propagates those announcements to its peers and upstreams.

That last step matters a lot. Sending traffic out is only half the job. If your prefixes are not announced correctly, the rest of the internet will not know how to send traffic back.

For IPv4, the practical minimum is usually a /24, because smaller prefixes are commonly filtered.

Transit vs Peering

Transit and peering are related, but they solve different problems.

IP transit gives you reachability to the whole internet. You pay a provider, usually per Mbps, and they carry your traffic globally.

Peering lets you exchange traffic directly with another network, often through an internet exchange. It is great for cost and latency when you have enough traffic with specific networks, but it does not replace transit for most operators.

The common path is simple:

Start with transit. Add peering later when traffic volume makes it worth it.

What You Need Before Buying Transit

Before a transit provider can bring you online, you typically need:

An ASN to identify your network in BGP
A BGP-capable router
An upstream/transit agreement
IPv4 and/or IPv6 address space you are allowed to announce
Correct routing objects and, ideally, RPKI ROAs

The first three are usually straightforward.

IPv4 is where things often slow down.

The IPv4 Problem

IPv6 is available. IPv4 is not.

In the RIPE region, the free IPv4 pool has been exhausted for years. If you need IPv4 today, your main options are:

Wait for allocation
Buy space on the transfer market
Lease IPv4 blocks

Each option has trade-offs.

Waiting can take a long time. Buying requires upfront capital. Leasing gives operators a faster way to get announceable address space without locking themselves into a large purchase.

For hosting providers, ISPs, CDNs, and infrastructure teams, this can be the difference between launching now and waiting months.

Pricing Is Not Just “$/Mbps”

IP transit pricing is usually quoted per Mbps per month, but the number depends on context:

Commit size
Location
Provider tier
Billing model
SLA
DDoS protection
Route quality
Redundancy

A low price in a major hub at 100 Gbps does not mean the same price exists for a small commit in a less connected market.

Also, cheaper transit is not always better transit. Bad routes, weak support, or poor visibility can cost more than the savings.

Practical Takeaway

IP transit is the foundation of public internet reachability.

To bring a network online, you need more than bandwidth. You need BGP, an ASN, upstream connectivity, route propagation, and address space that the global internet will accept.

And in many real deployments, IPv4 becomes the bottleneck — not the router, not the contract, and not the cross-connect.

So plan for IPv4 early. If your network depends on it, your rollout timeline probably does too.

Full version: What Is IP Transit?

IPv8: A Beautiful Spec With a Threat Model Problem

Artem Kohanevich — Tue, 30 Jun 2026 13:26:20 +0000

I work in the IPv4 address market, which means a new addressing proposal hits my inbox the moment it goes public. Most are noise. draft-thain-ipv8, submitted to the IETF in April 2026, is more interesting than most - not because it'll ship (it won't), but because its architecture is a clean case study in how a well-intentioned spec can accidentally specify a surveillance platform. Let's read it like engineers.

The naming collision (skip if you already know)

Three unrelated things share the name "IPv8":

py-ipv8 - a working P2P overlay from TU Delft over UDP, using Curve25519/Ed25519 identities. Nothing to do with TCP/IP replacement. The name is a joke about IPv6 adoption.
PIP (historical IPv8) - Paul Francis, 1992, RFC 1621/1622. Lost the IPng race to SIPP because variable-length addresses were murder in hardware. Historic since 2016.
draft-thain-ipv8 - the 2026 individual submission everyone is arguing about. This post is only about that one.

The addressing model

IPv8 defines a 64-bit address laid out as r.r.r.r.n.n.n.n - eight octets:

+-------------------+-------------------+

| ASN (32 bits) | Host (32 bits) |

+-------------------+-------------------+

r.r.r.r n.n.n.n

The high 32 bits carry an ASN; the low 32 bits are a host address with IPv4 semantics. The backward-compatibility hook is the part worth pausing on:

if (asn_prefix == 0.0.0.0) {

// treat as legacy IPv4, standard rules apply

}

So 0.0.0.0.a.b.c.d is IPv4. Clean idea on paper.

The consequences are large:

Each ASN holder gets 2^32 host addresses (~4.3 billion). Exhaustion stops being a meaningful constraint at any org scale.
The global routing table - currently 900k+ prefixes with no structural ceiling - gets capped near one entry per ASN (~175k today), because deaggregation below /16 is forbidden. That's the architecturally bounded BGP table people have wanted for years.
Header cost: +8 bytes vs IPv4 (source and destination each grow 32 → 64 bits). TTL, Protocol, Flags, Checksum are unchanged.

This is the genuinely attractive half of the draft. If you've ever stared at the routing table growth curve and winced, the bounding mechanism is hard not to like.

The Zone Server

Here's where it stops being an addressing proposal and becomes a platform. IPv8 mandates a per-segment Zone Server, active/active, that consolidates basically everything:

Service	Role
DHCP8	Address assignment
DNS8	Resolution
NTP8	Time
OAuth8	Authentication (OAuth2 + JWT)
WHOIS8	Route validation
ACL8	Access control
NetLog8	Telemetry / logging
XLATE8	IPv4 ↔ IPv8 translation

A device joins, fires one DHCP8 request, and gets every service endpoint in a single reply. Auth is JWT validated locally, no round trip to an external IdP. From an ops perspective, the "one box, one request" story is genuinely elegant.

Routing decisions run on a 32-bit Cost Factor, accumulated from seven inputs: RTT, packet loss, congestion window state, session stability, link capacity, economic policy, and great-circle distance as a speed-of-light floor. That last one is sharp - any path claiming to beat the physics floor is flagged as anomalous by definition. I like it as a design instinct.

Transition avoids a flag day via 8to4 tunnelling encapsulated over HTTPS, so it slips through firewalls without per-box config.

Where it breaks (the ordinary objections)

The community pushback is fair and mostly consistent:

No process. IPv6 came out of a multi-year working-group bake-off (CATNIP, TUBA, SIPP). This is a solo I-D with no WG, no sponsor, and a datatracker page that says outright it isn't endorsed. It expires Oct 19, 2026 absent adoption.
Layering violation. OAuth2/JWT is Layer 7 logic shoved into Layer 3. Access switches, industrial controllers, and basic routers aren't built to do application-level authz at line rate. I'm softer on this than most - hardware refreshes on 7-10 year cycles regardless, and ISPs ship ~180M CPE units a year - but "the silicon could eventually do it" is not the same as "the ecosystem will require it."
The Version field. Every ASIC checks the IP Version field and drops anything that isn't 4 or 6. A Version 8 packet dies at hop one. XLATE8 is the answer - legacy devices behind an IPv8 gateway emit plain IPv4 and never send a Version 8 packet - but the whole transition story rests on XLATE8 being as transparent in production as the spec claims, and nobody has tested that.
Provenance. GPTZero reportedly flagged ~76% of the text as likely AI-generated. The author acknowledges AI assistance. The concern isn't the tool; it's whether the design reflects lived operational experience.
Timing. Two weeks before the draft argued IPv6 had failed, Google's IPv6 traffic crossed 50% for the first time. The premise aged badly in real time.

The part the technical critique mostly misses

All of the above is solvable in principle. The thing that isn't solvable by iteration is what the Zone Server becomes once you treat it as a threat model instead of a feature list.

Walk the mechanisms as an adversary would:

DNS8 is not swappable. Today, DNS censorship is the weakest control - flip your resolver to 1.1.1.1 and you're out. Under IPv8, resolution lives in the mandatory egress box. There is no "use another resolver." Unresolved destination → dropped locally, before the packet ever leaves your segment.
WHOIS8 is a registry-level kill switch. Every destination ASN must be present and valid in WHOIS8 or the packet is dropped, and unvalidated routes are never installed at the BGP8 level at all. So censorship stops requiring DPI or border filtering - pressure the registry, remove the record, and the target is unreachable at the protocol layer everywhere IPv8 runs. No record, no route, no reachability.
OAuth2/JWT ends anonymous connections by design. Every managed device authenticates before its first packet. The stated goal is killing malware C2 - legitimate. The side effect is that the anonymity Tor and VPNs rely on stops existing at the IP layer, and whoever holds the identity infrastructure can attribute every connection.
NetLog8 makes logging mandatory. Real-time telemetry at every Zone Server - every auth, connection, and policy hit, timestamped. "Observability for operators" and "comprehensive surveillance record for a state actor" are the same dataset.

And the spec is silent exactly where it shouldn't be: no governance model for who runs the Zone Server, no oversight on WHOIS8 record removal, no judicial-review path for ACL8 rules or JWT revocation. The entire thing assumes good-faith operators. That assumption does not survive contact with a meaningful chunk of the world's governments.

We've seen this shape before. Huawei's 2020 "New IP" pitch to the ITU-T proposed per-packet, authenticated, government-controllable filtering at the network layer and was rejected by the IETF, ISOC, and several governments precisely because it baked control into the protocol. IPv8 reaches a structurally identical endpoint through different mechanisms - apparently without the author intending it. Intent doesn't edit the architecture.

The clean way to put it: today a national firewall is expensive overlay infrastructure fighting a protocol built for openness. IPv8 inverts the relationship. The authenticated, logged, gateway-validated network becomes the base layer, and the open internet becomes the overlay you have to fight to reach.

Why an IPv4 trader cares

Short term: nothing. The draft expires without WG adoption, no vendor or RIR backs it, and IPv4 leasing is unaffected.

Longer term, two things are worth watching:

The addressing logic. If a future, better-sponsored proposal inherits the "each ASN holder gets a giant block" model while keeping IPv4 backward compatibility, it attacks both pillars the secondary IPv4 market rests on - scarcity and IPv6 transition cost - simultaneously. That's speculative and distant, but it's the scenario to model.
The control pattern. Consolidating resolution, identity, route validation, and logging into one mandatory platform will resurface in proposals that do have momentum. When it does, the only question that matters is who controls the platform.

Takeaway

draft-thain-ipv8 is not going to standardize. But it's a useful artifact: it proves you can bound the BGP table and unify network management at the protocol layer - and it proves that the same consolidation, done without a governance model, hands you a censorship substrate for free. The address format being elegant doesn't change that. The end-to-end principle is the thing keeping those two outcomes separable, and it's worth defending precisely when the alternative looks this tidy.

Full technical write-up with the rest of the spec breakdown is here: https://ipbnb.com/blog/ipv8-internet-protocol

Don't Let Your IPAM Drift: Managing Leased IPv4 the API-First Way

Artem Kohanevich — Wed, 17 Jun 2026 04:04:11 +0000

Almost every IPAM mess I've debugged traces back to one root cause: the record and the reality drifted apart. Someone assigned an address and forgot to log it. A block expired and nothing flagged it. The spreadsheet said one thing, the routers said another.

With owned IPv4 you can usually recover from that. With leased IPv4 you have less room, because a leased block carries three things owned space doesn't: an expiry date, a reputation you inherited, and an owner who isn't you. You either manage those as data, or they end up managing you.

Here's how I'd wire it up.

Start with the data model

Before reaching for any tool, decide what a leased block actually is in your system. At minimum:

prefix: 203.0.113.0/24
status: active
lease:
  owner: ACME-LIR
  start: 2026-06-01
  expiry: 2027-06-01
  loa_reference: LOA-2026-0481
routing:
  origin_asn: 64500
  roa_status: valid          # valid | invalid | unknown
  irr_registered: true
reputation:
  status: clean              # clean | listed | watch
  last_checked: 2026-06-15

The three fields that make leased space different - lease.expiry, lease.owner, and reputation.status - are exactly the ones a generic IPAM setup tends to leave out. Don't leave them out.

Model it in NetBox, and let the API do the writing

NetBox is the tool I reach for here: open-source, IPAM plus DCIM, and an API that covers everything the UI does. Define the lease fields once as custom fields (lease_owner, lease_expiry, loa_reference, roa_status, reputation), then register a freshly leased block in a single call:

import pynetbox

nb = pynetbox.api("https://netbox.internal", token="<token>")

nb.ipam.prefixes.create({
    "prefix": "203.0.113.0/24",
    "status": "active",
    "description": "Leased /24 - web tier",
    "custom_fields": {
        "lease_owner": "ACME-LIR",
        "lease_expiry": "2027-06-01",
        "loa_reference": "LOA-2026-0481",
        "roa_status": "valid",
        "reputation": "clean",
    },
})

Now the lease metadata lives next to the prefix, not in a contract PDF nobody opens.

Allocate addresses through the API, not by hand

Manual assignment is the single biggest source of drift. Close that gap by allocating from NetBox's next-available-IP endpoint, so the assignment and the record are the same operation:

prefix = nb.ipam.prefixes.get(prefix="203.0.113.0/24")

ip = prefix.available_ips.create({
    "description": "web-01",
    "dns_name": "web-01.customer.example",
})

print(ip.address)   # -> 203.0.113.5/24

There's no window where inventory and reality disagree, because writing the record is the allocation. Wire this into your provisioning flow and the "who's on this address?" problem stops existing.

Verify routing before you announce, and know who owns the ROA

This is the leased-space gotcha that trips up strong teams: you cannot create your own ROA for leased space. Only the resource holder - the block owner, or the platform you leased from - can create the Route Origin Authorization, update the IRR route objects, and issue the LOA. Your job is to confirm it's all in place and that your origin validates before you announce a single route.

A quick scripted check against RIPEstat:

curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS64500&prefix=203.0.113.0/24" \
  | jq -r '.data.status'
# -> valid

If that returns invalid or unknown, stop and fix it with the owner before the prefix goes live - otherwise every network running ROV will drop your routes. Fold the result straight back into routing.roa_status so your inventory reflects what the routing table actually believes.

Treat reputation as a scheduled job

You inherit a block's history, so check it before assignment and keep checking on a timer. The DNSBL mechanism is simple enough to script and stay list-agnostic - point $DNSBL_ZONE at whichever current lists you trust:

check_dnsbl() {
  local ip="$1" zone="$2"
  local reversed
  reversed=$(awk -F. '{print $4"."$3"."$2"."$1}' <<< "$ip")

  if dig +short "${reversed}.${zone}" | grep -q '^127\.'; then
    echo "LISTED $ip ($zone)"
  else
    echo "clean  $ip ($zone)"
  fi
}

check_dnsbl 203.0.113.5 "$DNSBL_ZONE"

Run it across the block on a schedule, write the result and timestamp back into reputation.status / last_checked, and alert on any change. Keep mail-sending IPs on separate, warmed space so one customer's mistake doesn't taint a block shared with everyone else.

Catch renewals before they catch you

The authorizations that let you announce - the LOA and the ROA - are tied to the lease term. Let a lease lapse and you don't lose paperwork, you lose routing. So query for blocks nearing expiry on a cron and push them somewhere a human will actually look:

from datetime import date, timedelta
import pynetbox

nb = pynetbox.api("https://netbox.internal", token="<token>")
horizon = date.today() + timedelta(days=60)

for p in nb.ipam.prefixes.filter(status="active"):
    expiry = p.custom_fields.get("lease_expiry")
    if expiry and date.fromisoformat(expiry) <= horizon:
        print(f"Renewal due: {p.prefix} - {p.custom_fields['lease_owner']} - {expiry}")

Pipe that into Slack or your ticketing system and renewals become a planned task instead of a 2 a.m. incident.

Which tool?

phpIPAM - free, light, supports custom fields, fine for smaller footprints you're happy to self-host.
NetBox - open-source, API-first, the one I'd build automation on (everything above assumes it).
SolarWinds IPAM - mid-market, with discovery and conflict detection if you want the tool to reconcile itself against the network.
Infoblox - enterprise DDI, integrated DNS/DHCP/IPAM, priced for scale.

Whatever you pick, the test is the same: can it store lease owner, expiry, and reputation, and can you write to it from code? If yes, you can keep records and reality in lockstep. If no, you'll be back to debugging drift.

That's the whole philosophy - model the lease as data, let the API do the writing, and put reputation and renewals on a timer. The unglamorous automation is exactly what lets you scale leased IPv4 without surprises.

If you want the longer, less code-heavy treatment - the full lease-to-deployment workflow, a setup checklist for new blocks, and a deeper tool comparison - I wrote it up here: IP Address Management for Leased IPv4: Best Practices for Hosting Providers.

Is Your IPv4 Block Blacklisted? Checking a /24 the DNSBL Way

Artem Kohanevich — Thu, 11 Jun 2026 10:22:14 +0000

If you own or lease IPv4 space, the reputation of your addresses is part of the asset. A block that's quietly listed on a major DNSBL doesn't deliver mail, fails the health checks renters run before they sign, and loses value on resale - and nothing proactively tells you it happened.

Pasting one IP into a web form is fine for a spot check. If you're responsible for a whole block, here's how to actually query the reputation data and sweep a /24.

How a DNSBL lookup works

A DNSBL (DNS-based blocklist, aka RBL) answers reputation queries over DNS. You reverse the octets of the IP, append the zone, and do an A lookup. A 127.0.0.x answer means listed; NXDOMAIN means clean.

# 203.0.113.5  ->  5.113.0.203
dig +short 5.113.0.203.zen.spamhaus.org
# 127.0.0.x      = listed (the code tells you which list)
# empty/NXDOMAIN = not listed

For Spamhaus ZEN (their combined zone: SBL + CSS + XBL + PBL), the return code tells you which list you're on:

Return code	List	Meaning
127.0.0.2	SBL	Manually listed spam/abuse source
127.0.0.3	SBL CSS	Auto-detected low-reputation sender
127.0.0.4 - .7	XBL	Compromised host / open proxy / botnet (the old CBL data lives here now)
127.0.0.9	SBL	DROP/EDROP - hijacked or fully malicious range
127.0.0.10 / .11	PBL	Range that shouldn't send mail directly (often normal)

One gotcha that trips people up: Spamhaus's free public mirrors block queries coming from public/open resolvers like 8.8.8.8 and 1.1.1.1, and return an error code in the 127.255.255.x range instead of real data. Run your checks through your own resolver, or grab a free Data Query Service (DQS) key and query the DQS zone. If you dig through Google's resolver and get a strange answer, that's why.

Sweeping a whole /24

Once the query format makes sense, looping over the host range is trivial:

# Sweep 203.0.113.0/24 against Spamhaus ZEN
for i in $(seq 1 254); do
  ans=$(dig +short "$i.113.0.203.zen.spamhaus.org")
  [ -n "$ans" ] && echo "203.0.113.$i -> $ans"
done

(Same resolver caveat applies - for a real sweep, point it at a resolver that isn't a public mirror.)

AbuseIPDB for aggregate scoring

Spamhaus tells you listed/not-listed. AbuseIPDB gives you a crowdsourced confidence score (0-100) per address, and its check-block endpoint scores a whole subnet in one call:

curl -G https://api.abuseipdb.com/api/v2/check-block \
  --data-urlencode "network=203.0.113.0/24" \
  -d maxAgeInDays=90 \
  -H "Key: $ABUSEIPDB_KEY" \
  -H "Accept: application/json"

The response lists every reported address in the block with its abuseConfidenceScore. AbuseIPDB treats anything under 25 as noise; 75-100 is the range you'd actually block on. The free tier is 1,000 checks/day, and check-block is capped at /24 - for a larger block, iterate over its /24s or use a paid tier.

What to do with a hit

Two rules:

Fix the root cause before you request removal. Delisting while the open relay, compromised host, or spam source is still live just gets you relisted - sometimes with self-service removal disabled the next time.
Never pay for delisting. It's free everywhere. The return code points you at the path: SBL needs the owner-of-record or ISP to contact Spamhaus; XBL/CSS is self-service via check.spamhaus.org; AbuseIPDB decays over time or you dispute; Barracuda has a manual removal form. Timelines run from minutes (PBL) to weeks (AbuseIPDB decay).

While you're in there, confirm the boring hygiene that keeps a block off lists in the first place: clean, consistent rDNS, valid RPKI/ROA so the origin checks out, and an abuse@ address that someone actually reads.

The part the sweep doesn't solve

A sweep is a point-in-time snapshot. It tells you the block is clean now. The moment you lease it out, reputation becomes a function of what your renter does - and a single compromised host or one spam run can list addresses within hours.

Keeping a leased block clean is therefore continuous, not a one-off: screen who you hand a block to, watch abuse signals in real time, and de-provision fast enough that a listing never takes hold. That's most of the operational reason we built IPbnb the way we did - when a block is leased through the marketplace, that screening and monitoring runs in the background instead of landing on the owner. It won't scrub an existing listing, and no setup makes a block un-flaggable, but it keeps the day-to-day abuse-watching automated while the block earns.

Either way: before you lease or sell a block, sweep it. It's a few minutes of dig and one API call.

Full guide - every tool, return code, and delisting path by database: https://ipbnb.com/blog/ip-abuse-check-ipv4-blacklisted

Whitelisting leased IPv4 blocks: 3 gotchas owned-space guides skip

Artem Kohanevich — Fri, 05 Jun 2026 13:47:29 +0000

IP whitelisting is the oldest trick in the access-control book: deny everything, allow a known set of source IPs, done. The firewall mechanics don't care whether the addresses behind your allowlist are owned or leased.

The operational reality does. I run a leasing platform, so I see where leased IP whitelisting quietly breaks - and it's never the firewall syntax. It's three things owned space lets you ignore.

1. You inherit a reputation you didn't earn

A leased block usually has a past. If a previous renter spammed, scanned, or landed on Spamhaus / AbuseIPDB, that history can still cling to the addresses when they reach you.

Why it bites whitelisting specifically: half the time you're the one trying to get whitelisted - by a customer's firewall, a payment gateway, a partner API, an SMTP relay. Their automated reputation checks see a flagged range and quietly refuse, throttle, or shove you into extra verification. Your allowlist can be perfect and you still don't get onto theirs.

Fix: start from a clean, vetted block, and re-check your own block's reputation on a schedule - it drifts, including from your own workloads.

2. The lease has a clock; your allowlist doesn't know that

Owned IPs are yours indefinitely. A leased block is yours for a term. So any long-lived allowlist entry referencing leased space - yours sitting in a partner's firewall, or theirs sitting in yours - goes stale the moment that lease ends and the block gets reassigned.

An allowlist entry that outlives the lease behind it isn't dead weight. It's an open door to whoever holds the block next.

Treat the lease end date as a real event in your firewall lifecycle. Tag every leased-range entry with its expiry and review it then.

3. RPKI sits upstream of your firewall

A firewall allowlist filters traffic that already arrived. It does nothing to make the prefix route to you. If the ROA is missing or wrong, networks doing route origin validation drop your announcement - and now there's no traffic to whitelist in the first place.

If you're bringing the leased block to a cloud via BYOIP, the ROA has to authorise that provider's ASN or it won't advertise at all. RPKI is a prerequisite, not an alternative.

The boring part that actually matters

The cross-cloud best practice is the same everywhere: reference reusable objects, never hard-code CIDRs into individual rules. That's what turns an end-of-lease change from a risky sweep into a one-line edit.

On AWS, that's a customer-managed prefix list:

# define trusted sources once
aws ec2 create-managed-prefix-list \
  --prefix-list-name trusted-sources \
  --address-family IPv4 --max-entries 20 \
  --entries Cidr=203.0.113.0/24,Description="partner-api"

# reference it from the security group - not the raw CIDR
aws ec2 authorize-security-group-ingress \
  --group-id sg-0abc \
  --ip-permissions IpProtocol=tcp,FromPort=443,ToPort=443,\
PrefixListIds='[{PrefixListId=pl-0def,Description="HTTPS from partners"}]'

Change the range later? Edit the prefix list once; every referencing rule follows.

GCP: network / hierarchical firewall policies (Cloud NGFW), targeting workloads with IAM-governed tags instead of raw IPs.
Azure: NSGs (rules evaluated lowest-priority-number first) plus ASGs to group your own backends by role.

And the usual reminder: an IP proves where a packet looks like it came from, not who sent it. Pair the allowlist with real auth (mTLS, certs, an IdP). Whitelisting narrows the door; it doesn't check ID.

On automation - a quick critical take

"Automate your allowlists" is good advice for distribution: define ranges as code, sync from one reviewed source of truth, stop editing the same rule in 20 places.

But watch the failure modes:

Auto-discovery that adds IPs from a live feed grows your trusted set with nobody reviewing it - that's deny-by-default inverted.
A pipeline that can push a CIDR everywhere at once is a single blast radius for one bad entry.
Self-healing reconciliation will cheerfully re-add an entry you deliberately removed - including a leased range you retired at lease end. Revocation has to beat reconciliation, or it isn't revocation.

Automate distribution; keep a human gate on what enters the source of truth.

TL;DR: leased IP whitelisting = standard allowlist discipline (default-deny, CIDR ranges, reusable objects, real auth, audits) + three leased-only rules: start clean, keep RPKI/ROA correct upstream, and diary the lease boundary.

Longer write-up with the full per-provider setup here → IP Whitelisting Best Practices for Leased IPv4 Blocks

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