Konzept:

Durch DHCP ist die Einbindung eines neuen Computers in ein bestehendes Netzwerk ohne weitere Konfiguration möglich. Es muss lediglich der automatische Bezug der IP-Adresse am Client eingestellt werden. Ohne DHCP sind relativ aufwendige Einstellungen nötig, das neben der IP-Adresse die Eingabe weiterer Parameter wie Netzmaske, Gateway, DNS-Server, WINS-Server usw. verlangt. Per DHCP kann ein DHCP-Server diese Parameter beim Starten eines neuen Rechners (DHCP-Client) automatisch vergeben.

DHCP verwendet das BOOTP-Protokoll, mit dem sich laufwerklose Workstations realisieren lassen, die sich zunächst eine IP-Adresse vom BOOTP-Server holen, und anschließend ein Kernel-Image aus dem Netz nachladen, mit dem sie dann booten. DHCP ist weitgehend kompatibel zu BOOTP und kann mit BOOTP-Clients und -Servern eingeschränkt zusammenarbeiten.

DHCP wurde im Hinblick auf zwei Einsatzszenarien entwickelt:

Was ist der DHCP Relay-Agent?

1. Große Netzwerke mit häufig wechselnder Topologie
2. Anwender, die "einfach nur Netzwerkverbindung" haben wollen und nicht mit Netzwerkkonfiguration belastet werden sollen

Netzwerken bietet DHCP den Vorteil, dass bei Topologieänderungen nicht mehr alle betroffenen Workstations per Hand umkonfiguriert werden müssen, sondern die entsprechenden Vorgaben vom Administrator nur einmal in der Konfigurationsdatei des DHCP-Servers gemacht werden müssen. Auch für Rechner mit häufig wechselndem Standort (z.B. Notebooks) entfällt die fehleranfällige Konfiguration – der Rechner wird einfach ans Netzwerk gesteckt und erfragt alle relevanten Parameter vom DHCP-Server. Dies wird manchmal auch als Plug'n'Play für Netzwerke bezeichnet.

Der DHCP-Server:

Der DHCP-Server ist als Daemon (z.B. dhcpd) implementiert und wartet auf UDP-Port 67 auf Client-Anfragen. In der DOS-Konsole mit dem Befehl "netstat -an" lässt sich überprüfen, ob der Dienst gestartet ist. In seiner Konfigurationsdatei befinden sich Informationen über den zu vergebenden Adresspool. Zusätzliche Angaben über netzwerkrelevante Parameter wie die Subnetzmaske, die lokale DNS-Domäne oder das zu verwendende Gateway komplettieren die Konfigurationsdatei des DHCP-Servers.

Es gibt verschiedene Betriebsmodi eines DHCP-Servers:

Automatische Zuordnung:

In diesem Modus wird jedem Client eine IP-Adresse fest und auf unbestimmte Zeit zugeordnet. Der größte Nachteil liegt hier in der Tatsache begründet, dass eine IP-Adresse an die MAC-Adresse des jeweiligen Clients gebunden wird. Sobald die Anzahl der verschiedenen Rechner die der verfügbaren Adressen im Pool überschreitet, können keine Adressen mehr vergeben bzw. muss der Cache des Servers gelöscht werden.

Manuelle Zuordnung:

Hier wird der MAC-Adresse des Clients innerhalb der Konfigurationsdatei eine IP-Adresse fest zugeordnet. Der Vorteil dieses Einstellungsmodus gegenüber der manuellen Konfiguration direkt am Client liegt vor allem darin, trotz der Vergabe einer "festen" IP-Adresse die Einstellungen noch immer zentral am DHCP-Server verwaltet werden können. So muss weder der physikalische Weg zum Client-Rechner vorgenommen werden noch überhaupt unmittelbar in den Bereich des Benutzers eingegriffen werden.

Manuelle Zuordnungen werden vor allem dann vorgenommen, wenn der DHCP-Client beispielsweise Server-Dienste zur Verfügung stellt und daher unter einer festen IP-Adresse zu erreichen sein soll. Auch Port-Weiterleitungen von einem Router an einen ent benötigen in der Regel eine feste IP-Adresse.

Dynamische Zuordnung:

Dieses Verfahren gleicht der automatischen Zuordnung, allerdings hat der Server hier in seiner Konfigurationsdatei eine Angabe, wie lange eine bestimmte IP-Adresse an einen Client "vermietet" werden darf, bevor der Client sich erneut beim Server melden und eine "Verlängerung" beantragen sollte. Meldet er sich nicht, wird die Adresse frei und kann an einen anderen (oder auch den gleichen) Rechner neu vergeben werden. Diese Zeit, die vom Administrator bestimmt werden kann, heißt Lease-Zeit (zu deutsch also: "Mietzeit").

Ablauf der DHCP-Kommunikation:

Initiale Adresszuweisung:

Damit der Client einen DHCP-Server nutzen kann, muss sich dieser im selben Subnetz befinden. Befindet sich der DHCP-Server in einem anderen Subnetz so muss ein DHCP-Relay installiert werden.

Wenn ein Client erstmalig eine IP-Adresse benötigt, schickt er eine DHCPDISCOVER-Nachricht als Netzwerk-Broadcast an die verfügbaren DHCP-Server (es kann durchaus mehrere davon im gleichen Subnetz geben), die mit DHCPOFFER antworten und einen Vorschlag für eine IP-Adresse machen. Dieser Broadcast hat als Absenderadresse 0.0.0.0 und als Zieladresse 255.255.255.255. Der Client darf nun unter den eingetroffenen Angeboten wählen. Wenn er sich für eines entschieden hat (z.B. wegen längster Lease-Zeit oder auch wegen Ablehnung eines speziellen, evtl. falsch konfigurierten DHCP-Servers), kontaktiert er per Broadcast und einem im Paket enthaltenen Serveridentifier den entsprechenden Server mit der Nachricht DHCPREQUEST, worauf der Server ihm in einer DHCPACK-Nachricht die IP-Adresse mit den weiteren relevanten Daten übermittelt. Bevor der Client sein Netzwerkinterface mit der zugewiesenen Adresse konfiguriert, sollte er noch prüfen, ob nicht versehentlich noch ein anderer Rechner die Adresse verwendet. Der Client kann in diesem Fall eine vorgeschlagene Adresse mit einer DHCPDECLINE-Nachricht zurückweisen.

DHCP-Refresh: (nur bei dynamischer Zuordnung)

Zusammen mit der IP-Adresse erhält der Client in der DHCPACK-Nachricht die Lease-Zeit. Der Standard sieht vor, dass der Client nach der Hälfte der Lease-Zeit einen erneuten DHCPREQUEST sendet und so bekundet, dass weiter Interesse an der reservierten IP-Nummer besteht. Dieser DHCPREQUEST wird per Unicast an den im Datenpaket enthaltenen Server gesendet. Der Server sollte dann in der Regel ein DHCPACK mit identischen Daten wie vorher, aber einer neuen Lease-Zeit senden. Damit gilt die Adresse als verlängert. Sollte der Client es versäumen, bis zum Ablauf der Lease-Zeit eine Verlängerung zu beantragen, so muss er seine Netzwerkkarte dekonfigurieren und wieder bei DHCPDISCOVER mit einer initialen Adresszuweisung beginnen.Sollte der DHCP Server keine Adressen mehr zur Verfügung haben oder während des Vorganges schon ein anderer Client seine Letzte Adresse zugesagt bekommen haben sendet der Server ein DHCPNAK und der Vorgang der Adressanfrage beginnt erneut.

Sonstiges:

Die negative Bestätigung DHCPNAK tritt ein, wenn der Client versucht, seine ehemalige IP-Adresse zu leasen, die jedoch inzwischen nicht mehr verfügbar ist (Lease abgelaufen und anderweitig vergeben) oder wenn der Clientcomputer in ein anderes Subnetz verschoben wurde.

Um die Ausfallwahrscheinlichkeit zu verringern ist es möglich auch mehrere DHCP Server in einem Netz platzieren. Dazu gibt es die "authorative" Einstellung mit der man einstellen kann, ob ein DHCPNAK auch verschickt werden soll, wenn der DHCP Server für die vom Client vorgeschlagene Adresse nicht zuständig ist.

Wenn der Client eine negative Bestätigung erhält, wird der DHCP-Leasevorgang erneut gestartet.

Ein Client sendet DHCPRELEASE, wenn er eine IP-Adresse vor Ablauf der Lease-Zeit zurückgeben will.

Sollte der Client feststellen, dass die zugewiesene Adresse bereits benutzt wird, so teilt er dies dem Server durch DHCPDECLINE mit, welcher seinerseits den Administrator von dieser potentiellen Fehlkonfiguration unterrichten sollte.

Eine Liste der möglichen DHCP-Optionen, die DHCPACK enthalten kann ist hier zu finden.

DHCPv6:

IPv6 sollte DHCP als eigenständiges Protokoll ursprünglich überflüssig machen, da viele DHCP-Funktionen serienmäßig in IPv6 enthalten sind. Ein IPv6-fähiger Rechner kann aus der MAC-Adresse seines Netzwerk-Interfaces eine Link-lokale IPv6-Adresse errechnen, unter der er dann im lokalen Netz erreichbar ist.

Mit einer Anfrage an eine bestimmte Multicast-Gruppe (ff02::2) kann der Client nach erreichbaren Routern suchen und diese als Gateway verwenden. Bis hierhin funktioniert diese statuslose Autokonfiguration recht zuverlässig, wenn der Client jedoch auch noch einen DNS-Server braucht, bekommt er ein Problem, weil das Konzept der Autokonfiguration an dieser Stelle nicht zu Ende gedacht wurde: Eine automatische Suche nach DNS-Servern kommt in den gegenwärtigen Fassungen der IPv6-RFCs nicht vor.

Es existieren verschiedene Lösungsansätze, wie z. B. eine weitere Multicastgruppe, an der die DNS-Server des lokalen Netzwerks lauschen. Diese sind jedoch bislang nicht standardisiert, so dass man für autokonfiguriertes DNS unter IPv6 bislang auf DHCP angewiesen bleibt.

Für den beschriebenen Fall und Szenarios, in denen die automatische Netzwerkkonfiguration von IPv6-Clients nicht in die Hände des lokalen IPv6-Stacks im Betriebssystem gelegt werden soll, ist daher seit Juli 2003 in RFC 3315 das Protokoll DHCPv6 definiert, das in der IPv6-Welt die gleiche Funktionalität wie das gegenwärtig aktuelle DHCPv4 für IPv4 zur Verfügung stellt. Darüber hinaus ist DHCPv6 darauf ausgelegt über optionale Felder im DHCPv6-Protokoll Konfigurationsinformationen über NIS+-, SIP-, NTP- und weitere Dienste zu transportieren. Welche Optionen in DHCPV6 aufgenommen werden, wird von der DHCP-Arbeitsgruppe der IETF festgelegt. Weitere Features von DHCPv6 sind die integrierten Sicherheitsfunktionen, durch die es möglich ist, DHCPv6 nur autorisierten Clients zugänglich zu machen, sowie die Möglichkeit die Adresskonfiguration weiterhin per statusloser Autokonfiguration erfolgen zu lassen, jedoch weitere Konfigurationsdetails per DHCPv6 auf die Clients zu bringen.

Abweichend zu DHCPv4 läuft bei v6 die Kommunikation über die UDP-Ports 546 (Client) und 547 (Server)