1. Introduction (Einführung)
1. Introduction (Einführung)
Die IPv6-Adressierungsarchitektur [RFC4291] erlaubt die Zuweisung mehrerer Unicast-Adressen zu Schnittstellen. Diese Adressen können unterschiedliche Erreichbarkeitsbereiche (link-local, site-local oder global) haben. Diese Adressen können auch "preferred" oder "deprecated" [RFC4862] sein. Datenschutzüberlegungen haben die Konzepte "public addresses" und "temporary addresses" [RFC4941] eingeführt. Die Mobilitätsarchitektur führt "home addresses" und "care-of addresses" [RFC6275] ein. Darüber hinaus führen Multi-Homing-Situationen zu mehr Adressen pro Knoten. Beispielsweise könnte ein Knoten mehrere Schnittstellen haben, von denen einige Tunnel oder virtuelle Schnittstellen sind, oder eine Site könnte mehrere ISP-Anbindungen mit einem globalen Präfix pro ISP haben.
Das Endergebnis ist, dass IPv6-Implementierungen sehr oft mit mehreren möglichen Quell- und Zieladressen konfrontiert werden, wenn sie eine Kommunikation initiieren. Es ist wünschenswert, Standardalgorithmen zu haben, die für alle Implementierungen gemeinsam sind, um Quell- und Zieladressen auszuwählen, damit Entwickler und Administratoren das Verhalten ihrer Systeme nachvollziehen und vorhersagen können.
Darüber hinaus müssen Dual- oder Hybrid-Stack-Implementierungen, die sowohl IPv6 als auch IPv4 unterstützen, sehr oft zwischen IPv6 und IPv4 wählen, wenn sie eine Kommunikation initiieren, zum Beispiel wenn die DNS-Namensauflösung sowohl IPv6- als auch IPv4-Adressen liefert und der Netzwerkprotokollstapel sowohl IPv6- als auch IPv4-Quelladressen verfügbar hat. In solchen Fällen kann eine einfache Richtlinie, immer IPv6 oder immer IPv4 zu bevorzugen, zu schlechtem Verhalten führen. Als ein Beispiel nehmen wir an, dass ein DNS-Name zu einer globalen IPv6-Adresse und einer globalen IPv4-Adresse aufgelöst wird. Wenn dem Knoten eine globale IPv6-Adresse und eine 169.254/16 automatisch konfigurierte IPv4-Adresse [RFC3927] zugewiesen wurde, dann ist IPv6 die beste Wahl für die Kommunikation. Aber wenn dem Knoten nur eine link-local IPv6-Adresse und eine globale IPv4-Adresse zugewiesen wurde, dann ist IPv4 die beste Wahl für die Kommunikation. Der Zieladressauswahlalgorithmus löst dies mit einem einheitlichen Verfahren zur Wahl zwischen sowohl IPv6- als auch IPv4-Adressen.
Die Algorithmen in diesem Dokument sind als eine Menge von Regeln spezifiziert, die eine partielle Ordnung auf der Menge der verfügbaren Adressen definieren. Im Fall der Quelladressauswahl hat ein Knoten typischerweise mehrere Adressen, die seinen Schnittstellen zugewiesen sind, und die Quelladressordnungsregeln in Abschnitt 5 definieren, welche Adresse die "beste" zur Verwendung ist. Im Fall der Zieladressauswahl könnte das DNS eine Menge von Adressen für einen gegebenen Namen zurückgeben, und eine Anwendung muss entscheiden, welche zuerst verwendet werden soll und in welcher Reihenfolge andere auszuprobieren sind, wenn die erste nicht erreichbar ist. Die Zieladressordnungsregeln in Abschnitt 6 bieten, wenn sie auf die vom DNS zurückgegebene Adressmenge angewendet werden, eine solche empfohlene Ordnung.
Dieses Dokument spezifiziert die Quelladressauswahl und die Zieladressauswahl separat, verwendet aber einen gemeinsamen Kontext, so dass die beiden Algorithmen zusammen nützliche Ergebnisse liefern. Die Algorithmen versuchen, Quell- und Zieladressen mit angemessenem Bereich und Konfigurationsstatus ("preferred" oder "deprecated" im Sinne von RFC 4862) zu wählen. Darüber hinaus schlägt dieses Dokument eine bevorzugte Methode, longest matching prefix, zur Wahl zwischen ansonsten gleichwertigen Adressen in Abwesenheit besserer Informationen vor.
Dieses Dokument spezifiziert auch Richtlinien-Hooks, um eine administrative Übersteuerung des Standardverhaltens zu ermöglichen. Beispielsweise kann ein Administrator mit diesen Hooks ein bevorzugtes Quellpräfix für die Verwendung mit einem Zielpräfix angeben oder Zieladressen mit einem Präfix gegenüber Adressen mit einem anderen Präfix bevorzugen. Diese Hooks geben einem Administrator Flexibilität beim Umgang mit einigen Multi-Homing- und Übergangsszenarien, aber sie sind sicherlich kein Allheilmittel.
Die in diesem Dokument spezifizierten Auswahlregeln MÜSSEN NICHT so ausgelegt werden, dass sie die explizite Wahl einer Anwendung oder höheren Schicht für eine legale Ziel- oder Quelladresse überschreiben.