Client meldet sich neu an

Ein Client taucht neu in einem Netz auf. Um von einem Server konfiguriert zu werden und eine IP-Adresse zu bekommen, muß er zunächst einen DHCP Agenten lokalisieren.
Zu diesem Zwecke sendet er als Multicast ein DHCP Solicit an die Adresse FF02:0:0:0:0:0:1:0 mit TTL=1.

 

Abbildung:   DHCP Solicit : Mögliche Wege

12#12

Ein DHCP Agent (Server oder Relay) empfängt das DHCP Solicit und sendet ein DHCP Advertise mit allen Serveradressen, für die er werben soll über dieselbe Verbindung zurück.

Es ist möglich, den DHCP Agent periodisch DHCP Advertise-Meldungen an die All-DHCPv6-Clients Multicast-Adresse schicken zu lassen (mit TTL=1), um die Clients so oft wie möglich über den Zugang zu DHCPv6-Servern zu informieren.

Falls ein DHCP-Server das DHCP Solicit empfängt, stellt er ein DHCP Advertise zusammen, in dem er das sogenannte S-Bit (für Server) setzt. Das Advertise schickt er an die IPv6-Adresse des Interfaces, von dem er das Solicit empfangen hat.

 

Abbildung:   DHCP Advertise : Mögliche Wege

13#13

Der Client empfängt das DHCP Advertise.

Jetzt bieten sich mehrere Möglichkeiten:

• Client hat Advertise ohne Serveradressen und ohne gesetztes Server-Bit empfangen:
  Dann verwirft er das Advertise.
• Client hat Advertise mit gesetztem ServerBit empfangen:
  Das Advertise kam von einem Server und der Client kann sich eventuell angebotene Parameter für die Netzkonfiguration aussuchen.
  Jetzt kann der Client ein DHCP Request zusammenstellen, also eine Bitte um eine IPv6-Adresse plus Konfigurationsparametern und schickt diese an die Agentenadresse.
• Der Client hat schon einmal ein DHCP Request gesendet, aber keine Antwort erhalten:
  Dann muß er erneut einen identischen DHCP Request senden.
  Für die Retransmission von DHCPv6-PDUs werden anders als bei
  [4] DHCPv4 (s. ) Grenzzeitparameter festgelegt, welche vom Netzbetreiber bestimmt werden können [#!BoPe96!#])

Ein Relay empfängt das DHCP Request und überprüft folgende Eigenschaften der Meldung:

1.

kommt der Request von einer link-local-Adresse (s. o. )?

2.

stimmt die link-local-Adresse mit dem link-local-Adress-Feld im Header des DHCP Request überein?

3.

stimmt das agent-adress-Feld im Request mit der Adresse des Interfaces überein, von dem der Request empfangen wurde?

4.

Ist das S-Bit gesetzt?

Falls alle Bedingungen erfüllt sind, schickt das Relay den Request an den Server weiter, dessen Adresse es dem DHCP Request entnimmt.
Andernfalls verwirft es den Request.

Der Server empfängt den Request vom Relay und startet folgende Aktionen: Er überpruft anhand der Transaction ID, ob der Request wiederholt wurde: (Diese ID kennzeichnet jeden einzelnen Client-Server-Dialog.)

• Falls der Request wiederholt wurde:
  Server schickt denselben DHCP Reply an den Client wie nach dem ersten Request.
• Falls der Request nicht wiederholt wurde:
  Der Server überprüft, ob die Adresse im link-local-Feld gültig ist: Ist sie
  • nicht gültig,
    verwirft er den Request
  • gültig,
    prüft er, ob das S-Bit gesetzt ist:
  • Falls das S-Bit nicht gesetzt ist:
    Dann verwirft er den Request
    Vermutung, ist im DHCPv6-Draft nicht beschrieben
  • Falls das S-Bit gesetzt ist:
    Dann überprüft der Server, ob seine eigene Adresse mit der IPv6-Destination-Adresse im Request übereinstimmt:
    
    • Falls sie nicht übereinstimmt, verwirft er den Reqest und sendet ein dementsprechendes DHCP Reply an den Agenten.
    • Falls sie übereinstimmt, entnimmt er dem Request die link-local-Adresse und die Agentenadresse und kreiert einen Eintrag für den Client.
      Dieser enthält unter dem Titel (link-local-Adresse, Agentenadresse) die Konfigurationsdaten für den Client.
      Der Server sendet ein DHCP Reply an den Client mit den Konfigurationsparametern.
      Sollte die empfangene link-local-Adresse und die empfangene Agentenadresse nicht zu irgendeinem anderen Binding (link-local-Adresse,Agentenadresse) passen, kann der Server ein neues Binding kreieren oder ein DHCP Reply an den Agenten mit Error Code 5 zurücksenden.

Empfängt der Relay ein DHCP Reply, dann überprüft er:

1.

Ist das sogenannte L-Bit gesetzt, d. h.  will ein lokaler Server an einen bestimmten Client auf dem lokalen Subnetz senden?

2.

Hat das link-local-Feld der Meldung den Präfix FE80::00?

Falls beide Bedingungen erfüllt sind, sendet er den Reply an die link-local-Adresse, die er dem DHCP Reply entnimmt.
Die Alternativreaktion, wenn mindestens eine oder beide Bedingungen nicht erfüllt sind, wird vom Protokoll noch nicht festgelegt.

Der Client empfängt den DHCP Reply vom Relay und überprüft als erstes dessen Transaction ID, die seinen spezifischen Kontaktversuch zum DHCP-Server kennzeichnet. Ist diese

• nicht identisch mit der eines seiner DHCP Requests:
  Dann verwirft der Client den Reply und trägt eine Errormeldung in sein Log ein.
• identisch mit der ID eines seiner DHCP Requests:
  Dann überprüft er, ob das L-Bit in der Meldung gesetzt ist (Server auf gleichem Subnetz):
  • Falls das L-Bit gesetzt ist:
    Der Client überprüft, ob die Source Adress im IPv6-Header identisch ist mit der Agentenadresse unter dieser Transaction ID:
    • Falls die Adressen nicht identisch sind,
      Dann verwirft der Client den Reply und trägt einen Fehler in die Log-Datei ein
    • Falls die Adressen identisch sind,
      holt er sich die Konfigurationsparameter aus den Extensions des Reply und ist damit konfiguriert.
  • L-Bit nicht gesetzt: Der Client überprüft, ob die Source Adresse im IPv6-Header identisch ist mit der Serveradresse unter der Transaction ID:
    • Falls nicht, verwirft er den Reply und trägt den Fehler ins Logbuch ein
    • Falls sie identisch sind, holt er sich die Konfigurationsparameter aus den Extensions des Reply und ist damit konfiguriert.