Seite 1 von 8 Dynamic Host Configuration Protocol aus Wikipedia, der freien Enzyklopädie (Weitergeleitet von DHCP) Das Dynamic Host Configuration Protocol (DHCP) ermöglicht die Zuweisung der Netzwerkkonfiguration an Clients durch einen Server. Das Dynamic Host Configuration Protocol wurde im RFC 2131 definiert und bekam von der Internet Assigned Numbers Authority die UDP-Ports 67 und 68 zugewiesen. Inhaltsverzeichnis 1 Konzept 2 Aufbau eines DHCP-Paketes 3 Der DHCP-Server 3.1 Manuelle Zuordnung 3.2 Automatische Zuordnung 3.3 Dynamische Zuordnung 4 DHCP-Nachrichten 5 Ablauf der DHCP- Kommunikation 5.1 Initiale Adresszuweisung (Lease/Vergabe) 5.2 DHCP-Refresh (nur bei dynamischer Zuordnung) 5.3 Sonstiges 5.4 DHCP und DNS 5.5 Mögliche Zuweisungen 6 DHCP für mehrere Subnetze 7 Sicherheit 8 DHCPv6 9 Literatur 9.1 Spezifikationen 9.2 Weblinks 9.3 Einzelnachweise DHCP (Dynamic Host Configuration Protocol) Familie: Internetprotokollfamilie Einsatzgebiet: Automatischer Bezug von IP-Adressen und weiteren Parametern 67/UDP (Server oder Relay-Agent) Ports: 68/UDP (Client) DHCP im TCP/IP-Protokollstapel: Anwendung DHCP Transport UDP Internet IP (IPv4, IPv6) Netzzugang Ethernet Token Bus Standards: RFC 2131 (1997) Token Ring FDDI Konzept
Seite 2 von 8 Durch DHCP ist die automatische Einbindung eines Computers in ein bestehendes Netzwerk ohne dessen manuelle Konfiguration möglich. An diesem, dem Client, muss im Normalfall lediglich der automatische Bezug der IP-Adresse eingestellt sein. Beim Start des Rechners am Netz kann er die IP-Adresse, die Netzmaske, das Gateway, DNS-Server und gegebenenfalls WINS-Server von einem DHCP-Server beziehen. Ohne DHCP sind dazu abhängig vom Netzwerk, an das der Rechner angeschlossen werden soll einige Einstellungen nötig. DHCP ist eine Erweiterung des Bootstrap Protocol (BOOTP), mit dem sich festplattenlose Workstations realisieren lassen, die sich zunächst eine IP-Adresse vom BOOTP-Server holen. Anschließend laden sie ein startbares Betriebssystem aus dem Netz, mit dem sie dann starten. DHCP ist weitgehend kompatibel zu BOOTP und kann mit BOOTP-Clients und -Servern eingeschränkt zusammenarbeiten. Das Dynamic Host Configuration Protocol wurde im Hinblick auf zwei Einsatzszenarien entwickelt: 1. große Netzwerke mit häufig wechselnder Topologie, 2. Anwender, die einfach nur eine Netzwerkverbindung haben möchten und sich nicht näher mit der Netzwerkkonfiguration beschäftigen möchten. In Netzwerken bietet DHCP den Vorteil, dass bei Topologieänderungen nicht mehr alle betroffenen Workstations von Hand umkonfiguriert werden müssen, sondern die entsprechenden Vorgaben vom Administrator nur einmal in der Konfigurationsdatei des DHCP-Servers geändert werden. 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. Das wird manchmal auch als Plug n Play für Netzwerke bezeichnet. DHCP wurde erstmals 1993 in RFC 1531 und RFC 1541, aufbauend auf dem 1985 entstandenen BOOTP (RFC 951), definiert. Aufbau eines DHCP-Paketes op (1 Byte): Information, ob es sich um eine Anforderung (request = 1) oder eine Antwort (reply = 2) handelt htype (1 Byte): Netztyp (z. B. 1 = Ethernet, 6 = IEEE 802 Netzwerke oder 7 = ARCNET) hlen (1 Byte): Länge der physikalischen Netzadresse in Bytes (z. B. 6 = MAC/Ethernet-Adresse) hops (1 Byte, optional): Anzahl der DHCP-Relay-Agents auf dem Datenpfad xid (4 Byte): ID der Verbindung zwischen Client und Server secs (2 Byte): Zeit in Sekunden seit dem Start des Clients flags (2 Byte): Z. Zt. wird nur das erste Bit verwendet (zeigt an, ob der Client noch eine gültige IP-Adresse hat), die restlichen Bits sind für spätere Protokollerweiterungen reserviert ciaddr (4 Byte): Client-IP-Adresse yiaddr (4 Byte): eigene IP-Adresse siaddr (4 Byte): Server-IP-Adresse giaddr (4 Byte): Relay-Agent-IP-Adresse chaddr (16 Byte): Client-MAC-Adresse 32 Bit op htype hlen hops xid secs flags ciaddr yiaddr siaddr giaddr chaddr sname file options sname (64 Byte): Name des DHCP-Servers, falls ein bestimmter gefordert wird (enthält C-String), Angabe optional file (128 Byte): Name einer Datei (z. B. System-Kernel), die vom Server per TFTP an den Client gesendet werden soll (enthält C-String), Angabe optional
Seite 3 von 8 options (variabel, optional): DHCP-Parameter und -Optionen (Beschreibung in RFC 2132) Client sollte hier mindestens Optionen mit 312 Bytes Länge (als maximum), mit anderen Worten ein Paket mit der Größe von 576 Bytes empfangen können. Eine größere maximale Byteanzahl kann zwischen Server und Client 'ausgehandelt' werden. [1] Der DHCP-Server Der DHCP-Server wird wie alle Netzwerkdienste als Hintergrundprozess (Daemon oder Dienst) gestartet und wartet auf UDP-Port 67 auf Client-Anfragen. In seiner Konfigurationsdatei befinden sich Informationen über den zu vergebenden Adresspool sowie zusätzliche Angaben über netzwerkrelevante Parameter wie die Subnetzmaske, die lokale DNS-Domain oder das zu verwendende Gateway. Außerdem lassen sich auch weitere BOOTP-Server oder der Ort des zu verwendenden Bootimages einstellen. Es gibt drei verschiedene Betriebsmodi eines DHCP-Servers: manuelle, automatische und dynamische Zuordnung. Manuelle Zuordnung In diesem Modus (statisches DHCP) werden am DHCP-Server die IP-Adressen bestimmten MAC- Adressen fest zugeordnet. Die Adressen werden der MAC-Adresse auf unbestimmte Zeit zugeteilt. Der Nachteil kann darin liegen, dass sich keine zusätzlichen Clients in das Netz einbinden können, da die Adressen fest vergeben sind. Das kann unter Sicherheitsaspekten erwünscht sein. 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 erreichbar sein soll. Auch Port-Weiterleitungen von einem Router an einen Client benötigen in der Regel eine feste IP-Adresse. Automatische Zuordnung Bei der automatischen Zuordnung wird am DHCP-Server ein Bereich von IP-Adressen (range) definiert. IP-Adressen werden automatisch an die MAC-Adressen von neuen DHCP-Clients zugewiesen, was in einer Tabelle festgehalten wird. Im Unterschied zur dynamischen Zuordnung sind automatische Zuordnungen permanent und werden nicht entfernt. Der Vorteil ist, dass Hosts immer dieselbe IP-Adresse erhalten und eine zugewiesene IP-Adresse keinem anderen Host zugewiesen wird. Der Nachteil ist, dass neue Clients keine IP-Adresse erhalten, wenn der Adressbereich komplett vergeben ist, auch wenn IP-Adressen nicht mehr aktiv genutzt werden. Gegenüber der manuellen und dynamischen Zuordnung spielt dieser Modus in der Praxis eine untergeordnete Rolle. Dynamische Zuordnung Dieses Verfahren gleicht der automatischen Zuordnung, allerdings hat der DHCP-Server hier in seiner Konfigurationsdatei eine Angabe, wie lange eine bestimmte IP-Adresse an einen Client verliehen werden darf, bevor der Client sich erneut beim Server melden und eine Verlängerung beantragen muss. Meldet er sich nicht, wird die Adresse frei und kann an einen anderen (oder auch den gleichen) Rechner neu vergeben werden. Diese vom Administrator bestimmte Zeit heißt Lease-Time (zu deutsch also: Leihdauer ).
Seite 4 von 8 Manche DHCP-Server vergeben auch von der MAC-Adresse abhängige IP-Adressen, d. h. ein Client bekommt hier selbst nach längerer Netzwerkabstinenz und Ablauf der Lease-Zeit die gleiche IP- Adresse wie zuvor (es sei denn natürlich, diese ist inzwischen schon anderweitig vergeben). DHCP-Nachrichten DHCPDISCOVER: Ein Client ohne IP-Adresse sendet eine Broadcast-Anfrage nach Adress- Angeboten an den/die DHCP-Server im lokalen Netz. DHCPOFFER: Der/die DHCP-Server antworten mit entsprechenden Werten auf eine DHCPDISCOVER-Anfrage. DHCPREQUEST: Der Client fordert (eine der angebotenen) IP-Adresse(n), weitere Daten sowie Verlängerung der Lease-Zeit von einem der antwortenden DHCP-Server. DHCPACK: Bestätigung des DHCP-Servers zu einer DHCPREQUEST-Anforderung DHCPNAK: Ablehnung einer DHCPREQUEST-Anforderung durch den DHCP-Server DHCPDECLINE: Ablehnung durch den Client, da die IP-Adresse schon verwendet wird. DHCPRELEASE: Der Client gibt die eigene Konfiguration frei, damit die Parameter wieder für andere Clients zur Verfügung stehen. DHCPINFORM: Anfrage eines Clients nach Daten ohne IP-Adresse, z. B. weil der Client eine statische IP-Adresse besitzt. Ablauf der DHCP-Kommunikation Damit der Client einen DHCP-Server nutzen kann, muss sich dieser im selben Netzwerksegment befinden, da DHCP Broadcasts verwendet und Router keine Broadcasts weiterleiten (Router bilden Broadcast-Domänen). Befindet sich der DHCP-Server in einem anderen Netzwerksegment, so muss ein so genannter DHCP-Relay-Agent installiert werden, der die DHCP-Anfragen an den eigentlichen Server weitergibt. Initiale Adresszuweisung (Lease/Vergabe) Wenn ein Client erstmals eine IP-Adresse benötigt, schickt er eine DHCPDISCOVER-Nachricht (mit seiner MAC-Adresse) 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 noch keine IP- Ablauf der Zuweisung einer IP- Adresse per DHCP Adresse besitzt und seine Anfrage an alle richtet. Dabei ist der UDP-Quellport 68 und der UDP- Zielport 67. Die DHCP-Server antworten mit DHCPOFFER und machen Vorschläge für eine IP- Adresse. Das geschieht ebenfalls mit einem Broadcast an die Adresse 255.255.255.255 mit UDP- Quellport 67 und UDP-Zielport 68. Der Client darf nun unter den eingetroffenen Angeboten (DHCP-Offers) wählen. Wenn er sich für eines entschieden hat (z. B. wegen längster Lease-Zeit oder wegen Ablehnung eines speziellen, evtl. falsch konfigurierten DHCP-Servers, oder einfach für die erste Antwort), kontaktiert er per Broadcast und einem im Paket enthaltenen Serveridentifier den entsprechenden Server mit der Nachricht DHCPREQUEST. Alle eventuellen weiteren DHCP-Server werten das als Absage für ihre
Seite 5 von 8 Angebote. Der vom Client ausgewählte Server bestätigt in einer DHCPACK-Nachricht (DHCP- Acknowledged) die IP-Adresse mit den weiteren relevanten Daten, oder er zieht sein Angebot zurück (DHCPNAK, siehe auch sonstiges). 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. Das geschieht üblicherweise durch einen ARP-Request mit der soeben zugeteilten IP-Adresse. Antwortet ein anderer Host im Netz auf diesen Request, so wird der Client die 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. Das 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 weiteres Interesse an der reservierten IP-Adresse 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, bis die Lease abgelaufen ist. Er wird jedoch nach Ablauf von 7/8 der Lease-Zeit (87,5 %) versuchen, eine Verlängerung der IP-Konfiguration von irgendeinem DHCP-Server zu erhalten (Sendung der Anfrage im Broadcast). Ein möglicher Grund dafür ist, dass der ursprüngliche Server abgeschaltet wurde 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, 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 (DHCP-Not Acknowledged), und der Vorgang der Adressanfrage beginnt erneut. Sonstiges Eine negative Bestätigung DHCPNAK kann als Ursache haben, dass der Client versucht, seine ehemalige IP-Adresse zu leasen (engl. lease: mieten oder pachten), die jedoch inzwischen nicht mehr verfügbar ist, oder wenn der Client-Computer 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 authoritative (engl. für maßgebliche ) 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-Lease-Vorgang erneut gestartet. Ein Client sendet DHCPRELEASE, wenn er eine IP-Adresse vor Ablauf der Lease-Zeit zurückgeben
Seite 6 von 8 will. Sollte der Client feststellen, dass die zugewiesene Adresse bereits benutzt wird, so teilt er das dem Server durch DHCPDECLINE mit, der seinerseits den Administrator von dieser potentiellen Fehlkonfiguration unterrichten sollte. DHCP und DNS Damit ihre Namensauflösung möglich ist, registrieren Computer ihren Namen und ihre IP-Adresse in der Regel bei einem DNS-Server. Einige DHCP-Server können das an Stelle der Clients übernehmen. Bei Betriebssystemen von Microsoft war das vor Windows 2000 erforderlich. Mögliche Zuweisungen Standardmäßig kann DHCP dem Client folgende Einstellungen zuweisen: IP-Adresse und Netzwerkmaske Default-Gateway Nameserver Proxy-Konfiguration via WPAD Time- (nach RFC 868) sowie NTP-Server DNS-Server, DNS Context und DNS Tree Sekundärer DNS-Server WINS-Server (für Microsoft Windows Clients) DHCP für mehrere Subnetze Der DHCP-Server kann (Teil-)Netze bedienen, wenn er über Definitionen für das jeweilige Netz verfügt. Die Auswahl der Definition wird dann durch die Netzwerkkarte bestimmt, über welche die Anforderung hereinkommt. Beim Start des DHCP-Servers kann angegeben werden, auf welchen Interfaces der Server hört. Andererseits kann ein DHCP-Server auch entfernte Netze bedienen, wenn diese durch einen DHCP- Relay-Agenten (vielfach als Funktion eines Routers verfügbar) verbunden sind. Der Relay-Agent empfängt im entfernten Netz die DHCP-Broadcast-Anforderungen und leitet diese als Unicast- Botschaften an den/die konfigurierten DHCP-Server weiter. Die IP-Adresse der Schnittstelle, über welche der Broadcast empfangen wurde, wird vom Relay-Agenten dem Unicast-Paket im DHCP- Header hinzugefügt, sodass der DHCP-Server anhand dieser Information bestimmen kann, aus welchem Netzwerksegement die Anfrage kommt. Der DHCP-Relay-Agent empfängt die Antwortpakete der DHCP-Server auf Port UDP 67 und leitet diese dann mit Zielport UDP 68 an den Client weiter. Sicherheit DHCP kann leicht gestört und manipuliert werden, weil DHCP-Clients jeden DHCP-Server akzeptieren.
Seite 7 von 8 Die versehentliche Aktivierung eines DHCP-Servers, beispielsweise durch den Anschluss eines einfachen DSL-Routers oder WLAN-Routers im Auslieferungszustand, kann ein Netz weitgehend lahmlegen. Dieser antwortet möglicherweise schneller als der eigentlich vorgesehene DHCP-Server und verteilt dadurch ggf. ungültige Konfigurationen. Ein Angreifer kann alle Adressen eines DHCP-Servers reservieren (DHCP Starvation Attack), dadurch dessen Antwort auf weitere Anfragen verhindern und anschließend als einziger DHCP- Server auftreten. Er hat nun die Möglichkeit ein rogue DHCP Spoofing zu betreiben, indem er auf andere DNS-Server umleitet, die auf Computer verweisen, die die Kommunikation kompromittieren. Die vermeintliche Eindeutigkeit der MAC-Adresse darf nicht als Sicherheitskriterium angewandt werden. Es ist viel zu einfach, MAC-Adressen-Spoofing zu betreiben. Fast alle Betriebssysteme erlauben es gewöhnlichen Benutzern, die MAC-Adresse komfortabel in Konfigurationsmasken oder mit einfachen Dienstprogrammen wie ifconfig (UNIX, Linux) oder ip link (Linux) zu überschreiben. Gültige MAC-Adressen in einem Schicht-2-Netz können durch Abhören des Netzverkehrs ausfindig gemacht werden. Dazu ist lediglich der physische Zugang zum Netzwerk nötig. Die exklusive Vergabe von IP-Adressen nur an registrierte MAC-Adressen über RARP oder DHCP schließt also nicht aus, dass Unberechtigte Zugriff auf das Netzwerk erhalten; dafür ist der Einsatz eines sicheren Authentifizierungsmechanismus wie IEEE 802.1X notwendig. Eine Persiflage der Bemühungen, diese Probleme zu umgehen, ist das Wäscheklammerprotokoll Peg DHCP. DHCPv6 IPv6 benötigt für die eigentliche Adressvergabe keinen DHCP-Dienst (siehe IPv6 Autokonfiguration). Allerdings benötigt ein Client neben einem Gateway üblicherweise noch die Zuweisung eines DNS-Servers. Bislang gibt es kein verbreitetes Verfahren, diese zusätzlichen Informationen durch die Autokonfiguration dem Client zu übermitteln. Ein standardisiertes Verfahren für die Mitteilung der DNS-Server wird allerdings in RFC 6106 (RDNSS, DNSSL) beschrieben, so dass in einfachen Szenarien auf DHCPv6 verzichtet werden könnte. Für den beschriebenen Fall und Szenarien ist 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 von DHCPv4 läuft bei v6 die Kommunikation über die UDP-Ports 546 (Client) und 547 (Server). Literatur Spezifikationen RFC 2131 Dynamic Host Configuration Protocol für IPv4
Seite 8 von 8 RFC 2132 DHCP Options and BOOTP Vendor Extensions RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) RFC 3396 Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4) RFC 4361 Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) RFC 6221 Lightweight DHCPv6 Relay Agent RFC 6422 Relay-Supplied DHCP Options RFC 6644 Rebind Capability in DHCPv6 Reconfigure Messages Weblinks Links zum Thema DHCP (http://www.dmoz.org/computers/internet/protocols/dhcp/) im Open Directory Project Grundlagen zu DHCP (http://support.microsoft.com/kb/169289/de) Schaubild zur Verdeutlichung der Funktionsweise eines DHCP-Servers (http://www.microsoft.com/germany/technet/datenbank/articles/images/ch06xx09_big.gif) IPv6 Intelligence: DHCPv6 (http://ipv6int.net/software/index.html#dhcpv6), Beschreibung und Vergleich verschiedener DHCPv6-Software-Pakete (englisch) Liste aller DHCP-Options (Englisch) (http://www.networksorcery.com/enp/protocol/bootp/options.htm) Einzelnachweise 1. RFC 2131 Seite 10 unten. Link (english) (http://tools.ietf.org/html/rfc2131#page-10) Von http://de.wikipedia.org/w/index.php? title=dynamic_host_configuration_protocol&oldid=129590195 Kategorie: Internet-Anwendungsprotokoll Diese Seite wurde zuletzt am 17. April 2014 um 12:26 Uhr geändert. Abrufstatistik Der Text ist unter der Lizenz Creative Commons Attribution/Share Alike verfügbar; Informationen zum Lizenzstatus eingebundener Mediendateien (etwa Bilder oder Videos) können im Regelfall durch Anklicken dieser abgerufen werden. Möglicherweise unterliegen die Inhalte jeweils zusätzlichen Bedingungen. Durch die Nutzung dieser Website erklären Sie sich mit den Nutzungsbedingungen und der Datenschutzrichtlinie einverstanden. Wikipedia ist eine eingetragene Marke der Wikimedia Foundation Inc.