/48 —billones de subredes— sin racionar ni una IP.Hace poco defendimos que «NAT ya no es gratis»: que toda la maquinaria montada para estirar IPv4 —CGNAT, logging masivo, direcciones con precio de mercado, appliances que solo existen porque faltan IPs— es una factura real, solo que llega partida en demasiadas líneas. Aquel post cerraba una idea y abría otra. Si el problema es la escasez de IPv4, la respuesta estructural no es comprar más parches. Es IPv6.
El pero de siempre: «IPv6 lleva veinte años a la vuelta de la esquina y aquí seguimos con IPv4». Es verdad a medias. La adopción global ya ronda el 45-50 % del tráfico que llega a Google, hay operadores residenciales en España que sirven IPv6 por defecto y los grandes proveedores de cloud llevan tiempo cobrando explícitamente por cada IPv4 pública. Lo que ha cambiado no es la tecnología, que está madura desde hace años. Es el incentivo. Mientras IPv4 fue barata, migrar era un proyecto sin recompensa clara. Ahora IPv4 es un coste recurrente y creciente, y eso cambia la cuenta.
Este artículo va de lo concreto: qué significa IPv6 cuando montas un cloud privado sobre Proxmox, cómo se convive con IPv4 sin apagarlo de golpe, y por qué el argumento de fondo no es técnico sino de propiedad. En IPv6 vuelves a tener direcciones tuyas, suficientes y sin intermediario.
Una dirección IPv4 pública se ha convertido en un activo con precio de mercado. Se compran, se venden y se alquilan bloques como quien negocia con materias primas. Cuando contratas infraestructura, buena parte de lo que pagas por «IP pública» no cubre un coste técnico: cubre escasez.
IPv6 rompe esa lógica por diseño. El espacio de direcciones es tan grande que un proveedor puede asignarte un bloque /48 —281 billones de subredes /64, cada una con más direcciones que toda la IPv4 mundial— sin que eso suponga un problema de inventario. No es abundancia como lujo. Es abundancia como estado normal del recurso.
Para un cloud privado esto tiene una consecuencia directa y poco comentada: recuperas el direccionamiento como algo que gestionas tú, no como un cupo que te racionan. Puedes numerar cada máquina virtual, cada contenedor, cada servicio interno con una dirección única y enrutable, sin pelearte por un puñado de IPs públicas ni esconder toda la red detrás de una capa de traducción. Es el tipo de control que encaja con la lógica de la nube soberana: no solo dónde están tus datos, también quién decide sobre tu red.
El miedo más común es que IPv6 obligue a rehacerlo todo. La realidad es más tranquila si se planifica: casi nadie apaga IPv4 el día uno. Se convive.
El patrón dominante de migración se llama dual-stack: cada máquina habla IPv4 e IPv6 en paralelo. El sistema operativo elige el protocolo según el destino, prefiriendo IPv6 cuando está disponible (regla de selección de RFC 6724). No hay corte, no hay bandera roja: enciendes IPv6, sigues teniendo IPv4, y el tráfico empieza a irse por IPv6 solo cuando ambos extremos lo soportan.
Esto convierte la migración en un proceso gradual y reversible. Levantas IPv6 en una VLAN, pruebas, mides, y solo cuando estás cómodo lo extiendes. Si algo va mal, IPv4 sigue ahí. Es lo contrario del salto al vacío que la gente imagina.
En IPv4 privada, entre una VM y el mundo suele haber una o varias traducciones: NAT de salida, port forwarding para entrar, a veces CGNAT del operador por encima. Cada capa es un sitio donde una conexión se pierde, un log se complica y un diagnóstico se alarga.
En IPv6 con direccionamiento global, muchas de esas capas desaparecen. Una VM con dirección enrutable se conecta de extremo a extremo. Eso no significa quitar el firewall —eso es el mito peligroso, y lo desmontamos abajo— sino sustituir «traduzco porque no tengo direcciones» por «filtro porque decido qué entra». La seguridad pasa de ser un efecto colateral de la escasez a ser una política explícita. Que es donde debería haber estado siempre.
Bajemos al terreno. En un clúster Proxmox VE 9.2, IPv6 encaja en las mismas piezas que ya usas: el bridge de Linux, las VLANs y —si haces redes definidas por software— el SDN integrado.
Un despliegue dual-stack típico reparte así el direccionamiento:
| Plano | IPv4 | IPv6 | Notas |
|---|---|---|---|
| Gestión de nodos | RFC 1918 (10.x) | /64 de ULA o global | El acceso a la UI y a la API de Proxmox no necesita salir a Internet |
| Corosync / clúster | Red dedicada 10.x | Opcional | El tráfico de quorum conviene aislarlo; IPv4 basta |
| Storage (Ceph, NFS) | Red dedicada | /64 propio | Ceph soporta IPv6; útil si el almacenamiento crece a varias redes |
| VMs / servicios públicos | IPv4 pública escasa | /64 global por VLAN | Aquí es donde IPv6 más alivia: una dirección por servicio, sin racionar |
La idea de fondo: IPv6 se usa donde la escasez de IPv4 duele —servicios de cara al exterior, muchas VMs, entornos que crecen— y se deja IPv4 donde ya funciona sin fricción, como las redes internas de clúster.
Sobre Debian —la base de Proxmox— el direccionamiento vive en /etc/network/interfaces. Un bridge dual-stack se ve así de simple:
auto vmbr0
iface vmbr0 inet static
address 10.20.0.11/24
gateway 10.20.0.1
bridge-ports eno1
bridge-stp off
bridge-fd 0
iface vmbr0 inet6 static
address 2001:db8:20::11/64
gateway 2001:db8:20::1Las VMs cuelgan de vmbr0 y reciben su IPv6 por SLAAC (autoconfiguración con router advertisements) o por DHCPv6, según prefieras control fino o autonomía de los hosts. Para servicios que quieres localizar siempre igual, direcciones fijas; para flotas efímeras, SLAAC y a correr.
Aquí está el punto que separa una migración seria de un incidente de seguridad. En IPv6 cada VM puede ser directamente alcanzable desde Internet. Eso es una ventaja de conectividad y un riesgo si no filtras. El firewall de Proxmox (a nivel de datacenter, nodo y VM) entiende IPv6 igual que IPv4: reglas por dirección, por red, por puerto. La regla mental correcta es «denegar por defecto, permitir lo justo», exactamente igual que en IPv4. Lo que cambia es que ya no dependes del NAT como cortafuegos accidental.
IPv6 arrastra una mitología que retrasa decisiones sensatas. Vale la pena desactivarla una por una.
«IPv6 es inseguro porque todo es público». No. Direccionable no es lo mismo que accesible. El firewall decide qué se alcanza; la dirección global solo describe cómo se enruta. Una VM con IPv6 global y una política de «denegar entrante salvo 443» es tan cerrada como una tras NAT, y más fácil de auditar porque no hay una capa de traducción ocultando quién habla con quién.
«Nadie usa IPv6, no merece la pena». La mitad del tráfico de los grandes servicios ya es IPv6. Los móviles en muchas redes son IPv6-only con NAT64 para llegar a lo que queda de IPv4. No servir IPv6 no te hace neutral: te deja fuera de la ruta rápida para una parte creciente de usuarios.
«Migrar es un big bang.» Dual-stack existe precisamente para que no lo sea. Enciendes IPv6, convives, mides, y decides el ritmo. No hay ningún día en que apagues IPv4 a la fuerza.
«IPv6 no aporta nada que IPv4 no haga.» Aporta lo que IPv4 ya no puede: direcciones suficientes sin comprarlas, sin NAT estructural y sin un mercado secundario encareciéndolas cada año. En una infraestructura que crece, eso es la diferencia entre escalar y racionar.
El argumento definitivo no es la elegancia técnica. Es el coste evitado. IPv4 pública se ha vuelto una línea de gasto que sube:
IPv6 no elimina todos esos costes de un día para otro, pero corta la dependencia estructural: cada servicio nuevo en IPv6 no suma a la factura de direcciones. Si estás calculando cuánto cuesta de verdad un cloud privado, IPv4 es una de esas partidas que crece callada. IPv6 es la que la frena.
Ni heroísmo ni parálisis. Un orden que funciona:
/48 o al menos un /56 de tu proveedor o de tu RIR (RIPE NCC en Europa). Suficiente para numerar toda la organización durante años./64 por VLAN es la práctica estándar. No ahorres subredes: el espacio existe para gastarlo con orden.AAAA), comprueba el firewall.AAAA para los servicios de cara al exterior. El tráfico empieza a irse por IPv6 solo, sin tocar a los clientes.En ningún paso hay un corte. Y en todos, IPv4 sigue de red de seguridad.
¿Tengo que apagar IPv4 para usar IPv6? No. El modelo normal es dual-stack: ambos protocolos conviven y el sistema prefiere IPv6 cuando los dos extremos lo soportan. IPv4 se mantiene como respaldo el tiempo que haga falta.
¿IPv6 me obliga a exponer todas mis máquinas a Internet? No. Que una dirección sea globalmente enrutable no significa que sea accesible. El firewall sigue decidiendo qué entra. La política correcta es denegar entrante por defecto y abrir solo lo necesario, igual que en IPv4.
¿Proxmox soporta IPv6 de forma nativa?
Sí. El bridge de red, el firewall integrado, el SDN y componentes como Ceph funcionan con IPv6. La configuración vive en /etc/network/interfaces sobre Debian y admite dual-stack sin herramientas externas.
¿Cuánto espacio IPv6 necesito?
Para una organización, un /48 es lo estándar y da 65.536 subredes /64. Si el proveedor asigna un /56, siguen siendo 256 subredes: de sobra para la mayoría de clouds privados. La /64 es la unidad de subred; no se subdivide.
¿IPv6 reduce de verdad los costes? Corta la dependencia de IPv4 pública, que es una partida creciente: cargos por hora en hiperescalares, compra de bloques en un mercado al alza y coste de CGNAT con su logging. Cada servicio nuevo en IPv6 no suma a esa factura.
¿Sospechas que estás pagando por direcciones IPv4 que no necesitas y quieres dejar de racionar direccionamiento? Te ayudamos a inventariar tus IPs, diseñar un plan IPv6 y montar dual-stack sobre tu cloud privado sin cortes. Empieza por nuestra comparativa de cloud o hablemos de tu proyecto y planificamos la migración contigo.
Un estudio en arXiv mide, vía satélite, un aumento medio de 2,07 ºC en la temperatura de superficie alrededor de los centros de datos. El dato es llamativo, pero conviene leerlo sin convertirlo en eslogan: qué mide realmente, qué no, y por qué el problema de fondo no es el edificio, sino el software poco frugal que ejecutamos dentro.
El streaming del Mundial de la FIFA llevó el tráfico global de interconexión de DE-CIX a un máximo histórico de 28,4 Tbit/s durante el partido Portugal–España. Qué significa ese pico, por qué la demanda de un partido es tan brutal y qué papel juegan los puntos neutros de Internet —Madrid, Lisboa y Barcelona incluidos— en que la retransmisión no se caiga.
Un humano halló un use-after-free por condición de carrera en el subsistema epoll del kernel de Linux —un fallo que escala a root en Linux y Android y ni siquiera dispara KASAN—. Lo llamativo: la IA de Anthropic, Mythos, auditó exactamente ese mismo código, encontró un bug hermano y este se le pasó por alto. Qué es, por qué importa para tu cloud privado y qué nos dice sobre usar IA para buscar vulnerabilidades.