Migración de IPv4: planificación sin interrupciones

La migración de IPv4 sigue siendo una de las operaciones más delicadas que se ponen sobre la mesa en un equipo de red. Sobre todo cuando hay que mover servicios entre bloques distintos, ampliar espacio después de agotar los prefijos propios, o consolidar infraestructura tras una fusión (caso más común de lo que parece). Un plan bien atado evita caídas de servicio, problemas de entregabilidad de correo y conflictos de enrutamiento. Aquí desgloso el proceso por fases: planificación previa, auditoría de recursos y opciones para conseguir espacio de direcciones. Si al final necesitas bloques adicionales, plataformas como IP4 Market permiten operar con vendedores verificados y precios razonablemente competitivos, lo que simplifica bastante ese paso.

¿Por qué planificar la migración de IPv4 antes de tocar la red?

Una migración improvisada se nota. Y rápido: sesiones BGP que no convergen, filtrados en listas negres (DNSBL) por reutilizar espacio con mala reputación, cortafuegos con reglas ligadas a IPs concretas que nadie documentó nunca. Planificar antes sirve, ante todo, para reducir el riesgo operativo y económico.

• Ventana de mantenimiento: decide con antelación si harás corte limpio, migración por fases o doble ejecución (running both) durante semanas. Cada opción tiene un coste distinto en complejidad DNS y NAT.
• Dependencias ocultas: licencias de software atadas a IP, listas de permisos en proveedores, SPF/DKIM, peers de interconexión, sesiones IPsec. Levantar el inventario de dependencias en una reunión es infinitamente más rápido que hacerlo en plena incidencia.
• TTLs DNS: baja los TTL de los registros A/AAAA a 300-600 segundos al menos 48 horas antes de la migración. Es el consejo más simple de esta lista y el que más dolores de cabeza ahorra.
• Plan de rollback: si la migración falla a mitad, necesitas poder volver al estado anterior sin reconfigurar todo de nuevo. Documenta el estado previo con exportaciones de configuración.

El tiempo invertido en planificar se recupera con creces la primera vez que algo falla y tienes un procedimiento claro que seguir. Y algo siempre falla.

Inventario y auditoría: qué recursos IPv4 tienes y cuáles necesitas

Antes de mover nada, hay que saber exactamente qué se tiene. Suena obvio, pero muchas organizaciones descubren en plena migración que tienen prefijos sin usar, asignaciones heredadas de adquisiciones anteriores o subasignaciones informales que jamás se registraron en el RIR correspondiente.

Qué documentar

1. Prefijos y su estado registral: bloques PA asignados por un ISP, PI registrados en RIPE NCC, ARIN, LACNIC o APNIC, y quién es el titular real. Un prefijo PI con la titularidad sin actualizar en la base del RIR no se podrá transferir ni anunciar limpiamente.
2. Utilización real: usa datos de NetFlow, SNMP o herramientas de IPAM para medir el porcentaje de uso por prefijo. Ojo aquí: RIPE exige una utilización del 50 % para ampliar asignaciones, así que estos datos importan y mucho.
3. Objetos y validaciones: objetos route/route6 en la base del RIR, ROAs de RPKI vigentes y su validez. Un ROA desactualizado que no cubre el nuevo origen del prefijo provocará rutas inválidas en redes con filtrado estricto.
4. Reputación: comprueba los bloques en DNSBL y en servicios de reputación de correo. Un /24 con historial de spam arruinará la entregabilidad de tu plataforma de correo. Lo he visto pasar más de una vez, y arreglarlo cuesta meses.

El resultado de esta auditoría debería ser una lista de recursos con su estado legal, técnico y de utilización, más la brecha entre lo que tienes y lo que necesitas para el proyecto. Esa brecha, ni más ni menos, define la estrategia de adquisición.

Compra, alquiler o transferencia: opciones para conseguir bloques IPv4

Con el inventario claro, toca decidir cómo cubrir el déficit. Las tres vías habituales tienen perfiles de coste y riesgo muy distintos, y conviene conocerlos antes de comprometerse con ninguna.

Compra (transferencia)

Es la opción definitiva: el prefijo pasa a ser tuyo mediante una transferencia entre titulares registrada en el RIR (RIPE NCC, ARIN, etc.). Los precios de referencia recientes rondan los 30-50 USD por dirección, es decir, entre 7.500 y 12.500 USD por un /24, con variación según la región y el tamaño del bloque. Requiere contrato de transferencia, verificación del RIR y, en muchos casos, un LOA y la actualización de objetos route y ROAs. Procesos con vendedores verificados, como los que ofrece IP4 Market, reducen el riesgo de fraude y aceleran la parte registral.

Alquiler (leasing)

El arrendamiento funciona bien para necesidades temporales: un despliegue CGNAT puntual, un cliente de hosting con pico de demanda, pruebas de capacidad. Los precios típicos van entre 0,30 y 0,60 USD por IP y mes, con contratos de 12 a 36 meses. La titularidad sigue siendo del arrendador, pero tú recibes un LOA que te permite anunciar el prefijo y crear tus propios objetos en el RIR. Un detalle importante: verifica siempre que el LOA permita crear el ROA con tu ASN como origen, o el filtrado RPKI te pasará factura.

Reasignación interna y alternativas

Antes de gastar, vale la pena revisar si puedes recuperar espacio: renegociar subasignaciones a clientes inactivos, reutilizar rangos internos con NAT o ampliar con la propia asignación del RIR si superas el umbral de utilización. En muchos proyectos, una combinación de recuperación interna más un /23 en alquiler cubre la necesidad sin comprometer capital.

Sea cual sea la vía, documenta la titularidad y los permisos de anuncio desde el primer día. Es la base sobre la que se apoyará todo el resto del plan de migración.

Fases de la migración de IPv4: despliegue gradual y pruebas de enrutamiento

Nadie migra IPv4 de golpe. Y quien lo hace, suele pagarlo. El despliegue por fases existe precisamente para eso: detectar los problemas de enrutamiento cuando el impacto todavía es controlable y no tienes media red caída a las tres de la madrugada. Un enfoque que funciona bien, y que he visto aplicar más de una vez, consta de estas etapas:

1. Dual-stack paralelo: anuncia el nuevo prefijo junto al antiguo, pero sin mover tráfico todavía. Durante 1-2 semanas, verifica con Looking Glasses y herramientas como BGPlay que el /24 se propaga correctamente por los upstreams y las IXPs de siempre.
2. Tráfico de prueba: enruta hacia el nuevo rango servicios internos no críticos (DNS secundario, monitorización, entornos de staging). Mide latencia, pérdida de paquetes y qué tal aguantan las sesiones BGP.
3. Migración por servicios: mueve las cargas de trabajo de forma escalonada, empezando por las que toleran ventanas de mantenimiento sin quejarse. Un detalle que a veces se olvida: baja los TTL de DNS a 300 segundos 48 horas antes de cada corte. Acelera la propagación y te ahorra sorpresas.
4. Retirada controlada: mantén el rango antiguo anunciado en modo “drenaje” durante al menos 30 días, capturando el tráfico residual antes de desanunciarlo definitivamente. Hay clientes que tardan en actualizarse. Más de los que crees.

Prueba siempre el filtrado. Comprueba que ningún upstream aplica filtros bogon o listas que bloqueen tu nuevo prefijo, y valida que las rutas más específicas que puedas necesitar para traffic engineering no se pasen de los límites de longitud de prefijo de tus proveedores. Es una verificación de diez minutos que evita semanas de dolores de cabeza.

Documentación crítica: LOA, RPKI/ROA y actualización en los RIR

¿Sabes dónde fracasan más migraciones? Aquí. No por dificultad técnica, sino por trámites incompletos que se descubren cuando ya es tarde. Tres piezas son innegociables:

• LOA (Letter of Authorization): si el prefijo viene de una compra o de un alquiler, el titular registral debe emitir un LOA que autorice a tu ASN a anunciarlo. Sin ese papel, muchos tránsitos e IXPs rechazarán la ruta, o la filtrarán a la primera incidencia.
• RPKI/ROA: crea los ROA en el RIR correspondiente antes del primer anuncio, especificando el ASN origin y la longitud máxima de prefijo (por ejemplo, /24 con maxLength /24 si no piensas anunciar más específicos). Un ROA mal definido genera rutas Invalid, y esas rutas acaban descartadas por validación RPKI en un porcentaje creciente de redes. Si el prefijo era de otro titular, asegúrate de que la transferencia o actualización del ROA previo esté hecha. Los conflictos aquí son un problema serio.
• Registros en el RIR: en RIPE NCC, revisa que la asignación figure a nombre del nuevo titular, con los objetos inetnum, maintainer y route actualizados. En ARIN, lo que hay que mirar es el POC y la organización asociada. Los datos desactualizados complican muchísimo la resolución de incidentes y las renovaciones.

Y una recomendación que sale de la experiencia: mantén un inventario documental vivo. Copias de los LOA, capturas de los ROA publicados, contratos de alquiler, capturas de la propagación BGP en cada fase. Si algún día hay un litigio o una auditoría de la RIR, ese archivo será tu evidencia. Sin él, tendrás solo tu palabra.

Conclusión: migrar sin caídas es cuestión de método

Que una migración de IPv4 salga sin interrupciones no depende de la suerte. Depende de una secuencia disciplinada: inventariar y recuperar espacio interno, asegurar la titularidad y los permisos de anuncio, desplegar en fases con dual-stack y pruebas de enrutamiento, y dejar la documentación —LOA, ROA, registros RIR— impecable antes de mover el primer paquete. Los rangos limpios y bien documentados conservan mejor su valor de mercado, y los bien planificados se integran sin que los usuarios se enteren. Si tu inventario interno no llega, IP4 Market ofrece una plataforma con vendedores verificados y precios competitivos, tanto para compra como para alquiler de prefijos listos para anunciar. Con método, ventanas de prueba y la documentación en orden, la próxima migración puede ser, sencillamente, un evento sin incidentes.