LACNIC IPv4 Transfers: Policies & Compliance Guide

Las transferencias IPv4 en LACNIC se han convertido en una de las soluciones más prácticas para organizaciones de América Latina y el Caribe que necesitan espacio de direcciones en un mercado donde el inventario IPv4 sin asignar está, a efectos prácticos, agotado. Ya sea que seas un ISP que escala su base de suscriptores, una empresa migrando infraestructura o un titular que busca monetizar bloques sin uso, entender las políticas de transferencia de LACNIC es esencial antes de comprometerte con una transacción. Esta guía recorre las reglas de elegibilidad, los requisitos de preaprobación y las buenas prácticas de cumplimiento para que tu transferencia pase la revisión sin retrasos costosos.

Entendiendo las transferencias IPv4 de LACNIC: una visión general

LACNIC, el Registro Regional de Internet (RIR) que sirve a América Latina y el Caribe, formalizó su política de transferencias IPv4 para permitir el intercambio de bloques de direcciones entre organizaciones, tanto dentro de la región como con titulares de otras regiones de servicio de RIR. Las transferencias se registran directamente en la base de datos del registro de LACNIC, lo que significa que el destinatario se convierte en el titular oficial de registro con plena responsabilidad legal y administrativa sobre el bloque.

Hay dos modelos principales de transferencia que conviene entender:

• Transferencias intra-regionales: tanto la organización de origen (vendedor) como la de destino (comprador) son miembros de LACNIC o tienen recursos en la región de LACNIC.
• Transferencias inter-regionales: el bloque IPv4 se mueve entre LACNIC y otro RIR (como ARIN, RIPE NCC o APNIC). Estas requieren cumplir con las políticas de ambas regiones, lo que a menudo implica que la organización receptora debe ser miembro del RIR de destino.

Un detalle clave de la política: LACNIC permite transferir bloques de cualquier tamaño registrados bajo la cuenta del titular, pero la organización de origen debe demostrar que las direcciones fueron obtenidas legítimamente y, en la mayoría de los casos, que el bloque que se transfiere no es necesario para cubrir su uso actual justificado. Los bloques recibidos vía transferencia pueden, a su vez, transferirse de nuevo, sujetos a la misma revisión.

¿Quién puede comprar y vender? Requisitos de elegibilidad en la región LACNIC

No toda organización puede participar en las transferencias IPv4 de LACNIC, y confirmar la elegibilidad a tiempo ahorra semanas de retrabajo. Del lado del vendedor, la organización que transfiere debe:

1. Ser el titular registrado del bloque IPv4 en la base de datos de LACNIC, sin disputas ni procesos de recuperación pendientes.
2. Tener los recursos bajo una cuenta activa, con cuotas de membresía y facturas pendientes saldadas.
3. Demostrar que el bloque no es necesario para sus propias necesidades justificadas, según su utilización actual.

Del lado del comprador, el destinatario debe ser una organización legalmente constituida dentro de la región de servicio de LACNIC, o miembro del RIR de destino en escenarios inter-regionales. Los receptores también deben tener una necesidad documentada de las direcciones. Es importante: la política de LACNIC restringe qué tan recientemente un receptor puede haber recibido recursos; las organizaciones que obtuvieron una nueva asignación poco antes de una solicitud de transferencia pueden enfrentar escrutinio adicional sobre su justificación para necesitar más espacio.

Por ejemplo, un ISP guatemalteco con un /22 recibido directamente de LACNIC puede vender el bloque completo a un proveedor de hosting colombiano, siempre que el ISP documente que sus clientes actuales ya no requieren esas direcciones y el comprador presente un plan de crecimiento que justifique el /22. El mismo bloque también podría transferirse a un comprador registrado en ARIN, pero esa transacción seguiría las reglas inter-regionales y requeriría revisión del lado de ARIN.

Preaprobación y requisitos de listado para transferencias IPv4 de LACNIC

LACNIC exige que las transacciones de transferencia cuenten con preaprobación antes de ejecutarse. En la práctica, esto significa que las partes no deberían firmar acuerdos de compra basados en suposiciones; en cambio, ambas partes presentan la solicitud de transferencia a través del proceso de LACNIC con documentación de respaldo. Los requisitos típicos incluyen:

• Una solicitud de transferencia completa que identifique ambas organizaciones y el bloque de direcciones.
• Documentación que pruebe la legitimidad de la asignación de origen (asignación original o registros de transferencias previas).
• Justificación técnica del receptor que explique el uso previsto y la necesidad de las direcciones.
• Confirmación de pago de las tarifas administrativas aplicables.

Los vendedores que se preparan para listar su espacio deberían verificar el estado del bloque en las bases de datos de enrutamiento públicas, asegurarse de que ningún anuncio fraudulento o historial de secuestro contamine el prefijo, y confirmar que las delegaciones de DNS inverso (rDNS) puedan transferirse o reasignarse sin problemas. Los compradores, por su parte, se benefician de revisar la reputación del bloque en listas negras y su historial de enrutamiento antes de comprometer fondos.

Trabajar con una contraparte verificada reduce drásticamente el riesgo en esta fase. Plataformas como IP4 Market agilizan las transferencias IPv4 de LACNIC al conectar compradores y vendedores con credenciales verificadas, puntos de referencia de precios transparentes y transacciones respaldadas por custodia (escrow), de modo que ambas partes lleguen a la revisión de LACNIC con documentación completa y defendible.

Step-by-Step Transfer Process and Required Documentation

The purchase agreement is signed. Payment sits in escrow. Now the formal LACNIC transfer starts — and this is where things either move smoothly or drag on for weeks. From what I’ve seen, the difference usually comes down to one thing: whether the documentation package was prepared before anyone hit “submit.”

1. Resource pre-validation. Check the address block’s status in LACNIC’s registry system. Confirm there are no pending disputes, that the prefix is fully allocated, and that it isn’t tied to any return commitments. Skip this and you may find out about a problem three weeks in.
2. Submission of the transfer request. The receiving organization files the application through its LACNIC account, referencing the transaction type (received transfer) and specifying the exact prefix and prefix length.
3. Documentation package. Both parties supply legal incorporation documents proving organizational identity, the signed transfer agreement, government-issued ID for the legal representatives, and — this one trips people up — justification for why the buyer needs the addresses. The recipient has to show a utilization plan that fits its allocation category. Not a vague plan. A real one.
4. LACNIC technical review. Registry staff verify the prefix is free of conflicts, that SWIP/rWHOIS data is current, and that no rogue announcements or IRR inconsistencies exist. Stale route objects left over from years ago are a classic cause of avoidable rejections. Clean them up before submitting, not after.
5. Approval and registration. Once approved, LACNIC updates the registry, the seller’s resource certificate gets revoked for that prefix, and the buyer issues a new ROA under its own certificate.

Common Compliance Pitfalls and How to Avoid Them

Even seasoned operators hit snags here. Some of these are almost embarrassingly simple — outdated contact records, mostly — but they stall reviews all the same.

• Outdated registration data. Seller records still listing former employees or dissolved parent entities will freeze the review. Audit and fix organizational contact data before the block even goes to market.
• Unresolved use agreements. Legacy space under active use agreements with downstream ISPs can’t be transferred until those agreements are formally terminated and the space reclaimed. There’s no shortcut.
• Spamhaus and abuse history. A block with a poor reputation complicates the buyer’s due diligence. Run reputation checks on every prefix before signing. Not after.
• Fragmented prefixes. Sub-allocations smaller than the registry’s minimum transferable size get rejected, as do multiple partial transfers from a single block without clean boundaries.
• Escrow bypass. Paying the seller directly before LACNIC approval leaves the buyer exposed if the transfer is denied. Funds should only move once registration is confirmed. Always.

Avoiding all of this takes disciplined pre-transfer audits and, honestly, realistic expectations about timing. Budget six to ten weeks end-to-end. Then tell your internal stakeholders, so routing changes and IPAM updates can be coordinated instead of improvised.

Conclusion: Ensuring a Smooth, Compliant IPv4 Transfer

LACNIC IPv4 transfers reward preparation. Organizations that validate resource status, clean their registry data, document utilization needs properly, and route payments through escrow consistently close faster — and with far fewer objections from the registry. IPv4 scarcity keeps pushing prices up across all the regional registries, so a compliant transfer isn’t merely administrative box-ticking. It’s a financial safeguard for what is often a seven-figure asset. Working with a knowledgeable marketplace partner cuts friction at every stage: IP4 Market provides verified sellers, escrow-protected payments, and current pricing benchmarks, giving network engineers and IT managers confidence that their LACNIC transfers will close cleanly, on schedule, and in full regulatory compliance.