Passa al contenuto principale

5. Protocol Specification (Specifica del protocollo)

L'autoconfigurazione viene eseguita su base per interfaccia su interfacce che supportano il multicast. Per le macchine multihomed, l'autoconfigurazione viene eseguita indipendentemente su ciascuna interfaccia. L'autoconfigurazione si applica principalmente agli host, con due eccezioni. I router dovrebbero generare un indirizzo link-local utilizzando la procedura delineata di seguito. Inoltre, i router eseguono il rilevamento di indirizzi duplicati su tutti gli indirizzi prima di assegnarli a un'interfaccia.

5.1. Node Configuration Variables (Variabili di configurazione del nodo)​

Un nodo deve (MUST) consentire la configurazione da parte dell'amministrazione del sistema delle seguenti variabili relative all'autoconfigurazione per ogni interfaccia che supporta il multicast:

DupAddrDetectTransmits - Il numero di messaggi di sollecitazione di vicino consecutivi inviati durante l'esecuzione del rilevamento di indirizzi duplicati su un indirizzo provvisorio. Un valore di zero indica che il rilevamento di indirizzi duplicati non viene eseguito su indirizzi provvisori. Un valore di uno indica una singola trasmissione senza ritrasmissioni successive.

Valore predefinito: 1, ma può essere sovrascritto da un valore specifico del tipo di collegamento in un documento specifico del tipo di collegamento che copre i problemi relativi alla trasmissione di IP su un particolare tipo di collegamento (ad esempio, [RFC2464]).

L'autoconfigurazione presuppone anche l'esistenza della variabile RetransTimer definita in [RFC4861]. Ai fini dell'autoconfigurazione, RetransTimer specifica il ritardo tra trasmissioni consecutive di sollecitazioni di vicino eseguite durante il rilevamento di indirizzi duplicati (se DupAddrDetectTransmits è maggiore di uno), nonché il tempo che un nodo attende dopo aver inviato l'ultima sollecitazione di vicino prima di terminare il processo di rilevamento di indirizzi duplicati.

Al di là della formazione di un indirizzo link-local e dell'uso del rilevamento di indirizzi duplicati, il modo in cui i router (auto)configurano le loro interfacce è al di fuori dell'ambito di questo documento.

Gli host mantengono un elenco di indirizzi con le loro corrispondenti durate di vita. L'elenco degli indirizzi contiene sia indirizzi autoconfigurati che configurati manualmente.

Un nodo forma un indirizzo link-local ogni volta che un'interfaccia viene abilitata. Un'interfaccia può essere abilitata dopo uno dei seguenti eventi:

  • L'interfaccia viene inizializzata all'avvio del sistema.
  • L'interfaccia viene reinizializzata dopo un guasto temporaneo dell'interfaccia o dopo essere stata temporaneamente disabilitata dall'amministrazione del sistema.
  • L'interfaccia viene collegata a un link per la prima volta. Ciò include i casi in cui il link collegato cambia dinamicamente a causa di un cambiamento del punto di accesso alla rete wireless.
  • L'interfaccia viene abilitata dall'amministrazione del sistema dopo essere stata disabilitata amministrativamente.

L'indirizzo link-local viene formato combinando il noto prefisso link-local FE80::0 [RFC4291] (di lunghezza appropriata) con un identificatore di interfaccia come segue:

  1. I bit più a sinistra 'lunghezza prefisso' dell'indirizzo sono i bit del prefisso link-local.
  2. I bit nell'indirizzo a destra del prefisso link-local sono tutti impostati a zero.
  3. Se la lunghezza dell'identificatore di interfaccia è di N bit, i N bit più a destra dell'indirizzo vengono sostituiti dall'identificatore di interfaccia.

Se la somma della lunghezza del prefisso link-local e di N è maggiore di 128, l'autoconfigurazione fallisce ed è richiesta la configurazione manuale. La lunghezza dell'identificatore di interfaccia è definita in un documento separato specifico del tipo di collegamento, che dovrebbe anche essere coerente con l'architettura degli indirizzi [RFC4291] (vedere Sezione 2). Questi documenti definiranno attentamente le lunghezze in modo che un indirizzo link-local possa essere autoconfigurato su un link.

Un indirizzo link-local ha una durata di vita preferita e valida infinita; non scade mai.

5.4. Duplicate Address Detection (Rilevamento di indirizzi duplicati)​

Il rilevamento di indirizzi duplicati deve (MUST) essere eseguito su tutti gli indirizzi unicast prima di assegnarli a un'interfaccia, sia che siano ottenuti tramite autoconfigurazione senza stato, DHCPv6 o configurazione manuale, con le seguenti eccezioni:

  • Le interfacce in cui la variabile DupAddrDetectTransmits è impostata su zero non eseguono il rilevamento di indirizzi duplicati.

  • Un indirizzo unicast di cui si sa che è unico (ad esempio, un indirizzo ottenuto tramite configurazione manuale con stato o DHCPv6 utilizzando un meccanismo sufficiente per prevenire la duplicazione) può (MAY) eseguire il rilevamento di indirizzi duplicati (ma non è richiesto (MUST NOT)).

  • Il rilevamento di indirizzi duplicati non deve (MUST NOT) essere eseguito su indirizzi anycast (si noti che un indirizzo anycast non può essere sintatticamente distinto da un indirizzo unicast).

  • Ogni singolo indirizzo unicast dovrebbe (SHOULD) essere testato per l'unicità. Si noti che le implementazioni distribuite eseguono solo il rilevamento di indirizzi duplicati per gli indirizzi link-local e saltano il test per gli indirizzi globali che utilizzano lo stesso identificatore di interfaccia dell'indirizzo link-local. Sebbene questo documento non invalidi queste implementazioni, questa "ottimizzazione" non è raccomandata (NOT RECOMMENDED), e le nuove implementazioni non devono (MUST NOT) eseguire questa ottimizzazione. Questa ottimizzazione deriva dall'assunzione che tutti gli indirizzi di interfaccia siano generati dallo stesso identificatore. Tuttavia, questa assunzione in realtà non è vera; sono stati introdotti nuovi tipi di indirizzi in cui gli identificatori di interfaccia per tutti gli indirizzi unicast su una singola interfaccia non sono necessariamente gli stessi [RFC4941] [RFC3972]. Il requisito di eseguire il rilevamento di indirizzi duplicati per tutti gli indirizzi unicast renderà l'algoritmo robusto per gli identificatori di interfaccia speciali attuali e futuri.

La procedura per rilevare gli indirizzi duplicati utilizza messaggi di sollecitazione e annuncio di vicino, come descritto di seguito. Se durante la procedura viene scoperto un indirizzo duplicato, l'indirizzo non può essere assegnato all'interfaccia. Se l'indirizzo è derivato da un identificatore di interfaccia, un nuovo identificatore deve essere assegnato all'interfaccia, oppure tutti gli indirizzi IP per l'interfaccia devono essere configurati manualmente. Si noti che la procedura per rilevare gli indirizzi duplicati non è completamente affidabile, ed è comunque possibile che esistano indirizzi duplicati (ad esempio, se il link è stato partizionato durante l'esecuzione del rilevamento di indirizzi duplicati).

Un indirizzo su cui viene applicata la procedura di rilevamento di indirizzi duplicati è detto provvisorio fino al completamento con successo della procedura. Un indirizzo provvisorio non è considerato "assegnato a un'interfaccia" nel senso tradizionale. Cioè, l'interfaccia deve accettare messaggi di sollecitazione e annuncio di vicino contenenti l'indirizzo provvisorio nel campo indirizzo target, ma l'elaborazione di questi pacchetti è diversa da quella dei pacchetti il cui indirizzo target corrisponde a un indirizzo assegnato all'interfaccia. Altri pacchetti diretti all'indirizzo provvisorio dovrebbero essere scartati silenziosamente. Si noti che gli "altri pacchetti" includono messaggi di sollecitazione e annuncio di vicino che hanno l'indirizzo provvisorio (cioè, unicast) come indirizzo di destinazione IP e l'indirizzo provvisorio nel campo indirizzo target. Tuttavia, tali messaggi non dovrebbero verificarsi nell'operazione normale perché questi messaggi vengono inviati in multicast nella procedura di rilevamento di indirizzi duplicati.

Si dovrebbe anche notare che il rilevamento di indirizzi duplicati deve essere eseguito prima di assegnare l'indirizzo all'interfaccia per evitare che più nodi utilizzino lo stesso indirizzo contemporaneamente. Se un nodo inizia a utilizzare un indirizzo in parallelo con l'esecuzione del rilevamento di indirizzi duplicati e un altro nodo sta già utilizzando l'indirizzo, il nodo che esegue il rilevamento di indirizzi duplicati elaborerebbe erroneamente il traffico indirizzato all'altro nodo, portando a possibili conseguenze negative come il ripristino di connessioni TCP aperte.

Le sottosezioni seguenti descrivono i test specifici che un nodo esegue per verificare l'unicità di un indirizzo. Se nessuno dei test indica la presenza di un indirizzo duplicato entro RetransTimer millisecondi dopo l'invio di DupAddrDetectTransmits sollecitazioni di vicino, l'indirizzo è considerato unico. Una volta determinato che l'indirizzo è unico, può essere assegnato all'interfaccia.

5.4.1. Message Validation (Validazione del messaggio)​

Un nodo deve (MUST) scartare silenziosamente qualsiasi messaggio di sollecitazione o annuncio di vicino che non superi i controlli di validità specificati in [RFC4861]. Un messaggio di sollecitazione o annuncio di vicino che supera questi controlli di validità è chiamato rispettivamente una sollecitazione valida o un annuncio valido.

5.4.2. Sending Neighbor Solicitation Messages (Invio di messaggi di sollecitazione di vicino)​

Prima di inviare una sollecitazione di vicino, un'interfaccia deve (MUST) unirsi all'indirizzo multicast all-nodes e all'indirizzo multicast solicited-node dell'indirizzo provvisorio. Il primo assicura che il nodo riceva annunci di vicino da altri nodi già in uso dell'indirizzo; il secondo assicura che due nodi che tentano simultaneamente di utilizzare lo stesso indirizzo dovrebbero rilevare la presenza l'uno dell'altro.

Per verificare un indirizzo, un nodo invia DupAddrDetectTransmits sollecitazioni di vicino, ciascuna separata da RetransTimer millisecondi. L'indirizzo target della sollecitazione è impostato sull'indirizzo in corso di verifica, l'indirizzo IP sorgente è impostato sull'indirizzo non specificato e l'indirizzo IP di destinazione è impostato sull'indirizzo multicast solicited-node dell'indirizzo target.

Se la sollecitazione di vicino fosse il primo pacchetto da inviare dall'interfaccia dopo (re)inizializzazione dell'interfaccia, il nodo dovrebbe (SHOULD) ritardare l'unione all'indirizzo multicast solicited-node di un ritardo casuale tra 0 e MAX_RTR_SOLICITATION_DELAY come specificato in [RFC4861]. Questo aiuta a mitigare la congestione quando molti nodi si avviano contemporaneamente su un link (ad esempio, dopo un'interruzione di corrente) e può aiutare a evitare condizioni di gara quando più nodi tentano di sollecitare lo stesso indirizzo contemporaneamente.

Anche se la sollecitazione di vicino non è il primo pacchetto da inviare, il nodo dovrebbe (SHOULD) ritardare l'unione all'indirizzo multicast solicited-node di un ritardo casuale tra 0 e MAX_RTR_SOLICITATION_DELAY se l'indirizzo in corso di verifica è configurato da un messaggio di annuncio di router inviato a un indirizzo multicast. Il ritardo eviterà una congestione simile quando più nodi configurano indirizzi ricevendo lo stesso singolo annuncio di router multicast.

Si noti che quando un nodo si unisce a un indirizzo multicast, generalmente invia un messaggio di rapporto Multicast Listener Discovery (MLD) [RFC2710] [RFC3810] per l'indirizzo multicast. Nel caso del rilevamento di indirizzi duplicati, il rapporto MLD è necessario per informare gli switch in ascolto MLD (piuttosto che i router) di inoltrare i pacchetti multicast. Nella descrizione sopra, il ritardo dell'unione all'indirizzo multicast implica quindi ritardare la trasmissione del messaggio di rapporto MLD corrispondente. Poiché la specifica MLD non richiede un ritardo casuale per evitare condizioni di gara, ritardare solo la sollecitazione di vicino comporterebbe una congestione dei messaggi di rapporto MLD. La congestione impedirebbe quindi agli switch in ascolto MLD di funzionare correttamente, impedendo così al rilevamento di indirizzi duplicati di funzionare. Il requisito di includere il ritardo del rapporto MLD in questo caso evita questa situazione. [RFC3590] discute anche alcuni problemi di interazione tra il rilevamento di indirizzi duplicati e MLD e specifica quale indirizzo sorgente dovrebbe essere utilizzato per i rapporti MLD in questo caso.

Per migliorare la robustezza dell'algoritmo di rilevamento di indirizzi duplicati, un'interfaccia deve (MUST) ricevere ed elaborare datagrammi inviati all'indirizzo multicast all-nodes o all'indirizzo multicast solicited-node dell'indirizzo provvisorio durante il periodo di ritardo. Questo non è necessariamente in conflitto con il requisito di ritardare l'unione al gruppo multicast. Infatti, in alcuni casi, un nodo può iniziare ad ascoltare il gruppo durante il periodo di ritardo prima della trasmissione del rapporto MLD. Tuttavia, si dovrebbe notare che in alcuni ambienti di livello collegamento, in particolare con switch in ascolto MLD, non sarà possibile ricevere il multicast prima di inviare il rapporto MLD.

5.4.3. Receiving Neighbor Solicitation Messages (Ricezione di messaggi di sollecitazione di vicino)​

Alla ricezione, un nodo deve (MUST) verificare se l'indirizzo target o l'indirizzo sorgente di una sollecitazione di vicino corrisponde a un indirizzo provvisorio. Se corrisponde, la sollecitazione di vicino riguarda un indirizzo per il quale è in corso il rilevamento di indirizzi duplicati. L'elaborazione differisce a seconda che corrisponda l'indirizzo target o l'indirizzo sorgente.

Se l'indirizzo target corrisponde all'indirizzo provvisorio:

L'indirizzo sorgente della sollecitazione di vicino si riferisce all'indirizzo IP sorgente del mittente. Se l'indirizzo IP sorgente della sollecitazione di vicino è l'indirizzo non specificato (0:0:0:0:0:0:0:0), la sorgente sta eseguendo il rilevamento di indirizzi duplicati per quell'indirizzo, quindi la sollecitazione di vicino è stata inviata dal rilevamento di indirizzi duplicati. Altrimenti, la sorgente sta utilizzando l'indirizzo come indirizzo unicast. In entrambi i casi, la sollecitazione di vicino indica che l'indirizzo provvisorio del nodo è duplicato. La sollecitazione di vicino indica che il mittente della sollecitazione di vicino che tenta di verificare che l'indirizzo provvisorio del nodo non sia duplicato non lo farà. La sollecitazione di vicino indica che l'indirizzo è duplicato.

Un nodo che riceve tale sollecitazione di vicino non deve (MUST NOT) inviare un annuncio di vicino (altrimenti, l'indirizzo è provvisorio e non dovrebbe ancora (SHOULD NOT) essere utilizzato). Invece, la ricezione di tale sollecitazione di vicino indica che l'indirizzo provvisorio in corso di verifica è duplicato, quindi il nodo deve (MUST) interrompere immediatamente il processo di invio di sollecitazioni di vicino.

Se l'indirizzo sorgente corrisponde all'indirizzo provvisorio:

Questo indica che un altro nodo sta anche utilizzando lo stesso indirizzo come provvisorio e sta eseguendo simultaneamente il rilevamento di indirizzi duplicati. Questo è un fenomeno atteso quando più interfacce vengono inizializzate contemporaneamente (ad esempio, all'avvio del sistema). Tuttavia, la ricezione di questa sollecitazione di vicino indica che l'indirizzo è duplicato, quindi il nodo deve (MUST) interrompere immediatamente l'invio di sollecitazioni di vicino.

Un nodo può ricevere una sollecitazione di vicino mentre il rilevamento di vicino è in corso, ma dopo aver già interrotto l'invio prima che la duplicazione fosse rilevata. In questo caso, la sollecitazione di vicino dovrebbe (SHOULD) essere ignorata (tranne nel caso della Sezione 5.4.4).

5.4.4. Receiving Neighbor Advertisement Messages (Ricezione di messaggi di annuncio di vicino)​

Per il rilevamento di indirizzi duplicati (DAD), un nodo deve (MUST) verificare se l'indirizzo target della sollecitazione di vicino corrisponde a un indirizzo provvisorio e se l'indirizzo target dell'annuncio di vicino corrisponde all'indirizzo provvisorio. Se corrisponde, l'annuncio di vicino indica che l'indirizzo è duplicato. Se non corrisponde, l'annuncio non è pertinente.

Alla ricezione di un annuncio di vicino con un indirizzo target corrispondente a un indirizzo provvisorio, un nodo deve (MUST) interrompere l'invio di sollecitazioni di vicino e rileva che l'indirizzo è utilizzato sul link.

5.4.5. When Duplicate Address Detection Fails (Quando il rilevamento di indirizzi duplicati fallisce)​

Un indirizzo provvisorio determinato come duplicato come descritto sopra non deve (MUST NOT) essere assegnato a un'interfaccia, e il nodo dovrebbe (SHOULD) registrare un errore di amministrazione del sistema.

Se l'indirizzo è un indirizzo link-local formato da un identificatore di interfaccia basato su un indirizzo hardware che dovrebbe essere assegnato in modo univoco (ad esempio, un EUI-64 per un'interfaccia Ethernet), le operazioni IP sull'interfaccia dovrebbero (SHOULD) essere disabilitate. Disabilitando le operazioni IP, il nodo:

  • Non invierà alcun pacchetto IP dall'interfaccia,
  • Scarterà silenziosamente tutti i pacchetti IP ricevuti sull'interfaccia, e
  • Non inoltrerà alcun pacchetto IP all'interfaccia (quando agisce come router o elabora pacchetti con un'intestazione di routing).

In questo caso, la duplicazione dell'indirizzo IP può significare che è in uso un indirizzo hardware duplicato, e il tentativo di recuperare configurando un altro indirizzo IP non porterà a una rete utilizzabile. In effetti, può peggiorare la situazione creando problemi più difficili da diagnosticare rispetto alla semplice disabilitazione delle operazioni di rete sull'interfaccia; l'utente vedrà una rete parzialmente funzionante dove alcune cose funzionano e altre no.

D'altra parte, se l'indirizzo link-local duplicato non è formato da un identificatore di interfaccia basato su un indirizzo hardware che dovrebbe essere assegnato in modo univoco, le operazioni IP possono (MAY) continuare sull'interfaccia.

Nota: Come indicato nella Sezione 2, "IP" nella descrizione sopra significa "IPv6". Sebbene il ragionamento di fondo riguardante gli indirizzi hardware sia indipendente da un particolare protocollo di rete, le sue implicazioni per altri protocolli sono al di fuori dell'ambito di questo documento.

5.5. Creation of Global Addresses (Creazione di indirizzi globali)​

Gli indirizzi globali sono formati aggiungendo un identificatore di interfaccia a un prefisso di lunghezza appropriata. I prefissi sono ottenuti dalle opzioni di informazioni sul prefisso contenute negli annunci di router. La creazione di indirizzi globali descritta in questa sezione dovrebbe (SHOULD) essere configurabile localmente. Tuttavia, l'elaborazione descritta di seguito deve (MUST) essere abilitata per impostazione predefinita.

5.5.1. Soliciting Router Advertisements (Sollecitazione di annunci di router)​

Gli annunci di router vengono inviati periodicamente all'indirizzo multicast all-nodes. Per ottenere rapidamente un annuncio, un host invia una sollecitazione di router, come descritto in [RFC4861].

5.5.2. Absence of Router Advertisements (Assenza di annunci di router)​

Anche se non ci sono router sul link, un servizio DHCPv6 per ottenere indirizzi può essere ancora disponibile e un host può voler utilizzare quel servizio. Dal punto di vista dell'autoconfigurazione, se non vengono ricevuti annunci di router dopo aver inviato alcune sollecitazioni di router (come descritto in [RFC4861]), non ci sono router sul link.

Si noti che, in questo senso, potrebbero non esserci router sul link, ma potrebbe esserci un nodo con la capacità di inoltrare pacchetti. In questo caso, l'indirizzo del nodo di inoltro deve essere configurato manualmente nell'host per inviare pacchetti off-link, poiché l'unico meccanismo per autoconfigurare l'indirizzo del router predefinito è il meccanismo degli annunci di router.

5.5.3. Router Advertisement Processing (Elaborazione degli annunci di router)​

Per ogni opzione di informazioni sul prefisso in un annuncio di router:

a) Se il flag autonomo non è impostato, ignorare silenziosamente l'opzione di informazioni sul prefisso.

b) Se il prefisso è il prefisso link-local, ignorare silenziosamente l'opzione di informazioni sul prefisso.

c) Se la durata di vita preferita è maggiore della durata di vita valida, ignorare silenziosamente l'opzione di informazioni sul prefisso. In questo caso, un nodo può (MAY) voler registrare un errore di amministrazione del sistema.

d) Se il prefisso annunciato non è uguale al prefisso di un indirizzo di autoconfigurazione senza stato già presente nell'elenco associato all'interfaccia (dove "uguale" significa che entrambe le lunghezze del prefisso sono le stesse e i bit di lunghezza del prefisso del prefisso sono identici), e se la durata di vita valida non è zero, formare un indirizzo (e aggiungerlo all'elenco) combinando il prefisso annunciato con l'identificatore di interfaccia del link come segue:

|            128 - N bits               |       N bits           |
+---------------------------------------+------------------------+
|            link prefix                |  interface identifier  |
+----------------------------------------------------------------+

Se la somma della lunghezza del prefisso e della lunghezza dell'identificatore di interfaccia non è uguale a 128 bit, l'opzione di informazioni sul prefisso deve (MUST) essere ignorata. In questo caso, un'implementazione può (MAY) voler registrare un errore di amministrazione del sistema. La lunghezza dell'identificatore di interfaccia è definita in un documento separato specifico del tipo di collegamento, che dovrebbe anche essere coerente con l'architettura degli indirizzi [RFC4291] (vedere Sezione 2).

È responsabilità dell'amministratore di sistema assicurarsi che la lunghezza dei prefissi contenuti negli annunci di router sia coerente con la lunghezza dell'identificatore di interfaccia per quel tipo di collegamento. Tuttavia, si dovrebbe notare che ciò non significa che la lunghezza del prefisso annunciato sia priva di significato. In effetti, la lunghezza annunciata ha un significato non banale per la determinazione on-link in [RFC4861], dove la somma della lunghezza del prefisso e della lunghezza dell'identificatore di interfaccia potrebbe non essere uguale a 128. Pertanto, dovrebbe essere sicuro validare qui la lunghezza del prefisso annunciato per rilevare ed evitare errori di configurazione che specificano lunghezze di prefisso non valide nel contesto dell'autoconfigurazione degli indirizzi.

Si noti che le versioni future dell'architettura degli indirizzi [RFC4291] e i futuri documenti specifici del tipo di collegamento (che saranno comunque coerenti tra loro) possono consentire identificatori di interfaccia di lunghezze diverse dai valori definiti nei documenti attuali. Pertanto, le implementazioni non dovrebbero (SHOULD NOT) assumere una particolare costante. Invece, dovrebbero aspettarsi identificatori di interfaccia di qualsiasi lunghezza.

Se l'indirizzo è formato con successo e non è già nell'elenco, l'host lo aggiunge all'elenco degli indirizzi assegnati all'interfaccia, inizializzando i suoi valori di durata di vita preferita e valida dall'opzione di informazioni sul prefisso. Si noti che il controllo eseguito sul prefisso all'inizio di questo passaggio non rileva sempre conflitti di indirizzi nell'elenco. È possibile che un indirizzo già esistente nell'elenco (tramite configurazione manuale o configurazione DHCPv6) risulti identico all'indirizzo appena creato, e questa dovrebbe essere una situazione atipica.

e) Se il prefisso annunciato è uguale al prefisso di un indirizzo nell'elenco che è stato configurato tramite autoconfigurazione senza stato, la durata di vita preferita dell'indirizzo viene ripristinata alla durata di vita preferita nell'annuncio ricevuto. L'operazione specifica eseguita sulla durata di vita valida dell'indirizzo dipende dalla durata di vita valida nell'annuncio ricevuto e dal tempo rimanente fino alla scadenza della durata di vita valida dell'indirizzo precedentemente autoconfigurato. Nella discussione seguente, chiameremo il tempo rimanente "RemainingLifetime":

  1. Se la durata di vita valida ricevuta è maggiore di 2 ore o maggiore di RemainingLifetime, impostare la durata di vita valida dell'indirizzo corrispondente sulla durata di vita valida annunciata.
  2. Se RemainingLifetime è minore o uguale a 2 ore, ignorare l'opzione di informazioni sul prefisso riguardo alla durata di vita valida, a meno che l'annuncio di router da cui è stata ottenuta questa opzione non sia stato autenticato (ad esempio, tramite Secure Neighbor Discovery [RFC3971]). Se l'annuncio di router è stato autenticato, la durata di vita valida dell'indirizzo corrispondente dovrebbe (SHOULD) essere impostata sulla durata di vita valida nell'opzione ricevuta.
  3. Altrimenti, ripristinare la durata di vita valida dell'indirizzo corrispondente a 2 ore.

Le regole sopra affrontano un attacco denial-of-service specifico in cui annunci contraffatti potrebbero contenere prefissi con durate di vita valide molto brevi. Senza le regole sopra, un singolo annuncio non autenticato contenente un'opzione di informazioni sul prefisso contraffatta con una durata di vita valida breve potrebbe causare la scadenza prematura di tutti gli indirizzi di un nodo. Le regole sopra assicurano che gli annunci legittimi (che vengono inviati periodicamente) li "annullino" prima che la durata di vita valida breve prenda effettivamente effetto.

Si noti che la durata di vita preferita dell'indirizzo corrispondente viene sempre ripristinata alla durata di vita preferita nell'opzione di informazioni sul prefisso ricevuta, indipendentemente dal fatto che la durata di vita valida venga ripristinata o ignorata. La differenza deriva dal fatto che i possibili attacchi sulla durata di vita preferita sono relativamente minori. Inoltre, ignorare la durata di vita preferita non è nemmeno desiderabile quando un amministratore legittimo desidera deprecare un particolare indirizzo inviando una durata di vita preferita breve (e la durata di vita valida viene accidentalmente ignorata).

5.5.4. Address Lifetime Expiry (Scadenza della durata di vita dell'indirizzo)​

Quando la durata di vita preferita di un indirizzo preferito scade, l'indirizzo preferito diventa deprecato. Un indirizzo deprecato dovrebbe (SHOULD) continuare a essere utilizzato come indirizzo sorgente nelle comunicazioni esistenti, ma non dovrebbe (SHOULD NOT) essere utilizzato per avviare nuove comunicazioni se un indirizzo alternativo (non deprecato) di ambito sufficiente può essere facilmente utilizzato.

Si noti che la fattibilità dell'uso di un indirizzo non deprecato per avviare nuove comunicazioni può essere una decisione specifica dell'applicazione, poiché solo l'applicazione può sapere se l'indirizzo (ora) deprecato è (o è ancora) in uso dall'applicazione. Ad esempio, se un'applicazione specifica esplicitamente allo stack del protocollo di utilizzare l'indirizzo deprecato come indirizzo sorgente, lo stack del protocollo deve accettarlo; l'applicazione può richiederlo perché quell'indirizzo IP è utilizzato nella comunicazione di livello superiore e può richiedere che più connessioni in tali pacchetti utilizzino la stessa coppia di indirizzi IP.

IP e i livelli superiori (ad esempio, TCP, UDP) devono (MUST) continuare ad accettare ed elaborare datagrammi inviati a un indirizzo deprecato, poiché un indirizzo deprecato è ancora un indirizzo valido per l'interfaccia. Nel caso di TCP, questo significa rispondere a un segmento TCP SYN inviato a un indirizzo deprecato utilizzando l'indirizzo deprecato come indirizzo sorgente nel corrispondente SYN-ACK (se tale connessione sarà consentita).

Le implementazioni possono (MAY) impedire a qualsiasi nuova comunicazione di utilizzare un indirizzo deprecato, ma l'amministrazione del sistema deve (MUST) avere la capacità di disabilitare tale struttura, e tale struttura deve (MUST) essere disabilitata per impostazione predefinita.

Si dovrebbero anche notare altri casi sottili di selezione dell'indirizzo sorgente. Ad esempio, la descrizione sopra non chiarisce quale indirizzo dovrebbe essere utilizzato tra un indirizzo deprecato di ambito più piccolo e un indirizzo non deprecato di ambito sufficiente. I dettagli della selezione dell'indirizzo incluso questo caso sono descritti in [RFC3484] e sono al di fuori dell'ambito di questo documento.

Quando la durata di vita valida di un indirizzo (e la sua associazione con un'interfaccia) scade, l'indirizzo diventa non valido. Un indirizzo non valido non deve (MUST NOT) essere utilizzato come indirizzo sorgente nelle comunicazioni in uscita e non deve (MUST NOT) essere riconosciuto come destinazione sull'interfaccia ricevente.

5.6. Configuration Consistency (Coerenza della configurazione)​

Un host può utilizzare simultaneamente l'autoconfigurazione senza stato e DHCPv6 per ottenere informazioni sugli indirizzi, poiché entrambi possono essere abilitati contemporaneamente. I valori di altri parametri di configurazione (come la dimensione MTU e il limite di hop) possono anche essere appresi dagli annunci di router e da DHCPv6. Se le stesse informazioni di configurazione sono fornite da più sorgenti, i valori di queste informazioni dovrebbero essere coerenti. Tuttavia, se le informazioni ricevute da più sorgenti non sono coerenti, questo non è considerato un errore fatale. Un host accetta l'unione di tutte le informazioni ricevute tramite la scoperta di vicini e DHCPv6.

Se vengono apprese informazioni incoerenti da diverse sorgenti, le implementazioni possono voler privilegiare le informazioni apprese in modo sicuro rispetto a quelle apprese senza protezione. Ad esempio, la Sezione 8 di [RFC3971] discute di come gestire i conflitti tra le informazioni apprese tramite Secure Neighbor Discovery e quelle apprese tramite la scoperta di vicini ordinaria. La stessa discussione può applicarsi alla preferenza tra le informazioni apprese tramite la scoperta di vicini ordinaria e quelle apprese tramite DHCPv6 sicuro, ecc.

In ogni caso, in assenza di differenze di sicurezza, i valori ottenuti di recente dovrebbero (SHOULD) essere preferiti alle informazioni apprese in precedenza.

5.7. Retaining Configured Addresses for Stability (Conservazione degli indirizzi configurati per la stabilità)​

Le implementazioni con archiviazione stabile possono voler conservare gli indirizzi nell'archiviazione quando ottengono indirizzi tramite l'autoconfigurazione degli indirizzi senza stato. Supponendo che le durate di vita utilizzate siano ragionevoli, questa tecnica significa che un'interruzione temporanea dei router (di meno della durata di vita valida) non causerà mai la perdita dell'indirizzo globale di un nodo, anche se il nodo dovesse riavviarsi. Quando si utilizza questa tecnica, si dovrebbe anche notare che i tempi di scadenza delle durate di vita preferite e valide devono essere conservati per impedire l'uso dell'indirizzo dopo che l'indirizzo è diventato deprecato o non valido.

Maggiori dettagli su questa estensione sono al di fuori dell'ambito di questo documento.

Ultimo aggiornamento il