IPv4 Lease SLA Checklist: Replacement Windows, Support Response, Abuse Handling and Service Credits

An IPv4 lease SLA defines what the provider and lessee must do when a leased prefix develops an operational problem. Before companies lease IPv4 addresses, they should review replacement procedures, support response targets, abuse escalation, service credits, and the conditions that determine whether an SLA remedy applies.

An IPv4 lease SLA checklist is a structured set of service-level requirements for leased IPv4 space. It defines measurable support, replacement, abuse-response, and compensation obligations so that both parties know how incidents are reported, how quickly action must begin, and what remedy applies when an agreed service target is missed.

What should an IPv4 lease SLA include?

The SLA should use measurable terms. Phrases such as “prompt response” or “replacement as soon as possible” do not give network teams a clear operational target.

Core SLA commitments should define:

• the initial support response time;
• incident severity levels;
• escalation procedures;
• the replacement window for an eligible prefix;
• abuse-report handling;
• status-update intervals;
• eligibility for service credits;
• exclusions and customer responsibilities.

There is no universal four-hour or 24-hour replacement target for all IPv4 leases. The applicable deadline is the one stated in the contract. This is why SLA comparison should focus on documented obligations rather than assumed industry practice.

How should the replacement window be defined?

The replacement window is the contractual period between confirmation that a prefix qualifies for replacement and the availability of an alternative range.

Clear SLA replacement terms should answer:

1. What conditions qualify for replacement?
2. What event starts the SLA clock?
3. Is troubleshooting included in the measured period?
4. When must the replacement range become available?
5. Can the old and new prefixes overlap during migration?
6. Does replacement affect the remaining contract term?

Routing problems, persistent blocklisting, reputation issues, and incorrect geolocation may require different investigation procedures. The contract should therefore distinguish between the reasons for replacement.

A service schedule might, for example, specify a 4-hour acknowledgement target and a 24-hour replacement target for a defined severity level. These figures are illustrative. They become enforceable only if the signed SLA contains them.

What should SLA support terms cover?

The SLA support terms should distinguish between first response and final resolution. A provider may acknowledge an incident quickly while troubleshooting takes longer.

The agreement should specify:

• available support channels;
• support hours and applicable time zone;
• severity classifications;
• response targets for each severity;
• escalation contacts;
• update frequency during an incident;
• responsibility for routing, LOA, rDNS, and related tasks.

This distinction is important for production networks. An acknowledgement confirms that the case has been received. It does not mean that routing, reputation, or replacement issues have already been resolved.

How should abuse handling be covered by the SLA?

An abuse handling SLA should describe how reports involving spam, scanning, malware, compromised systems, or other prohibited activity are processed.

The SLA abuse response should state where reports are sent, how quickly they are acknowledged, what evidence is required, when escalation occurs, and what happens if the lessee does not respond.

For resources registered in the RIPE Database, applicable objects use an abuse-c contact, and the associated abuse-mailbox is intended to receive abuse reports. The abuse mailbox is subject to periodic validation under the applicable registry requirements. This registry requirement does not establish a commercial support-response deadline, so the lease agreement still needs its own response targets.

Abuse procedures are also relevant to organizations that lease out their IPv4 address space. The owner should know who receives complaints, who communicates with the tenant, and what events can lead to suspension or replacement of a range.

How should service credits work?

Service credits compensate the customer according to the contractual formula when a defined SLA target is missed. They should not be treated as automatic cash refunds.

The agreement should define:

• which failures qualify for credits;
• how breach credits are calculated;
• whether the customer must submit a claim;
• the deadline for filing that claim;
• any maximum credit amount;
• events excluded from SLA calculations.

For example, an SLA could grant a credit equal to 10% of one monthly lease charge after a specified breach. If that monthly charge is €500, the calculated credit would be €50. The percentage is only an example; it is not a standard IPv4 leasing requirement.

How can an SLA be tested before signing?

Network teams should test the contract against realistic incidents instead of reading the SLA only as legal text.

For each scenario, check:

• who reports the incident;
• what evidence is required;
• when the timer starts;
• who confirms replacement eligibility;
• when escalation occurs;
• how often updates are provided;
• what remedy applies if the deadline is missed.

This process can expose unclear responsibilities before a leased block enters production.

How can you review an IPv4 lease SLA before activation?

Define the service levels your team actually needs, then ask IPv4 Online to confirm which of them can be written into the lease. Replacement windows, support response, abuse escalation, and credits should be agreed before production traffic reaches the block.

Use the final SLA as an operating document, not a marketing summary. Match each incident type to a contact, response target, evidence requirement, and remedy so the team knows exactly what to do when a leased range develops a problem.