Resumen

  • Un cliente capaz solicita el código 108 en la lista de parámetros de DHCPv4. Solo un servidor que responda desde un pool configurado como mayoritariamente IPv6 debe devolver la opción; entonces el cliente puede rechazar la dirección ofrecida y detener DHCPv4.
  • El mínimo es 300 segundos y el valor predeterminado de RFC 8925 es 1.800. El estado termina al vencer el plazo o al producirse un nuevo evento de conexión. El temporizador ofrece una vuelta atrás; no demuestra que IPv4 haya dejado de ser necesario.

La dirección que nadie espera aceptar

El intercambio ocurre dentro de DHCPv4, pero su resultado previsto es que no haya dirección IPv4. El cliente coloca el código de “IPv6-Only Preferred” en la Parameter Request List de su DHCPDISCOVER o DHCPREQUEST. No envía los cuatro bytes del temporizador. Declara que, en esa interfaz, puede prescindir de una dirección si la red cuenta con las funciones IPv6 necesarias.

El servidor no puede interpretar silencio como permiso. Debe haber recibido la solicitud y el pool elegido debe estar configurado expresamente como IPv6-mostly. Solo entonces responde con V6ONLY_WAIT. La recomendación es ofrecer 0.0.0.0. Si el software o la infraestructura lo impiden, puede incluir una dirección real disponible, pero no debería reservarla: el cliente no está destinado a pedirla.

La peculiaridad resuelve un problema de convivencia. Un dispositivo que no conoce la opción sigue el DHCP ordinario y obtiene IPv4. Otro que sí la conoce puede quedarse únicamente con IPv6. Los dos comparten SSID, VLAN y dominio de difusión sin que un sistema central de admisión tenga que adivinar previamente la capacidad de cada aplicación.

El paquete no imparte una política universal. No etiqueta al dispositivo como avanzado ni declara obsoleto al resto. Coordina una decisión entre una interfaz que se presenta como capaz y un pool que el operador ha delimitado. Fuera de esa coincidencia, no cambia nada.

El valor operativo de una espera corta

RFC 8925 define V6ONLY_WAIT como un entero de 32 bits. Si el servidor envía un valor inferior al mínimo, el cliente usa 300 segundos. El valor predeterminado del RFC es 1.800 segundos. Durante el intervalo, el cliente debería detener la configuración DHCPv4 y puede apagar la pila IPv4 en esa interfaz.

La espera no sobrevive necesariamente al enlace. Un evento de nueva conexión la termina antes de tiempo. Esto evita que una decisión tomada en una oficina acompañe ciegamente al portátil hasta una red distinta. La capacidad es contextual: puede depender de que haya NAT64, de que el sistema tenga CLAT y de que las aplicaciones usadas en ese entorno hayan sido probadas.

El borrador 6MOPS de marzo de 2026 aconseja comenzar por los 300 segundos cuando interesa un retorno rápido. Sigue siendo un Internet-Draft, un trabajo en curso, y no debe presentarse como RFC. Su lógica se puede comprobar: si al retirar el arrendamiento aparece una dependencia crítica, el operador deja de enviar la opción y los clientes vuelven a intentar DHCPv4 cuando expire el plazo o se reconecten.

Cinco minutos no siempre es gratis. Miles de equipos que repiten DHCPDISCOVER con esa frecuencia pueden cargar los servidores. Por eso el intervalo es una variable de capacidad y riesgo. Un tiempo breve limita la duración de una mala decisión; uno más largo reduce tráfico de control. La elección necesita recuentos de clientes, consumo de DHCP y tiempos reales de reparación.

La cadena que un panel no debe comprimir

La frase “hemos activado la opción 108” mezcla al menos seis estados diferentes.

El primero es la política de interfaz. ¿Quién declaró que el equipo podía funcionar sin IPv4 y con qué pruebas? RFC 8925 llama a esta declaración una decisión de política. Un CLAT disponible en una interfaz no convierte automáticamente a todas las demás en capaces.

El segundo es la petición observada. ¿Apareció de verdad el código 108? Sin esa prueba no hay voluntad del cliente.

El tercero es el alcance del servidor. ¿La respuesta procedía del pool exacto configurado como IPv6-mostly? La activación global de una función no acredita el contexto de una oferta.

El cuarto es la oferta: longitud válida de cuatro bytes, valor del temporizador y dirección anunciada. Una captura de control puede mostrar si se usó 0.0.0.0 o una dirección no reservada.

El quinto es el estado alcanzado. ¿El cliente dejó de pedir la dirección, cuánto tiempo mantuvo la pausa y qué ocurrió en renovación, INIT-REBOOT o reconexión? El paquete del servidor no demuestra por sí solo la conducta del sistema operativo.

El sexto es el resultado útil. ¿Llegó PREF64? ¿Funcionó NAT64? ¿Se activó CLAT para el software que solo entiende IPv4? ¿Pudieron los usuarios completar sus tareas? Una tabla de arrendamientos vacía no contiene esas respuestas.

Separar la cadena permite decir algo preciso: este cliente rechazó esta dirección, en este pool, durante este periodo, y estas aplicaciones funcionaron o fallaron. Esa frase es evidencia. “IPv4 apagado” es una etiqueta.

Lo que la opción 108 deja fuera

El RFC presupone que la red ofrece NAT64 para alcanzar destinos que solo tienen IPv4. La opción 108 no negocia esa tecnología, no comunica el prefijo del traductor y no comprueba su ruta. Su trabajo termina antes.

RFC 8781, firmado también por Jen Linkova, define una opción de Router Advertisement para anunciar PREF64. RFC 9872 recomienda esa vía para despliegues nuevos porque el prefijo puede llegar junto con el resto de la configuración IPv6; mantiene el descubrimiento por DNS como alternativa cuando la opción RA no está disponible o el cliente no la admite. Hasta obtener PREF64, advierte RFC 9872, las aplicaciones IPv4 y los destinos exclusivamente IPv4 pueden quedar afectados.

464XLAT cubre otra brecha. Un traductor del lado del cliente presenta conectividad IPv4 limitada a programas heredados y transporta los paquetes sobre IPv6. RFC 6877 aclara que no es una sustitución uno a uno de IPv4 completo: no reproduce conexiones entrantes ni toda comunicación entre pares.

Así se explican fallos que no invalidan el intercambio DHCP. El cliente rechazó correctamente la dirección, pero el router no anunció PREF64. El prefijo llegó, pero NAT64 no tenía ruta. La traducción funcionaba, pero una VPN bloqueó tráfico IPv6. El navegador salió por IPv6 nativo mientras una aplicación con literales IPv4 no encontró CLAT.

En cada caso hay que nombrar la capa que falló. Si se culpa a “IPv6” o a “la opción 108” en bloque, la organización pierde la capacidad de reparar el mecanismo concreto.

La doble pila como ocultador de defectos

Happy Eyeballs puede evitar un camino IPv6 enfermo y utilizar IPv4 antes de que el usuario note el problema. Esa tolerancia protege la experiencia, pero también certifica como sana una red que quizá no lo esté. Cuando desaparece la dirección IPv4, el defecto antes oculto queda expuesto.

El borrador 6MOPS propone una secuencia para controlar esa exposición: activar primero la señal PREF64, después el procesamiento de la opción 108 en el servidor y, si se gestionan los terminales, avanzar por dispositivo. Alerta de que algunos sistemas operativos ya procesan la opción de forma predeterminada. Para ellos, encenderla en el servidor equivale a convertir de inmediato todo el subconjunto compatible.

Las diapositivas de Linkova en IETF 118 describieron pilotos en oficinas de Google, ampliación a varias ubicaciones y porcentajes de activación crecientes. También comunicaron descensos de utilización DHCP y previsiones de recuperación de direcciones. Son afirmaciones operativas atribuidas a esa presentación y a ese entorno, no tasas universales. La enseñanza transportable es la forma de probar: cohorte acotada, observación, ampliación y marcha atrás disponible.

La ejecución no obedece a un texto por deferencia. Genera datos que pueden confirmar, matizar o contradecir la guía. Un borrador que recomienda una secuencia ofrece una hipótesis; los arrendamientos, las capturas y los incidentes deciden si funcionó.

Cuánta demanda revela un arrendamiento rechazado

Una dirección no tomada puede volver al pool. Si los equipos recibían IPv4 públicas, el ahorro puede ser directo. En redes con RFC 1918, puede aliviar el agotamiento privado y evitar capas adicionales de NAT. Un segmento nuevo puede dimensionarse con menos IPv4 desde el principio. Uno existente quizá tenga que renumerarse antes de convertir el espacio libre en un bloque reutilizable.

La observación, sin embargo, está condicionada. Dice que esta interfaz, con este software y esta política, en una red con esta traducción, no necesitó tomar una dirección durante el intervalo. No demuestra que todas sus aplicaciones fueran correctas, que rechazará IPv4 en otro sitio ni que los equipos restantes puedan hacer lo mismo.

Tampoco elimina la escasez. Puede concentrar la demanda en los usos que verdaderamente dependen de IPv4. El valor económico del dato reside en separar la necesidad observada de la asignación automática, no en declarar que el recurso ha perdido valor.

Conviene mantener varios indicadores: clientes que piden el código, ofertas válidas, arrendamientos evitados, reintentos, retornos tras incidencias, salud de NAT64/CLAT, fallos por aplicación y espacio que finalmente pudo redimensionarse. Un porcentaje IPv6 no sustituye a ese inventario.

El reloj de cinco minutos evita que una conclusión temporal se convierta en dogma. La red toma nota del no, vigila las consecuencias y deja abierta la posibilidad de un sí posterior.

La contribución, sin convertirla en autoridad

RFC 8925 nombra a Lorenzo Colitti, Jen Linkova, Michael C. Richardson y Tomek Mrugalski. Linkova aparece asimismo en RFC 8781, RFC 9872 y el borrador 6MOPS junto con otros autores. El registro muestra una contribución continuada a mecanismos relacionados. No acredita invención exclusiva ni control sobre implementaciones, fabricantes u operadores.

La propia arquitectura impide esa confusión. Un documento especifica. El cliente decide si solicita. El operador configura el pool. El código interoperable ejecuta y el resultado se ve en la red. Quien no participa conserva DHCPv4 normal; no recibe una sanción institucional por ello.

La aportación más interesante es, precisamente, haber dado forma limitada a una pregunta grande. En lugar de anunciar el final de IPv4, la opción pregunta si una dirección puede quedar de guardia durante un intervalo. Cuando la respuesta práctica es negativa, el reloj permite que vuelva.

Fuentes