Resumen

  • En una asignación normal, DHCPACK compromete el vínculo del servidor; el cliente entra en BOUND después de comprobar que la dirección no está en conflicto. Autoriza uso temporal, no propiedad.
  • El tiempo reparte la autoridad entre la renovación con el servidor original en T1, la revinculación abierta a otros servidores en T2 y el abandono obligatorio al vencer sin otra confirmación.
  • DHCPACK también responde a DHCPINFORM sin asignar ninguna dirección, por lo que el tipo de mensaje aislado no prueba qué operación ocurrió.

Una concesión que se ve como posesión

El cliente comienza sin una configuración IPv4 utilizable. Difunde su búsqueda, compara ofertas, pide una y recibe DHCPACK. La dirección pasa a ser visible, el tráfico fluye y los registros empiezan a usarla como clave. En la experiencia inmediata no hay diferencia aparente entre una concesión y una pertenencia.

La RFC 2131 sí conserva la diferencia. El servidor seleccionado compromete un vínculo con el cliente y los parámetros que acepta entregar. Antes de usar la dirección, el cliente hace una última comprobación en el enlace. Si descubre que ya está ocupada, envía DHCPDECLINE y vuelve a empezar. El conocimiento de la base central no desplaza la evidencia contradictoria del medio local.

Ralph Droms figura como autor de la RFC 2131. Su perfil en el IETF añade que organizó en 1989 el grupo de trabajo que diseñó DHCP. La atribución razonable es importante: ayudó a convertir la configuración dinámica en una máquina de estados normalizada. No sería correcto atribuirle en solitario todas las extensiones posteriores, implementaciones comerciales o decisiones de cada operador.

El reloj forma parte del permiso

Una solicitud del cliente expresa preferencias, no derechos. Puede señalar una dirección conocida o proponer una duración, mientras el servidor aplica la política de su dominio. El DHCPACK comunica la decisión aceptada y activa un arrendamiento cuyos límites son parte esencial de su significado.

T1 suele llegar a la mitad del periodo. El cliente entra en RENEWING y dirige DHCPREQUEST al servidor que concedió el arrendamiento. Si no logra prolongarlo, T2 suele aparecer cuando han transcurrido siete octavos; en REBINDING puede aceptar respuesta de otro servidor. Ambos temporizadores son relativos y el servidor puede fijar valores distintos.

La expiración no es una advertencia blanda. Sin un nuevo DHCPACK a tiempo, el cliente debe detener inmediatamente el procesamiento de red con esa dirección, abandonarla y regresar a INIT. El servidor podrá reutilizarla. La especificación dibuja así una frontera en la que termina la autoridad, algo incompatible con leer el mensaje como propiedad permanente.

«Infinito» describe tiempo, no un título

La opción 51 de la RFC 2132 permite que todos los bits a uno representen un arrendamiento infinito. En operación, un periodo largo o infinito puede dar continuidad casi estática y reducir intercambios. Además, durante un arrendamiento vigente el DHCPACK sí expresa una autoridad efectiva del servicio de configuración.

Lo que no hace ese valor es certificar a la persona tras el equipo, producir derechos fuera del dominio o inmovilizar la política del administrador. «Sin expiración programada» y «propiedad» son afirmaciones distintas. La segunda no está codificada en la opción.

La RFC 5227 añade una comprobación independiente. Un host sondea el enlace antes de adoptar una dirección IPv4 y responde si encuentra un conflicto. La detección no sustituye al servidor, pero impide asumir que su tabla refleja perfectamente la realidad física. Política de asignación y disponibilidad observada son pruebas complementarias.

Un acuse que no concede dirección

DHCPINFORM rompe cualquier regla basada solo en el nombre DHCPACK. Un cliente que ya obtuvo su dirección por otro medio puede solicitar otros parámetros. El servidor responde con DHCPACK, pero no asigna dirección, no consulta un vínculo, no rellena yiaddr ni adjunta el tiempo de arrendamiento.

Así, un mismo tipo de mensaje participa en actos diferentes. Dentro del flujo de asignación confirma el vínculo; en INFORM se limita a entregar configuración adicional. Si un sistema de inventario cuenta ambos como asignaciones, convertirá una simplificación de análisis en procedencia falsa.

La RFC 6842 mejora el emparejamiento al exigir que el servidor devuelva el identificador de cliente en DHCPOFFER y DHCPACK en los casos definidos. La mejora ayuda a reconocer qué respuesta pertenece a qué intercambio. No autentica a un ser humano ni convierte el identificador en una credencial de propiedad.

La verdad que puede afirmar el servidor

Leasequery, en la RFC 4388, permite consultar la perspectiva del servidor. La respuesta clasifica una dirección como ACTIVE, UNASSIGNED o UNKNOWN y, si está activa, puede indicar cuánto queda. La consulta no cambia el vínculo. La autoridad se refiere a la base de arrendamientos consultada, no a toda la actividad observable del segmento.

Para una investigación, asignación de dirección y atribución de conducta son proposiciones distintas. El historial puede apoyar que un servicio autorizó a cierto identificador a usar una dirección durante un intervalo. No demuestra por sí solo quién manejaba el dispositivo, que todo paquete tuviera ese origen o que la conclusión siga siendo válida fuera de las fechas registradas.

La consecuencia no es descartar DHCP, sino combinar bien sus pruebas: historial íntegro, identificadores, datos del relay, observación de capa de enlace, conflictos y relojes sincronizados. DHCPACK es una pieza fuerte cuando se le pregunta por el acto que realmente representa.

Fuentes