Resumen

  • La versión 03 del borrador individual de Mark Smith incorpora una salida para los clientes que requieren DHCPv4 Router Option 3: la dirección DHCP del propio host o 127.0.0.1.
  • El documento prevé que ambos valores mantengan dentro del equipo los paquetes IPv4 no locales y generen un ICMP Destination Unreachable. Es una propuesta, no una prueba de interoperabilidad publicada.
  • Las pruebas mencionadas por el blog de LACNIC el 2 de octubre se hicieron sobre la versión 02, antes de que apareciera esta alternativa.

Análisis

Una puerta de enlace predeterminada debería conducir a otra red. La nueva revisión de un borrador DHCPv4 plantea que, para algunos clientes antiguos, el campo puede apuntar de vuelta al propio equipo.

El 16 de octubre, Mark Smith publicó la versión 03 de “Nearly IPv6 Only Dual Stack Hosts”. La versión 02 había caducado el 15 de junio. El texto conserva la opción de no enviar Router Option 3 para los clientes que la aceptan, pero añade una alternativa para los que supuestamente la exigen: indicar como router la dirección DHCP asignada al mismo host o 127.0.0.1.

No son puertas de enlace habituales. La RFC 2132 define la opción 3 como la lista de routers que el servidor DHCP entrega al host. El borrador dice que, con una máscara /32, cualquiera de los dos valores debería mantener en el equipo los paquetes destinados a direcciones IPv4 no locales y provocar un ICMPv4 Destination Unreachable. La expectativa depende de cómo interprete la ruta cada cliente. El documento no publica una matriz que muestre qué clientes aceptan cada valor, qué rutas instalan o si sus aplicaciones vuelven a intentar la conexión por IPv6.

Las pruebas anteriores no responden esa pregunta. La publicación de Alejandro Acosta del 2 de octubre en el blog de LACNIC enlaza con la versión 02 y enumera ensayos en Windows 11, Fedora 43, Raspberry Pi OS basado en Debian Trixie, Chromecast y Google Nest. También dice que no se probaron teléfonos inteligentes y que hacen falta más pruebas. Esos ensayos preceden a la versión 03; no verifican su nueva rama de Router.

Por eso, el primer resultado que interesa no es que el servidor DHCP pueda enviar el valor. Un piloto debe separar las dos alternativas y medirlas por cliente, versión del sistema y configuración de servidor o relay. Conviene guardar el DHCP ACK, revisar la tabla de rutas instalada, capturar paquetes enviados a destinos IPv4 externos al host y comprobar si el error ICMP llega a la aplicación y activa un reintento por IPv6. El tráfico entre equipos del mismo enlace requiere su propia prueba: bloquear el tráfico enrutado no demuestra que desaparezca toda conectividad IPv4 local.

La propuesta tampoco sustituye a DHCPv4 Option 108. La RFC 8925 permite que un host compatible indique que prefiere operar solo con IPv6 durante cierto intervalo. El borrador aborda a los equipos que no reconocen esa opción o siguen esperando una respuesta DHCPv4. La noticia de la versión 03 es, por tanto, una nueva pregunta de compatibilidad; no una nueva norma.

Datatracker clasifica la versión 03 como un Internet-Draft individual activo, sin flujo RFC y con estado IESG “I-D Exists”. El propio documento dice que no está respaldado por la IETF y carece de rango formal en su proceso de estándares. Indica un estado previsto Informational y vence el 19 de abril de 2027. Que haya una nueva versión significa que la propuesta sigue en elaboración; no que la hayan adoptado la IETF o los proveedores de sistemas operativos.

Para los operadores, esta rama sirve para diseñar una prueba acotada, no para justificar un cambio general. Las direcciones del host y de loopback deben probarse por separado en un grupo piloto reversible. Un DHCP completado solo demuestra que se entregó una concesión. La pregunta pendiente es qué hace realmente el host con esa puerta de enlace que apunta hacia sí mismo.

Fuentes