16. Nachrichtenvalidierung
Dieser Abschnitt bewahrt den RFC-Text zu DHCPv6, einschliesslich Nachrichtenaustausch, Relay-Verhalten, DUIDs, IA_NA, IA_TA, IA_PD, DHCP-Optionen, RKAP-Authentifizierung, IANA-Registern, normativen Anforderungen und der Optionsvorkommensmatrizen im Anhang.
Originaler RFC-Text
16. Nachrichtenvalidierung
Dieser Abschnitt beschreibt, welche Optionen in welchen Arten von
Nachrichtentypen gueltig sind, und erklaert, was zu tun ist, wenn ein
Client oder Server eine Nachricht empfaengt, die bekannte Optionen
enthaelt, die fuer diese Nachricht ungueltig sind. Beispielsweise darf
eine IA option nicht in einer Information-request-Nachricht erscheinen.
Clients und Server MAY waehlen, entweder (1) Informationen aus einer
solchen Nachricht zu extrahieren, wenn diese Informationen fuer den
Empfaenger nuetzlich sind, oder (2) eine solche Nachricht vollstaendig
zu ignorieren und sie einfach zu verwerfen.
Wenn ein Server eine Nachricht empfaengt, die er als ungueltig
betrachtet, MAY er eine Reply-Nachricht (oder Advertise-Nachricht, je
nach Bedarf) mit einer Server Identifier option (siehe Section 21.3),
einer Client Identifier option (siehe Section 21.2) (falls eine in der
Nachricht enthalten war) und einer Status Code option (siehe
Section 21.13) mit Status UnspecFail senden.
Clients, Relay Agents und Server MUST NOT Nachrichten verwerfen, die
unbekannte Optionen enthalten (oder Instanzen von Vendor-Optionen mit
unbekannten enterprise-number-Werten). Diese Optionen sollten ignoriert
werden, als ob sie nicht vorhanden waeren. Dies ist entscheidend, um
zukuenftige Erweiterungen von DHCP zu ermoeglichen.
Ein Client oder Server MUST jede empfangene DHCP-Nachricht mit einem
unbekannten Nachrichtentyp verwerfen.
Clients SHOULD NOT Multicast-Nachrichten akzeptieren.
Server SHOULD NOT Unicast-Verkehr von Clients akzeptieren. Die Server
Unicast option (siehe Section 21.12) und der UseMulticast-Statuscode
(siehe Section 21.13) wurden obsolet gemacht; daher sollten Clients
keine Nachrichten mehr an die Unicast-Adresse eines Servers senden und
auch keinen UseMulticast-Statuscode empfangen. Ein Server, der zuvor
die Server Unicast option unterstuetzt hat und aktualisiert wurde, um
sie nicht mehr zu unterstuetzen, MAY jedoch weiterhin Unicast-Nachrichten
empfangen, wenn er dem Client zuvor die Server Unicast option gesendet
hat. Dies verursacht jedoch keinen Schaden, und der Client wird
schliesslich wieder zum Senden von Multicast-Nachrichten wechseln (z.B.
nachdem die Rebinding-Zeit des Lease erreicht ist oder der Client neu
gestartet wurde).
Relay Agents SHOULD NOT Unicast-Nachrichten von Clients akzeptieren.
Hinweis: Die oben genannten Multicast/Unicast-Regeln gelten fuer die
DHCP-Nachrichten in diesem Dokument. Nachrichten, die in anderen und
zukuenftigen Dokumenten definiert werden, koennen andere Regeln haben.
16.1. Verwendung von Transaction IDs
Das Feld "transaction-id" enthaelt einen Wert, der von Clients und
Servern verwendet wird, um Serverantworten mit Client-Nachrichten zu
korrelieren. Ein Client SHOULD eine Zufallszahl erzeugen, die nicht
leicht erraten oder vorhergesagt werden kann, um sie als transaction ID
fuer jede neue Nachricht zu verwenden, die er sendet. Zu beachten ist,
dass ein Client, der leicht vorhersagbare Transaktionskennungen erzeugt,
anfaelliger fuer bestimmte Arten von Angriffen durch Off-Path-Eindringlinge
werden kann. Ein Client MUST die transaction ID bei Wiederuebertragungen
einer Nachricht unveraendert lassen.
16.2. Solicit-Nachricht
Clients MUST jede empfangene Solicit-Nachricht verwerfen.
Server MUST jede Solicit-Nachricht verwerfen, die keine Client
Identifier option enthaelt oder die eine Server Identifier option
enthaelt.
16.3. Advertise-Nachricht
Clients MUST jede empfangene Advertise-Nachricht verwerfen, die eine der
folgenden Bedingungen erfuellt:
* die Nachricht enthaelt keine Server Identifier option (siehe
Section 21.3).
* die Nachricht enthaelt keine Client Identifier option (siehe
Section 21.2).
* der Inhalt der Client Identifier option stimmt nicht mit dem DUID des
Clients ueberein.
* der Wert des Feldes "transaction-id" stimmt nicht mit dem Wert
ueberein, den der Client in seiner Solicit-Nachricht verwendet hat.
Server und Relay Agents MUST jede empfangene Advertise-Nachricht
verwerfen.
16.4. Request-Nachricht
Clients MUST jede empfangene Request-Nachricht verwerfen.
Server MUST jede empfangene Request-Nachricht verwerfen, die eine der
folgenden Bedingungen erfuellt:
* die Nachricht enthaelt keine Server Identifier option (siehe
Section 21.3).
* der Inhalt der Server Identifier option stimmt nicht mit dem DUID des
Servers ueberein.
* die Nachricht enthaelt keine Client Identifier option (siehe
Section 21.2).
16.5. Confirm-Nachricht
Clients MUST jede empfangene Confirm-Nachricht verwerfen.
Server MUST jede empfangene Confirm-Nachricht verwerfen, die keine
Client Identifier option (siehe Section 21.2) enthaelt oder die eine
Server Identifier option (siehe Section 21.3) enthaelt.
16.6. Renew-Nachricht
Clients MUST jede empfangene Renew-Nachricht verwerfen.
Server MUST jede empfangene Renew-Nachricht verwerfen, die eine der
folgenden Bedingungen erfuellt:
* die Nachricht enthaelt keine Server Identifier option (siehe
Section 21.3).
* der Inhalt der Server Identifier option stimmt nicht mit der Kennung
des Servers ueberein.
* die Nachricht enthaelt keine Client Identifier option (siehe
Section 21.2).
16.7. Rebind-Nachricht
Clients MUST jede empfangene Rebind-Nachricht verwerfen.
Server MUST jede empfangene Rebind-Nachricht verwerfen, die keine Client
Identifier option (siehe Section 21.2) enthaelt oder die eine Server
Identifier option (siehe Section 21.3) enthaelt.
16.8. Decline-Nachricht
Clients MUST jede empfangene Decline-Nachricht verwerfen.
Server MUST jede empfangene Decline-Nachricht verwerfen, die eine der
folgenden Bedingungen erfuellt:
* die Nachricht enthaelt keine Server Identifier option (siehe
Section 21.3).
* der Inhalt der Server Identifier option stimmt nicht mit der Kennung
des Servers ueberein.
* die Nachricht enthaelt keine Client Identifier option (siehe
Section 21.2).
16.9. Release-Nachricht
Clients MUST jede empfangene Release-Nachricht verwerfen.
Server MUST jede empfangene Release-Nachricht verwerfen, die eine der
folgenden Bedingungen erfuellt:
* die Nachricht enthaelt keine Server Identifier option (siehe
Section 21.3).
* der Inhalt der Server Identifier option stimmt nicht mit der Kennung
des Servers ueberein.
* die Nachricht enthaelt keine Client Identifier option (siehe
Section 21.2).
16.10. Reply-Nachricht
Clients MUST jede empfangene Reply-Nachricht verwerfen, die eine der
folgenden Bedingungen erfuellt:
* die Nachricht enthaelt keine Server Identifier option (siehe
Section 21.3).
* das Feld "transaction-id" in der Nachricht stimmt nicht mit dem Wert
ueberein, der in der urspruenglichen Nachricht verwendet wurde.
Wenn der Client in der urspruenglichen Nachricht eine Client Identifier
option (siehe Section 21.2) enthalten hat, MUST die Reply-Nachricht eine
Client Identifier option enthalten, und der Inhalt der Client Identifier
option MUST mit dem DUID des Clients uebereinstimmen. Wenn der Client
in der urspruenglichen Nachricht keine Client Identifier option enthalten
hat, MUST NOT die Reply-Nachricht eine Client Identifier option
enthalten.
Server und Relay Agents MUST jede empfangene Reply-Nachricht verwerfen.
16.11. Reconfigure-Nachricht
Server und Relay Agents MUST jede empfangene Reconfigure-Nachricht
verwerfen.
Clients MUST jede Reconfigure-Nachricht verwerfen, die eine der
folgenden Bedingungen erfuellt:
* die Nachricht wurde nicht per Unicast an den Client gesendet.
* die Nachricht enthaelt keine Server Identifier option (siehe
Section 21.3).
* die Nachricht enthaelt keine Client Identifier option (siehe
Section 21.2), die den DUID des Clients enthaelt.
* die Nachricht enthaelt keine Reconfigure Message option (siehe
Section 21.19).
* der msg-type der Reconfigure Message option ist kein gueltiger Wert.
* die Nachricht enthaelt keine Authentifizierung (wie RKAP; siehe
Section 20.4) oder besteht die Authentifizierungsvalidierung nicht.
16.12. Information-request-Nachricht
Clients MUST jede empfangene Information-request-Nachricht verwerfen.
Server MUST jede empfangene Information-request-Nachricht verwerfen, die
eine der folgenden Bedingungen erfuellt:
* die Nachricht enthaelt eine Server Identifier option (siehe
Section 21.3), und der DUID in der Option stimmt nicht mit dem DUID
des Servers ueberein.
* die Nachricht enthaelt eine IA option.
16.13. Relay-forward-Nachricht
Clients MUST jede empfangene Relay-forward-Nachricht verwerfen.
16.14. Relay-reply-Nachricht
Clients und Server MUST jede empfangene Relay-reply-Nachricht verwerfen.