Summary

  • Contract expiry, route withdrawal and operational cleanup are separate events. A lease can be legally over while BGP announcements remain visible, upstream filters still permit the old origin, ROAs still validate it, reverse DNS still names the old operator and customer systems still depend on the addresses.
  • The exit plan should be agreed at activation, not invented during the last week. It needs exact prefixes, time zones, notice periods, customer migration milestones, route and authorization owners, upstream contacts, emergency rules, evidence sources and a clear definition of completion.
  • A grace period is controlled migration time, not a free renewal. During grace, the lessee should stop adding customers, reduce traffic, preserve security duties and report progress. The lessor should preserve only the authority needed for safe withdrawal and should retain a hard final stop.
  • Customer migration comes before destructive cleanup. External allowlists, APIs, VPN peers, mail systems, payment partners and security controls can make an address part of business identity. A dual-running period may be necessary so customers can move before the old route disappears.
  • Transit providers must remove permission at the direct boundary. The lessee withdraws the announcement; the upstream removes customer filters and route acceptance; the lessor then removes residual RPKI and IRR authorization. Deleting a ROA alone does not guarantee that the route stops propagating.
  • Reverse DNS, RDAP or Whois contacts, RPKI, IRR and reputation records do not move on one clock. Each must have a named owner, observation method and exception record. A changed registration line cannot prove that routing, delegation and reputation are clean.
  • Reuse should follow risk, not ritual. A prefix that served stable enterprise access may need little cooling time; a block leaving a proxy, bulk-mail or abuse-heavy use may need longer observation and remediation. The objective is prompt, defensible reuse after verified cleanup, not permanent quarantine.

Midnight is a legal timestamp, not a network instruction

At 23:59, a leased prefix may carry customer sessions, APIs, VPN tunnels, mail, web traffic and monitoring. At 00:00, the agreement says the right to use it ends. Nothing in BGP reads that sentence.

The lessee's routers continue to originate whatever their configuration tells them to originate. The upstream's customer filters continue to accept whatever prefix-origin pairs they were built to accept. Remote networks continue to select paths according to their policies. RPKI relying parties continue to process the published material they can retrieve. Recursive resolvers continue to follow reverse DNS delegations. Reputation systems continue to associate past and current observations with the addresses.

This is not a defect in any one protocol. It is a category error in the contract. A commercial deadline is being asked to perform technical acts that belong to several independent operators.

The opposite error is to assume that because the route remains at dawn, the lease has silently renewed. Continued propagation can be unauthorized holdover, delayed convergence, an upstream filter left in place, a forgotten backup session or a customer migration that the parties expressly allowed for a short period. BGP visibility proves observed routing, not a new contract.

The safe design gives the moments different names. Commercial expiry ends the right to add new dependence and fixes the economic boundary. Service migration moves customers and traffic. Route withdrawal ends the old origin's announcement. Authorization cleanup removes the old origin from RPKI and IRR. Registration and delegation cleanup corrects RDAP contacts and reverse DNS. Reuse readiness marks the point at which the lessor can responsibly place the prefix elsewhere.

Those moments should be close, but they need not be identical. Forcing them into one second can create an avoidable outage. Letting them drift without a hard stop can create unauthorized use and conflict with the next lessee. Governance is the discipline of controlling the interval.

The title's dawn is therefore a warning against both denial and panic. Routes after midnight are not proof that leasing cannot work. They are proof that lease exit must be engineered as a transition rather than narrated as a date.

Define completion before anyone announces the prefix

The best time to negotiate an exit is before the first customer is placed on the addresses. At that point, neither party is trapped by existing dependence and both can price the work honestly.

The lease should attach an exit schedule for each exact CIDR. It identifies the current and permitted origin ASes, every upstream expected to carry them, any authorized more-specifics, the RPKI arrangement, relevant IRR maintainers, reverse DNS operator, registration contacts, abuse contact and known reputation-sensitive uses. The schedule also gives the time zone and authoritative clock for every deadline. "Midnight" is ambiguous in a global service.

Completion must be a set of observable conditions. At minimum: the old origin has withdrawn all leased prefixes; direct upstreams no longer accept them from the former lessee; old ROAs and route objects are removed or replaced; reverse DNS no longer delegates to an uncooperative former operator; public contacts do not misdirect abuse or routing reports; customer traffic has fallen to the agreed residual level; and no unapproved announcement remains visible during the observation period.

Some conditions may be inapplicable. A lease may never have changed the direct-holder registration. A lessee may have used the lessor's reverse DNS service. An upstream may not use an IRR. The answer is not to tick every box blindly but to record why a layer needs no change.

The schedule should name evidence. A router or upstream ticket can prove a submitted withdrawal. An independent route collector can show whether the route remains visible from its peers. An RPKI validator can show current validated payloads. DNS queries can show authoritative nameservers and representative PTR answers. RDAP can show current registration data. Reputation checks can show known listings. Each source answers a different question and each has limits.

The parties should agree who can declare completion. The lessee should provide its closure evidence. The lessor should verify public state and its own credentials. The upstream should confirm filter removal. If one actor is absent, the agreement should provide an alternate method and escalation. A self-certified email saying "all routes removed" is too weak for immediate reuse.

Exit design at entry has another benefit: it reveals whether the lease term is realistic. A thirty-day lease may be cheap as capacity but unsuitable for a service whose customers need sixty days to change firewall rules. The address term and the migration burden must belong to the same commercial decision.

The parties operate on different clocks

The lessor sees portfolio availability and the date on which the prefix should return for maintenance or reuse. The lessee sees customer commitments and network change windows. The upstream sees ticket queues, filter generation and route convergence. Customers see only whether their service still works.

These clocks create predictable conflict. The lessor may have promised the block to a successor beginning on the first day of the next month. The lessee may have one enterprise customer whose next approved firewall window is a week later. The transit provider may require a lead time to change prefix filters. A reputation service may require evidence and observation before it updates a listing.

The answer is a backward plan from the final withdrawal. Customer notice begins first. Replacement addresses and routes become available. External parties update allowlists and DNS. Traffic is measured on old and new paths. Upstream filters for the replacement are tested. Only then does the old route enter a drain period, followed by withdrawal and removal of residual authority.

The lessor needs visibility into milestones, not access to customer secrets. Weekly and then daily reports can state the percentage of traffic moved, number of unresolved dependencies, expected final route time and any request for grace. The lessee should not wait until the final hour to disclose that half its customers cannot move.

The upstream also needs early notice. A transit ticket opened at 23:55 creates unnecessary uncertainty about whether the route was deliberately retained or merely forgotten. Known expiry can be placed on the provider's calendar, with a named person authorized to remove filters even if the lessee becomes unresponsive.

These responsibilities are not perfectly symmetrical. The lessee controls customer migration and its router. The lessor controls portfolio allocation and often the ROA. The upstream controls direct route acceptance. Each should warrant the acts it can perform and cooperate on the acts it cannot.

Time should be measured from acknowledgements as well as requests. If a lessor tells the lessee to withdraw but the upstream never acknowledges a filter-removal request, the risk is not resolved. If the lessee says it sent customer notice but cannot show delivery or response for critical customers, migration confidence remains low.

The useful contract is not the one with the most dates. It is the one that connects each date to a responsible actor, an observable act and a consequence if the act is late.

Inventory dependence, not just addresses

A prefix can look idle in an asset list while remaining deeply embedded in other people's systems. Safe exit begins with an inventory of dependence.

The obvious items are BGP sessions, origin ASes, transit providers, route objects, ROAs and reverse zones. The less obvious items often set the migration schedule: customer allowlists, payment-provider rules, API partners, VPN peers, SFTP endpoints, security operations centers, certificate validation assumptions, geolocation, mail-server identity, monitoring probes, rate-limit exceptions and contractual references to fixed addresses.

Lu Heng's note on network identity and customer continuity describes the point directly. Once banks, suppliers, partners and security teams recognize an address, changing it becomes a business-continuity event rather than a simple capacity swap. That insight applies even when the address is leased. In fact, a finite term makes the need to classify identity dependence more urgent.

The lessee should classify each dependency by owner, change lead time, failure impact and evidence of completion. A customer-facing website behind a load balancer may move easily. A bank that accepts traffic only from a fixed /29 may require formal approval. A mail service may technically move in an hour but need a careful reputation ramp. A VPN peer in a heavily regulated organization may have one change window per month.

The inventory should also identify hidden downstream users. A reseller may have assigned addresses to customers. A managed-security provider may be advertising a more-specific during mitigation. A backup transit session may be quiet but able to re-originate the block. Reverse DNS may be delegated to a customer-run nameserver. None should be inferred only from the primary network diagram.

External observations help test completeness. Historical routing can reveal origins or more-specifics that the current list omits. Reverse DNS can expose active naming conventions. Abuse tickets can identify downstream services. These observations are prompts for verification, not proof of the legal relationship.

The lessor does not need every customer name to protect its prefix. It needs confidence that dependencies have been counted and that high-risk migrations are progressing. Confidential schedules can remain with the lessee or an agreed reviewer, while aggregate milestones support the lessor's planning.

Without this inventory, grace periods become guesses. With it, the parties can distinguish a genuine continuity need from delay caused by poor preparation.

Notice should become progressively more specific

One reminder thirty days before expiry is not an exit plan. Notice should tighten as uncertainty falls.

An initial notice several months ahead can confirm whether the lease will renew, end or change size. It asks the lessee to validate the prefix inventory, identify replacement capacity and list long-lead customer dependencies. It gives the lessor time to avoid promising the same prefix to a new user before the exit is feasible.

A second notice can confirm the replacement routes, upstream contacts, RPKI and IRR change owners, reverse DNS destination and expected residual traffic. By this stage, any request for contractual grace should be reasoned and bounded. "Customers need more time" is not enough; the request should identify how many dependencies remain, the dates available and what restrictions will apply during the extension.

In the final week, notice becomes operational. It states the change window, old and replacement origins, sequence of traffic drain, direct provider tickets, contact bridge and stop conditions. If a critical dependency fails, the parties know who may pause the withdrawal and for how long.

On the final day, notices should not introduce new facts. They should confirm readiness. The lessee reports traffic and customer status. The upstream confirms filter actions. The lessor confirms the timing for ROA, IRR and reverse DNS changes. Everyone uses the same UTC reference even if the commercial agreement names a local zone.

After withdrawal, notices become evidence. The former lessee confirms router and session changes. The upstream confirms that the prefix is no longer accepted from that customer. The lessor reports observed BGP and RPKI state. Any remaining visibility is assigned for investigation rather than treated as an accusation.

Notices need authenticated recipients. A billing contact may not reach the network team. A technical contact may lack authority to extend the lease. Role addresses should be backed by named individuals and out-of-band contacts. The parties should test them during the term, not discover bounced email during termination.

Progressive notice protects both sides. It prevents a lessor from creating surprise at midnight and prevents a lessee from using surprise as a reason for indefinite holdover. It turns expiry from a single threat into a sequence of increasingly verifiable commitments.

A grace period is a controlled descent

Grace is often described as generosity from the lessor or weakness in enforcement. It is better understood as a risk-control interval.

During grace, the commercial term has either been briefly extended or the parties have granted limited holdover rights for migration. The agreement should be explicit about which. Payment, liability, abuse duties and routing authority must remain defined. Ambiguity can leave the lessee using addresses without clear protection and the lessor accepting risk without compensation.

The lessee should enter a restricted mode. No new customers should be placed on the prefix. No new origin or more-specific should be added unless needed to complete migration safely. Traffic should decline according to milestones. Customer communications and unresolved blockers should be reported. Security and abuse response must continue at full strength; an expiring service is not an abandoned service.

The lessor should preserve the minimum authorization necessary for orderly exit. It should not revoke the only valid ROA while agreed traffic remains, but neither should it broaden authority or allow the grace interval to renew automatically. A hard authorization-end time remains necessary.

The upstream can help by marking the final filter-removal date, watching traffic decline and refusing additions outside the existing prefix set. If the lessee misses milestones, the parties can shorten the remaining grace or require a more intensive migration plan. If a critical third-party change window is documented, they can extend narrowly rather than improvise a full renewal.

Grace may carry a higher price because it blocks the lessor's next use and requires continued support. That price should be agreed in advance rather than used as punitive leverage during a crisis. A pre-priced daily or weekly holdover rate creates a known option without making delay free.

There must also be an emergency exception. Active abuse, fraud, a compromised route or a legal order may make continued service unsafe. Even then, the parties should coordinate with the direct upstream because ROA removal alone may not stop the route. Emergency termination changes the sequence and notice; it does not eliminate the need to verify withdrawal.

Controlled descent is not endless descent. A final date, declining traffic, bounded authority and observable progress distinguish safe grace from occupation without consent.

Move customers before removing the old path

The central continuity principle is make before break: establish and test the replacement before taking away the path on which customers depend.

RFC 6198 describes graceful shutdown requirements for planned BGP session maintenance. Its goal is to let alternate paths become available before the old path disappears, reducing packet loss during convergence. RFC 8326 standardizes the GRACEFUL_SHUTDOWN community and procedures that can lower preference before a deliberate session shutdown. A lease exit is broader than router maintenance, but the operational principle is relevant: planned change should steer traffic toward a ready alternative before removing the existing route.

The replacement may be a different leased prefix, transferred space, provider-assigned addresses or a customer-owned range. It should be routed, filtered and monitored before customers are told to use it. Forward DNS can expose both old and new destinations during a transition where the application supports that design. Load balancers, NAT, proxies or application gateways may permit parallel service. The method depends on the service; the principle is overlapping reachability with a clear end.

Customers should receive more than a new CIDR. They need the activation date, old-address retirement date, required allowlist or VPN changes, test endpoint, rollback contact and confirmation method. High-dependence customers may require bilateral testing.

Traffic measurements should show the old prefix declining. Zero traffic is not always attainable because scanners, stale DNS caches and abandoned clients can persist. The parties should distinguish meaningful customer traffic from background noise. A threshold can be set for final withdrawal, with named exceptions that will fail closed after the deadline.

Mail and security-sensitive uses may need special handling. A new sending IP can have little positive history, while the old address may remain in partner allowlists. A staged move and reduced volume can be safer than an abrupt switch. That is a service decision, not a reason to retain the old lease indefinitely.

Make-before-break also applies to administrative dependencies. New ROAs and upstream filters should be ready for the replacement. Reverse DNS should resolve appropriately. Abuse contacts should be staffed. The replacement is not ready merely because a ping succeeds.

The lessor should not dictate the lessee's application design, but it is entitled to evidence that the migration is real. Traffic trend, customer completion counts and successful replacement-route tests provide that evidence without exposing every business detail.

Withdraw at the origin and close the direct gate

When the migration threshold is reached, the lessee should withdraw the prefix from every old origin. The direct upstreams should then close the customer permission that allowed those announcements.

BGP's base specification, RFC 4271, provides the mechanism by which routes are advertised and withdrawn. In practice, a leased prefix may be present through several sessions, routers or providers. Removing one primary announcement is not enough if a backup remains. The exit inventory must cover all origins and sessions.

The upstream confirmation is essential because the old customer may become unresponsive or misconfigure a router later. Removing the accepted prefix from the customer's filter prevents a new announcement at the nearest contractual boundary. It also gives the lessor stronger evidence than waiting to see whether the former route returns globally.

The MANRS actions for network operators place responsibility on networks to ensure the correctness of their own and customer announcements and to maintain reachable contacts. The detailed MANRS implementation guide emphasizes accurate operational communication and verifiable routing information. Lease exit is a direct application of those norms: the upstream knows the customer relationship and can remove permission when it ends.

Observation should begin immediately but remain cautious. The RIPE Routing Information Service collects BGP data from peers through distributed route collectors. RIPEstat routing history can show observed origins and visibility over time. These are valuable independent views, but no collector sees every local or private path.

If the route remains visible, determine the source. It may be a second upstream, a more-specific, stale observation, route-server path or unauthorized continuation. Contact the originating network and direct provider through known channels. Do not assume that deleting more records will solve a route that is still being accepted at its source.

The desired result is convergence of evidence: lessee confirmation, upstream filter closure and disappearance from multiple independent observations. No one source is conclusive alone, but together they make reuse safer.

RPKI should follow the route plan, not substitute for it

RPKI cleanup is necessary because a former lessee should not remain cryptographically authorized after the right to route ends. Its timing must follow the withdrawal plan.

Before the old route is withdrawn, the lessor should confirm that any replacement origin has the ROAs it needs. During an agreed drain period, the old origin may remain authorized so that traffic does not become RPKI Invalid while customers move. Once the route has been withdrawn and the direct upstream has closed its filter, the old ROA should be removed or changed without unnecessary delay.

The order matters. Delete too early and networks applying origin validation may reject traffic before the service is ready to end. Delete too late and the former origin retains a signed authorization that can make a continued or renewed announcement look valid at the origin layer.

A ROA is not an off switch. RFC 9582 defines it as authorization for an AS to originate specified prefixes. If the ROA disappears, the route may become Not Found rather than Invalid, depending on covering authorizations. Even an Invalid route may still propagate through networks whose policies do not reject it. Direct withdrawal and upstream filtering remain primary.

The lessor should inspect overlaps and maximum lengths. An aggregate ROA may continue to cover the former route. A ROA containing several prefixes may require editing rather than wholesale deletion. In delegated RPKI, a subordinate certificate may need revocation only after confirming that it contains no continuing lease. Certification boundaries designed around customer boundaries make exit much safer.

Public validation should be checked after the change. The lessor should record what independent validators show and when. Different relying parties retrieve and process published material on their own cadence, so a successful portal action is not proof of universal instant removal.

ARIN's 2025 transfer practices are written for resource transfers, not leases, but the operational warning is instructive. ARIN tells source and recipient organizations to coordinate ROAs, IRR objects and reverse DNS rather than assume those layers follow a registration event automatically. A lease exit has the same coordination problem without a formal holder change to force attention.

The completion record should state the old origin, affected prefixes, removal time, observed validated state and any deliberate residual authorization. "RPKI cleaned" is too vague for a portfolio that may contain overlapping customers.

IRR records and upstream filters need separate closure

IRR route objects can describe which origin AS is associated with a prefix and can feed operator filters. They are not automatically the same thing as a ROA, even where tools can create matching records.

ARIN's ROA documentation explains that its IRR Auto-Manager can create matching route objects but also allows IRR objects to be managed independently. Deleting a ROA can leave an IRR object if the user chooses, and deleting an IRR object does not alter the corresponding ROA. ARIN's IRR API guide likewise documents separate create, update and delete operations for route objects.

That independence is useful during migration but dangerous at exit. A lessor may remove the ROA and assume the old route permission has vanished while an upstream continues to build a filter from a stale IRR object. Another upstream may use RPKI only. A third may combine data with manual customer records. The same prefix can therefore encounter different acceptance decisions.

The exit inventory should list every known route and route6 object, maintainer, source IRR and origin. The party with authority to remove each entity must be identified before termination. Mirrored data may persist after the authoritative entity changes, so checks should distinguish the source from copies.

The direct upstream should disclose which information created its filter and confirm that the customer entry itself has been removed. Waiting for an automated rebuild may be acceptable if the timing is known and monitored. A manual exception should be removed explicitly.

The lessor should also avoid creating a false new record before the successor is ready. Publishing the next lessee's origin too early can authorize or filter a route that should not yet exist. Preparation may occur in a controlled change window, but activation and old-route closure should be sequenced.

IRR cleanup is not glamorous, which is why it is often skipped. Yet a stale route object is a durable statement that other networks may still use. Safe leasing requires statements of authority to end when the authority ends, whether those statements are cryptographic, contractual or registry-based.

Reverse DNS is part of operational identity

Reverse DNS often survives the route because its failure is less visible than a BGP outage. That does not make it harmless.

RIPE NCC's reverse-delegation guide explains that reverse DNS maps addresses to names through in-addr.arpa for IPv4 and that delegated nameservers are represented in registry-managed domain entities. Applications, mail systems, logs and incident responders can rely on those names.

Before exit, identify who operates the authoritative reverse servers and who can change the delegation. If the lessee runs them, the lessor needs a destination for the post-lease zone: its own servers, a neutral temporary service or the next operator's servers when ready. The receiving service should be configured before the delegation changes.

The contents require care. PTR records naming the former lessee's mail hosts, VPN endpoints or customers should not persist into the next use. They can mislead incident response and interfere with mail policy. Yet deleting the whole zone too early can break a live service during migration. As with routing, readiness comes before destructive cleanup.

TTL values should be reviewed in advance. Lowering them shortly before the change can reduce stale answers, but only if done early enough for previous values to expire. The parties should test delegation and representative PTR answers from outside their own network after the cutover.

Subdelegations create another layer. A lessee may have delegated portions of a reverse zone to customers. Those customers need notice and a final date. The lessor should know whether the delegation tree contains child zones before declaring the prefix clean.

The successor should not inherit old names by accident. A neutral empty or generic reverse position may be safer during a short preparation interval than immediately publishing names for the next use. The appropriate choice depends on mail, customer and service requirements.

Reverse DNS proves why a changed Whois or RDAP line is not enough. The holder record can remain stable throughout a lease while operational naming moves twice. Safe exit follows the authority actually used, not only the most prominent public record.

RDAP and contact handoff must reflect roles honestly

RDAP is a structured way to retrieve registration information. It should help operators find the right party, but it cannot be asked to disclose a relationship that was never registered.

RFC 9083 defines the JSON responses and common data structures used by RDAP, including entities, roles, notices, events and links. RIR implementation and privacy practices determine which contacts appear for a particular resource. A lease may leave the lessor as the direct registrant while placing technical or abuse responsibility with the lessee through reassignment, reallocation or separate records where supported.

At exit, update only what actually changed. If the lessee's technical or abuse contact appears publicly, remove or replace it when responsibility ends. If the lessor remained the sole visible contact, confirm that its abuse and routing desks can handle reports after the lessee leaves. Do not insert the next operator before that operator has accepted the duty.

Contact accuracy matters during the observation period. Networks may see a lingering route and use RDAP or Whois to find help. If the record points only to a departed employee, remediation slows. The MANRS network-operator program treats globally accessible, current contact information as a basic routing-resilience duty for this reason.

The parties should preserve historical evidence privately even after public contacts change. The lessor may need to route an abuse report concerning conduct during the lease to the former lessee. The former lessee may need to show that a later incident occurred after withdrawal. Retention periods and privacy duties should be specified.

RDAP output also has interpretive limits. A current response is not a complete history of every lease, route or contact. A last-changed event does not prove the exact time at which a route stopped. Entity names can reflect registration structure rather than day-to-day operation. The exit record should use RDAP as one layer, not a complete certificate of cleanliness.

The public objective is straightforward: a person responding to a route, abuse or reverse-DNS problem should reach an actor who currently has the power and duty to help.

Reputation cleanup needs a before-and-after record

Address reputation is not a single public score. Mail providers, security companies, fraud systems, geolocation services and private networks observe different behavior and update at different speeds.

The lease should begin with a dated baseline and end with another. For each /24 or smaller operational unit where tools permit, record known blocklist status, mail use, abuse cases, proxy or hosting exposure, geolocation and any service-specific restrictions disclosed by the lessee. The comparison will not reveal every private model, but it creates a factual starting point for disputes and reuse.

Spamhaus's IP and Domain Reputation Checker is one public example. Its troubleshooting guidance explains that a listing can affect email delivery and that remediation may depend on correcting behavior, PTR and mail identity before requesting removal. Its XBL guidance also notes that different networks may synchronize removals at different speeds. This is why a clean result in one tool at one moment cannot certify universal reputation.

The lessee should close active abuse cases, stop customer services, remove compromised systems and provide evidence needed for legitimate delisting. The lessor should not file a false removal claim while the cause is active, nor should it treat every historical listing as permanent contamination. The next user should receive the known history and any remaining caveat appropriate to the transaction.

Cooling time should be risk-based. A stable enterprise VPN prefix with no mail and no meaningful abuse history may be ready soon after routing and identity cleanup. A prefix used for open proxies, high-volume mail or rapidly changing hosting customers may need longer observation, stricter tests and staged reuse. A fixed thirty-day quarantine for every block wastes scarce capacity without necessarily addressing the cause.

Reputation remediation also interacts with reverse DNS and RDAP. A delisting request may require the party controlling the block or the ISP's abuse desk. Stale contacts can prevent the former or new operator from proving authority. A PTR naming the old mail host can undermine the successor's configuration.

The lessor and lessee should allocate cost based on cause and disclosure. Pre-existing documented issues belong in the entry baseline. Harm created during the lease may justify a cleanup reserve, holdback or reimbursement. Unknown private scores remain a limitation that neither party can eliminate completely.

The aim is not to promise a perfectly clean prefix. It is to leave a documented prefix whose remaining reputation risk is known well enough to price and manage.

Scheduled expiry, breach and emergency are different exits

One exit sequence cannot fit every reason for termination.

Scheduled expiry is the easiest case. Notice is long, replacement capacity can be prepared, customers can move, traffic can drain and every administrative layer can be reconciled. The contract should make this the default rather than relying on repeated informal renewal.

Non-renewal after a commercial disagreement still permits planning if notice is timely. The parties may dislike each other, but neither benefits from creating third-party outages or disputed routes. A bounded grace option can isolate migration from the disagreement.

Termination for non-payment needs a cure period proportionate to the service and previous notice. The lessor should not be forced to finance indefinite use, yet immediate ROA deletion may not stop the route and can harm customers before it secures payment. Direct upstream coordination and a hard withdrawal date are more reliable.

Active abuse or a security compromise can require faster action. The relevant route may need to be filtered, a customer disconnected, credentials disabled or a ROA corrected. The direct provider and incident contacts should act together. "Emergency" should be defined by evidence and impact, not used as a label for every breach.

Insolvency or disappearance is different again. The lessee may have no staff capable of withdrawing. The upstream's agreement and filter control become critical. The lessor may need to contact network providers directly, preserve evidence and seek legal relief. The entry schedule should authorize the upstream to accept a closure instruction from the lessor after defined proof and failed attempts to reach the lessee.

A court or regulator may order action that overrides the ordinary sequence. The parties should preserve the order, identify exactly which prefixes and acts it covers, and avoid extending it by interpretation. Technical cleanup still needs verification after compliance.

Different exits can share one principle: use the narrowest action that stops the relevant risk while preserving unrelated customers where possible. A disputed invoice is not a compromised route. A compromised route is not an excuse for indefinite portfolio seizure. Precision protects leasing from both abuse and overreaction.

Reuse requires an acceptance test

The end of the old lease is not automatically the beginning of safe new use. The lessor needs an acceptance test before handing the prefix to a successor.

First, confirm route absence or approved successor visibility from several observations over the agreed period. Check aggregates and more-specifics. Confirm the old upstream has removed customer permission. Investigate any residual origin rather than assuming it is harmless.

Second, reconcile authorization. The former origin should not remain in active ROAs or authoritative IRR route objects. Any delegated certificate should be closed or constrained correctly. The successor's authorization should appear only when its route is ready.

Third, test reverse DNS and contacts. Authoritative nameservers must answer as intended, old subdelegations should be gone, and representative PTR records should not identify the former operator. RDAP or Whois should lead incident reporters to a current responsible party.

Fourth, assess reputation. Re-run the same public checks used at entry and record unresolved cases, geolocation lag and mail restrictions. The test should state uncertainty rather than convert partial visibility into a warranty.

Fifth, check customer and application residue known to the lessor. Unexpected inbound traffic may reveal stale dependencies, but packet observations must be handled lawfully and minimally. The objective is to detect material holdover, not inspect former customers' communications.

The acceptance result can be green, conditional or blocked. Green means the known layers are reconciled and the remaining uncertainty is ordinary. Conditional means reuse is possible for a limited use that does not depend on the unresolved layer; for example, non-mail infrastructure may tolerate a mail-specific reputation issue. Blocked means an active old route, unresolved delegation or severe continuing abuse makes new assignment unsafe.

Acceptance should produce a compact handoff record: prefix, prior origin, withdrawal time, observation window, RPKI and IRR state, DNS state, contact state, reputation findings, exceptions and approver. That record helps the successor distinguish inherited conditions from its own later operation.

The test does not need to become a new gatekeeper over every business model. It is a seller's quality control for a scarce operational input. Prompt reuse and careful reuse are compatible when evidence is gathered continuously rather than starting after the deadline.

Incentives should reward clean return

Leases end better when the economics make cleanup valuable before conflict begins.

A security deposit or final payment holdback can be tied to measurable return conditions: route withdrawal, upstream closure, ROA and IRR reconciliation, reverse DNS handoff, contact correction and delivery of the exit record. The amount should reflect likely cleanup cost, not serve as a hidden penalty.

The lessee can earn faster release by preparing early and providing complete evidence. If the lessor delays its own ROA or reverse-DNS act, the lessee should not lose the holdback for that delay. Each condition must map to the actor who controls it.

Pre-priced grace creates another useful incentive. The lessee knows the cost of extra migration time, and the lessor can price delayed reuse. Milestone failure can increase reporting or shorten the option. Successful early return can reduce the final charge.

The lessor should avoid double-booking the prefix so tightly that any ordinary convergence delay creates a breach with the successor. A short preparation interval can be priced into the portfolio. The next lessee also benefits from receiving a cleaner block with documented state.

Transit providers can improve the market by offering standard prefix-onboarding and closure commitments. Published lead times, evidence requirements and emergency contacts reduce last-minute exceptions. Providers already control the nearest acceptance point; treating closure as a service rather than an informal favor makes accountability clearer.

Reputation reserves should be evidence-based. A lessor should not retain money merely because a public score changed after the lease if the change is unrelated or pre-existing. A lessee should not deny responsibility for active abuse documented during its use. Entry and exit snapshots narrow the argument.

These mechanisms support leasing rather than suppress it. A market becomes more liquid when entities know that resources can return on time, customers can migrate without surprise and the next user will not inherit unpriced operational debris.

Lu Heng's discussion of managed IPv4 leasing emphasizes that operability continues after the visible transaction. Clean exit is the other half of that proposition. The value of managed leasing is not only obtaining a route; it is being able to end one without losing control of customers, credentials or the prefix's next use.

A safe exit receipt is stronger than a changed Whois line

The enduring mistake is to treat the public holder record as proof that everything else has changed. In many leases the holder never changes, so Whois or RDAP can look identical before, during and after operational use. Even where contacts change, the route, ROA, IRR, reverse zone and reputation can tell different stories.

A safe exit receipt joins those stories without pretending they are one system. It records the commercial end, migration window, final route time, direct provider closure, authorization cleanup, delegation cleanup, contact position, reputation state and observation limits. It names unresolved exceptions.

The receipt is useful to every party. The lessor can reuse or re-lease with evidence. The former lessee can show when its responsibility ended. The upstream can close a customer authorization cleanly. The successor can understand inherited conditions. An investigator can distinguish stale data from current use.

No receipt can prove that every router on the Internet forgot the route or every private reputation model updated. That is why the observation sources and limitations matter. Route collectors have finite peers. Caches refresh at different times. Private allowlists can persist. A strong record states what was tested, when and from where.

The standard should remain proportionate. A small, stable lease with one upstream and no reverse delegation needs less work than a multi-provider hosting block with customer subdelegations and mail use. The required layers are the same; the depth follows the risk.

Most importantly, the receipt should not become an excuse to block the return forever. If the old route is gone, direct permission is closed, authority is reconciled and known identity risks are documented, ordinary uncertainty can be priced. Scarcity makes unnecessary idle time costly.

Safe return is therefore neither instant cleansing nor indefinite quarantine. It is a reasoned decision based on converging evidence.

Leasing works when exit is part of the product

IPv4 leasing solves a real problem. Operators need addresses without always buying a permanent block; holders can put idle capacity to work; customers can launch services despite scarcity. The case for safe exit is not a case against that market.

It is a case against pretending that a private end date automatically propagates through global routing and its supporting records. The market becomes fragile when activation is managed carefully but termination is left to a final email.

A mature lease begins with the exit schedule. It inventories dependence, gives meaningful notice, prices grace, prepares replacement service, moves customers, drains traffic, withdraws every origin, closes direct upstream filters, removes stale RPKI and IRR authority, hands off reverse DNS, corrects contacts, records reputation and tests readiness for reuse.

Each actor has a clear duty. The lessee migrates customers and withdraws. The upstream closes acceptance. The lessor manages residual authorization and the next use. Registries and public services reflect the changes within their actual remit. Evidence travels between them.

The sequence protects both continuity and revocation. Customers are not disconnected merely to prove that a contract date is real. Former lessees do not retain indefinite routing permission merely because customers once depended on the addresses. Lessors do not inherit unexplained reputation damage. Successors do not discover stale authority after launch.

At midnight, the legal right can end. At dawn, the old route should either be gone or present only under a documented, declining and time-bounded migration period. Soon after, the public and operational records should converge on the new reality.

That is not tolerance for unauthorized routing. It is how authorization is withdrawn safely enough to be final.

Sources