3. Das Client-Server-Protokoll (The Client-Server Protocol)
DHCP verwendet das in RFC 951 definierte BOOTP-Nachrichtenformat, das in Tabelle 1 und Abbildung 1 dargestellt ist. Das 'op'-Feld jeder DHCP-Nachricht, die von einem Client an einen Server gesendet wird, enthält BOOTREQUEST. BOOTREPLY wird im 'op'-Feld jeder DHCP-Nachricht verwendet, die von einem Server an einen Client gesendet wird.
Die ersten vier Oktette des 'options'-Feldes der DHCP-Nachricht enthalten die (dezimalen) Werte 99, 130, 83 und 99 (dies ist derselbe Magic Cookie wie in RFC 1497 [17] definiert). Der Rest des 'options'-Feldes besteht aus einer Liste markierter Parameter, die "Optionen" genannt werden. Alle in RFC 1497 aufgelisteten "Vendor Extensions" sind ebenfalls DHCP-Optionen. RFC 1533 gibt den vollständigen Satz von Optionen an, die für die Verwendung mit DHCP definiert sind.
Bisher wurden mehrere Optionen definiert. Eine bestimmte Option - die Option "DHCP-Nachrichtentyp (DHCP Message Type)" - muss in jeder DHCP-Nachricht enthalten sein. Diese Option definiert den "Typ" der DHCP-Nachricht. Zusätzliche Optionen können je nach DHCP-Nachrichtentyp erlaubt, erforderlich oder nicht erlaubt sein.
In diesem Dokument werden DHCP-Nachrichten, die eine 'DHCP-Nachrichtentyp'-Option enthalten, nach dem Typ der Nachricht bezeichnet; z.B. wird eine DHCP-Nachricht mit 'DHCP-Nachrichtentyp'-Option Typ 1 als "DHCPDISCOVER"-Nachricht bezeichnet.
3.1 Client-Server-Interaktion - Zuweisung einer Netzwerkadresse (Client-server interaction - allocating a network address)
Die folgende Zusammenfassung des Protokollaustauschs zwischen Clients und Servern bezieht sich auf die in Tabelle 2 beschriebenen DHCP-Nachrichten. Das Zeitdiagramm in Abbildung 3 zeigt die zeitlichen Beziehungen in einer typischen Client-Server-Interaktion. Wenn der Client seine Adresse bereits kennt, können einige dieser Schritte weggelassen werden; diese abgekürzte Interaktion wird in Abschnitt 3.2 beschrieben.
1. Der Client sendet eine DHCPDISCOVER-Nachricht auf seinem lokalen physischen Subnetz. Die DHCPDISCOVER-Nachricht KANN Optionen enthalten, die Werte für die Netzwerkadresse und die Leasingdauer vorschlagen. BOOTP-Relay-Agenten können die Nachricht an DHCP-Server weiterleiten, die sich nicht im selben physischen Subnetz befinden.
2. Jeder Server kann mit einer DHCPOFFER-Nachricht antworten, die eine verfügbare Netzwerkadresse im 'yiaddr'-Feld enthält (und andere Konfigurationsparameter in DHCP-Optionen). Server müssen die angebotene Netzwerkadresse nicht reservieren, obwohl das Protokoll effizienter funktioniert, wenn der Server vermeidet, die angebotene Netzwerkadresse einem anderen Client zuzuweisen. Bei der Zuweisung einer neuen Adresse SOLLTEN Server überprüfen, dass die angebotene Netzwerkadresse noch nicht verwendet wird; z.B. kann der Server die angebotene Adresse mit einer ICMP-Echo-Anfrage untersuchen. Server SOLLTEN so implementiert werden, dass Netzwerkadministratoren KÖNNEN wählen können, die Untersuchung neu zugewiesener Adressen zu deaktivieren. Der Server überträgt die DHCPOFFER-Nachricht an den Client, wobei der BOOTP-Relay-Agent bei Bedarf verwendet wird.
DHCP-Nachrichten (DHCP messages)
| Nachricht | Verwendung |
|---|---|
| DHCPDISCOVER | Client-Broadcast zur Lokalisierung verfügbarer Server. |
| DHCPOFFER | Server an Client als Antwort auf DHCPDISCOVER mit Angebot von Konfigurationsparametern. |
| DHCPREQUEST | Client-Nachricht an Server, entweder (a) Anforderung angebotener Parameter von einem Server und implizite Ablehnung von Angeboten aller anderen, (b) Bestätigung der Korrektheit einer zuvor zugewiesenen Adresse nach z.B. Systemneustart, oder (c) Verlängerung des Leases für eine bestimmte Netzwerkadresse. |
| DHCPACK | Server an Client mit Konfigurationsparametern, einschließlich zugewiesener Netzwerkadresse. |
| DHCPNAK | Server an Client, der anzeigt, dass die Vorstellung des Clients von der Netzwerkadresse falsch ist (z.B. Client ist in ein neues Subnetz verschoben worden) oder das Lease des Clients abgelaufen ist. |
| DHCPDECLINE | Client an Server, der anzeigt, dass die Netzwerkadresse bereits verwendet wird. |
| DHCPRELEASE | Client an Server, der die Netzwerkadresse aufgibt und das verbleibende Lease abbricht. |
| DHCPINFORM | Client an Server, der nur nach lokalen Konfigurationsparametern fragt; Client hat bereits eine extern konfigurierte Netzwerkadresse. |
Tabelle 2: DHCP-Nachrichten
Zeitdiagramm (Timeline diagram)
Server Client Server
(not selected) (selected)
v v v
| | |
| Begins initialization |
| | |
| _____________/|\____________ |
|/DHCPDISCOVER | DHCPDISCOVER \|
| | |
Determines | Determines
configuration | configuration
| | |
|\ | ____________/ |
| \________ | /DHCPOFFER |
| DHCPOFFER\ |/ |
| \ | |
| Collects replies |
| \| |
| Selects configuration |
| | |
| _____________/|\____________ |
|/ DHCPREQUEST | DHCPREQUEST\ |
| | |
| | Commits configuration
| | |
| | _____________/|
| |/ DHCPACK |
| | |
| Initialization complete |
| | |
. . .
. . .
| | |
| Graceful shutdown |
| | |
| |\ ____________ |
| | DHCPRELEASE \|
| | |
| | Discards lease
| | |
v v v
Abbildung 3: Zeitdiagramm der zwischen DHCP-Client und Servern
ausgetauschten Nachrichten bei der Zuweisung einer
neuen Netzwerkadresse
3. Der Client empfängt eine oder mehrere DHCPOFFER-Nachrichten von einem oder mehreren Servern. Der Client kann wählen, auf mehrere Antworten zu warten. Der Client wählt einen Server aus, von dem Konfigurationsparameter angefordert werden sollen, basierend auf den in den DHCPOFFER-Nachrichten angebotenen Konfigurationsparametern. Der Client sendet eine DHCPREQUEST-Nachricht, die die Option 'Server Identifier' enthalten MUSS, um anzuzeigen, welchen Server er ausgewählt hat, und die KANN andere Optionen enthalten, die gewünschte Konfigurationswerte angeben. Die Option 'requested IP address' MUSS auf den Wert von 'yiaddr' in der DHCPOFFER-Nachricht vom Server gesetzt werden. Diese DHCPREQUEST-Nachricht wird über DHCP/BOOTP-Relay-Agenten gesendet und weitergeleitet. Um sicherzustellen, dass alle BOOTP-Relay-Agenten die DHCPREQUEST-Nachricht an denselben Satz von DHCP-Servern weiterleiten, die die ursprüngliche DHCPDISCOVER-Nachricht erhalten haben, MUSS die DHCPREQUEST-Nachricht denselben Wert im 'secs'-Feld des DHCP-Nachrichtenheaders verwenden und an dieselbe IP-Broadcast-Adresse wie die ursprüngliche DHCPDISCOVER-Nachricht gesendet werden. Der Client läuft ab und überträgt die DHCPDISCOVER-Nachricht erneut, wenn der Client keine DHCPOFFER-Nachrichten empfängt.
4. Die Server empfangen den DHCPREQUEST-Broadcast vom Client. Server, die nicht durch die DHCPREQUEST-Nachricht ausgewählt wurden, verwenden die Nachricht als Benachrichtigung, dass der Client das Angebot dieses Servers abgelehnt hat. Der in der DHCPREQUEST-Nachricht ausgewählte Server speichert die Bindung des Clients im persistenten Speicher und antwortet mit einer DHCPACK-Nachricht, die die Konfigurationsparameter für den anfragenden Client enthält. Die Kombination aus 'Client Identifier' oder 'chaddr' und zugewiesener Netzwerkadresse bildet einen eindeutigen Bezeichner für das Lease des Clients und wird sowohl vom Client als auch vom Server verwendet, um ein in einer DHCP-Nachricht referenziertes Lease zu identifizieren. Alle Konfigurationsparameter in der DHCPACK-Nachricht SOLLTEN NICHT mit denen in der früheren DHCPOFFER-Nachricht in Konflikt stehen, auf die der Client antwortet. Der Server SOLLTE die angebotene Netzwerkadresse an diesem Punkt NICHT überprüfen. Das 'yiaddr'-Feld in den DHCPACK-Nachrichten wird mit der ausgewählten Netzwerkadresse ausgefüllt.
Wenn der ausgewählte Server die DHCPREQUEST-Nachricht nicht erfüllen kann (z.B. die angeforderte Netzwerkadresse wurde zugewiesen), SOLLTE der Server mit einer DHCPNAK-Nachricht antworten.
Ein Server KANN wählen, Adressen, die Clients in DHCPOFFER-Nachrichten angeboten wurden, als nicht verfügbar zu markieren. Der Server SOLLTE eine Adresse, die einem Client in einer DHCPOFFER-Nachricht angeboten wurde, als verfügbar markieren, wenn der Server keine DHCPREQUEST-Nachricht von diesem Client empfängt.
5. Der Client empfängt die DHCPACK-Nachricht mit Konfigurationsparametern. Der Client SOLLTE eine endgültige Überprüfung der Parameter durchführen (z.B. ARP für zugewiesene Netzwerkadresse) und notiert die in der DHCPACK-Nachricht angegebene Leasingdauer. An diesem Punkt ist der Client konfiguriert. Wenn der Client erkennt, dass die Adresse bereits verwendet wird (z.B. durch die Verwendung von ARP), MUSS der Client eine DHCPDECLINE-Nachricht an den Server senden und den Konfigurationsprozess neu starten. Der Client SOLLTE mindestens zehn Sekunden warten, bevor der Konfigurationsprozess neu gestartet wird, um übermäßigen Netzwerkverkehr bei Schleifen zu vermeiden.
Wenn der Client eine DHCPNAK-Nachricht empfängt, startet der Client den Konfigurationsprozess neu.
Wenn der Client weder eine DHCPACK- noch eine DHCPNAK-Nachricht empfängt, läuft der Client ab und überträgt die DHCPREQUEST-Nachricht gemäß dem Wiederholungsalgorithmus in Abschnitt 4.1 erneut. Der Client SOLLTE wählen, die DHCPREQUEST ausreichend oft zu übertragen, um eine angemessene Wahrscheinlichkeit zu bieten, den Server zu kontaktieren, ohne dass der Client (und der Benutzer dieses Clients) zu lange warten muss, bevor er aufgibt; z.B. könnte ein Client, der wie in Abschnitt 4.1 beschrieben überträgt, die DHCPREQUEST-Nachricht viermal für eine Gesamtverzögerung von 60 Sekunden übertragen, bevor das Initialisierungsverfahren neu gestartet wird. Wenn der Client nach Verwendung des Wiederholungsalgorithmus weder eine DHCPACK- noch eine DHCPNAK-Nachricht empfängt, kehrt der Client zum INIT-Zustand zurück und startet den Initialisierungsprozess neu. Der Client SOLLTE den Benutzer benachrichtigen, dass der Initialisierungsprozess fehlgeschlagen ist und neu gestartet wird.
6. Der Client kann wählen, sein Lease für eine Netzwerkadresse aufzugeben, indem er eine DHCPRELEASE-Nachricht an den Server sendet. Der Client identifiziert das freizugebende Lease mit seinem 'Client Identifier' oder 'chaddr' und der Netzwerkadresse in der DHCPRELEASE-Nachricht. Wenn der Client beim Erhalt des Leases einen 'Client Identifier' verwendet hat, MUSS er denselben 'Client Identifier' in der DHCPRELEASE-Nachricht verwenden.
3.2 Client-Server-Interaktion - Wiederverwendung einer zuvor zugewiesenen Netzwerkadresse (Client-server interaction - reusing a previously allocated network address)
Wenn sich ein Client an eine zuvor zugewiesene Netzwerkadresse erinnert und diese wiederverwenden möchte, kann ein Client wählen, einige der im vorherigen Abschnitt beschriebenen Schritte wegzulassen. Das Zeitdiagramm in Abbildung 4 zeigt die zeitlichen Beziehungen in einer typischen Client-Server-Interaktion für einen Client, der eine zuvor zugewiesene Netzwerkadresse wiederverwendet.
1. Der Client sendet eine DHCPREQUEST-Nachricht auf seinem lokalen Subnetz. Die Nachricht enthält die Netzwerkadresse des Clients in der Option 'requested IP address'. Da der Client seine Netzwerkadresse noch nicht erhalten hat, DARF er das 'ciaddr'-Feld NICHT ausfüllen. BOOTP-Relay-Agenten leiten die Nachricht an DHCP-Server weiter, die sich nicht im selben Subnetz befinden. Wenn der Client einen 'Client Identifier' zum Erhalt seiner Adresse verwendet hat, MUSS der Client denselben 'Client Identifier' in der DHCPREQUEST-Nachricht verwenden.
2. Server mit Kenntnis der Konfigurationsparameter des Clients antworten mit einer DHCPACK-Nachricht an den Client. Server SOLLTEN NICHT überprüfen, dass die Netzwerkadresse des Clients bereits verwendet wird; der Client kann an diesem Punkt auf ICMP-Echo-Request-Nachrichten antworten.
Server Client Server
v v v
| | |
| Begins |
| initialization |
| | |
| /|\ |
| _________ __/ | \__________ |
| /DHCPREQUEST | DHCPREQUEST\ |
|/ | \|
| | |
Locates | Locates
configuration | configuration
| | |
|\ | /|
| \ | ___________/ |
| \ | / DHCPACK |
| \ _______ |/ |
| DHCPACK\ | |
| Initialization |
| complete |
| \| |
| | |
| (Subsequent |
| DHCPACKS |
| ignored) |
| | |
| | |
v v v
Abbildung 4: Zeitdiagramm der zwischen DHCP-Client und Servern
ausgetauschten Nachrichten bei der Wiederverwendung
einer zuvor zugewiesenen Netzwerkadresse
Wenn die Anforderung des Clients ungültig ist (z.B. der Client ist in ein neues Subnetz verschoben worden), SOLLTEN Server dem Client mit einer DHCPNAK-Nachricht antworten. Server SOLLTEN NICHT antworten, wenn ihre Informationen nicht garantiert genau sind. Zum Beispiel SOLLTE ein Server, der eine Anforderung für eine abgelaufene Bindung identifiziert, die einem anderen Server gehört, NICHT mit einem DHCPNAK antworten, es sei denn, die Server verwenden einen expliziten Mechanismus zur Aufrechterhaltung der Kohärenz zwischen Servern.
Wenn 'giaddr' in der DHCPREQUEST-Nachricht 0x0 ist, befindet sich der Client im selben Subnetz wie der Server. Der Server MUSS die DHCPNAK-Nachricht an die Broadcast-Adresse 0xffffffff senden, da der Client möglicherweise keine korrekte Netzwerkadresse oder Subnetzmaske hat und der Client möglicherweise nicht auf ARP-Anfragen antwortet. Andernfalls MUSS der Server die DHCPNAK-Nachricht an die IP-Adresse des BOOTP-Relay-Agenten senden, wie in 'giaddr' aufgezeichnet. Der Relay-Agent leitet die Nachricht wiederum direkt an die Hardwareadresse des Clients weiter, sodass die DHCPNAK auch dann zugestellt werden kann, wenn der Client in ein neues Netzwerk verschoben wurde.
3. Der Client empfängt die DHCPACK-Nachricht mit Konfigurationsparametern. Der Client führt eine endgültige Überprüfung der Parameter durch (wie in Abschnitt 3.1) und notiert die in der DHCPACK-Nachricht angegebene Leasingdauer. Das spezifische Lease wird implizit durch den 'Client Identifier' oder 'chaddr' und die Netzwerkadresse identifiziert. An diesem Punkt ist der Client konfiguriert.
Wenn der Client erkennt, dass die IP-Adresse in der DHCPACK-Nachricht bereits verwendet wird, MUSS der Client eine DHCPDECLINE-Nachricht an den Server senden und den Konfigurationsprozess durch Anforderung einer neuen Netzwerkadresse neu starten. Diese Aktion entspricht dem Wechsel des Clients in den INIT-Zustand im DHCP-Zustandsdiagramm, das in Abschnitt 4.4 beschrieben wird.
Wenn der Client eine DHCPNAK-Nachricht empfängt, kann er seine gespeicherte Netzwerkadresse nicht wiederverwenden. Er muss stattdessen eine neue Adresse anfordern, indem er den Konfigurationsprozess neu startet, diesmal unter Verwendung des (nicht abgekürzten) Verfahrens, das in Abschnitt 3.1 beschrieben wird. Diese Aktion entspricht auch dem Wechsel des Clients in den INIT-Zustand im DHCP-Zustandsdiagramm.
Wenn der Client weder eine DHCPACK- noch eine DHCPNAK-Nachricht empfängt, läuft der Client ab und überträgt die DHCPREQUEST-Nachricht gemäß dem Wiederholungsalgorithmus in Abschnitt 4.1 erneut. Der Client SOLLTE wählen, die DHCPREQUEST ausreichend oft zu übertragen, um eine angemessene Wahrscheinlichkeit zu bieten, den Server zu kontaktieren, ohne dass der Client (und der Benutzer dieses Clients) zu lange warten muss, bevor er aufgibt; z.B. könnte ein Client, der wie in Abschnitt 4.1 beschrieben überträgt, die DHCPREQUEST-Nachricht viermal für eine Gesamtverzögerung von 60 Sekunden übertragen, bevor das Initialisierungsverfahren neu gestartet wird. Wenn der Client nach Verwendung des Wiederholungsalgorithmus weder eine DHCPACK- noch eine DHCPNAK-Nachricht empfängt, KANN der Client wählen, die zuvor zugewiesene Netzwerkadresse und Konfigurationsparameter für den Rest des nicht abgelaufenen Leases zu verwenden. Dies entspricht dem Wechsel in den BOUND-Zustand im Client-Zustandsübergangsdiagramm, das in Abbildung 5 gezeigt wird.
4. Der Client kann wählen, sein Lease für eine Netzwerkadresse aufzugeben, indem er eine DHCPRELEASE-Nachricht an den Server sendet. Der Client identifiziert das freizugebende Lease mit seinem 'Client Identifier' oder 'chaddr' und der Netzwerkadresse in der DHCPRELEASE-Nachricht.
Beachten Sie, dass in diesem Fall, wo der Client seine Netzwerkadresse lokal behält, der Client normalerweise sein Lease während eines ordnungsgemäßen Herunterfahrens nicht aufgibt. Nur in dem Fall, in dem der Client sein Lease explizit aufgeben muss, z.B. der Client wird in ein anderes Subnetz verschoben, wird der Client eine DHCPRELEASE-Nachricht senden.
3.3 Interpretation und Darstellung von Zeitwerten (Interpretation and representation of time values)
Ein Client erwirbt ein Lease für eine Netzwerkadresse für eine feste Zeitdauer (die für immer sein kann). Im gesamten Protokoll sind Zeiten in Sekunden darzustellen. Der Zeitwert 0xffffffff ist reserviert, um "unendlich" darzustellen.
Da Clients und Server möglicherweise keine synchronisierten Uhren haben, werden Zeiten in DHCP-Nachrichten als relative Zeiten dargestellt, die in Bezug auf die lokale Uhr des Clients interpretiert werden. Die Darstellung relativer Zeiten in Sekunden in einem vorzeichenlosen 32-Bit-Wort ergibt einen Bereich relativer Zeiten von 0 bis etwa 100 Jahren, was für relative Zeiten, die mit DHCP gemessen werden, ausreichend ist.
Der im vorherigen Absatz angegebene Algorithmus zur Interpretation der Leasingdauer geht davon aus, dass Client- und Serveruhren relativ zueinander stabil sind. Wenn es eine Drift zwischen den beiden Uhren gibt, kann der Server das Lease als abgelaufen betrachten, bevor der Client dies tut. Zum Ausgleich KANN der Server dem Client eine kürzere Leasingdauer zurückgeben, als der Server in seiner lokalen Datenbank mit Client-Informationen speichert.
3.4 Erhalten von Parametern mit extern konfigurierter Netzwerkadresse (Obtaining parameters with externally configured network address)
Wenn ein Client eine Netzwerkadresse auf andere Weise erhalten hat (z.B. manuelle Konfiguration), kann er eine DHCPINFORM-Anforderungsnachricht verwenden, um andere lokale Konfigurationsparameter zu erhalten. Server, die eine DHCPINFORM-Nachricht empfangen, konstruieren eine DHCPACK-Nachricht mit allen für den Client geeigneten lokalen Konfigurationsparametern, ohne: eine neue Adresse zuzuweisen, eine bestehende Bindung zu überprüfen, 'yiaddr' auszufüllen oder Leasingzeitparameter einzuschließen. Die Server SOLLTEN die DHCPACK-Antwort per Unicast an die im 'ciaddr'-Feld der DHCPINFORM-Nachricht angegebene Adresse senden.
Der Server SOLLTE die Netzwerkadresse in einer DHCPINFORM-Nachricht auf Konsistenz überprüfen, DARF jedoch NICHT auf ein bestehendes Lease überprüfen. Der Server bildet eine DHCPACK-Nachricht, die die Konfigurationsparameter für den anfragenden Client enthält, und sendet die DHCPACK-Nachricht direkt an den Client.
3.5 Client-Parameter in DHCP (Client parameters in DHCP)
Nicht alle Clients benötigen die Initialisierung aller in Anhang A aufgeführten Parameter. Zwei Techniken werden verwendet, um die Anzahl der vom Server an den Client übertragenen Parameter zu reduzieren. Erstens haben die meisten Parameter Standardwerte, die in den Host Requirements RFCs definiert sind; wenn der Client keine Parameter vom Server erhält, die die Standardwerte überschreiben, verwendet ein Client diese Standardwerte. Zweitens kann ein Client in seiner anfänglichen DHCPDISCOVER- oder DHCPREQUEST-Nachricht dem Server eine Liste spezifischer Parameter bereitstellen, an denen der Client interessiert ist. Wenn der Client eine Liste von Parametern in einer DHCPDISCOVER-Nachricht enthält, MUSS er diese Liste in allen nachfolgenden DHCPREQUEST-Nachrichten einschließen.
Der Client SOLLTE die Option 'maximum DHCP message size' einschließen, um dem Server mitzuteilen, wie groß der Server seine DHCP-Nachrichten machen kann. Die an einen Client zurückgegebenen Parameter können immer noch den für Optionen in einer DHCP-Nachricht zugewiesenen Platz überschreiten. In diesem Fall zeigen zwei zusätzliche Optionsflags (die im 'options'-Feld der Nachricht erscheinen müssen) an, dass die Felder 'file' und 'sname' für Optionen verwendet werden sollen.
Der Client kann den Server darüber informieren, an welchen Konfigurationsparametern der Client interessiert ist, indem er die Option 'parameter request list' einschließt. Der Datenteil dieser Option listet explizit angeforderte Optionen nach Tag-Nummer auf.
Darüber hinaus KANN der Client Werte für die Netzwerkadresse und Leasingzeit in der DHCPDISCOVER-Nachricht vorschlagen. Der Client KANN die Option 'requested IP address' einschließen, um vorzuschlagen, dass eine bestimmte IP-Adresse zugewiesen wird, und KANN die Option 'IP address lease time' einschließen, um die gewünschte Leasingzeit vorzuschlagen. Andere Optionen, die "Hinweise" auf Konfigurationsparameter darstellen, sind in einer DHCPDISCOVER- oder DHCPREQUEST-Nachricht erlaubt. Zusätzliche Optionen können jedoch von Servern ignoriert werden, und mehrere Server geben möglicherweise nicht dieselben Werte für einige Optionen zurück. Die Option 'requested IP address' ist nur in einer DHCPREQUEST-Nachricht auszufüllen, wenn der Client zuvor zugewiesene, zwischengespeicherte Netzwerkparameter überprüft. Der Client füllt das 'ciaddr'-Feld nur aus, wenn er im Zustand BOUND, RENEWING oder REBINDING korrekt mit einer IP-Adresse konfiguriert ist.
Wenn ein Server eine DHCPREQUEST-Nachricht mit einer ungültigen 'requested IP address' empfängt, SOLLTE der Server dem Client mit einer DHCPNAK-Nachricht antworten und KANN wählen, das Problem dem Systemadministrator zu melden. Der Server KANN eine Fehlermeldung in die Option 'message' einschließen.
3.6 Verwendung von DHCP in Clients mit mehreren Schnittstellen (Use of DHCP in clients with multiple interfaces)
Ein Client mit mehreren Netzwerkschnittstellen MUSS DHCP über jede Schnittstelle unabhängig verwenden, um Konfigurationsinformationsparameter für diese separaten Schnittstellen zu erhalten.
3.7 Wann Clients DHCP verwenden sollten (When clients should use DHCP)
Ein Client SOLLTE DHCP verwenden, um seine IP-Adresse und Netzwerkparameter erneut zu erwerben oder zu überprüfen, wann immer sich die lokalen Netzwerkparameter geändert haben könnten; z.B. beim Systemstart oder nach einer Trennung vom lokalen Netzwerk, da sich die lokale Netzwerkkonfiguration ohne Wissen des Clients oder Benutzers ändern kann.
Wenn ein Client Kenntnis von einer früheren Netzwerkadresse hat und keinen lokalen DHCP-Server kontaktieren kann, KANN der Client die frühere Netzwerkadresse weiter verwenden, bis das Lease für diese Adresse abläuft. Wenn das Lease abläuft, bevor der Client einen DHCP-Server kontaktieren kann, MUSS der Client die Verwendung der früheren Netzwerkadresse sofort einstellen und KANN lokale Benutzer über das Problem informieren.