DEV Community: Artem Kohanevich

Leasing IPv4 for a Colocation Facility: Registry Objects, ROAs, and the /24 Floor

Artem Kohanevich — Sat, 12 Sep 2026 10:13:47 +0000

Leasing an IPv4 block is commercially simple and operationally not. The contract takes a week. Getting the block to carry traffic for your renters - and keeping the registry consistent while it does - involves objects in three different systems, two of which you do not control.

This post is the technical view. It assumes you know what BGP and RPKI are and skips the explanation of why IPv4 is scarce.

The distribution problem

Most parties leasing IPv4 consume it directly: one block, one announcement, one operator. A colocation facility is a distribution layer. You take space from an owner and hand portions of it to renters running their own equipment.

That introduces a constraint that shapes everything else:

The global routing table will not accept anything longer than a /24. Operators filter it. So a renter who needs 16 addresses cannot announce their /28 themselves - it has to be announced by you, from your ASN, as part of a covering /24.

This splits your renters into two categories before you allocate anything:

Renter needs	Announced by	ROA required
Less than a /24	Your ASN, inside a covering prefix	One, covering the whole block, your ASN
A full /24 or more, routed by you	Your ASN	One, your ASN
A full /24 or more, their own ASN	Their ASN	Separate ROA naming their ASN

The third row is the one that needs negotiating with the owner in advance, because it means they publish a ROA for an ASN that is neither yours nor theirs. Some owners will not do it. Find out before you sell that cabinet.

What the owner has to give you

Three artefacts, and none of them are optional.

1. Letter of Authorisation

A signed document from the registered owner authorising your ASN to announce the block. Your upstreams will ask for it before they accept the prefix. Check the expiry date matches your lease term - a LOA that expires before your contract does will cause an outage nobody diagnoses quickly.

2. A ROA in the RPKI

Published by the owner under their RIR account. Validators then treat your announcement as valid rather than notFound, and a growing share of the internet drops invalid.

The parameter to pay attention to is maxLength:

prefix:     192.0.2.0/24
asn:        AS64496
maxLength:  24

maxLength does not have to equal the prefix length. A wider value is valid and is sometimes genuinely needed - if you intend to deaggregate a /23 into two /24s announced separately, a maxLength of 24 on the covering /23 is what makes that work.

But RFC 9319 recommends against setting it wider than you actually need. An overly permissive maxLength makes forged-origin sub-prefix announcements validate cleanly, which is exactly the attack RPKI is supposed to stop. Ask for the specific values you need, not a blanket maximum.

3. Registry objects

RIPE is explicit that only allocations and assignments registered in the RIPE Database count as valid - registering the object is the final step of making an assignment, not paperwork that follows it. ARIN applies the same principle through SWIP for any reassignment of a /29 or larger.

In a lease, the block sits under the owner's registration. So the objects describing your renters are created under their maintainer, or through their sponsoring LIR. That has a direct consequence for your provisioning pipeline, covered below.

You will also likely want a route: object in the RIPE Database (or the relevant IRR), since plenty of upstreams still build prefix filters from IRR data rather than RPKI alone:

route:      192.0.2.0/24
origin:     AS64496
mnt-by:     MAINT-EXAMPLE
source:     RIPE

The object hierarchy

For a leased /24 where you assign sub-blocks to renters, the RIPE Database structure looks roughly like this:

192.0.2.0/24        ALLOCATED PA        (owner's LIR)
├── 192.0.2.0/26    ASSIGNED PA         renter A
├── 192.0.2.64/27   ASSIGNED PA         renter B
├── 192.0.2.96/27   ASSIGNED PA         renter C
└── 192.0.2.128/25  LIR-PARTITIONED PA  held for allocation

Two status values worth knowing:

LIR-PARTITIONED marks space reserved but not yet in use. It is explicitly not counted as used - when the addresses are deployed, a more specific inetnum has to be created. Useful for holding contiguous space against a renter's growth without misrepresenting utilisation.
SUB-ALLOCATED PA exists for delegating a range to a downstream operator who will make their own assignments within it. Whether you can use it depends entirely on how the owner has structured things and what your lease permits.

Each inetnum carries an abuse-c reference. This determines where complaints about traffic from that range are delivered. Decide deliberately whether that is your NOC or the renter's - routing abuse mail to a renter who ignores it will cost you the block's reputation.

Provisioning latency is now a dependency

Here is the practical consequence of the block being registered to someone else.

Your provisioning flow for a new renter probably looks like:

1. allocate sub-block in IPAM
2. configure interface / VLAN
3. create inetnum object          ← owner's maintainer
4. request reverse DNS delegation ← LIR only
5. announce / verify reachability

Steps 3 and 4 are not yours. RIPE only accepts reverse delegation requests from LIRs, so in-addr.arpa records for your renters route through the owner too. If a renter runs mail, missing PTR records will hurt them immediately and they will open a ticket with you, not with the owner.

Three questions to settle contractually before the first provision:

Delegated maintainer access, or request-based? Direct mnt-by access on the sub-objects removes a human from your critical path. Ask for it.
What is the committed turnaround on a request? 48 hours is workable. Two weeks silently becomes your provisioning SLA.
Who handles in-addr.arpa? Including the delegation for renters who need custom PTRs.

Reputation is a shared fate within the prefix

Blocklists operate on ranges. One renter in a /24 generating spam or scanning traffic can get the whole prefix listed, and delisting takes days to weeks during which your other renters in that block see degraded mail delivery.

Pre-lease diligence is cheap and entirely public:

# registry record and current holder
whois -h whois.ripe.net 192.0.2.0/24
curl -s https://rdap.db.ripe.net/ip/192.0.2.0/24 | jq

# RPKI validity and announcement history
# stat.ripe.net -> routing-history, rpki-validation

Then check the range against the major blocklists before signing, not after. A block with a history of listings is not automatically disqualified, but it is a price negotiation and it changes which renters you put in it.

Design-level mitigations:

Separate prefixes by risk profile. Mail-heavy renters and general hosting in different /24s where possible. Contained blast radius.
Egress rate limiting and outbound port 25 policy by default, opened per renter on request.
Netflow-based anomaly alerting on egress, so you find out before a blocklist does.
A suspension clause with a short notice period in the renter agreement. Your own lease almost certainly gives the owner equivalent rights against you.

Renumbering on exit

RIPE policy on provider aggregatable space is unambiguous: when a downstream operator changes provider, the PA space returns and they renumber. Leased space inherits this.

Put it in the renter agreement explicitly, with the notice period and a stated migration window. A renter who has hardcoded your addresses into their configs, their DNS, and their partners' allowlists will discover the problem at the worst moment otherwise.

BYOIP for hybrid renters

Leased space can be brought into AWS, Azure, Google Cloud, and OVHcloud under BYOIP, which matters for renters running split deployments. Requirements are broadly consistent across providers:

a /24 or larger (none of them accept longer prefixes)
a ROA authorising the provider's ASN, published by the owner
a signed authorisation message, usually with an X.509 keypair and a signed inetnum or ROA-derived token

The provisioning step is the slow one - expect weeks rather than days, and the owner is in the loop for the ROA. Worth scoping before a renter commits to a migration date.

Pre-signature checklist

[ ] LOA covers the full lease term, ASN correct
[ ] ROA parameters agreed, maxLength no wider than needed
[ ] Onward assignment to renters permitted in writing
[ ] Third-party ASN ROAs possible if a renter needs one
[ ] Delegated maintainer access, or committed turnaround
[ ] in-addr.arpa delegation path defined
[ ] abuse-c ownership decided per object
[ ] Registry and routing history checked, blocklist status clean
[ ] Abuse escalation process documented, both directions
[ ] Renumbering terms mirrored into renter agreements

Most of this is one conversation with the owner before signing. All of it is expensive to retrofit after you have renters in the block.

A less registry-heavy version of this, covering the commercial side and the buy-versus-lease decision, is on the IPbnb blog: IP Address Leasing for Data Centers.

Verifying an IPv4 Block Before You Lease It: RDAP, BGP, and RPKI in Practice

Artem Kohanevich — Thu, 03 Sep 2026 22:54:51 +0000

Most "who owns this IP" tooling answers one question and presents it as the whole answer. For incident response that's usually fine. For a lease you're about to route production traffic through, it isn't.

There are five separate questions, and they resolve against five different data sources:

Question	Source	What the answer actually means
Who is registered for the block?	RDAP / RIR WHOIS	Registered holder of the containing object
Who is originating it now?	BGP (RIPEstat, RouteViews)	Origin ASN as seen by route collectors
Is that origin authorized?	RPKI, secondarily IRR	Whether origin+prefix match a covering ROA
Where is it used?	Geolocation providers	An estimate. Not authoritative for anything
What's its abuse history?	Reputation services, plural	Provider-specific, time-sensitive signals

A holder/origin mismatch is not evidence of fraud - leasing, transit, BYOIP, and parent/subsidiary structures all produce one routinely. What matters is whether the mismatch is accounted for.

RDAP over WHOIS, and why

RDAP is standardized where WHOIS isn't:

RFC 9082 - query format
RFC 9083 - JSON response structure
RFC 9224 - bootstrap (IANA registry → correct RIR endpoint)

WHOIS returns registry-specific plain text. ARIN uses NetRange / OrgName; RIPE and APNIC use RPSL-style inetnum / descr. If you're parsing, you write a parser per registry. RDAP gives you consistent field names across all five RIRs.

Two things RDAP does not give you:

Accuracy. Both services read from the same registry data maintained by resource holders. A stale org name is stale in both.
A different answer than WHOIS. They're views over the same records, not independent sources. Cross-checking one against the other proves nothing.

One correction that comes up a lot: the January 2025 WHOIS sunset applied to gTLD registration data. RDAP became definitive for domain names on 28 January 2025, 374 gTLDs had disabled WHOIS by that September, and RDAP query volume overtook WHOIS in June 2025. RIR WHOIS for IP and ASN resources was unaffected and is still running in 2026.

The first pass

#!/usr/bin/env bash
# Minimum viable due diligence on an offered prefix.
PREFIX="198.51.100.0/24"
IP="198.51.100.10"

# 1. Registry record, via RDAP bootstrap.
curl -s "https://rdap.org/ip/${IP}" | jq '{
  name, handle, type, country,
  cidr: .cidr0_cidrs,
  parent: .parentHandle,
  roles: [.entities[]? | {handle, roles}],
  events: [.events[]? | {action: .eventAction, date: .eventDate}]
}'

# 2. Current origin + history.
curl -s "https://stat.ripe.net/data/routing-status/data.json?resource=${PREFIX}" \
  | jq '.data | {visibility, first_seen, last_seen, announced_space}'

curl -s "https://stat.ripe.net/data/routing-history/data.json?resource=${PREFIX}" \
  | jq '.data.by_origin[] | {origin, timelines}'

# 3. ROA state.
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS64500&prefix=${PREFIX}" \
  | jq '.data | {status, validating_roas}'

198.51.100.0/24 is TEST-NET-2 (RFC 5737). Substitute the real prefix; don't route the example.

Notes on the output:

type distinguishes ALLOCATION, ASSIGNMENT, LEGACY, and registry-specific values. Terminology differs per RIR - don't map ARIN semantics onto a RIPE object.
parentHandle matters when the offered range sits under a larger allocation. RDAP returns the most specific object; the commercial relationship may live one level up.
events gives you registration and last changed. A recent last changed means something was touched, not that every field was reverified.
cidr0_cidrs - confirm the returned object actually contains your full offered prefix. Querying one IP and assuming the /24 inherits its status is the single most common mistake here.

Persist the raw JSON with a timestamp. Registry and routing state both drift; a saved response is evidence, a screenshot isn't.

Origin history is the interesting part

Current origin tells you today. History tells you what you're inheriting.

What to pull out of routing-history:

Every origin ASN observed, with first/last seen
Gaps in announcement - dormant space is a hijack target
More-specifics announced from unrelated ASNs
Churn without explanation

Any of these is a question for the provider, not a disqualification. But "we don't know" is itself an answer.

ROA state, and what it's worth

Three outcomes:

Valid    → prefix + origin ASN covered by a matching ROA,
           announcement no more specific than maxLength
Invalid  → covering ROA exists, ASN or prefix length doesn't match
NotFound → no covering ROA

Worth calibrating expectations here. RPKI coverage hit a record 67.43% of announced prefixes in June 2026 - roughly 1.07M of 1.58M routes carrying a signed ROA. Enforcement is the lagging half: measurement work cited by RIPE Labs puts full route origin validation at around 12% of ASes, with roughly 36% not validating at all.

So Valid means the origin is authorized and networks that validate will accept it. It does not mean the announcement is safe from hijack, that the AS path is sound, or that the entity emailing you is the holder. ROV checks the rightmost AS in the path. An attacker who wants a protected prefix doesn't fight the ROA - they announce the victim's prefix with the victim's ASN at origin and prepend their own.

Also worth checking maxLength in the ROA. Over-permissive maxLength (RFC 9319 covers this) leaves room for more-specific announcements that still validate. If the lessor is creating a fresh ROA for your ASN, specify it exactly rather than accepting a default.

Reputation: scan the range, not a sample

Registry and routing checks say nothing about deliverability or platform acceptance. Separate step, separate tooling.

# Spamhaus ZEN, reversed-octet DNSBL query.
# Use your own resolver - public mirrors refuse queries from large resolvers,
# and a sequential /24 scan will hit rate limits.
check_zen() {
  local ip=$1
  local rev
  rev=$(echo "$ip" | awk -F. '{print $4"."$3"."$2"."$1}')
  local result
  result=$(dig +short "${rev}.zen.spamhaus.org" A)
  [[ -n "$result" ]] && echo "$ip -> $result"
}

# Whole /24, not a sample.
for i in $(seq 0 255); do check_zen "198.51.100.$i"; done

Return codes map to distinct lists, and they mean different things:

Code	List	What it means
`127.0.0.2`	SBL	Manually researched spam source
`127.0.0.3`	CSS	Auto-detected low-reputation sender
`127.0.0.4`	XBL	Compromised/exploited host
`127.0.0.9`	SBL DROP	Hijacked or wholly malicious allocation
`127.0.0.10/11`	PBL	Policy range, shouldn't send direct-to-MX

A PBL listing is a policy statement about the range, not an abuse finding. Treating it as equivalent to SBL will make you walk away from perfectly usable space. 127.0.0.9 is the one that should stop a deal.

One number that justifies the whole exercise: a study of RIR transfer reports from 2009 to 2019 found nearly 40% of routed transferred prefixes carried at least one blacklist report, against about 6% of routed prefixes that had never been transferred. Traded space isn't inherently bad. It's a different prior.

The check nobody automates

Everything above queries what the registry says. None of it tells you whether the registry can act.

That matters when a lease depends on a record change - a ROA creation, a route object update, an entity change - happening inside the lease term.

AFRINIC is the working example. Board dissolved, registry under receivership from 2022-2023, address requests stalled for months with no functioning governance. A board was seated after the 2025 elections and the receiver applied to terminate receivership in October 2025, but litigation begun before and after those elections is still open, the June 2025 election was annulled and re-run, and the incoming CEO doesn't take office until January 2027.

There's no API for "can this registry process my request this quarter." Ask the provider, name the RIR, get it in writing.

Checklist

[ ] Full CIDR, RIR, proposed origin ASN, lease term, activation date
[ ] RDAP object contains the entire offered prefix (not just a sample IP)
[ ] Registered holder identified; counterparty's relationship documented
[ ] Signer authority verified via a channel the counterparty didn't supply
[ ] Current + historical BGP origins reviewed; anomalies explained
[ ] ROA plan matches agreed prefix and origin ASN, maxLength specified
[ ] IRR route object plan confirmed
[ ] Full range scanned across multiple reputation sources
[ ] Registry turnaround time for record changes confirmed in writing
[ ] Acceptance criteria + remediation deadlines in the contract
[ ] Withdrawal sequence defined for end of lease
[ ] Raw JSON responses archived with timestamps

Activation ordering matters too: old announcement withdrawn → ROA and IRR updated → new announcement started → propagation monitored. Overlapping announcements during a handover produce exactly the ambiguity you spent all this effort eliminating.

Longer writeup with the field-by-field registry reading guide, the RDAP-vs-WHOIS comparison, and a green/yellow/red decision table for lease evaluation: Who Owns an IP Address? How to Check with WHOIS and RDAP

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.