Resumen

  • T1 da al servidor que concedió la dirección la primera oportunidad de renovar; T2 convierte DHCPREQUEST en una petición difundida para servidores con autoridad administrativa; el vencimiento obliga al cliente a abandonar la dirección sin un nuevo ACK.
  • REBINDING amplía la disponibilidad, no la autoridad universal. Poder oír una difusión no basta para prolongar una concesión, y que los paquetes sigan pasando no modifica el plazo.

La red seguía funcionando, pero el derecho ya estaba cambiando

Un equipo despierta con la misma dirección IPv4, rutas útiles y conexiones que todavía intercambian datos. El servidor DHCP original guarda silencio. A simple vista, sería razonable continuar como si nada hubiera ocurrido.

El protocolo rehúsa convertir esa impresión en una regla. El cliente conserva tres referencias: T1, T2 y el final de la concesión. T1 abre una conversación con quien otorgó el estado. T2 busca una autoridad alternativa. El vencimiento termina el uso autorizado.

No son tres recordatorios del mismo tipo. Cada uno cambia el conjunto de respuestas que el cliente puede aceptar y la consecuencia de no obtener ninguna.

Una dirección reutilizable no podía ser una posesión permanente

En octubre de 1993, RFC 1541 describió la asignación dinámica como una dirección entregada por tiempo limitado o hasta su liberación. Esa limitación permitía devolverla a un conjunto escaso y asignarla después a otro cliente.

El estado asociado es un binding: parámetros de configuración, incluida al menos una dirección IP, vinculados a un cliente y administrados por servidores DHCP. La palabra evita una confusión. DHCP no registra propiedad mundial; mantiene una decisión local bajo política administrativa.

RFC 2131 preservó en 1997 la asignación automática, la dinámica y la manual. Solo la dinámica depende necesariamente del reloj de concesión que conduce por BOUND, RENEWING y REBINDING.

T1 y T2 reservaron tiempo para autoridades distintas

RFC 2132 define la opción 51 para la duración, la 58 para T1 y la 59 para T2. Son intervalos contados desde la asignación y expresados en segundos. No son fechas del calendario ni marcas de expiración independientes.

Si faltan valores válidos, RFC 2131 sitúa T1 por defecto en el 50 % de la duración y T2 en el 87,5 %. Aconseja una variación aleatoria para evitar renovaciones sincronizadas. Esos porcentajes son valores de respaldo, no una recomendación para toda red actual.

El espacio entre T1 y T2 protege la afinidad. El espacio entre T2 y el vencimiento protege la recuperación. El final protege al conjunto de direcciones frente a una continuidad inventada por el cliente.

RENEWING preguntaba a quien conocía la concesión

Cuando vence T1, el cliente entra en RENEWING. Envía DHCPREQUEST al servidor que le otorgó la dirección si conoce su dirección de red. Coloca la dirección en uso en ciaddr; no vuelve a comparar ofertas ni escoge un servidor nuevo.

El servidor concedente recibe prioridad porque conoce el binding que creó. Puede prolongarlo, modificar parámetros o negarse a extenderlo según la política del administrador. Esta afinidad reduce el riesgo de que otro servidor tome una decisión sin conocer la promesa anterior.

Si no hay respuesta, el cliente no abandona inmediatamente la dirección. Todavía posee la concesión original y retransmite en función del tiempo restante. La caída del servidor es un fallo de contacto, no un NAK automático.

REBINDING cambió el alcance de la pregunta

Al llegar T2 sin ACK, el cliente difunde DHCPREQUEST. Mantiene ciaddr y elimina el identificador del servidor. La petición deja de depender de un destino que quizá haya desaparecido.

Sin embargo, RFC 2131 no autoriza a cualquier servidor que la reciba. Solo puede extender la concesión quien tenga autoridad administrativa local para hacerlo. La previsión sirve a instalaciones con varios servidores y un mecanismo que mantenga coherencia entre sus estados.

La difusión proporciona descubrimiento, no delegación. Una máquina puede escuchar el paquete y aun así carecer del estado del conjunto, de la política o del derecho a hablar por esa red.

Por eso el rebind somete a prueba algo más que la conectividad: somete a prueba la custodia compartida. Si dos servidores no coinciden acerca de qué dirección está concedida, la vía de recuperación puede producir precisamente la colisión que pretendía evitar.

ACK, NAK y silencio no eran equivalentes

DHCPACK renueva la concesión y vuelve a establecer los timers. También puede transportar parámetros cambiados; la continuidad de dirección no exige inmovilidad del resto de la configuración.

DHCPNAK declara inaceptable la configuración actual. El cliente debe detener su uso y regresar a la inicialización. Guardar la dirección después de un NAK sería otorgarse a sí mismo una facultad que el protocolo reserva a la red administrada.

El silencio conserva el derecho solo mientras dure la concesión anterior. En RENEWING, el cliente espera fracciones del tiempo hasta T2; en REBINDING, fracciones del tiempo restante hasta expirar, con límites de retransmisión definidos por el RFC.

Si llega el final sin ACK, el cliente pasa a INIT y detiene el procesamiento de red. Una respuesta ARP, una tabla de vecinos o un router que aún reenvía no pueden convertir el silencio en prórroga.

Reiniciar no hizo autoritativa la memoria local

INIT-REBOOT permite que un cliente recuerde una dirección usada antes y pida conservarla. La petición se difunde porque quizá haya cambiado de red o ya no conozca a la autoridad apropiada.

Un servidor confirma con DHCPACK o rechaza con DHCPNAK. Si el cliente no alcanza a ningún servidor, puede usar la configuración anterior únicamente durante la parte no vencida de la concesión. El valor almacenado acelera la recuperación, pero debe someterse a validación.

FORCERENEW adelantó el examen sin saltarse el protocolo

RFC 3203 añadió FORCERENEW, un mensaje unicast con el que un servidor puede llevar al cliente a RENEW antes de T1. El cliente responde con el DHCPREQUEST normal. Si debe abandonar la dirección, el servidor envía DHCPNAK y se reinicia la búsqueda.

El mensaje puede interrumpir sesiones y un emisor falso podría usarlo para negar servicio. Por eso RFC 3203 exige la autenticación de RFC 3118. El servidor obtiene una forma de adelantar la decisión, no una escritura silenciosa e ilimitada sobre el cliente.

La concesión no demostraba que el enlace estuviera libre

El servicio DHCP puede asignar correctamente una dirección que, por error, otro host ya usa. RFC 5227 exige sondear la dirección IPv4 antes de comenzar a utilizarla. Ante un conflicto de una oferta DHCP, el cliente envía DHCPDECLINE.

Así quedan separadas dos autoridades. DHCP expresa la configuración que la red pretende conceder; la observación ARP comprueba si el enlace contradice esa intención. Ni ACK ni la sonda autentican al usuario, prueban propiedad legal o garantizan alcance de extremo a extremo.

Fuentes y límites de la evidencia

La reconstrucción se apoya en seis fuentes oficiales:

Los documentos delimitan DHCPv4. No permiten afirmar cuotas de despliegue, valores por defecto de productos, calidad de clientes, consistencia real de servicios redundantes ni comportamiento de DHCPv6.