12.1. Requesting router behavior (Verhalten des anfragenden Routers)

12.1. Requesting router behavior (Verhalten des anfragenden Routers)

Der anfragende Router verwendet eine Request-Nachricht, um IA_PDs mit Präfixen zu füllen. Der anfragende Router schließt eine oder mehrere IA_PD-Optionen in die Request-Nachricht ein. Der delegierende Router gibt dann die Präfixe für die IA_PDs in IA_PD-Optionen in einer Reply-Nachricht an den anfragenden Router zurück.

Der anfragende Router schließt IA_PD-Optionen in alle Renew- oder Rebind-Nachrichten ein, die vom anfragenden Router gesendet werden. Die IA_PD-Option schließt alle Präfixe ein, die der anfragende Router derzeit mit dieser IA_PD verbunden hat.

Unter bestimmten Umständen kann der anfragende Router eine Verifikation benötigen, dass der delegierende Router noch eine gültige Bindung für den anfragenden Router hat. Beispiele für Zeiten, zu denen ein anfragender Router um eine solche Verifikation bitten könnte, umfassen:

• Der anfragende Router wird neu gestartet.

• Der Upstream-Link des anfragenden Routers flappt.

• Der anfragende Router wird physisch von einer kabelgebundenen Verbindung getrennt.

Wenn eine solche Verifikation benötigt wird, MUSS der anfragende Router einen Rebind/Reply-Nachrichtenaustausch initiieren, wie in Abschnitt 18.1.4, "Creation and Transmission of Rebind Messages" von RFC 3315 beschrieben, mit der Ausnahme, dass die Retransmission-Parameter wie für die Confirm-Nachricht gesetzt werden sollten, wie in Abschnitt 18.1.2, "Creation and Transmission of Confirm Messages" von RFC 3315 beschrieben. Der anfragende Router schließt alle IA_PDs zusammen mit den mit diesen IA_PDs verbundenen Präfixen in seine Rebind-Nachricht ein.

Jedes Präfix hat gültige und bevorzugte Lebensdauern, deren Dauer in der IA_PD Prefix Option für dieses Präfix spezifiziert ist. Der anfragende Router verwendet Renew- und Rebind-Nachrichten, um die Verlängerung der Lebensdauern eines delegierten Präfixes anzufordern.

Der anfragende Router verwendet eine Release-Nachricht, um ein delegiertes Präfix an einen delegierenden Router zurückzugeben. Die freizugebenden Präfixe MÜSSEN in den IA_PDs enthalten sein.

Die Nachrichtentypen Confirm und Decline werden nicht mit Präfix-Delegation verwendet.

Nach dem Empfang einer gültigen Reply-Nachricht weist der anfragende Router für jede IA_PD ein Subnetz aus jedem der delegierten Präfixe jedem der Links zu, an die die zugehörigen Schnittstellen angeschlossen sind, mit der folgenden Ausnahme: Der anfragende Router DARF KEINE delegierten Präfixe oder Subnetze aus den delegierten Präfix(en) dem Link zuweisen, über den er die DHCP-Nachricht vom delegierenden Router erhalten hat.

Wenn ein anfragender Router ein delegiertes Präfix subnetiert, muss er zusätzliche Bits zum Präfix hinzufügen, um eindeutige, längere Präfixe zu generieren. Wenn beispielsweise dem anfragenden Router in Abbildung 1 3FFE:FFFF:0::/48 delegiert würde, könnte er 3FFE:FFFF:0:1::/64 und 3FFE:FFFF:0:2::/64 für die Zuweisung an die zwei Links im Teilnehmernetzwerk generieren. Wenn dem anfragenden Router 3FFE:FFFF:0::/48 und 3FFE:FFFF:5::/48 delegiert würden, könnte er 3FFE:FFFF:0:1::/64 und 3FFE:FFFF:5:1::/64 einem der Links zuweisen und 3FFE:FFFF:0:2::/64 und 3FFE:FFFF:5:2::/64 für die Zuweisung an den anderen Link.

Wenn der anfragende Router ein delegiertes Präfix einem Link zuweist, an den der Router angeschlossen ist, und beginnt, Router Advertisements für das Präfix auf dem Link zu senden, MUSS der anfragende Router die gültige Lebensdauer in diesen Advertisements so setzen, dass sie nicht später als die in der IA_PD Prefix Option spezifizierte gültige Lebensdauer ist. Ein anfragender Router KANN die in der IA_PD Prefix Option spezifizierte bevorzugte Lebensdauer verwenden.

Die Behandlung von Status Codes-Optionen in empfangenen Reply-Nachrichten wird in Abschnitt 18.1.8, "Receipt of Reply Messages" von RFC 3315 beschrieben. Der NoPrefixAvail Status Code wird auf die gleiche Weise wie der NoAddrsAvail Status Code behandelt.