Summary

  • LACNIC’s current merger-and-acquisition procedure begins through the offering organisation’s administrative-contact userID and asks for transaction evidence, a resource inventory, customer information and a numbering plan. A signed acquisition agreement is therefore necessary evidence, not an automatic registry transfer.
  • Buyers should measure the registry gap from legal closing to accepted holder change and operational handover. The gap closes only when exact IPv4, IPv6 and ASN schedules, service obligations, RPKI and routing controls, and customer continuity all reconcile.

Two clocks at 23:57

Imagine a regional ISP sale scheduled to close at midnight. At 23:57 the buyer releases the purchase price. The shares, fibre contracts and workforce change control. Minutes later, the integration team discovers that the only administrative contact able to open the LACNIC transfer request left the seller the previous week. MiLACNIC still reflects the old organisation; the resource schedule says only “IP assets”; nobody has mapped the live prefixes to customers, ROAs, reverse DNS or the origin ASNs that will remain after integration.

The company has changed hands. Its addresses have not yet moved in the sense that matters to a registry.

That distinction is explicit in the LACNIC Policy Manual, version 2.21. Section 2.3.2.17 says LACNIC will process and register IPv4 transfers arising from partial or complete mergers, acquisitions, reorganisations or relocations, but it also says unauthorised transfers are not recognised. Registration requires legal documentation that, in LACNIC’s judgement, supports the operation. Examples include the asset-transfer document, an inventory of the assets used to keep the resources in use, and a list of clients using them.

The current M&A transfer procedure makes the execution risk sharper. The form must be completed by the userID of the offering organisation’s administrative contact. Applicants may be asked for the resources, the receiving organisation and the reason for the transfer, plus legal evidence, an operating-asset inventory, customer information and a numbering plan justifying need. A buyer’s ownership of the target does not itself recreate a missing credential, a departed contact or an incomplete resource ledger.

Three schedules, not one asset line

“IP assets” is too vague for a closing schedule. LACNIC’s manual has separate M&A provisions for IPv4 in section 2.3.2.17, ASNs in section 3.3 and IPv6 in section 4.5. Each provision allows registration of qualifying corporate changes and each preserves a need test: the recipient must justify keeping all the resources, with surplus addressed through return or another permitted transfer.

The practical schedule therefore needs exact prefixes and ASNs, the current registered holder, the relevant administrative and technical contacts, the legal entity intended to receive them, and the service they support. It should also identify whether any IPv4 space is legacy. LACNIC’s legacy-resource guidance says that an approved transfer ends legacy treatment and brings the recipient under current rights and obligations, including membership and renewal fees where applicable.

Money and calendar matter as well. LACNIC’s current procedure says the offering organisation must be current with contractual obligations. A recipient that has not previously received LACNIC resources must sign a service agreement; an existing member whose category changes may receive a complementary invoice. A transfer or return request submitted too close to the renewal invoice due date can leave the full renewal invoice payable if processing crosses that date. The published administrative fee is a processing charge, not LACNIC’s valuation of the address space.

Registry recognition is not routing continuity

The handover has at least three control layers. The corporate layer determines who owns or controls the operating company under the deal. The registry layer determines which organisation LACNIC recognises as holder and which contacts and obligations bind it. The operational layer determines which AS originates the routes, which ROAs authorise that origin, which IRR objects and reverse-DNS delegations are current, and whether customers remain reachable.

Those layers influence one another but are not interchangeable. LACNIC’s RPKI service may be hosted through MiLACNIC or delegated to a member-operated certificate authority. A holder-record change is not evidence that every ROA, private key, route object, DNS delegation or router policy has moved correctly. Nor does a continuing BGP announcement prove that the registry handover is complete.

This is why a clean M&A plan treats registry acceptance and routing cutover as connected workstreams with separate evidence. It does not switch routes merely to make a database record look current, and it does not postpone the LACNIC request until the seller’s people and credentials have disappeared.

Evidence limits

LACNIC does not promise a universal processing time or guarantee that one standard document set will be accepted in every transaction. Its public materials do not settle property, corporate, tax or insolvency law in any country. Ordinary IPv4 market-transfer rules are useful comparisons, but they should not be imposed mechanically on every M&A registration. Private protections such as holdbacks, price adjustments or transition services depend on the transaction documents and applicable law.

The reliable fact is narrower and more useful: legal closing, LACNIC recognition and operational continuity are distinct events. A deal model that collapses them into one date hides risk precisely where the acquired network is least able to tolerate it.

Primary sources