IPv8

01 El problema que llevamos ignorando 15 años

El 3 de febrero de 2011 IANA entregó los últimos bloques /8 libres de IPv4. Desde entonces no ha habido más espacio central que repartir. Los cinco registros regionales agotaron sus reservas entre 2011 y 2020 uno tras otro. Hoy todas las direcciones IPv4 útiles del mundo están en manos de alguien — y la única forma de conseguir más es comprárselas a ese alguien.

Durante estos años el parche ha sido CGNAT: compartir una IPv4 pública entre decenas o cientos de abonados mediante traducción masiva de puertos. Funciona, pero rompe peer-to-peer, complica la geolocalización, dispara la latencia de sesión y convierte la atribución forense en un deporte de alta precisión. Los ISPs lo saben y los usuarios lo sufren sin saberlo.

Y mientras tanto el mercado de direcciones se ha convertido en un sector con operadores, brokers y cotizaciones trimestrales. Una IPv4 suelta cuesta hoy entre $32–$45 según IPv4.Global. Un /24 supera los $10.000. No es una distorsión: es el equilibrio de un recurso escaso tratado como propiedad negociable.

02 Por qué IPv6 no terminó de llegar

IPv6 existe desde 1998. Lleva veintiocho años escribiéndose, estandarizándose, desplegándose. Y en 2026 apenas transporta el 45,2% del tráfico mundial según las estadísticas de Google. La mitad más uno de internet sigue siendo IPv4. El fracaso no es de ingeniería — IPv6 es un protocolo sólido — sino de incentivos.

El modelo de transición de IPv6 exige doble pila: cada dispositivo, cada aplicación, cada router tiene que hablar ambos protocolos simultáneamente durante el tiempo que dure la migración. Y ese tiempo, sin un forzante real, es indefinido. Cada operador asume el coste operativo del doble mantenimiento sin obtener un beneficio inmediato si sus pares no han migrado también. Sin externalidad forzante, el equilibrio racional es quedarse en IPv4 con CGNAT.

IPv6 rompe compatibilidad a nivel de paquete. Un router que solo entiende IPv4 no puede reenviar un paquete IPv6 — ni siquiera sabe qué longitud tiene la cabecera. Cada salto del camino debe actualizarse antes de que la ruta funcione. Eso multiplica el coste de coordinación por el número de operadores involucrados, que es un número grande.

Tras 25 años de esfuerzo de despliegue IPv6 transporta una minoría del tráfico global de internet. El coste operativo del modelo de transición doble pila, combinado con la ausencia de mejoras en la gestión, resultó comercialmente inaceptable.

03 Qué propone IPv8

IPv8 cambia la regla del juego: IPv4 es un subconjunto estricto de IPv8. Una dirección IPv8 es de 64 bits y se escribe r.r.r.r.n.n.n.n. El tramo n.n.n.n son los 32 bits IPv4 de siempre con idéntica semántica. El tramo r.r.r.r codifica el ASN — el número del sistema autónomo al que pertenece la IP.

Cuando r.r.r.r = 0.0.0.0, la dirección IPv8 es una dirección IPv4 clásica, procesada por las reglas IPv4 de siempre. Ningún router, ningún firmware, ninguna aplicación IPv4 existente necesita modificación. No hay flag day. No hay migración forzada.

Cada titular de un ASN recibe 4.294.967.296 direcciones — tantas como tiene IPv4 entero. Un ISP consumer, un hyperscaler, un laboratorio universitario: todos con espacio de sobra para décadas, sin CGNAT, sin renumeración. El espacio total pasa de 232 a 264 direcciones, es decir, ~18 trillones. El agotamiento deja de ser un problema arquitectónico.

La tabla BGP global también cambia. En IPv8 la regla es que el prefijo mínimo anunciable entre sistemas autónomos es /16. Se acabaron los /24, /22, /20 que hoy inflan la tabla BGP4 hasta los 970.000 prefijos. La tabla BGP8 queda acotada por el número de ASNs activos, no por la proliferación de prefijos. Hoy hay ~122.000 ASNs: ese es tu límite superior. Finito. Manejable.

04 Cómo se despliega IPv8 sin romper nada

La pieza clave del modelo de transición se llama selección de versión guiada por ARP8. Cuando un host IPv8 quiere hablarle a un vecino, hace dos sondeos en paralelo: ARP8 a t=0 y ARP4 a t=50ms. Lo que responda decide cómo se construye el paquete en adelante.

• Si el vecino respondió ARP8 → se transmite un paquete IPv8 completo de 64 bits.
• Si respondió ARP4 → se transmite un paquete IPv4 estándar, sin el prefijo r.r.r.r en el cable.

Consecuencia: un dispositivo IPv4-only jamás recibe un paquete con versión 8 en la cabecera IP. No puede descartarlo porque el emisor IPv8 nunca construye uno en la versión que el vecino no entiende. El caso de error clásico de transición — "router no reconoce la versión del paquete, drop" — deja de existir por construcción.

Para atravesar núcleos solo-IPv4 existe 8to4 anycast: cada ASN publica en su registro WHOIS8 una dirección IPv4 anycast que sus routers de borde anuncian por BGP4 normal. Un paquete IPv8 que necesita cruzar un tránsito IPv4 se encapsula en un IPv4 hacia esa anycast, el núcleo IPv4 lo reenvía creyendo que es tráfico normal, y el router de borde del destino lo decapsula. Cero túneles preconfigurados. Cero coordinación entre operadores.

La factura de migración de un router IPv8 cabe en cuatro líneas de configuración. Eso es lo que convierte el despliegue en posible.

05 Qué podría ir mal con IPv8

IPv8 es una propuesta, no un decreto. Merece la misma lectura crítica que cualquier otra. Estos son los puntos débiles reales del diseño — no para enterrarlo, sino para saber contra qué se está evaluando.

WHOIS8 como infraestructura crítica

Toda la validación de tráfico norte-sur depende de WHOIS8. Sin WHOIS8, los routers no pueden validar rutas BGP8 ni los Zone Servers pueden aplicar control de egreso. El draft lo llama explícitamente "critical infrastructure service". Lo que en otros protocolos es una capa de seguridad opcional aquí es un prerequisito. Si WHOIS8 cae, no degrada — se rompe. Y WHOIS histórico nunca ha sido una infraestructura especialmente robusta.

El Zone Server concentra demasiado

DHCP, DNS, NTP, autenticación, validación de rutas, control de acceso, traducción IPv4/IPv8 — todo corre en la misma plataforma. Es elegante en papel, pero multiplica el blast radius de cualquier compromiso. Un operador que pierde el Zone Server no pierde un servicio: pierde la red. La redundancia par/impar ayuda a disponibilidad, no a segregación de confianza.

OAuth2 JWT universal es pesado en operación

Autenticar "cada elemento gestionable" vía JWT exige gestión de claves, rotación, revocación, caché coherente y recuperación ante desastres. Una red ISP grande tiene millones de elementos. El ecosistema operativo para esto no existe a esa escala — ni PKI, ni herramientas, ni skills. El draft no dice cómo se bootstrappea el primer token en un dispositivo virgen.

El /16 mínimo rompe multihoming actual

Hoy miles de empresas multihoman anunciando su propio /24 desde dos ISPs. En IPv8 eso se prohíbe — solo se puede anunciar /16 o mayor. Quien no tiene un /16 queda fuera del peering directo y depende de su upstream. Para pequeños operadores es una regresión: pierden control sobre su routing.

Fragmenta el esfuerzo de IPv6

Los pocos operadores que sí migraron a IPv6 llevan ~25 años invirtiendo en ese ecosistema. IPv8 propone una tercera transición paralela. Si el mercado se divide entre IPv6 e IPv8, ninguna adopción gana masa crítica. IPv6 al menos tiene RFCs publicadas, implementaciones maduras, y presencia en hardware desplegado. IPv8 empieza desde cero.

Es un draft individual, no de grupo de trabajo

El draft-thain-ipv8-02 está presentado a título individual, sin un WG del IETF detrás. Eso significa: sin consenso comunitario, sin peer review estructurado, sin compromiso de los principales operadores. La mayoría de los drafts individuales caducan sin convertirse en RFC. Es una propuesta interesante; todavía no es un estándar en camino.

Ninguna de estas objeciones es fatal. Todas son tratables. Pero son las que un operador con experiencia va a poner sobre la mesa antes de planificar nada. Ignorarlas es la mejor forma de que el draft no avance.

06 Qué hacer ahora

IPv8 es un Internet-Draft individual del IETF, no una RFC. Para avanzar necesita revisión, implementaciones experimentales y — lo más difícil — adopción operativa. Si operas un AS, te dedicas a investigación de redes, trabajas en un fabricante de equipamiento o simplemente te importa cómo evoluciona el sustrato de todo esto, estos son los siguientes pasos razonables:

1. Lee el borrador. En español o en el datatracker del IETF en inglés. Son ~70 páginas en total, densas pero legibles.
2. Revisa las especificaciones complementarias. Zone Server, WHOIS8, Update8, RINE, Routing Protocols — cada una tiene su propio draft individual.
3. Escribe al autor con comentarios técnicos: jamie@one.bm.
4. Participa en el IETF. La Internet Area Working Group es donde este draft buscará tracción.