An IPv4 lease agreement is useful only when its terms describe the prefix, deployment, and operating responsibilities accurately. A generic order form may record the quantity and monthly rate while leaving the important questions unresolved. Network teams need to know who can authorize the route, change reverse DNS, respond to abuse reports, approve renewal, and withdraw records when the lease ends.
Before signing an agreement to lease IP addresses, procurement, legal, security, and network operations should review the same deployment plan. The contract should reflect that plan and assign an owner to each dependency. The following clauses provide a practical review structure, but case-specific legal advice remains appropriate.
The agreement should identify the exact CIDR prefix whenever it is known. If the contract begins with a quantity rather than a named block, it should state when the prefix will be assigned, what acceptance checks apply, and whether substitution is allowed. Record the nominal address count, any exclusions, the service region, and the expected start condition.
Avoid relying on a product label such as “one /24” when the specific range matters to routing history, reputation, or customer allowlists. The technical handover should connect the contractual description to the precise prefix that will enter production.
The contract should identify the lessor and the basis on which it can grant the proposed use. Registry data is relevant evidence, but it does not replace the agreement or automatically prove that the commercial counterparty controls every required change. If the resource holder, lessor, technical operator, and billing party are different organizations, name their roles and escalation paths.
Include a process for a change in source authority, a dispute, or a loss of the ability to support the lease. The remedy may involve replacement capacity, migration time, termination rights, or another agreed response. The contract should define the remedy rather than leave the network team to negotiate it during an incident.
Describe the intended workloads, users, locations, and traffic profile with enough precision to prevent conflicting assumptions. The acceptable-use terms should explain prohibited activity, investigation duties, notice, cure periods where appropriate, and circumstances that can lead to restriction or suspension. Security and compliance teams should confirm that the intended deployment fits the policy before traffic moves.
State whether the customer, lessor, or another network will originate the prefix. Identify the approved origin ASN, upstream arrangement, Letter of Authorization process, Internet Routing Registry object, and activation sequence. The party that signs the commercial agreement may not control every routing artifact, so the handover must identify who requests, approves, implements, and verifies each change.
For RPKI, record who can create and withdraw the ROA and how the prefix and maximum length will be set. ARIN describes a ROA as a cryptographically signed object that identifies the ASN authorized to originate a prefix. A valid ROA supports route-origin validation, but it does not replace the lease contract or guarantee that every upstream will accept the route.
The agreement should state whether reverse DNS will be delegated or managed through a service request, who approves PTR changes, and what response time applies. If geolocation affects the application, identify who supplies geofeed information or requests corrections from third-party databases. Neither the lessor nor the customer controls every external dataset, so the clause should define the work to be performed rather than promise a universal result.
Reputation and reachability should be assessed against the intended application before acceptance. Define the sources, sample addresses, test date, and pass conditions. A general promise of “clean IPs” is difficult to verify because blocklists, fraud systems, mail providers, and content platforms use different data and can change their classifications.
State what happens if the block fails an agreed test before activation. Options may include remediation, a bounded replacement process, delayed acceptance, or termination. After acceptance, assign monitoring and incident-response responsibilities instead of treating the initial result as a permanent warranty.
Identify who receives abuse notices, how the customer is notified, what evidence must be provided, and when escalation occurs. The IANA guidance on abuse issues and IP addresses explains that reports should be directed using the registration information associated with the address. The agreement should keep registry contacts, operational contacts, and response procedures current.
Support language should separate ordinary service requests from urgent routing or security incidents. Record support hours, response targets, escalation contacts, and the party authorized to approve material changes. A shared inbox without named escalation is not a sufficient continuity plan for a production prefix.
Specify whether the price applies per address, per block, per month, or for the full term. Record the billed address count, currency, taxes, deposit, setup charges, routing work, support, and any usage-based fees. Define when billing begins and what happens when activation is delayed for reasons outside the customer’s control.
Teams comparing alternatives can model lease and purchase costs over the same capacity and time horizon. The agreement should still control the actual amount and included services; a planning model is not a quote.
Renewal should not depend on an informal conversation shortly before expiry. State the initial term, notice deadline, renewal option, repricing method, invoice timing, and the date by which both parties must confirm continuation. If the customer depends on stable allowlists or partner integrations, the notice period should leave enough time for an orderly migration if renewal does not proceed.
A managed IPv4 leasing process can coordinate authority, routing, activation, and lifecycle evidence, but the signed agreement remains the place to record the customer’s actual renewal and continuity rights.
Define termination events, notice, cure periods, service suspension, and any early-termination charges. The return plan should identify when production traffic must stop, when BGP announcements and authorizations will be withdrawn, how reverse DNS and route objects will be removed, and when the prefix is considered returned.
The customer also needs time to update DNS, allowlists, firewalls, partner configurations, documentation, and monitoring. Require written confirmation that the agreed return steps are complete. Where appropriate, include a quarantine period before the prefix is assigned to another user.
- Exact prefix, address count, service region, term, and permitted use
- Resource authority and the role of each commercial and technical party
- Origin ASN, upstream model, LOA, route object, ROA, and activation order
- Reverse DNS, geolocation, registry contacts, and change procedures
- Acceptance tests for reachability, reputation, routing, and application fit
- Support hours, incident escalation, abuse reporting, and remediation
- Price unit, fees, billing start, payment timing, and renewal formula
- Notice dates, termination rights, route withdrawal, return, and evidence retention
Attach the completed technical schedule to the agreement or incorporate it by reference with clear version control. Operations should verify that the final document matches the approved network plan before authorizing production traffic.
A strong IPv4 lease agreement does more than record a price and term. It connects the commercial right to use a prefix with the authority, routing records, support, renewal, and return work needed to keep that prefix usable. Settling those details before activation reduces uncertainty when the network changes or an incident requires a fast response.
