Das lernst du
- Clientzustände aus mehreren Paketfeldern rekonstruieren.
- Broadcast-Flag, Wiederholungen und Konfliktprüfung korrekt begrenzen.
Voraussetzungen: F04 · Das Client-ZustandsmodellF05 · T1, T2 und Lease-AblaufE01 · Paketaufbau bis auf Byteebene
Ein Client kann vor Abschluss des Bezugs unter Umständen schon Unicastantworten empfangen, ein anderer benötigt Broadcast. Das Protokoll muss beide Bootstrap-Fähigkeiten berücksichtigen.
Welcher Zustellweg gewinnt?
Grafik vergrößern
Adressierung folgt Zustand und Fähigkeit
Beim Auswählen eines Angebots ist ciaddr null; gewünschte Adresse und Serverkennung stehen in Optionen. In RENEWING ist ciaddr gesetzt und der bisherige Server wird normalerweise unicast angesprochen. In REBINDING bleibt ciaddr gesetzt, die Anfrage wird aber broadcast gesendet.
Das Broadcast-Flag signalisiert bei bestimmten Antworten, ob der Client eine Broadcastzustellung benötigt. Es ist keine Anweisung, sämtliche Pakete immer als Broadcast zu senden. Bei giaddr ungleich null geht der Server zunächst an den Relay. Zustandskontext, giaddr, ciaddr und Flag werden gemeinsam ausgewertet.
Neustart, NAK und Wiederholungen
Ein Client mit gespeicherter Adresse kann in INIT-REBOOT um Bestätigung bitten. Ein NAK zwingt zum Verwerfen der ungeeigneten Konfiguration. Ein Timeout ist kein NAK: Bei fehlender Antwort muss der Client Wiederholungs- und Rückfallregeln anwenden. DHCP nutzt zeitlich verteilte Wiederholungen mit Zufallseinflüssen, um gleichzeitige Starts nicht dauerhaft zu synchronisieren.
Konflikterkennung kann ARP-Probes einsetzen. Erkennt der Client einen Konflikt, darf er die Adresse nicht einfach normal benutzen; ein DECLINE informiert den Server. Prüfungen haben Grenzen: ausgeschaltete Geräte, Filter und bösartige Antworten können die Beobachtung beeinflussen. Eine erfolgreiche Probe ist kein Ersatz für koordinierte Adressplanung.
Die Zustellentscheidung in der richtigen Reihenfolge lesen
Für OFFER und ACK ist zunächst eine gesetzte giaddr relevant: Die Antwort geht zum Relay. Ohne Relay kann eine gesetzte ciaddr den bereits konfigurierten Client adressieren. Sind beide null, werden Broadcast-Flag und die Fähigkeit zur frühen Unicastzustellung wichtig. Ein Client kann dabei ein IP-Paket an yiaddr auf seiner Hardwareadresse empfangen, bevor diese Adresse vollständig im normalen Betrieb eingerichtet ist. Genau diese Fähigkeit darf nicht bei jedem Client vorausgesetzt werden.
DHCPNAK verdient eine eigene Betrachtung. Bei einem lokalen Client wird es als Broadcast zugestellt, weil dessen bisherige Adresse oder Maske gerade unbrauchbar sein kann. Mit Relay sorgt der entsprechende Weg für die Broadcastauslieferung auf dem Clientnetz. Die einfache Aussage „Serverantworten sind immer Unicast“ verliert diese entscheidende Ausnahme.
Backoff, Konflikt und Neustart sind drei verschiedene Ursachen
Beim anfänglichen Bezug fordert RFC 2131 zufällig verteilte, exponentiell vergrößerte Wiederholungsabstände. Als Ethernet-Beispiel nennt der RFC zunächst etwa vier, dann acht Sekunden mit Zufallsanteil und einer Obergrenze für das Wachstum. Das ist von den Timern einer bereits gültigen Lease zu unterscheiden. Ähnliche Pakete im Capture können also normale Wiederholungen statt eines neuen Problems darstellen.
Ein erkannter Adresskonflikt führt dagegen zu DECLINE und einem neuen Bezug; der RFC empfiehlt vor diesem Neustart mindestens zehn Sekunden Wartezeit. Ein NAK verwirft die ungeeignete Konfiguration aus einem anderen Grund. Bei der Analyse müssen deshalb Zeitabstände, Nachrichtentypen und die vorherige Adressnutzung gemeinsam betrachtet werden. Eine reine Zählung von DISCOVER-Paketen erklärt die Ursache noch nicht.
Ein Mitschnitt nach einem Standortwechsel
- Der Laptop besitzt gespeichert .10.120, wird aber ins Gästenetz gesteckt. Er sendet nach Neustart REQUEST mit gewünschter alter Adresse und ohne ausgewählte Serverkennung.
- Ein zuständiger Server erkennt, dass die Adresse zum falschen Netz gehört, und kann NAK senden. Der Client verwirft sie und startet neu.
- Danach DISCOVER, geeignetes Angebot, REQUEST und ACK aus dem Gästenetz prüfen. Ein altes Gateway im aktiven Clientzustand wäre weiterhin fehlerhaft.
- Siehst du statt NAK nur wiederholte Anfragen, zunächst Erreichbarkeit und Zuständigkeit klären; Schweigen beweist keine negative Bestätigung.
Ergebnis: Zustandsrekonstruktion benötigt Ereignisfolge und Felder. DORA ist ein wichtiger Einstieg, aber kein vollständiger Automat.
Typische Fehler
- Broadcast-Flag und IP-Zieladresse sind nicht dasselbe Feld.
- Ein fehlender ARP-Widerspruch beweist keine dauerhaft konfliktfreie Planung.
- Ein NAK und eine ausbleibende Antwort erfordern unterschiedliche Interpretation.
Praktisch anwenden
Offizielle Quellen
Versionsbezüge geprüft am 14. Oktober 2026. Produktkonfigurationen werden im jeweiligen isolierten Labor validiert.
- RFC 2131 · DHCPv4 ↗Protokollbasis, insbesondere §§ 3 und 4; März 1997
- RFC 5227 · IPv4-Konflikterkennung ↗ARP-Probes und Konfliktbehandlung; Juli 2008