Wikipedia

Dynamic Host Configuration Protocol

Kommunikationsprotokoll
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 12. Februar 2006 um 12:48 Uhr durch Koblaid (Diskussion | Beiträge) (→Initiale Adresszuweisung: Router verlinkt). Sie kann sich erheblich von der aktuellen Version unterscheiden.
DHCP im TCP/IP-Protokollstapel
Anwendung DHCP
Transport UDP
Internet IP
Netzwerk Ethernet Token
Ring 		FDDI ...

Das DHCP (Dynamic Host Configuration Protocol) ermöglicht mit Hilfe eines entsprechenden Servers die dynamische Zuweisung einer IP-Adresse und weiterer Konfigurationsparameter an Computer in einem Netzwerk (z.B. Internet oder LAN).

DHCP bekam von der IANA den UDP-Port 67 zugewiesen.

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, was 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:

  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.

Das DHCP wurde erstmalig 1993 in RFC 1531 und RFC 1541, aufbauend auf dem 1985 entstandenen BOOTP definiert.

Der DHCP-Server

Der DHCP-Server ist in der Regel als Daemon (z.B. dhcpd) implementiert und wartet auf UDP-Port 67 auf Client-Anfragen. In seiner Konfigurationsdatei befinden sich etwa Informationen über den zu vergebenden Adresspool sowie zusätzliche Angaben über netzwerkrelevante Parameter wie die Subnetzmaske, die lokale DNS-Domäne oder das zu verwendende Gateway.

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 automatischen 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 Client 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 IP-Subnetz befinden. (Das liegt an der Tatsache, dass DHCP Broadcasts verwendet (siehe dazu auch weiter unten) und dass Router keine Broadcasts weiterleiten - Router bilden Broadcast-Domänen). Befindet sich der DHCP-Server in einem anderen Subnetz, so muss ein so genannter DHCP-Relay installiert werden, der die DHCP-Anfragen in das Subnetz des eigentlichen Servers weitergibt.

Wenn ein Client erstmalig eine IP-Adresse benötigt, schickt er eine DHCP-DISCOVER-Nachricht als Netzwerk-Broadcast an die verfügbaren DHCP-Server (es kann durchaus mehrere davon im gleichen Subnetz geben). Dieser Broadcast hat als Absender-IP-Adresse 0.0.0.0 und als Zieladresse 255.255.255.255, da der Absender natürlich noch keine IP-Adresse besitzt und seine Anfrage „an alle“ richtet. Dabei ist der Quellport 68 und der Zielport 67. Die DHCP-Server antworten mit DHCP-OFFER und machen einen Vorschlag für eine IP-Adresse. Dies geschieht ebenfalls mit einem Broadcast an die Adresse 255.255.255.255 mit Quellport 68 und Zielport 67.

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 DHCP-REQUEST, worauf der Server ihm in einer DHCP-ACKNOWLEDGE-Nachricht (DHCP-ACK) 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 DHCP-DECLINE-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. Dies ist ein Zeitwert, der angibt, wie lange der Client die zugewiesene IP-Konfiguration verwenden darf; er wird vom Administrator des DHCP-Servers eingestellt. 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 Server gesendet, der die IP-Konfiguration vergeben hat. 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.

Antwortet der Server nicht, so kann der Client die IP-Konfiguration ohne Einschränkungen weiter verwenden. Er wird jedoch nach Ablauf von 7/8 der Lease-Zeit (87,5%) versuchen, eine Verlängerung der IP-Konfiguration von irgendeinem DHCP-Server im selben Subnetz zu erhalten. (Ein möglicher Grund dafür ist, dass der ursprüngliche Server abgeschaltet worden sein kann und nun ein neuer Server für die Verwaltung der IP-Adressen zuständig ist.)

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 DHCP-NAK (DHCP-Not Acknowledged) 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 auch möglich, mehrere DHCP-Server in einem Netz zu platzieren. Dabei sollte allerdings beachtet werden, dass sich die Adressbereiche der einzelnen Server nicht überlappen, da es sonst zu Doppelvergaben von IP-Adressen kommen kann. 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. Diese statuslose Autokonfiguration funktioniert recht zuverlässig, allerdings benötigt der Client oft neben einem Gateway auch noch die Zuweisung eines DNS-Servers; das wird jedoch durch diese Form der Konfiguration nicht bewerkstelligt: 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 Szenarien, 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).

Abgerufen von „https://de.wikipedia.org/w/index.php?title=Dynamic_Host_Configuration_Protocol&oldid=13637042“