DHCPACK (Dynamic Host Configuration Protocol acknowledgment) is the final DHCP message type that a server sends to confirm an address lease and deliver configuration parameters to a client, as defined in RFC 2131. It completes the standard four-message DHCP exchange and represents the moment a device gains working network access in enterprise networks. When DHCPACK messages are slow, missing, or blocked by misconfigurations—such as faulty relay agents, firewall rules, or pool exhaustion—clients lose network access or fall back to link-local addressing, creating operational outages that operators can diagnose through logging of DHCPACK and DHCPNAK activity.
Cómo funciona DHCPACK
DHCPACK es el último mensaje del intercambio DHCP estándar de cuatro mensajes para una nueva concesión. También se utiliza cuando un cliente renueva una concesión o solicita únicamente parámetros de configuración.
- Discover: El cliente emite un DHCPDISCOVER para encontrar servidores DHCP disponibles.
- Oferta: Cada servidor que responde envía un DHCPOFFER con una dirección propuesta y opciones de configuración.
- Solicitud: El cliente elige una oferta y emite un DHCPREQUEST indicando el servidor elegido, lo que también comunica a los demás servidores que sus ofertas han sido rechazadas.
- Confirmación: El servidor seleccionado registra la concesión y envía un DHCPACK que contiene la dirección, el tiempo de concesión y las opciones. A continuación, el cliente puede configurar su interfaz y empezar a utilizar la dirección.
Antes de utilizar la dirección, un cliente puede sondear la red, por ejemplo mediante ARP, para comprobar que ningún otro host la tiene asignada. Si la dirección ya está en uso, la RFC 2131 establece que el cliente envíe un DHCPDECLINE y vuelva a empezar. Si el servidor no puede atender una solicitud, envía un DHCPNAK en lugar de un DHCPACK. Un DHCPACK también responde a un DHCPINFORM; en ese caso, incluye opciones pero no una dirección.
Problemas habituales con DHCPACK
Los clientes de una subred remota envían solicitudes, pero nunca reciben un DHCPACK porque el agente de retransmisión tiene una giaddr incorrecta o no la tiene, o porque se bloquea el tráfico de retorno. Los registros del servidor muestran que se ha enviado un acuse de recibo, mientras que los registros del cliente muestran solicitudes repetidas.
Tras un corte de corriente o una tormenta de itinerancia Wi-Fi, muchos clientes envían solicitudes a la vez y un servidor sobrecargado o una base de datos backend lenta retrasa el DHCPACK. Los clientes agotan el tiempo de espera, vuelven a intentarlo y pueden recurrir a direcciones locales de enlace.
Un servidor DHCP no autorizado, a menudo un router doméstico conectado a un conmutador, envía su propio DHCPACK con una puerta de enlace o un servidor DNS incorrectos. Los usuarios obtienen direcciones que funcionan a nivel local, pero no pueden acceder a otras redes.
Un cliente comprueba la dirección tras el DHCPACK, descubre que ya está en uso y rechaza la concesión. Esto suele deberse a un dispositivo estático dentro del rango dinámico, y se manifiesta como rechazos repetidos en los registros del servidor.
Una política de seguridad o el filtrado DHCP en un puerto no de confianza descarta el DHCPACK del servidor, por lo que este registra una concesión de la que el cliente nunca tiene conocimiento. Comprueba que el puerto orientado al servidor sea de confianza y que los puertos UDP 67 y 68 estén permitidos.