DHCP

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

Das Dynamic Host Configuration Protocol wurde definiert im RFC 2131 und bekam von der Internet Assigned Numbers Authority (IANA) die UDP-Ports 67 und 68 zugewiesen.

Konzept

Durch DHCP ist die vollautomatische Einbindung eines neuen Computers in ein bestehendes Netzwerk ohne weitere Konfiguration (Computer)|Konfiguration möglich. Am Client muss im Normalfall lediglich der automatische Bezug der IP-Adresse eingestellt sein. Beim Start des Rechners am Netz kann er die IP-Adresse, Netzmaske, Gateway (Computer)|Gateway, Domain Name System (DNS)-Server und ggf. noch Windows Internet Naming Service|WINS-Server von einem DHCP-Server automatisch beziehen. Ohne DHCP sind dazu – abhängig vom Netzwerk, an das der Rechner angeschlossen werden soll – relativ aufwändige Einstellungen nötig.

DHCP ist eine Erweiterung des BOOTP-Protokolls, mit dem sich laufwerklose 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 booten. 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 wollen und sich nicht näher mit der Netzwerkkonfiguration beschäftigen wollen.

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 Systemadministrator|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. 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.

Aufbau eines DHCP-Paketes

32 Bit
op	htype	hlen	hops
xid
secs		flags
ciaddr
yiaddr
siaddr
giaddr
chaddr
sname
file
options

• op (1 Byte): Information, ob es sich um eine Anforderung (request = 1) oder eine Antwort (reply = 2) handelt
• htype (1 Byte): Netztyp (z. B. 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. ist 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
• sname (64 Byte, optional): Name des DHCP-Servers, falls ein bestimmter gefordert wird
• file (128 Byte, optional): Name einer Datei (z. B. System-Kernel), welche vom Server per Trivial File Transfer Protocol|TFTP an den Client gesendet werden soll
• options (312 Byte, optional): DHCP-Parameter und -Optionen

Der DHCP-Server

Der DHCP-Server wird – wie alle Netzwerkdienste – als Hintergrundprozess (Daemon oder Dienst) gestartet und wartet auf User Datagram Protocol|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 Domäne (Internet)|DNS-Domäne 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 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. Dies 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 definiert. Wenn die Adresse aus diesem Bereich einmal einem DHCP-Client zugeordnet wurde, dann gehört sie diesem auf unbestimmte Zeit, denn auch hier wird die zugewiesene IP-Adresse an die MAC-Adresse gebunden. Ist der Adressbereich komplett vergeben, so können sich keine zusätzlichen Clients in das Netz einbinden. Das geht auch dann nicht, wenn die Rechner gar nicht aktiv (eingeschaltet) sind, denn im Cache des DHCP-Servers wird die IP-Adresse gespeichert. Es hilft dann nur ein Löschen des Caches, um die an nicht aktive Rechner vergebenen Adressen verwenden zu können.

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 „vermietet“ 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: „Mietzeit“).

DHCP-Kommandos

• 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 erstmalig 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-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. Dies 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 dies als Absage für ihre 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. Dies geschieht üblicherweise durch einen Address Resolution Protocol|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. 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 weiteres 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 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, die jedoch inzwischen nicht mehr verfügbar ist (Lease abgelaufen und anderweitig vergeben), 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 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.

DHCP und DNS

Einige DHCP-Server können mit dem Domain Name System|DNS zusammenarbeiten, indem sie IP-Adresse, Rechnernamen und "lease time" an den DNS-Server weiterleiten. Damit ist eine Namensauflösung für Arbeitsstationen auch in Netzen mit DHCP bequem möglich. Dies ist allerdings nicht die Regel. Im Normalfall kommuniziert der Client direkt mit dem DNS-Server. Lediglich bei älteren Windows-Betriebssystemen (älter als Windows 2000) muss diese Aufgabe vom DHCP-Server übernommen werden.

Mögliche Zuweisungen

Standardmäßig kann DHCP dem Client folgende Einstellungen zuweisen:

• IP-Adresse und Netzwerkmaske
• Default-Gateway
• Nameserver
• WINS-Server
• Proxy-Konfiguration (nicht bei Windows Systemen)

DHCP für mehrere Subnetze

Der DHCP-Server kann Subnetze bedienen, wenn er über Definitionen für die jeweilige Netzwerkkarte verfügt. Die Auswahl der Definition bestimmt dann die Netzwerkkarte, über welche die Anforderung hereinkommt. Beim Start des DHCP-Servers kann angegeben werden, auf welche Interfaces der Server hört.

Andererseits kann ein DHCP-Server auch über eine Netzwerkkarte mehrere Subnetze bedienen, wenn diese durch einen DHCP-Relay-Agenten verbunden sind, der die DHCP-Befehle weiterreicht.

Sicherheit

DHCP basiert auf User Datagram Protocol. Es ist somit leicht manipulierbar.

Weiterhin wäre es möglich, alle Adressen eines DHCP-Servers zu reservieren, anschließend selbst als DHCP-Server aufzutreten (DHCP-Spoofing) und dann entweder nur falsche Informationen an anfragende Clients weiterzureichen (z. B. immer dieselbe IP-Adresse oder nicht vorhandene Gateways) oder z. B. Gateway- und DNS-IP-Adressen auf andere Rechner umzuleiten, um auch diese Protokolle zu Technische Kompromittierung|kompromittieren.

Um dieses Problem zu umgehen, wird gelegentlich auch Peg DHCP nach RFC 2322 verwendet.

Weitere Probleme treten bei Verwendung von Secure Shell auf, da sich ein SSH-Client bei jeder Rechnerverbindung den Namen und die IP-Adresse merkt und eine Änderung, wie z. B. eine neue IP-Adresse, als Angriff wertet.

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 Domain Name System|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-Request for Comments|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 Network Information Service|NIS+-, Session Initiation Protocol|SIP-, Network Time Protocol|NTP- und weitere Dienste zu transportieren. Welche Optionen in DHCPv6 aufgenommen werden, wird von der DHCP-Arbeitsgruppe der Internet Engineering Task Force|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).

Konfiguration

Der folgende Absatz stammt nicht aus dem angegebenen Wikiimport.

Autor: na-cx

Bei Problemen mit DHCP die entsprechende Datei /etc/dhcpd.conf hier posten.

/etc/dhcpd.conf

option domain-name "server.home";
option domain-name-servers 192.168.0.1;
option routers 192.168.0.1;
default-lease-time 14400;
ddns-update-style none;
subnet 192.168.0.0 netmask 255.255.255.0 {
       range 192.168.0.100 192.168.0.199;
       default-lease-time 14400;
       max-lease-time 172800;
       }
group {
host client1 {
       hardware ethernet XX:XX:XX:XX:XX:XX;
       fixed-address 192.168.0.10;
       }
host client2 {
       hardware ethernet XX:XX:XX:XX:XX:XX;
       fixed-address 192.168.0.20;
       }
}

/etc/sysconfig/dhcpd

DHCPD_INTERFACE="eth-id-XX:XX:XX:XX:XX:XX"
DHCPD_RUN_CHROOTED="yes"
DHCPD_CONF_INCLUDE_FILES=""
DHCPD_RUN_AS="dhcpd"
DHCPD_OTHER_ARGS=""
DHCPD_BINARY=""

/etc/sysconfig/network/config

DEFAULT_BROADCAST="+"
GLOBAL_POST_UP_EXEC="yes" 
GLOBAL_PRE_DOWN_EXEC="yes"
CHECK_DUPLICATE_IP="no"
DEBUG="no"
USE_SYSLOG="yes"
MODIFY_RESOLV_CONF_DYNAMICALLY="no"
MODIFY_NAMED_CONF_DYNAMICALLY="yes"
CONNECTION_SHOW_WHEN_IFSTATUS="no"
CONNECTION_CHECK_BEFORE_IFDOWN="no"
CONNECTION_CLOSE_BEFORE_IFDOWN="no"
CONNECTION_UMOUNT_NFS_BEFORE_IFDOWN="no"
CONNECTION_SEND_KILL_SIGNAL="no"
MANDATORY_DEVICES=""
WAIT_FOR_INTERFACES="20"
FIREWALL="yes"
FAILURE_ACTION="off"
LINKLOCAL_INTERFACES="eth*[0-9]|tr*[0-9]|wlan[0-9]|ath[0-9]"
IFPLUGD_OPTIONS="-f -I -u 0 -d 10"
USE_IPV6="yes"

Quellen und weiterführende Links

• DHCP Musterkonfigurationen
• RFC 2131 – Dynamic Host Configuration Protocol für IPv4
• RFC 3315 – Dynamic Host Configuration Protocol für IPv6
• Links zu dem Thema „DHCP“ aus dem Open Directory Project (Eintrag aus der Wikipedia)

Dieser Artikel ist aus der Wikipedia mit der dortigen Lizenz GFDL (Wikipedia) übernommen worden. Die Quelle in der Wikipedia unter DHCP ist zum Zeitpunkt der Einfügung identisch mit dem, was im Linux-Cub Wiki unter DHCP steht. Der Artikel kann gerne überarbeitet werden. Wenn der Artikel der Quelle im Wortlaut nicht mehr entspricht, kann der Baustein entfernt werden, es muss aber die Quellenangabe unten eingefügt werden. Zudem sollte dann der Bausteine Vorlage:GFDL eingefügt werden, da der Artikel dann unter diese Lizenz fällt. In der Wikipedia ist eine Liste der Autoren verfügbar.

---

zurück zur DNS