2. Protokollzusammenfassung (Protocol Summary)
Aus Sicht eines Clients ist DHCP eine Erweiterung des BOOTP-Mechanismus. Dieses Verhalten ermöglicht es bestehenden BOOTP-Clients, mit DHCP-Servern zu interoperieren, ohne dass Änderungen an der Initialisierungssoftware der Clients erforderlich sind. RFC 1542 [2] beschreibt detailliert die Interaktionen zwischen BOOTP- und DHCP-Clients und -Servern [9]. Es gibt einige neue optionale Transaktionen, die die Interaktion zwischen DHCP-Clients und -Servern optimieren und in den Abschnitten 3 und 4 beschrieben werden.
Abbildung 1 zeigt das Format einer DHCP-Nachricht und Tabelle 1 beschreibt jedes der Felder in einer DHCP-Nachricht. Die Zahlen in Klammern geben die Größe jedes Feldes in Oktetten an. Die in der Abbildung angegebenen Feldnamen werden in diesem Dokument durchgehend verwendet, um auf die Felder in DHCP-Nachrichten zu verweisen.
Es gibt zwei wesentliche Unterschiede zwischen DHCP und BOOTP. Erstens definiert DHCP Mechanismen, durch die Clients eine Netzwerkadresse für eine endliche Leasingdauer zugewiesen werden kann, was eine serielle Neuzuweisung von Netzwerkadressen an verschiedene Clients ermöglicht. Zweitens bietet DHCP den Mechanismus für einen Client, alle IP-Konfigurationsparameter zu erwerben, die er für den Betrieb benötigt.
DHCP führt eine kleine terminologische Änderung ein, die dazu dient, die Bedeutung eines der Felder zu klären. Was in BOOTP das Feld „Vendor Extensions" war, wurde in DHCP in das Feld „Options" umbenannt. Ebenso werden die markierten Datenelemente, die innerhalb des BOOTP-Feldes „Vendor Extensions" verwendet wurden und früher als „Vendor Extensions" bezeichnet wurden, nun einfach als „Options" bezeichnet.
Format einer DHCP-Nachricht (Format of a DHCP message)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| op (1) | htype (1) | hlen (1) | hops (1) |
+---------------+---------------+---------------+---------------+
| xid (4) |
+-------------------------------+-------------------------------+
| secs (2) | flags (2) |
+-------------------------------+-------------------------------+
| ciaddr (4) |
+---------------------------------------------------------------+
| yiaddr (4) |
+---------------------------------------------------------------+
| siaddr (4) |
+---------------------------------------------------------------+
| giaddr (4) |
+---------------------------------------------------------------+
| |
| chaddr (16) |
| |
| |
+---------------------------------------------------------------+
| |
| sname (64) |
+---------------------------------------------------------------+
| |
| file (128) |
+---------------------------------------------------------------+
| |
| options (variable) |
+---------------------------------------------------------------+
Abbildung 1: Format einer DHCP-Nachricht
DHCP definiert eine neue Option „Client Identifier", die verwendet wird, um eine explizite Client-Identifikation an einen DHCP-Server zu übergeben. Diese Änderung beseitigt die Überladung des Feldes „chaddr" in BOOTP-Nachrichten, wo „chaddr" sowohl als Hardwareadresse für die Übertragung von BOOTP-Antwortnachrichten als auch als Client-Identifikation verwendet wurde. Der „Client Identifier" ist ein undurchsichtiger Schlüssel, der vom Server nicht interpretiert werden darf; beispielsweise kann der „Client Identifier" eine Hardwareadresse enthalten, die mit dem Inhalt des Feldes „chaddr" identisch ist, oder er kann einen anderen Identifikatortyp enthalten, wie z. B. einen DNS-Namen. Der von einem DHCP-Client gewählte „Client Identifier" MUSS innerhalb des Subnetzes, mit dem der Client verbunden ist, für diesen Client eindeutig sein. Wenn der Client in einer Nachricht einen „Client Identifier" verwendet, MUSS er denselben Identifikator in allen nachfolgenden Nachrichten verwenden, um sicherzustellen, dass alle Server den Client korrekt identifizieren.
DHCP klärt die Interpretation des Feldes „siaddr" als die Adresse des Servers, der im nächsten Schritt des Bootstrap-Prozesses des Clients verwendet werden soll. Ein DHCP-Server kann seine eigene Adresse im Feld „siaddr" zurückgeben, wenn der Server bereit ist, den nächsten Bootstrap-Dienst bereitzustellen (z. B. die Bereitstellung eines ausführbaren Betriebssystem-Images). Ein DHCP-Server gibt immer seine eigene Adresse in der Option „Server Identifier" zurück.
Beschreibung der Felder in einer DHCP-Nachricht (Description of fields in a DHCP message)
| Feld | Oktette | Beschreibung |
|---|---|---|
| op | 1 | Nachrichten-Opcode / Nachrichtentyp. 1 = BOOTREQUEST, 2 = BOOTREPLY |
| htype | 1 | Hardware-Adresstyp, siehe ARP-Abschnitt in „Assigned Numbers" RFC; z. B. '1' = 10mb Ethernet. |
| hlen | 1 | Hardware-Adresslänge (z. B. '6' für 10mb Ethernet). |
| hops | 1 | Wird vom Client auf Null gesetzt, optional von Relay-Agenten beim Booten über einen Relay-Agenten verwendet. |
| xid | 4 | Transaktions-ID, eine vom Client gewählte Zufallszahl, die vom Client und Server verwendet wird, um Nachrichten und Antworten zwischen einem Client und einem Server zuzuordnen. |
| secs | 2 | Wird vom Client ausgefüllt, Sekunden seit Beginn des Adresserwerbs- oder Erneuerungsprozesses durch den Client. |
| flags | 2 | Flags (siehe Abbildung 2). |
| ciaddr | 4 | Client-IP-Adresse; nur ausgefüllt, wenn sich der Client im Zustand BOUND, RENEW oder REBINDING befindet und auf ARP-Anfragen antworten kann. |
| yiaddr | 4 | 'Ihre' (Client-)IP-Adresse. |
| siaddr | 4 | IP-Adresse des nächsten Servers, der beim Bootstrap verwendet werden soll; wird in DHCPOFFER, DHCPACK vom Server zurückgegeben. |
| giaddr | 4 | Relay-Agent-IP-Adresse, wird beim Booten über einen Relay-Agenten verwendet. |
| chaddr | 16 | Client-Hardwareadresse. |
| sname | 64 | Optionaler Server-Hostname, null-terminierte Zeichenkette. |
| file | 128 | Boot-Dateiname, null-terminierte Zeichenkette; „generischer" Name oder null in DHCPDISCOVER, vollqualifizierter Verzeichnispfadname in DHCPOFFER. |
| options | var | Optionales Parameterfeld. Siehe die Options-Dokumente für eine Liste der definierten Optionen. |
Tabelle 1: Beschreibung der Felder in einer DHCP-Nachricht
Das Feld „options" ist nun variabel lang. Ein DHCP-Client muss bereit sein, DHCP-Nachrichten mit einem „options"-Feld von mindestens 312 Oktetten Länge zu empfangen. Diese Anforderung impliziert, dass ein DHCP-Client bereit sein muss, eine Nachricht von bis zu 576 Oktetten zu empfangen, die minimale IP-Datagrammgröße, die ein IP-Host empfangen können muss [3]. DHCP-Clients können die Verwendung größerer DHCP-Nachrichten über die Option „Maximum DHCP Message Size" aushandeln. Das options-Feld kann weiter in die Felder „file" und „sname" erweitert werden.
Im Fall eines Clients, der DHCP für die Erstkonfiguration verwendet (bevor die TCP/IP-Software des Clients vollständig konfiguriert ist), erfordert DHCP eine kreative Nutzung der TCP/IP-Software des Clients und eine liberale Interpretation von RFC 1122. Die TCP/IP-Software SOLLTE alle IP-Pakete, die an die Hardwareadresse des Clients geliefert werden, akzeptieren und an die IP-Schicht weiterleiten, bevor die IP-Adresse konfiguriert ist; DHCP-Server und BOOTP-Relay-Agenten können möglicherweise keine DHCP-Nachrichten an Clients liefern, die keine Hardware-Unicast-Datagramme akzeptieren können, bevor die TCP/IP-Software konfiguriert ist.
Um einige Clients zu umgehen, die keine IP-Unicast-Datagramme akzeptieren können, bevor die TCP/IP-Software wie im vorherigen Absatz beschrieben konfiguriert ist, verwendet DHCP das Feld „flags" [21]. Das äußerste linke Bit ist als BROADCAST (B)-Flag definiert. Die Semantik dieses Flags wird in Abschnitt 4.1 dieses Dokuments diskutiert. Die verbleibenden Bits des flags-Feldes sind für zukünftige Verwendung reserviert. Sie MÜSSEN von Clients auf Null gesetzt und von Servern und Relay-Agenten ignoriert werden. Abbildung 2 zeigt das Format des Feldes „flags".
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B: BROADCAST-Flag
MBZ: MUSS NULL SEIN (MUST BE ZERO) (für zukünftige Verwendung reserviert)
Abbildung 2: Format des 'flags'-Feldes
2.1 Konfigurationsparameter-Repository (Configuration parameters repository)
Der erste von DHCP bereitgestellte Dienst besteht darin, persistenten Speicher für Netzwerkparameter für Netzwerk-Clients bereitzustellen. Das Modell des persistenten DHCP-Speichers ist, dass der DHCP-Dienst für jeden Client einen Schlüssel-Wert-Eintrag speichert, wobei der Schlüssel eine eindeutige Kennung ist (z. B. eine IP-Subnetz-Nummer und eine eindeutige Kennung innerhalb des Subnetzes) und der Wert die Konfigurationsparameter für den Client enthält.
Beispielsweise könnte der Schlüssel das Paar (IP-subnet-number, hardware-address) sein, was eine serielle oder gleichzeitige Wiederverwendung einer Hardwareadresse in verschiedenen Subnetzen und für Hardwareadressen ermöglicht, die möglicherweise nicht global eindeutig sind. Alternativ könnte der Schlüssel das Paar (IP-subnet-number, hostname) sein, was es dem Server ermöglicht, Parameter intelligent einem DHCP-Client zuzuweisen, der in ein anderes Subnetz verschoben wurde oder seine Hardwareadresse geändert hat (möglicherweise aufgrund eines Netzwerkschnittstellenfehlers und eines Hardware-Austauschs). Das Protokoll definiert, dass der Schlüssel (IP-subnet-number, hardware-address) sein wird, es sei denn, der Client liefert explizit eine Kennung unter Verwendung der Option „Client Identifier". Ein Client kann den DHCP-Dienst abfragen, um seine Konfigurationsparameter abzurufen. Die Client-Schnittstelle zum Konfigurationsparameter-Repository besteht aus Protokollnachrichten zum Anfordern von Konfigurationsparametern und Antworten vom Server, die die Konfigurationsparameter übertragen.
2.2 Dynamische Zuweisung von Netzwerkadressen (Dynamic allocation of network addresses)
Der zweite von DHCP bereitgestellte Dienst ist die Zuweisung temporärer oder permanenter Netzwerk-(IP-)Adressen an Clients. Der grundlegende Mechanismus für die dynamische Zuweisung von Netzwerkadressen ist einfach: Ein Client fordert die Verwendung einer Adresse für einen bestimmten Zeitraum an. Der Zuweisungsmechanismus (eine Gruppe von DHCP-Servern) garantiert, diese Adresse innerhalb der angeforderten Zeit nicht neu zuzuweisen, und versucht, jedes Mal, wenn der Client eine Adresse anfordert, dieselbe Netzwerkadresse zurückzugeben. In diesem Dokument wird der Zeitraum, über den eine Netzwerkadresse einem Client zugewiesen wird, als „Lease" bezeichnet [11]. Der Client kann sein Lease mit nachfolgenden Anfragen verlängern. Der Client kann eine Nachricht senden, um die Adresse an den Server zurückzugeben, wenn der Client die Adresse nicht mehr benötigt. Der Client kann eine permanente Zuweisung anfordern, indem er ein unendliches Lease anfordert. Selbst bei der Zuweisung „permanenter" Adressen kann ein Server wählen, langwierige, aber nicht unendliche Leases zu vergeben, um die Erkennung der Tatsache zu ermöglichen, dass ein Client außer Betrieb genommen wurde.
In einigen Umgebungen wird es aufgrund der Erschöpfung verfügbarer Adressen notwendig sein, Netzwerkadressen neu zuzuweisen. In solchen Umgebungen wird der Zuweisungsmechanismus Adressen wiederverwenden, deren Lease abgelaufen ist. Der Server sollte alle im Konfigurationsinformations-Repository verfügbaren Informationen verwenden, um eine wiederzuverwendende Adresse auszuwählen. Beispielsweise kann der Server die zuletzt zugewiesene Adresse wählen. Als Konsistenzprüfung SOLLTE der zuweisende Server die wiederzuverwendende Adresse vor der Zuweisung der Adresse untersuchen, z. B. mit einer ICMP-Echo-Anfrage, und der Client SOLLTE die neu empfangene Adresse untersuchen, z. B. mit ARP.