Las plataformas cloud, los operadores de infraestructura de IA y los proveedores de hosting se enfrentan a una realidad de red compleja: la demanda de conectividad pública sigue creciendo, pero la disponibilidad de direcciones IPv4 no.
La
Internet Assigned Numbers Authority confirma que su suministro general de IPv4 se ha agotado. Sin embargo, los clientes, las integraciones empresariales, las aplicaciones heredadas, las herramientas de seguridad, las API y los dispositivos de red todavía dependen de la conectividad IPv4. La adopción de IPv6 es esencial, pero no elimina la necesidad inmediata de seguir siendo compatible con Internet IPv4.
Para los proveedores de infraestructura, IPv4 es por tanto mucho más que un requisito de direccionamiento. Es una cuestión de capacidad, continuidad, seguridad y experiencia del cliente.
Una estrategia IPv4 sostenible debe responder a cinco preguntas:
1. ¿Cuánta capacidad IPv4 pública necesita realmente la plataforma?
2. ¿Qué cargas de trabajo requieren direcciones IPv4 dedicadas?
3. ¿Cómo se obtendrá nueva capacidad sin ralentizar las implementaciones?
4. ¿Quién es responsable del enrutamiento, la reputación, la gestión de abusos y las renovaciones?
5. ¿Cómo funcionarán IPv4 e IPv6 conjuntamente a largo plazo?
Esta guía explica cómo los proveedores de cloud, IA y hosting pueden desarrollar esa estrategia.
Por qué IPv4 sigue siendo fundamental para los proveedores de infraestructura
IPv4 utiliza un espacio de direcciones de 32 bits. Esta limitación técnica no permite un crecimiento indefinido de los servicios conectados a Internet. El espacio de direcciones disponible se gestiona actualmente mediante asignaciones existentes, transferencias, arrendamientos, recuperación y un uso más eficiente.
Sin embargo, la demanda continúa siendo elevada en varios mercados de infraestructura.
Plataformas cloud
Los servicios de cloud público pueden requerir direcciones IPv4 para:
- Máquinas virtuales e instancias bare-metal
- Balanceadores de carga públicos
- Bases de datos gestionadas y gateways de aplicaciones
- Gateways de traducción de direcciones de red
- Firewalls controlados por los clientes
- Servicios VPN y de acceso remoto
- Conectividad multi-cloud y cloud híbrido
Los clientes suelen esperar disponer de un endpoint IPv4 cuando lanzan un servicio. Si la capacidad de direcciones no puede mantenerse al mismo ritmo que la capacidad de computación, IPv4 se convierte en una limitación para la infraestructura que genera ingresos.
Infraestructura de IA
Las plataformas de IA generan sus propios requisitos de IPv4. Los clústeres de GPU pueden utilizar direccionamiento privado internamente, pero las direcciones públicas siguen siendo necesarias con frecuencia para:
- API de inferencia
- Endpoints para servir modelos
- Entornos de desarrollo de IA
- Paneles de control para clientes
- Gateways de ingesta de datos
- Acceso administrativo seguro
- Integración con sistemas de terceros
- Servicios distribuidos de procesamiento de datos
Los rápidos ciclos de implementación asociados con la IA hacen que la velocidad de aprovisionamiento sea especialmente importante. Una plataforma no debería mantener capacidad de computación inactiva simplemente porque su equipo de red está esperando espacio de direcciones públicas utilizable.
Servicios de hosting y centros de datos
El hosting dedicado, los VPS, la colocación, la infraestructura gestionada y el alojamiento de aplicaciones siguen dependiendo en gran medida de IPv4. Muchos clientes esperan al menos una dirección IPv4 pública utilizable, mientras que servicios como firewalls gestionados, alta disponibilidad, terminación SSL y dispositivos especializados pueden necesitar capacidad adicional.
La disponibilidad de IPv4 puede, por tanto, afectar al diseño de los productos, la adquisición de clientes, la expansión a nuevas ubicaciones y la rentabilidad de cada servidor o máquina virtual.
Tratar IPv4 como una cartera de infraestructura
El primer paso consiste en dejar de tratar todas las direcciones como si fueran intercambiables.
Una cartera eficaz separa los requisitos de IPv4 según la carga de trabajo, la duración, el valor para el cliente y el impacto de una posible interrupción. Los proveedores pueden clasificar la demanda en cuatro grandes categorías:
- **
Capacidad principal de producción:** Direcciones que soportan servicios de larga duración, endpoints críticos, infraestructura de clientes y cargas de trabajo costosas de renumerar.
- **
Capacidad de crecimiento:** Direcciones reservadas para expansiones previstas, nuevas regiones, servidores adicionales o lanzamientos de productos.
- **
Capacidad elástica:** Direcciones utilizadas para demanda variable o de menor duración.
- **
Capacidad de transición:** Direcciones utilizadas para migraciones, adquisiciones, renumeración o implementaciones dual-stack.
Esta clasificación ayuda a la empresa a decidir dónde necesita la máxima continuidad y dónde puede aceptar una mayor flexibilidad operativa.
Una dirección de producción que soporta cientos de cargas de trabajo de clientes no debería obtenerse bajo los mismos controles que una capacidad temporal de desarrollo. El coste de un acuerdo IPv4 debe compararse con el coste de una interrupción, no únicamente con el precio mensual por dirección.
Prever la demanda de IPv4 a partir de los factores de negocio
Los proveedores de infraestructura deben relacionar la previsión de IPv4 con actividades comerciales medibles.
Entre los datos útiles se incluyen:
- Número de servidores, instancias, tenants o clústeres que se implementarán
- Crecimiento esperado de clientes y tasa de abandono
- Consumo medio de direcciones por producto
- Planes de expansión regional
- Proporción de productos con IP dedicada frente a IP compartida
- Capacidad requerida para alta disponibilidad
- Utilización y fragmentación dentro de los bloques existentes
- Direcciones reservadas para red, broadcast, gateways o necesidades operativas
- Periodo de cuarentena antes de reasignar una dirección
- Capacidad para migraciones y contingencias
Las previsiones deben abarcar varios horizontes. Una previsión operativa continua de 90 días facilita el aprovisionamiento, mientras que un modelo de 12 a 24 meses ayuda a la dirección a evaluar el arrendamiento, la compra, la optimización de direcciones y la inversión en IPv6.
Los equipos también deben mantener una reserva de capacidad. Esperar hasta que el pool disponible llegue a cero convierte el crecimiento normal en una situación de adquisición de emergencia.
Decidir cuándo arrendar, comprar u optimizar
No existe un único modelo de aprovisionamiento que sea adecuado para todos los proveedores. La mayoría de los grandes operadores se benefician de combinar varios enfoques.
Arrendar IPv4 para un crecimiento escalable y eficiente en términos de capital
El arrendamiento puede ser apropiado cuando un proveedor necesita:
- Añadir capacidad de direcciones sin realizar una gran compra inicial
- Lanzar rápidamente una nueva región o servicio
- Ajustar los compromisos de IPv4 a la demanda de los clientes
- Preservar capital para computación, almacenamiento, GPU y expansión de red
- Evitar gestionar una cadena fragmentada de proveedores de direcciones
- Mantener flexibilidad cuando la demanda a largo plazo es incierta
Sin embargo, un arrendamiento de IPv4 debe evaluarse como una dependencia de infraestructura. La propiedad o el control de las direcciones por parte del proveedor, las condiciones de renovación, el soporte de enrutamiento, la situación registral y las capacidades operativas son importantes.
LARUS proporciona
arrendamiento directo de IPv4 desde su propio pool de direcciones bajo control. Su estructura de servicios actual permite a los clientes seleccionar un arrendamiento únicamente de capacidad o añadir controles de continuidad que cubren áreas como la validez del enrutamiento, la preparación RPKI/ROA, el DNS inverso, los procesos de gestión de abusos, el soporte de geolocalización, los compromisos de respuesta y la previsibilidad de las renovaciones.
Comprar cuando la propiedad encaje con la estrategia de capital
La compra puede ser adecuada para organizaciones con necesidades permanentes y previsibles, así como con los recursos necesarios para gestionar transferencias, registros, cumplimiento normativo, enrutamiento, seguridad y obligaciones durante todo el ciclo de vida.
El precio de compra es solo una parte de la decisión. Los compradores deben evaluar:
- Los requisitos del Registro Regional de Internet
- La documentación de titularidad y transferencia
- El historial y la reputación de las direcciones
- La autorización de enrutamiento
- Las responsabilidades continuas ante el registro
- La gobernanza interna
- El coste futuro de mantener espacio infrautilizado
La propiedad puede aportar valor económico a largo plazo, pero también concentra las responsabilidades administrativas y relacionadas con el registro dentro de la empresa operativa.
Optimizar el espacio existente antes de añadir capacidad
Los proveedores deben auditar regularmente sus asignaciones existentes para identificar:
- Asignaciones de clientes no utilizadas
- Subredes sobredimensionadas
- Entornos de desarrollo abandonados
- Direcciones conservadas después de finalizar un servicio
- Reservas duplicadas
- Registros deficientes de asignación
- Fragmentación que impide una reasignación eficiente
La optimización es útil, pero tiene sus límites. Una reutilización demasiado agresiva de direcciones puede aumentar la carga operativa y crear problemas de reputación si las direcciones pasan de un cliente a otro sin una revisión y un periodo de cuarentena adecuados.
Las organizaciones que mantienen más IPv4 de las que necesitan también pueden considerar vender los recursos no utilizados. LARUS opera como
comprador directo de primer nivel de espacio de direcciones IPv4 y admite estructuras en las que una organización vende un bloque y vuelve a arrendar la capacidad que todavía necesita.
Integrar la continuidad en el proceso de aprovisionamiento
La disponibilidad de direcciones por sí sola no hace que un bloque esté preparado para producción.
Antes de poner en servicio un espacio IPv4 arrendado o adquirido, el proveedor debe confirmar:
- Que la parte que suministra las direcciones tiene autoridad para hacerlo
- Que el uso permitido está claramente documentado
- Que el prefijo requerido puede anunciarse desde el ASN del proveedor
- Que las Route Origin Authorizations pueden crearse y mantenerse
- Que el DNS inverso puede delegarse o gestionarse
- Que los registros de geolocalización pueden corregirse cuando sea necesario
- Que los informes de abuso tienen un proceso de respuesta establecido
- Que las condiciones de renovación y terminación son adecuadas para la carga de trabajo
- Que se comprende el proceso para devolver o renumerar las direcciones
- Que las rutas de escalamiento del soporte y las expectativas de respuesta están documentadas
El objetivo es reducir el número de dependencias entre el contrato y la red en producción.
Esta es una de las razones por las que el aprovisionamiento directo es importante. Arrendar a través de múltiples intermediarios puede generar incertidumbre sobre la propiedad, la autorización, la renovación y la responsabilidad cuando se produce un problema operativo.
LARUS posiciona su modelo de arrendamiento como una relación directa de primer nivel, manteniéndose LARUS responsable del recurso subyacente y de la capa de continuidad.
Proteger el enrutamiento con RPKI y ROA
Un acuerdo comercial válido no crea automáticamente una configuración de enrutamiento segura.
Resource Public Key Infrastructure, o RPKI, permite al titular de un recurso autorizar a un sistema autónomo a originar un prefijo. La Route Origin Authorization resultante identifica el ASN de origen permitido y la longitud máxima del prefijo. La función técnica de los ROA se describe en las
especificaciones RPKI del IETF.
Para los proveedores de cloud, IA y hosting, el proceso de incorporación debe incluir:
1. Confirmar el ASN de origen
2. Crear o actualizar el ROA correspondiente
3. Comprobar la longitud de prefijo autorizada
4. Validar la ruta antes de utilizarla en producción
5. Supervisar anuncios no válidos o inesperados
6. Actualizar la autorización antes de cualquier migración de enrutamiento
7. Eliminar las autorizaciones obsoletas después de retirar el servicio
RPKI debe combinarse con supervisión de rutas, filtros de prefijos, control documentado de cambios y verificación por varias partes para los cambios de enrutamiento sensibles.
Gestionar la reputación como un activo operativo
Una dirección IPv4 puede ser técnicamente enrutable pero comercialmente inutilizable si tiene una mala reputación.
Los entornos cloud y de hosting son objetivos frecuentes de spam, abuso de credenciales, malware, escaneo, phishing y otras actividades prohibidas. Las plataformas de IA pueden enfrentarse a riesgos adicionales relacionados con la creación automatizada de cuentas, el uso indebido de proxies, scraping o actividades masivas no autorizadas.
Los proveedores deben evaluar tanto el historial del espacio de direcciones entrante como el comportamiento de los nuevos clientes.
Un programa práctico de gestión de reputación incluye:
- Comprobaciones previas a la implementación en fuentes de reputación relevantes
- Políticas claras de uso aceptable
- Controles de identidad y riesgo de clientes
- Detección automatizada de tráfico anómalo
- Contactos dedicados a la gestión de abusos
- Gestión de incidentes basada en evidencias
- Cuarentena de direcciones antes de reasignarlas
- DNS directo e inverso precisos
- Procesos para corregir registros de geolocalización y reputación
- Documentación de las acciones correctivas
La reputación no es una comprobación que se realiza una sola vez durante la incorporación. Debe gestionarse durante todo el ciclo de vida de la dirección.
Utilizar IPv4 compartida de forma selectiva
NAT y carrier-grade NAT pueden reducir el consumo de direcciones públicas, pero deben aplicarse según la carga de trabajo.
La IPv4 compartida puede funcionar bien para tráfico saliente de clientes, servicios internos, entornos de desarrollo y cargas de trabajo que no requieren un endpoint entrante único. El espacio de direcciones compartido reservado para carrier-grade NAT está definido en [
RFC 6598].
Una IPv4 pública dedicada puede seguir siendo necesaria cuando los clientes requieren:
- Conexiones entrantes
- Listas de permitidos estables
- DNS controlado por el cliente
- Reputación independiente para el correo electrónico
- Protocolos que no funcionan correctamente a través de NAT
- Administración directa del servidor
- Separación del tráfico por motivos de cumplimiento normativo
- Un endpoint único para un servicio alojado
El objetivo no debe ser maximizar el uso compartido de direcciones a cualquier coste. Los proveedores deben utilizar la arquitectura que proporcione a cada producto un equilibrio adecuado entre eficiencia del direccionamiento, observabilidad, facilidad de soporte y experiencia del cliente.
Adoptar IPv6 sin asumir que IPv4 desaparecerá
IPv6 es la solución a largo plazo para la escasez de direcciones. Todo proveedor de cloud, IA y hosting debe disponer de una hoja de ruta activa para IPv6.
Esa hoja de ruta puede incluir:
- Gestión dual-stack y redes de clientes dual-stack
- Compatibilidad con IPv6 para balanceadores de carga y API
- Kubernetes y plataformas de contenedores compatibles con IPv6
- Supervisión, registro y controles de seguridad para IPv6
- Documentación para clientes y herramientas de migración
- DNS compatible con IPv6 y aprovisionamiento automatizado
- Compatibilidad con IPv6 en sistemas de facturación y gestión de direcciones
Sin embargo, dual-stack puede aumentar la complejidad operativa, ya que los equipos deben proteger, supervisar, solucionar problemas y documentar ambos protocolos. Por tanto, la adopción de IPv6 debe tratarse como un programa de ingeniería y no simplemente como un ejercicio de asignación de direcciones.
En el futuro previsible, muchos proveedores necesitarán una estrategia integrada: IPv6 para la escalabilidad y la modernización de la arquitectura, combinado con IPv4 fiable para mantener la accesibilidad universal y la compatibilidad con los clientes.
Construir un plano de control de IPv4
A medida que un proveedor crece, las hojas de cálculo y los flujos de trabajo informales basados en tickets se vuelven arriesgados. La capacidad IPv4 debe gestionarse mediante un plano de control integrado o un sistema de gestión de direcciones IP.
Como mínimo, el sistema debe realizar un seguimiento de:
- Inventario de prefijos y direcciones
- Información sobre el propietario o arrendador
- Región y RIR
- ASN y estado del enrutamiento
- Estado del ROA
- Asignación a clientes o cargas de trabajo
- Autoridad del DNS inverso
- Geolocalización
- Eventos relacionados con la reputación
- Fechas de inicio, renovación y finalización del arrendamiento
- Utilización
- Historial de cuarentena y reasignación
Los registros comerciales y de red deben coincidir. Una fecha de renovación que exista únicamente en la bandeja de entrada del equipo de compras constituye un riesgo operativo.
Deben generarse alertas con suficiente antelación antes de que los umbrales de capacidad, los plazos contractuales, las expiraciones de ROA, los cambios de enrutamiento o las migraciones de clientes requieran alguna acción.
Lista práctica para una estrategia IPv4
Los proveedores de cloud, IA y hosting pueden utilizar la siguiente lista al desarrollar su estrategia de direccionamiento:
- Segmentar la demanda de direcciones según la carga de trabajo y el impacto de una interrupción
- Mantener previsiones de capacidad a 90 días y a largo plazo
- Establecer umbrales mínimos de reserva
- Auditar la utilización actual y recuperar el espacio realmente no utilizado
- Seleccionar el arrendamiento o la compra según la duración, el capital y el riesgo
- Verificar la autoridad del proveedor y la cadena comercial
- Documentar las condiciones de renovación, terminación y renumeración
- Validar la reputación antes de la implementación
- Crear y supervisar los ROA adecuados
- Definir las responsabilidades de rDNS, geolocalización y gestión de abusos
- Adaptar los compromisos de soporte al coste de una interrupción del servicio
- Introducir IPv6 de forma sistemática manteniendo la compatibilidad con IPv4
- Mantener sincronizados los inventarios de red, clientes y comerciales
- Revisar la estrategia cada vez que la empresa lance una nueva región, producto o implementación importante para un cliente
La capacidad IPv4 debe impulsar el crecimiento, no limitarlo
Para los proveedores de cloud, IA y hosting, la escasez de IPv4 no se resuelve con una única compra, un arrendamiento temporal o un anuncio de IPv6. Requiere un modelo operativo que conecte la planificación de capacidad, el aprovisionamiento, el enrutamiento, la reputación, la seguridad, las renovaciones y la modernización de los protocolos.
La estrategia más sólida es aquella en la que la empresa sabe cuántas IPv4 necesita, qué servicios realmente las requieren, de dónde proceden las direcciones, cómo se protegen y qué sucede si cambian la demanda o los proveedores.
LARUS apoya a los proveedores de infraestructura con
arrendamiento directo de IPv4 y Continuity Assurance. Las opciones Capacity Only, Production, Enterprise y Critical permiten a las organizaciones adaptar los controles operativos a la importancia de cada implementación.
Para hablar sobre el tamaño de los bloques, la ubicación geográfica de la implementación, los requisitos de ASN, el enrutamiento, la continuidad o las necesidades de renovación, contacte con LARUS o escriba a: sales@larus.net.
Preguntas frecuentes
1. ¿Por qué los proveedores cloud siguen necesitando IPv4?
Los proveedores cloud necesitan IPv4 porque muchos usuarios, redes empresariales, aplicaciones, dispositivos e integraciones de terceros todavía no pueden accederse únicamente mediante IPv6. Los endpoints IPv4 públicos mantienen la compatibilidad con el Internet más amplio.
2. ¿Es adecuado el arrendamiento de IPv4 para infraestructura de producción?
Sí, siempre que el arrendamiento incluya la autoridad adecuada, soporte de enrutamiento, condiciones de renovación, controles de reputación y responsabilidades operativas. Las cargas de trabajo de producción deben asociarse con un nivel de continuidad basado en el coste de una posible interrupción.
3. ¿Cómo utilizan las plataformas de IA las direcciones IPv4 públicas?
Las plataformas de IA pueden utilizar IPv4 pública para API de inferencia, paneles de control, entornos de desarrollo, gateways de datos, integraciones con socios y administración segura. El tráfico interno de GPU puede permanecer a menudo en redes privadas o IPv6.
4. ¿Una empresa de hosting debería arrendar o comprar IPv4?
La respuesta depende de la duración de la demanda, la disponibilidad de capital, la experiencia interna y la flexibilidad deseada. El arrendamiento puede facilitar un crecimiento rápido y eficiente en términos de capital, mientras que la compra puede ser adecuada para necesidades estables a largo plazo. Muchos proveedores utilizan ambas opciones.
5. ¿IPv6 elimina la necesidad de una estrategia IPv4?
Todavía no. IPv6 es esencial para la escalabilidad a largo plazo, pero los proveedores deben seguir siendo compatibles con clientes y sistemas dependientes de IPv4. Una estrategia dual-stack combina preparación para el futuro con compatibilidad actual.
6. ¿Qué debe ofrecer un proveedor de IPv4 además de capacidad de direcciones?
Los proveedores para entornos de producción deben considerar la autorización de enrutamiento, las operaciones RPKI/ROA, el DNS inverso, la geolocalización, la reputación, la respuesta a abusos, los compromisos de soporte, la previsibilidad de las renovaciones y procedimientos claros de escalamiento.
Publicado:
Última actualización:
