5. DHCP-Konstanten
5. DHCP-Konstanten
Dieser Abschnitt beschreibt verschiedene Programm- und Netzwerkkonstanten, die von DHCP verwendet werden.
5.1. Multicast-Adressen
DHCP verwendet die folgenden Multicast-Adressen:
All_DHCP_Relay_Agents_and_Servers (FF02::1:2)
Eine Link-scoped Multicast-Adresse, die von einem Client verwendet wird, um mit benachbarten (d.h. on-link) Relay-Agents und Servern zu kommunizieren. Alle Server und Relay-Agents sind Mitglieder dieser Multicast-Gruppe.
All_DHCP_Servers (FF05::1:3)
Eine Site-scoped Multicast-Adresse, die von einem Relay-Agent verwendet wird, um mit Servern zu kommunizieren, entweder weil der Relay-Agent Nachrichten an alle Server senden möchte oder weil er die Unicast-Adressen der Server nicht kennt. Beachten Sie, dass ein Relay-Agent, um diese Adresse zu verwenden, eine Adresse mit ausreichendem Bereich haben muss, um von den Servern erreichbar zu sein. Alle Server innerhalb der Site sind Mitglieder dieser Multicast-Gruppe.
5.2. UDP-Ports
Clients lauschen auf DHCP-Nachrichten auf UDP-Port 546. Server und Relay-Agents lauschen auf DHCP-Nachrichten auf UDP-Port 547.
5.3. DHCP-Nachrichtentypen
DHCP definiert die folgenden Nachrichtentypen. Weitere Details zu diesen Nachrichtentypen finden sich in den Abschnitten 6 und 7. Nachrichtentypen, die hier nicht aufgeführt sind, sind für zukünftige Verwendung reserviert. Die numerische Kodierung für jeden Nachrichtentyp ist in Klammern angegeben.
SOLICIT (1)
Ein Client sendet eine Solicit-Nachricht, um Server zu lokalisieren.
ADVERTISE (2)
Ein Server sendet eine Advertise-Nachricht, um anzuzeigen, dass er für DHCP-Dienste verfügbar ist, als Antwort auf eine Solicit-Nachricht, die von einem Client empfangen wurde.
REQUEST (3)
Ein Client sendet eine Request-Nachricht, um Konfigurationsparameter, einschließlich IP-Adressen, von einem bestimmten Server anzufordern.
CONFIRM (4)
Ein Client sendet eine Confirm-Nachricht an einen verfügbaren Server, um zu bestimmen, ob die ihm zugewiesenen Adressen noch für den Link geeignet sind, an den der Client angeschlossen ist.
RENEW (5)
Ein Client sendet eine Renew-Nachricht an den Server, der ursprünglich die Adressen und Konfigurationsparameter des Clients bereitgestellt hat, um die Lebensdauern auf den dem Client zugewiesenen Adressen zu verlängern und andere Konfigurationsparameter zu aktualisieren.
REBIND (6)
Ein Client sendet eine Rebind-Nachricht an einen verfügbaren Server, um die Lebensdauern auf den dem Client zugewiesenen Adressen zu verlängern und andere Konfigurationsparameter zu aktualisieren; diese Nachricht wird gesendet, nachdem ein Client keine Antwort auf eine Renew-Nachricht erhalten hat.
REPLY (7)
Ein Server sendet eine Reply-Nachricht, die zugewiesene Adressen und Konfigurationsparameter enthält, als Antwort auf eine Solicit-, Request-, Renew- oder Rebind-Nachricht, die von einem Client empfangen wurde. Ein Server sendet eine Reply-Nachricht, die Konfigurationsparameter enthält, als Antwort auf eine Information-request-Nachricht. Ein Server sendet eine Reply-Nachricht als Antwort auf eine Confirm-Nachricht, die bestätigt oder verneint, dass die dem Client zugewiesenen Adressen für den Link geeignet sind, an den der Client angeschlossen ist. Ein Server sendet eine Reply-Nachricht, um den Empfang einer Release- oder Decline-Nachricht zu bestätigen.
RELEASE (8)
Ein Client sendet eine Release-Nachricht an den Server, der Adressen an den Client zugewiesen hat, um anzuzeigen, dass der Client eine oder mehrere der zugewiesenen Adressen nicht mehr verwenden wird.
DECLINE (9)
Ein Client sendet eine Decline-Nachricht an einen Server, um anzuzeigen, dass der Client festgestellt hat, dass eine oder mehrere vom Server zugewiesene Adressen bereits auf dem Link verwendet werden, an den der Client angeschlossen ist.
RECONFIGURE (10)
Ein Server sendet eine Reconfigure-Nachricht an einen Client, um den Client zu informieren, dass der Server neue oder aktualisierte Konfigurationsparameter hat und dass der Client eine Renew/Reply- oder Information-request/Reply-Transaktion mit dem Server initiieren soll, um die aktualisierten Informationen zu erhalten.
INFORMATION-REQUEST (11)
Ein Client sendet eine Information-request-Nachricht an einen Server, um Konfigurationsparameter anzufordern, ohne dass dem Client IP-Adressen zugewiesen werden.
RELAY-FORW (12)
Ein Relay-Agent sendet eine Relay-forward-Nachricht, um Nachrichten an Server weiterzuleiten, entweder direkt oder über einen anderen Relay-Agent. Die empfangene Nachricht, entweder eine Client-Nachricht oder eine Relay-forward-Nachricht von einem anderen Relay-Agent, ist in einer Option in der Relay-forward-Nachricht gekapselt.
RELAY-REPL (13)
Ein Server sendet eine Relay-reply-Nachricht an einen Relay-Agent, die eine Nachricht enthält, die der Relay-Agent an einen Client liefert. Die Relay-reply-Nachricht kann von anderen Relay-Agents weitergeleitet werden, um sie an den Ziel-Relay-Agent zu liefern. Der Server kapselt die Client-Nachricht als Option in der Relay-reply-Nachricht, die der Relay-Agent extrahiert und an den Client weiterleitet.
5.4. Statuscodes
DHCPv6 verwendet Statuscodes, um den Erfolg oder das Scheitern von Operationen zu kommunizieren, die in Nachrichten von Clients und Servern angefordert wurden, und um zusätzliche Informationen über die spezifische Ursache des Scheiterns einer Nachricht bereitzustellen. Die spezifischen Statuscodes sind in Abschnitt 24.4 definiert.
5.5. Übertragungs- und Wiederholungsparameter
Dieser Abschnitt präsentiert eine Tabelle von Werten, die verwendet werden, um das Nachrichtenübertragungsverhalten von Clients und Servern zu beschreiben.
| Parameter | Standard | Beschreibung |
|---|---|---|
| SOL_MAX_DELAY | 1 Sek | Max Verzögerung der ersten Solicit |
| SOL_TIMEOUT | 1 Sek | Initiale Solicit-Timeout |
| SOL_MAX_RT | 120 Sek | Max Solicit-Timeout-Wert |
| REQ_TIMEOUT | 1 Sek | Initiale Request-Timeout |
| REQ_MAX_RT | 30 Sek | Max Request-Timeout-Wert |
| REQ_MAX_RC | 10 | Max Request-Wiederholungsversuche |
| CNF_MAX_DELAY | 1 Sek | Max Verzögerung der ersten Confirm |
| CNF_TIMEOUT | 1 Sek | Initiale Confirm-Timeout |
| CNF_MAX_RT | 4 Sek | Max Confirm-Timeout |
| CNF_MAX_RD | 10 Sek | Max Confirm-Dauer |
| REN_TIMEOUT | 10 Sek | Initiale Renew-Timeout |
| REN_MAX_RT | 600 Sek | Max Renew-Timeout-Wert |
| REB_TIMEOUT | 10 Sek | Initiale Rebind-Timeout |
| REB_MAX_RT | 600 Sek | Max Rebind-Timeout-Wert |
| INF_MAX_DELAY | 1 Sek | Max Verzögerung der ersten Information-request |
| INF_TIMEOUT | 1 Sek | Initiale Information-request-Timeout |
| INF_MAX_RT | 120 Sek | Max Information-request-Timeout-Wert |
| REL_TIMEOUT | 1 Sek | Initiale Release-Timeout |
| REL_MAX_RC | 5 | MAX Release-Versuche |
| DEC_TIMEOUT | 1 Sek | Initiale Decline-Timeout |
| DEC_MAX_RC | 5 | Max Decline-Versuche |
| REC_TIMEOUT | 2 Sek | Initiale Reconfigure-Timeout |
| REC_MAX_RC | 8 | Max Reconfigure-Versuche |
| HOP_COUNT_LIMIT | 32 | Max Hop-Zähler in einer Relay-forward-Nachricht |
5.6. Darstellung von Zeitwerten und "Unendlich" als Zeitwert
Alle Zeitwerte für Lebensdauern, T1 und T2 sind vorzeichenlose Ganzzahlen. Der Wert 0xffffffff wird als "Unendlich" interpretiert, wenn er als Lebensdauer (wie in RFC2461 [17]) oder als Wert für T1 oder T2 verwendet wird.