IPAM for Leased IPv4 Space

Model lease metadata as structured fields

Add fields to your IPAM — custom fields in NetBox, custom fields in phpIPAM — for the attributes a lease has and ownership does not:

• Lessor — who you lease from, and the contract reference
• Start and end dates — as dates, so they can be queried and alerted on
• Renewal terms — automatic, optional, or fixed end
• Notice period — how long before the end date a decision is required
• Authorisation reference — where the letter of authorisation is stored
• Registry status — what the RIR record says about the block

Structured, not free text. The whole point is being able to ask “which blocks end within six months” and get an answer, and a description field cannot answer that. See IPAM best practices on why this generalises.

Set an alert on the end-date field. A date nobody is reminded of is a date that arrives unannounced.

Separate leased space from owned space in reporting

Utilization across a mixed estate is a misleading number. Owned space is permanent capacity; leased space is capacity with an expiry, and reporting them together hides the fact that a chunk of your addressing has a countdown on it.

Tag every block by tenure and report the two separately. The questions you need answerable are: how much space do we hold outright, how much do we lease, and what does the leased portion cost per year against what buying the equivalent would cost. That last comparison is the input to the buy-versus-lease decision, and it cannot be made from a blended figure.

Store the authorisation and check the registry record

Keep the letter of authorisation somewhere findable, and record its location in the IPAM entry. You will need it when an upstream asks why you are announcing a prefix that is registered to someone else, and that request tends to arrive at the point where you cannot spend a day looking for it.

Then check what the registry actually says. Look the block up with WHOIS or RDAP and confirm the record matches the arrangement you agreed. If the lease includes a sub-allocation or reassignment in your name, verify it exists. If it does not include one — which is common — do not create objects yourself. The holder controls those records, and unauthorised changes cause problems for them and for you.

The same applies to routing objects. IRR route objects and ROAs for leased space are created under the holder’s authority. Confirm before you announce that the necessary objects exist and authorise your ASN, because an announcement without them is filtered by a growing share of the internet.

Assign responsibility for geofeed and reputation

Two things about a leased block affect your users directly and are nobody’s job by default.

Geolocation. Geolocation providers key off registry data and published geofeeds. A block previously used in another country will keep geolocating there until corrected, which surfaces as users being served the wrong language, wrong currency, or blocked content. Agree in writing who publishes the geofeed and where it is referenced, because a geofeed published by a party the registry record does not point at may never be found.

Reputation. Blocklist entries attach to addresses and survive the change of tenant. Check the block against major blocklists before accepting it, and monitor throughout the lease — inherited reputation is the single most common unpleasant surprise with leased space. Agree who handles delisting when it is needed.

Neither of these is expensive to sort out at the start of a lease. Both are painful once users are on the addresses.

Set renumbering milestones well before the end date

Work backwards from the return date and record the milestones as tasks, not intentions.

The real constraint is rarely reconfiguring your own equipment. It is everything that has your addresses embedded in it somewhere else: customer allowlists, partner firewall rules, third-party API restrictions, DNS records with long TTLs, hardcoded configuration in systems nobody remembers. Each of those needs a change request on someone else’s schedule.

A workable shape for a block of any significance:

• Six months out — decide renew or return, while renewal is still negotiable
• Four months out — if returning, inventory everything referencing the addresses
• Three months out — notify external parties holding allowlist entries
• Two months out — begin migrating services, starting with the least externally visible
• One month out — reduce DNS TTLs and complete migration
• Return date — stop announcing, confirm with the lessor

Compress these if the block is small and internal. Do not compress the external-notification steps, because they depend on other organisations’ change windows.