Education and research networks
IPv4 Planning for Education & Research Networks
Plan campus and research IPv4 capacity with documented holder authority, registry and routing prerequisites, workload segmentation, acceptance checks, and change ownership.
- Primary planning question
- Which campus, lab, and partner workloads require dedicated public IPv4, and which can use shared translation or IPv6?
- Authority evidence
- Registered-holder approval, RIR account authority, route-origin authorization, and responsible contacts are confirmed before change work.
- Acceptance evidence
- Route visibility, source addressing, DNS dependencies, abuse contacts, and rollback criteria are recorded for the approved scope.
Capacity path
Compare retained, leased, and purchased IPv4 capacity
Start with workload-level demand and the institution’s existing authorized space. Then compare a retained-space plan, a bounded lease, and a purchase against duration, utilization, authority, funding, registry eligibility, routing, and operating ownership. Availability and commercial terms remain live checks.
- 01
Retain and segment existing allocations
Map authorized institutional space to public services, lab systems, instruments, partners, and reserves before requesting additional capacity.
- 02
Lease for a bounded operating window
Model the term, assignment scope, permitted use, routing prerequisites, renewal decision, return duties, and exit plan for temporary or staged demand.
- 03
Purchase for durable demand
Compare transfer eligibility, capital, registry path, long-term routing and record ownership, operating duties, and timeline for persistent requirements.
Planning problem
Public address demand is not one uniform campus requirement
Campus services, instruments, lab environments, remote access, partner connections, and long-running data pipelines have different addressing and change-window needs. A historical inventory alone does not show which workload needs public IPv4 or who may authorize registry and routing changes.
Planning starts by mapping each workload to holder authority, RIR records, route-origin controls, external dependencies, acceptance checks, and rollback ownership. Reputation and geolocation are time-bound observations—not guarantees of access or institutional identity.
Build the plan around evidence and ownership
Each step produces a reviewable input for the institution, its network operators, and the parties that retain external decision authority.
- 01
Segment demand by workload
Separate public services, lab systems, instruments, partner links, remote access, and temporary projects before sizing address demand.
- 02
Verify authority and route prerequisites
Record holder approval, RIR account access, route-origin authorization, upstream requirements, contacts, and dependency owners.
- 03
Define change and acceptance ownership
Set the window, sequence, observable checks, stop criteria, rollback owner, and post-change review for the approved scope.
A decision record for every proposed change
The deliverable connects workload need, prefix scope, authority evidence, dependencies, acceptance checks, and rollback ownership. It supports an informed institutional decision; it does not promise registry approval, route propagation, destination access, reputation, geolocation, or research outcomes.
Scope
Workload, environment, requested prefix, intended use, timeline, and responsible institutional owner.
Evidence
Holder authority, RIR and route records, upstream prerequisites, DNS dependencies, contacts, and dated external observations.
Decision
Proceed, revise, or stop with named approvers, acceptance criteria, rollback responsibility, and the next review point.
Before
Campus demand is expressed as one address total without workload-level justification.
After
Demand is separated by workload, environment, intended use, timeline, and owner.
Before
Registry and routing changes begin before authority and dependency evidence is assembled.
After
Holder approval, RIR access, route controls, upstream needs, and contacts are reviewed first.
Before
Acceptance and rollback expectations remain distributed across tickets and email.
After
Checks, change windows, stop criteria, rollback owners, and review dates share one record.
Decision boundaries
What remains outside the plan’s control
i.lease can coordinate evidence and an authorized change sequence. It cannot replace the institution’s authority or the independent decisions of registries, network operators, and external services.
- RIRs and upstream networks retain authority over their records, routing policies, validation, and processing timelines.
- External platforms, data providers, and collaboration partners retain their own access, rate, classification, and security policies.
- The institution retains approval of workload scope, credentials, change windows, research obligations, acceptance, and rollback.
Planning questions
What campus and research teams should confirm
Use these answers to define the first workload, capacity, authority, and deployment review.
How should a campus or research network estimate IPv4 capacity?
Inventory public services, lab systems, instruments, remote access, partner links, temporary projects, current utilization, forecast demand, assignment duration, IPv6 or translation options, reserve capacity, and accountable owners. Treat the estimate as planning evidence, not a guarantee that a specific range is available.
Which education or research workloads still need public IPv4?
Document the technical or partner dependency that requires public IPv4 for each workload. Private addressing, translation, or IPv6 may fit other workloads, but the institution must validate application, security, funding, and research requirements.
Should an institution retain, lease, or buy IPv4 capacity?
Retained institutional space can fit existing authorized capacity, leasing can fit a defined project or transition window, and purchase can fit durable demand when eligibility, capital, timing, and long-term operations support it. None of these paths guarantees availability, registry approval, price, routing, or external access.
What evidence should be ready before registry or routing changes?
Prepare holder authorization, applicable RIR and WHOIS records, origin ASN, IRR and ROA plans, upstream and partner prerequisites, DNS needs, security and abuse contacts, change windows, observable acceptance checks, monitoring, and rollback ownership. Registries, networks, and partners retain their own decisions.
Start with one bounded network requirement
Bring the workload, current records, intended routing, target window, and accountable contacts. We will identify the evidence and decisions needed before execution.
