2. Context in Which the Algorithms Operate (Contesto in cui Operano gli Algoritmi)

Il nostro contesto per la selezione degli indirizzi deriva dall'architettura di implementazione più comune, che separa la scelta dell'indirizzo di destinazione dalla scelta dell'indirizzo sorgente. Di conseguenza, abbiamo due algoritmi separati per questi compiti. Gli algoritmi sono progettati per funzionare bene insieme e condividono un meccanismo per la sostituzione della policy amministrativa.

In questa architettura di implementazione, le applicazioni utilizzano API come getaddrinfo() [RFC3493] che restituiscono un elenco di indirizzi all'applicazione. Questo elenco potrebbe contenere sia indirizzi IPv6 che IPv4 (talvolta rappresentati come indirizzi IPv4-mapped). L'applicazione passa quindi un indirizzo di destinazione allo stack di rete con connect() o sendto(). L'applicazione tipicamente proverebbe il primo indirizzo nell'elenco, iterando sull'elenco di indirizzi finché non trova un indirizzo funzionante. In ogni caso, il livello di rete non si trova mai in una situazione in cui deve scegliere un indirizzo di destinazione tra diverse alternative. L'applicazione potrebbe anche specificare un indirizzo sorgente con bind(), ma spesso l'indirizzo sorgente viene lasciato non specificato. Pertanto, il livello di rete sceglie spesso un indirizzo sorgente tra diverse alternative.

Di conseguenza, intendiamo che le implementazioni di API come getaddrinfo() utilizzeranno l'algoritmo di selezione dell'indirizzo di destinazione specificato qui per ordinare l'elenco di indirizzi IPv6 e IPv4 che restituiscono. Separatamente, il livello di rete IPv6 utilizzerà l'algoritmo di selezione dell'indirizzo sorgente quando un'applicazione o un livello superiore non ha specificato un indirizzo sorgente. L'applicazione di questa specifica alla selezione dell'indirizzo sorgente in un livello di rete IPv4 potrebbe essere possibile, ma questo non viene esplorato ulteriormente qui.

Le applicazioni ben comportate NON DOVREBBERO semplicemente utilizzare il primo indirizzo restituito da un'API come getaddrinfo() e poi rinunciare se fallisce. Per molte applicazioni, è appropriato iterare attraverso l'elenco di indirizzi restituiti da getaddrinfo() finché non viene trovato un indirizzo funzionante. Per altre applicazioni, potrebbe essere appropriato provare più indirizzi in parallelo (ad esempio, con un piccolo ritardo tra loro) e utilizzare il primo che ha successo.

Sebbene la selezione dell'indirizzo sorgente e di destinazione sia tipicamente effettuata quando si avvia la comunicazione, anche un risponditore deve gestire la selezione degli indirizzi. In molti casi, questo viene gestito banalmente da un'applicazione utilizzando l'indirizzo sorgente di un pacchetto ricevuto come destinazione della risposta e l'indirizzo di destinazione del pacchetto ricevuto come sorgente della risposta. Altri casi, tuttavia, vengono gestiti come un iniziatore, come quando la richiesta è multicast e quindi la selezione dell'indirizzo sorgente deve ancora avvenire quando si genera una risposta o quando la richiesta include un elenco degli indirizzi dell'iniziatore da cui scegliere una destinazione. Infine, un terzo scenario di applicazione è quello di un'applicazione in ascolto che sceglie su quali indirizzi locali ascoltare. Questo terzo scenario è fuori dall'ambito di questo documento.

Gli algoritmi utilizzano diversi criteri nel prendere le loro decisioni. L'effetto combinato è quello di preferire coppie di indirizzi destinazione/sorgente per i quali i due indirizzi sono di ambito o tipo uguale, preferire ambiti più piccoli rispetto a ambiti più grandi per l'indirizzo di destinazione, preferire indirizzi sorgente non-deprecated, evitare l'uso di indirizzi di transizione quando sono disponibili indirizzi nativi e, a parità di condizioni, preferire coppie di indirizzi con il prefisso comune più lungo possibile. Per la selezione dell'indirizzo sorgente, gli indirizzi temporanei [RFC4941] sono preferiti rispetto agli indirizzi pubblici. In situazioni mobili [RFC6275], gli indirizzi home sono preferiti rispetto agli indirizzi care-of. Se un indirizzo è simultaneamente un indirizzo home e un indirizzo care-of (indicando che il nodo mobile è "a casa" per quell'indirizzo), allora l'indirizzo home/care-of è preferito rispetto agli indirizzi che sono esclusivamente un indirizzo home o esclusivamente un indirizzo care-of.

Questa specifica consente opzionalmente la possibilità di configurazione amministrativa della policy (ad esempio, tramite configurazione manuale o un'opzione DHCP come quella proposta in [ADDR-SEL-OPT]) che può sostituire il comportamento predefinito degli algoritmi. La sostituzione della policy consiste nel seguente insieme di stato, che DOVREBBE essere configurabile:

• Policy Table (Sezione 2.1): una tabella che specifica valori di precedenza e prefissi sorgente preferiti per i prefissi di destinazione.

• Automatic Row Additions flag (Sezione 2.1): un flag che specifica se l'implementazione ha il permesso di aggiungere automaticamente righe specifiche del sito per determinati tipi di indirizzi.

• Privacy Preference flag (Sezione 5): un flag che specifica se gli indirizzi sorgente temporanei o gli indirizzi sorgente stabili sono preferiti per impostazione predefinita quando esistono entrambi i tipi.