La propuesta del Internet Protocol Version 8 (IPv8) para tener compatibilidad con IPv4 e ignorar IPv6

Estamos en el proceso de migrar todo el tráfico IPv4 a IPv6 desde hace ya unos años, y la verdad es que poco a poco esto está creciendo, pero aún estamos lejos de llegar al objetivo de tener más tráfico IPv6 que tráfico IPv4 en las redes de todo el mundo. Sin embargo, existen algunas otras propuestas de cambios para IPv4 distintas a la de IPv6, y recientemente se ha publicado la propuesta hecha por James Thain de, en lugar de migrar a IPv6, hacerlo a IPv8, que es cuanto menos interesante.

Figura 1: La propuesta del Internet Protocol Version 8 (IPv8)

para tener compatibilidad con IPv4 e ignorar IPv6

La propuesta fue publicada hace menos de un mes, con una serie completa de documentos para definir los protocolos necesarios para pasar a IPv8, como serían los protocolos DHCP8, WHOIS8, y el conjunto mínimo de protocolos de gestión del enrutamiento de tráfico IPv8 en las redes de Internet de hoy en día.

Figura 2: Propuesta de Internet Protocol Version 8 (IPv8)

El objetivo principal de esta propuesta, como bien se explica a lo largo de todo el documento, que la verdad, es bastante sencillo de leer, consiste en mantener la compatibilidad hacia atrás con todo lo construido hasta el momento, haciendo un cambio muy pequeño, que es cambiar la dirección IPv4 por la dirección IPv8.

Figura 3: Paquete de dirección IPv8

La gran diferencia, como se puede ver en el paquete IPv8 es que se añaden las cabeceras ASN de 32 bits tanto a la dirección IP de origen, como a la dirección IP de destino, lo que permite a los protocolos de enrutamiento reenviar correctamente al ASN correspondiente el paquete correctamente.

Figura 4: Compatibilidad hacia atrás de IPv8 con IPv4

Al añadir el Autonomous System Number (ASN), marcado como r.r.r.r, en los cuatro primeros bytes, una dirección IPv8 sería la suma de la parte de ASN r.r.r.r más la parte de IPv4 clásica, a la que se llama en el documento como n.n.n.n. 

Figura 5: Direcciones IPV8

Esto sería como tener 2 a la 32 veces el tamaño de direcciones IPv4 que tenemos hoy en día, y dejando la dirección 0.0.0.0.n.n.n.n como la red de IPv4 que tenemos en Internet funcionando ahora mismo.

Figura 6: r.r.r.r igual 0.0.0.0 sería el IPv4 de hoy en día.

Es decir, con un cambio sencillo en el envío de paquetes de red IPv4 se podría resolver el problema de que se acaben las direcciones IPv4 manteniendo todo el software construido sobre él funcionando. Y la propuesta es porque está costando ir más rápido a IPv6 de lo que se estaba esperando al inicio. Si miramos radar, podemos ver en Radar de Cloudflare que en los últimos doce meses el tráfico sobre IPv6 está estable en un 30% más o menos.

Figura 7: Trafico IPv4 vs. Tráfico IPv6 en Radar de Cloudflare

Claro, mantener la compatibilidad hacia atrás implica que sigan funcionando todos los ataque en redes de datos IPv4 que ya conocemos, además de todas sus medidas de seguridad. Es decir, se supone que el conocimiento que tenemos de estos protocolos debemos usarlos en hacerlos más seguros y no en migrarlos.

Figura 8: Ataques en redes de datos IPv4&IPv6 (4ª Edición) de

JL. Rambla, ampliado y revisado por Pablo González y Chema Alonso

Los cambios que sí que habría que hacer son los relativos a la interconexión de redes, por lo que todos los protocolos de enrutamiento de tráfico y gestión de redes deberían cambiar a IPv8, como serían BGP8, OSPF8, WHOIS8, SNMP8, etcétera, que están definidos en sus correspondientes documentos.

Figura 9: Documentos para los protocolos de gestión de redes IPv8

Y por supuesto, crear los tipos de redes especiales con direccionamientos reservados, al igual que tenemos en IPv4 e IPv6, que están descritos con detalle en el documento de Internet Protocol Version 8 (IPv8) del que estamos hablando.

Figura 10: Tipos de redes en IPv8

El documento recoge también las direcciones especiales que deben existir en estas redes IPv8, donde los nodos de enrutamiento dentro de tráfico a través de los ASNs deben ser tenidos en cuenta de manera especial, así que en la definición de estándar están especificados.

Figura 11: Direcciones especiales en IPv8

En definitiva, me parece una propuesta súper bonita como trabajo técnico de arquitectura de redes. Me falta criterio tan pronto para decir si es una opción mejor que ir hacia IPv6 o no, pero desde luego mis felicitaciones a James Thain por este trabajo tan bonito que ha publicado. Así es la investigación y la innovación, proponer ideas concretas que puedan ser evaluadas y aprender de ellas. 

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Multipath Reliable Connection (MRC): Un protocolo de red diseñado para los LLMs

Este fin de semana he estado leyendo sobre este nuevo protocolo de red creado especialmente para resolver el problema de la congestión del tráfico de red que se produce en los mega-datacenters utilizados para entrenar los nuevos LLM cuando se mueven datos de GPU a GPU en los centros de datos. En estos casos, estamos hablando de interconexión de datos entre clusters que pueden contener centenares de miles de GPUs, por lo que los protocolos que envían los datos por la red son críticos en la reducción del tiempo de entrenamiento, mediante una reducción de la latencia de envío de paquetes de red y, por consiguiente, reducción del consumo de energía. 

Figura 1: Multipath Reliable Connection (MRC).

Un protocolo de red diseñado para los LLMs

MRC está creado específicamente para resolver esos problemas, y ha sido publicado en el paper de Open Compute "Multipath Reliable Connection (MRC) Specification" donde equipos de OpenAI, Microsoft, NVIDIA, Broadcom y AMD han estado trabajando para definir el nuevo protocolo que ya han puesto en producción en los clusters de entrenamiento de OpenAI y Microsoft, incluidos centros de datos de entrenamiento de Oracle.

Figura 2: Multipath Reliable Connection (MRC)

El protocolo MRC se basa en RoCEv2 (RDMA over Converged Ethernet v2), es decir, que sigue aprovechando las capacidades de RDMA (Remote Direct Access Memory) para enviar tráfico por la red de computador a computador desde la memoria de uno hasta la memoria de otro sin pasar por la CPU utilizando RoCEv2, que está diseñado especialmente para las redes Ethernet.

Figura 3: La red es el punto de congestión de los mega-datacenters

Sin embargo, en entornos de alta congestión - como es el de entrenar un LLM de frontera en un datacenter con cientos de miles des GPUs pasándose datos - , es que la red necesita una arquitectura de capas (Tiers) para conectar switches, de tal manera que dependiendo de la distancia física que exista entre las GPUs que se pasan los datos, hay que atravesar muchas capas de Switches de interconexión, y es ahí donde se produce la congestión. 

Figura 4: La propuesta de OCP es MRC con Packet Spraying

Para resolver esto, la solución es ampliar el número de capas, ampliando la latencia, para que existan más rutas posibles, lo que tampoco es una solución perfecta. Lo que propone MRC es utilizar Packet Spraying, es decir, dividir los datos que se van a enviar en pequeños paquetes de red que utilizarán, cada uno de ellos, una ruta diferente dentro de las rutas posibles.

Figura 5: Arquitectura en Tiers de Switches

Para eso es necesario conocer el estado de calidad de la red, los puertos disponibles, y poder crear una ruta para cada paquete de la red. Esto se hace con un protocolo llamado  SRv6 (Segment Routing over IPv6) que se encarga de crear la ruta para cada paquete dentro de la estructura de Tiers de los Switches de interconexión. 

Figura 6: Control de Congestión con QPCP

La especificación completa, donde se definen los estados de los protocolos de control de la congestión y calidad de la red en cada momento QP Congestion Protocol (QPCP) están todos correctamente descritos en la especificación, ya que se trata de un protocolo abierto, y tienes el paper académico de Resilient AI Supercomputer Networking using MRC and SRv6 con las pruebas realizadas publicado.

Figura 7: Resilient AI Supercomputer Networking using MRC and SRv6

Este es un ejemplo de cómo la necesidad de innovar con Inteligencia Artificial está impulsando la innovación en otras áreas adyacentes de forma masiva, como es la gestión de la energía, los protocolos de red o la gestión de grandes volúmenes de datos. 

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Cloudflare Talks en Londres: The Intelligent Network, Connect on Tour & Futurenet World en Abril.

Esta semana que viene, el día 15 de Abril, voy a estar en The Wave, en Zaragoza, dando una conferencia con Cloudflare y Nunsys, pero también subiré el día antes a Londres donde tenemos una semana de eventos con Cloudflare Connnect on Tour. Pero además también regresaré la semana de después, para participar en Futurenet. Viajes interesantes a la capital de UK que os dejo hoy por aquí.

Figura 1: Cloudflare Connnect on Tour.

Mi primera charla será en The Intelligent Network el día 14 de Abril, que es un evento sólo para un grupo de CXO y que tendrá lugar en Londres la próxima semana. No os puedo dejar más información, ya que el evento va solo por invitación, pero habrá en abierto otros. Pero del que sí os puedo dejar información es de Cloudflare Connect on Tour London 2026, que tendrá lugar el día 15 de Abril.

Figura 2: Cloudflare Connnect on Tour.

La lista de Speakers es de primera linea, con Stephanie Cohen, Chief Strategy Officer de Cloudflare, Grant Bourzikas, Chief Security Officer de Cloudflare, Ramy Houssaini Chief Cyber Solutions Officer Cloudflare o Tony Van den Berge, Geo Vice President, EMEA Cloudflare. Puedes registrarte en la web, pero date prisa que queda poco tiempo.

Figura 3: Regístrate al Cloudflare Connect on Tour London 2026

Después estos dos eventos, la tercera cita será en Futurenet World, que tendrá lugar a la semana siguiente, los días 21 y 22 de Abril, también en Londres, y donde yo estaré dando una charla el primer día, para hablar de "cómo fortificar despliegues de IA en la empresa".

Figura 4: Chema Alonso en Futurenet World

O sea, que si estás por Londres estos días, puede que te cruces conmigo "at random" por la city, y si vienes a alguna de las charlas, pues nos vemos seguro, que estaré trabajando en la ciudad "de los cielos grises".

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Pon a prueba la calidad de tu conexión a Internet con Cloudflare

El equipo de Radar en Cloudflare acaba de incorporar el Test de Velocidad para tu conexión a Internet que puedes probar gratuitamente desde las herramientas disponibles. Con este test se miden cosas como la velocidad de descarga de datos, de subida de datos, pero también condiciones de latencia, y lo mejor, una comparativa con otras conexiones cercanas geográficamente a ti, así que puedes darle una prueba rápida, a ver qué descubres.

Figura 1: Pon a prueba la calidad de tu conexión a Internet con Cloudflare

Yo lo he probado desde mi piso en Lisboa, donde mi conexión a Internet está compartida y ya sabéis que no es un Internet tan rápido y bueno como el de España, así que los resultados no han sido muy espectaculares, por lo que mejor aún porque me sirve para ver que tengo espacio para mejorar en la calidad de mis conexiones a Internet.

Figura 2: Network Quality Test en Cloudflare Radar

Para hacer el test, se consume la descarga de 200Mb de tráfico sintético desde tu dirección IP a servidores de Cloudflare, donde se tienen medidos todos los tests que se realizan con este proceso de comparación de la calidad de la conexión.

Figura 3: Funcionamiento del Test en Cloudflare Radar

En mi caso, como podéis ver, la conexión la he hecho desde Lisboa, Portugal, y utilizando conexión IPv6 que como me conecto con el cliente WARP a Internet, mi tráfico va todo en IPv6 y PQC por defecto.

Figura 4: Datos de conexión en el Test

Y los resultados, pues a parte de tener los números en la primera captura, tenemos las gráficas que nos sitúan en comparación con otras conexiones y test realizados desde mismas ubicaciones geográficas, que en mi caso es que yo estoy por debajo de la media en velocidad de descarga y de subida.

Figura 5: Por debajo en ancho de banda de tráfico de subida y bajada

Y sin embargo, en latencias estoy por encima, es decir peor, porque mi conexión genera más retraso en las peticiones de transferencia de paquetes, así que tengo espacio para mejorar con mi proveedor de Internet en donde vivo aquí.

Figura 6: Comparativa de latencias. También peor que la media

Si quieres más detalles, puedes aún tener más información de tu conexión, si te vas a utilizar la herramienta de Speed Test de Cloudflare, que es una versión con algunos datos extras, aunque en el fondo veréis que los puntos de medición son los mismos.

Figura 7: Ataques en redes de datos IPv4&IPv6 (4ª Edición) de

JL. Rambla, ampliado y revisado por Pablo González y Chema Alonso

Para ello te vas a Speed Test Cloudflare, y allí seleccionas la opción de realizar ejecutar el test de velocidad y listo. No tiene ninguna complejidad más que dar al botón de Start.

Figura 8: Realizar un test en Sppedtest Cloudflare

Una vez realizado, como lo estoy haciendo desde el mismo equipo y la misma red, y la prueba es la misma, podéis ver que los datos son muy similares, a excepción de detalles de anomalías puntuales de contexto en la red. En este caso, prácticamente iguales. 

Figura 9: 95.4 Mbps de descarga, 13.2 de subida

Como podéis ver, la conexión es buena para ver vídeo en streaming, pero para jugar online o vídeo conferencias múltiples es una conexión "Average". Vamos, del montón, por culpa de la latencia, que no da buenos resultados.

Figura 10: Medidas de latencia con 0 pérdidas de paquetes.

Como podéis ver, mi conexión es desde el Barrio de Alcantara en Lisboa, y usando IPv6 para conectarme al servidor de medición en la red de Cloudflare.

Figura 11: Conexión a la red de Cloudflare con cliente WARP

Del funcionamiento del cliente WARP os publiqué un artículo hace unas semanas, que te permite tener la conexión acelerada, evitar bloqueos de red, navegar con WAF de protección, utilizando IPv6 y con criptografía PQC (Post-Quantum Criptography), así que más que recomendado. 

Figura 12: Un clic en WARP y conexión Securizada

Y por supuesto, tienes también las mediciones detalladas del tráfico de subida y tráfico de bajada para que tengas los detalles de cómo se ha hecho el test de velocidad con tu conexión.

Figura 13: Detalles de las mediciones de tráfico de bajada

Como véis, se hacen los 200Mb en 4 tests de 25Mb, en 6 tests de 10Mb, 8 tests de 1Mb y 10 tests de 100Kb, para ver cómo se comporta la red ante diferentes tipos de tamaños de descargas. Y lo mismo para la subida de tráfico.

Figura 14: Detalles de las mediciones de subida de tráfico

Esta información te puede dar una buena idea de dónde estás con tu conexión a Internet. Yo te recomiendo que hagas la prueba con tu conexión, y luego te instales el Cliente WARP y pruebes lo que es navegar con la aceleración del Edge de Cloudflare, la seguridad del WAF por defecto, las conexiones IPv6 y el cifrado PQC. Ya te lo he dicho.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Trinetra: Datos y Conocimiento Sobre el uso de IPv6 en Organizaciones en España

Siempre me ha gustado el dicho de “Dato mata Relato” para entender con precisión el estado del arte y poder extraer conclusiones y acciones fructíferas en temas tan opinables como es el grado de adopción de IPv6 por parte de las empresas y otros tipos de organizaciones. En esto del IPv6 se ha seguido un poco el “modelo de Internet” donde se ha llevado primero a los usuarios finales (50% de adopción mundial mientras escribo estas líneas) pero las empresas y administraciones todavía no están ahí.

Figura 1: Trinetra -Datos y Conocimiento Sobre

el uso de IPv6 en Organizaciones en España

Pero veamos con datos dónde estamos claramente. Precisamente con esta idea, me decidí a hacer un modesto proyecto en Python los últimos fines de semana. He bautizado este proyecto, en honor a mis raíces hindúes, como “Trinetra” porque esta palabra alude al tercer ojo de la deidad Shiva, símbolo de visión profunda, claridad y revelación de lo oculto.

Figura 2: Ataques en redes de datos IPv4&IPv6 (4ª Edición) de

JL. Rambla, ampliado y revisado por Pablo González y Chema Alonso

La idea es que, identificando y analizando los recursos que las organizaciones de distintos sectores exponen en IPv6, entenderemos que tipo de empresas, administraciones públicas y universidades están contribuyendo, cómo lo están haciendo y si hay alguna conclusión/recomendación que podamos extraer. Desde el punto de vista de la ciberseguridad, sólo con una visión más clara y profunda podremos entender y proteger esta nueva superficie de exposición que es IPv6.

Grado de Adopción de IPv6 por Sector en España en Marzo de 2026

Veamos primero dónde estamos, cómo lo están haciendo otros países y qué conclusiones podemos sacar con un análisis puntual. En futuros artículos podremos analizar aspectos más interesantes y la propia evolución del ecosistema. El siguiente gráfico nos muestra, para cada sector, el grado de adopción de IPv6 del mismo, en términos de empresas que exponen alguno de sus dominios en IPv6 públicamente en Internet. 

• Infraestructuras: 100% aunque poco representativo, pues se ha analizado 1.
• Servicios: un 50% con 6 analizadas.
• Seguros: un 50% con 2 analizadas.
• Consumo: un 36,8% con 19 analizadas.
• Energía: un 33% de 15 analizadas.
• Universidades (Educación): tenemos un 24,4% de un total de 33 organizadas analizadas.
• Administraciones Públicas (Administración): llegan a un 25% de un toral de 36 analizadas.

En total, hemos analizado 220 empresas de las cuales 57 (un 25,91%) exponen algún dominio en IPv6. Algunas conclusiones del top por sector.

Figura 3: Distribución por sectores

Un análisis más detallado, recogido en el siguiente diagrama, es mostrar estos resultados no en función del número de empresas, sino de los dominios totales del sector expuestos en IPv6 frente al número de dominios totales analizados.

Figura 4: Distribución sectorial por dominios

Ranking sectorial de Campeones IPv6 en España en 2026

De las empresas analizadas en cada uno de los distintos sectores, el siguiente gráfico muestra las que están exponiendo recursos IPv6. En la leyenda, el primer número corresponde a las empresas de ese sector con recursos en IPv6 y el segundo es el porcentaje sobre el total de empresas de todos los sectores que exponen IPv6.

Figura 5: Contribución sectorial a IPv6 en España

Así, por ejemplo, para el sector de Energía, de las 82 empresas analizadas que veíamos en el gráfico anterior, 5 exponen recursos IPv6 y esto supone un 9% de las empresas que

Ranking de Métodos de Exposición en IPv6 en España en 2026

De las 220 organizaciones analizadas, 57 exponen dominios en IPv6 pero dos de ellas lo hacen de dos maneras distintas por lo que hay 59 items en total, de los cuales los líderes son las CDN Akamai (37%) y Cloudflare (20%), seguidos del servicio CDN de AWS, CloudFront, con un 15% del porcentaje.

Figura 6: Métodos para exponer recursos IPv6

Por tanto, podemos decir que la mayoría de la exposición es a través de CDNs, en muchos casos seguramente son los proxies de la CDN los que habilitan IPv6 traduciendo las peticiones para los servers IPv4-only de las organizaciones, pero algo es algo. De todos modos, no siempre tiene que ser así, nuestra Web del IPv6 Council se expone a través de Cloudflare y las peticiones en IPv6 se progresan hasta nuestro server en la Cloud de Telefónica Tech en este mismo protocolo.

No obstante, podemos ver algunas organizaciones con direccionamiento propio o direccionamiento de hosts en proveedores cloud que parecen indicar que algunas tienen confirmado un despliegue IPv6 en sus servidores (alrededor de un 20%).

Herramienta Utilizada

La herramienta Python para obtener los datos de este informe, Trineta, no es muy complicada, pero he publicado el código en un repo GIT de codeberg.org por si queréis clonarlo y probar con el CSV de organizaciones en España que uso yo o bien probar con otro propio.

Figura 7: Trineta en su repo GIT

Esta herramienta es parte de las utilidades que estamos desarrollando en la comunidad de ciberseguridad del IPv6 Council España y se ejecuta en las máquinas de nuestro laboratorio IPv6-only SecLab. 

Figura 8: Laboratorio IPv6-only SecLab

Próximos Pasos

Si has leído hasta aquí, lo primero muchas gracias, y lo segundo, igual te estás preguntando como yo, cómo están yendo estas mismas métricas ahora mismo en otros países y cómo van a ir evolucionando. Como prueba a alto nivel, utilizando Cloudflare Radar podemos ver el porcentaje de peticiones HTTP hechas sobre IPv4 y sobre IPv6 en España.

Figura 9: Tráfico HTTP sobre IPv4 y sobre IPv6 en España

Un 10%, pero si miramos, por ejemplo, Alemania, el resultado nos deja bastante por detrás, ya que allí el porcentaje llega hasta el 38%. Así que tenemos espacio de mejora, eso seguro.

Figura 10: Tráfico HTTP sobre IPv4 y sobre IPv6 en Alemania

Puede que tengas más interrogantes que quieres compartir con nosotros, para ir construyendo informes más valiosos. Nos vemos en siguientes artículos, y si quieres puedes colaborar con nosotros. Contacta conmigo si quieres colaborar con hacer que IPv6 se despliegue más rápido en España.

¡Saludos Malignos!

Autor: Carlos Ralli 

Contactar con Carlos Ralli Ucendo