IPv4 Block Leasing and Buying: /24 Minimum, LOA, Reputation

An IPv4 block you plan to announce over BGP should be at least a /24, because almost every network on the internet filters anything more specific. Whether you lease, buy, or transfer the space, you need three things sorted out before it goes live: the block must be a routable size, the holder must authorize you in writing (the LOA, or Letter of Authorization), and the addresses must have a clean reputation.

This guide walks through the options, the paperwork, and the checks that save you from paying for space you can't use.

Lease, Buy, or Transfer: What Each Option Means

With a lease, the block is not yours. The holder can revoke the authorization, and you should assume you will renumber if the contract ends. With a purchase, the block moves to your organization's account at an RIR (ARIN, RIPE NCC, APNIC, LACNIC, or AFRINIC). Transfer rules differ by region, including need justification, minimum sizes, and holding periods, so read the current policy of the RIR involved before signing anything. Brokers typically handle the paperwork, but you remain responsible for verifying the seller.

Why /24 Is the Minimum Announce Size

The global IPv4 routing table is large, and operators protect their routers' memory and convergence time by filtering overly specific routes. The de facto convention is simple: accept up to /24, reject longer prefixes. IPv6 has the same convention at /48.

What that means in practice:

• A /24 (256 addresses) is the smallest block that will propagate widely.
• A /25 or /26 that you announce will be dropped by most upstreams and peers. It may be reachable only inside one provider's network, if at all.
• You cannot split a /24 into smaller pieces and announce them to the internet independently. You can subdivide it internally for customers, but the announcement stays a /24.
• Buying less than a /24 is rarely useful for BGP. Smaller blocks are only helpful as provider-assigned space.

If you need more than 256 addresses, aggregate where you can. A contiguous /23 announced as one prefix is cleaner than two /24s, unless you want separate /24 announcements for traffic engineering or redundancy.

The LOA: Letter of Authorization

An LOA is a signed statement from the block holder authorizing a specific ASN to originate a specific prefix. Providers ask for it before they accept your announcement, and it's the standard document in lease arrangements.

A usable LOA contains:

• Holder's legal name, address, and contact details
• The exact prefix (for example, 192.0.2.0/24)
• The authorized origin ASN (for example, AS64496)
• The provider or network being authorized to announce on your behalf, if applicable
• A start date and an expiration date
• A signature from someone with authority, plus a printed name and title

A minimal example:

LETTER OF AUTHORIZATION

I, [Name, Title], on behalf of [Holder Organization], registered holder of
the IP resource below, authorize [Your Organization] (AS64496) to originate
and announce the following prefix via BGP:

  Prefix:        192.0.2.0/24
  Origin ASN:    AS64496
  Valid from:    2025-01-01
  Valid until:   2026-01-01

Registry/handle: [RIR and org handle]
Contact:         [email / phone]

Signature: ____________________   Date: ____________

An LOA alone is a weak proof. A PDF can be forged. Careful providers cross-check it against the registry data and the RPKI. That's why you should ask the holder for the following, not just a signed letter.

Make the Authorization Verifiable

1. RPKI ROA. The holder creates a Route Origin Authorization in their RIR portal that authorizes your ASN for the prefix, with a max length of /24.
2. IRR route object. A route: object with origin: AS64496, maintained by the holder or with their consent.
3. Registry whois. The holder's details in the RIR database should match the name on the LOA.

Check what is currently published:

# Registry data for the block
whois 192.0.2.0/24

# IRR route objects
whois -h whois.radb.net 192.0.2.0/24

# RPKI validation state (with a local Routinator)
routinator validate --asn AS64496 --prefix 192.0.2.0/24

You want the ROA to say "valid" for your ASN. If it says "invalid," most networks that perform route origin validation will drop your announcement, even if your LOA is perfect.

Check IP Reputation Before You Pay

IPv4 space is recycled. A block that was used for spam, scanning, or abuse years ago may still sit on blocklists, and your mail, API calls, or game traffic may suffer for it. Check before you commit, and ideally put the check into the contract.

Blocklist Checks

For a /24 you need to check every address, not only the first one. Many providers and aggregators let you query a range. For a quick manual check of a single address against a DNSBL, reverse the octets:

# Check 192.0.2.10 (reverse octets) against a DNSBL zone
dig +short 10.2.0.192.zen.spamhaus.org

# No answer (NXDOMAIN) = not listed. A 127.x.x.x answer = listed.

Mind the usage policies of public DNSBL resolvers. Heavy automated querying through large public DNS resolvers can return false results or errors. For bulk checks, use a resolver you control or the list operator's own tools.

Check several sources, since lists differ in scope: spam, malware, scanning, and abuse reports. Don't forget that Microsoft and Google have their own reputation systems for mail.

History and Routing Checks

• Previous origin ASNs. Use a public BGP data tool such as RIPEstat or bgp.he.net and see who announced the block and when. Frequent hops between unrelated ASNs deserve questions.
• Current announcements. Make sure nobody is currently announcing it. If the block is still routed by someone else, you'll have a conflict (or the seller doesn't control it).
• Reverse DNS. Look for leftover PTR records that point to unrelated domains.
• Geolocation. Geo-IP databases may still place the block in the previous owner's country. Plan to update them (see below).
• Bogon and hijack history. If the prefix was ever flagged as hijacked or unallocated, walk away or demand full documentation.

Put It in the Contract

• Seller warrants the holder status and that no one else is authorized.
• A defined window after delivery in which you can reject the block if it's listed on major blocklists.
• Refund or replacement terms if the block is revoked or found to be unrouteable.

Putting the Block Into Service

Once the paperwork and reputation checks pass, the process is short:

1. Get the ROA published (or the transfer completed) and the IRR route: object created.
2. Provide the LOA and your ASN to your upstream. Make sure your ASN is in the upstream's AS-SET so the prefix passes their filters.
3. Configure your router or VDS to originate the /24 and run the BGP session. For a hands-on walkthrough, see our other guides on BIRD and FRRouting.
4. Verify propagation from outside your network with a looking glass.
5. Set reverse DNS, update geolocation data, and warm up mail reputation gradually if you send email.

At Nixcon Group LLC, we run BGP-enabled VDS servers where you can announce your own ASN and IP block from a BGP session on the VDS. Ownership of the ASN and prefix is validated automatically against RPKI ROAs and official RIR/IRR records, and your ASN is added to the AS-NIXCON AS-SET. You can choose between an unprotected announcement, a DDoS-protected announcement, and a full routing table. Our public looking glass offers BGP route, ping, and traceroute queries from Izmir, Frankfurt, and the US, which is useful for step 4.

Common Mistakes and Fixes

• Buying a /25 or smaller for BGP. It won't propagate. Fix: acquire at least a /24 or use provider-assigned space.
• ROA max length too short. If your ROA says /23 max and you announce /24s, the /24s become RPKI-invalid. Fix: set the max length to match what you announce.
• Wrong origin ASN in the ROA or IRR. Fix: match exactly the ASN you use in BGP.
• Relying on the LOA only. Fix: require a ROA and IRR object so verification is possible.
• Skipping reputation checks on part of the range. Fix: check all 256 addresses, and recheck after delivery.
• Stale geolocation. Fix: submit corrections to the major geo-IP providers after the block goes live.
• No exit plan for leased space. Fix: keep your own services portable, use short TTLs, and track the lease end date.

Quick Checklist

• Block is at least a /24
• Holder verified in the RIR database
• LOA signed, dated, and specific to your ASN and prefix
• ROA valid, max length correct
• IRR route object present
• All addresses checked against multiple blocklists
• Routing history reviewed, no conflicting announcements
• Contract covers revocation and rejection rights