Resumen

  • RFC 3315 permitió que un cliente DHCPv6 pidiera Solicit–Reply en lugar de Solicit–Advertise–Request–Reply; el servidor podía rechazar esa petición y seguir con la selección habitual.
  • Con Rapid Commit, el servidor comprometía la concesión antes de enviar Reply. Varios servidores podían comprometer direcciones aunque el cliente solo usara las de uno; una respuesta perdida también separaba el estado del servidor de lo que el cliente había recibido.

Los cuatro mensajes habituales hacían algo más que añadir una espera. Tras enviar Solicit, el cliente recibía anuncios Advertise, podía compararlos y elegía un servidor con Request. La confirmación Reply llegaba después de esa elección. RFC 3315, publicado en julio de 2003, estableció la especificación de DHCP para IPv6 y permitió acortar ese intercambio, pero no convirtió la vía breve en automática.

Para usarla, el cliente incluía la opción Rapid Commit —sin datos en su campo de opción— dentro de Solicit. Con ello mostraba que aceptaría Reply inmediato. La opción no obligaba a los servidores: cada uno seguía sujeto a su política y configuración. Si no estaba preparado para asignar recursos comprometidos en esa etapa, podía ignorar la petición y responder con Advertise. Entonces el cliente continuaba por la ruta normal de selección. Si el servidor sí aceptaba Rapid Commit, creaba la asignación antes de transmitir Reply.

Ese orden es el centro del intercambio. Cuando el cliente recibe un Reply válido que lleva Rapid Commit, puede usar la dirección y la configuración incluidas sin enviar Request. Sin embargo, el servidor no recibe una confirmación posterior de que el cliente haya recibido Reply. RFC 3315 advierte que, si responden varios servidores al mismo Solicit, todos pueden comprometer direcciones mientras el cliente utiliza únicamente las concesiones de uno. Los demás registros quedan comprometidos aunque no se usen. Si Reply se pierde, también puede quedar una concesión registrada por el servidor que el cliente no puede utilizar.

La vía de cuatro mensajes mantenía una elección explícita antes de la asignación definitiva. La de dos aceleraba la configuración al prescindir de esa etapa y adelantar el compromiso. No eliminaba la incertidumbre: la trasladaba a los pools y a la coordinación entre servidores. El documento propone limitar quién responde o usar concesiones iniciales más cortas para reducir recursos comprometidos que nadie utiliza. No afirma que todos los despliegues tengan un único servidor ni que cada concesión sobrante provoque un conflicto.

En 2005, RFC 4039 llevó una opción Rapid Commit a DHCPv4, retomando la idea en entornos de movilidad frecuente, donde cambiar a menudo el punto de conexión podía hacer valiosa una configuración rápida. También explicó la ventaja de la secuencia normal: varias ofertas pueden seguir siendo provisionales mientras el cliente decide. Esa continuidad documenta un compromiso de diseño, no su adopción universal ni una medición de latencia.

RFC 8415 consolidó DHCPv6 en 2018. En 2026, RFC 9915 sustituyó RFC 8415 y mantuvo el mismo reparto de decisiones: el cliente puede solicitar la vía rápida, pero el servidor decide si la configuración le permite comprometer las concesiones de inmediato. El riesgo de direcciones comprometidas pero no usadas sigue siendo explícito. La historia de Rapid Commit trata, por tanto, de cuándo el protocolo hace irreversible en la práctica una decisión de recursos y de qué señal permite saber si ambos extremos comparten el mismo estado.

Fuentes: RFC 3315, RFC 4039, RFC 8415 y RFC 9915.