Hoy hablaremos sobre el Internet Draft llamado: “Hosts de doble pila casi exclusivos de IPv6” (Nearly IPv6 Only Dual Stack Hosts)
Introducción
Este documento técnico propone un método para gestionar dispositivos de doble pila (dual stack) que ya no requieren conectividad IPv4 pero que continúan generando tráfico de red al solicitar direcciones automáticamente (como cliente DHCPv4).
La estrategia consiste en asignarles una máscara de subred 255.255.255.255 mediante DHCPv4, lo que efectivamente aísla al equipo y le impide comunicarse con destinos externos bajo ese protocolo. Al omitir la configuración de una puerta de enlace o router, el tráfico se fuerza hacia el protocolo IPv6, eliminando la necesidad de soporte para opciones de red más modernas y complejas. Esta técnica reduce el ruido en la red local y permite reutilizar rangos de direcciones privadas sin afectar el enrutamiento global. Además, el autor sugiere implementar periodos de concesión de direcciones más prolongados para minimizar la carga sobre los servidores. En definitiva, se presenta una solución práctica para la transición a redes únicamente IPv6 utilizando mecanismos tradicionales de infraestructura.
(Acceso libre, no requiere suscripción)
El problema que se busca solucionar
El borrador soluciona el problema de cómo silenciar las ruidosas solicitudes DHCPv4 de los dispositivos antiguos y retirarles de manera efectiva el acceso a IPv4 (obligándolos a usar IPv6), utilizando los mecanismos tradicionales de DHCPv4 que esos mismos dispositivos antiguos ya entienden, sin necesidad de actualizar su software
Específicamente, el documento aborda las siguientes problemáticas encadenadas:
Tráfico basura en la red local (Broadcasts infinitos): Cuando una red dual stack quiere avanzar hacia un entorno puramente IPv6, el paso lógico sería dejar de entregar direcciones IPv4 a los dispositivos. Sin embargo, si simplemente se deshabilita la asignación de IPv4, los sistemas operativos de los hosts continuarán enviando peticiones DHCPv4 de manera periódica -e insatisfactoria- . Recordemos que este tráfico DHCPv4 es generalmente broadcast.
Incompatibilidad de los dispositivos antiguos con soluciones modernas: Ya muchos conocen las redes IPv6 Mostly donde la Opción 108 de DHCPv4 (IPv6-Only Preferred) es la clave. ¿Qué tiene de malo?, esta opción permite que un “dispositivo moderno” le avise al servidor que prefiere no recibir una IPv4 si hay IPv6 disponible. En otras palabras, el problema es que los dispositivos antiguos no entenderán esta opción DHCPv4 y se quedarán enviando broadcast todo el infinitamente.
El “dilema” de la asignación de IPv4: Los administradores de red se ven obligados a seguir ofreciendo direccionamiento IPv4, mantenimiento una red IPv6, servidores DHCPv4 solo para mantener callados a otros clientes antiguos.
Solución propuesta
La solución en mi humilde opinión es muy creativa.
El problema que se busca solucionar
El borrador soluciona el problema de cómo silenciar las ruidosas solicitudes DHCPv4 de los dispositivos antiguos y retirarles de manera efectiva el acceso a IPv4 (obligándolos a usar IPv6), utilizando los mecanismos tradicionales de DHCPv4 que esos mismos dispositivos antiguos ya entienden, sin necesidad de actualizar su software
Específicamente, el documento aborda las siguientes problemáticas encadenadas:
Tráfico basura en la red local (Broadcasts infinitos): Cuando una red dual stack quiere avanzar hacia un entorno puramente IPv6, el paso lógico sería dejar de entregar direcciones IPv4 a los dispositivos. Sin embargo, si simplemente se deshabilita la asignación de IPv4, los sistemas operativos de los hosts continuarán enviando peticiones DHCPv4 de manera periódica -e insatisfactoria- . Recordemos que este tráfico DHCPv4 es generalmente broadcast.
Incompatibilidad de los dispositivos antiguos con soluciones modernas: Ya muchos conocen las redes IPv6 Mostly donde la Opción 108 de DHCPv4 (IPv6-Only Preferred) es la clave. ¿Qué tiene de malo?, esta opción permite que un “dispositivo moderno” le avise al servidor que prefiere no recibir una IPv4 si hay IPv6 disponible. En otras palabras, el problema es que los dispositivos antiguos no entenderán esta opción DHCPv4 y se quedarán enviando broadcast todo el infinitamente.
El “dilema” de la asignación de IPv4: Los administradores de red se ven obligados a seguir ofreciendo direccionamiento IPv4, mantenimiento una red IPv6, servidores DHCPv4 solo para mantener callados a otros clientes antiguos.
Solución propuesta
La solución en mi humilde opinión es muy creativa.
Se busca de alguna manera complacer al host/cliente. El cliente quiere una dirección IPv4 y que la dé el DHCP server. ¿Qué hace el DHCP server?, ok, te daré una. Lo que el cliente “matematicamente no sabe” es que realmente ese IP casi no sirve para nada.
No voy a entrar en todas las ideas mencionadas en el draft, pero si en las dos más interesantes:
La solución propuesta en el borrador (Internet-Draft) para lograr que los hosts de doble pila (dual-stack) operen de manera casi exclusiva en IPv6 consiste en un método sutil pero altamente efectivo basado en la configuración de DHCPv4 tradicional:
Configurar una máscara de subred /32 (255.255.255.255): A través de la opción 1 de DHCPv4 (Subnet Mask), se le asigna al cliente una máscara de subred de host único. Al recibir esta máscara, el dispositivo concluye que no hay ninguna otra dirección IPv4 en su propio enlace físico; es decir, todo el tráfico IPv4 hacia el exterior es considerado automáticamente como fuera de su enlace o off-link.
Omitir la entrega de routers (puertas de enlace): El servidor DHCPv4 no proporciona ninguna dirección de router al cliente (se elimina deliberadamente la Opción de Router, opción valor 3).
De esta manera, el host antiguo satisface su necesidad de obtener una dirección IPv4 (silenciando las molestas peticiones de broadcast repetitivas), pero queda aislado de la red IPv4 y se ve forzado a comunicarse únicamente a través de IPv6 (adicionalmente debemos sumar el tráfico broadcast de ARP).
¿Cómo con lo anterior aísla un host en el mundo IPv4?
El efecto de la máscara /32: Al configurarse la interfaz del host con una máscara 255.255.255.255, el sistema operativo calcula que no existe ninguna otra dirección IPv4 en su propio enlace. Por ello, para el host, absolutamente cualquier dirección IPv4 externa es considerada fuera de su alcance.
Búsqueda de un enrutador inexistente: Al asumir que todos los destinos IPv4 están en redes externas, el host intentará enviar cualquier paquete IPv4 a través de su puerta de enlace o router predeterminado. Sin embargo, el método del draft consiste en no proporcionar ningún router a través de DHCPv4
Hasta este momento, el host satisface su necesidad de obtener una IP por DHCPv4 y adicionalmente no genera tráfico de broadcast repetitivo en la red
¿Qué ventajas ofrece este método frente a redes IPv6 Mostly?
La principal ventaja de este método (proporcionar una máscara de subred 255.255.255.255 y no entregar default gateway/puerta de enlace predeterminada) frente a la opción 108 (IPv6-Only Preferred) es la compatibilidad con dispositivos y servidores legados (antiguos).
No requiere soporte de protocolos recientes: La opción 108 es un mecanismo de DHCPv4 relativamente nuevo, lo que exige que tanto el sistema operativo del host (cliente) como el servidor DHCPv4 lo soporten explícitamente. El método de la máscara /32 (255.255.255.255) funciona utilizando mecanismos tradicionales de DHCPv4, lo que lo hace compatible con sistemas legados que no admiten la opción 108.
Evita el tráfico de broadcast innecesario: Si simplemente se dejara de proporcionar direccionamiento IPv4 a un host antiguo que no soporta la opción 108, este seguiría enviando solicitudes DHCPv4 de forma periódica e insatisfecha, inundando el enlace local con tráfico de broadcast innecesario. Este método satisface su solicitud DHCPv4 entregándole una IP, pero restringe su conectividad.
Ahorro y flexibilidad de direccionamiento IPv4: Dado que los hosts configurados con una máscara 255.255.255.255 no intentarán alcanzar destinos IPv4 fuera de sí mismos, las direcciones asignadas no necesitan ser enrutables en la red interna ni en Internet. Esto permite utilizar rangos no enrutables como el direccionamiento de enlace local (169.254.0.0/16) o bloques privados RFC1918, e incluso reutilizar el mismo pool de direcciones IP en distintos enlaces físicos si el servidor DHCPv4 está directamente conectado a ellos.
IPv6 Mostly y Nearly IPv6 Only Dual Stack hosts no son mutuamente excluyentes
Cabe destacar que ambos enfoques no son mutuamente excluyentes y pueden coexistir: una red desplegada con la opción 108 para que los hosts modernos y no consuman direcciones IPv4 de los pools de DHCPv4, al mismo tiempo que aplica el método de la máscara 255.255.255.255 (sin default gateway) para silenciar la conectividad IPv4 de los hosts legados.
¿Por qué expiró el draft?
El documento que estamos viendo en cuestión expiró el 15 de junio de 2026.
Sin entrar en detalles en la parte política de IETF se puede resumir que los borradores de Internet son documentos de trabajo temporales y tienen una validez máxima de seis meses, en ese tiempo alguno de los autores debe retomar el documento para evitar que sean descartados.
Dado que esa fecha ya ha pasado, el borrador ha expirado de manera automática al no haber sido reemplazado por una nueva revisión activa, A pesar de tener una validez máxima de seis meses, los I-D, pueden ser actualizados o reemplazados por otros documentos en cualquier momento. Para reactivarlo, el autor o los colaboradores simplemente tendrían que publicar una nueva revisión.
¿Qué sistemas operativos se llegaron a probar?
El autor ha probado con éxito este método en los siguientes sistemas operativos y dispositivos:
Windows 11.
Diversas distribuciones de Linux (o sistemas basados en este núcleo) que utilizan diferentes clientes DHCPv4:
Fedora 43.
Raspberry Pi OS (basado en Debian Trixie).
Dispositivos Chromecast.
Dispositivos Google Nest.
Por otra parte, se menciona explícitamente que no se llegaron a realizar pruebas en teléfonos inteligentes (smartphones)
Conclusiones
Esta técnica forza el uso de IPv6 al simular una conexión IPv4 funcional, eliminando el tráfico de broadcast innecesario de equipos antiguos sin requerir actualizaciones de software. El método, compatible con sistemas como Windows 11 y Linux.
Es muy importante realizar extensas pruebas en muchos sistemas operativos, en diferentes redes (Dual Stack, Single Stack v4, Single Stack v6). Probar donde existe un mejor comportamiento, por ejemplo, recibiendo una máscara 255.255.255.255 desde el DHCP o recibiendo una dirección IP sin default gw. Falta mucho para tomar decisiones
Les prometo probar esta solución muy pronto junto a la opción 108 en alguna red IPv6 Mostly.
Necesitamos más compatibilidad en diversos sistemas operativos y diferentes versiones. Tu colaboración es fundamental para ofrecer una experiencia impecable. Si deseas sumarte a este proceso, por favor contáctanos a imasd@lacnic.net
