2. Context in Which the Algorithms Operate (Kontext)

2. Context in Which the Algorithms Operate (Kontext, in dem die Algorithmen arbeiten)

Unser Kontext für die Adressauswahl leitet sich von der gängigsten Implementierungsarchitektur ab, die die Wahl der Zieladresse von der Wahl der Quelladresse trennt. Folglich haben wir zwei separate Algorithmen für diese Aufgaben. Die Algorithmen sind so konzipiert, dass sie gut zusammenarbeiten, und sie teilen sich einen Mechanismus für administrative Richtlinienübersteuerung.

In dieser Implementierungsarchitektur verwenden Anwendungen APIs wie getaddrinfo() [RFC3493], die eine Liste von Adressen an die Anwendung zurückgeben. Diese Liste könnte sowohl IPv6- als auch IPv4-Adressen (manchmal als IPv4-mapped-Adressen dargestellt) enthalten. Die Anwendung übergibt dann eine Zieladresse mit connect() oder sendto() an den Netzwerkstapel. Die Anwendung würde dann typischerweise die erste Adresse in der Liste versuchen und die Liste der Adressen durchlaufen, bis sie eine funktionierende Adresse findet. In jedem Fall befindet sich die Netzwerkschicht niemals in einer Situation, in der sie eine Zieladresse aus mehreren Alternativen wählen muss. Die Anwendung könnte auch eine Quelladresse mit bind() angeben, aber oft wird die Quelladresse nicht spezifiziert. Daher wählt die Netzwerkschicht oft eine Quelladresse aus mehreren Alternativen.

Folglich beabsichtigen wir, dass Implementierungen von APIs wie getaddrinfo() den hier spezifizierten Zieladressauswahlalgorithmus verwenden, um die Liste der IPv6- und IPv4-Adressen zu sortieren, die sie zurückgeben. Separat wird die IPv6-Netzwerkschicht den Quelladressauswahlalgorithmus verwenden, wenn eine Anwendung oder höhere Schicht keine Quelladresse spezifiziert hat. Die Anwendung dieser Spezifikation auf die Quelladressauswahl in einer IPv4-Netzwerkschicht könnte möglich sein, wird hier aber nicht weiter untersucht.

Gut verhaltende Anwendungen SOLLTEN NICHT einfach die erste von einer API wie getaddrinfo() zurückgegebene Adresse verwenden und dann aufgeben, wenn sie fehlschlägt. Für viele Anwendungen ist es angemessen, die von getaddrinfo() zurückgegebene Adressliste zu durchlaufen, bis eine funktionierende Adresse gefunden wird. Für andere Anwendungen könnte es angemessen sein, mehrere Adressen parallel zu versuchen (z.B. mit einer kleinen Verzögerung dazwischen) und die erste zu verwenden, die erfolgreich ist.

Obwohl die Quell- und Zieladressauswahl am häufigsten beim Initiieren der Kommunikation durchgeführt wird, muss sich auch ein Responder mit der Adressauswahl befassen. In vielen Fällen wird dies trivial von einer Anwendung behandelt, die die Quelladresse eines empfangenen Pakets als Antwortziel und die Zieladresse des empfangenen Pakets als Antwortquelle verwendet. Andere Fälle werden jedoch wie ein Initiator behandelt, z.B. wenn die Anfrage Multicast ist und daher bei der Generierung einer Antwort immer noch eine Quelladressauswahl stattfinden muss, oder wenn die Anfrage eine Liste der Adressen des Initiators enthält, aus denen ein Ziel gewählt werden soll. Schließlich ist ein drittes Anwendungsszenario das einer lauschenden Anwendung, die wählt, auf welchen lokalen Adressen sie lauschen soll. Dieses dritte Szenario liegt außerhalb des Geltungsbereichs dieses Dokuments.

Die Algorithmen verwenden mehrere Kriterien bei ihren Entscheidungen. Der kombinierte Effekt besteht darin, Ziel-/Quelladresspaare zu bevorzugen, für die die beiden Adressen von gleichem Bereich oder Typ sind, kleinere Bereiche gegenüber größeren Bereichen für die Zieladresse zu bevorzugen, nicht-deprecated Quelladressen zu bevorzugen, die Verwendung von Übergangsadressen zu vermeiden, wenn native Adressen verfügbar sind, und bei sonst gleichen Bedingungen Adresspaare mit dem längstmöglichen gemeinsamen Präfix zu bevorzugen. Für die Quelladressauswahl werden temporäre Adressen [RFC4941] gegenüber öffentlichen Adressen bevorzugt. In mobilen Situationen [RFC6275] werden Home-Adressen gegenüber Care-of-Adressen bevorzugt. Wenn eine Adresse gleichzeitig eine Home-Adresse und eine Care-of-Adresse ist (was anzeigt, dass der mobile Knoten für diese Adresse "zu Hause" ist), dann wird die Home-/Care-of-Adresse gegenüber Adressen bevorzugt, die ausschließlich eine Home-Adresse oder ausschließlich eine Care-of-Adresse sind.

Diese Spezifikation erlaubt optional die Möglichkeit der administrativen Konfiguration von Richtlinien (z.B. über manuelle Konfiguration oder eine DHCP-Option wie die in [ADDR-SEL-OPT] vorgeschlagene), die das Standardverhalten der Algorithmen überschreiben können. Die Richtlinienübersteuerung besteht aus dem folgenden Satz von Zuständen, die konfigurierbar sein SOLLTEN:

• Policy Table (Abschnitt 2.1): eine Tabelle, die Präzedenzwerte und bevorzugte Quellpräfixe für Zielpräfixe spezifiziert.

• Automatic Row Additions flag (Abschnitt 2.1): ein Flag, das spezifiziert, ob die Implementierung berechtigt ist, automatisch site-spezifische Zeilen für bestimmte Adresstypen hinzuzufügen.

• Privacy Preference flag (Abschnitt 5): ein Flag, das spezifiziert, ob temporäre Quelladressen oder stabile Quelladressen standardmäßig bevorzugt werden, wenn beide Typen existieren.