¿Por qué se usa la transmisión en el paso DHCPREQUEST?

Este es el proceso de DHCPoperación,

Mi pregunta es en el tercer paso, ¿por qué el cliente envía una transmisión y no unidifusión ya que después de las dos operaciones anteriores se debe conocer la dirección del servidor DHCP / servidor de retransmisión?

dhcp

— Mahoma
fuente

¿Alguna respuesta te ayudó? Si es así, debe aceptar la respuesta para que la pregunta no siga apareciendo para siempre, buscando una respuesta. Alternativamente, puede proporcionar y aceptar su propia respuesta.

— Ron Maupin

Respuestas:

https://tools.ietf.org/html/rfc2131#page-13

Los servidores reciben la transmisión DHCPREQUEST del cliente. Los servidores no seleccionados por el mensaje DHCPREQUEST usan el mensaje como notificación de que el cliente ha rechazado la oferta de ese servidor.

El protocolo asume que puede haber múltiples servidores DHCP. Al transmitir el mensaje de solicitud, todos los servidores que pueden haber emitido una oferta pueden conocer la elección del cliente.

— boomi
fuente

Potencialmente, puede tener varios servidores DHCP: la solicitud se envía como difusión para notificar a los otros servidores DHCP que potencialmente han enviado ofertas de que su oferta no se ha tomado.

— Zac67
fuente

Porque hasta que el servidor envíe el DHCPACK, el cliente aún no tiene una dirección IP. Es posible que un servidor DHCP responda a una solicitud con un DHCPNACK.

— YLearn
fuente

¿Por qué eso implicaría que sería necesario utilizar la transmisión? El cliente conoce la dirección MAC del servidor del mensaje DHCPOFFER, por lo que podría enviar la unidifusión DHCPREQUEST a ese servidor; no es necesario que haya una dirección IP para que eso suceda.

— Psmears

@psmears, porque las transmisiones L3 se envían como transmisiones L2. DHCP no es un protocolo L2, por lo que está sujeto a reglas a medida que los datos pasan de L3 a L2.

— YLearn

@YLearn: También necesita una IP de origen y de destino para un paquete de multidifusión o transmisión L3, por lo que claramente ese no es el problema :) No hay una razón teórica por la cual el paquete DHCPREQUEST no pueda enviarse con la IP y MAC de destino del servidor y (como con el paquete de difusión) una IP de origen de 0.0.0.0. El motivo de la transmisión es informar a otros servidores DHCP (si los hay) que el cliente está rechazando sus ofertas.

— Psmears

@psmears, el destino de una transmisión L3 es 255.255.255.255. Puede obtener una transmisión L3 de 0.0.0.0. Sin embargo, no puede generar una unidifusión L3 desde 0.0.0.0.

— YLearn

@YLearn: ¡Sin duda puede enviar un paquete con los bytes para la dirección de origen establecida en cero! Sin embargo, eso puede estar prohibido por algunos RFC: ¿conoces uno? RFC1700 dice 0.0.0.0 "solo puede usarse como una dirección de origen" (pero nada sobre unidifusión / difusión); RFC1122 dice 0.0.0.0 "NO DEBE enviarse, excepto como una dirección de origen como parte de un procedimiento de inicialización mediante el cual el host aprende su propia dirección IP" (de nuevo, sin restricción de difusión / uni). ¿Es obligatorio en otro lugar?

— Psmears