6. Destination Address Selection (Selezione dell'Indirizzo di Destinazione)
L'algoritmo di selezione dell'indirizzo di destinazione prende un elenco di indirizzi di destinazione e ordina gli indirizzi per produrre un nuovo elenco. È specificato qui in termini di confronto a coppie degli indirizzi DA e DB, dove DA appare prima di DB nell'elenco originale.
L'algoritmo ordina insieme sia gli indirizzi IPv6 che IPv4. Per trovare gli attributi di un indirizzo IPv4 nella policy table, l'indirizzo IPv4 DEVE essere rappresentato come un indirizzo IPv4-mapped.
Scriviamo Source(D) per indicare l'indirizzo sorgente selezionato per una destinazione D. Per gli indirizzi IPv6, la sezione precedente specifica l'algoritmo di selezione dell'indirizzo sorgente. La selezione dell'indirizzo sorgente per gli indirizzi IPv4 non è specificata in questo documento.
Diciamo che Source(D) è indefinito se non c'è un indirizzo sorgente disponibile per la destinazione D. Per gli indirizzi IPv6, questo è solo il caso in cui CandidateSource(D) è l'insieme vuoto.
Il confronto a coppie degli indirizzi di destinazione consiste di dieci regole, che DEVONO essere applicate in ordine. Se una regola determina un risultato, allora le regole rimanenti non sono rilevanti e DEVONO essere ignorate. Le regole successive fungono da tiebreaker per le regole precedenti. Vedere la sezione precedente per una descrizione più lunga di come le regole di tiebreaker del confronto a coppie possono essere utilizzate per ordinare un elenco.
Rule 1: Avoid unusable destinations.
Se DB è noto per essere irraggiungibile o se Source(DB) è indefinito, allora preferire DA. Similmente, se DA è noto per essere irraggiungibile o se Source(DA) è indefinito, allora preferire DB.
Discussione: Un'implementazione potrebbe sapere che una particolare destinazione è irraggiungibile in diversi modi. Ad esempio, la destinazione potrebbe essere raggiunta attraverso un'interfaccia di rete che è attualmente scollegata. Ad esempio, l'implementazione potrebbe conservare informazioni dalla Neighbor Unreachability Detection [RFC4861] per un certo periodo di tempo. In ogni caso, la determinazione dell'irraggiungibilità ai fini di questa regola è specifica dell'implementazione.
Rule 2: Prefer matching scope.
Se Scope(DA) = Scope(Source(DA)) e Scope(DB) <> Scope(Source(DB)), allora preferire DA. Similmente, se Scope(DA) <> Scope(Source(DA)) e Scope(DB) = Scope(Source(DB)), allora preferire DB.
Rule 3: Avoid deprecated addresses.
Se Source(DA) è deprecated e Source(DB) non lo è, allora preferire DB. Similmente, se Source(DA) non è deprecated e Source(DB) è deprecated, allora preferire DA.
Rule 4: Prefer home addresses.
Se Source(DA) è simultaneamente un indirizzo home e un indirizzo care-of e Source(DB) non lo è, allora preferire DA. Similmente, se Source(DB) è simultaneamente un indirizzo home e un indirizzo care-of e Source(DA) non lo è, allora preferire DB.
Se Source(DA) è solo un indirizzo home e Source(DB) è solo un indirizzo care-of, allora preferire DA. Similmente, se Source(DA) è solo un indirizzo care-of e Source(DB) è solo un indirizzo home, allora preferire DB.
Rule 5: Prefer matching label.
Se Label(Source(DA)) = Label(DA) e Label(Source(DB)) <> Label(DB), allora preferire DA. Similmente, se Label(Source(DA)) <> Label(DA) e Label(Source(DB)) = Label(DB), allora preferire DB.
Rule 6: Prefer higher precedence.
Se Precedence(DA) > Precedence(DB), allora preferire DA. Similmente, se Precedence(DA) < Precedence(DB), allora preferire DB.
Rule 7: Prefer native transport.
Se DA è raggiungibile tramite un meccanismo di transizione incapsulante (ad esempio, IPv6 in IPv4) e DB non lo è, allora preferire DB. Similmente, se DB è raggiungibile tramite incapsulamento e DA non lo è, allora preferire DA.
Discussione: Il protocollo IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [RFC5969], l'Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214] e i tunnel configurati [RFC4213] sono esempi di meccanismi di transizione incapsulanti per i quali l'indirizzo di destinazione non ha un prefisso specifico e quindi non può essere assegnata una precedenza inferiore nella policy table. Un'implementazione PUÒ generalizzare questa regola utilizzando un concetto di preferenza dell'interfaccia e dando alle interfacce virtuali (come le interfacce incapsulanti IPv6-in-IPv4) una preferenza inferiore rispetto alle interfacce native (come le interfacce ethernet).
Rule 8: Prefer smaller scope.
Se Scope(DA) < Scope(DB), allora preferire DA. Similmente, se Scope(DA) > Scope(DB), allora preferire DB.
Rule 9: Use longest matching prefix.
Quando DA e DB appartengono alla stessa famiglia di indirizzi (entrambi sono IPv6 o entrambi sono IPv4): Se CommonPrefixLen(Source(DA), DA) > CommonPrefixLen(Source(DB), DB), allora preferire DA. Similmente, se CommonPrefixLen(Source(DA), DA) < CommonPrefixLen(Source(DB), DB), allora preferire DB.
Rule 10: Otherwise, leave the order unchanged.
Se DA precedeva DB nell'elenco originale, preferire DA. Altrimenti, preferire DB.
Le Rules 9 e 10 POSSONO essere sostituite se l'implementazione ha altri mezzi per ordinare gli indirizzi di destinazione. Ad esempio, se l'implementazione in qualche modo sa quali indirizzi di destinazione produrranno le "migliori" prestazioni di comunicazione.