Mensajes DHCP

Mensajes DHCP

de Juan Carlos Sosa Gómez -
Número de respuestas: 5

Buenas, que tal?

Cuando en la consola de pc1 ejecuto dicho comando de la imagen, me sale que la secuencia de mensajes es
DHCP discover, luego hace DHCP request, luego recibe un DHCP offer y por ultimo un DHCP ack.
Pero según en el teórico, el orden es discover, offer, request y ack.

Es más en los pcap el servidor envía un offer de manera unicast al host, según entiendo cuando sucede esto es porque el host le sugirió una IP y el servidor se la aceptó, pero en el mensaje discover no hay ningún campo "Requested IP address". Es decir que para que el servidor envíe por unicast a esa IP, primero ocurrió el request antes que el offer.

Espero que me puedan aclarar el orden de estos mensajes. Gracias.


En respuesta a Juan Carlos Sosa Gómez

Re: Mensajes DHCP

de Eugenio Andres Lacuesta Pessina -
Nosotros vemos lo mismo en la terminal del PC, pero si inspeccionas los paquetes el orden es como dice en el teórico:

En respuesta a Eugenio Andres Lacuesta Pessina

Re: Mensajes DHCP

de Jorge Visca -
En DHCP está permitido a un cliente "solicitar" una IP sin que se la ofrezcan, por ejemplo para intentar usar una que le fue asignada anteriormente.

RFC2131 :

4.3.2 DHCPREQUEST message

   A DHCPREQUEST message may come from a client responding to a
   DHCPOFFER message from a server, from a client verifying a previously
   allocated IP address or from a client extending the lease on a
   network address.  If the DHCPREQUEST message contains a 'server
   identifier' option, the message is in response to a DHCPOFFER
   message.  Otherwise, the message is a request to verify or extend an
   existing lease.



En respuesta a Jorge Visca

Re: Mensajes DHCP

de Juan Carlos Sosa Gómez -
Como muestran los compañeros, el offer lo hace unicast a una dirección que no fue asignada todavía, como sucede eso? puede ser que sea por la dirección MAC del cliente?
En respuesta a Juan Carlos Sosa Gómez

Re: Mensajes DHCP

de Jorge Visca -
Efectivamente, como el cliente no tiene aún una IP asignada, sólo va a mirar que la dirección MAC destino del OFFER sea la correcta (para el). La dirección IP del paquete OFFER no le importa al cliente.
Sin embargo, el paquete debe tener una dirección IP destino. El servidor usualmente no pone IP de broadcast porque el offer no es para todos, así que poner IP broadcast no sería adecuado (ya es unicast en capa 2). Entonces tiene que poner una IP "real" como destino IP, y pone la que está ofreciendo. Tiene la ventaja de que sabe que no es de nadie más, por eso la está ofreciendo.
Resumiendo, como manda datagramas UDP que corren sobre IP para configurar IP antes de que IP esté funcional, hace cosas "extrañas". Del RFC 2131:

Normally, DHCP servers and BOOTP relay agents attempt to deliver
   DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
   uicast delivery.  The IP destination address (in the IP header) is
   set to the DHCP 'yiaddr' address and the link-layer destination
   address is set to the DHCP 'chaddr' address.  Unfortunately, some
   client implementations are unable to receive such unicast IP
   datagrams until the implementation has been configured with a valid
   IP address (leading to a deadlock in which the client's IP address
   cannot be delivered until the client has been configured with an IP
   address).