Warum wird Broadcast im Schritt DHCPREQUEST verwendet?

Dies ist der Vorgang DHCP,

Meine Frage ist im 3. Schritt, warum der Client einen Broadcast und keinen Unicast sendet, da nach den beiden vorherigen Vorgängen die Adresse des DHCP-Servers / Relay-Servers bekannt sein sollte.

dhcp

— Muhammad
quelle

Hat Ihnen eine Antwort geholfen? In diesem Fall sollten Sie die Antwort akzeptieren, damit die Frage nicht für immer auftaucht und nach einer Antwort sucht. Alternativ können Sie auch Ihre eigene Antwort eingeben und annehmen.

— Ron Maupin

Antworten:

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

Die Server empfangen die DHCPREQUEST-Übertragung vom Client. Die Server, die nicht in der DHCPREQUEST-Nachricht ausgewählt wurden, verwenden die Nachricht als Benachrichtigung, dass der Client das Angebot dieses Servers abgelehnt hat.

Das Protokoll geht davon aus, dass möglicherweise mehrere DHCP-Server vorhanden sind. Durch das Senden der Anforderungsnachricht können alle Server, die möglicherweise ein Angebot abgegeben haben, über die Wahl des Clients informiert werden.

— Boomi
quelle

Sie können möglicherweise über mehrere DHCP-Server verfügen. Die Anforderung wird als Broadcast gesendet, um die anderen DHCP-Server zu benachrichtigen, die möglicherweise Angebote gesendet haben, deren Angebot nicht angenommen wurde.

— Zac67
quelle

Denn bis der Server den DHCPACK sendet, hat der Client noch keine IP-Adresse. Ein DHCP-Server kann auf eine Anfrage mit einem DHCPNACK antworten.

— YLearn
quelle

Warum bedeutet dies, dass Broadcast verwendet werden muss? Der Client kennt die MAC-Adresse des Servers aus der DHCPOFFER-Nachricht, sodass der DHCPREQUEST-Unicast an diesen Server gesendet werden kann.

— Psmears

@psmears, da L3-Broadcasts als L2-Broadcasts gesendet werden. Da DHCP kein L2-Protokoll ist, sind Sie bei der Übergabe der Daten von L3 an L2 an Regeln gebunden.

— YLearn

@YLearn: Sie benötigen auch eine Quell- und Ziel-IP für ein L3-Multicast- oder Broadcast-Paket, das ist also eindeutig nicht das Problem :) Es gibt keinen theoretischen Grund, warum das DHCPREQUEST-Paket nicht mit der Ziel-IP und dem MAC des gesendet werden konnte Server und (wie beim Broadcast-Paket) eine Quell-IP von 0.0.0.0. Der Grund für die Übertragung ist, dass andere DHCP-Server (falls vorhanden) wissen, dass der Client ihre Angebote ablehnt.

— Psmears

@psmears, das Ziel einer L3-Sendung ist 255.255.255.255. Sie können eine L3-Sendung von 0.0.0.0 beziehen. Sie können jedoch keinen L3-Unicast von 0.0.0.0 beziehen.

— YLearn

@YLearn: Sie können durchaus ein Paket mit den Bytes für die auf Null gesetzte Quelladresse senden! Dies kann jedoch von einigen RFCs verboten werden - kennen Sie einen? RFC1700 sagt 0.0.0.0 "darf nur als Quelladresse verwendet werden" (aber nichts über Unicast / Broadcast); RFC1122 sagt 0.0.0.0 "DARF NICHT gesendet werden, außer als Quelladresse als Teil einer Initialisierungsprozedur, durch die der Host seine eigene IP-Adresse lernt" (wiederum keine Uni- / Broadcast-Einschränkung). Ist das woanders vorgeschrieben?

— Psmears