4. Protocol Overview (Protokollübersicht)
Dieser Abschnitt gibt einen Überblick über die typischen Schritte, die auftreten, wenn eine Schnittstelle sich selbst autokonfiguriert. Die Autokonfiguration wird nur auf Links durchgeführt, die Multicast unterstützen, und beginnt, wenn eine Multicast-unterstützende Schnittstelle aktiviert wird, z. B. während des Systemstarts. Knoten (Hosts und Router) beginnen den Autokonfigurationsprozess durch Generierung einer Link-Local-Adresse für die Schnittstelle. Die Link-Local-Adresse wird gebildet, indem der Identifikator der Schnittstelle an das bekannte Link-Local-Präfix [RFC4291] angehängt wird.
Bevor jedoch eine Link-Local-Adresse einer Schnittstelle zugewiesen und verwendet wird, muss (MUST) ein Knoten versuchen zu überprüfen, dass diese „vorläufige (Tentative)" Adresse nicht bereits von einem anderen Knoten auf dem Link verwendet wird. Insbesondere sendet er eine Neighbor Solicitation-Nachricht, die die vorläufige Adresse als Ziel enthält. Wenn ein anderer Knoten diese Adresse bereits verwendet, wird er eine Neighbor Advertisement zurücksenden, die dies anzeigt. Wenn ein anderer Knoten ebenfalls versucht, dieselbe Adresse zu verwenden, wird er ebenfalls eine Neighbor Solicitation für das Ziel senden. Die genaue Anzahl der (erneuten) Übertragungen von Neighbor Solicitations und die Verzögerung zwischen aufeinanderfolgenden Solicitations sind link-spezifisch und können (MAY) durch Systemverwaltungskonfiguration festgelegt werden.
Wenn ein Knoten feststellt, dass seine vorläufige Link-Local-Adresse nicht eindeutig ist, stoppt die Autokonfiguration und eine manuelle Konfiguration der Schnittstelle ist erforderlich. Um die Wiederherstellung in diesem Fall zu vereinfachen, sollte (SHOULD) ein Administrator in der Lage sein, einen alternativen Schnittstellenidentifikator bereitzustellen, der den Standardidentifikator überschreibt, sodass der Autokonfigurationsmechanismus mit einem neuen (möglicherweise eindeutigen) Schnittstellenidentifikator angewendet werden kann. Alternativ ist eine manuelle Konfiguration der Link-Local-Adresse und anderer Adressen erforderlich.
Sobald ein Knoten feststellt, dass seine vorläufige Link-Local-Adresse eindeutig ist, weist er die Adresse der Schnittstelle zu. Zu diesem Zeitpunkt hat der Knoten IP-Level-Konnektivität mit benachbarten Knoten. Die verbleibenden Autokonfigurationsschritte werden nur von Hosts ausgeführt; die (automatische) Konfiguration von Routern liegt außerhalb des Umfangs dieses Dokuments.
Die nächste Phase der Autokonfiguration umfasst das Erhalten einer Router Advertisement oder die Feststellung, dass keine Router vorhanden sind. Wenn Router vorhanden sind, senden sie Router Advertisements, die angeben, welche Art von Autokonfiguration ein Host durchführen kann. Es sollte beachtet werden, dass auch bei Abwesenheit von Routern ein DHCPv6-Dienst für die Adresskonfiguration verfügbar sein kann (MAY).
Router senden periodisch Router Advertisements, aber die Verzögerung zwischen aufeinanderfolgenden Advertisements wird im Allgemeinen länger sein, als ein Host, der Autokonfiguration durchführt, warten möchte [RFC4861]. Um schnell eine Advertisement zu erhalten, sendet ein Host eine oder mehrere Router Solicitations an die Multicast-Gruppe aller Router.
Router Advertisements enthalten auch null oder mehr Prefix Information-Optionen, die Informationen enthalten, die von der zustandslosen Adress-Autokonfiguration zur Generierung globaler Adressen verwendet werden. Es sollte beachtet werden, dass ein Host zustandslose Adress-Autokonfiguration und DHCPv6 gleichzeitig verwenden sollte (SHOULD). Ein Prefix Information-Optionsfeld, das « Autonomous Address-Configuration Flag », gibt an, ob die Option überhaupt auf zustandslose Autokonfiguration anwendbar ist. Wenn sie anwendbar ist, enthalten zusätzliche Optionsfelder das Subnetz-Präfix sowie Lebensdauerwerte, die angeben, wie lange von dem Präfix erstellte Adressen bevorzugt und gültig bleiben.
Da Router periodisch Router Advertisements generieren, werden Hosts kontinuierlich neue Advertisements empfangen. Hosts verarbeiten die in jeder Advertisement enthaltenen Informationen wie oben beschrieben, indem sie Informationen hinzufügen und aktualisieren, die in früheren Advertisements empfangen wurden.
Standardmäßig sollten (SHOULD) zu Sicherheitszwecken alle Adressen auf Eindeutigkeit getestet werden, bevor sie einer Schnittstelle zugewiesen werden. Dieser Test sollte (SHOULD) individuell auf allen Adressen durchgeführt werden, die manuell, über zustandslose Adress-Autokonfiguration oder über DHCPv6 erhalten wurden. Um Sites zu berücksichtigen, die glauben, dass der Aufwand für die Durchführung der Duplicate Address Detection ihre Vorteile überwiegt, kann (MAY) die Verwendung der Duplicate Address Detection durch Verwaltungskonfiguration eines Pro-Interface-Konfigurationsflags deaktiviert werden.
Um den Autokonfigurationsprozess zu beschleunigen, kann (MAY) ein Host seine Link-Local-Adresse generieren (und ihre Eindeutigkeit überprüfen) parallel zum Warten auf eine Router Advertisement. Da Router möglicherweise einige Sekunden mit der Antwort auf Router Solicitations warten, kann die Gesamtzeit, die für die Fertigstellung der Autokonfiguration erforderlich ist, erheblich länger sein, wenn diese beiden Schritte seriell ausgeführt werden.
4.1. Site Renumbering (Site-Renummerierung)
Adress-Leases erleichtern die Site-Renummerierung, indem sie einen Mechanismus für das Timeout von Adressen bereitstellen, die Schnittstellen in Hosts zugewiesen sind. Derzeit unterstützen Protokolle der oberen Schicht (wie TCP) nicht das Ändern von Endpunktadressen, während eine Verbindung geöffnet ist. Wenn eine Endpunktadresse ungültig wird, brechen bestehende Verbindungen ab und alle Kommunikationen mit der ungültigen Adresse schlagen fehl. Selbst wenn eine Anwendung UDP als Transportprotokoll verwendet, müssen Adressen im Allgemeinen während eines Paketaustauschs gleich bleiben.
Die Aufteilung gültiger Adressen in bevorzugte und veraltete Kategorien bietet eine Möglichkeit, oberen Schichten anzuzeigen, dass eine gültige Adresse bald ungültig werden kann und dass zukünftige Kommunikationen, die diese Adresse verwenden, fehlschlagen werden, wenn die gültige Lebensdauer der Adresse vor dem Ende der Kommunikation abläuft. Um dies zu vermeiden, sollten (SHOULD) obere Schichten bevorzugte Adressen verwenden (unter der Annahme, dass Adressen ausreichenden Gültigkeitsbereichs existieren), um die Wahrscheinlichkeit zu erhöhen, dass eine Adresse während der Kommunikation gültig bleibt. Systemadministratoren sollten (SHOULD) geeignete Präfix-Lebensdauern festlegen, um die Auswirkungen fehlgeschlagener Kommunikationen zu minimieren, wenn eine Renummerierung auftritt. Die Veraltungszeit sollte (SHOULD) lang genug sein, damit die meisten (wenn nicht alle) Kommunikationen eine neue Adresse verwenden, wenn eine Adresse ungültig wird.
Es wird erwartet, dass die IP-Schicht oberen Schichten (einschließlich Anwendungen) eine Möglichkeit bietet, die am besten geeignete Quelladresse auszuwählen, gegeben ein bestimmtes Ziel und möglicherweise andere Einschränkungen. Anwendungen können (MAY) wählen, die Quelladresse selbst auszuwählen, bevor sie eine neue Kommunikation beginnen, oder können (MAY) wählen, keine Adresse anzugeben, in welchem Fall die obere Netzwerkschicht den von der IP-Schicht bereitgestellten Mechanismus verwendet, um im Namen der Anwendung eine geeignete Adresse auszuwählen.
Detaillierte Adressauswahlregeln liegen außerhalb des Umfangs dieses Dokuments und werden in [RFC3484] beschrieben.