DHCP, descubrimiento y configuración de red

Una dirección ofrecida no es todavía una red comprendida

Cuando un equipo recién conectado muestra una dirección IP, la tentación es describir el resultado como «la red lo configuró». Esa frase mezcla varias decisiones: un servidor pudo ofrecer un binding, un relay pudo identificar la subred, el cliente pudo elegir entre varias respuestas, el sistema operativo pudo instalar una ruta y el tráfico posterior pudo no ocurrir nunca. En IPv6, además, un Router Advertisement (RA) puede haber creado una dirección por Stateless Address Autoconfiguration (SLAAC) mientras DHCPv6 sólo entregó otros parámetros.

DHCP (Dynamic Host Configuration Protocol) es un mecanismo para entregar parámetros y, cuando la política lo permite, asignar direcciones o prefijos por un tiempo. No es por sí mismo autenticación de red, un registro universal de DNS ni prueba de que una lease esté en uso. Este capítulo construye el modelo que permite reconstruir esas diferencias: la máquina de estados de DHCPv4, los relays y sus campos, los temporizadores y opciones, la forma de DHCPv6 y su relación con RA/SLAAC, y los límites de controles como DHCP snooping.

Los ejemplos son sintéticos. Un paquete o una tabla sólo puede sostener lo que su punto de observación, su ventana temporal y su procedencia permiten afirmar.

Qué problema resuelve DHCP y qué no decide

Un cliente necesita más que una dirección. Para enviar un datagrama debe saber, al menos según su diseño, qué prefijo considera conectado, qué siguiente salto puede alcanzar, qué servidores DNS consultar y cuánto tiempo puede conservar ciertos parámetros. DHCP permite transportar esa configuración desde un servidor a un host y admite asignación automática, dinámica o manual. En la asignación dinámica, la dirección queda asociada a un cliente durante un periodo limitado y puede reutilizarse después; RFC 2131 llama binding a la colección de parámetros asociados al cliente. RFC 2131, §§1, 1.5 y 2.2

La palabra «asociada» es importante. Un binding es estado administrativo del servidor y una lease es una relación temporal de configuración; no es una medición continua de presencia. El cliente puede desconectarse, suspenderse, cambiar de interfaz o dejar de transmitir antes de que expire el tiempo. A la inversa, una tabla puede tardar en reflejar una pérdida, y una dirección estática puede no tener DHCP. Para afirmar uso actual hacen falta observaciones adicionales del host, de vecinos, de tráfico o de la aplicación.

DHCP también evita suponer que cada segmento tiene un servidor. El diseño admite un relay agent que pasa mensajes entre clientes y servidores; así, el broadcast inicial puede quedarse en la red local y el servidor puede atender varias subredes con contexto de relay. RFC 2131, §§1.5–1.6 La topología importa: un servidor puede ser legítimo para una VLAN y una respuesta idéntica puede ser incorrecta si aparece en otra.

DHCPv4: leer el mensaje antes de nombrar la transacción

Los campos correlacionan la transacción y el contexto; no prueban autenticidad ni uso posterior.

DHCPv4 conserva el formato general de BOOTP y añade opciones. El encabezado incluye op, htype, hlen, hops, xid, secs, flags, ciaddr, yiaddr, siaddr, giaddr y chaddr; el campo options transporta el tipo de mensaje y parámetros variables. La tabla de RFC 2131 distingue, por ejemplo, yiaddr —la dirección que el servidor propone al cliente— de siaddr —el siguiente servidor de bootstrap— y de giaddr —la dirección del relay—. RFC 2131, §2, Figura 1 y Tabla 1

xid es un identificador de transacción elegido por el cliente. Ayuda a asociar respuestas con una solicitud, pero no es una credencial. chaddr describe una dirección de hardware en el mensaje BOOTP/DHCP; la opción client identifier puede ser otro identificador opaco y debe mantenerse constante en los mensajes de esa interacción si el cliente la usa. Ninguno de los dos demuestra por sí solo quién controla físicamente el puerto, quién está autorizado o qué proceso generó el paquete.

El campo flags puede pedir que una respuesta se emita como broadcast cuando el cliente aún no puede recibir unicast. secs indica el tiempo transcurrido desde el inicio del proceso que el cliente está ejecutando. hops está disponible para relays. Leer esos campos con el punto de captura y el enlace evita atribuir al servidor una decisión que pudo tomar el relay o el cliente.

Las opciones añaden semántica sin convertir el mensaje en una política universal. La opción 53 identifica el tipo de mensaje; la 50 puede indicar la dirección solicitada; la 54 identifica al servidor para seleccionar una oferta; la 51 lleva el tiempo de lease. RFC 2132 define también la máscara de subred (opción 1), una lista de routers (3), servidores DNS (6) y el nombre de dominio (15). RFC 2132, §§3.3, 3.5, 3.8, 3.15 y 9.1–9.6

La lista de routers no debe confundirse con una autorización de salida. Es información que el cliente puede usar al construir su configuración; la decisión efectiva depende del sistema operativo y de su política. Para rutas más específicas existe la opción de rutas estáticas sin clase de RFC 3442, con semántica distinta de la opción de routers de RFC 2132. RFC 3442, §§3–5 Del mismo modo, una opción DNS entrega direcciones de servidores disponibles; RFC 2131 indica que DHCP no define por sí mismo el registro del cliente en DNS. RFC 2131, §1.3

DORA como atajo, no como máquina de cuatro paquetes

DORA es un atajo pedagógico; retransmisiones, NAK y renovaciones requieren el estado observado.

Para una asignación nueva, el recorrido conocido como DORA resume cuatro tipos de mensaje:

1. DHCPDISCOVER: el cliente busca servidores, normalmente mediante broadcast local cuando aún no tiene una dirección utilizable.
2. DHCPOFFER: cada servidor que decide responder ofrece parámetros y, cuando corresponde, una dirección.
3. DHCPREQUEST: el cliente indica qué oferta elige, incluyendo el server identifier y la dirección solicitada en el caso de SELECTING.
4. DHCPACK: el servidor confirma los parámetros y la lease, y el cliente entra en BOUND.

La abreviatura es útil para reconstruir la intención, pero no promete cuatro paquetes exactos. Puede haber pérdida y retransmisión, varias ofertas, un DHCPNAK, un cliente que usa INIT-REBOOT para verificar una dirección previa, un DHCPINFORM para pedir parámetros con dirección configurada o un DHCPDECLINE si detecta un conflicto. Un cliente también puede recibir un ACK distinto del que esperaba y descartarlo por xid u otras condiciones. RFC 2131 describe transacciones de asignación, reutilización y la tabla de mensajes por estado en §§3.1–3.2 y 4.4. RFC 2131, §§3.1–3.2 y 4.4

La máquina de estados es la explicación más fiable:

• INIT: el cliente no tiene parámetros utilizables y empieza una adquisición.
• SELECTING: ha recibido una o más ofertas y decide cuál solicitar.
• REQUESTING: solicita la oferta seleccionada; un NAK lo devuelve a una inicialización.
• INIT-REBOOT: tras reiniciar, puede intentar confirmar parámetros obtenidos antes, sin seleccionar de nuevo una oferta.
• BOUND: usa los parámetros dentro de su validez y programa los temporizadores.
• RENEWING: al alcanzar T1, contacta al servidor que concedió la lease para extenderla.
• REBINDING: al alcanzar T2 sin respuesta suficiente, intenta renovar con cualquier servidor disponible.
• EXPIRED: al terminar el tiempo válido sin renovación, deja de usar la dirección y vuelve a iniciar.

En SELECTING, el DHCPREQUEST anuncia implícitamente a los demás servidores que la oferta elegida ganó: incluye el identificador del servidor y la dirección solicitada. En RENEWING, el mensaje puede ser unicast y no necesita relay; en REBINDING, el cliente elimina el identificador del servidor concreto y usa el mecanismo de difusión previsto para encontrar otro servidor. RFC 2131, §4.4.1

Ejemplo verificable de DORA

Supongamos una cliente sintético con xid=0x4a22b1c0 en 10.40.0.0/24. D1 ofrece 10.40.0.57, lease de 3600 s y server identifier=10.200.0.10; D2 ofrece 10.40.0.88. El cliente elige D1 y envía:

DHCPREQUEST
xid:                 0x4a22b1c0
server identifier:   10.200.0.10
requested IP:        10.40.0.57
parameter request:   subnet mask, router, DNS

La observación permite afirmar que el cliente pidió esa oferta en esa transacción. Todavía no prueba que D1 haya respondido con ACK, que el host instalara la ruta, que 10.40.0.57 esté libre para otro uso o que una aplicación haya transmitido. El siguiente dato discriminante es el DHCPACK correlacionado por xid, seguido por la configuración efectiva y, si la pregunta es disponibilidad, por tráfico de prueba autorizado.

Relay, giaddr y selección de servidor

Un broadcast IPv4 no cruza un router por defecto. El relay recibe el mensaje en la interfaz del cliente, incrementa el campo hops al reenviarlo y lo entrega al servidor. giaddr comunica al servidor qué interfaz o subred del relay atendió la solicitud. El servidor usa ese contexto para escoger el pool y los parámetros adecuados; la respuesta se entrega de vuelta por el relay. La server identifier de una oferta identifica qué servidor la emitió y se usa para la selección posterior. RFC 2131, §§4.1, 4.3.1–4.3.2 y 4.4.1

Esto explica dos errores frecuentes. Primero, giaddr no es «la IP del servidor» ni prueba que el relay sea un router por defecto para el cliente. Segundo, una captura en el enlace servidor–relay no es la misma evidencia que una captura en la VLAN del cliente: la dirección IP de transporte, la difusión y el campo de enlace pueden cambiar según el tramo. Para atribuir una respuesta al segmento correcto hay que conservar giaddr, interfaz/VLAN, xid, server identifier, reloj y dirección del flujo.

El relay no autentica automáticamente el contenido que reenvía. Puede ser un punto de decisión y observabilidad —por ejemplo, aplicar una política o añadir información de circuito en una implementación—, pero la seguridad de esa decisión depende de su configuración, del enlace entre relay y servidor y de los controles aguas arriba. RFC 2131 describe el comportamiento de relay; no convierte el campo giaddr en una prueba criptográfica de procedencia.

Leases, T1/T2 y el tiempo que no demuestra presencia

Una lease tiene un tiempo de validez y dos hitos de renovación. RFC 2131 define T1 como el momento en que el cliente intenta renovar con el servidor que concedió la dirección y T2 como el momento en que, si no ha podido renovar, intenta rebind con cualquier servidor disponible. Si el servidor no especifica esos valores, los valores por defecto documentados son aproximadamente 0.5 y 0.875 de la duración de la lease; el servidor puede configurar otros valores. RFC 2131, §4.4.5 y Figura 5; RFC 2132, §9.2

Con una lease de 3600 s, los valores por defecto orientativos serían T1=1800 s y T2=3150 s. El cálculo ilustra el modelo, no certifica que una implementación concreta use esos valores: el ACK y la opción de lease deben observarse. En T1, el DHCPREQUEST puede ir al servidor que concedió el binding. En T2, el cliente quita server identifier y busca cualquier servidor que pueda extender la dirección. Al expirar la lease, el cliente debe dejar de usar esa dirección y reiniciar la adquisición.

DHCPRELEASE puede informar al servidor de que el cliente deja de usar la dirección, pero RFC 2131 señala que la operación correcta no depende de que el RELEASE llegue. RFC 2131, §4.4.6 Por eso un registro de lease sin RELEASE no prueba abandono, y un RELEASE observado no demuestra que ningún paquete posterior haya salido por otra interfaz o con otra configuración.

Un control positivo de renovación debe comprobar el mensaje en T1, la identidad del servidor y el ACK que extiende el tiempo. Un control negativo puede aislar temporalmente al cliente después del ACK y comparar la tabla de bindings con tráfico posterior: la lease puede seguir visible mientras no existe uso actual. La prueba no debe convertir un contador de servidor en una presencia continua.

Opciones: parámetros que cambian la decisión del host

Una opción no es automáticamente una política de enforcement. El host puede aceptar, rechazar o combinar parámetros según su implementación y configuración. Para leer un artefacto DHCPv4 conviene separar cuatro preguntas:

Desliza horizontalmente para consultar todas las columnas.

La diferencia entre máscara, router y rutas específicas es operacional. La máscara altera la decisión local/remota; el router propone un siguiente salto; una ruta sin clase puede crear una excepción más específica. Un host con opciones coherentes puede aun así tener una tabla de rutas distinta por una configuración manual, otra interfaz, una VPN o una política local. La observación de una opción es una evidencia de configuración ofrecida, no una fotografía completa del estado de forwarding.

DHCPv6: otra forma de descubrir y mantener estado

Son mecanismos relacionados pero no equivalentes: RA comunica el router por defecto.

DHCPv6 utiliza IPv6 y UDP, con clientes y servidores que operan mediante mensajes definidos en RFC 8415. RFC 8415, §7 El intercambio de asignación más común es:

1. Solicit: el cliente busca servidores y solicita opciones, una o más Identity Associations (IA) o prefijos.
2. Advertise: un servidor ofrece parámetros y recursos disponibles.
3. Request: el cliente selecciona un servidor mediante su Server Identifier y solicita los recursos anunciados.
4. Reply: el servidor confirma parámetros, direcciones o prefijos y lifetimes.

No se trata de DORA con nombres nuevos. RFC 8415 permite Rapid Commit, donde Solicit y Reply forman un intercambio directo, y define Renew, Rebind, Confirm, Release, Decline e Information-request para estados y objetivos distintos. RFC 8415, §§5.1–5.3, 18.2 y 19

DUID, IAID e IA

El DUID (DHCP Unique Identifier) identifica al cliente o servidor en la lógica DHCPv6. RFC 8415 define tipos como DUID-LLT, DUID-EN, DUID-LL y DUID-UUID, con requisitos de persistencia que dependen del tipo. El IAID (Identity Association Identifier) distingue una asociación dentro del cliente. Un cliente puede tener una IA_NA para direcciones no temporales, una IA_TA para direcciones temporales o una IA_PD para prefijos delegados. RFC 8415, §§11–12

El DUID no es una firma ni una prueba de que el mensaje venga del dispositivo cuya etiqueta contiene. Es un identificador de protocolo que ayuda al servidor a localizar bindings y políticas. Un IAID tampoco equivale a una interfaz física universal: su relación con interfaces y asociaciones la define el modelo del cliente. El análisis debe conservar DUID, IAID, transaction-id, Server Identifier y relay context como piezas de correlación, no como autenticación.

En una IA_NA, el servidor puede devolver direcciones y valores T1/T2; en IA_PD, puede devolver prefijos y sus lifetimes. Las opciones y temporizadores se describen en §§21.4 y 21.21; el comportamiento del cliente al enviar Renew y Rebind está en §§18.2.4–18.2.5. T1 indica cuándo renovar con el servidor que otorgó la asociación; T2, cuándo rebind con cualquier servidor. RFC 8415, §§18.2.4–18.2.5, 21.4 y 21.21 Al igual que en DHCPv4, una IA vigente no prueba que haya tráfico actual.

Relay-forward y selección del enlace

DHCPv6 no usa giaddr. Un relay encapsula el mensaje del cliente en Relay-forward, incluye una dirección de enlace que permite al servidor identificar el vínculo atendido y puede añadir Interface-Id. El servidor responde con Relay-reply, que el relay entrega al cliente. En relays encadenados, cada relay encapsula el mensaje recibido e incrementa hop-count, conservando o añadiendo el contexto de relay definido por el protocolo. RFC 8415, §19.1

La diferencia de campos no es cosmética. En IPv4, el servidor selecciona un pool a partir de giaddr; en IPv6, debe razonar con link-address, Interface-Id, DUID, IA y la topología de relays. Un Relay-forward capturado en el servidor puede contener el mensaje interior del cliente, pero no ofrece por sí solo una prueba de que el relay sea confiable o de que la respuesta recorriera todos los switches previstos.

RA, SLAAC y DHCPv6: colaboración, no sustitución automática

IPv6 configura más de una pieza mediante RA. RFC 4861 define el Router Advertisement, su Router Lifetime, prefijos y flags. Un lifetime positivo permite al host considerar a ese router candidato a router por defecto; DHCPv6 no es el campo que comunica esa lista. RFC 4861, §4.2

RFC 4861 describe en el RA la flag M (Managed address configuration) como indicación de que hay direcciones disponibles mediante DHCPv6 y la flag O (Other configuration) como indicación de que hay otra información disponible, por ejemplo DNS. Si M está activa, O es redundante en el modelo de la RFC. Estas son señales del protocolo; no son un contrato de que todos los sistemas operativos, versiones, perfiles de red o políticas harán exactamente la misma consulta. RFC 4861, §4.2

SLAAC obtiene prefijos y lifetimes desde las opciones de información de prefijo del RA y forma direcciones; DAD (Duplicate Address Detection) intenta detectar duplicados antes de asignarlas. RFC 4862 permite que SLAAC y DHCPv6 se utilicen simultáneamente y señala que un servicio DHCPv6 puede existir incluso si no se reciben RA. Sin RA, sin embargo, la especificación no proporciona por esa vía la dirección del router por defecto; tendría que existir configuración adicional. RFC 4862, §§5.5.1–5.5.6

Un ejemplo evita sobreprometer:

RA: prefix 2001:db8:40::/64, A=1, Router Lifetime=1800 s, M=0, O=1
Resultado esperado del modelo:
  - SLAAC puede formar una dirección y ejecutar DAD.
  - el RA proporciona candidato a router por defecto.
  - DHCPv6 puede consultarse por otra información.
  - no se deduce que DHCPv6 asignó la dirección ni que O obligue a cada host.

En otra red, M=1 puede anunciar direcciones disponibles vía DHCPv6 mientras el RA sigue siendo el mecanismo que comunica el router por defecto. Un host puede usar dirección SLAAC y parámetros DHCPv6; la palabra «stateful» describe el origen administrativo de parte de la configuración, no una frontera de seguridad.

Conflictos, rogue server y starvation bajo precondiciones

RFC 2131 advierte que un servidor DHCP no autorizado puede entregar direcciones duplicadas, rutas o DNS incorrectos, y que un cliente malicioso puede reclamar recursos dinámicos para impedir que otros los obtengan. RFC 2131, §7 RFC 8415 actualiza el contexto para DHCPv6: la falta de cifrado end-to-end permite interceptación, manipulación y escucha; también describe rogue servers, mensajes Reconfigure maliciosos y agotamiento de direcciones, prefijos, CPU o ancho de banda. RFC 8415, §22

La palabra «puede» exige condiciones. Un rogue server necesita llegar al segmento o al camino de relay donde sus respuestas son aceptadas, o aprovechar un relay mal configurado. Una starvation necesita que el servidor admita suficientes solicitudes nuevas, que el pool sea compartido y que no existan límites o políticas que reduzcan la tasa. Un conflicto puede ser un error de configuración, una VM restaurada, una dirección estática superpuesta, un servidor duplicado o una respuesta maliciosa. Sin correlacionar topología, xid/DUID, tiempos, pool, logs y estado del host, no se puede atribuir intención.

Un conflicto tampoco prueba que la lease original estuviera en uso. Detección de dirección duplicada, ARP, Neighbor Discovery, tabla del servidor y tráfico pueden observar capas distintas. La hipótesis «rogue server» gana apoyo si aparece una respuesta desde un puerto no autorizado con opciones divergentes y clientes afectados; pierde fuerza si la respuesta legítima y el cambio de inventario explican el evento. La ausencia de una respuesta en una captura puede significar filtro, relay no observado, pérdida o una ventana mal elegida.

Snooping y observabilidad: el control tiene un mapa

DHCP snooping suele describirse como un filtro que permite mensajes de servidor sólo desde puertos confiables y usa mensajes observados para construir asociaciones entre puerto, VLAN, dirección y binding. El nombre no sustituye la topología. La efectividad depende de que el dispositivo vea el puerto de acceso correcto, de que el trunk y la VLAN estén cubiertos, de que el relay esté en el camino y de que las excepciones estén documentadas.

RFC 7610 formaliza DHCPv6-Shield como filtrado en capa 2 de mensajes de servidor DHCPv6: el administrador configura los puertos permitidos y el dispositivo descarta mensajes de servidor recibidos en otros puertos. También advierte que, en una cadena de switches, la protección debe cubrir los switches del dominio; el switch local puede depender de filtros aguas arriba. DHCPv6-Shield no protege por sí solo frente a Router Advertisements maliciosos ni frente a ataques contra el servidor. RFC 7610, §§1, 4–6

Por tanto, el claim profesional debe ser acotado: «En VLAN 40, durante T, el switch S-2 descartó mensajes DHCPv6 de servidor recibidos por puertos de acceso no confiables y registró N eventos». No equivale a «la red está protegida». Un control positivo debe hacer llegar una respuesta sintética por el puerto confiable y comprobar que el cliente la recibe; un control negativo debe hacerla llegar por un puerto no confiable y comprobar descarte, contador y log. Repetir en un trunk, una VLAN aislada y un relay diferente prueba cobertura. Los controles deben ejecutarse en un entorno autorizado.

La procedencia es parte de la evidencia. Una captura en el cliente muestra lo que esa interfaz recibió; una tabla de binding muestra lo que el switch cree haber aprendido; un log del servidor muestra su decisión; un tráfico posterior muestra, como máximo, que algo usó una configuración. Para correlacionarlos, conservar reloj, interfaz/VLAN, xid o transaction-id, giaddr o relay context, DUID/IAID cuando aplique, opciones, dirección observada, lease/lifetimes, estado del host y resultado de una prueba autorizada.

Límites y errores de lectura

«DORA siempre son cuatro mensajes». Es un resumen de una ruta frecuente, no la máquina de estados. Retransmisiones, múltiples ofertas, NAK, INIT-REBOOT y renovaciones cambian la secuencia.

«DHCP autentica al cliente y al servidor». DHCP base usa UDP/IP; RFC 2131 y RFC 8415 describen amenazas de falsificación, escucha y rogue servers. RFC 3118 define una opción de autenticación para un despliegue coordinado, no una autenticación automática presente en toda transacción.

«Una lease prueba que la IP está en uso». Sólo prueba un binding y sus tiempos según la evidencia disponible. El cliente puede estar desconectado, usar otra interfaz o haber dejado de transmitir.

«DHCPv6 entrega el gateway». El router por defecto proviene de Router Advertisement y su Router Lifetime. DHCPv6 puede entregar direcciones, prefijos y otros parámetros, pero no se debe atribuir a él la ruta por defecto base.

«M=1/O=1 obligan el comportamiento». Son indicaciones de RA; el perfil y la implementación del host importan. Además, SLAAC y DHCPv6 pueden coexistir.

«Snooping cubre la VLAN». Sólo cubre los puertos y caminos efectivamente configurados. Trunks, relays, VLANs, switches en cascada y RA requieren verificación separada.

«La opción DNS registra el host». La opción entrega servidores DNS disponibles. El registro dinámico es otra función, con otro estado y otra evidencia.

Caso completo: Aurora en dos familias de protocolo

Volvamos a C-17. En IPv4, la captura de la VLAN muestra DHCPDISCOVER y DHCPREQUEST con xid=0x4a22b1c0. La captura entre relay y servidores muestra giaddr=10.40.0.1; D1 responde con yiaddr=10.40.0.57 y server identifier=10.200.0.10; el ACK lleva lease de 3600 s y opciones de router y DNS. Estas observaciones sostienen que D1 ofreció y confirmó un binding para esa transacción y que el relay usó el contexto de VLAN 40. No sostienen que C-17 esté usando 10.40.0.57 en el instante del informe.

Treinta minutos después, T1 llega. El cliente envía un DHCPREQUEST a D1 y recibe DHCPACK: la lease se extiende. Si el enlace hacia D1 falla después y no llegan respuestas, T2 lleva al cliente a REBINDING; un DHCPACK de D2 podría extender el binding si la política de red lo permite. Si aparece un DHCPNAK, el cliente debe dejar de usar la configuración invalidada y reiniciar la adquisición. Un informe que diga «el DHCP falló» sin identificar estado, servidor, relay y temporizador pierde el mecanismo causal.

En IPv6, el RA de VLAN 40 anuncia 2001:db8:40::/64, A=1, Router Lifetime positivo, M=0 y O=1. C-17 puede formar 2001:db8:40::... por SLAAC y ejecutar DAD. Después puede enviar Information-request DHCPv6 para DNS u otras opciones, dependiendo de su perfil; la dirección y el router por defecto no proceden necesariamente del mismo intercambio. Si el servidor DHCPv6 responde con una IA_NA en otra política, esa asignación se correlaciona por DUID, IAID y transaction-id. Sólo una observación del estado efectivo del host puede decir qué parámetros instaló.

Un supuesto cambia el diagnóstico: un equipo no autorizado conectado al puerto de acceso responde antes que D1, ofrece 10.40.0.1 como router y un DNS distinto. Si S-2 registra el paquete en un puerto no confiable y lo descarta, el control negativo de snooping gana apoyo. Si la VLAN permite un trunk no cubierto, el mismo control local no basta. En IPv6, aunque DHCPv6-Shield descarte la respuesta rogue, un RA rogue requiere un control de RA separado. La defensa no debe confundirse con la causa ni con una garantía de todos los caminos.

Transferencia profesional: del artefacto al claim

Ante «varios equipos pierden salida después de cambiar el servidor DHCP», redacta primero cuatro capas:

1. Observación: qué mensajes, opciones, relays, DUID/IAID, lifetimes, puertos, VLAN y logs se vieron.
2. Inferencia: qué estado es compatible —oferta equivocada, NAK, lease expirada, pool agotado, relay incorrecto, RA ausente o ruta no instalada—.
3. Impacto observado: qué clientes no obtuvieron ACK, qué hosts instalaron una dirección, qué consultas o conexiones fallaron en una ventana concreta.
4. Fuera de alcance: qué no se vio —uso actual, tráfico de aplicación, otra VLAN, otro relay, mensajes filtrados, política del host—.

Un claim defendible sería: «En VLAN 40, entre 10:00 y 10:05, S-2 observó DHCPACK de D2 para 18 xid y el relay conservó giaddr=10.40.0.1; ocho clientes instalaron una dirección según su estado local; no se demostró que esas direcciones se usaran en tráfico de aplicación ni que la ruta de VLAN 50 compartiera la misma falla». La frase puede ampliarse cuando una prueba positiva y una negativa conecten el ACK con configuración efectiva y tráfico.

El retest debe conservar una variable a la vez: repetir con un cliente autorizado en VLAN 40, luego en VLAN 50; comparar oferta y ACK de cada servidor; detener la prueba si aparece un activo no previsto; comprobar T1/T2 sin esperar a una expiración riesgosa; y revisar que el filtro de snooping no bloquee al relay legítimo. Para IPv6, repetir con RA que cambie sólo M/O y observar dirección, ruta por defecto, consulta DHCPv6 y DAD por separado. Si la conectividad vuelve, aún queda abierta la pregunta de por qué el primer camino falló si no se preservaron mensajes, estado y tiempos.

Síntesis

DHCP convierte una interfaz sin configuración en un conjunto temporal de parámetros mediante mensajes, estado y decisiones de servidor, relay y cliente. En DHCPv4, DORA resume una asignación nueva, pero la comprensión profesional exige la máquina de estados, xid, giaddr, server identifier, opciones, bindings y T1/T2. En DHCPv6, Solicit/Advertise/Request/Reply convive con Rapid Commit y con otros intercambios; DUID e IAID correlacionan identidades de protocolo y asociaciones sin convertirse en autenticación.

En IPv6, RA comunica routers por defecto, prefijos y las indicaciones M/O; SLAAC, DAD y DHCPv6 pueden colaborar. Una dirección, un ACK, una IA o una lease no certifican por sí solos uso actual, identidad o autorización. Rogue servers, conflictos y starvation dependen de topología, recursos y controles. Snooping y DHCPv6-Shield pueden filtrar mensajes desde puertos no confiables, pero sólo en el mapa que realmente cubren y sin sustituir el control de RA ni la seguridad del relay/servidor.

La pregunta útil no es «¿qué IP dio DHCP?», sino: ¿qué componente decidió, qué mensaje y estado lo demuestran, qué configuración efectiva quedó instalada, qué tráfico posterior la usa y qué caminos o tiempos no se observaron? Esa cadena permite distinguir norma, implementación, práctica e inferencia sin convertir una lease o una abreviatura en una certeza que el protocolo no ofrece.

Problema de transferencia

Un informe afirma: «El servidor DHCP autorizó a todos los portátiles porque entregó leases correctas; los equipos IPv6 tienen gateway porque M=1; el switch está protegido porque DHCP snooping está activado». Reescribe la conclusión separando DHCPv4, DHCPv6, RA y control de capa 2. Incluye una secuencia de observaciones que discrimine: (a) un relay con giaddr incorrecto, (b) una oferta rogue más rápida, (c) starvation del pool, (d) una lease vigente pero sin uso, (e) un RA sin ruta por defecto y (f) un trunk no cubierto por snooping. Para cada hipótesis formula un control positivo, uno negativo y un límite que seguiría siendo cierto aunque el cliente recuperase conectividad.

Fuentes principales

• R. Droms, RFC 2131: Dynamic Host Configuration Protocol, §§1–4.4 y 7, 1997. Norma base de DHCPv4, estados, relays, leases y seguridad.
• S. Alexander y R. Droms, RFC 2132: DHCP Options and BOOTP Vendor Extensions, §§3 y 9, 1997. Opciones de tipo de mensaje, máscara, routers, DNS y lease.
• T. Lemon et al., RFC 8415: DHCP for IPv6, §§5–6, 11–12, 18–22, 2018. Intercambios, DUID/IAID, relays, lifetimes y seguridad de DHCPv6.
• T. Narten et al., RFC 4861: Neighbor Discovery for IPv6, §4.2, 2007; y S. Thomson et al., RFC 4862: IPv6 Stateless Address Autoconfiguration, §§5.5–5.6, 2007. RA, Router Lifetime, M/O, SLAAC y DAD.
• F. Gont et al., RFC 7610: DHCPv6-Shield, §§1 y 4–6, 2015. Filtrado de mensajes de servidor por puertos y límites de cobertura.