Ein neuer Rechner braucht mehr als eine Adresse.
Ein Laptop verbindet sich mit dem Heimnetz. Damit seine IPv4-Kommunikation funktioniert, benötigt er eine passende Adresse und Subnetzmaske. Für entfernte Netze braucht er einen Routerweg, meist ein Standardgateway. Für die Auflösung von Namen benötigt er passende DNS-Einstellungen. Das Dynamic Host Configuration Protocol (DHCP) kann diese Konfiguration automatisch bereitstellen.
Bei einer statischen Konfiguration trägst du die Werte am Gerät ein. Bei DHCP fragt der Client einen Server und erhält eine zeitlich geregelte Zuweisung. Dynamisch bedeutet nicht „bei jedem Start anders“. Ein Server kann dieselbe Adresse wieder zuteilen. DHCP selbst transportiert keine Webseiten und routet keine Nutzdaten. Ein Heimrouter übernimmt oft DHCP, DNS-Weiterleitung und Routing zugleich; fachlich sind das getrennte Funktionen.
Der folgende Ablauf behandelt DHCPv4. Die IPv4-Grundlagen erklären Adressen und Netzgrenzen. DNS löst anschließend Namen auf; Routing bestimmt Wege zwischen Netzen.
Der Server verwaltet einen passenden Adressvorrat.
Ein Scope bezeichnet in vielen Verwaltungsoberflächen die Einstellungen für ein Subnetz: Adressbereich, Ausschlüsse, Lease-Dauer und Optionen. Der genaue Produktbegriff kann abweichen. Der Pool enthält die Adressen, die der Server vergeben darf. Er ist kein zusätzliches Subnetz. Server und Administrator müssen verhindern, dass DHCP-Adressen mit fest eingetragenen Adressen kollidieren.
Unser Beispielnetz ist 192.168.10.0/24. Das Gateway hat 192.168.10.1, der Pool reicht von 192.168.10.100 bis 192.168.10.199. Das sind einschließlich beider Grenzen 100 mögliche Pooladressen. Die Netzadresse .0 und die Broadcastadresse .255 gehören nicht zu diesem Pool. Andere Adressen des Subnetzes bleiben für bewusst getrennt verwaltete Geräte verfügbar.
Der Laptop soll beispielsweise 192.168.10.120 erhalten. Der Server kann zusätzlich Subnetzmaske 255.255.255.0 (Option 1), Router 192.168.10.1 (Option 3), DNS-Server 192.168.10.1 (Option 6) und eine Lease-Dauer (Option 51) liefern. Gateway und DNS haben hier absichtlich denselben Wert, müssen aber weder dieselbe Adresse noch dasselbe Gerät sein. Ein falscher DNS-Wert kann Namensauflösung verhindern, obwohl lokale IP-Kommunikation funktioniert. Ein falsches Gateway kann entfernte Ziele unerreichbar machen.
DORA: Suchen, anbieten, auswählen, bestätigen.
Bei einer typischen erstmaligen DHCPv4-Zuweisung startet der Client ohne nutzbare IPv4-Konfiguration. Mit DHCPDISCOVER sucht er nach Servern. Ein Server bietet mit DHCPOFFER eine Adresse und Einstellungen an. Der Client wählt ein Angebot und teilt seine Auswahl in DHCPREQUEST mit. Der ausgewählte Server bestätigt die Zuweisung mit DHCPACK. Daraus entsteht die Merkhilfe DORA.
Discover verwendet im typischen Anfangszustand 0.0.0.0 als Quelladresse und 255.255.255.255 als Ziel. DHCPv4 nutzt UDP, mit Port 68 beim Client und Port 67 beim Server. Der auswählende Request wird ebenfalls als Broadcast gesendet und nennt den ausgewählten Server. So erfahren auch andere anbietende Server, dass ihre Angebote nicht gewählt wurden. Ein Offer allein macht die angebotene Adresse noch nicht zur bestätigten Clientkonfiguration.
Offer und ACK sind nicht immer Broadcasts: Ohne Relay hängen Zieladressierung und Zustellung unter anderem vom Broadcast-Flag und davon ab, ob der Client vor vollständiger Konfiguration direkte Antworten empfangen kann. Beim Relay läuft der Serverkontakt über den Vermittler. Die verkürzte Regel „Alle vier Nachrichten sind Broadcasts“ ist falsch. Auch ein Neustart mit bekannter früherer Lease muss nicht erneut die vollständige DORA-Folge auslösen.
Der Client prüft vor der Nutzung die Adresse auf Konflikte. Erkennt er eine bereits verwendete Adresse, meldet er dies mit DHCPDECLINE und beginnt die Konfiguration erneut. Eine DHCPNAK-Antwort weist dagegen eine unpassende Anfrage zurück; der Client muss seine Konfiguration neu beschaffen. Solche Abläufe sind in der Grundgrafik nicht eingezeichnet.
Die Lease läuft weiter, während der Rechner arbeitet.
Eine Lease ist eine zeitlich befristete Adresszuweisung. Bei der Erneuerung muss der Client keine neue Adresse verlangen. Er bittet darum, seine bisherige weiter nutzen zu dürfen. Zwei Zeitpunkte strukturieren diesen Vorgang: T1 startet die Erneuerung beim bisherigen Server, T2 das Rebinding bei einem erreichbaren zuständigen Server.
Ohne andere Servervorgaben liegt T1 bei 50 Prozent und T2 bei 87,5 Prozent der Lease-Dauer. Bei einer achtstündigen Lease sind das vier und sieben Stunden. Zum T1 sendet der konfigurierte Client DHCPREQUEST als Unicast zum bisherigen Server. Bleibt die Verlängerung aus, wechselt er bei T2 zum Rebinding und sendet DHCPREQUEST als Broadcast. Ein passender Server kann mit ACK verlängern. Der Client darf bis zum Ablauf seiner noch gültigen Lease grundsätzlich weiterarbeiten.
Läuft die Lease ohne Verlängerung ab, darf der Client die zugewiesene Adresse nicht weiter benutzen und muss erneut nach Konfiguration suchen. T1 und T2 sind deshalb keine Zeitpunkte, an denen die Adresse automatisch wechselt. Die hier verwendeten Prozentwerte sind Standardwerte, keine für alle Netze fest vorgeschriebenen Zeitpläne.
Relay und Reservierung lösen unterschiedliche Probleme.
Router leiten den lokalen Initial-Broadcast nicht einfach in andere Subnetze weiter. Ein DHCP-Relay nimmt die Anfrage im Clientnetz entgegen und übermittelt sie gezielt an einen konfigurierten DHCP-Server. Bei DHCPv4 trägt es unter anderem seine Adresse im Feld giaddr ein. Der Server kann dadurch das passende Clientnetz und den Scope bestimmen und Antworten über das Relay zurückschicken. Die Rückzustellung ins Clientnetz berücksichtigt wiederum den Clientzustand und das Broadcast-Flag.
Ein zentraler Server kann so mehrere Netze versorgen. Das Relay muss am richtigen Netzübergang konfiguriert sein, und Filter müssen die nötige Kommunikation erlauben. Ein „IP-Helper“ ist je nach Hersteller die Bezeichnung einer solchen Funktion; seine genaue Konfiguration ist produktspezifisch.
Eine Reservierung legt dagegen serverseitig fest, welche Adresse ein bestimmter Client erhalten soll. Der Client verwendet weiterhin DHCP. Die Zuordnung kann nach Produkt und Konfiguration einen Client-Identifier oder eine Hardwareadresse verwenden. „DHCP erkennt Geräte immer nur an der MAC-Adresse“ ist daher zu einfach. Private beziehungsweise wechselnde WLAN-MAC-Adressen und geänderte Client-Identifier können eine bisherige Zuordnung beeinflussen.
Eine Reservierung ist weder eine am Endgerät statisch eingetragene Adresse noch eine Sicherheitsgarantie. Die Pool- und Ausschlussregeln des konkreten Servers müssen zur Reservierung und zu anderen festen Adressen passen. Nicht autorisierte DHCP-Server können falsche Gateway- oder DNS-Werte verteilen; die automatische Konfiguration macht solche Angaben nicht vertrauenswürdig.
Kein Angebot: Pool, Verbindung und Zuständigkeit prüfen.
Sind alle 100 Adressen unseres Beispielpools gebunden oder anderweitig nicht verfügbar, kann der Server einem neuen Laptop aus diesem Pool keine weitere freie Adresse anbieten. Das bedeutet nicht, dass das gesamte /24 voll ist. Prüfe aktive Leases, Reservierungen und Ausschlüsse. Einen Bereich zu erweitern hilft nur, wenn die zusätzlichen Adressen im richtigen Subnetz liegen und tatsächlich frei sind.
Bleibt die Antwort ganz aus, kommen auch eine getrennte Verbindung, eine falsche VLAN-Zuordnung, ein fehlendes Relay, Filter oder ein ausgefallener Dienst infrage. Kontrolliere zuerst Schnittstellenstatus und erhaltene Werte. Unter Windows zeigt ipconfig /all unter anderem DHCP-Status, Server und Lease-Daten. Unter Linux hängen entsprechende Ansichten vom Netzwerkdienst ab; bei NetworkManager zeigt etwa nmcli device show die aktuelle Konfiguration. Ein Paketmitschnitt mit den UDP-Ports 67 und 68 kann zeigen, an welcher Stelle die Folge abbricht.
Manche Systeme vergeben bei fehlender DHCPv4-Konfiguration selbst eine IPv4-Link-Local-Adresse aus 169.254.0.0/16; unter Windows ist die Funktion als APIPA bekannt. Diese Adresse kommt nicht vom DHCP-Server und erfordert eine Konfliktprüfung. Sie kann Kommunikation auf demselben Link ermöglichen, ist aber nicht für die Weiterleitung über Router vorgesehen und liefert keinen normalen Internetzugang. Die ersten und letzten 256 Adressen dieses /16 sind für die automatische Auswahl ausgenommen. Nicht jedes System muss dieses Ausweichverfahren verwenden.
Eine 169.254-Adresse ist somit ein Anlass, die erwartete Konfiguration zu prüfen, kein eindeutiger Beweis für einen defekten Server. Eine noch gültige Lease kann einen zeitweisen Serverausfall außerdem überbrücken. Beim gezielten Fehlerbeheben sollte man sie nicht ohne Grund vorzeitig freigeben.
DHCPv6 ist ein eigenes Protokoll.
DHCPv6 übernimmt Einstellungen, IPv6-Adresszuweisungen oder Präfixdelegation. Es verwendet andere Nachrichten und UDP-Ports 546 und 547. Ein typischer Austausch heißt Solicit, Advertise, Request und Reply; DORA ist die Merkhilfe für den hier erklärten DHCPv4-Fall. IPv6 besitzt keinen Broadcast. DHCPv6 verwendet auf dem Clientlink Multicast und kann Relays nutzen.
Die aktuelle Grundspezifikation ist RFC 9915 (Januar 2026); sie ersetzt RFC 8415. Zu ihren Änderungen gehört das Entfernen der früheren Server-Unicast-Option. Alte DHCPv6-Beschreibungen dürfen deshalb nicht ungeprüft als aktueller Ablauf übernommen werden.
Bei SLAAC bildet der Host Adressen anhand geeigneter Präfixinformationen aus Router Advertisements selbst und prüft sie auf Duplikate. SLAAC und DHCPv6 können nebeneinander verwendet werden, beispielsweise SLAAC für Adressen und DHCPv6 für weitere Einstellungen. Im üblichen IPv6-Verfahren stammt der Standardrouter aus Router Advertisements, nicht aus einer DHCPv4-artigen Gateway-Option. DNS-Server können je nach Netz über DHCPv6 oder Router Advertisements bekannt werden. Der IPv6-Artikel ordnet diese Verfahren genauer ein.
Pool und Erneuerung begründen.
Ein Laptop erhält um 08:00 Uhr eine achtstündige Lease. Es gelten die Standardwerte für T1 und T2, und auf die Erneuerungsversuche kommt keine Antwort. Wann fragt er wen, und wann muss er die Adresse aufgeben?
Lösung: Drei Zeitpunkte auseinanderhalten
Um 12:00 Uhr erreicht er T1: vier Stunden sind 50 Prozent der Lease. Er fragt den bisherigen Server per DHCPREQUEST als Unicast. Um 15:00 Uhr erreicht er T2: sieben Stunden sind 87,5 Prozent. Er sucht per Broadcast eine Verlängerung bei einem geeigneten Server. Ohne ACK endet die Lease um 16:00 Uhr; die Adresse darf danach nicht weiter verwendet werden. Ein ausgebliebener Versuch um 12:00 Uhr beendet die Lease noch nicht.
Im Netz 192.168.10.0/24 sind alle Adressen von .100 bis .199 belegt. Ein neues Gerät erhält kein Angebot. Darfst du den Pool einfach bis 192.168.11.50 verlängern?
Lösung: Der Pool muss zum Subnetz passen
Nein. 192.168.11.50 gehört nicht zum festgelegten 192.168.10.0/24. Zuerst müssen Belegung, Leases und Ausschlüsse geprüft werden. Ein freier Bereich innerhalb des bestehenden Subnetzes könnte nach Prüfung nutzbar sein. Eine größere Netzstruktur erfordert eine geplante Änderung von Präfix, Routing und betroffenen Konfigurationen; eine längere Poolliste allein schafft keine korrekte Verbindung.
Quellen und fachlicher Stand.
Fachlich geprüft am . RFC 2131, Abschnitt 3.1 (Adressvergabe), Abschnitt 4.1 (Zustellung) und Abschnitt 4.4.5 (T1/T2) bilden die DHCPv4-Grundlage. RFC 2132 beschreibt die Optionen.
Ergänzend: RFC 1542 (Relay), RFC 4361 (Client-Identifier), RFC 3927 (IPv4-Link-Local) und RFC 9915 (aktuelles DHCPv6; ersetzt RFC 8415). Für IPv6 ergänzen RFC 4861 (Router Advertisements), RFC 4862 (SLAAC) und RFC 8106 (DNS über Router Advertisements) die Einordnung. Herstellerabhängige Scope- und Reservierungskonfigurationen sind am tatsächlich eingesetzten Server zu prüfen.
Die Grundlagen im Serverbetrieb anwenden.
Diese Lernschritte verbinden das Thema mit einer konkreten Infrastruktur: