DORA-Prozess: Discover, Offer, Request, Acknowledge

Der DORA-Prozess ist der vierstufige Handshake zwischen DHCP-Client und DHCP-Server. Das Akronym steht für Discover, Offer, Request, Acknowledge – die vier Nachrichten, die bei jeder erstmaligen IP-Adressvergabe ausgetauscht werden. Versteht man DORA, versteht man DHCP im Kern.

Ein wichtiges Detail vorab: Die ersten beiden Nachrichten (Discover und Offer) laufen als Broadcasts – das Gerät kennt noch keine IP-Adresse und kann daher keine gezielte Unicast-Anfrage stellen. Der Client verwendet als Absenderadresse 0.0.0.0 (keine IP bekannt) und sendet an 255.255.255.255 (alle Geräte im Segment). Erst nach dem Acknowledge kommuniziert das Gerät mit seiner zugewiesenen IP. Dieses Broadcastverhalten erklärt auch, warum DHCP ohne einen DHCP-Relay-Agent nur innerhalb eines Subnetzes funktioniert – Broadcasts werden von Routern nicht weitergeleitet. Der Prozess arbeitet auf OSI-Schicht 7 über UDP.

1) Die vier DORA-Schritte – animiert

Die folgende Animation zeigt den vollständigen DORA-Prozess. Zu beachten: Schritt 1 und 3 gehen vom Client aus, Schritt 2 und 4 vom Server. Broadcast-Nachrichten erreichen alle Geräte im Segment, aber nur der DHCP-Server reagiert auf sie.

DORA-Prozess – Discover · Offer · Request · Acknowledge

💻

DHCP-Client

0.0.0.0

⇌

🖥

DHCP-Server

192.168.1.1

1. D Discover – Client sendet Broadcast: „Gibt es einen DHCP-Server? Ich brauche eine IP!" (Src: 0.0.0.0, Dst: 255.255.255.255) –

2. O Offer – Server antwortet (Broadcast): „Ich biete dir 192.168.1.42 an, Lease 86400s, Gateway .1, DNS .10" –

3. R Request – Client sendet Broadcast: „Ich nehme das Angebot von Server 192.168.1.1 an und fordere 192.168.1.42" –

4. A Acknowledge – Server bestätigt: „192.168.1.42 ist für 86400s für dich reserviert!" Client übernimmt Konfiguration. –

Drücke „DORA starten" für die Animation.

Der Request-Broadcast in Schritt 3 scheint redundant – der Client könnte doch direkt mit dem Server sprechen. Der Grund: Im Netz könnten mehrere DHCP-Server Offers geschickt haben. Der Broadcast-Request informiert alle anderen Server: „Ich habe Angebot X gewählt, ihr könnt eure Angebote zurückziehen." Das verhindert, dass mehrere Server dieselbe Adresse blockieren.

2) Paketinhalte im Detail

Jede DORA-Nachricht enthält spezifische Felder. Besonders wichtig ist die Transaction-ID – eine zufällige Zahl, die Client und Server in allen vier Nachrichten einbauen, um den Austausch eindeutig zuzuordnen. Außerdem trägt jede Nachricht die MAC-Adresse des Clients, damit der Server die Kommunikation einem physischen Gerät zuordnen kann.

Paketinhalte der DORA-Nachrichten

Die Transaction-ID (xid) verbindet alle vier Pakete: Client wählt eine zufällige Zahl beim Discover, Server trägt dieselbe xid in Offer und Ack ein. So kann ein Client mit mehreren gleichzeitigen DHCP-Anfragen (z.B. WLAN und LAN) die Antworten den richtigen Anfragen zuordnen.

3) Lease-Erneuerung: kein voller DORA nötig
Nach der erstmaligen Zuweisung muss der Client die Lease-Zeit regelmäßig verlängern. Dafür sind nicht alle vier DORA-Schritte nötig – Client und Server kennen sich bereits. Die Erneuerung erfolgt mit nur zwei Nachrichten direkt (Unicast, kein Broadcast).

Zeitpunkt Aktion Nachrichten

50% der Lease-Zeit Client versucht Erneuerung beim selben Server (Unicast) DHCPREQUEST → DHCPACK

87,5% der Lease-Zeit Rebinding: Client versucht Erneuerung bei beliebigem Server (Broadcast) DHCPREQUEST (Broadcast) → DHCPACK

100% der Lease-Zeit Lease abgelaufen: Client verliert IP, startet neuen DORA-Prozess Voller DORA

DORA-Prozess: Discover, Offer, Request, Acknowledge

1) Die vier DORA-Schritte – animiert

2) Paketinhalte im Detail

Anmelden

Account Registrieren und Fortschritt Speichern!

Modal title