4. Protocol Overview (Panoramica del protocollo)
Questa sezione fornisce una panoramica dei passaggi tipici che si verificano quando un'interfaccia si configura automaticamente. La configurazione automatica viene eseguita solo su link che supportano il multicast e inizia quando un'interfaccia che supporta il multicast viene abilitata, ad esempio durante l'avvio del sistema. I nodi (host e router) iniziano il processo di configurazione automatica generando un indirizzo link-local per l'interfaccia. L'indirizzo link-local viene formato aggiungendo l'identificatore dell'interfaccia al prefisso link-local noto [RFC4291].
Tuttavia, prima che un indirizzo link-local venga assegnato a un'interfaccia e utilizzato, un nodo deve (MUST) tentare di verificare che questo indirizzo « provvisorio (Tentative) » non sia già utilizzato da un altro nodo sul link. In particolare, invia un messaggio di Neighbor Solicitation contenente l'indirizzo provvisorio come target. Se un altro nodo sta già utilizzando quell'indirizzo, restituirà una Neighbor Advertisement che lo indica. Se un altro nodo sta anche tentando di utilizzare lo stesso indirizzo, invierà anch'esso una Neighbor Solicitation per il target. Il numero esatto di (ri)trasmissioni di Neighbor Solicitation e il ritardo tra solicitation consecutive sono specifici del link e possono (MAY) essere impostati tramite configurazione dell'amministrazione di sistema.
Se un nodo determina che il suo indirizzo link-local provvisorio non è univoco, la configurazione automatica si arresta ed è necessaria una configurazione manuale dell'interfaccia. Per semplificare il recupero in questo caso, un amministratore dovrebbe (SHOULD) poter fornire un identificatore di interfaccia alternativo che sostituisca l'identificatore predefinito, in modo che il meccanismo di configurazione automatica possa essere applicato con un nuovo identificatore di interfaccia (possibilmente univoco). In alternativa, è necessaria una configurazione manuale dell'indirizzo link-local e di altri indirizzi.
Una volta che un nodo determina che il suo indirizzo link-local provvisorio è univoco, assegna l'indirizzo all'interfaccia. A questo punto, il nodo ha connettività a livello IP con i nodi vicini. I restanti passaggi di configurazione automatica sono eseguiti solo dagli host; la configurazione (automatica) dei router è al di fuori dell'ambito di questo documento.
La fase successiva della configurazione automatica implica l'ottenimento di una Router Advertisement o la determinazione che nessun router è presente. Se sono presenti router, invieranno Router Advertisement specificando quale tipo di configurazione automatica può eseguire un host. Si deve notare che anche in assenza di router, un servizio DHCPv6 per la configurazione degli indirizzi può (MAY) essere ancora disponibile.
I router inviano periodicamente Router Advertisement, ma il ritardo tra advertisement consecutivi sarà generalmente più lungo del tempo che un host che esegue la configurazione automatica vorrebbe attendere [RFC4861]. Per ottenere rapidamente un'advertisement, un host invia una o più Router Solicitation al gruppo multicast di tutti i router.
Le Router Advertisement contengono anche zero o più opzioni di Prefix Information, che contengono informazioni utilizzate dalla configurazione automatica di indirizzi senza stato per generare indirizzi globali. Si deve notare che un host dovrebbe (SHOULD) utilizzare simultaneamente la configurazione automatica di indirizzi senza stato e DHCPv6. Un campo dell'opzione Prefix Information, il « flag di configurazione di indirizzo autonomo (Autonomous Address-Configuration Flag) », indica se l'opzione si applica anche alla configurazione automatica senza stato. Se si applica, campi di opzione aggiuntivi contengono il prefisso di sottorete e valori di durata di vita che indicano per quanto tempo gli indirizzi creati dal prefisso rimangono preferiti e validi.
Poiché i router generano periodicamente Router Advertisement, gli host riceveranno continuamente nuove advertisement. Gli host elaborano le informazioni contenute in ogni advertisement, come descritto sopra, aggiungendo e aggiornando le informazioni ricevute nelle advertisement precedenti.
Per impostazione predefinita, per motivi di sicurezza, tutti gli indirizzi dovrebbero (SHOULD) essere testati per l'unicità prima di essere assegnati a un'interfaccia. Questo test dovrebbe (SHOULD) essere eseguito individualmente su tutti gli indirizzi ottenuti manualmente, tramite configurazione automatica di indirizzi senza stato o tramite DHCPv6. Per accomodare i siti che ritengono che il sovraccarico dell'esecuzione del rilevamento di indirizzi duplicati superi i suoi benefici, l'uso del rilevamento di indirizzi duplicati può (MAY) essere disabilitato tramite configurazione amministrativa di un flag di configurazione per interfaccia.
Per accelerare il processo di configurazione automatica, un host può (MAY) generare il suo indirizzo link-local (e verificare la sua unicità) in parallelo con l'attesa di una Router Advertisement. Poiché i router possono ritardare di alcuni secondi la risposta alle Router Solicitation, se questi due passaggi vengono eseguiti in serie, il tempo totale necessario per completare la configurazione automatica può essere significativamente più lungo.
4.1. Site Renumbering (Rinumerazione del sito)
I leasing di indirizzi facilitano la rinumerazione del sito fornendo un meccanismo per il timeout degli indirizzi assegnati alle interfacce negli host. Attualmente, i protocolli di livello superiore (come TCP) non supportano la modifica degli indirizzi degli endpoint mentre una connessione è aperta. Se un indirizzo di endpoint diventa non valido, le connessioni esistenti si interrompono e tutte le comunicazioni con l'indirizzo non valido falliscono. Anche se un'applicazione utilizza UDP come protocollo di trasporto, gli indirizzi generalmente devono rimanere gli stessi durante uno scambio di pacchetti.
La divisione degli indirizzi validi in categorie preferite e deprecate fornisce un modo per indicare ai livelli superiori che un indirizzo valido potrebbe presto diventare non valido e che le comunicazioni future che utilizzano quell'indirizzo falliranno se la durata di vita valida dell'indirizzo scade prima della fine della comunicazione. Per evitare ciò, i livelli superiori dovrebbero (SHOULD) utilizzare indirizzi preferiti (supponendo che esistano indirizzi di ambito sufficiente) per aumentare la probabilità che un indirizzo rimanga valido durante la comunicazione. Gli amministratori di sistema dovrebbero (SHOULD) impostare durate di vita di prefisso appropriate per minimizzare l'impatto delle comunicazioni fallite quando si verifica una rinumerazione. Il periodo di deprecazione dovrebbe (SHOULD) essere sufficientemente lungo affinché la maggior parte (se non tutte) delle comunicazioni utilizzi un nuovo indirizzo quando un indirizzo diventa non valido.
Si prevede che il livello IP fornisca un modo per i livelli superiori (incluse le applicazioni) di selezionare l'indirizzo sorgente più appropriato, data una particolare destinazione e possibilmente altri vincoli. Le applicazioni possono (MAY) scegliere di selezionare esse stesse l'indirizzo sorgente prima di iniziare una nuova comunicazione, oppure possono (MAY) scegliere di non specificare un indirizzo, nel qual caso il livello di rete superiore utilizzerà il meccanismo fornito dal livello IP per selezionare un indirizzo appropriato per conto dell'applicazione.
Le regole dettagliate di selezione degli indirizzi sono al di fuori dell'ambito di questo documento e sono descritte in [RFC3484].