IPv4 lease agreement key terms at a glance
Use this guide as an operational and commercial discussion checklist. It is not a contract template or a determination of enforceability. Have qualified counsel review the actual agreement, applicable law and negotiated remedies.
- Resource and authority: exact CIDR, parties, authorized signer, permitted use and restrictions on onward use.
- Delivery: operator responsibilities, required records, acceptance tests and a remedy if activation fails.
- Money and time: complete charges, billing trigger, term, renewal notice and price changes.
- Operating life: support, abuse reports, changes, suspension and escalation.
- Exit: migration, route withdrawal, record cleanup, final billing and evidence of handback.
1. Identify the prefix, parties and authority to lease
List every included prefix in CIDR notation and its RIR. Name the contracting organizations, their roles, the authorized signers and the service operator. If a broker or intermediary is involved, establish the chain of authorization from the registered holder and who is responsible for delivery.
A registry record helps identify the registered resource holder; it does not by itself prove that a particular person may sign this agreement or grant the proposed use. Verify that authority separately. Distinguish the lessee's agreed use from a registry transfer: signing a lease or receiving an LOA does not transfer the registry holding.
Record the intended workload, deployment region, origin ASN or announcing provider, and whether onward assignment or subleasing is permitted. Specify whether the exact prefix is committed or a substitute may be proposed, who must approve a substitute, and what happens if it fails the agreed acceptance criteria. Do not treat an advertised address count as a confirmed allocation.
2. Assign activation and operating responsibilities
A lease, a Letter of Authorization (LOA), a Route Origin Authorization (ROA), an IRR record and a BGP announcement serve different purposes. The APNIC RPKI explanation describes a ROA as authorization for an origin ASN and prefix, with a maximum prefix length. It is not an authorization of the complete AS path or a promise of reachability.
Ask the intended upstream or platform what it accepts. For example, SpectraIP's LOA instructions request documentary authorization for its own announcement service. That provider's requirements are not a universal LOA standard. See the LOA guide for the evidence to prepare.
| Work | Owner to identify | Evidence to agree |
|---|---|---|
| LOA and authority | Holder or authorized representative issues it; the receiving provider reviews it. | Exact prefix, authorized use and recipient, signer authority, validity period and recipient acceptance. |
| RPKI ROA | Party with authority over the relevant resource certificate. | Intended origin ASN, prefix and maxLength; validation result for each planned announcement. |
| IRR and BGP | Authorized record maintainer and the announcing network operator. | Required route objects and upstream filters, observed origin and reachability for the intended service. |
| Registry and reverse DNS | Responsible registry contact and DNS operator, with any delegated access agreed. | Applicable assignment/contact records, PTR or delegation changes, and a working change-request path. |
| Abuse and reputation | Lessee's service operator, holder/provider and named escalation contacts. | Dated baseline findings, monitored contact, response process, repair owner and agreed remedy. |
| Changes and exit | Named coordinators on both sides and each affected operator. | Change approvals, migration window, withdrawal and record-cleanup checks, final acknowledgment. |
The ARIN IRR FAQ explains routing records and the permissions needed to manage them. A lessee should not assume a contract gives it access to the holder's registry, RPKI or DNS account. Agree the service channel and change owner without sharing account credentials.
3. Connect charges to delivery and acceptance
Specify the unit of pricing, address or prefix quantity, currency, billing frequency, minimum commitment, deposits, taxes and any setup, routing, registry, support or renewal charges. Define late-payment terms and the procedure for disputed charges. A price per address alone is not a complete cost.
Separate the contract start, requested activation, acceptance and billing dates. Agree what evidence establishes delivery: required authorization accepted, expected route origin and validation status, reverse DNS where needed, and a permitted test of the intended service. Set a review window and the process for documenting a failed criterion.
Agree whether a failure leads to repair, an approved substitute, delayed billing, credit, refund or termination, and on what terms. These are negotiated remedies, not automatic i.lease commitments. Reputation and geolocation observations are dated and source-specific; no check guarantees all receivers will accept the traffic. Compare the full term with the IPv4 cost calculator using your actual quote.
4. Make renewal and notice dates explicit
Record the start and end dates with a time zone, whether renewal is automatic or requires agreement, the notice deadline and delivery method, and how receipt is acknowledged. State when a renewal price is proposed and accepted, and what happens if no agreement is reached.
Give the migration plan enough room for the agreed notice period and the dependencies on other operators. Define what happens to routing authorization if the term expires or the holder proposes a transfer during the lease. Continued use, grace periods and extensions need an explicit agreement; do not infer permission from a route that is still visible.
5. Agree abuse response, support and suspension
Describe allowed uses and prohibited activity, who monitors abuse reports, the information needed to investigate, and who can contain the affected workload. Name contacts and escalation routes that work outside the primary contact's absence. Agree any response targets and distinguish acknowledgment from resolution.
Define the circumstances for suspension, scope of the affected resources, notice where applicable, opportunity to remedy, urgent intervention, reinstatement and dispute handling. A report needs investigation; it is not automatically proof of the lessee's conduct. Keep assignment times and relevant evidence so earlier use can be distinguished from the current workload.
List the support work actually included. Delisting, geolocation updates and receiver acceptance may depend on third parties. An agreed investigation or submission does not guarantee their decision. The IP abuse response guide explains how to prepare and route a useful report.
6. Check the applicable registry and legal conditions
Identify the applicable RIR, resource status and registration obligations rather than assuming one worldwide leasing rule. ARIN's leasing guidance, for example, distinguishes leasing existing space from justification for acquiring more resources and discusses reassignment records. Confirm the current policy and contractual conditions for the particular resource with the responsible registry or provider.
Have counsel assess the governing law, permitted use, applicable restrictions, data handling and dispute provisions for the parties and deployment. Agree who supplies required information and who can make registry changes. The private lease cannot itself override registry policy or another provider's acceptance requirements.
7. Negotiate remedies and dispute handling
Discuss responsibility for unauthorized use, authority defects, missed changes, service interruption, non-payment and third-party claims. Have counsel review any liability limits, exclusions, indemnities, evidence obligations, dispute forum and enforceability. Do not assume all losses belong to the lessee or that the same wording fits every jurisdiction.
Make the operational consequence understandable alongside the legal clause: who is contacted, who investigates, what may be suspended, what can be repaired and how service or funds are handled while a dispute is open.
8. Plan an orderly exit and verify the handback
Cover normal expiry, early termination, notice and any opportunity to cure. Agree the migration and cutoff sequence with each operator before making changes. Emergency action may need a different agreed process. Removing a ROA or deleting an IRR object does not itself withdraw a BGP announcement.
- Prepare migration: move affected services, check dependencies and agree the authorized use end time, change owners and rollback conditions.
- Stop the old use: have the announcing operator withdraw the lessee's routes at the agreed cutoff and verify their withdrawal. Do not continue using the prefix after authorization ends.
- Retire the relevant permissions and records: coordinate LOA expiry or revocation, ROA and IRR updates, reverse DNS/delegation and applicable assignment/contact records with their authorized maintainers.
- Preserve other users: identify records shared with other prefixes or legitimate announcements. Change only the departing use; do not blindly delete an aggregate or shared authorization.
- Close with evidence: retain dated routing observations, completed change references and both sides' acknowledgment. Resolve final invoices, deposits and any open incident under the agreed terms.
A stale registry record and a live unwanted route are different findings. Escalate each to the party that can change it and verify again after updates propagate. A signed termination notice alone is not evidence that technical handback is finished.
Prepare a clear leasing request
Bring the quantity or CIDR, RIR or region, intended use, origin ASN or provider, requested start, term and budget. Add the responsibilities you can operate yourself and those you need coordinated. Keep the checklist with the proposed agreement so unresolved items have a named owner.
Discuss leasing requirements with i.lease or review managed IPv4 leasing. Sending a request does not reserve a prefix, accept a contract or activate service. Availability, authority, scope, price and acceptance remain subject to the actual arrangement.
Common questions about IPv4 lease agreements
What are the key terms in an IPv4 lease agreement?
Identify the exact prefix and authority, permitted use, activation responsibilities and acceptance, complete charges, term and renewal, abuse response, remedies and the exit process. Name an owner and evidence for each operational obligation.
Is an LOA the same as an IPv4 lease contract or a ROA?
No. A lease sets contractual terms. A Letter of Authorization supplies documentary permission for a recipient's process. An RPKI ROA authorizes a route origin ASN and prefix. None alone establishes successful BGP routing or transfers the registry holding.
When should billing for a leased prefix begin?
Agree the billing trigger explicitly and distinguish it from signing, requested activation and acceptance. Define the evidence of delivery and the remedy if a required criterion fails; there is no universal start date or refund rule.
Who handles abuse reports and reputation problems?
Name the service operator, provider or holder and escalation contacts in the agreement. Investigate dated evidence, assign the repair and agree any replacement or refund terms. A contract cannot guarantee a third party's delisting or filtering decision.
What happens when the IPv4 lease ends?
Follow the agreed migration and cutoff plan, withdraw the lessee's announcements, coordinate relevant authorization and record updates, and verify the result. Preserve unrelated uses and resolve final charges. Ending the contract or removing a ROA alone does not withdraw a route.
