Dynamic Host Configuration Protocol – einfach erklärt

Grundidee und Nutzen

Das Dynamic Host Configuration Protocol (DHCP) ist ein Kommunikationsprotokoll der Internetprotokollfamilie. Ein DHCP-Server weist Clients automatisch ihre Netzwerkkonfiguration zu. Dadurch können Geräte ohne manuelle Konfiguration der Netzschnittstelle in ein bestehendes Netz eingebunden werden. Zu den übermittelbaren Angaben gehören insbesondere IP-Adresse, Netzwerkmaske, Default-Gateway und DNS-Server. Voraussetzung ist, dass das Betriebssystem des Clients DHCP unterstützt.

DHCP verwendet das verbindungslose Transportprotokoll UDP. Bei IPv4 kommuniziert der Server beziehungsweise Relay-Agent über UDP-Port 67 und der Client über UDP-Port 68. Das Protokoll wurde in RFC 2131 definiert. Es erweitert das ältere Bootstrap-Protokoll BOOTP und ist weitgehend dazu kompatibel, sodass eine eingeschränkte Zusammenarbeit mit BOOTP-Clients und -Servern möglich ist.

Ein DHCP-Server läuft als Hintergrundprozess, also als Dienst oder Daemon. Er wartet auf Anfragen und verwaltet einen Adresspool, aus dem IP-Adressen vergeben werden können. Seine Konfiguration enthält außerdem Netzparameter wie Subnetzmaske, lokale DNS-Domain und Gateway. Auch Angaben zu weiteren BOOTP-Servern oder zu einem Bootimage sind möglich.

Paketaufbau und Konfigurationsdaten

Ein DHCP-Paket enthält feste Felder und einen variablen Optionsbereich. Wichtige Felder sind:

„op“ (1 Byte): Kennzeichnet eine Anforderung mit request = 1 oder eine Antwort mit reply = 2.
„htype“ (1 Byte): Gibt den Netztyp an, beispielsweise 1 für Ethernet.
„hlen“ (1 Byte): Länge der physischen Netzadresse; bei einer Ethernet-MAC-Adresse beträgt sie gewöhnlich 6 Byte.
„hops“ (1 Byte, optional): Anzahl der durchlaufenen DHCP-Relay-Agents.
„xid“ (4 Byte): Identifiziert die Verbindung zwischen Client und Server.
„secs“ (2 Byte): Sekunden seit dem Start des Clients.
„flags“ (2 Byte): Das erste Bit zeigt an, ob der Client noch eine gültige IP-Adresse hat; die übrigen Bits sind reserviert.
„ciaddr“, „yiaddr“, „siaddr“ und „giaddr“ (je 4 Byte): Client-IP-Adresse, eigene zugewiesene IP-Adresse, Server-IP-Adresse und Relay-Agent-IP-Adresse.
„chaddr“ (16 Byte): Client-MAC-Adresse.
„sname“ (64 Byte, optional): Name eines gewünschten DHCP-Servers.
„file“ (128 Byte, optional): Name einer Datei, etwa eines System-Kernels, die per TFTP übertragen werden soll.
„options“ (variabel, optional): DHCP-Parameter und -Optionen nach RFC 2132.

Die Optionen können bis zu 312 Bytes lang sein. Damit kann ein IP-Paket insgesamt bis zu 576 Bytes umfassen: 236 Bytes DHCP-Header, 312 Bytes Optionen, 8 Bytes UDP-Header und 20 Bytes IPv4-Header. Client und Server können eine größere maximale Byteanzahl aushandeln.

DHCP kann neben IP-Adresse und Netzwerkmaske unter anderem Default-Gateway, primären und sekundären DNS-Server, DNS Context und DNS Tree, Time-Server nach RFC 868, NTP-Server, WINS-Server sowie eine Proxy-Konfiguration über WPAD zuweisen. Weitere Optionen sind möglich. Beispielsweise kann für eine Diskless-Workstation ein TFTP-Server angegeben werden; für einen PXE-Boot muss das BIOS beziehungsweise UEFI diese Zuweisung unterstützen.

Arten der Adresszuordnung

Ein DHCP-Server kennt drei grundlegende Betriebsmodi:

Bei der statischen Zuordnung ordnet der Server einer bestimmten MAC-Adresse dauerhaft eine feste IP-Adresse zu. Das eignet sich für Clients, die Server-Dienste anbieten oder wegen einer Port-Weiterleitung zuverlässig unter derselben Adresse erreichbar sein müssen. Weil die Adressen fest gebunden sind, können zusätzliche Clients gegebenenfalls nicht aufgenommen werden; unter Sicherheitsaspekten kann diese Begrenzung erwünscht sein.
Bei der automatischen Zuordnung definiert der Server einen Bereich von IP-Adressen. Eine Adresse wird einem neuen Client anhand seiner MAC-Adresse zugewiesen und dauerhaft in einer Tabelle gespeichert. Der Client erhält damit immer dieselbe Adresse, und diese wird keinem anderen Host zugeteilt. Ist der gesamte Bereich vergeben, erhalten neue Clients jedoch auch dann keine Adresse, wenn einzelne gespeicherte Adressen nicht mehr aktiv verwendet werden.
Bei der dynamischen Zuordnung wird eine IP-Adresse nur für eine begrenzte Lease-Time, also Leihdauer, vergeben. Der Client muss rechtzeitig eine Verlängerung beantragen. Geschieht das nicht, wird die Adresse wieder frei und kann einem anderen oder demselben Rechner zugeteilt werden. Manche Server bevorzugen abhängig von der MAC-Adresse auch nach längerer Abwesenheit wieder die frühere Adresse, sofern sie noch verfügbar ist.

Vergabe, Nachrichten und Verlängerung

Die initiale Vergabe folgt typischerweise einer Folge aus vier Nachrichten. Ein Client ohne IP-Adresse sendet zunächst DHCPDISCOVER als Broadcast. Dabei lauten die Absenderadresse 0.0.0.0 und die Zieladresse 255.255.255.255; verwendet werden UDP-Quellport 68 und UDP-Zielport 67. Die Nachricht enthält unter anderem die MAC-Adresse des Clients.

Erreichbare Server antworten mit DHCPOFFER und schlagen eine IP-Adresse sowie weitere Werte vor. Abhängig vom gesetzten Broadcast-Bit erfolgt die Antwort als Broadcast an 255.255.255.255 oder als Unicast an die vorgeschlagene IP-Adresse und die MAC-Adresse. Der Client wählt ein Angebot aus und sendet DHCPREQUEST als Broadcast. Ein Serveridentifier kennzeichnet den gewählten Server; andere Server erkennen daran, dass ihre Angebote abgelehnt wurden. Der ausgewählte Server bestätigt die Konfiguration mit DHCPACK oder lehnt die Anfrage mit DHCPNAK ab.

Vor der Verwendung sollte der Client mit einem ARP-Request prüfen, ob die zugewiesene Adresse bereits von einem anderen Rechner genutzt wird. Antwortet ein anderer Host, weist der Client die Adresse mit DHCPDECLINE zurück. DHCPRELEASE gibt eine Adresse vor Ablauf der Lease-Time freiwillig frei. DHCPINFORM dient dazu, zusätzliche Parameter anzufordern, beispielsweise bei bereits statisch eingestellter IP-Adresse.

Bei dynamischer Vergabe enthält DHCPACK neben der Lease-Time zwei Fristen. Die „renewal time“ T1 soll standardmäßig bei der Hälfte der Lease-Time liegen, die „rebinding time“ T2 bei 7/8 beziehungsweise 87,5 %. Der Server kann andere Werte vorgeben. Nach T1 bittet der Client den ursprünglichen Server per DHCPREQUEST-Unicast um Verlängerung. Ein DHCPACK erneuert gewöhnlich die Lease-Time.

Antwortet der ursprüngliche Server nicht, darf der Client die Konfiguration bis zum Ende der Lease-Time weiterverwenden. Nach T2 sendet er DHCPREQUEST als Broadcast, um einen beliebigen anderen Server zu erreichen. Läuft die Lease vollständig ab, muss der Client seine Netzwerkkarte dekonfigurieren und wieder mit DHCPDISCOVER beginnen. Auch nach DHCPNAK startet die Vergabe erneut. Gründe für DHCPNAK sind etwa eine inzwischen vergebene frühere Adresse oder der Wechsel des Clients in ein anderes Subnetz.

Subnetze, Relay, DNS und Active Directory

DHCP arbeitet zunächst mit Broadcasts. Da Router Broadcasts nicht weiterleiten und damit Broadcast-Domänen trennen, muss sich der Server entweder im selben Netzwerksegment wie der Client befinden oder ein DHCP-Relay-Agent eingesetzt werden. Dieser befindet sich funktional auf einer Router-Schnittstelle. Er nimmt die Broadcast-Anfrage des Clients entgegen und leitet sie als Unicast an einen oder mehrere DHCP-Server weiter. Dadurch ist nicht in jedem Subnetz ein eigener Server erforderlich.

Der Relay-Agent trägt die IP-Adresse der Schnittstelle, an der er den Broadcast empfangen hat, in den DHCP-Header ein. Der Server erkennt daran das Netzwerksegment und kann die passende Netzdefinition auswählen. Antworten erreichen den Relay-Agenten auf UDP-Port 67 und werden mit Zielport 68 an den Client weitergeleitet. Ein Server kann außerdem mehrere direkt angeschlossene Netze bedienen; beim Start lässt sich festlegen, auf welchen Netzwerkschnittstellen er Anfragen annimmt.

Mehrere DHCP-Server können die Ausfallwahrscheinlichkeit verringern. Ihre Adressbereiche dürfen sich jedoch nicht überschneiden, weil sonst dieselbe IP-Adresse mehrfach vergeben werden kann. Über die Einstellung „authoritative“ lässt sich bestimmen, ob ein Server auch dann DHCPNAK sendet, wenn er für die vorgeschlagene Adresse nicht zuständig ist.

Für die Namensauflösung registrieren Computer gewöhnlich ihren Namen und ihre IP-Adresse bei einem DNS-Server. Einige DHCP-Server übernehmen diese Registrierung für die Clients. In einem Active Directory ist der DHCP-Dienst in die AD-Datenbank integriert. Nur autorisierte Server dürfen Leases verteilen; zur Autorisierung muss ein Server Domain Controller sein oder ein Domänenkonto besitzen.

Sicherheit und DHCPv6

DHCP lässt sich leicht stören oder manipulieren, weil Clients grundsätzlich jeden DHCP-Server akzeptieren. Schon ein versehentlich angeschlossener DSL- oder WLAN-Router mit aktivem DHCP kann schneller als der vorgesehene Server antworten und ungültige Konfigurationen verteilen.

Bei einer DHCP Starvation Attack reserviert ein Angreifer alle verfügbaren Adressen. Anschließend kann er als einziger Server auftreten und rogue DHCP Spoofing betreiben. Durch falsche DNS-, Gateway- oder Subnetzangaben sind Denial-of-Service- und Man-in-the-Middle-Angriffe möglich: Datenverkehr kann blockiert, mitgeschnitten oder umgeleitet werden.

Die MAC-Adresse ist kein zuverlässiges Sicherheitsmerkmal, da sie leicht überschrieben werden kann. Gültige Adressen lassen sich außerdem durch Abhören eines Schicht-2-Netzes ermitteln. Eine Beschränkung auf registrierte MAC-Adressen über RARP oder DHCP verhindert daher keinen unberechtigten Zugriff. Dafür ist ein sicherer Authentifizierungsmechanismus wie IEEE 802.1X erforderlich.

Bei IPv6 ist DHCP für die eigentliche Adressvergabe nicht zwingend nötig, weil IPv6 die statuslose Autokonfiguration besitzt. Für DNS-Server existiert mit RFC 8106 ein standardisiertes Verfahren über RDNSS und DNSSL. Werden weitere Angaben benötigt, kann DHCPv6 ergänzend oder anstelle der Autokonfiguration eingesetzt werden.

DHCPv6 ist seit Juli 2003 in RFC 3315 spezifiziert. Es bietet für IPv6 eine ähnliche Funktionalität wie DHCPv4 und kann über optionale Felder Informationen zu NIS+-, SIP-, NTP- und weiteren Diensten übertragen. Es besitzt integrierte Sicherheitsfunktionen, mit denen der Dienst auf autorisierte Clients beschränkt werden kann. Außerdem kann die Adresse weiterhin statuslos konfiguriert werden, während DHCPv6 nur zusätzliche Konfigurationsdetails liefert. Abweichend von DHCPv4 verwendet DHCPv6 UDP-Port 546 für Clients und UDP-Port 547 für Server beziehungsweise Relay-Agents.