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

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:

1. Delegated maintainer access, or request-based? Direct mnt-by access on the sub-objects removes a human from your critical path. Ask for it.
2. What is the committed turnaround on a request? 48 hours is workable. Two weeks silently becomes your provisioning SLA.
3. 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.