Resumen

  • Option 108 permite que un cliente preparado para IPv6-only pida no recibir una dirección IPv4; el servidor responde solo en un pool IPv6-mostly configurado.
  • El borrador no fija una prueba universal de compatibilidad. El operador decide los dispositivos, la salida de emergencia y los fallos que IPv4 ocultaba.

Un servidor DHCP no puede revisar las aplicaciones de un portátil y certificar que el día de su usuario funcionará sin IPv4. Option 108 ni siquiera lo intenta. Permite que un cliente compatible diga que está dispuesto a prescindir de una dirección IPv4. El operador decide en qué redes se acepta esa señal.

Ese es el punto de giro de la versión 12 del borrador del IETF sobre redes IPv6-mostly, actualizada el 29 de octubre y en última llamada del IESG hasta el 12 de noviembre. El borrador sitúa dispositivos IPv4 e IPv6-only en el mismo segmento. Un cliente que solicita Option 108 y la recibe en un DHCPOFFER no debería pedir la dirección IPv4 ofrecida. Los dispositivos que no reconocen la opción aún pueden recibir una dirección de un pool configurado para IPv6-mostly.

La opción es una señal, no una prueba de compatibilidad. El borrador dice que “IPv6-only-capable” no tiene una definición técnica estricta. Describe un dispositivo que funciona sin IPv4 nativa y ofrece al usuario la misma experiencia. Sus aplicaciones pueden usar sockets IPv6 y comunicarse solo con destinos IPv6; NAT64 puede abrirles destinos IPv4-only; o el dispositivo puede ejecutar CLAT, el traductor del lado del cliente definido por RFC 6877, para aplicaciones IPv4 antiguas. RFC 8925 ya trata la declaración de capacidad de una interfaz como una decisión de política. El borrador -12 asume la consecuencia: el intercambio DHCP no descubre si el dispositivo está listo. Alguien debe decidir qué equipos, interfaces o grupos de usuarios pueden afirmarlo.

El servidor tiene un papel acotado. RFC 8925 solo permite enviar Option 108 cuando el cliente la solicitó y el pool seleccionado está configurado explícitamente como IPv6-mostly. Su valor de cuatro octetos indica durante cuántos segundos el cliente debe desactivar DHCPv4. El servidor envía el temporizador V6ONLY_WAIT configurado; si no existe, envía cero. La configuración del pool, y no una etiqueta optimista del cliente, controla dónde desaparece la dirección.

Los destinos IPv4-only siguen necesitando una ruta. El borrador se apoya en NAT64 y en que el prefijo se anuncie mediante mensajes de Router Advertisement según RFC 8781, DNS64 según RFC 6147, o ambos. Una aplicación sin compatibilidad con IPv6 puede necesitar CLAT. Si falla el dispositivo, el DNS, el traductor o el acceso de red, desaparece el respaldo dual-stack que antes escondía el problema.

Por eso el calendario de migración importa más que el número de la opción. El borrador -12 recomienda un piloto voluntario y después una fase de salida voluntaria mientras el operador activa el anuncio de PREF64 y Option 108. Incluso plantea que el usuario tenga que reportar un problema para salir. Eso produce una señal útil de fallos y convierte a la persona afectada en el primer equipo de pruebas. El borrador también llama provisional al bloqueo de IPv4 mediante ACL: el operador debe mantener al día la intención asociada a cada dispositivo, especialmente cuando se mueve.

El borrador no aporta cifras de despliegue ni datos de fallos observados, por lo que no permite medir el ahorro de direcciones ni la experiencia de usuario. Su argumento es arquitectónico: una red común puede dejar de entregar IPv4 a los clientes listos para vivir sin ella y mantener la dirección para quienes aún la necesitan. La pregunta operativa sigue abierta: ¿cómo demuestra el operador que un dispositivo está “listo” antes de que soporte aprenda la respuesta aplicación por aplicación?

Sources · RFC 8925 · RFC 6877 · RFC 8781 · RFC 6147