Resumen
- RFC 3736 permitió que un nodo que ya tenía dirección IPv6 solicitara otros parámetros mediante un intercambio DHCPv6
Information-request/Reply, sin pedir al servidor que asignara una dirección. - «Sin estado» significa que el servidor no necesita conservar estado dinámico por cliente para este servicio; siguen importando la identificación opcional, la política local y el funcionamiento del relay.
Una dirección y un resolutor son trabajos distintos
La autoconfiguración IPv6 sin estado puede dar una dirección a un host a partir de los anuncios de router. Eso no resuelve todas sus necesidades de configuración: aún puede requerir direcciones de DNS recursivo, datos de servidores SIP u otras opciones. Es fácil imaginar DHCP como un paquete único: pedir una dirección al servidor y recibir junto con ella el resto de la configuración de red.
RFC 3736 separó esas funciones. El cliente ya obtuvo su dirección por otro mecanismo —normalmente autoconfiguración sin estado o configuración manual— y tiene al menos una dirección link-local para comunicarse. Envía Information-request con una opción de solicitud que indica los tipos de opciones deseados. El servidor responde con Reply y los parámetros que ha seleccionado. En este modo no se solicita una asociación de identidad de dirección ni se asigna una dirección.
El intercambio se redujo deliberadamente a dos mensajes: Information-request y después Reply. El host podía pedir configuración DNS sin convertir esa operación en un arrendamiento de dirección. El mismo sistema de servidores podía atender tanto a clientes que pedían direcciones como a los que solo necesitaban otros parámetros; los agentes relay operaban igual que en DHCP con estado.
Pero «sin estado» no quiere decir que el servidor carezca de configuración o política. RFC 3736 dice que no necesita mantener estado dinámico de cada cliente. También permite incluir un identificador de cliente cuando el administrador quiere personalizar la respuesta para un nodo. El servidor sigue seleccionando opciones según su política, y un relay puede seguir reenviando mensajes. El límite exacto es que este servicio de información no necesita crear ni seguir una vinculación de dirección por cliente.
La distinción ayuda a interpretar los indicadores de los anuncios de router IPv6. En RFC 4861, el indicador Managed señala que DHCPv6 puede proporcionar direcciones; Other anuncia que hay otra información disponible por DHCPv6. Cuando Managed está activo, Other resulta redundante. Son señales de disponibilidad, no prueba de que el host completara el intercambio DHCP, instalara un resolutor o pueda alcanzarlo.
Al quitar el arrendamiento de dirección también desapareció su reloj
Las direcciones asignadas tienen tiempos de vida que indican cuándo son preferidas, válidas o dejan de poder usarse. Otros parámetros pueden no tener ese tipo de vencimiento. RFC 3736 dejó expresamente sin resolver cuándo debía enviar el host otro Information-request para actualizar esos valores; tampoco dio una regla para hacerlo después de cambiar de enlace.
RFC 4242 añadió más tarde la opción Information Refresh Time: un límite superior al tiempo que el cliente debe esperar antes de pedir información DHCPv6 actualizada. La razón es reveladora. Si el intercambio no incluye un arrendamiento de dirección o prefijo, quizá tampoco haya un tiempo de vida que le diga al cliente cuándo volver. RFC 8415 consolidó después DHCPv6, dejó obsoletos RFC 3736 y RFC 4242, y conservó el intercambio informativo de dos mensajes.
La historia no es «DHCP desapareció cuando SLAAC produjo una dirección». La formación de la dirección y los demás parámetros del host podían separarse. Eso reducía el estado por cliente que necesitaba el servidor informativo, pero la configuración aún debía resolver precedencia de fuentes, renovación, alcance por interfaz e instalación del resolutor en el host. Un Reply demuestra que el protocolo devolvió opciones; por sí solo no demuestra que se instalaran o que una consulta DNS tuviera éxito.
Estas RFC no establecen con qué frecuencia usan hoy los clientes este modo ni cómo lo configura una red concreta. Especifican el mecanismo y sus límites, no su prevalencia ni el resultado del servicio.
Fuentes
- RFC 3736 — Stateless DHCP Service for IPv6 y registro del RFC Editor
- RFC 4242 — Information Refresh Time Option for DHCPv6 y registro del RFC Editor
- RFC 4861 — Neighbor Discovery for IPv6; RFC 4862 — IPv6 Stateless Address Autoconfiguration
- RFC 8415 — Dynamic Host Configuration Protocol for IPv6 y registro del RFC Editor
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
