Un nuevo borrador publicado en el entorno de la IETF ha reabierto uno de los debates más antiguos de Internet: cómo superar definitivamente las limitaciones de IPv4 sin repetir los problemas de adopción que han acompañado a IPv6 durante más de dos décadas. El documento, titulado Internet Protocol Version 8 (IPv8) y firmado por Jamie Thain, propone un nuevo protocolo de direcciones de 64 bits, con compatibilidad declarada con IPv4 y una arquitectura mucho más ambiciosa que no se limita al direccionamiento, sino que intenta integrar gestión, autenticación, telemetría, DNS, DHCP, NTP, validación de rutas y control de acceso.

Conviene empezar por el matiz más importante: no es un estándar aprobado. Es un Internet-Draft, es decir, un documento de trabajo que cualquier autor puede presentar y que no implica respaldo formal de la IETF salvo que sea adoptado por un grupo de trabajo o avance hasta convertirse en RFC. La propia IETF recuerda que los Internet-Drafts son válidos durante un máximo de seis meses y deben citarse como “trabajo en curso”. En este caso, la versión inicial draft-thain-ipv8-00 se publicó el 14 de abril de 2026 y al día siguiente apareció la revisión draft-thain-ipv8-01, con expiración prevista el 17 de octubre de 2026.

Una dirección de 64 bits basada en el ASN

La idea central de IPv8 es utilizar direcciones con el formato r.r.r.r.n.n.n.n. Los primeros 32 bits corresponderían al prefijo de enrutamiento asociado al ASN —el número de sistema autónomo— y los otros 32 bits mantendrían una semántica similar a la de una dirección IPv4 tradicional para identificar hosts.

En términos sencillos, el borrador propone que cada titular de un ASN disponga de 4.294.967.296 direcciones de host, una cantidad equivalente a todo el espacio IPv4 actual, pero asignada a cada sistema autónomo. El espacio total resultante sería de 18.446.744.073.709.551.616 direcciones, frente a los algo más de 4.294 millones de direcciones posibles en IPv4.

El objetivo declarado es resolver el agotamiento de IPv4 sin obligar a una migración dual-stack al estilo IPv6. El borrador sostiene que IPv4 sería un subconjunto de IPv8: una dirección IPv8 con el campo de prefijo de enrutamiento a cero se trataría como una dirección IPv4 normal. En teoría, esto permitiría mantener aplicaciones IPv4 sin modificaciones, usando una capa de compatibilidad que gestionaría el prefijo adicional de forma transparente.

La propuesta también intenta limitar el crecimiento de la tabla global de rutas. En lugar de depender de millones de prefijos más específicos, el documento plantea una tabla estructuralmente acotada por ASN y no por prefijos, con una regla mínima de inyección de /16 para evitar la desagregación excesiva. Es una respuesta directa a uno de los problemas históricos de BGP: el crecimiento de la tabla global y la dificultad para validar qué rutas son legítimas.

Zone Server: una pieza única para DHCP, DNS, NTP, autenticación y telemetría

El punto más ambicioso del borrador no está solo en el direccionamiento. IPv8 propone una arquitectura de gestión integrada basada en un Zone Server, una plataforma activa/activa que agruparía servicios que hoy suelen gestionarse por separado: DHCP8, DNS8, NTP8, NetLog8, caché de autenticación OAuth8, resolución WHOIS8, control de acceso ACL8 y traducción XLATE8.

La idea es que un dispositivo que entra en una red IPv8 envíe una única solicitud DHCP8 y reciba en una sola respuesta todos los servicios que necesita. Según el borrador, el dispositivo quedaría autenticado, sincronizado, registrado, sujeto a políticas de zona y preparado para operar antes de la primera interacción del usuario.

El documento también plantea que todos los elementos gestionables de la red se autoricen mediante tokens OAuth2 JWT, servidos desde una caché local. Esto permitiría, según la propuesta, validar identidades sin depender siempre de llamadas a proveedores externos. En entornos remotos o con conectividad degradada, el Zone Server podría seguir validando firmas con claves públicas almacenadas localmente.

Sobre el papel, es una visión atractiva para quienes sufren la fragmentación de la gestión de red. En la práctica, también es una de sus mayores dificultades. IPv8 no propone solo una nueva versión del protocolo IP; propone una reordenación completa de la operación de red, desde el direccionamiento hasta la autenticación, pasando por el control de acceso y la telemetría. Esa amplitud puede ser una ventaja conceptual, pero también eleva enormemente el coste de implementación, validación y adopción.

Seguridad norte-sur y este-oeste por diseño

El borrador intenta reforzar dos planos de seguridad. En el tráfico este-oeste, es decir, dentro de la propia red, plantea aislamiento por zonas mediante ACL8, de modo que los dispositivos solo se comuniquen con sus gateways y servicios autorizados. El objetivo es reducir el movimiento lateral, uno de los grandes problemas en incidentes de ransomware y compromisos internos.

En el tráfico norte-sur, desde la red hacia Internet, IPv8 propone dos validaciones obligatorias en el punto de salida: que exista una consulta DNS8 asociada a la conexión y que el destino esté validado contra un registro WHOIS8 con ruta activa. La idea es dificultar conexiones directas a direcciones IP codificadas en malware, una técnica habitual en canales de mando y control.

También se plantea que los anuncios BGP8 sean validados contra WHOIS8 antes de instalarse en la tabla de rutas. Si una ruta no puede validarse, no se aceptaría. En teoría, esto reduciría secuestros de prefijos, filtraciones de rutas y anuncios no autorizados. En la práctica, exigiría una infraestructura de registro, firma, validación y operación global extremadamente robusta.

El problema incómodo: el número 8 ya está reservado

Uno de los puntos técnicos más delicados es que la propuesta solicita a IANA asignar el número de versión IP 8 a IPv8. Sin embargo, en el registro oficial de IP Version Numbers de IANA, el valor 8 aparece como Reserved (Historic), junto a los valores 5, 7 y 9. El registro indica que los valores de versión IP se asignan por “Standards Action”, lo que refuerza la idea de que esta propuesta tendría que superar un proceso muy exigente antes de cualquier adopción real.

Ese detalle no invalida automáticamente el debate técnico, pero sí muestra la distancia entre un borrador y una implementación viable en Internet. Cambiar el número de versión de IP no es una decisión menor. Afecta a sistemas operativos, routers, firewalls, ASICs, stacks TCP/IP, herramientas de monitorización, DNS, aplicaciones, bibliotecas, middleboxes y políticas de seguridad de todo el ecosistema.

Además, el borrador llega en un momento en el que IPv6 ya no puede describirse simplemente como un fracaso. Aunque su despliegue sigue siendo desigual, Google muestra que alrededor del 48% de los usuarios accedían a sus servicios por IPv6 el 22 de marzo de 2026, y mediciones de APNIC situaban la capacidad IPv6 global en torno al 43% en la media de los 30 días anteriores al 16 de abril de 2026. Es decir, IPv6 todavía no ha reemplazado por completo a IPv4, pero ya transporta una parte muy significativa del tráfico mundial.

Una propuesta interesante, pero con recorrido muy incierto

IPv8 resulta interesante porque aborda varias frustraciones reales: agotamiento de IPv4, complejidad del dual-stack, dependencia de NAT y CGNAT, crecimiento de tablas BGP, fragmentación de servicios de red y falta de validación fuerte de rutas. También tiene valor como ejercicio de diseño: obliga a pensar qué se haría distinto si hoy se rediseñara Internet con la experiencia acumulada durante décadas.

Pero su probabilidad de adopción parece, por ahora, muy incierta. No basta con que una propuesta sea técnicamente imaginativa; tiene que ser implementable, compatible con infraestructuras existentes, aceptable para operadores, fabricantes, cloud providers, sistemas operativos, organismos de estandarización y empresas. Y debe demostrar que sus beneficios compensan los costes de cambiar una arquitectura global que, pese a sus defectos, sigue funcionando.

El propio hecho de unificar tantas piezas en un mismo conjunto —DHCP8, DNS8, WHOIS8, NetLog8, Zone Server, BGP8, OAuth8, XLATE8— puede jugar en su contra. Los estándares de Internet suelen avanzar mejor cuando resuelven problemas concretos, con límites claros y fuerte consenso operativo. IPv8 intenta resolver muchos problemas a la vez, lo que hace la propuesta más llamativa, pero también más difícil de digerir.

Aun así, el borrador merece atención como señal cultural. La comunidad técnica sigue incómoda con la transición interminable entre IPv4 e IPv6, con la dependencia de CGNAT y con la complejidad de gestionar redes modernas. IPv8 quizá no llegue nunca a convertirse en estándar, pero su aparición demuestra que la conversación sobre el futuro del direccionamiento y la gestión de Internet sigue abierta.

Preguntas frecuentes

¿IPv8 es un nuevo estándar oficial de Internet?

No. IPv8 es, por ahora, un Internet-Draft, un borrador de trabajo. No está aprobado como estándar ni tiene respaldo formal de la IETF salvo que avance en el proceso, sea adoptado por un grupo de trabajo y acabe convirtiéndose en RFC.

¿Qué diferencia tendría IPv8 frente a IPv6?

La principal diferencia propuesta es que IPv8 usaría direcciones de 64 bits con un formato familiar tipo IPv4 extendido, incorporando el ASN en los primeros 32 bits. Además, plantea una gestión integrada con Zone Server, DHCP8, DNS8, WHOIS8, OAuth8 y telemetría.

¿IPv8 sería compatible con IPv4?

El borrador afirma que IPv4 sería un subconjunto de IPv8, usando el prefijo 0.0.0.0 en la parte de enrutamiento. Según la propuesta, las aplicaciones IPv4 podrían seguir funcionando mediante una capa de compatibilidad, aunque esto tendría que demostrarse en implementaciones reales.

¿Puede IPv8 sustituir a IPv6?

Es muy pronto para afirmarlo. IPv8 es una propuesta en fase inicial y con importantes retos técnicos, operativos y de estandarización. Además, IPv6 ya tiene una adopción global significativa, aunque todavía convive ampliamente con IPv4.