How to Split an IPv4 Block: Rules and RIR Requirements

Splitting an IPv4 block sounds simple until you actually have to do it. Get it wrong, and you’re looking at registration errors, routing headaches, and delays the next time you want to sell or transfer space. I’ve seen deals stall for weeks over documentation that could have been sorted out on day one. This guide walks through the rules, what the RIRs expect, and the practical steps involved.

Why Split an IPv4 Block? Use Cases and Benefits

There are plenty of legitimate reasons to divide up your address space:

• Multi-site deployments: A company holding a /22 can hand a /24 to each of its four data centers. Routing gets simpler, and geographic redundancy becomes easier to manage.
• Customer provisioning: ISPs and hosting providers sub-allocate chunks of larger blocks to downstream customers while keeping a single allocation for themselves.
• Sales and monetization: Scarcity has pushed prices to roughly $30–$50 per address. If you own a /16, you might sell off several /24s to different buyers rather than transfer everything in one shot.
• Departmental isolation: Dividing space along organizational lines makes security segmentation, accounting, and day-to-day network management far cleaner.

There’s flexibility here too. You can lease one portion and keep another for growth, or liquidate part of your inventory without touching production networks. But — and this matters — every split needs to be documented with your RIR, or it loses validity for routing announcements, transfers, and future transactions.

Understanding Sub-Allocation: What RIR Policies Allow

Each RIR — ARIN, RIPE NCC, APNIC, LACNIC, and AFRINIC — writes its own policies, though the underlying principles look pretty similar across regions:

• Minimum allocation size: ARIN and RIPE NCC generally work with blocks as small as a /24 for transfers and assignments. Go smaller and you may find the space isn’t registrable, or isn’t easily routable.
• Sub-allocation vs. assignment: A sub-allocation is space you delegate downstream (to a customer, say), while an assignment goes to an end user for actual use. Both need to be recorded in the regional registry database (WHOIS/RDAP).
• Justification requirements: RIPE NCC policy requires a signed agreement with the downstream party for sub-allocations. ARIN wants demonstrated need for new assignments — typically 25% immediate utilization with a plan to reach 50% within a year.
• Alignment on octet boundaries: Stick to CIDR boundaries. A /23 divides cleanly into two /24s. Arbitrary splits, on the other hand, leave you with fragmented space that’s painful to route.

How to Split IPv4 Block: Step-by-Step Process

1. Audit your current registration. Confirm the exact block size, the holder organization, and the RIR through WHOIS or RDAP lookups. Don’t assume — verify.
2. Plan the split on CIDR boundaries. An IPv4 subnet calculator helps here. Dividing a /23 into two /24s, for example, should be mapped out before you touch anything.
3. Submit the request to your RIR. Provide justification, downstream agreements, and utilization plans where required.
4. Update registry objects. Each new subnet needs accurate inetnum/NET objects, maintainer references, and route objects so BGP announcements stay clean.
5. Validate before deployment. Make sure the registry reflects the new structure before you advertise prefixes or execute any transfer.

When the split is tied to a sale or lease, having an experienced partner in your corner makes a real difference. IP4 Market offers a trusted platform for IPv4 transactions — verified sellers, full RIR-compliant documentation support, competitive pricing. It takes much of the risk out of subdividing and transferring a block.

Minimum Prefix Sizes and Utilization Requirements by RIR

Before you split any IPv4 block, check what your Regional Internet Registry actually allows. Each RIR sets its own minimum sizes for allocations and assignments, and if you request something smaller, the request gets rejected. Simple as that.

• ARIN: The minimum prefix for directly assigned space is typically a /24. You can make smaller sub-allocations to downstream organizations, but every assignment needs documented need behind it.
• RIPE NCC: End-user assignments can go down to a /24 in most cases. PI space generally starts at /24 or /22, depending on the request type. And if you’re an LIR subdividing PA space, you’ll have to work within RIPE’s assignment windows and their Y2K-format documentation requirements.
• APNIC: Minimum assignments are generally /24 for end users. Sub-allocation to downstream ISPs is permitted — but APNIC expects that space to show up correctly in the registry database. No shortcuts there.
• LACNIC and AFRINIC: Both apply stricter scrutiny. LACNIC usually wants detailed technical justification for any subdivision, and AFRINIC, having historically managed the smallest available pool, has kept the most conservative assignment policies of the five.

Utilization matters too. ARIN, for example, applies what’s known as the 80/25 rule: you should be using at least 80% of your current space before you receive more. Here’s the part people miss — when you split a block and assign prefixes downstream, the RIR evaluates utilization across the entire range, not just the parent block. So keep your host-count documentation, network diagrams, and justification worksheets handy. Registries routinely ask for this evidence during review.

Updating SWIP and RIR Records After Sub-Allocation

The physical split is done. Now comes the paperwork — and honestly, this is where things go wrong more often than in the actual subnetting. Every sub-allocation has to be registered correctly, or you risk routing filtering, abuse reports going to the wrong place, and headaches in any future transfer.

1. Submit SWIP/RWHOIS records: ARIN requires SWIP (Shared WHOIS Project) registration for reassignments of /24 or larger to downstream organizations. RIPE and APNIC handle their equivalents through their own databases — object creation for inetnum, inet6num, and organisation objects.
2. Update abuse and NOC contacts: Make sure each new prefix has valid abuse-c, tech-c, and admin-c references. Incomplete contact data is one of the most common causes of registry rejection. It’s tedious. Do it anyway.
3. Announce and verify: Once registered, create route objects (IRR) and RPKI ROAs for each new prefix. Many upstream providers and IXPs now reject unfiltered-invalid or unregistered announcements outright — no negotiation.
4. Reconcile periodically: Audit your registry records at least once a year. Stale sub-allocations still registered to former customers can block transfers or trigger compliance reviews down the road.

Conclusion: Splitting IPv4 Space Safely and Compliantly

Splitting an IPv4 block is, technically speaking, easy. The administrative obligations around it are where most organizations stumble. Every successful split follows the same sequence: verify your RIR’s minimum prefix sizes and utilization rules, document the need for each sub-allocation, execute the subdivision — then update SWIP, IRR, and RPKI records immediately so they reflect the new topology. Not eventually. Immediately.

Cutting corners has real costs. Rejected registry requests. Routing instability. Contested ownership in future transfers. And diminished asset value in a market where clean, well-documented prefixes command premium prices — which, with IPv4 scarcity still pushing prices upward, matters more every year. Your address space is one of your most valuable network assets. It deserves the same diligence you’d give any other investment.

Whether you’re subdividing for internal growth, downstream customers, or an upcoming sale, precision at every step pays off. And if the split is part of a sale or lease, IP4 Market provides the verified-seller environment, RIR-compliant documentation support, and competitive pricing to close the transaction with confidence. Split carefully. Register accurately. Your IPv4 space will stay both compliant and liquid for years to come.