IPv8: el protocolo de internet que podría dar a los gobiernos la herramienta de censura perfecta

Cada pocos años, alguien publica una propuesta para sustituir el sistema de direccionamiento de internet. La mayoría caduca sin hacer ruido. La que apareció el 14 de abril de 2026, un borrador titulado «Internet Protocol Version 8» firmado por Jamie Thain, de One Limited, es distinta, no porque vaya a prosperar, sino porque las preocupaciones que plantea merecen tomarse en serio antes de que ideas similares aparezcan en una propuesta que sí lo haga.

En IPbnb operamos en el mercado de direcciones IPv4. Reflexionamos detenidamente sobre cómo funciona el direccionamiento IP, quién lo controla y qué implican los cambios en esa arquitectura para las personas y organizaciones que dependen de ella. IPv8 toca los tres aspectos. Repasemos qué propone realmente, por qué la comunidad se muestra escéptica y por qué un aspecto concreto de su diseño merece más atención de la que ha recibido.

Primero, una aclaración: hay tres cosas llamadas «IPv8»

Antes de nada, una aclaración necesaria. El término «IPv8» se refiere actualmente a, al menos, tres cosas sin relación entre sí.

La primera es py-ipv8, un framework peer-to-peer funcional desarrollado por la Universidad Tecnológica de Delft y utilizado en el proyecto Tribler. Funciona sobre UDP, utiliza identidades criptográficas Curve25519/Ed25519 en lugar de direcciones IP y está en desarrollo activo desde 2018. El nombre es, según sus propios desarrolladores, una broma de hace una década sobre la lenta adopción de IPv6. No tiene nada que ver con sustituir TCP/IP.

La segunda es el IPv8 histórico original: un protocolo llamado PIP, propuesto por Paul Francis, de Bellcore, en 1992 y documentado en los RFC 1621 y 1622. PIP compitió en el proceso «IPng» del IETF contra lo que acabaría siendo IPv6, y perdió en julio de 1994 porque sus direcciones de longitud variable eran difíciles de procesar en hardware. En 2016 pasó formalmente al estado Historic.

La tercera, y la que está generando todo el debate actual, es draft-thain-ipv8, un Internet-Draft individual presentado al IETF en abril de 2026. De él trata el resto de este artículo.

Qué propone realmente draft-thain-ipv8

El borrador pretende resolver tres problemas a la vez: el agotamiento de las direcciones IPv4, la fragmentación de la gestión de red y el crecimiento descontrolado de la tabla de enrutamiento BGP global.

El formato de dirección es una dirección de 64 bits escrita como r.r.r.r.n.n.n.n: ocho octetos en lugar de cuatro. Los primeros 32 bits codifican un ASN (número de sistema autónomo); los últimos 32 bits son una dirección de host convencional, con una semántica idéntica a la de IPv4. La afirmación clave sobre compatibilidad con versiones anteriores es esta: si el prefijo ASN es 0.0.0.0, la dirección es una dirección IPv4 y se procesa con las reglas estándar de IPv4. Sin necesidad de modificar los dispositivos ni las aplicaciones existentes.

Con este esquema, cada titular de un ASN recibe 2^32 direcciones de host, más de cuatro mil millones, lo que hace que el agotamiento de direcciones deje de ser un problema a cualquier escala organizativa. La tabla de enrutamiento BGP global, que hoy supera los 900.000 prefijos sin ningún límite estructural, quedaría limitada a aproximadamente una entrada por ASN (unas 175.000 en la actualidad), porque se prohíbe la desagregación por debajo de /16.

La cabecera del paquete es 8 bytes más larga que la de IPv4: los campos de dirección de origen y de destino pasan de 32 a 64 bits cada uno. Todo lo demás (TTL, Protocol, Flags, Checksum) se mantiene igual.

El Zone Server es la pieza central de la arquitectura. Se trata de una plataforma obligatoria, en modo activo/activo, que concentra todos los servicios que necesita un segmento de red: DHCP8, DNS8, NTP8, autenticación (OAuth8), validación de rutas (WHOIS8), control de acceso (ACL8), telemetría (NetLog8) y traducción NAT (XLATE8). Un dispositivo que se une a una red IPv8 envía una única solicitud DHCP8 y recibe, en una sola respuesta, todos los endpoints de servicio que necesita. La autenticación se realiza mediante tokens JWT de OAuth2 validados localmente, sin consultas a proveedores de identidad externos.

La mejora del enrutamiento es el Cost Factor (CF): una métrica acumulada de 32 bits derivada de siete componentes: tiempo de ida y vuelta, pérdida de paquetes, estado de la ventana de congestión, estabilidad de la sesión, capacidad del enlace, política económica y distancia geográfica como límite físico. El componente geográfico es especialmente elegante: ninguna ruta puede parecer mejor de lo que permite la velocidad de la luz sobre la distancia ortodrómica, de modo que una ruta que se mide más rápida de lo que permite la física se marca inmediatamente como anómala.

La transición está diseñada para no requerir un «día D». Un mecanismo de túnel 8to4, encapsulado sobre HTTPS para atravesar cortafuegos sin configuración, permite que las islas IPv8 se comuniquen a través de redes de tránsito que solo admiten IPv4.

Por qué la comunidad técnica se muestra escéptica

Las críticas han sido incisivas y bastante coherentes en HackerNews, The Register, LowEndTalk y blogs especializados en redes.

La carencia de proceso es flagrante. IPv6 surgió de un proceso competitivo de varios años dentro del IETF, en el que un grupo de trabajo evaluó tres candidatos serios (CATNIP, TUBA y SIPP) antes de seleccionar SIPP y ampliarlo a 128 bits. Draft-thain-ipv8 llegó como una única propuesta individual: sin grupo de trabajo, sin proceso competitivo previo y sin respaldo institucional. La propia página del datatracker del IETF indica que no cuenta con el aval del IETF y que carece de estatus formal. Caduca el 19 de octubre de 2026 salvo que se renueve o lo adopte un grupo de trabajo, y ninguna de las dos cosas parece probable.

La violación del modelo OSI es de fondo. IPv8 traslada la autenticación OAuth2 y JWT, mecanismos propios de la capa 7 del modelo OSI, directamente a la capa de red (capa 3). La mayoría de los dispositivos de red (switches de acceso, controladores industriales, routers básicos) no están diseñados para realizar autorizaciones a nivel de aplicación. El argumento de que se trata de una funcionalidad y no de un fallo no resuelve la realidad del hardware. Dicho esto, en IPbnb tendemos a interpretarlo de forma más optimista que la mayoría de los críticos: el hardware no es estático. Los proveedores renuevan su infraestructura cada siete a diez años de todos modos, impulsados por las necesidades de capacidad, los despliegues de fibra y las actualizaciones generacionales como DOCSIS 3.1 y Wi-Fi 6. Si el hardware compatible con IPv8 se convierte simplemente en la próxima generación de esos equipos, la objeción OSI deja de ser un obstáculo y pasa a ser una cuestión de plazos.

La verdadera cuestión no es si los dispositivos pueden sustituirse, porque pueden y lo serán, sino si habrá suficiente tracción en el ecosistema como para que la compatibilidad con IPv8 sea un requisito en la próxima generación y no una función opcional que nadie incorpora.

La afirmación sobre compatibilidad con versiones anteriores tiene un límite claro, aunque con más matices de lo que parece a primera vista. La versión tajante de esta crítica dice así: todos los routers, switches y ASIC validan el campo Version de la cabecera IP y descartan todo lo que no sea 4 o 6. Un paquete marcado como versión 8 muere en el primer salto. Es correcto. Pero pasa por alto algo importante sobre cómo gestiona realmente la transición la arquitectura de IPv8.

El mecanismo XLATE8, integrado en todos los Zone Server de IPv8, está diseñado para traducir entre IPv4 e IPv8 en la pasarela. Un dispositivo heredado situado detrás de una pasarela doméstica o de un router de borde de ISP compatibles con IPv8 nunca llega a enviar un paquete de versión 8: envía IPv4 estándar, XLATE8 lo encapsula e IPv8 se encarga del resto. Los más de mil millones de dispositivos finales (teléfonos, portátiles, televisores inteligentes) no tienen por qué sustituirse necesariamente. Lo que sí hay que sustituir es el CPE y la infraestructura del proveedor que se sitúan entre ellos e internet. Y en este punto, el panorama de renovación de hardware es menos sombrío de lo que sugieren los críticos: solo en 2024, los ISP distribuyeron aproximadamente 180 millones de unidades de CPE en todo el mundo, y los operadores de telecomunicaciones invirtieron más de $35 mil millones en actualizaciones de hardware entre 2022 y 2025, impulsados por los despliegues de fibra y 5G. Si las futuras generaciones de CPE incorporan compatibilidad con IPv8 (una cuestión empresarial y regulatoria, no una imposibilidad física), la transición de las pasarelas se produce en gran medida al ritmo de los ciclos naturales, sin tocar en absoluto los dispositivos de los usuarios. Los casos más difíciles son los dispositivos que se conectan directamente a la red sin pasar por una pasarela compatible con IPv8: teléfonos móviles con chipsets de banda base celular, dispositivos IoT con conexiones celulares directas y hardware empresarial fuera de la infraestructura controlada por el ISP. Estos siguen ciclos de sustitución distintos y más lentos.

En el fondo, todo el argumento depende de que XLATE8 funcione en la práctica con la transparencia que afirma la especificación, una suposición considerable que todavía no ha puesto a prueba ninguna implementación real.

La cuestión de la autoría con IA. Según se ha informado, un análisis con GPTZero indicó una probabilidad aproximada del 76% de que partes sustanciales del texto se hubieran generado con IA. Thain ha reconocido haber utilizado asistencia de IA y lo considera una práctica habitual. Lo que preocupa a la comunidad técnica no es la herramienta, sino si la propuesta refleja una experiencia real de ingeniería con los problemas que dice resolver.

El momento elegido es incómodo respecto a IPv6. El 28 de marzo de 2026, apenas dos semanas antes de que apareciera el borrador, el tráfico IPv6 global medido por Google superó por primera vez el 50%, 32 años después del inicio del proceso IPng. La premisa central del borrador, según la cual «IPv6 ha fracasado», es hoy bastante más difícil de sostener que hace apenas un año.

El problema de la censura, y por qué importa más que la crítica técnica

Todas las críticas anteriores son legítimas. Pero existe una preocupación que ha recibido una atención menos sistemática, y es la que más debería hacer reflexionar a la comunidad de internet en general.

La arquitectura de seguridad de IPv8 se basa en un conjunto de mecanismos interconectados, defendibles uno por uno, que en conjunto crean la infraestructura de censura y vigilancia más potente jamás integrada en la especificación de un protocolo de internet.

Así funciona en la práctica.

DNS8 como puerta ineludible. En la internet actual, el bloqueo basado en DNS es la forma más débil de censura. Los usuarios pueden pasar del resolver de su ISP a 8.8.8.8, 1.1.1.1 o cualquier resolver abierto en segundos. El bloqueo por DNS se elude con facilidad. Con IPv8, DNS8 no es un resolver que se pueda sustituir. Es el Zone Server, y el Zone Server es el punto de salida obligatorio de todo el tráfico. No existe la opción de «usar otro servidor DNS». Si el Zone Server no resuelve su destino, la conexión se bloquea en la pasarela antes de que el paquete salga de su red: no en el extremo remoto ni en un router fronterizo, sino en su propia infraestructura local obligatoria.

WHOIS8 como interruptor de apagado del registro global. El ASN de destino de cada paquete saliente debe figurar en el registro WHOIS8 como una ruta activa registrada legítimamente. Si no figura, el paquete se descarta. Y, lo que es más grave, a nivel del BGP8 global, las rutas que no pueden validarse en WHOIS8 nunca llegan a instalarse en las tablas de enrutamiento. Esto significa que bloquear un recurso no requiere DPI, manipulación del DNS ni filtrado fronterizo. A un gobierno que controle, o pueda presionar, al registro regional de internet correspondiente le basta con asegurarse de que el prefijo de un ASN objetivo no figure en WHOIS8. Sin registro no hay ruta, y sin ruta no hay alcance, algo que se aplica en la capa de protocolo en todas las redes que implementen IPv8.

OAuth2/JWT: el fin de las conexiones anónimas. Todo dispositivo gestionado debe autenticarse mediante un token JWT antes de enviar su primer paquete. El protocolo es explícito: las conexiones anónimas a nivel IP dejan de existir. Esto está pensado para eliminar los canales de mando y control de malware, un problema real. Pero, al mismo tiempo, elimina el anonimato que hace eficaces a Tor, las VPN y las herramientas de privacidad. Un gobierno que controle la infraestructura de identidad (o que pueda obligar a hacerlo a los operadores que la controlan) obtiene la capacidad de atribuir cada conexión a una identidad autenticada concreta.

NetLog8: vigilancia integrada en la especificación. La recopilación obligatoria de telemetría en tiempo real no es una función opcional. Es obligatoria en todos los Zone Server. Cada autenticación, cada conexión y cada infracción de políticas se registra con su marca de tiempo. Se presenta como observabilidad de red para los operadores. Funciona igual de bien como registro exhaustivo de vigilancia del tráfico para actores estatales.

El borrador no contiene ningún marco de gobernanza sobre quién controla el Zone Server. No especifica qué supervisión rige la eliminación de registros de WHOIS8. No incluye ningún mecanismo de revisión judicial de las reglas ACL8 ni de la revocación de JWT. Se da por hecho que todo ello lo gestionarán de buena fe administradores de red legítimos.

Esa suposición no resiste el contacto con la realidad política de buena parte del mundo.

La comparación con la propuesta «New IP» de Huawei resulta reveladora. En 2020, Huawei presentó ante el UIT-T una propuesta llamada «New IP» que habría permitido un filtrado por paquete, autenticado y controlable por los gobiernos en la capa de red. La comunidad de gobernanza de internet la rechazó, incluidos la dirección del IETF, la Internet Society y varios gobiernos, precisamente porque habría integrado la capacidad de censura en el propio protocolo. IPv8 logra resultados estructuralmente idénticos mediante mecanismos técnicos distintos, al parecer sin que su autor pretendiera esta lectura. La intención no cambia la arquitectura.

Seamos directos: hoy, construir un sistema nacional de censura exige una enorme inversión en infraestructura superpuesta. La Gran Muralla Cortafuegos de China, el СОРМ de Rusia o la intranet nacional de Irán son sistemas caros y técnicamente exigentes que tienen que luchar contra un protocolo diseñado para la apertura. IPv8 invierte esta relación. Con su arquitectura, la internet abierta sería la capa superpuesta. La red controlada, autenticada, registrada y validada en la pasarela sería la capa base.

Qué significa esto para el mercado de direcciones IPv4

Para quienes trabajamos en el arrendamiento de direcciones IPv4 y su comercialización, IPv8 en su forma actual no representa ningún riesgo inmediato para el mercado. Es casi seguro que el borrador caducará en octubre sin que lo adopte ningún grupo de trabajo. Ningún gran fabricante, operador ni RIR le ha mostrado su apoyo.

La cuestión de fondo es si las ideas de IPv8 acabarán incorporándose a futuras propuestas que sí ganen tracción. El problema de la tabla de enrutamiento que identifica IPv8 es real. El problema de la fragmentación de la gestión es real. El problema del agotamiento de direcciones, aunque parcialmente resuelto por el despliegue continuado de IPv6, sigue siendo grave para las organizaciones que no pueden asumir el coste operativo de la transición a IPv6.

Si futuras propuestas heredan la lógica de direccionamiento centrada en el ASN de IPv8, incluida la idea de que cada titular de un ASN reciba un gran bloque de direcciones privado, las consecuencias para el mercado secundario de IPv4 serían importantes. La propuesta de valor de las direcciones IPv4 arrendadas depende de la escasez de direcciones y del coste operativo de la transición a IPv6. Una arquitectura que eliminara ambos factores, manteniendo a la vez la compatibilidad con IPv4, afectaría directamente a ese mercado.

Ese escenario es especulativo y lejano. Lo que no es especulativo es la arquitectura de censura integrada en el diseño de IPv8. Prospere o no este borrador concreto, el patrón que representa (concentrar la resolución DNS, la autenticación de identidad, la validación de rutas y el registro del tráfico en una única plataforma obligatoria) reaparecerá en futuras propuestas. Cuando lo haga, la cuestión de quién controla esa plataforma será la más importante que plantear.

Conclusión

Es poco probable que draft-thain-ipv8 llegue a convertirse en un estándar. Sus carencias técnicas, sus fallos de proceso y el momento incómodo respecto al hito de despliegue de IPv6 hacen improbable su adopción. Pero es una propuesta detallada y técnicamente ambiciosa que pone sobre la mesa cuestiones realmente importantes: ¿se puede resolver la fragmentación de la gestión en la capa de protocolo? ¿Se puede acotar arquitectónicamente el crecimiento de la tabla BGP? Y, sobre todo, ¿puede confiarse en que cualquier protocolo que logre un control del tráfico obligatorio, universal, autenticado y registrado vaya a ser gestionado de buena fe por todos los gobiernos del planeta?

La respuesta a esta última pregunta es la razón por la que importa el principio de extremo a extremo. Una internet en la que cada conexión está atribuida, cada destino se valida previamente frente a un registro accesible para los gobiernos y cada paquete pasa por una plataforma obligatoria controlada por quien tenga la infraestructura no es una internet más segura. Es una internet más controlada. Merece la pena preservar esa distinción, por elegante que sea el formato de dirección.