5. Source Address Selection (Selezione dell'Indirizzo Sorgente)

L'algoritmo di selezione dell'indirizzo sorgente produce come output un singolo indirizzo sorgente da utilizzare con un dato indirizzo di destinazione. Questo algoritmo si applica solo agli indirizzi di destinazione IPv6, non agli indirizzi IPv4.

L'algoritmo è specificato qui in termini di un elenco di regole di confronto a coppie che (per un dato indirizzo di destinazione D) impone un ordinamento "maggiore di" sugli indirizzi nell'insieme di candidati CandidateSource(D). L'indirizzo all'inizio dell'elenco dopo il completamento dell'algoritmo è quello che l'algoritmo seleziona.

Si noti che concettualmente, viene eseguito un ordinamento dell'insieme di candidati, dove un insieme di regole definisce l'ordinamento tra gli indirizzi. Ma poiché l'output dell'algoritmo è un singolo indirizzo sorgente, un'implementazione non deve effettivamente ordinare l'insieme; deve solo identificare il valore "massimo" che finisce all'inizio dell'elenco ordinato.

L'ordinamento degli indirizzi nell'insieme di candidati è definito da un elenco di otto regole di confronto a coppie, con ogni regola che pone un ordinamento "maggiore di", "minore di" o "uguale a" su due indirizzi sorgente rispetto l'uno all'altro (e quella regola). Nel caso in cui una data regola produca un pareggio, cioè fornisce un risultato "uguale a" per i due indirizzi, le regole rimanenti DEVONO essere applicate (in ordine) solo a quegli indirizzi che sono in pareggio per rompere il pareggio. Si noti che se una regola produce un singolo chiaro "vincitore" (o insieme di "vincitori" nel caso di pareggi), quegli indirizzi non nell'insieme vincente possono essere scartati da ulteriore considerazione, con regole successive applicate solo agli indirizzi rimanenti. Se le otto regole non riescono a scegliere un singolo indirizzo, il tiebreaker è specifico dell'implementazione.

Quando si confrontano due indirizzi SA e SB dall'insieme di candidati, diciamo "preferire SA" per intendere che SA è "maggiore di" SB, e similmente, diciamo "preferire SB" per intendere che SA è "minore di" SB. Se nessuno dei due è dichiarato preferito, questo significa che SA è "uguale a" SB, e le regole rimanenti si applicano come notato sopra.

Rule 1: Prefer same address.
Se SA = D, allora preferire SA. Similmente, se SB = D, allora preferire SB.

Rule 2: Prefer appropriate scope.
Se Scope(SA) < Scope(SB): Se Scope(SA) < Scope(D), allora preferire SB e altrimenti preferire SA. Similmente, se Scope(SB) < Scope(SA): Se Scope(SB) < Scope(D), allora preferire SA e altrimenti preferire SB.

Discussione: Questa regola deve avere alta priorità perché può influenzare l'interoperabilità.

Rule 3: Avoid deprecated addresses.
Se uno dei due indirizzi sorgente è "preferred" e uno di essi è "deprecated" (nel senso dell'RFC 4862), allora preferire quello che è "preferred".

Rule 4: Prefer home addresses.
Se SA è simultaneamente un indirizzo home e un indirizzo care-of e SB non lo è, allora preferire SA. Similmente, se SB è simultaneamente un indirizzo home e un indirizzo care-of e SA non lo è, allora preferire SB. Se SA è solo un indirizzo home e SB è solo un indirizzo care-of, allora preferire SA. Similmente, se SB è solo un indirizzo home e SA è solo un indirizzo care-of, allora preferire SB.

Le implementazioni che supportano gli indirizzi home DEVONO fornire un meccanismo che consenta a un'applicazione di invertire il senso di questa preferenza e preferire gli indirizzi care-of rispetto agli indirizzi home (ad esempio, tramite appropriate estensioni API come [RFC5014]). L'uso del meccanismo DEVE influenzare solo le regole di selezione per l'applicazione che lo invoca.

Rule 5: Prefer outgoing interface.
Se SA è assegnato all'interfaccia che verrà utilizzata per inviare a D e SB è assegnato a un'interfaccia diversa, allora preferire SA. Similmente, se SB è assegnato all'interfaccia che verrà utilizzata per inviare a D e SA è assegnato a un'interfaccia diversa, allora preferire SB.

Rule 5.5: Prefer addresses in a prefix advertised by the next-hop.
Se SA o il prefisso di SA è assegnato dal next-hop selezionato che verrà utilizzato per inviare a D e SB o il prefisso di SB è assegnato da un next-hop diverso, allora preferire SA. Similmente, se SB o il prefisso di SB è assegnato dal next-hop che verrà utilizzato per inviare a D e SA o il prefisso di SA è assegnato da un next-hop diverso, allora preferire SB.

Discussione: Un'implementazione IPv6 non è tenuta a ricordare quali next-hop hanno pubblicizzato quali prefissi. I modelli concettuali degli host IPv6 nella Sezione 5 di [RFC4861] e nella Sezione 3 di [RFC4191] non hanno tale requisito. Quindi, la Rule 5.5 è applicabile solo alle implementazioni che tracciano queste informazioni.

Rule 6: Prefer matching label.
Se Label(SA) = Label(D) e Label(SB) <> Label(D), allora preferire SA. Similmente, se Label(SB) = Label(D) e Label(SA) <> Label(D), allora preferire SB.

Rule 7: Prefer temporary addresses.
Se SA è un indirizzo temporaneo e SB è un indirizzo pubblico, allora preferire SA. Similmente, se SB è un indirizzo temporaneo e SA è un indirizzo pubblico, allora preferire SB.

Le implementazioni DEVONO fornire un meccanismo che consenta a un'applicazione di invertire il senso di questa preferenza e preferire gli indirizzi pubblici rispetto agli indirizzi temporanei (ad esempio, tramite appropriate estensioni API come [RFC5014]). L'uso del meccanismo DEVE influenzare solo le regole di selezione per l'applicazione che lo invoca. Questa impostazione predefinita ha lo scopo di affrontare le preoccupazioni sulla privacy come discusso in [RFC4941] ma introduce un rischio di potenziale fallimento delle applicazioni a causa della durata relativamente breve degli indirizzi temporanei o a causa della possibilità che la ricerca inversa di un indirizzo temporaneo fallisca o restituisca un nome randomizzato. Le implementazioni per le quali le considerazioni di compatibilità delle applicazioni superano queste preoccupazioni sulla privacy POSSONO invertire il senso di questa regola e per impostazione predefinita preferire gli indirizzi pubblici rispetto agli indirizzi temporanei. CI DOVREBBE essere un'opzione amministrativa (il flag Privacy Preference) per modificare questa preferenza, se l'implementazione supporta gli indirizzi temporanei. Se non c'è tale opzione, CI DEVE essere un'opzione amministrativa per disabilitare gli indirizzi temporanei.

Rule 8: Use longest matching prefix.
Se CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), allora preferire SA. Similmente, se CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), allora preferire SB.

La Rule 8 PUÒ essere sostituita se l'implementazione ha altri mezzi per scegliere tra gli indirizzi sorgente. Ad esempio, se l'implementazione in qualche modo sa quale indirizzo sorgente produrrà le "migliori" prestazioni di comunicazione.