Qué es DHCP
DHCP automatiza la entrega de direcciones y otros parámetros de red. RFC 2131 define el protocolo DHCP para IPv4 y su modelo de concesiones temporales.
DHCP resuelve un problema práctico: entregar de forma consistente parámetros de red a muchos clientes sin configurar cada host a mano. Además de una dirección IPv4, el servidor puede proporcionar máscara, router por defecto, servidores DNS, dominio y muchas otras opciones.
El protocolo está basado en un modelo cliente-servidor con concesiones temporales. Esa temporalidad permite reutilizar direcciones y mantener control administrativo sobre un pool, algo especialmente útil en redes con movilidad o gran número de endpoints.
DORA
El flujo DORA resume DHCPDISCOVER, DHCPOFFER, DHCPREQUEST y DHCPACK. El cliente comienza sin una configuración completa y por eso parte del intercambio usa broadcast.
En el flujo más conocido, el cliente emite DHCPDISCOVER, uno o varios servidores responden con DHCPOFFER, el cliente selecciona una oferta mediante DHCPREQUEST y el servidor confirma con DHCPACK. DORA es una ayuda mnemotécnica, no una descripción de todos los mensajes posibles.
Durante el arranque el cliente todavía puede carecer de dirección utilizable y de conocimiento del servidor. Por eso aparecen broadcasts y campos específicos de DHCP/BOOTP. Una captura de paquetes permite ver rápidamente en qué fase se interrumpe la negociación.
Puertos UDP
DHCPv4 usa normalmente UDP 67 en el servidor y UDP 68 en el cliente. Reconocer estos puertos ayuda al revisar ACL, firewall y capturas.
DHCPv4 utiliza UDP 67 para el servidor y UDP 68 para el cliente. El hecho de usar UDP obliga al protocolo a gestionar sus propios tiempos de espera y retransmisiones. Una ACL que bloquee estos puertos en el punto equivocado puede romper el servicio aunque IP y routing estén bien configurados.
Leases
Una dirección se entrega durante una concesión o lease. El cliente intenta renovarla antes de que expire y el servidor puede reutilizar direcciones cuando dejan de estar en uso.
La concesión define durante cuánto tiempo puede utilizarse una configuración. Normalmente el cliente intenta renovar antes de llegar al final; si no puede contactar con el servidor original, puede pasar a una fase de rebinding más amplia. El objetivo es conservar la dirección cuando sea razonable sin impedir que el servidor recupere recursos abandonados.
Duraciones muy cortas aumentan tráfico y carga administrativa; duraciones demasiado largas ralentizan la reutilización de un pool. La política depende de estabilidad, tamaño del rango y movilidad de los clientes.
Scopes y opciones
Un pool define las direcciones disponibles para una subred. Además se entregan opciones como máscara, puerta de enlace y DNS. Un cliente puede tener IP y aun así fallar si gateway o DNS son incorrectos.
Un scope o pool debe corresponder con la subred donde se utilizarán las direcciones. Es habitual excluir direcciones reservadas para infraestructura y definir parámetros comunes como gateway y DNS. El servidor no «adivina» el diseño de la red: debe estar alineado con el plan de direccionamiento.
Una configuración incompleta puede producir síntomas engañosos. Por ejemplo, una dirección y máscara correctas con gateway incorrecto permiten comunicación local pero no salida a otras redes.
Reservas
Una reserva mantiene una dirección estable para una identidad concreta sin renunciar a la gestión centralizada. Es diferente de configurar una IP manual fija fuera del servidor.
Las reservas asocian una identidad del cliente con una dirección concreta gestionada por DHCP. Son útiles para impresoras, dispositivos de gestión o equipos que necesitan estabilidad sin perder administración centralizada. No deben confundirse con una IP estática configurada manualmente en el host.
DHCP relay
Los broadcasts no atraviesan routers normalmente. Un DHCP relay recibe la petición en la red del cliente y la reenvía al servidor, indicando la subred de origen para elegir el pool correcto.
Los routers no reenvían de forma ordinaria el broadcast inicial de un cliente DHCP entre subredes. Un relay escucha en la interfaz/VLAN del cliente y envía la petición al servidor, incluyendo información como la dirección del gateway de la subred de origen. El servidor usa esa información para seleccionar el pool adecuado.
Cuando sólo fallan clientes de una VLAN concreta y el servidor central funciona para otras, el relay, la ruta de retorno o la política entre esa VLAN y el servidor son candidatos claros.
Agotamiento y conflictos
Un pool agotado, exclusiones mal definidas, reservas solapadas o un servidor no autorizado pueden causar fallos. DHCP snooping es una defensa de Capa 2 que veremos en seguridad.
Un pool puede quedarse sin direcciones libres por crecimiento real, leases demasiado largos o clientes que no liberan concesiones. Los conflictos también aparecen si existen IP estáticas dentro del rango dinámico o servidores DHCP no autorizados.
En entornos conmutados, mecanismos como DHCP snooping ayudan a limitar respuestas no confiables y crean información útil para otras protecciones de Capa 2. Eso pertenece al cluster de seguridad, pero conviene conocer la relación.
169.254.0.0/16
Algunos sistemas usan direccionamiento IPv4 link-local de 169.254.0.0/16 cuando no obtienen DHCP. Es una pista útil, no una explicación completa.
RFC 3927 define IPv4 Link-Local dentro de 169.254.0.0/16. Sistemas operativos pueden autoconfigurarse ahí cuando no obtienen una configuración normal. Ver una 169.254.x.x es una pista fuerte de que el proceso esperado de direccionamiento no terminó, pero la causa puede ser desde Capa 2 hasta relay, servidor o filtrado.
DHCPv6
IPv6 puede combinar SLAAC y DHCPv6. La puerta de enlace por defecto se aprende mediante Router Advertisements, no como una simple réplica del modelo DHCPv4.
IPv6 separa funciones que en IPv4 suelen asociarse a DHCP. Los Router Advertisements de Neighbor Discovery comunican información de router y prefijos; SLAAC puede generar direcciones; DHCPv6 puede aportar direcciones y/o parámetros adicionales. La puerta de enlace por defecto no se aprende simplemente como una opción DHCPv6 equivalente a DHCPv4.
Por eso al diagnosticar IPv6 hay que observar RA, flags, SLAAC y DHCPv6 como piezas relacionadas pero distintas.
Troubleshooting
Comprueba enlace y VLAN, presencia de Discover, relay, pool, gateway, DNS y políticas UDP 67/68. Si hay IP pero no nombres, sigue con DNS; si no hay salida, revisa routing.
Empieza por verificar enlace, VLAN y puerto; después observa si sale DHCPDISCOVER y si aparece una oferta. Si existe relay, confirma su configuración y la ruta entre relay y servidor. Revisa pool, exclusiones, leases y opciones entregadas.
Si el cliente recibe dirección pero no navega, deja de mirar DHCP como primera hipótesis: prueba gateway, routing y DNS. Una captura en cliente, relay o servidor permite ubicar con precisión dónde desaparece el intercambio.
Referencias
RFC 2131 define DHCPv4, RFC 2132 sus opciones, RFC 3927 IPv4 link-local y RFC 8415 DHCPv6.
RFC 2131 define DHCPv4 y RFC 2132 documenta muchas opciones. RFC 3927 cubre IPv4 Link-Local. DHCPv6 se especifica actualmente en RFC 8415, que consolidó y actualizó el trabajo anterior.
Cómo continuar
Continúa con DNS para entender cómo se entregan y utilizan resolvers, con routing para el camino hacia servidores remotos y con IPv6 para SLAAC y DHCPv6.
Ejemplo operativo
En una red real, DHCP debe documentarse junto con direccionamiento, VLAN, rutas y políticas. El diagnóstico más fiable separa primero conectividad IP de la función del servicio, verifica el camino de ida y vuelta y después revisa la configuración específica. Esta disciplina evita atribuir a DHCP fallos que en realidad pertenecen a Capa 2, routing, ACL o resolución de nombres.
También conviene registrar cambios y medir antes y después. Una configuración técnicamente válida puede tener un efecto operativo distinto al esperado si existen dependencias no documentadas o si varios dispositivos aplican políticas diferentes.
Supón una empresa con veinte VLAN y un único par de servidores DHCP. Cada SVI actúa como relay. Si una nueva VLAN no obtiene direcciones pero las demás sí, comprobar el scope del servidor es útil, pero también lo son la dirección de relay, la ACL de esa interfaz y la ruta de retorno hacia la nueva subred.
La metodología correcta es seguir el mensaje: ¿sale Discover?, ¿el relay lo reenvía?, ¿el servidor ofrece?, ¿la respuesta vuelve?, ¿el cliente acepta? Ese recorrido convierte un síntoma genérico en una localización concreta del fallo.