Skip to content
Fresh IPv4 news just dropped — 🎉 see what you’re missing

Post-Transfer Checklist: Bringing a Block Online

Reviewed by Marek Dvořák, Network engineer

The registry update makes the block yours on paper. It does not make it routable, reachable, or correctly located. Work through these steps before the first announcement; most can be done the same day the record changes.

Before you start, have:

  • Access to your registry portal (LIR Portal, ARIN Online, MyAPNIC) with rights to create objects
  • The ASN that will originate the prefix — your own or your upstream’s; see how to get an ASN
  • Name servers for reverse DNS
  • The list of upstreams and the IRR database each one uses for filters

Examples use 203.0.113.0/24 and AS64500.

Confirm the registry record

Check the record yourself rather than relying on the registry’s email:

whois -h whois.ripe.net 203.0.113.0/24 | grep -E '^(inetnum|org|status|mnt-by|abuse-c):'
curl -s https://rdap.db.ripe.net/ip/203.0.113.0/24 | jq '.handle, [.entities[].handle]'

Expected result: your organisation ID, your maintainer in mnt-by, and the status you expected (ALLOCATED PA for an LIR receiving allocated space). For ARIN, whois -h whois.arin.net "n + 203.0.113.0" should show your OrgName and NetType: Direct Allocation.

If the record also changed status — PA to PI, for example — check that the new status fits how you will use the block. PI space cannot be sub-assigned to customers.

Set contacts and the abuse mailbox

Inherited admin-c and tech-c references and old remarks: should go. In the RIPE Database the abuse contact comes from abuse-c on your organisation object or on the inetnum; at ARIN it is the abuse POC on your Org.

Test that abuse mail is delivered to a monitored mailbox. Unanswered abuse reports are how a clean block acquires a reputation problem in its first month.

Clear the previous holder’s routing objects

APNIC deletes route and domain objects associated with a transferred block. Other registries may leave objects behind, and third-party IRRs such as RADB never clean up automatically.

# Route objects anywhere in the IRR system for this prefix
whois -h whois.radb.net 203.0.113.0/24

# ROAs currently covering the prefix, as seen by validators
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS64500&prefix=203.0.113.0/24" \
  | jq '.data.status, .data.validating_roas'

Any route object or ROA naming an origin other than yours has to go. Objects in the previous holder’s registry account are theirs to delete; make that a contractual obligation, ideally before escrow release. For RADB objects maintained by a third party, contact the maintainer listed on the object or RADB support.

Sign ROAs for your origin

All five registries offer hosted RPKI through their portals. Create a ROA for each origin:

FieldValue
Prefix203.0.113.0/24
Origin ASNAS64500
maxLength24

Set maxLength to exactly the longest prefix you will announce. A wider maxLength lets anyone announce a more-specific route with your origin spoofed; a narrower one makes your own announcement invalid.

If the block will sit idle for a while, an AS0 ROA marks it as not to be routed and protects it from squatting until you are ready.

Create route objects

Create a route object in the IRR your upstreams use. In the RIPE Database:

route:    203.0.113.0/24
descr:    Example Networks
origin:   AS64500
mnt-by:   EXAMPLE-MNT
source:   RIPE

ARIN offers an IRR in ARIN Online, and APNIC has its own IRR. Check what your upstream’s filter will contain:

bgpq4 -4 -l PL-AS64500 AS64500

Your prefix should appear in the generated list. If it does not, the upstream’s filter will not either.

Delegate reverse DNS

Delegate the in-addr.arpa zone through the registry: a domain object in the RIPE Database, the reverse DNS section of ARIN Online or MyAPNIC. Each /24 is one zone.

dig +short NS 113.0.203.in-addr.arpa
dig +short -x 203.0.113.10

The first command should return your name servers, the second the PTR you configured. Mail servers in particular need forward-confirmed reverse DNS before anyone accepts their mail.

Publish a geofeed

A geofeed is a CSV file, defined in RFC 8805, that tells geolocation providers where each prefix is used:

203.0.113.0/24,NL,NL-NH,Amsterdam,

Publish it over HTTPS and reference it from the registry object as described in RFC 9632: the geofeed: attribute on the inetnum in the RIPE Database, or a Geofeed remark elsewhere. A block that moved countries keeps the previous location in some databases until the feed is picked up, so publish it on day one.

Check reputation before traffic

Sample addresses across the block against major blocklists:

for i in 1 64 128 254; do echo -n "203.0.113.$i: "; dig +short $i.113.0.203.zen.spamhaus.org || true; echo; done

Empty output means not listed. Run it from your own resolver; Spamhaus refuses queries from large public resolvers. Start delisting anything inherited now, while the block carries no traffic and the listing cannot be blamed on you.

Announce and verify from outside

Ask each upstream to update its filters, announce the prefix, and then check what the internet actually sees:

curl -s "https://stat.ripe.net/data/routing-status/data.json?resource=203.0.113.0/24" \
  | jq '.data.origins, .data.visibility'

Visibility should approach the full set of route collector peers within an hour, and the RPKI status from the earlier query should now be valid. Partial visibility usually means a missing IRR object at one upstream or a stale bogon filter; see reserved and bogon ranges.

Afterwards

Record the block in IPAM with its registry ID, transfer date, and any restriction window. A block received in the RIPE region cannot be transferred again for 24 months; your records should say so. See utilization and RIR audits for keeping registry assignments in step with real use.

Set up origin monitoring. An alert for your prefix being announced by any ASN other than yours catches hijacks and forgotten objects.

If the block is spare capacity rather than production space, leasing it out is an option once it is clean and routable.

Last updated on