Das Dynamic Host Configuration Protocol, ist aus heutiger Sicht in einer modernen Netzwerkinfrastruktur nicht mehr wegzudenken.
Wenn DHCP aktiviert ist ermöglicht es eine automatisierte IP-Vergabe in einem Netzwerk. Gerade in größeren Netzwerken, wie beispielsweise Firmennetzwerken aber auch in gängigen Heimnetzwerken, wie zum Beispiel die IP-Releases über den DHCP-Dienst der Fritzbox, ist heute als Standard für eine IP-Vergabe an Endgeräte automatisch konfiguriert und eingestellt.
Es muss also keine manuelle IP-Vergabe mehr durchgeführt werden. Das Protocol kümmert sich aber nicht nur um eine IP-Vergabe an ein Endgerät, sondern liefert zusätzlich die wichtigsten Netzwerkparameter (später mehr) automatisiert mit. Dieses Protokoll arbeitet auf Layer 7 (Application Layer) des OSI-Modells.
Das Dynamic Configuration Host Protocol arbeitet nach dem Client-Server Prinzip. Wenn ein Client in ein Netzwerk eingebunden wird, fragt dieser im Normalfall bei einem zugehörigen DHCP-Server eine IP-Konfiguration an. Der bereits konfigurierte Server verfügt über einen sogenannten Pool (Bereich) von IP-Adressen, die er vergeben kann.
Damit der Client über eine IP-Adresse verfügen kann, muss dieser mit dem DHCP-Server kommunizieren. Dies ist anfangs jedoch nicht über direktem Wege möglich. Denn der Client verfügt über keine gültige IP-Adresse, keine Subnetzmaske oder gar Gateway, über den der Client den Server erreichen kann. Das Einzige, was der Client vorweisen kann, ist seine MAC-Adresse.
Im Folgenden werden die einzelnen Schritte erklärt, wie der Client eine Verbindung zum DHCP aufbaut und eine IP-Konfiguration durch den Server bekommt. Dieses Verfahren wird auch als „DORA“-Prinzip bezeichnet.
Damit der Client den zugehörigen DHCP-Server erreichen kann, schickt der Client ein UDP-Paket mit einer Broadcast-Anfrage (auf Layer 2 sowie Layer 3) und der Quell-Adresse 0.0.0.0. (siehe Abbildung 1) Kurzgesagt bedeutet Broadcast, dass das Paket an alle erreichbaren Endgeräte innerhalb eines Netzes gesendet wird und das gesuchte Gerät antwortet. Die restlichen Geräte verwerfen das Paket einfach.
Ist der DHCP-Server nicht im gleichen Subnetz wie der anfragende Client angesiedelt, muss die Anfrage vom Client ausgehend über einen DHCP-Relay Agent bearbeitet werden, da Broadcast-Anfragen über ein Subnetz hinaus nicht geroutet werden. Der Relay Agent ist meist auf einem Router bzw. Switch mit Routing Funktion implementiert und sendet die Anfrage des Clients im Uni-Cast weiter an den angeforderten DHCP-Server.
Der Server antwortet darauf mit einem Offer (Angebot). Er schlägt dem Client eine freie IP-Adresse vor und schickt diese zusammen mit anderen wichtigen Netzwerk-Parametern (siehe später) mithilfe eines MAC-Unicast (vorausgesetzt, der Server liegt im gleichen Subnetz wie der anfragende Client) an den Client zurück.
Liegt der DHCP-Server in einem anderen Subnetz wie der anfragende Client, schickt der Server seine Informationen im Uni-Cast zurück an den DHCP-Relay Agent und dieser im MAC-Unicast an den gewünschten Client. (siehe Abbildung 2).
Damit überprüft werden kann, ob die vorgeschlagene IP-Adresse gültig ist, die von dem Server zur Verfügung gestellt wurde oder zwischenzeitlich ein anderer Client diese IP-Adresse zugeordnet wurde, überprüft der anfragende Client mithilfe eines ARP-Request, ob die vorliegende IP-Adresse noch gültig ist. Ist dies der Fall, sendet der Client einen Request zurück an den Server und bittet um die Konfiguration.
Nach Erhalt des erfolgreichen Requests des Clients schaut der Server, ob die Konfiguration bis dato immer noch frei ist und sendet, wenn dies der Fall ist, die IP-Konfiguration an den Client.
Je nach Konfiguration können folgende Netzwerk-Parameter mitgeliefert werden:
All diese Daten in der Konfiguration werden als „LEASE“ bezeichnet. Dieser LEASE ist nur für eine bestimmte Zeit gültig. Dies bedeutet, dass der Client die Konfiguration nur für eine bestimmte Zeit zur Verfügung gestellt bekommt.
Nach ungefähr 50 % der Leasedauer sendet der Client erneut einen Request im Uni-Cast an den DHCP-Server (siehe Abbildung 2) und fragt nach einer Erneuerung des Leases. Ist der Lease noch gültig, sendet der DHCP-Server mithilfe eines Acknowlege die Bestätigung der Erneuerung des Leases. Die Lease wird also wieder erneut gültig.
Die Zuweisung der Adressen kann dabei auf drei unterschiedliche Weisen verfolgen:
Die IP-Adressen werden anhand der MAC-Adressen fest zugeordnet. Die Adresse wird dabei zeitlich unbeschränkt zugeordnet. Eine Anwendung wäre z.B. ein Drucker, der immer unter der gleichen Adresse erreichbar sein sollte.
Der DHCP-Server verfügt über einen Bereich (Pool) von IP-Adressen. Wenn die Adresse aus diesem Bereich einmal einem Client zugeordnet wurde, dann gehört sie diesem auf unbestimmte Zeit., denn auch hier wird die IP-Adresse an die MAC-Adresse gebunden. Diese Zuordnung geht auch nicht verloren, wenn der Client ausgeschaltet wird, da die Zuordnung im Cache des DHCP-Servers gespeichert wird.
Wenn der anfragende Client keine DHCP-Konfiguration erhalten sollte, weil der Service nicht erreichbar oder gar ausgefallen ist, verwendet der Client eine sogenannte APIPA-Adresse. (Automatic Private IP-Adressing). Dadurch ist der Client in der Lage, lokal weiterarbeiten zu können. Er stellt jedoch in der Regel keine gültige Verbindung zum Netzwerk her. (außer andere Clients besitzen auch eine APIPA-Adresse). Der Client versucht alle 10 Minuten eine gültige Adresse zu beziehen. APIPA dient also auch zur Fehlersuche.
Der Bereich, in dem sich APIPA befindet ist: 169.254.X.X /16. (Klasse B)
