Perché la trasmissione viene utilizzata nel passaggio DHCPREQUEST?

Questo è il processo DHCPoperativo,

La mia domanda è al terzo passaggio perché il client invia una trasmissione e non un Unicast poiché dopo le due precedenti operazioni l'indirizzo del server DHCP / server di inoltro dovrebbe essere noto?

dhcp

— Maometto
fonte

Qualche risposta ti è stata d'aiuto? In tal caso, dovresti accettare la risposta in modo che la domanda non continui a comparire per sempre, cercando una risposta. In alternativa, potresti fornire e accettare la tua risposta.

— Ron Maupin

Risposte:

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

I server ricevono la trasmissione DHCPREQUEST dal client. I server non selezionati dal messaggio DHCPREQUEST utilizzano il messaggio come notifica che il client ha rifiutato l'offerta del server.

Il protocollo presuppone che possano essere presenti più server DHCP. Trasmettendo il messaggio di richiesta, tutti i server che potrebbero aver emesso un'offerta possono essere consapevoli della scelta del cliente.

— Boomi
fonte

È possibile disporre potenzialmente di più server DHCP: la richiesta viene inviata come trasmissione per notificare agli altri server DHCP che hanno potenzialmente inviato offerte che la loro offerta non viene accettata.

— Zac67
fonte

Perché fino a quando il server non invia DHCPACK, il client non ha ancora un indirizzo IP. È possibile che un server DHCP risponda a una richiesta con un DHCPNACK.

— YImparare
fonte

Perché ciò implicherebbe la necessità di utilizzare la trasmissione? Il client conosce l'indirizzo MAC del server dal messaggio DHCPOFFER, quindi potrebbe inviare unicast DHCPREQUEST a quel server - non è necessario un indirizzo IP perché ciò avvenga.

— psmears

@psmears, perché le trasmissioni L3 vengono inviate come trasmissioni L2. DHCP non è un protocollo L2, quindi sei vincolato alle regole poiché i dati vengono passati da L3 a L2.

— YLearn

@YLearn: è necessario anche un IP di origine e di destinazione per un pacchetto multicast o broadcast L3, quindi questo non è chiaramente il problema :) Non esiste alcun motivo teorico per cui il pacchetto DHCPREQUEST non possa essere inviato con l'IP e MAC di destinazione del server e (come nel pacchetto di trasmissione) un IP sorgente di 0.0.0.0. Il motivo della trasmissione è far sapere agli altri server DHCP (se presenti) che il client sta rifiutando le loro offerte.

— psmears

@psmears, la destinazione di una trasmissione L3 è 255.255.255.255. È possibile generare una trasmissione L3 da 0.0.0.0. Tuttavia, non è possibile generare un unicast L3 da 0.0.0.0.

— YLearn

@YLearn: puoi certamente inviare un pacchetto con i byte per l'indirizzo sorgente impostato su zero! Ciò potrebbe essere vietato da alcuni RFC - ne conosci uno? RFC1700 afferma che 0.0.0.0 "può essere usato solo come indirizzo sorgente" (ma nulla sull'unicast / broadcast); RFC1122 dice 0.0.0.0 "NON DEVE essere inviato, tranne come indirizzo sorgente come parte di una procedura di inizializzazione mediante la quale l'host apprende il proprio indirizzo IP" (di nuovo, nessuna restrizione uni / broadcast). Questo è obbligatorio da qualche altra parte?

— psmears