La nueva versión de IP que podría eclipsar IPv6

Tiempo de lectura: 10 minutos

El nuevo borrador presentado ante la IETF como alternativa a IPv6: IPv8

IPv4 quedó obsoleto hace décadas, sin embargo, la transición a IPv6 no parece estar funcionando como una alternativa viable. Recientemente se ha propuesto un borrador de un nuevo protocolo que podría sustituir a ambos: IPv8.

Las IPs son las direcciones de red que hacen posibles las comunicaciones entre sistemas. La mayoría de IPs que se ven a diario son IPv4. Esta versión fue desarrollada en los años 80, y falló en prever el crecimiento exponencial que sufriría internet.

Las direcciones constan de 4 octetos (un octeto son 8 bits). Es decir, 4 números, representados en decimal desde el 0 al 255 separados por puntos.

IPv4

En total, las direcciones IPv4 son de 32 bits de longitud (8 × 4 = 32). Ya que los bits tienen dos valores posibles, la cantidad total de direcciones IPv4 potenciales es 2³², es decir, 4.294.967.296 o ~4,3 mil millones de direcciones posibles.

Los ingenieros que desarrollaron IPv4 consideraron que esa cantidad de direcciones sería suficiente para abastecer al mundo, pero fallaron en prever el estallido de los dispositivos móviles y el IoT.

Se estima que hay entre 19 mil millones, según IoT Analytics, y los 41,6 mil millones que calcula IDC de dispositivos conectados; el recuento varía en función de la actividad de los dispositivos y de si se tienen en cuenta o no algunos dispositivos IoT.

Aún con las cifras conservadoras, la cantidad de direcciones actual sobrepasa por mucho la capacidad de IPv4, y es de esperar que siga aumentando.

El agotamiento de direcciones IPv4 fue llegando por zonas, comenzando en 2011 en IANA (central), y volviéndose definitivo en LACNIC (LATAM) en 2020. Esto se debe principalmente a varios factores.

• Enriquecimiento global: más poder adquisitivo, más dispositivos por persona
• Abaratamiento de los costes de compra
• Auge de la industria de los dispositivos móviles
• Estandarización de los dispositivos IoT: cámaras, relojes, termómetros… Todos conectados a Internet.

Esto significa que ya no quedan IPs, todas están asignadas, y para conseguir una es necesario comprarla. Pero, si cada vez hay más dispositivos y las direcciones se acabaron en 2011 ¿cómo es que casi todos los dispositivos siguen funcionando con IPv4?

Algunos arreglos a IPv4

Para mitigar este agotamiento de direcciones, se han propuesto e implementado distintas tecnologías con el fin de liberar un poco la carga que soporta IPv4 y alargar lo inevitable: una transición de protocolo.

Reclamar IPs en desuso

La medida más burocrática y menos eficiente. La IANA (Internet Assigned Numbers Authority) coordina la asignación global de direcciones IP, delegando su gestión regional en los cinco RIR (RIPE NCC, ARIN, APNIC, LACNIC y AFRINIC). Son estos registros quienes tramitarían la reclamación de IPs en desuso, algo que, a pesar de ser técnicamente complejo, era posible.

Sin embargo, la carga administrativa y posibles represalias legales que podrían tomar las empresas a las que se le sustraen IPs volverían el proceso excesivamente complicado.

CIDR (Classless Inter-Domain Routing)

Implementado en 1993 con el objetivo de retrasar el agotamiento de IPv4. En principio, se diseñó como una solución a corto plazo, con un tiempo previsto de 5 años. Pero ya en su revisión en 2006 se había convertido en una solución a medio plazo, y sigue en uso hoy.

La solución que plantea consiste en abandonar el modelo de IPs por clase. En uso hasta ese momento:

Clase	Rango del Primer Octeto	Máscara por Defecto	Propósito / Uso	Ejemplo de IP	Cantidad IPs
Clase A	1 – 126	255.0.0.0	Redes masivas (Gubernamentales, ISPs).	10.0.0.1	16.777.214
Clase B	128 – 191	255.255.0.0	Redes medianas (Universidades, Empresas).	172.16.254.1	65.534
Clase C	192 – 223	255.255.255.0	Redes pequeñas (Hogar, Pequeñas oficinas).	192.168.1.50	254
Clase D	224 – 239	N/A	Multicast: Transmisión de datos a un grupo.	224.0.0.1
Clase E	240 – 255	N/A	Experimental: Reservado para investigación.	241.0.0.2

Por una notación que consiste en un valor de 4 octetos —como una IP normal— y una máscara de red. Por ejemplo, 192.20.0.0/16. La cifra decimal tras la barra indica la cantidad de bits de la máscara de red, en el ejemplo, sería 255.255.0.0, una red que permite 2¹⁶ o 65.536 IPs.

CIDR	Máscara de Red (Decimal)	Total de IPs	IPs Útiles (Hosts)	Explicación Breve
/32	255.255.255.255	1	1	Define una única IP (Host específico).
/30	255.255.255.252	4	2	Ideal para enlaces Punto a Punto (Router a Router).
/29	255.255.255.248	8	6	Redes muy pequeñas (ej. servidores públicos limitados).
/27	255.255.255.224	32	30	Segmentación de departamentos pequeños.
/24	255.255.255.0	256	254	El estándar para LANs domésticas y pequeñas oficinas.
/21	255.255.248.0	2.048	2.046	Redes corporativas grandes con muchos dispositivos.
/16	255.255.0.0	65.536	65.534	Redes de campus o infraestructuras cloud extensas.
/8	255.0.0.0	16.7M	16.7M	Redes globales o privadas masivas (ej. Red 10.x.x.x).

Esto permite dar IPs en bloques más granulares que con el modelo de clases, en función de las necesidades de cada organización, liberando muchas IPs que estaban contenidas en rangos demasiado grandes para el tamaño de una organización.

Por ejemplo, si la empresa Ejemplo S.A. necesita 300 IPs, se le daría una clase B, desperdiciando 65.236 direcciones. Con el modelo CIDR, en cambio, se le asignaría un bloque /23 de 512 direcciones, suficiente para sus necesidades y ahorrando 65.024 IPs. Si en el futuro creciesen las necesidades hasta los 600 hosts, se aprovisiona un bloque /22.

Nota. Las cifras usan el total de direcciones del bloque. En la práctica, cada bloque reserva 2 direcciones no asignables (la de red y la de broadcast), por lo que las útiles son 2 menos: una clase B ofrece 65.534 y un /23, 510.

NAT (Network Address Translation)

El protocolo NAT permite asignar una IP a múltiples dispositivos. Presente en prácticamente todas las redes domésticas, el router asume una IP pública y crea dentro de sí una subred privada cuyas IPs no es necesario aprovisionar, ya que la red existe solo dentro del router.

Cuando el router recibe un paquete a reenviar de una IP interna, sustituye la IP de origen por su propia IP y lo manda. Cuando regresa una respuesta, en base a una tabla de enrutamiento construida en base a IPs y puertos, el router reenvía los paquetes al equipo donde se originó la petición.

En una red de, por ejemplo, 10 dispositivos, esto ahorra 9 IPs, ya que una única IP pública sirve para esos 10 dispositivos.

CGNAT (Carrier-Grade NAT)

CGNAT o NAT a gran escala consiste en aglomerar múltiples IPs privadas asociadas a una pública. De forma similar al NAT en redes domésticas, se agrupan IPs privadas dentro de una red, en la que se utiliza una única IP pública para toda la red y se gestionan desde el borde de la red las redirecciones internas.

La diferencia con NAT es la escala, mientras que NAT funciona en redes desde un router hacia dentro, CGNAT se implementa a nivel de ISP (Internet Service Provider).

Esto implica un alcance muchísimo mayor, pudiendo abarcar un CGNAT regiones enteras. Un router del borde de la red «privada» del proveedor seguirá un proceso similar al del NAT doméstico cuando envía paquetes fuera de su red y mantendrá una tabla de rutas para saber a dónde devolver las respuestas.

Si con el NAT doméstico se podían ahorrar 9 IPs en un hogar u oficina con 10, CGNAT puede llegar a ahorrar —teóricamente— 65.535 (el máximo de puertos) IPs privadas por cada pública, en la práctica al ahorro oscila entre los ratios 64:1 y 512:1, según las exigencias de red y el servicio contratado.

Esta anidación de las redes y sus direcciones en estructuras jerárquicas ahorra muchas IPs, pero continúa sin ser una solución viable a largo plazo.

DHCP

Por último, DHCP (Dynamic Host Configuration Protocol) ayuda a rotar IPs rápidamente: cuando un equipo se une a la red, solicita una dirección, lo que permite aprovisionarlas y liberarlas dinámicamente, aliviando la carga de IPv4.

IPv6

Ninguna de estas muletas es ni pretendía ser una solución real. El crecimiento de Internet hace imposible la viabilidad de IPv4 a largo plazo. Para poner una solución definitiva a este problema, se propuso el estándar IPv6.

Esta versión pretende acabar con el problema de raíz, cambiando la forma de las direcciones para que estas tengan una cantidad tal de direcciones posibles que no sea plausible volver a agotarlas.

Las direcciones IPv6 tienen 128 bits en lugar de 32, y se dividen en hextets (16 bits) en lugar de octetos. En total, son 8 campos de 16 bits (128 ÷ 16 = 8), representados de forma alfanumérica con cuatro caracteres. Por ejemplo 2001:0db8:85a3:0000:0000:8a2e:0370:7334.

De nuevo, al tener cada bit dos posibilidades, y tener las direcciones 128 bits, las posibles direcciones son 2¹²⁸, es decir, 340282366920938463463374607431768211456, o 340 sextillones (billones de billones de billones).

El estancamiento de IPv6

Pretendía ser una solución definitiva, y se planteó como tal en su salida en 1998. 28 años después, solo el 45,74% del tráfico que recibe Google es a través de IPv6.

La migración a IPv6 ha tratado de realizarse con un modelo de transición dual-stack. Las versiones son protocolos totalmente distintos, y los dispositivos deben soportar ambos protocolos para que la migración sea posible sin disrupciones. El tiempo ha dejado claro que la migración total no iba a llegar como se planeó en su día.

El borrador de IPv8 publicado en la IETF pone el foco del problema en la viabilidad comercial. El protocolo es bueno desde un punto de vista técnico, pero los incentivos no son suficientes. La necesaria colaboración de las organizaciones ha brillado por su ausencia, lo que el autor identifica como un factor diferencial en el presunto fracaso de IPv6.

«La ausencia de una medida coercitiva implica que las organizaciones pueden continuar con CGNAT de forma indefinida»

— Borrador draft-thain-ipv8-00, §2.2

Al ser viable a medio plazo estirar la vida de IPv4 mediante CGNAT, las organizaciones no tienen incentivos para invertir en el coste operacional, técnico y económico que supone la migración total a IPv6.

Pese a crecer en uso, el ritmo es demasiado lento, los «parches» funcionan lo suficientemente bien como para eliminar la sensación de urgencia, y la transición es un reto quizá demasiado grande para ser coordinado a nivel global. Por eso muchos dan por perdido IPv6, y algunos han empezado a trabajar en alternativas. La respuesta es IPv8, presentado el 14 de abril del 2026 por J.Thain.

La nueva propuesta: IPv8

En la búsqueda de un nuevo candidato para sustituir a IPv4, era clave cumplir varios puntos.

• Viabilidad de migración sin modelo dual-stack
• Compatibilidad total con IPv4
• Expansión masiva de direcciones disponibles
• Implementable solo con actualizaciones software, sin tocar los componentes físicos.
• Formato legible por humanos y consistente con el de IPv4

Para cumplir todos estos requerimientos, se desarrolla IPv8, cuyas direcciones tienen este aspecto.

0.0.251.240.93.184.216.34

A efectos prácticos, son dos direcciones IPv4 seguidas. Hay 8 octetos en lugar de 4, es decir, el doble de bits (8 × 8 = 64), pero la estructura es muy similar. En números, esta versión habilita 2⁶⁴ o 18446744073709551616 posibles direcciones. Es decir, 18 trillones (un millón de billones). Son muchas menos que con IPv6, pero muchas más que con IPv4. Además, cumple los requisitos uno por uno:

• Viabilidad: Es compatible con IPv4, por lo que no es necesario modelo dual-stack
• Compatibilidad: Son dos IPv4 concatenadas
• Expansión: IPv8 tiene ~4.300 millones de veces más direcciones posibles que IPv4
• Es implementable solo con actualizaciones
• El formato es familiar y legible

¿Cómo funciona?

La estructura es la siguiente:

r.r.r.r.n.n.n.n

Los primeros 4 octetos (r) son un prefijo ASN, o Autonomous System Number, que identifica el AS (ASN y AS se explican en la siguiente sección), los 4 últimos octetos (n), semánticamente idénticos a una IPv4, identifican la dirección del host individual. Es decir, para representar una IPv4 como IPv8 bastaría con hacer la siguiente conversión: 192.12.1.56 → 0.0.0.0.192.12.1.56.

Un paquete cuya dirección de destino contiene 4 ceros en los primeros 4 octetos ha de ser tratado como una IPv4 a la hora de enrutar. Esta simple decisión habilita total compatibilidad con IPv4 con mínimo esfuerzo.

De todas formas, es imposible comprender esto bien sin explicar los AS y ASNs. Internet es una red de redes, y se llama AS o sistemas autónomos a las redes masivas que componen Internet.

Más específicamente, un AS es una red o agrupación de redes grande que tiene una política de enrutamiento unificada. Todos los dispositivos conectados a Internet lo están a través de un AS y estos se coordinan para habilitar las comunicaciones a nivel global.

El Autonomous System Number (ASN)

Un ASN es un número de hasta 32 bits, entre 1 y 2³² (~4,300 mill.) que identifica un AS. Por ejemplo, el ASN de Amazon es AS16509.

¿Qué más tiene una longitud de 32 bits? Una dirección IPv4. Los primeros 4 octetos de una dirección IPv8 no son más que un prefijo que identifica el ASN (como si fuera la extensión de un número de teléfono).

Aunque sea simple, no es trivial: esto consigue dar el espacio completo de direcciones IPv4 —todas las que existen hoy en el mundo— a cada uno de los (posibles) ~4,3 millones de ASNs.

Más ventajas

El plan de implementación se basa en un modelo de negociación de versión vía ARP8 y ARP4. Los host negocian el protocolo a utilizar, pudiendo proceder vía IPv4 en cualquier momento.

A diferencia de la transición dual-stack planteada por IPv6, IPv8 puede degradar a IPv4 si el host con el que se comunica no entiende IPv8.

Además, IPv8 tiene incentivos, al estar identificado el ASN destinatario del paquete en la primera mitad de la dirección, se alivia la carga de los AS: no se requiere coordinación entre operadores ni túneles preconfigurados entre bordes, porque el AS destinatario está en la propia dirección de destino.

Los retos a superar

IPv8 viene con su propia colección de retos a superar. En primer lugar, esto solo se trata de un borrador en su segunda versión. Si no se aporta revisión antes del 19 de octubre, el borrador expira.

Para que el borrador pase a ser aceptado por la IETF y se pueda comenzar a hablar de una transición a IPv8, es necesario revisar la propuesta, perfeccionarla y conseguir el apoyo de la IETF.

Aún si eso se consigue, hay más problemas que IPv8 deberá sortear si quiere imponerse como el nuevo estándar:

• WHOIS8 se vuelve una parte crítica de las comunicaciones. Sin WHOIS8, los routers no pueden validar las rutas BGP8, y si WHOIS8 cae en el Internet de IPv8, Internet cae con él.
• Los Zone Servers asumen demasiada carga: DHCP, DNS, NTP, autenticación, validación de rutas, control de acceso y traducción IPv4/IPv8. El área de impacto se multiplica, y un operador que pierda el Zone Server perdería la red.
• El mínimo /16 rompe el multihoming actual: el multihoming es la práctica de conectar una misma red a varios proveedores a la vez para ganar redundancia. Hoy, miles de empresas lo hacen anunciando su propio bloque /24 desde dos ISP distintos. IPv8 lo prohíbe: solo se pueden anunciar bloques /16 o mayores. Quien no tenga un /16 queda fuera del peering directo y pasa a depender de su proveedor upstream (el operador de nivel superior que le da salida al resto de Internet). Para los operadores pequeños es un retroceso: pierden el control sobre su propio enrutamiento.
• Fragmenta el esfuerzo invertido en IPv6: Los operadores que sí han migrado a IPv6 han invertido muchos recursos. IPv8 propone una transición paralela, esta bifurcación podría dividir los esfuerzos y retrasar aún más una migración completa.
• IPv8 empieza de cero: IPv6, pese a sus defectos, es un proyecto maduro, con múltiples revisiones y mucha parte del trabajo hecho, IPv8 significaría reiniciar todo ese progreso y empezar a pensar en un nuevo protocolo.
• Es solo un borrador: De momento, IPv8 es tan sólo una proposición individual, no tiene ningún grupo de trabajo de la IETF detrás. Esto significa que no hay consenso, revisiones concienzudas ni apoyo institucional. Mientras esto no llegue, los operadores no confiarán en la propuesta.

¿Qué viene ahora?

Por el momento, los interesados en IPv8 podrían:

1. Leer el borrador y las especificaciones de las que depende
2. Aportar revisiones técnicas al autor: jamie@one.bm
3. Participar en la IETF: Intentar aportar «presión» para empujar el protocolo hacia delante.

En definitiva

De momento, es difícil hacer poco más que especular sobre este tema. El proyecto es joven, inmaduro y falto de consenso. La propuesta es interesante y podría llegar a ser revolucionaria, pero le falta mucho tiempo y trabajo para llegar a ser adoptado como estándar.