4. Spezifikation des DHCP-Client-Server-Protokolls (Specification of the DHCP Client-Server Protocol)
In diesem Abschnitt wird angenommen, dass ein DHCP-Server über einen Block von Netzwerkadressen verfügt, aus dem er Anfragen nach neuen Adressen erfüllen kann. Jeder Server verwaltet außerdem eine Datenbank der zugewiesenen Adressen und Leasingverträge im lokalen persistenten Speicher.
4.1 Konstruktion und Versand von DHCP-Nachrichten (Constructing and sending DHCP messages)
DHCP-Clients und -Server konstruieren DHCP-Nachrichten, indem sie die Felder im Fixformatbereich der Nachricht ausfüllen und getaggte Datenelemente im Optionsbereich variabler Länge hinzufügen. Der Optionsbereich enthält zunächst ein vier Oktette langes 'Magic Cookie' (beschrieben in Abschnitt 3), gefolgt von den Optionen. Die letzte Option muss immer die 'end'-Option sein.
DHCP verwendet UDP als Transportprotokoll. DHCP-Nachrichten von einem Client zu einem Server werden an den 'DHCP-Server'-Port (67) gesendet, und DHCP-Nachrichten von einem Server zu einem Client werden an den 'DHCP-Client'-Port (68) gesendet. Ein Server mit mehreren Netzwerkadressen (z.B. ein Multihomed-Host) kann eine seiner Netzwerkadressen in ausgehenden DHCP-Nachrichten verwenden.
Das Feld 'Server-Identifikator' wird sowohl zur Identifizierung eines DHCP-Servers in einer DHCP-Nachricht als auch als Zieladresse von Clients zu Servern verwendet. Ein Server mit mehreren Netzwerkadressen muss bereit sein, eine seiner Netzwerkadressen als Identifikation dieses Servers in einer DHCP-Nachricht zu akzeptieren. Um potenziell unvollständiger Netzwerkkonnektivität Rechnung zu tragen, muss ein Server eine Adresse als 'Server-Identifikator' auswählen, die nach bestem Wissen des Servers vom Client aus erreichbar ist. Wenn beispielsweise der DHCP-Server und der DHCP-Client mit demselben Subnetz verbunden sind (d.h. das 'giaddr'-Feld in der Nachricht vom Client ist null), sollte der Server die IP-Adresse auswählen, die der Server für die Kommunikation in diesem Subnetz verwendet, als 'Server-Identifikator'. Wenn der Server mehrere IP-Adressen in diesem Subnetz verwendet, kann eine dieser Adressen verwendet werden. Wenn der Server eine Nachricht über einen DHCP-Relay-Agenten erhalten hat, sollte der Server eine Adresse von der Schnittstelle auswählen, auf der die Nachricht empfangen wurde, als 'Server-Identifikator' (es sei denn, der Server verfügt über andere bessere Informationen, auf denen er seine Wahl gründen kann). DHCP-Clients müssen die in der Option 'Server-Identifikator' angegebene IP-Adresse für alle Unicast-Anfragen an den DHCP-Server verwenden.
DHCP-Nachrichten, die von einem Client übertragen werden, bevor dieser Client seine IP-Adresse erhalten hat, müssen das Quelladressfeld im IP-Header auf 0 setzen.
Wenn das 'giaddr'-Feld in einer DHCP-Nachricht von einem Client ungleich null ist, sendet der Server alle Antwortnachrichten an den 'DHCP-Server'-Port am BOOTP-Relay-Agenten, dessen Adresse in 'giaddr' erscheint. Wenn das 'giaddr'-Feld null und das 'ciaddr'-Feld ungleich null ist, sendet der Server DHCPOFFER- und DHCPACK-Nachrichten per Unicast an die Adresse in 'ciaddr'. Wenn 'giaddr' null und 'ciaddr' null ist und das Broadcast-Bit gesetzt ist, überträgt der Server DHCPOFFER- und DHCPACK-Nachrichten an 0xffffffff. Wenn das Broadcast-Bit nicht gesetzt ist und 'giaddr' null und 'ciaddr' null ist, sendet der Server DHCPOFFER- und DHCPACK-Nachrichten per Unicast an die Hardware-Adresse des Clients und die 'yiaddr'-Adresse. In allen Fällen, wenn 'giaddr' null ist, überträgt der Server alle DHCPNAK-Nachrichten an 0xffffffff.
Wenn sich die Optionen in einer DHCP-Nachricht in die Felder 'sname' und 'file' erstrecken, muss die Option 'Option Overload' im Feld 'options' mit dem Wert 1, 2 oder 3 erscheinen, wie in RFC 1533 spezifiziert. Wenn die Option 'Option Overload' im Feld 'options' vorhanden ist, müssen die Optionen im Feld 'options' mit einer 'end'-Option beendet werden und können eine oder mehrere 'pad'-Optionen enthalten, um das Optionsfeld zu füllen. Die Optionen in den Feldern 'sname' und 'file' (wenn wie durch die Option 'Option Overload' angegeben verwendet) müssen mit dem ersten Oktett des Feldes beginnen, müssen mit einer 'end'-Option beendet werden und müssen von 'pad'-Optionen gefolgt werden, um den Rest des Feldes zu füllen. Jede einzelne Option in den Feldern 'options', 'sname' und 'file' muss vollständig in diesem Feld enthalten sein. Die Optionen im Feld 'options' müssen zuerst interpretiert werden, damit jede Option 'Option Overload' interpretiert werden kann. Das Feld 'file' muss als nächstes interpretiert werden (wenn die Option 'Option Overload' anzeigt, dass das Feld 'file' DHCP-Optionen enthält), gefolgt vom Feld 'sname'.
Die Werte, die in einem 'option'-Tag übergeben werden, können zu lang sein, um in die 255 Oktette zu passen, die für eine einzelne Option verfügbar sind (z.B. eine Liste von Routern in einer 'router'-Option [21]). Optionen können nur einmal erscheinen, sofern nicht anders im Optionsdokument angegeben. Der Client verkettet die Werte mehrerer Instanzen derselben Option zu einer einzigen Parameterliste für die Konfiguration.
DHCP-Clients sind für alle Neuübertragungen von Nachrichten verantwortlich. Der Client muss eine Neuübertragungsstrategie verwenden, die einen randomisierten exponentiellen Backoff-Algorithmus einbezieht, um die Verzögerung zwischen Neuübertragungen zu bestimmen. Die Verzögerung zwischen Neuübertragungen sollte so gewählt werden, dass sie ausreichend Zeit für die Zustellung von Antworten vom Server basierend auf den Eigenschaften des Internets zwischen Client und Server ermöglicht. Beispielsweise sollte in einem 10Mb/sec Ethernet-Internet die Verzögerung vor der ersten Neuübertragung 4 Sekunden betragen, randomisiert durch den Wert einer gleichmäßigen Zufallszahl, die aus dem Bereich -1 bis +1 gewählt wurde. Clients mit Uhren, die eine Auflösungsgranularität von weniger als einer Sekunde bieten, können einen nicht-ganzzahligen Randomisierungswert wählen. Die Verzögerung vor der nächsten Neuübertragung sollte 8 Sekunden betragen, randomisiert durch den Wert einer gleichmäßigen Zahl, die aus dem Bereich -1 bis +1 gewählt wurde. Die Neuübertragungsverzögerung sollte bei nachfolgenden Neuübertragungen bis zu einem Maximum von 64 Sekunden verdoppelt werden. Der Client kann dem Benutzer eine Anzeige der Neuübertragungsversuche als Hinweis auf den Fortschritt des Konfigurationsprozesses geben.
Das 'xid'-Feld wird vom Client verwendet, um eingehende DHCP-Nachrichten mit ausstehenden Anfragen abzugleichen. Ein DHCP-Client muss 'xid' auf eine Weise wählen, die die Chancen minimiert, eine 'xid' zu verwenden, die mit einer von einem anderen Client verwendeten identisch ist. Beispielsweise kann ein Client bei jedem Neustart des Clients eine andere zufällige anfängliche 'xid' wählen und dann bis zum nächsten Neustart sequentielle 'xids' verwenden. Die Wahl einer neuen 'xid' für jede Neuübertragung ist eine Implementierungsentscheidung. Ein Client kann wählen, dieselbe 'xid' wiederzuverwenden oder für jede neu übertragene Nachricht eine neue 'xid' zu wählen.
Normalerweise versuchen DHCP-Server und BOOTP-Relay-Agenten, DHCPOFFER-, DHCPACK- und DHCPNAK-Nachrichten direkt per Unicast an den Client zu übermitteln. Die IP-Zieladresse (im IP-Header) wird auf die DHCP-'yiaddr'-Adresse gesetzt und die Link-Layer-Zieladresse wird auf die DHCP-'chaddr'-Adresse gesetzt. Leider sind einige Client-Implementierungen nicht in der Lage, solche Unicast-IP-Datagramme zu empfangen, bis die Implementierung mit einer gültigen IP-Adresse konfiguriert wurde (was zu einem Deadlock führt, bei dem die IP-Adresse des Clients nicht zugestellt werden kann, bis der Client mit einer IP-Adresse konfiguriert wurde).
Ein Client, der keine Unicast-IP-Datagramme empfangen kann, bis seine Protokollsoftware mit einer IP-Adresse konfiguriert wurde, sollte das BROADCAST-Bit im 'flags'-Feld auf 1 in allen DHCPDISCOVER- oder DHCPREQUEST-Nachrichten setzen, die dieser Client sendet. Das BROADCAST-Bit gibt DHCP-Servern und BOOTP-Relay-Agenten einen Hinweis, alle Nachrichten im Subnetz des Clients an den Client zu übertragen. Ein Client, der Unicast-IP-Datagramme empfangen kann, bevor seine Protokollsoftware konfiguriert wurde, sollte das BROADCAST-Bit auf 0 löschen. Das BOOTP-Klarstellungsdokument diskutiert die Auswirkungen der Verwendung des BROADCAST-Bits [21].
Ein Server oder Relay-Agent, der eine DHCP-Nachricht direkt an einen DHCP-Client sendet oder weiterleitet (d.h. nicht an einen im 'giaddr'-Feld angegebenen Relay-Agenten), sollte das BROADCAST-Bit im 'flags'-Feld untersuchen. Wenn dieses Bit auf 1 gesetzt ist, sollte die DHCP-Nachricht als IP-Broadcast unter Verwendung einer IP-Broadcast-Adresse (vorzugsweise 0xffffffff) als IP-Zieladresse und der Link-Layer-Broadcast-Adresse als Link-Layer-Zieladresse gesendet werden. Wenn das BROADCAST-Bit auf 0 gelöscht ist, sollte die Nachricht als IP-Unicast an die im 'yiaddr'-Feld angegebene IP-Adresse und an die im 'chaddr'-Feld angegebene Link-Layer-Adresse gesendet werden. Wenn Unicast nicht möglich ist, kann die Nachricht als IP-Broadcast unter Verwendung einer IP-Broadcast-Adresse (vorzugsweise 0xffffffff) als IP-Zieladresse und der Link-Layer-Broadcast-Adresse als Link-Layer-Zieladresse gesendet werden.
4.2 Administrative Steuerungen des DHCP-Servers (DHCP server administrative controls)
DHCP-Server sind nicht verpflichtet, auf jede DHCPDISCOVER- und DHCPREQUEST-Nachricht zu antworten, die sie erhalten. Beispielsweise kann ein Netzwerkadministrator, um eine strikte Kontrolle über die an das Netzwerk angeschlossenen Clients aufrechtzuerhalten, wählen, DHCP-Server so zu konfigurieren, dass sie nur auf Clients antworten, die zuvor durch einen externen Mechanismus registriert wurden. Die DHCP-Spezifikation beschreibt nur die Interaktionen zwischen Clients und Servern, wenn Clients und Server wählen zu interagieren; es liegt außerhalb des Geltungsbereichs der DHCP-Spezifikation, alle administrativen Steuerungen zu beschreiben, die Systemadministratoren verwenden möchten. Spezifische DHCP-Server-Implementierungen können alle Steuerungen oder Richtlinien einbeziehen, die ein Netzwerkadministrator wünscht.
In einigen Umgebungen müssen DHCP-Server den Wert der Vendor-Class-Optionen berücksichtigen, die in DHCPDISCOVER- oder DHCPREQUEST-Nachrichten enthalten sind, wenn sie die richtigen Parameter für einen bestimmten Client bestimmen.
Ein DHCP-Server muss eine eindeutige Kennung verwenden, um einen Client mit seinem Leasing zu verknüpfen. Der Client kann wählen, die Kennung explizit über die Option 'Client-Identifikator' bereitzustellen. Wenn der Client einen 'Client-Identifikator' bereitstellt, muss der Client denselben 'Client-Identifikator' in allen nachfolgenden Nachrichten verwenden, und der Server muss diese Kennung verwenden, um den Client zu identifizieren. Wenn der Client keine Option 'Client-Identifikator' bereitstellt, muss der Server den Inhalt des 'chaddr'-Feldes verwenden, um den Client zu identifizieren. Es ist entscheidend für den korrekten Betrieb von DHCP, dass der Client eine eindeutige Kennung im Subnetz verwendet, mit dem der Client verbunden ist, in der Option 'Client-Identifikator'. Die Verwendung von 'chaddr' als eindeutige Kennung des Clients kann zu unerwarteten Ergebnissen führen, da diese Kennung möglicherweise mit einer Hardware-Schnittstelle verknüpft ist, die zu einem neuen Client verschoben werden könnte. Einige Standorte können wählen, eine Herstellerseriennummer als 'Client-Identifikator' zu verwenden, um unerwartete Änderungen in der Netzwerkadresse eines Clients aufgrund der Übertragung von Hardware-Schnittstellen zwischen Computern zu vermeiden. Standorte können auch wählen, einen DNS-Namen als 'Client-Identifikator' zu verwenden, wodurch die Netzwerkadresse eines Clients mit dem DNS-Namen und nicht mit einer bestimmten Hardware-Box verknüpft wird.
DHCP-Clients können jede Strategie frei verwenden, um einen DHCP-Server aus denjenigen auszuwählen, von denen der Client eine DHCPOFFER-Nachricht empfängt. Die Client-Implementierung von DHCP sollte einen Mechanismus bereitstellen, der es dem Benutzer ermöglicht, die Werte des 'Vendor-Class-Identifikators' direkt auszuwählen.
4.3 DHCP-Server-Verhalten (DHCP server behavior)
Ein DHCP-Server verarbeitet eingehende DHCP-Nachrichten von einem Client basierend auf dem aktuellen Status der Bindung für diesen Client. Ein DHCP-Server kann die folgenden Nachrichten von einem Client empfangen:
- DHCPDISCOVER
- DHCPREQUEST
- DHCPDECLINE
- DHCPRELEASE
- DHCPINFORM
Tabelle 3 zeigt die Verwendung von Feldern und Optionen in einer DHCP-Nachricht durch einen Server. Der Rest dieses Abschnitts beschreibt die Aktion des DHCP-Servers für jede mögliche eingehende Nachricht.
4.3.1 DHCPDISCOVER-Nachricht
Wenn ein Server eine DHCPDISCOVER-Nachricht von einem Client empfängt, wählt der Server eine Netzwerkadresse für den anfragenden Client aus. Wenn keine Adresse verfügbar ist, kann der Server wählen, das Problem dem Systemadministrator zu melden. Wenn eine Adresse verfügbar ist, sollte die neue Adresse wie folgt gewählt werden:
- Die aktuelle Adresse des Clients, wie in der aktuellen Bindung des Clients aufgezeichnet, SONST
- Die vorherige Adresse des Clients, wie in der (nun abgelaufenen oder freigegebenen) Bindung des Clients aufgezeichnet, wenn diese Adresse im Pool verfügbarer Adressen des Servers ist und noch nicht zugewiesen ist, SONST
- Die in der Option 'Angeforderte IP-Adresse' angeforderte Adresse, wenn diese Adresse gültig ist und noch nicht zugewiesen ist, SONST
- Eine neue Adresse, die aus dem Pool verfügbarer Adressen des Servers zugewiesen wurde; die Adresse wird basierend auf dem Subnetz ausgewählt, von dem die Nachricht empfangen wurde (wenn 'giaddr' 0 ist) oder der Adresse des Relay-Agenten, der die Nachricht weitergeleitet hat ('giaddr', wenn nicht 0).
Wie in Abschnitt 4.2 beschrieben, kann ein Server aus administrativen Gründen eine andere als die angeforderte Adresse zuweisen oder sich weigern, einem bestimmten Client eine Adresse zuzuweisen, auch wenn freie Adressen verfügbar sind.
Beachten Sie, dass in einigen Netzwerkarchitekturen (z.B. Internets mit mehr als einem IP-Subnetz, das einem physischen Netzwerksegment zugewiesen ist) es der Fall sein kann, dass einem DHCP-Client eine Adresse aus einem anderen Subnetz als der in 'giaddr' aufgezeichneten Adresse zugewiesen werden sollte. Daher verlangt DHCP nicht, dass dem Client eine Adresse aus dem Subnetz in 'giaddr' zugewiesen wird. Ein Server kann frei ein anderes Subnetz wählen, und es liegt außerhalb des Geltungsbereichs der DHCP-Spezifikation, die Mittel zu beschreiben, durch die die zugewiesene IP-Adresse gewählt werden könnte.
Obwohl dies für den korrekten Betrieb von DHCP nicht erforderlich ist, sollte der Server die ausgewählte Netzwerkadresse nicht wiederverwenden, bevor der Client auf die DHCPOFFER-Nachricht des Servers antwortet. Der Server kann wählen, die Adresse als dem Client angeboten aufzuzeichnen.
Der Server muss auch einen Ablaufzeitpunkt für das Leasing wählen, wie folgt:
- WENN der Client kein spezifisches Leasing in der DHCPDISCOVER-Nachricht angefordert hat und der Client bereits eine zugewiesene Netzwerkadresse hat, gibt der Server den Ablaufzeitpunkt des zuvor dieser Adresse zugewiesenen Leasings zurück (beachten Sie, dass der Client explizit ein spezifisches Leasing anfordern muss, um den Ablaufzeitpunkt einer zuvor zugewiesenen Adresse zu verlängern), SONST
- WENN der Client kein spezifisches Leasing in der DHCPDISCOVER-Nachricht angefordert hat und der Client keine zugewiesene Netzwerkadresse hat, weist der Server eine lokal konfigurierte Standard-Leasingzeit zu, SONST
- WENN der Client ein spezifisches Leasing in der DHCPDISCOVER-Nachricht angefordert hat (unabhängig davon, ob der Client eine zugewiesene Netzwerkadresse hat), kann der Server wählen, das angeforderte Leasing zurückzugeben (wenn das Leasing für die lokale Richtlinie akzeptabel ist) oder ein anderes Leasing auszuwählen.
Tabelle der von DHCP-Servern verwendeten Felder und Optionen
| Feld | DHCPOFFER | DHCPACK | DHCPNAK |
|---|---|---|---|
| op | BOOTREPLY | BOOTREPLY | BOOTREPLY |
| htype | (aus RFC "Assigned Numbers") | ||
| hlen | (Hardware-Adresslänge in Oktetten) | ||
| hops | 0 | 0 | 0 |
| xid | 'xid' aus Client-DHCPDISCOVER-Nachricht | 'xid' aus Client-DHCPREQUEST-Nachricht | 'xid' aus Client-DHCPREQUEST-Nachricht |
| secs | 0 | 0 | 0 |
| ciaddr | 0 | 'ciaddr' aus DHCPREQUEST oder 0 | 0 |
| yiaddr | Dem Client angebotene IP-Adresse | Dem Client zugewiesene IP-Adresse | 0 |
| siaddr | IP-Adresse des nächsten Bootstrap-Servers | IP-Adresse des nächsten Bootstrap-Servers | 0 |
| flags | 'flags' aus Client-DHCPDISCOVER-Nachricht | 'flags' aus Client-DHCPREQUEST-Nachricht | 'flags' aus Client-DHCPREQUEST-Nachricht |
| giaddr | 'giaddr' aus Client-DHCPDISCOVER-Nachricht | 'giaddr' aus Client-DHCPREQUEST-Nachricht | 'giaddr' aus Client-DHCPREQUEST-Nachricht |
| chaddr | 'chaddr' aus Client-DHCPDISCOVER-Nachricht | 'chaddr' aus Client-DHCPREQUEST-Nachricht | 'chaddr' aus Client-DHCPREQUEST-Nachricht |
| sname | Server-Hostname oder Optionen | Server-Hostname oder Optionen | (unbenutzt) |
| file | Client-Boot-Dateiname oder Optionen | Client-Boot-Dateiname oder Optionen | (unbenutzt) |
| options | Optionen | Optionen |
| Option | DHCPOFFER | DHCPACK | DHCPNAK |
|---|---|---|---|
| Angeforderte IP-Adresse | DARF NICHT | DARF NICHT | DARF NICHT |
| IP-Adress-Leasingdauer | MUSS | MUSS (DHCPREQUEST) DARF NICHT (DHCPINFORM) | DARF NICHT |
| 'file'/'sname'-Felder verwenden | KANN | KANN | DARF NICHT |
| DHCP-Nachrichtentyp | DHCPOFFER | DHCPACK | DHCPNAK |
| Parameter-Anforderungsliste | DARF NICHT | DARF NICHT | DARF NICHT |
| Nachricht | SOLLTE | SOLLTE | SOLLTE |
| Client-Identifikator | DARF NICHT | DARF NICHT | KANN |
| Vendor-Class-Identifikator | KANN | KANN | KANN |
| Server-Identifikator | MUSS | MUSS | MUSS |
| Maximale Nachrichtengröße | DARF NICHT | DARF NICHT | DARF NICHT |
| Alle anderen | KANN | KANN | DARF NICHT |
Tabelle 3: Von DHCP-Servern verwendete Felder und Optionen
Sobald die Netzwerkadresse und das Leasing bestimmt sind, konstruiert der Server eine DHCPOFFER-Nachricht mit den angebotenen Konfigurationsparametern. Es ist wichtig, dass alle DHCP-Server dieselben Parameter (mit der möglichen Ausnahme einer neu zugewiesenen Netzwerkadresse) zurückgeben, um vorhersehbares Client-Verhalten zu gewährleisten, unabhängig davon, welcher Server vom Client ausgewählt wird. Die Konfigurationsparameter müssen durch Anwendung der folgenden Regeln in der unten angegebenen Reihenfolge ausgewählt werden. Der Netzwerkadministrator ist verantwortlich für die Konfiguration mehrerer DHCP-Server, um einheitliche Antworten von diesen Servern sicherzustellen. Der Server muss dem Client Folgendes zurückgeben:
- Die Netzwerkadresse des Clients, wie durch die zuvor in diesem Abschnitt angegebenen Regeln bestimmt,
- Der Ablaufzeitpunkt für das Leasing des Clients, wie durch die zuvor in diesem Abschnitt angegebenen Regeln bestimmt,
- Die vom Client angeforderten Parameter gemäß den folgenden Regeln:
- WENN der Server explizit mit einem Standardwert für den Parameter konfiguriert wurde, muss der Server diesen Wert in einer geeigneten Option im 'option'-Feld einfügen, SONST
- WENN der Server den Parameter als einen im Host-Requirements-Dokument definierten Parameter erkennt, muss der Server den Standardwert für diesen Parameter, der im Host-Requirements-Dokument angegeben ist, in einer geeigneten Option im 'option'-Feld einfügen, SONST
- Der Server darf keinen Wert für diesen Parameter zurückgeben,
- Der Server muss so viele angeforderte Parameter wie möglich bereitstellen und muss alle Parameter weglassen, die er nicht bereitstellen kann. Der Server muss jeden angeforderten Parameter nur einmal einfügen, sofern nicht ausdrücklich im DHCP-Optionen- und BOOTP-Vendor-Extensions-Dokument erlaubt.
- Alle Parameter der vorhandenen Bindung, die von den Standardwerten des Host-Requirements-Dokuments abweichen,
- Alle Parameter, die für diesen Client spezifisch sind (wie durch den Inhalt von 'chaddr' oder 'Client-Identifikator' in der DHCPDISCOVER- oder DHCPREQUEST-Nachricht identifiziert), zum Beispiel wie vom Netzwerkadministrator konfiguriert,
- Alle Parameter, die für die Klasse dieses Clients spezifisch sind (wie durch den Inhalt der Option 'Vendor-Class-Identifikator' in der DHCPDISCOVER- oder DHCPREQUEST-Nachricht identifiziert), zum Beispiel wie vom Netzwerkadministrator konfiguriert; die Parameter müssen durch eine genaue Übereinstimmung zwischen den Vendor-Class-Identifikatoren des Clients und der im Server identifizierten Client-Klasse identifiziert werden,
- Parameter mit nicht standardmäßigen Werten im Subnetz des Clients.
Der Server kann wählen, den 'Vendor-Class-Identifikator' zurückzugeben, der zur Bestimmung der Parameter in der DHCPOFFER-Nachricht verwendet wurde, um dem Client bei der Auswahl zu helfen, welches DHCPOFFER akzeptiert werden soll. Der Server fügt das 'xid'-Feld aus der DHCPDISCOVER-Nachricht in das 'xid'-Feld der DHCPOFFER-Nachricht ein und sendet die DHCPOFFER-Nachricht an den anfragenden Client.
4.3.2 DHCPREQUEST-Nachricht
Eine DHCPREQUEST-Nachricht kann von einem Client stammen, der auf eine DHCPOFFER-Nachricht von einem Server antwortet, von einem Client, der eine zuvor zugewiesene IP-Adresse überprüft, oder von einem Client, der das Leasing für eine Netzwerkadresse verlängert. Wenn die DHCPREQUEST-Nachricht eine Option 'Server-Identifikator' enthält, ist die Nachricht eine Antwort auf eine DHCPOFFER-Nachricht. Andernfalls ist die Nachricht eine Anfrage zur Überprüfung oder Verlängerung eines vorhandenen Leasings. Wenn der Client einen 'Client-Identifikator' in einer DHCPREQUEST-Nachricht verwendet, muss er denselben 'Client-Identifikator' in allen nachfolgenden Nachrichten verwenden. Wenn der Client eine Liste angeforderter Parameter in einer DHCPDISCOVER-Nachricht enthalten hat, muss er diese Liste in allen nachfolgenden Nachrichten enthalten.
Alle Konfigurationsparameter in der DHCPACK-Nachricht sollten nicht mit denen in der vorherigen DHCPOFFER-Nachricht in Konflikt stehen, auf die der Client antwortet. Der Client sollte die Parameter in der DHCPACK-Nachricht für die Konfiguration verwenden.
Clients senden DHCPREQUEST-Nachrichten wie folgt:
DHCPREQUEST generiert während des SELECTING-Zustands:
Der Client fügt die Adresse des ausgewählten Servers in 'Server-Identifikator' ein, 'ciaddr' muss null sein, 'Angeforderte IP-Adresse' muss mit dem yiaddr-Wert des gewählten DHCPOFFER gefüllt werden.
Beachten Sie, dass der Client wählen kann, mehrere DHCPOFFER-Nachrichten zu sammeln und das "beste" Angebot auszuwählen. Der Client zeigt seine Auswahl an, indem er den anbietenden Server in der DHCPREQUEST-Nachricht identifiziert. Wenn der Client keine akzeptablen Angebote erhält, kann der Client wählen, eine weitere DHCPDISCOVER-Nachricht zu versuchen. Daher können Server möglicherweise keine spezifische DHCPREQUEST erhalten, aus der sie entscheiden können, ob der Client das Angebot angenommen hat. Da Server keine Netzwerkadresszuweisung basierend auf einem DHCPOFFER festgelegt haben, können Server die angebotenen Netzwerkadressen als Antwort auf nachfolgende Anfragen frei wiederverwenden. Als Implementierungsdetail sollten Server angebotene Adressen nicht wiederverwenden und können einen implementierungsspezifischen Timeout-Mechanismus verwenden, um zu entscheiden, wann eine angebotene Adresse wiederverwendet werden soll.
DHCPREQUEST generiert während des INIT-REBOOT-Zustands:
'Server-Identifikator' darf nicht gefüllt werden, die Option 'Angeforderte IP-Adresse' muss mit der Vorstellung des Clients von seiner zuvor zugewiesenen Adresse gefüllt werden. 'ciaddr' muss null sein. Der Client versucht, eine zuvor zugewiesene, zwischengespeicherte Konfiguration zu überprüfen. Der Server sollte eine DHCPNAK-Nachricht an den Client senden, wenn die 'Angeforderte IP-Adresse' falsch ist oder sich im falschen Netzwerk befindet.
Die Bestimmung, ob sich ein Client im INIT-REBOOT-Zustand im richtigen Netzwerk befindet, erfolgt durch Untersuchung von 'giaddr', dem Inhalt der Option 'Angeforderte IP-Adresse' und einer Datenbanksuche. Wenn der DHCP-Server feststellt, dass der Client sich im falschen Netzwerk befindet (d.h. das Ergebnis der Anwendung der lokalen Subnetzmaske oder der entfernten Subnetzmaske (wenn 'giaddr' nicht null ist) auf den Wert der Option 'Angeforderte IP-Adresse' stimmt nicht mit der Realität überein), dann sollte der Server eine DHCPNAK-Nachricht an den Client senden.
Wenn das Netzwerk korrekt ist, dann sollte der DHCP-Server überprüfen, ob die Vorstellung des Clients von seiner IP-Adresse korrekt ist. Wenn nicht, dann sollte der Server eine DHCPNAK-Nachricht an den Client senden. Wenn der DHCP-Server keine Aufzeichnung über diesen Client hat, dann muss er schweigen und kann eine Warnung an den Netzwerkadministrator ausgeben. Dieses Verhalten ist für die friedliche Koexistenz von nicht kommunizierenden DHCP-Servern auf derselben Leitung erforderlich.
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 übertragen, weil der Client möglicherweise keine korrekte Netzwerkadresse oder Subnetzmaske hat und der Client möglicherweise nicht auf ARP-Anfragen antwortet.
Wenn 'giaddr' in der DHCPREQUEST-Nachricht gesetzt ist, befindet sich der Client in einem anderen Subnetz. Der Server muss das Broadcast-Bit im DHCPNAK setzen, damit der Relay-Agent das DHCPNAK an den Client überträgt, weil der Client möglicherweise keine korrekte Netzwerkadresse oder Subnetzmaske hat und der Client möglicherweise nicht auf ARP-Anfragen antwortet.
DHCPREQUEST generiert während des RENEWING-Zustands:
'Server-Identifikator' darf nicht gefüllt werden, die Option 'Angeforderte IP-Adresse' darf nicht gefüllt werden, 'ciaddr' muss mit der IP-Adresse des Clients gefüllt werden. In dieser Situation ist der Client vollständig konfiguriert und versucht, sein Leasing zu verlängern. Diese Nachricht wird per Unicast übertragen, daher ist kein Relay-Agent an ihrer Übertragung beteiligt. Da 'giaddr' daher nicht gefüllt ist, wird der DHCP-Server dem Wert in 'ciaddr' vertrauen und ihn bei der Antwort an den Client verwenden.
Ein Client kann wählen, sein Leasing vor T1 zu erneuern oder zu verlängern. Der Server kann wählen, das Leasing nicht zu verlängern (als Richtlinienentscheidung durch den Netzwerkadministrator), sollte aber in jedem Fall eine DHCPACK-Nachricht zurückgeben.
DHCPREQUEST generiert während des REBINDING-Zustands:
'Server-Identifikator' darf nicht gefüllt werden, die Option 'Angeforderte IP-Adresse' darf nicht gefüllt werden, 'ciaddr' muss mit der IP-Adresse des Clients gefüllt werden. In dieser Situation ist der Client vollständig konfiguriert und versucht, sein Leasing zu verlängern. Diese Nachricht muss an die IP-Broadcast-Adresse 0xffffffff übertragen werden. Der DHCP-Server sollte 'ciaddr' auf Richtigkeit überprüfen, bevor er auf die DHCPREQUEST antwortet.
Die DHCPREQUEST von einem REBINDING-Client ist dazu gedacht, Standorte zu berücksichtigen, die mehrere DHCP-Server und einen Mechanismus zur Aufrechterhaltung der Konsistenz von Bindungen zwischen Leasingverhältnissen haben, die von mehreren Servern verwaltet werden. Ein DHCP-Server kann das Leasing eines Clients nur verlängern, wenn er die lokale administrative Autorität dazu hat.
4.3.3 DHCPDECLINE-Nachricht
Wenn der Server eine DHCPDECLINE-Nachricht erhält, hat der Client auf andere Weise festgestellt, dass die vorgeschlagene Netzwerkadresse bereits verwendet wird. Der Server muss die Netzwerkadresse als nicht verfügbar markieren und sollte den lokalen Systemadministrator über ein mögliches Konfigurationsproblem informieren.
4.3.4 DHCPRELEASE-Nachricht
Nach Erhalt einer DHCPRELEASE-Nachricht markiert der Server die Netzwerkadresse als nicht zugewiesen. Der Server sollte eine Aufzeichnung der Initialisierungsparameter des Clients zur möglichen Wiederverwendung als Antwort auf nachfolgende Anfragen vom Client aufbewahren.
4.3.5 DHCPINFORM-Nachricht
Der Server antwortet auf eine DHCPINFORM-Nachricht, indem er eine DHCPACK-Nachricht direkt an die im 'ciaddr'-Feld der DHCPINFORM-Nachricht angegebene Adresse sendet. Der Server darf dem Client keinen Leasingablauf senden und sollte 'yiaddr' nicht füllen. Der Server fügt andere Parameter in die DHCPACK-Nachricht ein, wie in Abschnitt 4.3.1 definiert.
4.3.6 Client-Nachrichten
Tabelle 4 erläutert die Unterschiede zwischen Nachrichten von Clients in verschiedenen Zuständen.
| INIT-REBOOT | SELECTING | RENEWING | REBINDING | |
|---|---|---|---|---|
| Broadcast/Unicast | Broadcast | Broadcast | Unicast | Broadcast |
| server-ip | DARF NICHT | MUSS | DARF NICHT | DARF NICHT |
| requested-ip | MUSS | MUSS | DARF NICHT | DARF NICHT |
| ciaddr | null | null | IP-Adresse | IP-Adresse |
Tabelle 4: Client-Nachrichten aus verschiedenen Zuständen
4.4 DHCP-Client-Verhalten (DHCP client behavior)
Abbildung 5 zeigt das Zustandsübergangsdiagramm für einen DHCP-Client. Ein Client kann die folgenden Nachrichten von einem Server empfangen:
- DHCPOFFER
- DHCPACK
- DHCPNAK
Die DHCPINFORM-Nachricht wird in Abbildung 5 nicht gezeigt. Ein Client sendet einfach das DHCPINFORM und wartet auf DHCPACK-Nachrichten. Sobald der Client seine Parameter ausgewählt hat, hat er den Konfigurationsprozess abgeschlossen.
Tabelle 5 zeigt die Verwendung von Feldern und Optionen in einer DHCP-Nachricht durch einen Client. Der Rest dieses Abschnitts beschreibt die Aktion des DHCP-Clients für jede mögliche eingehende Nachricht. Die Beschreibung im nächsten Abschnitt entspricht dem vollständigen Konfigurationsverfahren, das zuvor in Abschnitt 3.1 beschrieben wurde, und der Text des folgenden Abschnitts entspricht dem abgekürzten Konfigurationsverfahren, das in Abschnitt 3.2 beschrieben wurde.
Zustandsübergangsdiagramm für DHCP-Clients
-------- -------
| | +-------------------------->| |<-------------------+
| INIT- | | +-------------------->| INIT | |
| REBOOT |DHCPNAK/ +---------->| |<---+ |
| |Neustart | | ------- | |
-------- | DHCPNAK/ | | |
| Angebot verwerfen | -/DHCPDISCOVER senden |
-/DHCPREQUEST senden | | |
| | | DHCPACK v | |
----------- | (nicht akzeptieren)/ ----------- | |
| | | DHCPDECLINE senden | | |
| REBOOTING | | | | SELECTING |<----+ |
| | | / | | |DHCPOFFER/ |
----------- | / ----------- | |Antworten |
| | / | | | sammeln |
DHCPACK/ | / +----------------+ +-------+ |
Leasing aufzeichnen, T1,T2 | | v Angebot auswählen/ |
Timer setzen ------------ DHCPREQUEST senden | |
| +----->| | DHCPNAK, Leasing abgelaufen/ |
| | | REQUESTING | Netzwerk anhalten |
DHCPOFFER/ | | | |
Verwerfen ------------ | |
| | | | ----------- |
| +--------+ DHCPACK/ | | |
| Leasing aufzeichnen, T1,T2 -----| REBINDING | |
| Timer setzen / | | |
| | DHCPACK/ ----------- |
| v Leasing aufzeichnen, ^ |
+----------------> ------- /T1,T2 setzen | |
+----->| |<---+ | |
| | BOUND |<---+ | |
DHCPOFFER, DHCPACK, | | | T2 läuft ab/ DHCPNAK/
DHCPNAK/Verwerfen ------- | Broadcast Netzwerk anhalten
| | | | DHCPREQUEST |
+-------+ | DHCPACK/ | |
T1 läuft ab/ Leasing aufzeichnen, T1,T2 | |
DHCPREQUEST senden Timer setzen | |
an Leasingserver | | |
| ---------- | |
| | |------------+ |
+->| RENEWING | |
| |----------------------------+
----------
Abbildung 5: Zustandsübergangsdiagramm für DHCP-Client
4.4.1 Initialisierung und Zuweisung von Netzwerkadressen
Der Client beginnt im INIT-Zustand und bildet eine DHCPDISCOVER-Nachricht. Der Client sollte eine zufällige Zeit zwischen einer und zehn Sekunden warten, um die Verwendung von DHCP beim Booten zu desynchronisieren. Der Client setzt 'ciaddr' auf 0x00000000. Der Client kann spezifische Parameter anfordern, indem er die Option 'Parameter-Anforderungsliste' einfügt. Der Client kann eine Netzwerkadresse und/oder Leasingzeit vorschlagen, indem er die Optionen 'Angeforderte IP-Adresse' und 'IP-Adress-Leasingdauer' einfügt. Der Client muss seine Hardware-Adresse im 'chaddr'-Feld einfügen, falls erforderlich für die Zustellung von DHCP-Antwortnachrichten. Der Client kann eine andere eindeutige Kennung in der Option 'Client-Identifikator' einfügen, wie in Abschnitt 4.2 besprochen. Wenn der Client eine Liste angeforderter Parameter in einer DHCPDISCOVER-Nachricht enthalten hat, muss er diese Liste in allen nachfolgenden Nachrichten enthalten.
Der Client generiert und zeichnet eine zufällige Transaktionskennung auf und fügt diese Kennung in das 'xid'-Feld ein. Der Client zeichnet seine eigene lokale Zeit zur späteren Verwendung bei der Berechnung des Leasingablaufs auf. Der Client überträgt dann das DHCPDISCOVER auf der lokalen Hardware-Broadcast-Adresse zur IP-Broadcast-Adresse 0xffffffff und zum 'DHCP-Server'-UDP-Port.
Wenn die 'xid' einer ankommenden DHCPOFFER-Nachricht nicht mit der 'xid' der neuesten DHCPDISCOVER-Nachricht übereinstimmt, muss die DHCPOFFER-Nachricht stillschweigend verworfen werden. Alle ankommenden DHCPACK-Nachrichten müssen stillschweigend verworfen werden.
Der Client sammelt DHCPOFFER-Nachrichten über einen Zeitraum, wählt eine DHCPOFFER-Nachricht aus den (möglicherweise vielen) eingehenden DHCPOFFER-Nachrichten aus (z.B. die erste DHCPOFFER-Nachricht oder die DHCPOFFER-Nachricht von einem zuvor verwendeten Server) und extrahiert die Serveradresse aus der Option 'Server-Identifikator' in der DHCPOFFER-Nachricht. Die Zeit, über die der Client Nachrichten sammelt, und der Mechanismus, der zur Auswahl eines DHCPOFFER verwendet wird, sind implementierungsabhängig.
Tabelle der von DHCP-Clients verwendeten Felder und Optionen
| Feld | DHCPDISCOVER DHCPINFORM | DHCPREQUEST | DHCPDECLINE, DHCPRELEASE |
|---|---|---|---|
| op | BOOTREQUEST | BOOTREQUEST | BOOTREQUEST |
| htype | (aus RFC "Assigned Numbers") | ||
| hlen | (Hardware-Adresslänge in Oktetten) | ||
| hops | 0 | 0 | 0 |
| xid | vom Client gewählt | 'xid' aus Server-DHCPOFFER-Nachricht | vom Client gewählt |
| secs | 0 oder Sekunden seit Beginn des DHCP-Prozesses | 0 oder Sekunden seit Beginn des DHCP-Prozesses | 0 |
| flags | 'BROADCAST'-Flag setzen, wenn Client Broadcast-Antwort benötigt | 'BROADCAST'-Flag setzen, wenn Client Broadcast-Antwort benötigt | 0 |
| ciaddr | 0 (DHCPDISCOVER) Netzwerkadresse des Clients (DHCPINFORM) | 0 oder Netzwerkadresse des Clients (BOUND/RENEW/REBIND) | 0 (DHCPDECLINE) Netzwerkadresse des Clients (DHCPRELEASE) |
| yiaddr | 0 | 0 | 0 |
| siaddr | 0 | 0 | 0 |
| giaddr | 0 | 0 | 0 |
| chaddr | Hardware-Adresse des Clients | Hardware-Adresse des Clients | Hardware-Adresse des Clients |
| sname | Optionen (falls in Option 'sname/file' angegeben); sonst unbenutzt | Optionen (falls in Option 'sname/file' angegeben); sonst unbenutzt | (unbenutzt) |
| file | Optionen (falls in Option 'sname/file' angegeben); sonst unbenutzt | Optionen (falls in Option 'sname/file' angegeben); sonst unbenutzt | (unbenutzt) |
| options | Optionen | Optionen | (unbenutzt) |
| Option | DHCPDISCOVER DHCPINFORM | DHCPREQUEST | DHCPDECLINE, DHCPRELEASE |
|---|---|---|---|
| Angeforderte IP-Adresse | KANN (DISCOVER) DARF NICHT (INFORM) | MUSS (in SELECTING oder INIT-REBOOT) DARF NICHT (in BOUND oder RENEWING) | MUSS (DHCPDECLINE), DARF NICHT (DHCPRELEASE) |
| IP-Adress-Leasingdauer | KANN (DISCOVER) DARF NICHT (INFORM) | KANN | DARF NICHT |
| 'file'/'sname'-Felder verwenden | KANN | KANN | KANN |
| DHCP-Nachrichtentyp | DHCPDISCOVER/ DHCPINFORM | DHCPREQUEST | DHCPDECLINE/ DHCPRELEASE |
| Client-Identifikator | KANN | KANN | KANN |
| Vendor-Class-Identifikator | KANN | KANN | DARF NICHT |
| Server-Identifikator | DARF NICHT | MUSS (nach SELECTING) DARF NICHT (nach INIT-REBOOT, BOUND, RENEWING oder REBINDING) | MUSS |
| Parameter-Anforderungsliste | KANN | KANN | DARF NICHT |
| Maximale Nachrichtengröße | KANN | KANN | DARF NICHT |
| Nachricht | SOLLTE NICHT | SOLLTE NICHT | SOLLTE |
| Standortspezifisch | KANN | KANN | DARF NICHT |
| Alle anderen | KANN | KANN | DARF NICHT |
Tabelle 5: Von DHCP-Clients verwendete Felder und Optionen
Wenn die Parameter akzeptabel sind, zeichnet der Client die Adresse des Servers auf, der die Parameter bereitgestellt hat, aus dem Feld 'Server-Identifikator' und sendet diese Adresse im Feld 'Server-Identifikator' einer Broadcast-DHCPREQUEST-Nachricht. Sobald die DHCPACK-Nachricht vom Server eintrifft, ist der Client initialisiert und wechselt in den BOUND-Zustand. Die DHCPREQUEST-Nachricht enthält dieselbe 'xid' wie die DHCPOFFER-Nachricht. Der Client zeichnet den Leasingablauf als Summe der Zeit auf, zu der die ursprüngliche Anfrage gesendet wurde, und der Leasingdauer aus der DHCPACK-Nachricht. Der Client sollte eine Überprüfung der vorgeschlagenen Adresse durchführen, um sicherzustellen, dass die Adresse nicht bereits verwendet wird. Wenn sich der Client beispielsweise in einem Netzwerk befindet, das ARP unterstützt, kann der Client eine ARP-Anfrage für die vorgeschlagene Anfrage ausgeben. Beim Übertragen einer ARP-Anfrage für die vorgeschlagene Adresse muss der Client seine eigene Hardware-Adresse als Absender-Hardware-Adresse einfügen und 0 als Absender-IP-Adresse einfügen, um die ARP-Caches in anderen Hosts im selben Subnetz nicht zu verwirren. Wenn die Netzwerkadresse verwendet zu werden scheint, muss der Client eine DHCPDECLINE-Nachricht an den Server senden. Der Client sollte eine ARP-Antwort übertragen, um die neue IP-Adresse des Clients anzukündigen und alle veralteten ARP-Cache-Einträge in Hosts im Subnetz des Clients zu löschen.
4.4.2 Initialisierung mit bekannter Netzwerkadresse
Der Client beginnt im INIT-REBOOT-Zustand und sendet eine DHCPREQUEST-Nachricht. Der Client muss seine bekannte Netzwerkadresse als Option 'Angeforderte IP-Adresse' in der DHCPREQUEST-Nachricht einfügen. Der Client kann spezifische Konfigurationsparameter anfordern, indem er die Option 'Parameter-Anforderungsliste' einfügt. Der Client generiert und zeichnet eine zufällige Transaktionskennung auf und fügt diese Kennung in das 'xid'-Feld ein. Der Client zeichnet seine eigene lokale Zeit zur späteren Verwendung bei der Berechnung des Leasingablaufs auf. Der Client darf keinen 'Server-Identifikator' in die DHCPREQUEST-Nachricht einfügen. Der Client überträgt dann das DHCPREQUEST auf der lokalen Hardware-Broadcast-Adresse zum 'DHCP-Server'-UDP-Port.
Sobald eine DHCPACK-Nachricht mit einem 'xid'-Feld, das mit dem der DHCPREQUEST-Nachricht des Clients übereinstimmt, von einem beliebigen Server eintrifft, ist der Client initialisiert und wechselt in den BOUND-Zustand. Der Client zeichnet den Leasingablauf als Summe der Zeit auf, zu der die DHCPREQUEST-Nachricht gesendet wurde, und der Leasingdauer aus der DHCPACK-Nachricht.
4.4.3 Initialisierung mit einer extern zugewiesenen Netzwerkadresse
Der Client sendet eine DHCPINFORM-Nachricht. Der Client kann spezifische Konfigurationsparameter anfordern, indem er die Option 'Parameter-Anforderungsliste' einfügt. Der Client generiert und zeichnet eine zufällige Transaktionskennung auf und fügt diese Kennung in das 'xid'-Feld ein. Der Client stellt seine eigene Netzwerkadresse in das 'ciaddr'-Feld. Der Client sollte keine Leasingzeitparameter anfordern.
Der Client sendet dann das DHCPINFORM per Unicast an den DHCP-Server, wenn er die Adresse des Servers kennt, andernfalls überträgt er die Nachricht an die begrenzte Broadcast-Adresse (alle Einsen). DHCPINFORM-Nachrichten müssen an den 'DHCP-Server'-UDP-Port gerichtet sein.
Sobald eine DHCPACK-Nachricht mit einem 'xid'-Feld, das mit dem der DHCPINFORM-Nachricht des Clients übereinstimmt, von einem beliebigen Server eintrifft, ist der Client initialisiert.
Wenn der Client innerhalb einer angemessenen Zeit (60 Sekunden oder 4 Versuche, wenn das in Abschnitt 4.1 vorgeschlagene Timeout verwendet wird) kein DHCPACK erhält, sollte er eine Nachricht anzeigen, die den Benutzer über das Problem informiert, und sollte dann die Netzwerkverarbeitung mit geeigneten Standardwerten gemäß Anhang A beginnen.
4.4.4 Verwendung von Broadcast und Unicast
DHCP-Clients übertragen DHCPDISCOVER-, DHCPREQUEST- und DHCPINFORM-Nachrichten, es sei denn, der Client kennt die Adresse eines DHCP-Servers. Der Client sendet DHCPRELEASE-Nachrichten per Unicast an den Server. Da der Client die Verwendung der vom Server bereitgestellten IP-Adresse ablehnt, überträgt der Client DHCPDECLINE-Nachrichten.
Wenn der DHCP-Client die Adresse eines DHCP-Servers kennt, im INIT- oder REBOOTING-Zustand, kann der Client diese Adresse im DHCPDISCOVER oder DHCPREQUEST anstelle der IP-Broadcast-Adresse verwenden. Der Client kann auch Unicast verwenden, um DHCPINFORM-Nachrichten an einen bekannten DHCP-Server zu senden. Wenn der Client keine Antwort auf DHCP-Nachrichten erhält, die an die IP-Adresse eines bekannten DHCP-Servers gesendet wurden, kehrt der DHCP-Client zur Verwendung der IP-Broadcast-Adresse zurück.
4.4.5 Wiederbeschaffung und Ablauf
Der Client verwaltet zwei Zeiten, T1 und T2, die die Zeiten angeben, zu denen der Client versucht, sein Leasing für seine Netzwerkadresse zu verlängern. T1 ist die Zeit, zu der der Client in den RENEWING-Zustand eintritt und versucht, den Server zu kontaktieren, der die Netzwerkadresse des Clients ursprünglich ausgegeben hat. T2 ist die Zeit, zu der der Client in den REBINDING-Zustand eintritt und versucht, einen beliebigen Server zu kontaktieren. T1 muss früher als T2 sein, das wiederum früher als die Zeit sein muss, zu der das Leasing des Clients abläuft.
Um die Notwendigkeit synchronisierter Uhren zu vermeiden, werden T1 und T2 in Optionen als relative Zeiten ausgedrückt [2].
Zur Zeit T1 wechselt der Client in den RENEWING-Zustand und sendet (per Unicast) eine DHCPREQUEST-Nachricht an den Server, um sein Leasing zu verlängern. Der Client setzt das 'ciaddr'-Feld im DHCPREQUEST auf seine aktuelle Netzwerkadresse. Der Client zeichnet die lokale Zeit auf, zu der die DHCPREQUEST-Nachricht gesendet wird, zur Berechnung des Leasingablaufs. Der Client darf keinen 'Server-Identifikator' in die DHCPREQUEST-Nachricht einfügen.
Alle DHCPACK-Nachrichten, die mit einer 'xid' ankommen, die nicht mit der 'xid' der DHCPREQUEST-Nachricht des Clients übereinstimmt, werden stillschweigend verworfen. Wenn der Client ein DHCPACK vom Server erhält, berechnet der Client den Leasingablauf als Summe der Zeit, zu der der Client die DHCPREQUEST-Nachricht gesendet hat, und der Leasingdauer aus der DHCPACK-Nachricht. Der Client hat seine Netzwerkadresse erfolgreich wiederbeschafft, kehrt in den BOUND-Zustand zurück und kann die Netzwerkverarbeitung fortsetzen.
Wenn kein DHCPACK vor der Zeit T2 eintrifft, wechselt der Client in den REBINDING-Zustand und sendet (per Broadcast) eine DHCPREQUEST-Nachricht, um sein Leasing zu verlängern. Der Client setzt das 'ciaddr'-Feld im DHCPREQUEST auf seine aktuelle Netzwerkadresse. Der Client darf keinen 'Server-Identifikator' in die DHCPREQUEST-Nachricht einfügen.
Die Zeiten T1 und T2 sind vom Server über Optionen konfigurierbar. T1 ist standardmäßig (0,5 * duration_of_lease). T2 ist standardmäßig (0,875 * duration_of_lease). Die Zeiten T1 und T2 sollten mit etwas zufälliger "Unschärfe" um einen festen Wert herum gewählt werden, um die Synchronisierung der Wiederbeschaffung durch Clients zu vermeiden.
Ein Client kann wählen, sein Leasing vor T1 zu erneuern oder zu verlängern. Der Server kann wählen, das Leasing des Clients gemäß der vom Netzwerkadministrator festgelegten Richtlinie zu verlängern. Der Server sollte T1 und T2 zurückgeben, und ihre Werte sollten von ihren ursprünglichen Werten angepasst werden, um die verbleibende Zeit im Leasing zu berücksichtigen.
In den Zuständen RENEWING und REBINDING sollte der Client, wenn er keine Antwort auf seine DHCPREQUEST-Nachricht erhält, die Hälfte der verbleibenden Zeit bis T2 (im RENEWING-Zustand) und die Hälfte der verbleibenden Leasingzeit (im REBINDING-Zustand) warten, bis zu einem Minimum von 60 Sekunden, bevor er die DHCPREQUEST-Nachricht erneut sendet.
Wenn das Leasing abläuft, bevor der Client ein DHCPACK erhält, wechselt der Client in den INIT-Zustand, muss sofort alle andere Netzwerkverarbeitung stoppen und Netzwerkinitialisierungsparameter anfordern, als ob der Client nicht initialisiert wäre. Wenn der Client anschließend ein DHCPACK erhält, das diesem Client seine vorherige Netzwerkadresse zuweist, sollte der Client die Netzwerkverarbeitung fortsetzen. Wenn dem Client eine neue Netzwerkadresse zugewiesen wird, darf er die vorherige Netzwerkadresse nicht weiter verwenden und sollte die lokalen Benutzer über das Problem informieren.
4.4.6 DHCPRELEASE
Wenn der Client seine zugewiesene Netzwerkadresse nicht mehr verwenden muss (z.B. wird der Client ordnungsgemäß heruntergefahren), sendet der Client eine DHCPRELEASE-Nachricht an den Server. Beachten Sie, dass der korrekte Betrieb von DHCP nicht von der Übertragung von DHCPRELEASE-Nachrichten abhängt.