6. Destination Address Selection (Zieladressauswahl)
6. Destination Address Selection (Zieladressauswahl)
Der Zieladressauswahlalgorithmus nimmt eine Liste von Zieladressen und sortiert die Adressen, um eine neue Liste zu erzeugen. Er ist hier in Bezug auf den paarweisen Vergleich von Adressen DA und DB spezifiziert, wobei DA vor DB in der ursprünglichen Liste erscheint.
Der Algorithmus sortiert sowohl IPv6- als auch IPv4-Adressen zusammen. Um die Attribute einer IPv4-Adresse in der Richtlinientabelle zu finden, MUSS die IPv4-Adresse als IPv4-mapped-Adresse dargestellt werden.
Wir schreiben Source(D), um die ausgewählte Quelladresse für ein Ziel D anzuzeigen. Für IPv6-Adressen spezifiziert der vorherige Abschnitt den Quelladressauswahlalgorithmus. Die Quelladressauswahl für IPv4-Adressen ist in diesem Dokument nicht spezifiziert.
Wir sagen, dass Source(D) undefiniert ist, wenn keine Quelladresse für Ziel D verfügbar ist. Für IPv6-Adressen ist dies nur der Fall, wenn CandidateSource(D) die leere Menge ist.
Der paarweise Vergleich von Zieladressen besteht aus zehn Regeln, die in Reihenfolge angewendet werden MÜSSEN. Wenn eine Regel ein Ergebnis bestimmt, dann sind die verbleibenden Regeln nicht relevant und MÜSSEN ignoriert werden. Nachfolgende Regeln dienen als Tiebreaker für frühere Regeln. Siehe den vorherigen Abschnitt für eine ausführlichere Beschreibung, wie paarweise Vergleichs-Tiebreaker-Regeln verwendet werden können, um eine Liste zu sortieren.
Rule 1: Avoid unusable destinations (Vermeide unbrauchbare Ziele). Wenn DB bekanntermaßen unerreichbar ist oder wenn Source(DB) undefiniert ist, dann bevorzuge DA. Ebenso, wenn DA bekanntermaßen unerreichbar ist oder wenn Source(DA) undefiniert ist, dann bevorzuge DB.
Diskussion: Eine Implementierung könnte auf mehrere Arten wissen, dass ein bestimmtes Ziel unerreichbar ist. Zum Beispiel könnte das Ziel über eine Netzwerkschnittstelle erreicht werden, die derzeit nicht angeschlossen ist. Zum Beispiel könnte die Implementierung Informationen von Neighbor Unreachability Detection [RFC4861] für einen bestimmten Zeitraum behalten. In jedem Fall ist die Bestimmung der Unerreichbarkeit für die Zwecke dieser Regel implementierungsabhängig.
Rule 2: Prefer matching scope (Bevorzuge übereinstimmenden Bereich). Wenn Scope(DA) = Scope(Source(DA)) und Scope(DB) <> Scope(Source(DB)), dann bevorzuge DA. Ebenso, wenn Scope(DA) <> Scope(Source(DA)) und Scope(DB) = Scope(Source(DB)), dann bevorzuge DB.
Rule 3: Avoid deprecated addresses (Vermeide deprecated Adressen). Wenn Source(DA) deprecated ist und Source(DB) nicht, dann bevorzuge DB. Ebenso, wenn Source(DA) nicht deprecated ist und Source(DB) deprecated ist, dann bevorzuge DA.
Rule 4: Prefer home addresses (Bevorzuge Home-Adressen). Wenn Source(DA) gleichzeitig eine Home-Adresse und Care-of-Adresse ist und Source(DB) nicht, dann bevorzuge DA. Ebenso, wenn Source(DB) gleichzeitig eine Home-Adresse und Care-of-Adresse ist und Source(DA) nicht, dann bevorzuge DB.
Wenn Source(DA) nur eine Home-Adresse ist und Source(DB) nur eine Care-of-Adresse ist, dann bevorzuge DA. Ebenso, wenn Source(DA) nur eine Care-of-Adresse ist und Source(DB) nur eine Home-Adresse ist, dann bevorzuge DB.
Rule 5: Prefer matching label (Bevorzuge übereinstimmendes Label). Wenn Label(Source(DA)) = Label(DA) und Label(Source(DB)) <> Label(DB), dann bevorzuge DA. Ebenso, wenn Label(Source(DA)) <> Label(DA) und Label(Source(DB)) = Label(DB), dann bevorzuge DB.
Rule 6: Prefer higher precedence (Bevorzuge höhere Präzedenz). Wenn Precedence(DA) > Precedence(DB), dann bevorzuge DA. Ebenso, wenn Precedence(DA) < Precedence(DB), dann bevorzuge DB.
Rule 7: Prefer native transport (Bevorzuge nativen Transport). Wenn DA über einen einkapselnden Übergangsmechanismus (z.B. IPv6 in IPv4) erreicht wird und DB nicht, dann bevorzuge DB. Ebenso, wenn DB über Einkapselung erreicht wird und DA nicht, dann bevorzuge DA.
Diskussion: Das IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) Protokoll [RFC5969], das Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214] und konfigurierte Tunnel [RFC4213] sind Beispiele für einkapselnde Übergangsmechanismen, für die die Zieladresse kein spezifisches Präfix hat und daher keine niedrigere Präzedenz in der Richtlinientabelle zugewiesen werden kann. Eine Implementierung KANN diese Regel verallgemeinern, indem sie ein Konzept der Schnittstellenpräferenz verwendet und virtuellen Schnittstellen (wie den IPv6-in-IPv4-Einkapselnden Schnittstellen) eine niedrigere Präferenz gibt als nativen Schnittstellen (wie Ethernet-Schnittstellen).
Rule 8: Prefer smaller scope (Bevorzuge kleineren Bereich). Wenn Scope(DA) < Scope(DB), dann bevorzuge DA. Ebenso, wenn Scope(DA) > Scope(DB), dann bevorzuge DB.
Rule 9: Use longest matching prefix (Verwende längstes übereinstimmendes Präfix). Wenn DA und DB zur selben Adressfamilie gehören (beide sind IPv6 oder beide sind IPv4): Wenn CommonPrefixLen(Source(DA), DA) > CommonPrefixLen(Source(DB), DB), dann bevorzuge DA. Ebenso, wenn CommonPrefixLen(Source(DA), DA) < CommonPrefixLen(Source(DB), DB), dann bevorzuge DB.
Rule 10: Otherwise, leave the order unchanged (Andernfalls Reihenfolge unverändert lassen). Wenn DA vor DB in der ursprünglichen Liste stand, bevorzuge DA. Andernfalls bevorzuge DB.
Die Regeln 9 und 10 KÖNNEN ersetzt werden, wenn die Implementierung andere Mittel zum Sortieren von Zieladressen hat. Zum Beispiel, wenn die Implementierung irgendwie weiß, welche Zieladressen zur "besten" Kommunikationsleistung führen werden.