1. Introduction (Introduzione)
L'architettura di indirizzamento IPv6 [RFC4291] consente l'assegnazione di più indirizzi unicast alle interfacce. Questi indirizzi potrebbero avere diversi ambiti di raggiungibilità (link-local, site-local o global). Questi indirizzi potrebbero anche essere "preferred" o "deprecated" [RFC4862]. Le considerazioni sulla privacy hanno introdotto i concetti di "indirizzi pubblici" e "indirizzi temporanei" [RFC4941]. L'architettura di mobilità introduce "indirizzi home" e "indirizzi care-of" [RFC6275]. Inoltre, le situazioni di multi-homing comporteranno più indirizzi per nodo. Ad esempio, un nodo potrebbe avere più interfacce, alcune delle quali tunnel o interfacce virtuali, oppure un sito potrebbe avere più collegamenti ISP con un prefisso globale per ISP.
Il risultato finale è che le implementazioni IPv6 si troveranno molto spesso di fronte a più possibili indirizzi sorgente e di destinazione quando avviano la comunicazione. È auspicabile avere algoritmi predefiniti, comuni a tutte le implementazioni, per la selezione degli indirizzi sorgente e di destinazione in modo che gli sviluppatori e gli amministratori possano ragionare e prevedere il comportamento dei loro sistemi.
Inoltre, le implementazioni dual-stack o hybrid-stack, che supportano sia IPv6 che IPv4, dovranno molto spesso scegliere tra IPv6 e IPv4 quando avviano la comunicazione, ad esempio quando la risoluzione del nome DNS restituisce sia indirizzi IPv6 che IPv4 e lo stack del protocollo di rete ha disponibili sia indirizzi sorgente IPv6 che IPv4. In tali casi, una semplice policy di preferire sempre IPv6 o sempre IPv4 può produrre comportamenti scadenti. Come esempio, supponiamo che un nome DNS si risolva in un indirizzo IPv6 globale e un indirizzo IPv4 globale. Se il nodo ha assegnato un indirizzo IPv6 globale e un indirizzo IPv4 auto-configurato 169.254/16 [RFC3927], allora IPv6 è la scelta migliore per la comunicazione. Ma se il nodo ha assegnato solo un indirizzo IPv6 link-local e un indirizzo IPv4 globale, allora IPv4 è la scelta migliore per la comunicazione. L'algoritmo di selezione dell'indirizzo di destinazione risolve questo problema con una procedura unificata per scegliere tra indirizzi sia IPv6 che IPv4.
Gli algoritmi in questo documento sono specificati come un insieme di regole che definiscono un ordinamento parziale sull'insieme di indirizzi disponibili per l'uso. Nel caso della selezione dell'indirizzo sorgente, un nodo ha tipicamente più indirizzi assegnati alle sue interfacce, e le regole di ordinamento dell'indirizzo sorgente nella Sezione 5 definiscono quale indirizzo è il "migliore" da usare. Nel caso della selezione dell'indirizzo di destinazione, il DNS potrebbe restituire un insieme di indirizzi per un dato nome, e un'applicazione deve decidere quale usare per primo e in quale ordine provare gli altri se il primo non è raggiungibile. Le regole di ordinamento dell'indirizzo di destinazione nella Sezione 6, quando applicate all'insieme di indirizzi restituiti dal DNS, forniscono tale ordinamento raccomandato.
Questo documento specifica la selezione dell'indirizzo sorgente e la selezione dell'indirizzo di destinazione separatamente ma utilizza un contesto comune in modo che insieme i due algoritmi producano risultati utili. Gli algoritmi tentano di scegliere indirizzi sorgente e di destinazione di ambito e stato di configurazione appropriati ("preferred" o "deprecated" nel senso dell'RFC 4862). Inoltre, questo documento suggerisce un metodo preferito, il prefisso corrispondente più lungo, per scegliere tra indirizzi altrimenti equivalenti in assenza di informazioni migliori.
Questo documento specifica anche hook di policy per consentire la sostituzione amministrativa del comportamento predefinito. Ad esempio, utilizzando questi hook, un amministratore può specificare un prefisso sorgente preferito da utilizzare con un prefisso di destinazione o preferire indirizzi di destinazione con un prefisso rispetto a indirizzi con un altro prefisso. Questi hook forniscono a un amministratore flessibilità nel trattare alcuni scenari di multi-homing e transizione, ma certamente non sono una panacea.
Le regole di selezione specificate in questo documento NON DEVONO essere interpretate come una sostituzione della scelta esplicita di un'applicazione o di un livello superiore di un indirizzo di destinazione o sorgente legale.