Kommunikationsmodell

Wenn ein Client neu in ein Netz hineinkommt und den DHCP-Service nutzen soll um sich eine IP-Adresse zuweisen zu lassen, hat er in der Regel noch keine IP-Adresse. Eine solche Adresse ist aber normalerweise nötig, um in einem IP-Netzwerk zu kommunizieren.

Aus diesem Grund muß eine Übertragungsart gewählt werden, die jedes System im Netz empfangen kann, auch wenn es noch keine eigene IP-Adresse hat: BROADCAST.

Broadcast-Pakete sind Pakete, welche jeder in diesem Netz aktive Rechner empfangen kann. Sie sind an die sogenannte Broadcast-Adresse des Netzes adressiert.

Auf diese Art und Weise werden die meisten Daten im DHCP-Protokoll ausgetauscht.

Um Daten per Broadcast zu übermitteln, hat jedes Paket eine spezielle Form, je nachdem, welchen Typ von Daten es enthält. So sieht die Anfrage nach einer Konfiguration anders aus, als die Bestätigung einer IP-Address-Zuweisung.

Es werden also alle Informationen in einem einzigen Nachrichtenpaket untergebracht und versendet. In einem solchen Fall würde ein kompletter Verbindungsauf- und Verbindungsabbau, wie man ihn bei TCP/IP hat, einen übermäßigen Protokoll-Overhead produzieren. Deshalb werden alle Informationen über UDP übertragen.

Dabei muß man in Kauf nehmen, daß bei UDP Bei der Verwendung von UDP muß man in Kauf nehmen, daß die Möglichkeit besteht, daß einzelne Nachrichtenpakete verloren gehen und ihren Empfänger nicht erreichen. Diesem Problem kann man im Protokolldesign und in der programmtechnischen Umsetzung entgegen wirken.

So kann man zum Beispiel den Empfang von Daten extra bestätigen lassen:

1.

Schritt: Absenden der Daten

2.

Schritt: Der Empfänger bestätigt den Empfang der Daten

3.

Schritt: der Sender bestätigt den Empfang der Bestätigung oder schickt die nächsten Daten

Bei einem solchen Vorgehen ist es auch erlaubt, daß die Empfangsbestätigung der Empfangsbestätigung verloren geht und das Protokoll deshalb nicht abgebrochen werden muß. Der Verlust anderer Pakete fällt ebenfalls auf.

Die untenstehende Tabelle gibt einen Überblick über die verschiedenen, im DHCP-Protokoll verwendeten Pakettypen sowie über die Auswirkungen, wenn eines der Pakete verloren geht. Der leichteren Zuordbarkeit ist die Funktion des jeweiligen Paketes mit angegeben.

 

Abbildung: DHCP: State-Diagramm DHCP-Client nach [Dro97]

Paketbezeichnung	Funktion	Folge bei Paketverlust
DHCPDISCOVER	Aufforderung an alle DHCP-Server im Netz, ein Angebot zu schicken, welche Daten der Client vom jeweiligen Server erhalten könnte.	Der Client bekommt auf dieses verlorene Paket keine Antwort von einem DHCP-Server, da die Anfrage nach seiner Existenz verloren gegangen ist. Im schlimmsten Fall bekommt der Client als Folge keine IP-Adresse.
DHCPOFFER	Das Angebot der jeweiligen Server, welche Daten sie dem Client geben können.	Der Client bekommt vom Server das Angebot nicht, kann es also nicht auswählen. Im schlimmsten Fall verfällt das Angebot serverseitig und der Client bekommt mangels IP-Adresse keinen Netzzugang.
DHCPREQUEST	Paket des Clients an die Server. Es enthält die Daten des ausgewählten Angebotes.	Der Server bekommt die explizite Anfrage nicht, kann somit keine endgültige Vergabe der Ressource durchführen und dem Client nicht auf seine Anfrage antworten. Der Client bekommt entweder keinen Netzzugang oder arbeitet das Anmeldeprotokoll von vorne nochmals ab, da er diesmal keine Antwort bekommen hat.
DHCPACK /
DHCPNACK	Endgültige Bestätigung/Ablehnung des Servers an den Client, die Daten aus dem DHCPREQUEST -Paket für diesen Client zu verwalten.	Die endgültige Bestätigung der Ressourcenvergabe geht verloren, der Client ist in einem Schwebezustand und der Server hat die Ressource auf diesen Client bereits festgelegt. Sollte sich daran nichts ändern, bekommt der Client keinen Netzzugang und nach Ablauf der Leased Time wird im Server die vergebene Adresse wieder freigegeben (wegen Zeitüberschreitung). Handelt es sich um ein ACK auf ein DHCPINFORM , kann der Client die benötigten Daten nicht verwenden, da sie im ACK -Paket enthalten sind.

Paketbezeichnung	Funktion	Folge bei Paketverlust
DHCPRELEASE	Explizite Aufforderung des Clients an den Server, die diesem Client zugeordneten Daten wieder frei zu geben.	Der Server kann die vom Client freigegebenen Ressourcen nicht freigeben, da er die vorzeitige Freigabe nicht bekommt. Die Ressourcen werden nach Ablauf der Leased Time verspätet freigegeben.
DHCPINFORM	Anfrage des Clients an DHCP-Server, nach den allgemeinen Konfigurationsparametern des Netzes. (z.B. Gateway, Netmask, aber auch Drucker und andere Services)	Der Client bekommt vom Server keine Antwort, weil dieser die Anfrage nach den Konfigurationsdaten nicht bekommen hat.

  

Abbildung: DHCP: Ausführliches Protokoll-Fluß-Bild

[DHCP: Relay über Netzgrenzen hinweg]DHCP: Relay über Netzgrenzen hinweg 

Den Ablauf des DHCP-Protokolls stellt Abbildung 3.6 dar. Dabei wird von zwei aktiven DHCP-Servern im Netz ausgegangen.

In der Darstellung fehlt der Ablauf bei der Verwendung von DHCPINFORM . Dieser sieht vor, daß die mit DHCPINFORM  angeforderten Konfigurationsdaten in einem DHCPACK -Paket versendet werden.

DHCP-Relay

]DHCP-Relay In manchen Netzen werden Broadcast-Pakete von aktiven Komponenten (z.B. Router) gefiltert und nicht weitergleitet. Dies verhindert die Verwendung von DHCP. Um DHCP trotzdem verwenden zu können, wurde ein DHCP-Relay entwickelt. Dabei handelt es sich um eine Art Proxy für DHCP.

Dabei werden die Broadcast-Pakete von einer Komponente (DHCP-Relay) empfangen, in ein anderes IP-Paket umgesetzt und direkt an den DHCP-Server gesendet. Dieser sendet dann seine Antworten an den DHCP-Relay zurück, welcher sie in ein Broadcast-Paket umsetzt und im richtigen Netzsegment wieder weiterleitet. Abbildung 3.7 stellt diesen Vorgang dar.