DEV Community: Artem Kohanevich

Bring Leased IPv4 to AWS with BYOIP (and skip the $0.005/hr charge)

Artem Kohanevich — Fri, 31 Jul 2026 15:38:37 +0000

Since 1 February 2024, AWS bills $0.005/hour for every public IPv4 address in your account - attached or not. That's ~$3.65/address/month, or ~$934/month for a working /24 (256 addresses). Addresses you bring in via BYOIP are exempt, and Elastic IPs allocated from your own pool are free too.

The AWS docs cover the happy path but skip the two things that actually cause tickets: the authorization-context signing step, and whether a leased block even qualifies. This post fills both gaps and gives you the full CLI sequence.

TL;DR: a leased /24 works fine, because AWS validates control via your RIR, not ownership. You just need the registrant to set up the ROA.

What AWS actually checks

When you provision a block, AWS verifies two registry-side records:

A ROA (Route Origin Authorization) in your RIR's RPKI, authorizing Amazon's ASNs to originate the prefix.
RDAP records proving you control the range, verified either with a signed X.509 authorization context (the classic path) or a DNS TXT record via IPAM (the newer path).

Neither of these cares who owns the block in a contractual sense - they care who holds the registration. For a leased /24, that's the IP owner. So the block qualifies as long as the registrant creates the ROA and, if you're using the X.509 path, signs the authorization message for you. A decent leasing provider does this as part of onboarding; if you're wiring it up yourself, budget a back-and-forth with whoever holds the registration.

Requirements checklist

Prefix: /24 is the most specific IPv4 you can bring. No /25 or longer. (IPv6: /48 for publicly advertised.)
RIR: ARIN, RIPE, or APNIC, registered to a business/institutional entity, not an individual.
ROA: authorize ASNs 16509 and 14618 (use 8987 for GovCloud). Set maxLength to /24. Allow up to 24h to propagate.
Quota: 5 ranges per Region; more via a Support ticket.
Scope: one block, one Region at a time.

If you already advertise the block from your own ASN, create the ROA for your ASN before adding Amazon's, or you risk disrupting your live announcement.

The step everyone trips on: the authorization context

provision-byoip-cidr takes a --cidr-authorization-context with a Message and a Signature. This is where people get stuck, because the docs describe it more than they show it.

The Message is a plaintext string in a fixed format:

1|aws|<account-id>|<cidr>|<expiry-yyyymmdd>|SHA256|RSAPSS

You sign that message with the private key of the X.509 certificate whose public half is published in your RIR's RDAP record. The base64 of that signature becomes Signature:

# message
text_message="1|aws|123456789012|203.0.113.0/24|20261231|SHA256|RSAPSS"

# sign with your BYOIP private key
signed_message=$(echo -n "$text_message" \
  | openssl dgst -sha256 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 \
    -sign private-key.pem -keyform PEM \
  | openssl base64 | tr -- '+=/' '-_~' | tr -d '\n')

Two things bite here: the signature must use RSA-PSS, and the base64 needs URL-safe substitution (+=/ → -_~). Get either wrong and provisioning fails validation with an unhelpful message.

The provisioning sequence

1. Provision the block:

aws ec2 provision-byoip-cidr \
  --cidr 203.0.113.0/24 \
  --cidr-authorization-context Message="$text_message",Signature="$signed_message"

This is asynchronous - it returns immediately, but the block isn't usable yet.

2. Poll until it flips to provisioned:

aws ec2 describe-byoip-cidrs --max-results 5

You'll see State walk from pending-provision → provisioned. If it lands on failed-provision, the StatusMessage tells you why - almost always a ROA that hasn't propagated or a maxLength that isn't /24.

3. Advertise it:

aws ec2 advertise-byoip-cidr --cidr 203.0.113.0/24

State moves to advertised and AWS starts originating the prefix.

4. Allocate an Elastic IP from your pool (free, unlike Amazon-provided EIPs):

aws ec2 allocate-address \
  --region eu-central-1 \
  --public-ipv4-pool ipv4pool-ec2-xxxxxxxx

5. Associate it with an EC2 instance, NAT gateway, or Network Load Balancer:

aws ec2 associate-address \
  --instance-id i-0abc123 \
  --allocation-id eipalloc-0abc123

That's it. From here your BYOIP addresses behave like any Elastic IP - minus the hourly charge.

Where BYOIP addresses actually attach

EC2 / VPC via Elastic IP - instances, NAT gateways, NLBs.
AWS Global Accelerator - assign IPv4 from your own pool directly (IPv4 only).

⚠️ Amazon SES also has a "BYOIP" feature - it is not this one. SES BYOIP is a paid, per-address monthly feature (256-address minimum) for preserving sending reputation. It does not dodge the $0.005/hr charge. Different mechanism, different billing, different purpose. Don't conflate them.

Timing and gotchas

No SLA on provisioning. It's async; allow up to 24h for ROA propagation and a few business days end to end once registry records are set.
pending-provision that won't clear = ROA not propagated, or maxLength ≠ /24.
ROA mismatch = wrong prefix or missing an ASN. Both 16509 and 14618 must be authorized, valid for the whole time the block lives in AWS.
Signature failures = not RSA-PSS, or non-URL-safe base64.
Quota surprises = you get 5 ranges/Region before needing Support.

Is it worth it?

For a few addresses with no existing block: no - just use Amazon's and move on. For dozens of addresses, or anywhere IP reputation and migration continuity matter: absolutely. A working /24 is ~$934/month on Amazon-provided addresses versus $0 in AWS address charges on BYOIP. Your only cost is the lease, which runs a fraction of that - and nothing at all if you own the block.

Full version with the cost breakdown, the leased-IPv4 details, and the complete requirements is on our blog: How to Bring Leased IPv4 to AWS.

Importing a leased /24 into OVHcloud with BYOIP (and skipping the $612/mo IP bill)

Artem Kohanevich — Thu, 30 Jul 2026 10:04:58 +0000

I run IPbnb, so IPv4 economics are kind of my whole day. But this one still catches teams off guard, so let me walk through it like an engineer, not a marketer.

OVHcloud bills Additional IPs at $2.39 per IP per month. Fine for a couple of addresses. Now do a /24:

256 addresses × $2.39 = ~$612 / month, forever

And you own none of it. The addresses are OVH's, the reputation you build on them can't leave with you, and the meter never stops. There's a cleaner way, and it's called BYOIP.

What BYOIP actually does

Bring Your Own IP means OVHcloud announces a block you control instead of renting you theirs. No per-IP rental on imported space - OVH advertises it for free. So the only real question is where the block comes from: rent, buy, or lease.

You don't need to own a /24 to do this. Lease a clean one (we do this at IPbnb from ~$79/mo), import it via BYOIP, and you're paying roughly 85% less than renting OVH's 256 addresses - with a block whose reputation is yours and portable.

Requirements (the short list)

RIR: ARIN, RIPE, or APNIC. NIRs are experimental; AFRINIC/LACNIC not supported yet.
Size: /24 minimum, /19 max. It's delivered to you as one or more /24 blocks.
Clean + unannounced: don't have it advertised elsewhere when it goes live, or you'll get routing conflicts.
WHOIS status must be a real allocation/assignment (e.g. RIPE ALLOCATED PA / ASSIGNED PA), matching the exact prefix.

The setup

1. Publish a route object at your RIR with OVH's ASN as origin:

route:    203.0.113.0/24
origin:   AS16276
source:   RIPE

2. Prove control by dropping the token OVH gives you into the descr field of the inetnum (its own line):

inetnum:  203.0.113.0 - 203.0.113.255
descr:    -----BEGIN TOKEN-----
descr:    <your-ovh-token>
descr:    -----END TOKEN-----

3. Order it in the Control Panel: Network > IP > + Bring Your Own IP. Pick the RIR, the region, the range, and OVH's AS (or your own via BYOAS). Delivery takes a few weeks.

4. Go live by assigning a /24 to an eligible service. Announcement is assignment-driven - nothing is advertised until you attach the block to a Bare Metal box, Public Cloud instance, or a vRack-connected service.

Need smaller blocks? Slice via the API:

POST /ip/{ip}/bringYourOwnIp/slice
{ "slicingSize": 25 }   // splits a /24 into /25s

Gotchas worth knowing before you commit

Region lock-in is gone. OVH dropped the old ARIN→US / RIPE→EU rule. A RIPE block now works in any OVH region. You still choose one region per import, and you can't move a range across regions without releasing and re-ordering it.
No WHOIS edits from the panel. OVH doesn't own the block, so reverse DNS runs through delegated ARPA zones instead. PTRs work; WHOIS stays with the holder.
Kill the old announcement fast. If the block was advertised elsewhere, withdraw that the moment OVH delivery completes, or you're multihoming into packet loss.
Anti-DDoS is included on BYOIP ranges at no extra cost, which is a nice freebie.

The leased-block angle

BYOIP isn't owner-only. OVH just needs proof you're authorised to route the prefix. With a leased block, that's a Letter of Authorisation from the holder plus correct route/ROA objects - which, if your provider actually supports BYOIP, is already done for you before you place the order. That's the difference between leasing from someone who preps the block and someone who just emails you a range.

TL;DR

If you need address space for years, buy it. For hosting, SaaS, and migrations, paying ~$612/mo to rent IPs you'll never own is hard to justify when ~$79 gets you the same /24 with your reputation intact.

Full step-by-step, requirements, and the honest cost math here:
Bring a Leased /24 to OVHcloud: BYOIP Guide →

Whose ASN Goes on Your Leased IPv4 Prefix?

Artem Kohanevich — Mon, 20 Jul 2026 08:22:21 +0000

You leased a /24. Something has to originate it in BGP. That something has an ASN attached, and if the wrong ASN is attached, your prefix gets dropped by every network running Route Origin Validation.

That is the entire problem. Here is how the four options differ at the object level.

The four origination paths

Path	Origin AS	Who creates what
Your own ASN + BGP	Yours	Owner issues LOA + `route:` + ROA, all naming your ASN
Upstream/host announces	Provider's	Same three objects, naming their ASN
Cloud BYOIP	Cloud's, or yours on AWS	ROA naming cloud ASN (or yours via BYOASN) + RDAP proof
Third-party AS	Partner's	Same three objects, naming the partner's ASN

Three of the four need no ASN registered to you.

The rule

ROA.asID must equal the origin AS in the announcement. RFC 6811 gives three outcomes:

NotFound - no covering ROA. Still widely accepted, decreasingly so.
Valid - origin AS and prefix length both match.
Invalid - wrong origin AS, or announced prefix longer than maxLength. Dropped by every validating peer.

Invalid is the dangerous one because it fails partially. Peers doing ROV drop you, peers that do not still carry you, and the symptom looks like an application bug.

The failure I see most

Renter plans to get their own ASN later. Asks the IP owner to create the ROA against that future ASN now. Goes live with the host announcing from the host's AS.

ROA:          198.51.100.0/24  origin AS64496  maxLength 24
Announcement: 198.51.100.0/24  AS_PATH ... 64511
                                            ^^^^^ mismatch -> Invalid

Sequence it the other way. Decide the origin, then create the ROA.

Also watch maxLength

ROA:          203.0.113.0/22   origin AS64496  maxLength 22
Announcement: 203.0.113.0/24   origin AS64496
                        ^^^ correct AS, too specific -> Invalid

Correct ASN is not sufficient. maxLength has to cover what you actually originate.

Verifying before you announce

RIPEstat works regardless of which RIR administers the block:

curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=64496&prefix=198.51.100.0/24" \
  | jq '.data.status, .data.validating_roas'

Anything other than "valid" means stop. For a local relying-party cache, use Routinator, rpki-client or FORT.

Note: the RIPE NCC RPKI Validator has been unmaintained since 1 July 2021 and the public instance was migrated to Routinator in September 2021. Plenty of tutorials still point at it.

Then confirm what the world actually sees:

whois -h whois.radb.net -- '-i origin AS64496'   # route objects
# plus RIPE RIS / BGPView / HE looking glass for the live AS_PATH

Cloud specifics

AWS commercial regions. ROA must authorise 16509 and 14618, maxLength 24 for IPv4. GovCloud (US) uses 8987. Authorisation is two-part: the ROA plus a self-signed X.509 certificate published in the RDAP remarks for the prefix.

AWS BYOASN. You are not forced onto Amazon's origin AS. Bring an ASN you hold:

aws ec2 provision-ipam-byoasn --ipam-id ipam-xxxx --asn 64496 --asn-authorization-context ...
aws ec2 associate-ipam-byoasn --asn 64496 --cidr 198.51.100.0/24
aws ec2 advertise-byoip-cidr --cidr 198.51.100.0/24 --asn 64496

The ROA then names your ASN, not Amazon's.

Azure Custom IP Prefix. Origin AS must be 8075 (public) or 8070 (US Gov). Parent IPv4 prefix must be /21 to /24. Two constraints that kill use cases outright: SMTP is not permitted from Azure BYOIP space, and you must decommission the range before modifying or deleting the ROA - otherwise Microsoft keeps advertising a prefix it is no longer authorised to originate.

Do you actually want your own ASN?

RIPE still requires multihoming. ripe-679 §2.0 is unambiguous, and proposal 2025-01 - which would have dropped all justification for a first ASN - was withdrawn on 6 July 2026. The old criteria stand.

You submit a routing policy in RPSL:

aut-num:  AS64496
import:   from AS64500 accept ANY
import:   from AS64501 accept ANY
export:   to AS64500 announce AS64496
export:   to AS64501 announce AS64496

Two upstreams in that object is not decoration. RIPE NCC may contact both to verify.

Single-homed with one /24? An ASN gets you EUR 50 per assignment, registry obligations, and a routing policy identical to your upstream's. Skip it until you are genuinely multihoming.

Pre-flight

[ ] LOA names the announcing ASN
[ ] route: object exists with correct origin:
[ ] ROA correct on both asID and maxLength
[ ] RPKI status valid
[ ] Prefix visible from multiple vantage points, observed origin matches the ROA
[ ] rDNS delegated
[ ] Reputation checked on the block and the announcing ASN

Longer version with the full path-by-path breakdown, the RIPE policy history, and the LOA/IRR/ROA sequencing: https://ipbnb.com/blog/asn-to-announce-ipv4

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.