Ablauf des Renumberings beim DHCP-Client

Der Ablauf der Bemühung des Clients um eine neue IP-Adresse und Konfiguration wurde schon als Zustandsdiagramm in Kapitel 2 vorgestellt. Im folgenden wird auf diesen Ablauf Bezug genommen, indem die Namen der einzelnen Zustände des Ablaufs (INITIALIZE, REQUEST, etc. ) verwendet werden.
Wenn nun ein Client ein DHCPACK mit Renumbering-Option empfängt, das ihn vom REQUEST- in den BOUND-Zustand übergehen ließe, überprüft er, ob er schon wegen einer Post-Renumbering-Adresse mit einem DHCP-Server kommuniziert:

• Falls nicht, startet er einen zweiten DHCP-Dialog entsprechend dem Diagramm aus Kapitel 2 (s.a. ) mit dem Server, um eine neue (Post- Renumbering-) Adresse zu erhalten.
  Das bedeutet, daß ab diesem Moment vom Client zwei
  [4] DHCP-Konfigurationsprozesse in Gang gehalten werden, einer für die alte Adresse, einer für die neue.
• Falls schon ein Renumber-Dialog existiert, sendet der Client ein DHCPRELEASE an den Renumber-DHCP-Server und startet einen neuen Renumber-Dialog.

Wenn der Client das DHCPACK schon im BOUND, RENEW oder
[4] REBIND-Zustand empfängt, markiert er den laufenden Adreßvergabeablauf als ``entwertet`` und initiiert einen neuen. Der neue Ablauf startet im INITIALIZE-Zustand. Die mit DHCPACK empfangene DHCP-Option muß nun in das DHCPDISCOVER kopiert werden, mit dem der neue Ablauf beginnt. Der Client muß bei Abschluß des Renumberings entscheiden, wann er den alten Lease durch den neuen ersetzt.

Wenn der Client das DHCPACK ohne Renumbering-Option empfängt, überprüft er, ob er einen als ``entwertet`` bezeichneten Konfigurationsprozeß besitzt, ( d. h. , ob er sich um ein Renumbering bemüht hat) :

• Falls ja, soll er die neuen Konfigurationsparameter übernehmen und für seine Netzkommunikation benutzen. Das Renumbering ist damit für ihn abgeschlossen. Der alte, ``entwertete`` Lease läuft dann aus, ohne erneuert zu werden.
• Falls nicht, hat er sich nicht um ein Renumbering bemüht und ist damit (mit der Pre-Renumbering-Adresse) konfiguriert.