LACNIC permits intra-regional and inter-RIR IPv4 transfers, with strict needs-based tests, cooling-off periods, and a public transfer log.
Ownership changes through mergers and acquisitions are processed with legal proof and—by Board decision—no LACNIC processing fee.
Why this matters now
Scarcity of unused IPv4 addresses has reshaped how networks in Latin America and the Caribbean acquire or dispose of address space. LACNIC (the Regional Internet Registry for the region) formally exhausted its IPv4 pool in August 2020, which elevated the role of transfers and organisational ownership changes in keeping networks growing without disruption.
This article explains how LACNIC handles IP transfers and ownership changes, what operators must prepare, the differences between intra-regional and inter-RIR (inter-registry) movements, and the post-transfer housekeeping required in WHOIS, IRR and RPKI so routes keep flowing.
LACNIC’s policy backbone: the essentials
The authoritative source is the LACNIC Policy Manual, which sets out the criteria and procedures for IPv4 transfers and for ownership changes due to mergers, acquisitions, reorganisations or relocations (often abbreviated to “M&A”). The manual is explicit that LACNIC does not recognise unauthorised sales, except for the transfer frameworks established in section 2.3.2.18 (IPv4 transfers) and the M&A mechanisms in section 2.3.2.17.
Some cornerstone rules:
Minimum size of an IPv4 block that may be transferred is /24. (“The minimum block size that may be transferred is a /24.”)
LACNIC maintains a publicly accessible transfer log recording date, offering and receiving organisations, block(s), and—in inter-RIR cases—the source and destination RIRs.
Cooling-off periods apply: the offering organisation becomes ineligible for new IPv4 from LACNIC for one year after the transfer; the transferred block itself cannot be retransferred for one year; and any addresses allocated or assigned by LACNIC cannot be transferred for three years from their original allocation date.
When the legacy prefixes are brought into the LACNIC region through an inter-RIR transfer, they no longer retain the legacy status.
Because the operations are consider as the high-impact and sensitive, LACNIC applies a rigorous review process. It first verifies that the resources involved are not subject to dispute. Next, it requires proper legal documentation: for intra-regional transfers, this means a signed legal instrument from both parties
Intra-regional IPv4 transfers: how LACNIC handles them
What they are. Intra-regional transfers move IPv4 blocks between two LACNIC-region holders (LIRs or end users). Since 2016, these have been allowed without requiring an M&A—a deliberate move by the community to support operational flexibility under IPv4 scarcity.
LACNIC’s guidance states clearly that intra-regional IPv4 block transfers are allowed in the service region without the need for a merger or acquisition, subject to policy.
Eligibility and needs test. The recipient must pass a needs-based justification before LACNIC will register the transfer—this is the same philosophy used across RIRs to ensure stewardship of a finite resource. (“In order for an organization within the LACNIC region to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 resources before LACNIC.”)
Process and evidence. For intra-RIR transfers, both parties submit a signed legal document supporting the transaction; LACNIC verifies the holder and that the resources aren’t in dispute, and then updates the records upon completion. The transaction is then recorded in the public transfer log.
Practical timeline expectations. While LACNIC does not publish a clock for intra-regional cases, prior experience across RIRs suggests that well-prepared legal documentation and clear network justification are the biggest determinants of speed.
After approval. Once complete, LACNIC modifies registration data to reflect the new holder. Operators should then promptly align ROAs (in RPKI) and IRR objects to match the new reality (more on this below).
Inter-RIR IPv4 transfers: LACNIC’s procedures and coordination
What they are. Inter-RIR transfers move IPv4 blocks into or out of the LACNIC region. LACNIC implemented this capability in 2020 after community policy work and significant systems development (WHOIS, MiLACNIC, RPKI, IRR, reverse DNS and more).
Compatibility matters. Inter-RIR transfers are only possible between RIRs with compatible, reciprocal policies. As ARIN puts it, “APNIC, RIPE NCC, and LACNIC are currently the only RIRs with ARIN-compatible inter-RIR transfer policies.”
Two-registry approval. The RIPE NCC explains a core inter-RIR rule succinctly: “Inter-RIR transfers must first be approved by both the RIPE NCC and the other RIR before they can be processed.” This equally applies when the “other RIR” is LACNIC.
Inbound vs outbound specifics. LACNIC’s public guidance describes both directions. For example, in inbound cases (from another RIR to LACNIC), LACNIC contacts the recipient with terms and instructions; if accepted, it moves to documentation and verification. Outbound cases mirror this, with coordination between registries and synchronised registry updates on a target date.
Policy mirrors the intra-RIR rules. LACNIC’s transfer section applies to both intra- and inter-RIR movements: minimum /24, public logging, one-year re-transfer bar, and a three-year hold before LACNIC-allocated space is eligible to move. Where an inter-RIR transfer imports legacy space into the LACNIC region, it ceases to be legacy under LACNIC policy.
Ownership changes (M&A, reorganisations, relocations): what LACNIC requires
Scope. Beyond market transfers, LACNIC registers resource ownership changes when an entity acquires another’s network assets (in whole or part) or when legal structures change (reorganisations, relocations, or name changes). The policy exists for IPv4, IPv6 and ASNs—but remember that ASNs are only transferable under these organisational-change rules, not as “specified recipient” market transfers.
Documentation and discretion. LACNIC requires legal documentation supporting the operation—examples include an asset transfer agreement, an inventory of network assets supporting the resources in use, and a list of clients using those resources. LACNIC has discretion to request further proofs to validate the event.
No processing fee at LACNIC for M&A transfers. The Spanish-language guidance is unambiguous: “Por resolución del Directorio de LACNIC, las transferencias realizadas bajo esta política no tendrán costo alguno.” (By resolution of LACNIC’s Board, transfers under this policy carry no LACNIC processing cost.)
Return or move surplus space. Crucially, the party must justify the need to keep all resources after the transaction. If there is surplus address space, it must be returned to LACNIC (under conditions and deadlines LACNIC determines) or transferred to third parties in line with policy.
Name changes. Even a simple change of legal name must be supported by documentation validating the change so registration can be updated cleanly.
The needs-based test: what “justification” really means
The needs-based principle is the bedrock of Internet number resource stewardship. It allows address space to flow from lower-use to higher-need networks without undermining the registry’s accuracy or the routing system’s stability.
In LACNIC’s case, a recipient must justify current or near-term use of the requested space, using the same criteria LACNIC applies for regular allocations and assignments. This is why transfer recipients are “subject to the policies and membership terms and conditions of the corresponding RIR.”
Other RIRs echo this principle. ARIN, for example, explains that inter-RIR transfers require reciprocal, compatible, needs-based policy.
Cooling-off periods and other anti-flipping controls
To discourage rapid speculation and ensure records keep pace with reality, LACNIC applies several timing guards:
The offering organisation becomes ineligible to receive new IPv4 allocations or assignments from LACNIC for one year from the transfer date.
A transferred block can’t be re-transferred (in full or part) for one year after the logged date.
Any prefix allocated or assigned by LACNIC must age for three years before it becomes eligible to transfer.
Imported legacy space loses its legacy status once in the LACNIC region.
These controls are common across RIRs, though the exact timers vary. They preserve registry quality and reduce routing churn from hand-to-hand flipping.
What gets recorded: the transfer log and registry updates
Transparency is a design goal. The Manual directs LACNIC to keep a public transfer log noting date, offering and receiving organisations, the blocks transferred, and—in inter-RIR cases—the source and destination RIRs. Once complete, LACNIC modifies the registration to reflect the new holder.
At an ecosystem level, inter-RIR transactions also touch partner registries. The RIPE NCC notes that both RIRs must approve and synchronise registry updates on an agreed date. That coordination—across time zones and systems—is why inter-RIR cases generally take longer.
After the transfer: WHOIS, IRR and RPKI housekeeping
A transfer or ownership change doesn’t end when LACNIC updates the registration. Operators must align routing and security artefacts to match the new holder:
WHOIS: Ensure organisation, contact, and abuse contacts are current. (LACNIC updates holder data upon completion, but downstream maintainers should verify related records.)
IRR: Update route/route6 objects in the relevant IRR (for many LACNIC operators, that’s RADB or another IRR in the ecosystem) so upstreams and peers see correct origin and covering routes on day one.
RPKI: Re-issue ROAs under the new holder’s certificate. LACNIC’s RPKI FAQ underscores that the holder of the address block must create the ROA. Mis-aligned ROAs can turn perfectly good announcements into “Invalid” or “Unknown.”
The Number Resource Organization publishes updated RPKI best practices, a useful cross-RIR reference for teams regularising transfers and minimising route-security gaps during handover.
Market dynamics and LACNIC’s position on leasing
Transfers aren’t the only way operators seek IPv4 space; some look to leasing. LACNIC’s current posture is clear: leasing IPv4 addresses assigned by LACNIC is not allowed, and doing so may risk revocation for policy violations.
How LACNIC coordinates with other RIRs
LACNIC is one of the four RIRs (with ARIN, RIPE NCC, APNIC) which is run inter-RIR IPv4 transfers. APNIC, RIPE NCC, and LACNIC are currently the only RIRs with ARIN-compatible inter-RIR transfer policies. the requests must satisfy both sides’ policies, a practical tip for operators is to pre-clear documentation against both RIRs’ checklists to avoid last-minute surprises.
Practical checklist: preparing a LACNIC-region IPv4 transfer
For offering organisations:
Confirm eligibility and timers. Ensure you’re not within the three-year post-allocation window for LACNIC resources and note the one-year ineligibility after transfer approval.
Build the legal record. For intra-RIR cases, both parties will need a signed legal document supporting the transfer; for inter-RIR, documentation requirements are coordinated between RIRs.
Pre-plan routing transition. Prepare IRR and RPKI updates timed to the registry-update date.
Coordinate reverse DNS cutover for inter-RIR moves, since delegations shift registries and may require recreation.
For receiving organisations:
Assemble needs-based justification. Map projections to LACNIC’s allocation criteria; have utilisation evidence ready.
Ensure membership/contract status aligns with LACNIC’s requirements. The Manual makes clear recipients are subject to the policies and membership terms of the corresponding RIR.
Prepare to create ROAs and route objects as soon as the registry change finalises.
Check legacy implications if importing legacy space; it will not remain legacy in the LACNIC region.
When a corporate event changes your network: M&A scenarios
Classic case: Company A acquires Company B and continues operating B’s network. Under LACNIC rules, the new entity must register the change and provide legal documentation. If the combined network doesn’t need all the space, the surplus must be returned or transferred under policy.
The timeline: how long will it take?
Duration depends on the completeness of documentation which needs-based review complexity, and—especially for inter-RIR transfers—coordination between registries. The RIPE NCC notes inter-RIR cases require more work due to synchronised registry updates and due diligence in both regions. Practical experience: allow time for reviews and be prepared to answer clarifying questions from both RIRs.
Data points: growth in LACNIC transfers
LACNIC’s own analysis shows steady growth since policy activation: intra-RIR transfers were enabled in March 2016, with inter-RIR following in July 2020; country-level patterns show Brazil and Argentina featuring prominently on both sides of the ledger. These statistics come from a presentation by LACNIC’s Head of Registration Services.
The listing service: finding counterparties
To help counterparties find one another under policy, LACNIC maintains an IPv4 Transfer Listing Service with organisations offering or seeking space. It’s not a marketplace in the speculative sense; it’s a registry-adjacent directory to aid policy-compliant contact between parties.
Common pitfalls—and how to avoid them
Insufficient need justification. Prepare utilisation data and growth projections that match LACNIC criteria.
Forgetting ROAs. If the new holder doesn’t quickly create accurate ROAs, valid announcements can drop to Unknown or Invalid in RPKI filters.
IRR drift. Route objects in popular IRRs must reflect the new origin AS and prefix relationships on the day the registry updates.
Timing bars. Attempting to move a prefix inside LACNIC’s three-year eligibility window will be blocked; trying to re-transfer within the one-year cool-off will be too.
Legacy assumptions. Imported legacy space does not retain legacy status under LACNIC policy. Build that into your compliance plan.
Assuming leasing is permitted. It isn’t—at least not today in LACNIC’s region. Plan accordingly.
FAQs
1) Does LACNIC allow IPv4 transfers without a merger or acquisition?
Yes. Intra-regional IPv4 transfers are permitted without an M&A event, subject to needs-based justification and other policy controls (minimum /24, transfer log, cooling-off periods).
2) What is the minimum IPv4 block size LACNIC will register for transfer?
/24. That’s explicitly set in the Policy Manual’s transfer section.
3) Can I re-transfer a block I just received or offer one I was recently allocated?
Not immediately. A transferred block cannot be re-transferred for one year; and any prefix newly allocated or assigned by LACNIC must age three years before it becomes eligible to transfer.
4) Are there fees for LACNIC’s M&A ownership-change process?
LACNIC’s Board resolved that M&A transfers carry no LACNIC processing fee. You must still provide legal documentation, and LACNIC may require surplus resources to be returned or transferred out.
5) What happens to RPKI and reverse DNS when moving a block between RIRs?
Expect RPKI certificates/ROAs to be revoked or recreated as resources shift registries, and reverse DNS delegations to be removed and recreated in the receiving registry. Plan the cutover so routes don’t appear Unknown/Invalid and DNS doesn’t go dark.
