Die erste Vergabe: DORA

Vor dem ersten Paket: Was der Client schon weiß

Der neue Büro-PC kennt seine Netzwerkschnittstelle und deren MAC-Adresse, hier 02:00:00:00:10:21. Er weiß noch nicht, welche IPv4-Adresse er verwenden darf, wie groß sein Subnetz ist oder welcher DHCP-Server zuständig ist. Dieses Startproblem nennt man Bootstrap: Ein System muss Informationen bekommen, die es für seine normale Kommunikation erst noch benötigt.

DHCP löst das mit besonderen Adressen. 0.0.0.0 dient beim Start als noch nicht konfigurierte IPv4-Quelle. 255.255.255.255 ist ein Limited Broadcast, also eine Nachricht an das lokale Netz. Im Ethernet wird sie an ff:ff:ff:ff:ff:ff gesendet. Ein Switch verteilt diesen Rahmen innerhalb des VLANs. Ein gewöhnlicher Router leitet den Limited Broadcast nicht einfach in andere Subnetze weiter; dafür braucht es einen DHCP-Relay.

Für den ersten Durchgang verwenden wir eine vereinfachte Nordlicht-Labortopologie: Client und DHCP-Server 192.168.10.10 liegen beide in .10.0/24. Das Gateway ist .10.1, der erreichbare DNS-Server .20.10. Der Client setzt das Broadcast-Flag, damit Antworten lokal als Broadcast ankommen. Diese ausdrückliche Annahme erklärt die Paketadressen in der Schrittansicht; anschließend übertragen wir den Ablauf auf den zentralen Server mit Relay.

1 · DISCOVER: Eine Transaktion beginnen

Der Client sendet DHCPDISCOVER von UDP-Port 68 an Serverport 67. UDP transportiert einzelne Nachrichten ohne vorherigen Verbindungsaufbau. DHCP selbst muss deshalb verlorene Nachrichten erkennen und gegebenenfalls wiederholen. Der Client erzeugt eine Transaktionskennung, xid genannt, damit er Antworten seinem laufenden Vorgang zuordnen kann. Im Beispiel lautet sie 0x4a31b902. Eine xid ist eine Zuordnungshilfe, kein Passwort und kein Authentizitätsnachweis.

Im DHCP-Inhalt steht ciaddr, die bereits verwendete Clientadresse, noch auf 0.0.0.0. chaddr trägt hier die Hardwareadresse. Option 53 mit Wert 1 bezeichnet DHCPDISCOVER. Eine Option ist ein zusätzliches, durch eine Nummer beschriebenes Datenfeld. Option 55, die Parameter Request List, kann etwa Maske, Router, DNS und Domain anfordern. Eine Client-Identifier-Option 61 kann zusätzlich die Identität ausdrücken, die der Server für die Zuordnung verwendet.

Auch eine gewünschte frühere Adresse kann als Option 50 enthalten sein. Das ist ein Wunsch, keine bereits erlaubte Nutzung. Im hier gezeigten erstmaligen Bezug lassen wir Option 50 bewusst weg. Der Client wechselt von INIT, also ohne verwendbare Konfiguration, in SELECTING und wartet auf geeignete Angebote. Nicht jeder sichtbare Server muss antworten: Zuständigkeit, freie Adressen und Verwaltungsregeln können eine Antwort verhindern.

2 · OFFER: Was der Server anbietet

Der Server bestimmt zunächst den passenden Bereich, dann eine geeignete Adresse innerhalb seiner Vergaberegeln. Bestehende Bindungen, Reservierungen, Ausschlüsse und freie Kapazität spielen dabei eine Rolle. Im Beispiel bietet er 192.168.10.120 an. Diese Adresse steht im Feld yiaddr: „your IP address“, also die dem Client angebotene Adresse. Sie ist nicht die IP-Quelladresse des Servers und auch nicht die Gatewayoption.

Option 53 trägt jetzt Wert 2 für DHCPOFFER. Option 54 nennt den Anbieter 192.168.10.10. Option 51 bietet eine Lease von 28.800 Sekunden, also acht Stunden. Dazu kommen im Beispiel Maske /24, Router .10.1 und DNS .20.10. Der Server übernimmt die Transaktionskennung der Anfrage, damit der Client das Angebot zuordnen kann. Ein Angebot ist jedoch noch kein abgeschlossener Bezug. Der Client kann weitere Angebote sammeln und eines davon auswählen.

In unserer Ansicht wird das OFFER wegen des gesetzten Broadcast-Flags von .10.10:67 an 255.255.255.255:68 geschickt. Andere Clients sehen diesen Broadcast ebenfalls, dürfen ihn aber nicht als eigene Konfiguration übernehmen. xid und Clientbezug helfen bei der Zuordnung. Ohne erforderliche Broadcastzustellung ist auch Unicast an die angebotene Adresse und Hardwareadresse möglich. „OFFER ist immer Broadcast“ wäre deshalb fachlich zu eng.

3 · REQUEST: Die Auswahl öffentlich machen

Der Client entscheidet sich für ein Angebot und sendet DHCPREQUEST. Option 50 nennt nun ausdrücklich 192.168.10.120, Option 54 den ausgewählten Server 192.168.10.10. ciaddr bleibt null: Der Client hat diese Adresse noch nicht als gültige Konfiguration übernommen. Die gewünschte Adresse steht an dieser Stelle in einer Option, nicht als bereits verwendete Quelladresse. Auch yiaddr bleibt im REQUEST null; dieses Feld füllt hier der antwortende Server.

Der REQUEST zur Angebotsauswahl wird als Broadcast gesendet. Das ist sinnvoll, obwohl der ausgewählte Server nun bekannt ist: Andere Anbieter erfahren damit ebenfalls, welches Angebot angenommen wurde, und können ihre nicht ausgewählten Angebote verwerfen. Ein zweiter Server mit Kennung .10.11 erkennt an Option 54, dass er nicht gemeint ist. Er soll den gültigen Auswahlvorgang nicht einfach mit einem konkurrierenden ACK überschreiben.

Die Auswahlstrategie ist Sache der Clientimplementierung. Das erste eintreffende OFFER kann gewählt werden, muss aber nicht immer gewinnen. Ein Mitschnitt beweist die Auswahl deshalb am REQUEST, nicht allein an der Reihenfolge der Angebote. Nach dem Senden befindet sich der Client in REQUESTING und wartet auf die Entscheidung des ausgewählten Servers. Ohne Bestätigung ist die Konfiguration noch nicht fertig.

4 · ACK: Bestätigen, prüfen, verwenden

Der gewählte Server prüft die Anfrage und bestätigt die Zuordnung mit DHCPACK, Option 53 gleich 5. Im ACK stehen die zu verwendende Adresse und die tatsächlich bestätigten Parameter. Der Client darf nicht einfach unterstellen, dass jeder zuvor angeforderte Parameter enthalten ist. Die Parameter Request List ist eine Wunschliste, keine Garantie. Für die spätere Diagnose zählt deshalb das ACK zusammen mit dem tatsächlich aktiven Clientzustand.

Im Beispiel bestätigt der Server .10.120, Maske 255.255.255.0, Gateway .10.1, DNS .20.10 und acht Stunden Lease. T1 und T2 können als Optionen 58 und 59 übermittelt werden; hier sind es 14.400 und 25.200 Sekunden. Ohne abweichende Vorgabe entsprechen diese Werte den üblichen Anteilen von 50 und 87,5 Prozent. Die genaue zeitliche Berechnung und spätere Erneuerung werden in F05 behandelt.

Vor der normalen Verwendung soll der Client die Parameter und einen möglichen Adresskonflikt prüfen. ARP kann dabei helfen festzustellen, ob ein anderes Gerät die Adresse bereits beansprucht. Erkennt der Client einen Konflikt, darf er die Adresse nicht einfach benutzen: Er meldet DHCPDECLINE und beginnt nach entsprechender Wartezeit neu. Ohne Konflikt geht er in BOUND über und kann die bestätigte Konfiguration verwenden. ACK bedeutet also nicht automatisch, dass DNS, Routing und jede Anwendung bereits erfolgreich getestet wurden.

Die Felder im direkten Vergleich

Lies die folgende Tabelle immer als einen konkreten Erstbezug ohne Relay und mit gewünschter Broadcastzustellung. Im Relayfall ändern sich Transportwege und giaddr. Bei einer Erneuerung ändern sich unter anderem ciaddr, Zieladresse und die Verwendung der Optionen 50 und 54. Das Grundformat bleibt ähnlich, die Bedeutung entsteht aus dem Zustand.

Was sich mit einem Relay ändert

Im größeren Nordlicht-Netz steht der DHCP-Server auf 192.168.20.10. Der Client startet weiterhin mit einem lokalen Broadcast im Büro. Der Relay auf 192.168.10.1 nimmt ihn entgegen, setzt im gewöhnlichen Relayfall giaddr auf die Adresse des Clientlinks und leitet die Anfrage an den Server weiter. Zwischen Relay und Server verwendet dieser klassische Austausch UDP 67 auf beiden Seiten.

Der Server erkennt anhand der Herkunftsinformation, dass eine Adresse aus .10.0/24 benötigt wird. Seine eigene Adresse .20.10 wäre kein Grund, dem Büro-PC eine .20er-Adresse zu geben. Die Antwort geht zunächst zum Relay und von dort zurück auf den Clientlink. In einem Capture neben dem Server siehst du deshalb andere äußere IP-Adressen als neben dem Client. Die vier fachlichen Schritte bleiben erkennbar, obwohl jeder Schritt mehrere Übertragungsabschnitte besitzt.

Wenn der Ablauf unterbrochen wird

Fehlt ein OFFER, prüfe zuerst, ob das DISCOVER den zuständigen Server überhaupt erreicht. Ist es dort sichtbar, untersuche Scopeauswahl, freien Bestand und Verwaltungsregeln. Verlässt ein OFFER den Server, kommt aber nicht beim Client an, liegt der nächste Messpunkt auf dem Rückweg. Aus „kein OFFER am PC“ allein folgt noch nicht „DHCP-Dienst kaputt“.

Fehlt nach dem REQUEST eine Bestätigung, kann eine Nachricht verloren gegangen sein. Der Client wiederholt nach seinen Timern. Für den anfänglichen Bezug beschreibt RFC 2131 einen zufällig verteilten exponentiellen Backoff, also wachsende Warteabstände mit Zufallsanteil. Das verhindert, dass viele gleichzeitig gestartete Clients immer wieder im selben Takt senden. Die konkreten Zeitabstände eines Betriebssystems werden am echten Mitschnitt geprüft, nicht aus der Vier-Schritte-Abkürzung abgeleitet.

DHCPNAK ist etwas anderes als Schweigen: Der Server erklärt die angefragte Nutzung ausdrücklich für unzulässig, etwa bei einer unpassenden gespeicherten Adresse. DHCPDECLINE kommt dagegen vom Client nach erkanntem Konflikt. Die Richtung und der Nachrichtentyp zeigen deshalb, welche Art von Fehler untersucht werden muss. Einen Timeout als NAK zu beschreiben würde diese wichtige Unterscheidung verlieren.

Warum eine Verlängerung nicht wieder DORA ist

Ein Client mit gültiger Lease besitzt bereits eine nutzbare Adresse und kennt den bisherigen Server. Bei T1 sendet er normalerweise einen direkten DHCPREQUEST zur Erneuerung. ciaddr enthält nun seine aktive Adresse; Optionen 50 und 54 werden in diesem REQUEST nicht verwendet. Ein passendes ACK bestätigt die neue Gültigkeit. DISCOVER und OFFER sind dafür nicht erforderlich.

Bleibt die Antwort bis T2 aus, fragt der Client im REBINDING per Broadcast verfügbare Server. Erst wenn keine Verlängerung gelingt und die Lease abläuft, darf er die alte Adresse nicht weiterverwenden. Ein Neustart mit gespeicherter Adresse kann wiederum einen eigenen Bestätigungsweg über INIT-REBOOT nehmen. DORA erklärt den vollständigen ersten Bezug; das Zustandsmodell in F04 erklärt, warum der laufende Betrieb mehr Wege besitzt.