A veces se oye la idea de que, si IPv4 fue seguido por IPv6, entonces tal vez IPv8 sea lo siguiente. En la practica, sin embargo, no existe ningun estandar formal llamado IPv8. El campo de version de IPv4 tiene 4 bits, asi que en teoria admite valores del 0 al 15. IPv5 ya fue utilizado por Internet Stream Protocol (ST) en 1979, e IPv6 fue diseñado deliberadamente como una ruptura con IPv4. Ha habido propuestas dispersas para IPv7 y versiones posteriores, pero ninguna ha sido estandarizada por la IETF.
Entonces, ¿que es lo que realmente se esta investigando y estandarizando como la proxima generacion de protocolos de Internet? ¿Y como intentan esas iniciativas resolver las limitaciones acumuladas de IPv4? Este articulo ordena el panorama actual.
IPv4 sigue aqui, pero los problemas no dejan de crecer
Empecemos por un hecho evidente: IANA agoto el espacio IPv4 sin asignar en 2011. Aun asi, en la operacion diaria IPv4 sigue sobreviviendo gracias a NAT, CGNAT, CDN, proxies y al mercado de transferencia de direcciones.
Las tasas de adopcion de IPv6 siguen variando mucho entre paises.
Francia e India ya se mueven aproximadamente entre el 70 y el 90 por ciento, mientras que Japon y Corea del Sur siguen por debajo del 50 por ciento. La lentitud de IPv6 no se explica porque el estandar sea defectuoso, sino porque NAT todavia permite seguir funcionando, y eso hace que la migracion rara vez llegue a ser una prioridad alta.
La velocidad de banda ancha fija tambien cambia mucho segun el pais.
La diferencia sigue estando marcada sobre todo por la inversion en infraestructura, pero las capas adicionales de NAT y proxy tambien suman latencia. Cuantos mas remiendos se añaden para alargar la vida de IPv4, mas se pierde la simplicidad del camino de red.
Por que IPv6 eligio una ruptura limpia, y cuanto costo eso
IPv6 renuncio a la compatibilidad hacia atras con IPv4 de forma intencional. El objetivo no era solo ampliar el espacio de direcciones de 32 a 128 bits, sino tambien rediseñar el encabezado y volver a un modelo extremo a extremo que no asumiera NAT.
El problema es que esa ruptura limpia tambien encarecio la migracion. El largo periodo de dual stack obligo a duplicar la gestion de monitorizacion, firewalls, analisis de logs y listas de permitidos. Los costos crecieron, pero el beneficio visible para el usuario final siguio siendo limitado, por lo que muchas organizaciones concluyeron que no habia una razon suficientemente fuerte para moverse de inmediato.
Esa experiencia termino abriendo otra pregunta: ¿era posible extender la red sin romper la compatibilidad con IPv4? De esa linea de pensamiento nacen SRv6 y varias tecnologias de transicion.
SRv6: extender IPv6 sin dejar de transportar IPv4
SRv6 (Segment Routing over IPv6) utiliza cabeceras de extension de IPv6 para hacer explicitas las rutas de los paquetes. Fue estandarizado en RFC 8986.
Lo importante aqui es que los paquetes IPv4 pueden encapsularse dentro de SRv6. Dicho de otro modo, el trafico IPv4 puede moverse sobre un modelo de control de rutas basado en IPv6. Es una de las aproximaciones mas cercanas que tenemos hoy a una via de evolucion compatible con IPv4 construida sobre IPv6.
SRv6 resulta atractivo porque puede abordar varios problemas operativos al mismo tiempo.
- Control de rutas sin etiquetas MPLS, reduciendo la complejidad del stack de etiquetas
- Ingenieria de trafico mas fina para cada ruta
- Control de rutas mas coherente entre la nube y las redes de operador
- Un solo plano de reenvio para entornos mixtos de IPv4 e IPv6
NTT, China Telecom y Alibaba ya avanzan hacia despliegues comerciales, especialmente entre grandes centros de datos y en nucleos de red 5G.
SCION: rediseñar la propia ruta
A diferencia de SRv6, que es una extension de IPv6, SCION (Scalability, Control, and Isolation On Next-generation networks) apunta a un rediseño mas fundamental. Fue impulsado por ETH Zurich y presentado en IEEE Security & Privacy 2011.
La idea central de SCION es devolver la seleccion de rutas al emisor. En Internet actual, las rutas se determinan mediante BGP (Border Gateway Protocol), y los emisores no pueden elegir por donde circularan sus paquetes. En SCION, el emisor puede especificar explicitamente la ruta.
Eso permite varias cosas.
- Dificulta cambios arbitrarios de ruta por parte de ISP o Estados, ayudando contra el secuestro de rutas
- Permite elegir rutas segun latencia, ancho de banda o fiabilidad
- Facilita aislar fallos en sistemas autonomos concretos
- La autenticacion esta integrada en la arquitectura, lo que dificulta la suplantacion
SCION ya esta en uso productivo dentro de la Swiss Secure Finance Network (SSFN). Tambien puede funcionar como overlay sobre IPv4 e IPv6, por lo que puede coexistir con la infraestructura existente.
NDN: enrutar por nombre de contenido en lugar de direccion IP
NDN (Named Data Networking) enruta paquetes por nombre de contenido en lugar de direccion. Ha sido investigado dentro del proyecto Future Internet Architecture apoyado por la NSF.
La Internet actual esta diseñada en torno a “a que host enviar”. NDN cambia el eje hacia “que contenido quiero obtener”. El contenido recibe un nombre, y el enrutamiento se realiza usando ese nombre.
Eso puede resolver varias cosas.
- La propia red puede cachear contenido identico, logrando algo parecido a un CDN a nivel de infraestructura
- La integridad del contenido puede comprobarse mas facilmente al vincularla al nombre del contenido
- Al no depender de la direccion IP del emisor, el handover en entornos moviles se vuelve mas natural
Sin embargo, su compatibilidad con la infraestructura IP existente es baja, por lo que su adopcion generalizada sigue siendo incierta. Su uso parcial avanza sobre todo en IoT y edge computing.
QUIC/HTTP3: absorber las diferencias entre versiones IP en una capa superior
Existe otra direccion posible: en lugar de cambiar la arquitectura de red, absorber las diferencias entre IPv4 e IPv6 en una capa superior. QUIC (RFC 9000) es el ejemplo mas representativo.
QUIC funciona sobre UDP y no utiliza directamente la combinacion de direccion IP y puerto como identificador de la conexion. En su lugar utiliza un ID de conexion. Gracias a ello, la conexion puede mantenerse incluso cuando cambia la direccion IP.
Como resultado, la capa superior puede ofrecer la misma calidad de comunicacion tanto sobre IPv4 como sobre IPv6. HTTP/3 funciona sobre QUIC, y hoy casi todos los navegadores y servidores principales ya lo soportan.
Hasta donde ha avanzado realmente la idea de un “IPv4 compatible hacia arriba”
El enfoque mas practico que hoy se acerca a un “IPv4 compatible hacia arriba” es la combinacion de SRv6 con tecnologias de transicion como MAP-T.
MAP-T (Mapping of Address and Port using Translation, RFC 7599) transporta paquetes IPv4 a traves de una red IPv6 y los devuelve a IPv4 en el borde. Los endpoints siguen siendo IPv4, mientras que el backbone puede migrar a IPv6.
Combinando ambos, es posible construir una arquitectura en la que:
- Los usuarios finales siguen utilizando IPv4
- La red troncal se diseña alrededor de IPv6
- El control de rutas se unifica con SRv6
Eso ya funciona a un nivel practico. Un nuevo numero de version llamado “IPv8” no es estrictamente necesario para aproximarse a ese objetivo.
Lo que ya esta ocurriendo en la practica
Tambien conviene ordenar lo que ya esta funcionando en el mundo real, no solo en papers o documentos de estandarizacion.
- 5G SA (Standalone): el nucleo de red se diseña sobre IPv6, como ya esta integrado en los estandares de 3GPP
- Despliegues comerciales de SRv6: China Telecom, NTT y SoftBank lo estan introduciendo en entornos de backbone
- SCION en produccion: ya funciona en la red financiera suiza (SSFN)
- Revision de Apple App Store: exige que las aplicaciones funcionen en entornos solo IPv6
- Cloudflare / Google: el porcentaje de trafico IPv6 sigue aumentando, mientras las arquitecturas edge absorben cada vez mas las diferencias entre IPv4 e IPv6
La “proxima version” de IP no esta apareciendo como un unico nuevo estandar. En cambio, distintas tecnologias estan sustituyendo distintas capas con el tiempo.
Lo que hoy puede hacerse es reducir poco a poco la dependencia de las direcciones IP. Abandonar, cuando sea posible, las listas blancas basadas en IP fija. Moverse hacia autenticacion basada en certificados e identidad. Utilizar correctamente DNS. Apoyarse mas en CDN y arquitecturas edge. Asi se preparan los sistemas para el protocolo de proxima generacion que finalmente prevalezca.
Mi opinion: habria sido mejor ampliar IPv4 a ocho octetos
Quiero terminar con una opinion personal.
Al ver que IPv6 eligio una ruptura limpia y que aun asi la migracion sigue incompleta despues de casi treinta años, me cuesta no pensar que la direccion general del diseño pudo haber sido equivocada.
Mi opcion ideal habria sido ampliar IPv4 conservando su notacion, simplemente llevandolo a ocho octetos.
255.255.255.255.255.255.255.255
Es decir, ampliar el modelo actual x.x.x.x (32 bits) a x.x.x.x.x.x.x.x (64 bits).
¿Que habria cambiado con eso?
El espacio de direcciones se habria ampliado drasticamente
IPv4 de 32 bits proporciona unos 4.300 millones de direcciones. A 64 bits, el numero pasa a unos 18,4 quintillones. Incluso si los dispositivos IoT llegaran a 35.000 millones, el espacio disponible seguiria siendo enorme. Habria mucha menos necesidad de prolongar IPv4 mediante NAT.
Habria sido mas facil preservar la compatibilidad con IPv4
Si las direcciones IPv4 existentes se representaran como 0.0.0.0.x.x.x.x, los paquetes IPv4 actuales podrian funcionar como subconjunto del nuevo protocolo. Los routers podrian reenviar cualquier direccion cuyos cuatro octetos superiores fueran 0.0.0.0 como compatible con IPv4. El caotico periodo dual stack podria haber sido mucho mas corto.
Se habria mantenido una notacion legible para humanos
Una direccion IPv6 como 2001:0db8:85a3:0000:0000:8a2e:0370:7334 es incomoda de manejar en respuesta a incidentes, revision de logs y gestion de reglas de firewall. Con una notacion de ocho octetos, cualquiera familiarizado con IPv4 podria seguir leyendola de forma intuitiva.
# IPv4 actual
192.168.1.100
# Extension propuesta de 8 octetos
0.0.0.0.192.168.1.100 (espacio compatible con IPv4)
10.48.0.0.192.168.1.100 (ejemplo de un nuevo espacio global)
Tambien podria haber ofrecido ventajas operativas de seguridad frente a IPv6
La ventaja aqui no seria que un diseño tipo IPv4 de ocho octetos aportara automaticamente mejor cifrado o autenticacion. La ventaja habria sido operativa. Si la compatibilidad con IPv4 se hubiera mantenido, las reglas existentes de firewall, listas blancas IP, reglas de correlacion en SIEM y configuraciones basadas en direcciones dentro de WAF y dispositivos VPN habrian podido reutilizarse mucho mas facilmente. Tambien podria haberse acortado el periodo en el que las organizaciones debieron gestionar en paralelo conjuntos de reglas IPv4 e IPv6.
Las direcciones IPv6 son mas largas y admiten varias formas de compresion, lo que hace que la revision humana, las auditorias y el troubleshooting sean mas propensos a errores. Un modelo de ocho octetos habria permitido que los logs, las listas de permitidos y la respuesta a incidentes siguieran siendo mucho mas cercanos a la experiencia operativa de IPv4. En entornos como los sistemas empresariales japoneses, donde las listas blancas de IP fija siguen siendo comunes, eso podria haber reducido la carga operativa de seguridad frente a IPv6.
Por supuesto, hay desafios practicos
No habria sido un diseño perfecto.
- Incluso 64 bits podrian no ser suficientes para un futuro de IoT y redes de agentes de IA a gran escala, que es una de las razones por las que IPv6 eligio 128 bits
- Los routers aun habrian necesitado cambios en la logica de tratamiento de direcciones, algo pesado para el hardware de los años noventa
- Ampliar direcciones por si solo no resuelve la autenticacion ni la seguridad criptografica
Aun asi, “mantener la notacion y aumentar solo el numero de octetos” sigue pareciendo una alternativa realista si se observa el costo de migracion de IPv6 en los ultimos treinta años.
Los diseñadores de IPv6 seguramente entendian este dilema, y aun asi eligieron la ruptura limpia por sus propias razones. Pero el hecho sigue siendo que una gran parte del mundo todavia funciona sobre IPv4.
Mi opinion: el cuello de botella de NAT tambien es un problema de capa fisica
Hay otro angulo que vale la pena añadir.
NAT se convierte en cuello de botella no solo porque la traduccion de direcciones consume procesamiento. Los equipos de red actuales tambien convierten señales opticas en señales electricas antes de tratarlas. Ese procesamiento electrico introduce calor, interferencias y degradacion. El tratamiento de NAT se hace dentro de ese dominio electrico, por lo que los limites aparecen con claridad cuando el numero de sesiones crece.
La iniciativa IOWN (Innovative Optical and Wireless Network) de NTT, y su idea central de la APN (All-Photonics Network), intenta replantear toda esa estructura.
La arquitectura convencional se parece a esto.
Fibra optica -> [conversion electrica] -> router (procesamiento electrico) -> [conversion optica] -> fibra optica
APN apunta mas bien a algo asi.
Fibra optica -> router (procesamiento optico) -> fibra optica
La idea es construir caminos opticos de extremo a extremo y reenviar o controlar paquetes sin volver a convertirlos en señales electricas. IOWN tambien mira mas alla de la capa de red hacia dispositivos e incluso semiconductores. NTT ha mencionado objetivos como reducir el consumo energetico a 1/100, multiplicar por 125 la capacidad de transmision y reducir la latencia extremo a extremo a 1/200 frente a los enfoques actuales.
¿Que cambiaria si esto llegara a ser practico?
El costo de procesamiento de NAT podria caer desde la raiz
Si desaparece la conversion electrica, tambien desaparece gran parte del calor y la latencia asociados. El muro de escala de sesiones que enfrenta CGNAT podria aliviarse considerablemente. Esto sugiere que lo que muchas veces se resume como “NAT es lento” no es solo un problema de protocolo, sino tambien de capa fisica.
IPv4 podria sobrevivir aun mas tiempo
Paradojicamente, si APN se difunde, podria prolongar aun mas el escenario de “NAT todavia aguanta”. Pero al relajarse el cuello de botella de procesamiento, mas dispositivos podrian ser atendidos por menos equipos. El consumo energetico tambien caeria con fuerza, lo que cambiaria la estructura de costos operativos de la infraestructura.
El gran salto podria venir por un eje distinto al del diseño de direcciones
El debate entre IPv4 e IPv6, o entre ocho octetos y 128 bits, trata en el fondo sobre espacio de direcciones y control de rutas. IOWN/APN introduce un eje completamente distinto: velocidad fisica de transporte, consumo energetico y latencia.
El diseño de protocolos y la evolucion de la infraestructura fisica avanzan por separado. Si APN logra crear una base capaz de procesar rapidamente y con baja latencia cualquier protocolo, entonces, ya sea IPv4, IPv6 o algun nuevo esquema de direcciones, el abanico de opciones viables se ampliara.
NTT apunta a una comercializacion en la decada de 2030, y por ahora todo esto sigue en fase de investigacion y pruebas. Aun asi, la idea de procesar señales opticas sin reconvertirlas a electricidad tiene el potencial de remodelar la base fisica de Internet. Vale la pena seguirla de cerca junto con el debate sobre direccionamiento.