Zusammenfassung

  • Bei der normalen Vergabe bestätigt DHCPACK die Bindung im Server; erst nach der letzten Konfliktprüfung wechselt der Client zu BOUND. Gewährt wird zeitlich begrenzte Nutzung, kein Eigentum.
  • T1 führt zur Erneuerung beim ursprünglichen Server, T2 öffnet das Rebinding für andere Server. Läuft der Lease ohne neues ACK ab, muss der Client die Nutzung beenden und zu INIT zurückkehren.
  • Ein DHCPACK als Antwort auf DHCPINFORM vergibt überhaupt keine Adresse. Der Nachrichtentyp allein belegt daher nicht, welcher Vorgang stattgefunden hat.

Wenn Zuteilung wie Besitz aussieht

Ein Gerät betritt das Netz ohne brauchbare IPv4-Konfiguration. Es sucht Server, erhält Angebote, fordert eines an und bekommt DHCPACK. Kurz darauf steht die Adresse am Interface, Anwendungen kommunizieren und Protokolle ordnen Aktivität diesem Wert zu. Aus Anwendersicht hat das Netz die Adresse „gegeben“.

RFC 2131 beschreibt stattdessen eine Bindung zwischen Client und Konfigurationsparametern. Der gewählte Server schreibt sie fest. Bevor der Client die Adresse verwendet, prüft er trotzdem ein letztes Mal, ob sie auf dem lokalen Link belegt ist. Bei einem Konflikt sendet er DHCPDECLINE und beginnt neu. Das positive Urteil der zentralen Datenbank verdrängt also keine gegenteilige Beobachtung am Medium.

Ralph Droms ist der Autor von RFC 2131. Sein IETF-Profil vermerkt außerdem, dass er 1989 die Arbeitsgruppe organisierte, die DHCP entwarf. Präzise ist damit seine zentrale Rolle bei der Standardisierung eines dynamischen Dialogs mit Zuständen und Fristen. Nicht präzise wäre es, jede spätere Erweiterung, Implementierung und Betriebsentscheidung ihm allein zuzuschreiben.

Zur Erlaubnis gehört die Uhr

Der Client darf eine Adresse oder Dauer vorschlagen, erwirbt dadurch aber keinen Anspruch. Der Server wendet die Richtlinie seiner Domäne an. DHCPACK übermittelt die Konfiguration, die er tatsächlich akzeptiert, mitsamt der zeitlichen Reichweite.

Bei T1, normalerweise nach der Hälfte des Lease, geht der Client in RENEWING und richtet DHCPREQUEST an den ursprünglichen Server. Bleibt das erfolglos, folgt T2 üblicherweise nach sieben Achteln. In REBINDING können andere erreichbare Server antworten. Beide Zeitpunkte sind relativ; der Server darf abweichende Werte mitteilen.

Der Ablauf bildet eine harte Grenze. Ohne verlängerndes DHCPACK muss der Client die Netzwerkverarbeitung mit dieser Adresse sofort einstellen, sie aufgeben und nach INIT zurückkehren. Danach kann sie anderweitig vergeben werden. Ein Verfahren, das das Ende erlaubter Nutzung ausdrücklich bestimmt, überträgt kein dauerhaftes Eigentum.

Auch unendlich ist keine Urkunde

RFC 2132 erlaubt im IP Address Lease Time eine Folge aus lauter Einsen als unendlichen Lease. Für den Betrieb ist das erheblich: Lange oder unendliche Laufzeiten schaffen Kontinuität, reduzieren Erneuerungen und können statisch wirken. Während eines gültigen Lease ist DHCPACK zudem eine echte Autorisierung durch den Konfigurationsdienst.

„Unendlich“ sagt hier, dass kein planmäßiger Ablaufzeitpunkt gesetzt ist. Der Wert authentisiert weder den Menschen am Gerät noch begründet er Rechte gegenüber anderen Netzen oder hindert Administratoren an Änderungen. Eigentum wäre eine zusätzliche rechtliche und identitätsbezogene Aussage, die das Optionsfeld nicht trifft.

RFC 5227 bewahrt eine unabhängige Grenze. Ein Host sondiert vor der IPv4-Nutzung den Link und reagiert auf einen gefundenen Konflikt. Diese Prüfung ersetzt den DHCP-Server nicht. Sie zeigt aber, dass dessen Lease-Datenbank keine unfehlbare Beschreibung des Mediums ist. Erlaubnis der Steuerungsebene und beobachtete Verfügbarkeit gehören zusammen.

Eine Bestätigung ohne Adressvergabe

DHCPINFORM liefert den deutlichsten Gegenbeweis zur Deutung nach Nachrichtennamen. Ein bereits anderweitig konfigurierter Client kann zusätzliche lokale Parameter anfordern. Der Server antwortet mit DHCPACK, vergibt dabei aber keine Adresse, prüft keine Bindung, lässt yiaddr leer und fügt keine Lease-Dauer hinzu.

Derselbe Nachrichtentyp begleitet damit unterschiedliche Handlungen. Im Vergabeautomaten kann er eine Bindung festschreiben; bei INFORM liefert er nur Konfiguration. Ein Inventarsystem, das jedes beobachtete DHCPACK als Zuweisungsbeleg behandelt, erzeugt aus einer bequemen Regel falsche Provenienz.

RFC 6842 verbessert die Zuordnung von Antworten. In den festgelegten Fällen gibt der Server die Client-Kennung in DHCPOFFER und DHCPACK zurück. Das hilft, eine Nachricht ihrem Austausch zuzuordnen. Die technische Kennung authentisiert jedoch keinen Menschen und wird nicht zum Eigentumsnachweis.

Wofür die Serveransicht maßgeblich ist

Leasequery in RFC 4388 macht die Sicht des Servers sichtbar. Er kann eine Adresse als ACTIVE, UNASSIGNED oder UNKNOWN melden und für einen aktiven Lease die Restdauer nennen. Die Abfrage liest den Zustand, ohne die Bindung zu ändern. Maßgeblich ist die Antwort für diese Lease-Datenbank, nicht zwingend für sämtliche Geräte, Pakete und Konflikte im Segment.

In einer Untersuchung sind Adresszuweisung und Handlungszuordnung getrennte Behauptungen. Der Verlauf kann belegen, dass ein Dienst einer Client-Kennung während eines Intervalls die Nutzung gestattete. Allein beweist er nicht, welcher Mensch das Gerät bediente, ob jeder Verkehr von ihm stammte oder ob die Zuordnung außerhalb des Intervalls gilt.

Das schwächt DHCP als Beweismittel nicht. Vollständige Historie, Kennungen, Relay-Daten, Beobachtungen der Sicherungsschicht, Konflikte und synchronisierte Uhren ergeben gemeinsam ein stärkeres Bild. Problematisch ist nur, einem DHCPACK Fragen außerhalb seines Entwurfs zu stellen.

Quellen