Zusammenfassung

  • Ein dynamischer DHCPv4-Lease kennt drei entscheidende Grenzen: T1 startet RENEWING beim verleihenden Server, T2 startet das per Broadcast erreichbare REBINDING, und der Ablauf beendet die Adressnutzung, wenn kein DHCPACK eine neue Frist geschaffen hat.
  • Rebinding erweitert den Wiederherstellungsweg, nicht die Autorität beliebiger erreichbarer Server. Ein Ersatzserver darf nur mit lokaler administrativer Zuständigkeit verlängern; funktionierender Datenverkehr kann die Frist nicht ersetzen.

Ein funktionsfähiger Anschluss war noch kein unbefristetes Recht

Kurz vor T1 sieht ein Nutzer womöglich keinen Fehler. Bestehende Verbindungen laufen, der Router antwortet, und die Netzwerkschnittstelle bleibt aktiv. Dennoch hat im Hintergrund eine andere Phase begonnen: Der Client muss klären, ob seine Konfiguration weiter gelten darf.

DHCP behandelt diese Klärung nicht während der gesamten Laufzeit gleich. Zuerst zählt die Nähe zum ursprünglichen Entscheider. Später zählt die Chance, einen anderen zuständigen Entscheider zu erreichen. Am Ende zählt die zeitliche Grenze stärker als jede lokale Beobachtung.

Das gewöhnliche Wort „automatische Verlängerung“ verdeckt diesen Wechsel. Der Client wiederholt nicht nur Pakete. Er verändert schrittweise, wen er um Fortsetzung bittet, ohne sich selbst eine Fortsetzung ausstellen zu können.

Dynamische Vergabe brauchte widerrufbare Bindungen

RFC 1541 beschrieb im Oktober 1993 die dynamische DHCP-Vergabe als Zuweisung einer Adresse für einen begrenzten Zeitraum oder bis zur ausdrücklichen Freigabe. Die von DHCP-Servern verwaltete Zuordnung von Client, Adresse und weiteren Konfigurationswerten hieß Binding.

Damit wurde serielle Wiederverwendung möglich. Ein begrenzter IPv4-Bestand konnte nacheinander verschiedene Clients versorgen, weil eine frühere Zuweisung nicht als dauerhafter Besitz galt.

Der im März 1997 erschienene RFC 2131 behielt automatische, dynamische und manuelle Vergabe bei. Eine automatische Vergabe kann dauerhaft sein; eine manuelle übermittelt die Entscheidung eines Administrators. Bei der dynamischen Vergabe bestimmen dagegen Lease-Uhr und Wiedererlangungszustände, wie lange die Konfiguration trägt.

Die Adresse ist daher kein einmal übergebenes Gut. Sie ist Bestandteil einer zeitlich begrenzten, unter lokaler Richtlinie geführten Konfigurationsentscheidung.

Ein Lease trug drei voneinander getrennte Zeiten

RFC 2132 ordnet Option 51 der Adress-Lease-Dauer, Option 58 der Renewal Time T1 und Option 59 der Rebinding Time T2 zu. Alle drei sind Intervalle in Sekunden seit der Zuweisung und keine Kalenderzeitpunkte.

Fehlen gültige Werte für T1 und T2, setzt RFC 2131 die Vorgaben auf die Hälfte beziehungsweise sieben Achtel der Lease-Dauer. Eine kleine zufällige Abweichung soll verhindern, dass ganze Client-Gruppen gleichzeitig anfragen. Diese Bruchteile sind Protokoll-Fallbacks, keine allgemeingültige Betriebsempfehlung.

Die Reihenfolge transportiert eine Richtlinie. Vor T1 bleibt viel Zeit für den ursprünglichen Server. Nach T2 bleibt noch eine begrenzte Rettungsphase mit breiterem Adressatenkreis. Das Lease-Ende ist keine weitere Erinnerungsmarke, sondern das Ende des aktuellen Bindings.

T1 gab dem Verleiher den ersten Zugriff

Ein Client im Zustand BOUND wechselt bei T1 in RENEWING. Kennt er die Adresse des verleihenden Servers, sendet er dorthin DHCPREQUEST und trägt seine aktuelle Adresse in ciaddr ein. Er sammelt keine frischen Angebote, sondern bittet um Fortführung einer bestehenden Entscheidung.

Diese Präferenz bewahrt Zuständigkeit. Der ursprüngliche Server kennt das von ihm angelegte Binding, die Pool-Regeln und mögliche Änderungen, die eine Verlängerung begleiten sollen. Er kann mit DHCPACK eine neue Frist vergeben, Parameter ändern oder die Verlängerung nach administrativer Richtlinie verweigern.

Eine ausbleibende Sofortantwort hebt das alte Recht nicht auf. Solange der Lease läuft, darf der Client die Adresse nutzen und mit Blick auf die verbleibende Zeit begrenzt erneut anfragen. So führt ein kurzer Fehler im Kontrollpfad nicht sofort zum Ausfall des Datenpfads. Die Uhr hält dadurch aber nicht an.

T2 machte die Anfrage hörbarer, nicht jeden Hörer zuständig

Ist bis T2 kein DHCPACK eingetroffen, wechselt der Client in REBINDING. Er sendet DHCPREQUEST per Broadcast, belässt die genutzte Adresse in ciaddr und lässt den Server Identifier weg. Nun können andere Server eine Anfrage hören, die den ursprünglichen womöglich nie erreicht.

Aus Empfang folgt jedoch keine Befugnis. RFC 2131 erlaubt einem anderen Server die Verlängerung nur, wenn er lokale administrative Autorität besitzt. Mehrere Server an einem Standort benötigen also konsistenten Lease-Zustand und eine gemeinsame betriebliche Zuständigkeit.

Darin liegt das Zentrum von Rebinding. DHCP erweitert den Kreis möglicher Helfer, weil Verfügbarkeit wichtig ist, erhebt Erreichbarkeit aber nicht zur Delegation. Hält ein alternativer Server einen veralteten Stand, kann er eine noch gebundene Adresse für frei halten. Der Broadcast legt den Widerspruch offen; er löst ihn nicht.

ACK, NAK und Schweigen waren drei verschiedene Urteile

Ein DHCPACK in RENEWING oder REBINDING schafft Fortsetzung. Der Client speichert die zurückgegebenen Lease- und Konfigurationswerte und startet neue T1- und T2-Timer. Eine Verlängerung kann also mehr ändern als nur die Dauer.

DHCPNAK erklärt die aktuelle Konfiguration für unzulässig. Der Client muss ihre Nutzung beenden und zur Initialisierung zurückkehren. Sendet er nach einer solchen Ablehnung weiter, wird sein lokaler Erinnerungsstand zu einer konkurrierenden Adressbehauptung.

Schweigen ist innerhalb der gültigen Frist weder ACK noch NAK. Das bestehende Lease bleibt maßgeblich, während der Client begrenzt wiederholt. Läuft es aber ohne ACK ab, verlangt RFC 2131 den Wechsel zu INIT, das Ende sonstiger Netzwerkverarbeitung und eine neue Konfigurationsanfrage wie von einem unkonfigurierten Client.

Der Switch-Port kann weiterhin Link anzeigen. Nachbar-Caches können antworten, und ein Router kann Pakete noch weiterleiten. Diese Beobachtungen belegen nur einen funktionsfähigen lokalen Datenpfad. Sie erteilen keine neue Adressbefugnis.

Eine gespeicherte Adresse blieb nach einem Neustart ein Antrag

Nach dem Neustart kann ein Client seine vorige Adresse kennen und glauben, im selben Netz zu sein. INIT-REBOOT erlaubt ihm, diese Adresse anzufragen. Aus der Erinnerung wird aber kein gegenwärtiges Recht.

Die Anfrage wird als Broadcast versandt, weil weder der alte Server noch das alte Netz sicher relevant sind. Ein Server kann sie mit DHCPACK bestätigen oder mit DHCPNAK verwerfen. Bleibt jeder Kontakt aus, gestattet RFC 2131 die vorige Konfiguration nur für den noch nicht abgelaufenen Teil des ursprünglichen Lease.

„Gleiche Adresse nach dem Start“ ist damit ein überprüftes Ergebnis. DHCP schützt sinnvolle Kontinuität, leitet gegenwärtige Autorität jedoch nicht aus einem Wert ab, den der interessierte Client selbst gespeichert hat.

FORCERENEW konnte die Prüfung vorziehen

Die ursprüngliche Zustandsmaschine wurde vor allem von Client-Timern bewegt. RFC 3203 führte später das Unicast-Signal FORCERENEW ein. Ein Server kann damit vor T1 den normalen RENEW-Ablauf anstoßen, etwa wenn eine Konfiguration zeitnah geändert werden soll.

FORCERENEW schreibt selbst keine Konfiguration. Es veranlasst ein gewöhnliches DHCPREQUEST. Soll der Client die Adresse aufgeben, kann der Server auf diese Anfrage mit DHCPNAK antworten und ihn zur Discovery zurückführen.

Ein gefälschtes Signal könnte laufende Sitzungen wiederholt unterbrechen. RFC 3203 fordert deshalb eine FORCERENEW-Authentisierung nach RFC 3118. Auch eine vorgezogene Neubewertung braucht nachweisbare Herkunft und einen kontrollierten Zustandswechsel.

Ein gültiges Lease bewies keinen konfliktfreien Link

Selbst ein echtes DHCPACK kann nicht nachweisen, dass kein anderer Host dieselbe Adresse im lokalen Netz verwendet. Die Autorität eines Konfigurationsdienstes und die Beobachtung am Link liefern unterschiedliche Beweise.

RFC 5227 verlangt, dass ein IPv4-Host eine neu konfigurierte Adresse prüft, bevor er sie nutzt. Erkennt ein DHCP-Client einen Konflikt, sendet er DHCPDECLINE. Die Planung des Servers trifft dann auf widersprechende lokale Evidenz und muss neu bewertet werden.

Ein Lease belegt daher nur, dass ein verwalteter Dienst einem Client eine Adresse für ein Zeitfenster zugeordnet hat. Es authentisiert keine Person, beweist kein rechtliches Eigentum, garantiert keine Ende-zu-Ende-Erreichbarkeit und schließt eine doppelte Nutzung nicht aus.

Quellen und Grenzen der Evidenz

Die historischen und protokollbezogenen Aussagen beruhen auf RFC 1541, RFC 2131, RFC 2132, RFC 3118, RFC 3203 und RFC 5227:

Sie definieren einen DHCPv4-Vertrag. Sie belegen weder aktuelle Standardwerte noch Failover-Architektur, Client-Korrektheit oder Verbreitung eines benannten Produkts oder Netzes. DHCPv6 ist ein anderes Protokoll. Auch die Standardbruchteile für T1 und T2 beweisen nicht, dass jeder Server sie sendet oder jeder Client sie verwendet.