La escasez de direcciones IPv4 ha impulsado la adopción de IPv6. IPv4, con sus aproximadamente 4.300 millones de direcciones posibles (32 bits), ya no cubre las necesidades de los dispositivos modernos. En cambio, IPv6 ofrece 128 bits (~340 sextillones de direcciones), garantizando una capacidad prácticamente ilimitada.

Durante las últimas décadas se desarrollaron diversos métodos de transición, siendo el más extendido “Dual Stack”, donde cada dispositivo opera simultáneamente con IPv4 e IPv6. Además de “Dual Stack”, surgió 6to4, 6rd, ISATAP, Teredo, NAT-PT, NAPT-PT. Muchos de estos métodos están obsoletos; por ejemplo, NAT-PT fue declarado en desuso oficialmente en la RFC 4966, y 6to4 dependen de prefijos especiales hoy considerados históricos (RFC 7526).

A pesar de las herramientas disponibles, muchas organizaciones aún no completan la transición a IPv6 debido a la complejidad operativa que implica mantener redes Dual Stack. Este modelo exige una gestión duplicada —rutas, políticas y seguridad para IPv4 e IPv6— lo que incrementa el gasto operativo. La IETF indica que las redes Dual Stack no solucionan la escasez de IPv4, ya que siguen requiriendo los mismos recursos que enredes Ipv4 only. En la práctica, su adopción prolongada actúa como una “muleta” que oculta fallos: cuando IPv6 presenta errores, las conexiones suelen revertir a IPv4 sin que se detecte el problema. Además, operar miles de dispositivos en doble pila (por ejemplo, 5.000 estaciones con IPv4+IPv6) representa un coste significativo tanto en direcciones IPv4 como en administración.

Métodos de transición obsoletos

Hoy las organizaciones ya casi no usan técnicas antiguas de transición. Entre las obsoletas se incluyen mecanismos automáticos de túneles como 6to4 (red 2002::/16, hoy en estado histórico RFC 7526), 6rd (IPv6 rápido sobre IPv4), Teredo (túnel UDP para saltar NAT) o ISATAP (IPv6 sobre IPv4 en LANs). Estos enfoques se diseñaron como solución provisional, pero han quedado relegados por su complejidad y problemas de seguridad. Tampoco se recomienda usar NAT-PT o NAPT-PT (traducciones IPv6↔IPv4 tradicionales), los cuales fueron descontinuados.

¿Por qué Dual Stack no fue definitivo?

El enfoque Dual Stack —donde los hosts operan con IPv4 e IPv6 simultáneamente— sigue siendo común como solución temporal. Permite probar IPv6 sin riesgo, ya que ante fallos el tráfico vuelve a IPv4. Sin embargo, no resuelve la escasez de direcciones: cada equipo dual-stack sigue usando una IPv4 y depende de rutas y servicios IPv4 (DNS, DHCPv4), manteniendo la presión sobre la infraestructura heredada. Además, dividir redes o SSIDs por protocolo solo añade complejidad; por ejemplo, en entornos inalámbricos separar una SSID IPv6-only y otra dual-stack puede saturar los canales. En definitiva, Dual Stack facilita la transición, pero incrementa los costes operativos y la complejidad a largo plazo.

Las Redes IPv6 son un nuevo enfoque

Para superar estos retos ha surgido el concepto de Redes IPv6-Mostly (o “mayoritariamente IPv6”). Según el RFC 8925 (sección 1.2), una IPv6-mostly network es aquella que provee servicio NAT64 (y opcionalmente DNS64) junto con conectividad IPv4, permitiendo que coexistan en el mismo segmento hosts IPv6-only, IPv4-only y dual-stack. En otras palabras, la red entrega IPv4 “bajo demanda”: los dispositivos que pueden vivir sin IPv4 operan solo con IPv6, mientras que aquellos que lo requieran siguen recibiendo IPv4. Esta idea fue motivada por grandes redes (Google, conferencias, etc.) donde se agotaron incluso direcciones privadas (RFC 1918) en esquemas Dual Stack. La comunidad técnica destaca, lo ideal es ser “IPv6-only donde se pueda, dual-stack donde sea necesario”.

El mecanismo central de IPv6-Mostly es el uso de la Opción 108 de DHCPv4 definida en RFC 8925. Mediante esta opción, un cliente DHCPv4 indica que prefiere operar en modo IPv6-only. Si el servidor DHCP soporta la opción 108, reconoce que ese equipo no necesita IPv4 y simplemente no le asigna ninguna dirección IPv4. El cliente hace el proceso normal DORA de DHCP, pero en cuanto el servidor devuelve la opción 108 (IPv6-only preferred), el cliente no realiza el paso de solicitud de IPv4 y, por ende, nunca recibe un ACK de dirección IPv4. En palabras sencillas: “el cliente le dice al servidor DHCPv4 (usando la opción 108): ‘puedo trabajar sin IPv4’. El servidor entonces corta el proceso y deja libre la dirección IPv4.” De este modo, cada dispositivo IPv6-only libera una IP v4 para otros.

¿Cómo funciona la red IPv6-Mostly en la práctica?

Al conectarse a una red IPv6-Mostly, cada equipo configura su stack según sus capacidades. Los dispositivos solo IPv4 se comportan igual que siempre: obtienen una dirección IPv4 vía DHCPv4. Los dual-stack (que no soportan operar IPv6-only) obtienen dirección IPv6 (por SLAAC o DHCPv6) y además reciben IPv4 por DHCPv4. En cambio, los equipos IPv6-capaces (los modernos smartphones, PCs recientes, etc.) incluyen la opción 108 en su petición DHCPv4 y solo quedan configurados con direcciones IPv6.

Para que estos clientes IPv6-only puedan comunicarse con servidores IPv4, la red provee un NAT64 (y opcionalmente DNS64). NAT64 traduce IPv6↔IPv4 (definido en RFC 6146) que permite a los hosts IPv6-only alcanzar recursos IPv4. Por ejemplo, al intentar hacer ping a un IPv4 puro como 8.8.8.8, el tráfico se encapsula hacia el NAT64 que le asigna una dirección IPv4 privada oculta (via 464XLAT) y luego convierte todo al IPv4 real. Gracias a esto, las aplicaciones IPv4 tradicionales funcionan transparente a los usuarios. En una red IPv6-Mostly conviven tranquilamente equipos sin IPv4 y otros que sí lo usan, utilizando NAT64/DNS64/464XLAT para interoperar.

RFC8925 para apagar IPv4 + Host IPv6 comunicándose con un servicio IPv4 nativo

Ventajas de la red IPv6-Mostly

El enfoque IPv6-Mostly aporta varias mejoras operativas. Primero, reduce drásticamente el consumo de direcciones IPv4. Al asignar IPv4 solo a los equipos que realmente lo necesitan, las subredes IPv4 pueden ser mucho menores. Según la IETF en escenarios reales (ej. Wi-Fi de conferencias) un 60–70% de los dispositivos han operado en IPv6-only; lo cual permitiría tener subredes IPv4 más pequeñas y liberando así espacio IPv4 y los recursos de su infraestructura.

Además, la operación de la red se simplifica y se hace más escalable. No es necesario mantener VLANs, SSIDs o puentes duplicados para separar IPv4 e IPv6, ambos grupos de hosts pueden convivir en el mismo segmento. El documento 6mops de IETF explica que esto evita duplicar SSIDs inalámbricos (lo cual congestiona el espectro) y elimina la necesidad de crear subredes VLANs distintas por tipo de dispositivo. Administrar un único entorno unificado es más sencillo: no hay que enrutar tráfico IPv4 entre segmentos específicos ni educar al usuario final para que elija la red “correcta”.

Otro beneficio es la transición controlada. Al usar Option 108, los administradores de red pueden migrar dispositivos a IPv6-only de forma progresiva. Por ejemplo, se puede empezar con redes pequeñas o dispositivos que ya soportan IPv6 en su totalidad, dejando el resto en dual-stack. Con este despliegue incremental se “frena” de forma gradual el uso de IPv4 donde ya no es estrictamente necesario.

Finalmente, mejora el diagnóstico de problemas IPv6. En redes solo-dual stack, cuando un servicio falla sobre IPv6, el tráfico suele caer en IPv4 sin que los usuarios lo noten, retrasando la detección de fallos en IPv6. En un escenario IPv6-Mostly, los clientes IPv6-only deben usar IPv6 y enfrentan cualquier incompatibilidad de inmediato, lo que hace más visible cualquier fallo en la nueva pila.

En síntesis, el modelo IPv6-Mostly permite tener un pie en cada mundo pero operando “a la carta”. Los equipos capaces disfrutan de todos los beneficios de IPv6 sin carga IPv4, mientras que los servicios o dispositivos que aún dependen de IPv4 siguen funcionando mediante NAT64/DNS64. El resultado es una red más ligera y menos costosa de mantener.

Conclusión

En lugar de insistir en mantener dobles configuraciones por dispositivo, las redes IPv6-Mostly proponen usar lo mejor de ambos mundos. Aprovechan la abundante capacidad de IPv6 para la mayoría del tráfico, y solo “sacan” IPv4 cuando es estrictamente necesario. Así se aligera la infraestructura, se retrasa la escasez de IPv4 y se facilita la transición global a IPv6. Con opciones estándar como la Opción 108 de DHCPv4 (RFC 8925) y servicios de NAT64/DNS64, las empresas pueden adoptar IPv6 de forma incremental y más asequible. En definitiva, las IPv6-Mostly networks demuestran que avanzar hacia IPv6 no tiene por qué ser tan costoso ni complejo: basta con usar las herramientas adecuadas para que la red “prefiera” IPv6 donde pueda, simplificando la gestión y dando más espacio para el futuro.

Referencias

– Experimental IPv6-only network at APRICOT 2024 | Network Startup Resource Center

https://nsrc.org/blog/apricot-ipv6-only

– book6: A Collaborative IPv6 Book

https://ipv6textbook.com/files/ipv6textbook.pdf

– IPv6 Mostly Network

https://blog.lacnic.net/redes-ipv6-mostly/

– IPv6-Only Preferred Option for DHCPv4

https://datatracker.ietf.org/doc/html/rfc8925

– IPv6 transition mechanism – Wikipedia

https://en.wikipedia.org/wiki/IPv6_transition_mechanism

– IPv6-Mostly Networks: Deployment and Operations Considerations

https://www.ietf.org/archive/id/draft-ietf-v6ops-6mops-00.html

– draft-ietf-v6ops-6mops-02

https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-6mops-02