Das lernst du
- Alle acht zentralen Nachrichtentypen ihrem Auslöser zuordnen.
- REQUEST anhand von Zustand und Optionen interpretieren.
Voraussetzungen: G09 · Die erste Vergabe: DORAF01 · Transport und Erreichbarkeit
Der Name DHCPREQUEST allein verrät nicht, ob der Client gerade ein Angebot auswählt, eine bekannte Adresse nach einem Neustart bestätigt oder eine laufende Lease verlängert.
Ein REQUEST, vier verschiedene Situationen
Grafik vergrößern
Nachrichten und Folgen
Option 53 bezeichnet den Nachrichtentyp. Die Interpretation benötigt zusätzlich ciaddr, gewünschte Adresse, Serverkennung und Adressierung. Ein BOOTP-op von 1 bedeutet Anfrage, nicht automatisch DHCPREQUEST; auch DISCOVER trägt op=1.
| Typ | Auslöser/Zweck | Folge |
|---|---|---|
| DISCOVER | Client sucht Konfiguration | Server können Angebote senden |
| OFFER | Server bietet Adresse und Optionen | Client wählt; noch kein Abschluss |
| REQUEST | Auswahl, Wiederbestätigung oder Erneuerung | ACK, gegebenenfalls NAK oder keine Antwort |
| ACK | Server bestätigt/übermittelt Parameter | Client übernimmt geeignete Parameter |
| NAK | Angefragte Nutzung ist nicht zulässig | Client verwirft die alte Konfiguration und beginnt neu |
| DECLINE | Client erkennt eine angebotene Adresse als konfliktbehaftet | Server behandelt sie als verdächtig/nicht verfügbar |
| RELEASE | Client gibt seine Adresse bewusst zurück | Server kann das Nutzungsrecht beenden |
| INFORM | Client hat bereits eine extern konfigurierte Adresse und fragt Optionen | ACK mit Optionen, keine neue dynamische Lease |
REQUEST ist zustandsabhängig
Bei Angebotsauswahl sind gewünschte Adresse (Option 50) und Serverkennung (54) enthalten, ciaddr bleibt null. Bei INIT-REBOOT fragt ein Client eine gespeicherte Adresse an, ohne bereits einen Server auszuwählen. Bei RENEWING enthält ciaddr die benutzte Adresse; normalerweise wird der bekannte Server direkt angesprochen.
Ein NAK ist kein allgemeines Signal für „Server langsam“. Es sagt, dass die angefragte Konfiguration nicht genutzt werden darf. Schweigen kann dagegen Erreichbarkeit, Zuständigkeit oder Serverpolitik bedeuten. RELEASE erhält üblicherweise kein ACK; fehlendes ACK auf RELEASE ist kein Fehlerbeweis.
REQUEST anhand seiner Felder beweisen
Bei SELECTING beziehungsweise dem Übergang nach REQUESTING benennt Option 54 den ausgewählten Server und Option 50 die gewünschte Adresse; ciaddr ist noch null. In INIT-REBOOT wird ebenfalls eine Adresse mit Option 50 angefragt, aber ohne Option 54. Der Client bittet um Prüfung einer gespeicherten Konfiguration und hat gerade kein neues Angebot ausgewählt. Diese fehlende Serverkennung ist also beabsichtigt, nicht automatisch ein defektes Paket.
Bei RENEWING und REBINDING steckt die bereits verwendete Adresse dagegen in ciaddr. Optionen 50 und 54 gehören in diesen REQUEST nicht hinein. RENEWING richtet die Anfrage an den bisherigen Server; REBINDING sendet sie als Broadcast. Wenn ein Analyzer in allen drei Fällen nur DHCPREQUEST anzeigt, musst du diese Felder selbst vergleichen. Nachrichtentyp, Adressierung und Zustand bilden gemeinsam den Beleg.
Negative Antworten und freiwillige Freigaben
DHCPNAK kommt vom Server und verwirft eine nicht zulässige angefragte Nutzung. DHCPDECLINE kommt vom Client und meldet einen erkannten Adresskonflikt. Beide unterbrechen einen normalen Vergabeweg, aber aus völlig unterschiedlichen Gründen. Bei einem DECLINE untersuchst du mögliche Doppelbelegung oder fehlerhafte Konfliktmeldungen; bei einem NAK zunächst angefragte Adresse, Netzzuordnung und Serverzuständigkeit.
DHCPINFORM zeigt noch eine weitere Grenze der DORA-Abkürzung: Ein Client mit extern konfigurierter Adresse kann zusätzliche Parameter anfordern. Das antwortende ACK ist dabei keine neue dynamische Adressvergabe. Deshalb ist auch „ACK im Capture“ ohne Zusammenhang keine ausreichende Aussage. Dokumentiere stets, auf welche Anfrage die Bestätigung antwortet und welche Felder sie tatsächlich enthält.
Drei Requests unterscheiden
- A: ciaddr=0, Option 50=.120, Option 54=.20.10. Das passt zu einer Angebotsauswahl nach OFFER.
- B: ciaddr=.120, keine Option 50/54, Ziel .20.10. Das passt zur Erneuerung einer aktiven Lease.
- C: ciaddr=0, Option 50=.120, keine Serverkennung, Broadcast nach Neustart. Das passt zu INIT-REBOOT/REBOOTING.
- Die zeitliche Umgebung prüfen: Ohne vorherige Pakete und Clientzustand bleibt die Einordnung eine begründete Hypothese.
Ergebnis: Nachrichtentyp und Kontext ergeben gemeinsam die Bedeutung. Eine reine DORA-Liste erklärt nicht den gesamten Betrieb.
Typische Fehler
- DHCPINFORM vergibt keine neue Adresse.
- BOOTP-op und DHCP-Option 53 sind verschiedene Felder.
- Ein NAK darf nicht wie ein unbestätigtes OFFER weiterverwendet werden.
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 2132 · DHCP-Optionen ↗Optionen 1, 3, 6, 15, 50–61; März 1997