5. Source Address Selection (Quelladressauswahl)

5. Source Address Selection (Quelladressauswahl)

Der Quelladressauswahlalgorithmus erzeugt als Ausgabe eine einzelne Quelladresse zur Verwendung mit einer gegebenen Zieladresse. Dieser Algorithmus gilt nur für IPv6-Zieladressen, nicht für IPv4-Adressen.

Der Algorithmus ist hier als eine Liste paarweiser Vergleichsregeln spezifiziert, die (für eine gegebene Zieladresse D) eine "größer als"-Ordnung auf die Adressen in der Kandidatenmenge CandidateSource(D) auferlegt. Die Adresse an der Spitze der Liste nach Abschluss des Algorithmus ist diejenige, die der Algorithmus auswählt.

Beachten Sie, dass konzeptionell eine Sortierung der Kandidatenmenge durchgeführt wird, wobei eine Reihe von Regeln die Ordnung zwischen Adressen definiert. Da die Ausgabe des Algorithmus jedoch eine einzelne Quelladresse ist, muss eine Implementierung die Menge nicht tatsächlich sortieren; sie muss nur den "Maximalwert" identifizieren, der am Anfang der sortierten Liste endet.

Die Ordnung der Adressen in der Kandidatenmenge ist durch eine Liste von acht paarweisen Vergleichsregeln definiert, wobei jede Regel eine "größer als"-, "kleiner als"- oder "gleich"-Ordnung auf zwei Quelladressen in Bezug aufeinander (und diese Regel) setzt. In dem Fall, dass eine gegebene Regel ein Unentschieden erzeugt, d.h. ein "gleich"-Ergebnis für die beiden Adressen liefert, MÜSSEN die verbleibenden Regeln (in Reihenfolge) auf genau die Adressen angewendet werden, die unentschieden sind, um das Unentschieden zu brechen. Beachten Sie, dass wenn eine Regel einen einzelnen klaren "Gewinner" (oder eine Menge von "Gewinnern" im Fall von Unentschieden) erzeugt, diese Adressen, die nicht in der Gewinnermenge sind, von weiterer Betrachtung verworfen werden können, wobei nachfolgende Regeln nur auf die verbleibenden Adressen angewendet werden. Wenn die acht Regeln keine einzelne Adresse wählen, ist der Tiebreaker implementierungsspezifisch.

Wenn wir zwei Adressen SA und SB aus der Kandidatenmenge vergleichen, sagen wir "bevorzuge SA", um zu bedeuten, dass SA "größer als" SB ist, und ähnlich sagen wir "bevorzuge SB", um zu bedeuten, dass SA "kleiner als" SB ist. Wenn keine bevorzugt wird, bedeutet dies, dass SA "gleich" SB ist, und die verbleibenden Regeln gelten wie oben angegeben.

Rule 1: Prefer same address (Bevorzuge dieselbe Adresse). Wenn SA = D, dann bevorzuge SA. Ebenso, wenn SB = D, dann bevorzuge SB.

Rule 2: Prefer appropriate scope (Bevorzuge angemessenen Bereich). Wenn Scope(SA) < Scope(SB): Wenn Scope(SA) < Scope(D), dann bevorzuge SB und andernfalls bevorzuge SA. Ebenso, wenn Scope(SB) < Scope(SA): Wenn Scope(SB) < Scope(D), dann bevorzuge SA und andernfalls bevorzuge SB.

Diskussion: Diese Regel muss hohe Priorität erhalten, weil sie die Interoperabilität beeinflussen kann.

Rule 3: Avoid deprecated addresses (Vermeide deprecated Adressen). Wenn eine der beiden Quelladressen "preferred" und eine von ihnen "deprecated" (im Sinne von RFC 4862) ist, dann bevorzuge diejenige, die "preferred" ist.

Rule 4: Prefer home addresses (Bevorzuge Home-Adressen). Wenn SA gleichzeitig eine Home-Adresse und Care-of-Adresse ist und SB nicht, dann bevorzuge SA. Ebenso, wenn SB gleichzeitig eine Home-Adresse und Care-of-Adresse ist und SA nicht, dann bevorzuge SB. Wenn SA nur eine Home-Adresse ist und SB nur eine Care-of-Adresse ist, dann bevorzuge SA. Ebenso, wenn SB nur eine Home-Adresse ist und SA nur eine Care-of-Adresse ist, dann bevorzuge SB.

Implementierungen, die Home-Adressen unterstützen, MÜSSEN einen Mechanismus bereitstellen, der es einer Anwendung ermöglicht, den Sinn dieser Präferenz umzukehren und Care-of-Adressen gegenüber Home-Adressen zu bevorzugen (z.B. über geeignete API-Erweiterungen wie [RFC5014]). Die Verwendung des Mechanismus MUSS nur die Auswahlregeln für die aufrufende Anwendung beeinflussen.

Rule 5: Prefer outgoing interface (Bevorzuge ausgehende Schnittstelle). Wenn SA der Schnittstelle zugewiesen ist, die zum Senden an D verwendet wird, und SB einer anderen Schnittstelle zugewiesen ist, dann bevorzuge SA. Ebenso, wenn SB der Schnittstelle zugewiesen ist, die zum Senden an D verwendet wird, und SA einer anderen Schnittstelle zugewiesen ist, dann bevorzuge SB.

Rule 5.5: Prefer addresses in a prefix advertised by the next-hop (Bevorzuge Adressen in einem vom Next-Hop beworbenen Präfix). Wenn SA oder SAs Präfix vom ausgewählten Next-Hop zugewiesen ist, der zum Senden an D verwendet wird, und SB oder SBs Präfix von einem anderen Next-Hop zugewiesen ist, dann bevorzuge SA. Ebenso, wenn SB oder SBs Präfix vom Next-Hop zugewiesen ist, der zum Senden an D verwendet wird, und SA oder SAs Präfix von einem anderen Next-Hop zugewiesen ist, dann bevorzuge SB.

Diskussion: Eine IPv6-Implementierung ist nicht verpflichtet, sich zu merken, welche Next-Hops welche Präfixe beworben haben. Die konzeptionellen Modelle von IPv6-Hosts in Abschnitt 5 von [RFC4861] und Abschnitt 3 von [RFC4191] haben keine solche Anforderung. Daher ist Regel 5.5 nur auf Implementierungen anwendbar, die diese Information verfolgen.

Rule 6: Prefer matching label (Bevorzuge übereinstimmendes Label). Wenn Label(SA) = Label(D) und Label(SB) <> Label(D), dann bevorzuge SA. Ebenso, wenn Label(SB) = Label(D) und Label(SA) <> Label(D), dann bevorzuge SB.

Rule 7: Prefer temporary addresses (Bevorzuge temporäre Adressen). Wenn SA eine temporäre Adresse ist und SB eine öffentliche Adresse ist, dann bevorzuge SA. Ebenso, wenn SB eine temporäre Adresse ist und SA eine öffentliche Adresse ist, dann bevorzuge SB.

Implementierungen MÜSSEN einen Mechanismus bereitstellen, der es einer Anwendung ermöglicht, den Sinn dieser Präferenz umzukehren und öffentliche Adressen gegenüber temporären Adressen zu bevorzugen (z.B. über geeignete API-Erweiterungen wie [RFC5014]). Die Verwendung des Mechanismus MUSS nur die Auswahlregeln für die aufrufende Anwendung beeinflussen. Diese Standardeinstellung soll Datenschutzbedenken wie in [RFC4941] diskutiert adressieren, führt aber ein Risiko ein, dass Anwendungen möglicherweise aufgrund der relativ kurzen Lebensdauer temporärer Adressen oder aufgrund der Möglichkeit, dass die umgekehrte Suche einer temporären Adresse entweder fehlschlägt oder einen zufälligen Namen zurückgibt, versagen. Implementierungen, für die Anwendungskompatibilitätsüberlegungen diese Datenschutzbedenken überwiegen, KÖNNEN den Sinn dieser Regel umkehren und standardmäßig öffentliche Adressen gegenüber temporären Adressen bevorzugen. Es SOLLTE eine administrative Option (das Privacy Preference Flag) geben, um diese Präferenz zu ändern, wenn die Implementierung temporäre Adressen unterstützt. Wenn es keine solche Option gibt, MUSS es eine administrative Option geben, um temporäre Adressen zu deaktivieren.

Rule 8: Use longest matching prefix (Verwende längstes übereinstimmendes Präfix). Wenn CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), dann bevorzuge SA. Ebenso, wenn CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), dann bevorzuge SB.

Regel 8 KANN ersetzt werden, wenn die Implementierung andere Mittel zur Wahl zwischen Quelladressen hat. Zum Beispiel, wenn die Implementierung irgendwie weiß, welche Quelladresse zur "besten" Kommunikationsleistung führen wird.