8. Comportamento delle Funzionalità Sostituibili

Normalmente, in una rete multihop 6LoWPAN, i messaggi RA vengono utilizzati per disseminare prefissi e informazioni di contesto a tutti i 6LR in una topologia route-over. Se tutti i router sono configurati per utilizzare un meccanismo sostitutivo per tale distribuzione di informazioni, qualsiasi uso rimanente dei meccanismi 6LoWPAN-ND è governato dalla specifica sostitutiva.

C'è anche l'opzione per un 6LR di eseguire il DAD multihop (per indirizzi IPv6 non derivati da un EUI-64) contro un 6LBR in una topologia route-over utilizzando i messaggi DAR e DAC. Questo è sostituibile perché potrebbero esserci altri modi per allocare un indirizzo unico, come DHCPv6 [RFC3315], o utilizzare altri meccanismi futuri per il DAD multihop. Ancora una volta, in questo caso, qualsiasi uso rimanente dei meccanismi 6LoWPAN-ND è governato dalla specifica sostitutiva.

Per essere chiari: Le implementazioni DEVONO supportare le funzionalità descritte nelle Sezioni 8.1 e 8.2, a meno che l'implementazione non supporti qualche alternativa ("sostituto") da qualche altra specifica.

8.1. Distribuzione Multihop di Prefissi e Contesti

La distribuzione multihop si basa su messaggi RS e messaggi RA inviati tra router, e sull'uso del numero di versione ABRO per controllare la propagazione delle informazioni (prefissi e informazioni di contesto) che vengono inviate negli RA.

Questo meccanismo di distribuzione multihop può gestire informazioni arbitrarie da un numero arbitrario di 6LBR. Tuttavia, la semantica delle informazioni di contesto richiede che tutti i 6LN utilizzino le stesse informazioni sia che inviino, inoltrino o ricevano pacchetti compressi. Quindi, il gestore dei 6LBR deve in qualche modo garantire che le informazioni di contesto siano sincronizzate tra i 6LBR. Questo può essere gestito in modi diversi. Un modo possibile per garantirlo è trattare le informazioni di contesto e prefisso come provenienti da qualche fonte logica o virtuale, il che in sostanza significa che sembra che le informazioni siano distribuite da una singola fonte.

Se un set di 6LBR si comporta come uno solo (utilizzando meccanismi fuori dall'ambito di questo documento) in modo che i prefissi e i contesti e il numero di versione ABRO siano gli stessi da tutti i 6LBR, allora quei 6LBR possono scegliere un singolo indirizzo IP da utilizzare nell'ABRO.

8.1.1. 6LBR che Inviano Router Advertisement

I 6LBR che supportano la distribuzione multihop di prefissi e contesti DEVONO includere un ABRO in ciascuno dei loro RA. Il campo Numero di Versione ABRO viene utilizzato per mantenere coerenti le informazioni di prefisso e contesto in tutta la LoWPAN, insieme alle linee guida nella Sezione 7.2. Ogni volta che una qualsiasi informazione nel set di PIO o 6CO cambia, la versione ABRO viene aumentata di uno.

Ciò richiede che il 6LBR mantenga il PIO, la 6CO e il Numero di Versione ABRO in uno storage stabile, poiché un vecchio numero di versione sarà ignorato silenziosamente dai 6LR.

8.1.2. Router che Inviano Router Solicitation

In una 6LoWPAN, a meno che non sia sostituita, la distribuzione multihop viene effettuata utilizzando messaggi RA. Quindi, all'inizializzazione dell'interfaccia, un router (6LR) DEVE inviare messaggi RS seguendo le regole specificate per gli host in [RFC4861]. Questo a sua volta farà sì che i router rispondano con messaggi RA che possono poi essere utilizzati per seminare inizialmente le informazioni di prefisso e contesto.

8.1.3. Router che Elaborano Router Advertisement

Se la distribuzione multihop non viene effettuata utilizzando messaggi RA, allora i router seguono [RFC4861], che afferma che essi fanno semplicemente alcuni controlli di coerenza; in questo caso, nulla nella Sezione 8.1 si applica. Altrimenti, i router controlleranno e registreranno le informazioni di prefisso e contesto dagli RA ricevuti, e utilizzeranno quelle informazioni come segue.

Se un RA ricevuto non contiene un ABRO, allora l'RA DEVE essere ignorato silenziosamente.

Il router utilizza il campo Indirizzo 6LBR nell'ABRO per controllare se ha precedentemente ricevuto informazioni dal 6LBR. Se non trova tali informazioni, allora registra semplicemente l'indirizzo 6LBR, la Versione, la Durata Valida e i prefissi e le informazioni di contesto associati. Se il 6LBR è precedentemente noto, allora il campo Numero di Versione DEVE essere confrontato con il numero di versione registrato per quel 6LBR. Se il numero di versione ricevuto nel pacchetto è inferiore al numero di versione memorizzato, allora le informazioni nell'RA sono ignorate silenziosamente. Altrimenti, le informazioni registrate e il numero di versione vengono aggiornati.

8.1.4. Memorizzazione delle Informazioni

Il router mantiene lo stato per ogni 6LBR che vede con un ABRO. Questo include il numero di versione, la Durata Valida e il set completo di PIO e 6CO. I prefissi scadono in base alla Durata Valida nel PIO. Il Prefisso di Contesto scade in base alla Durata Valida nella 6CO.

Mentre i prefissi e le informazioni di contesto sono memorizzati nel router, le loro durate valide e preferite vengono decrementate col passare del tempo. Questo garantisce che quando il router sta a sua volta annunciando successivamente quelle informazioni negli RA che invia, il 'tempo di scadenza' non si sposti accidentalmente più avanti nel futuro. Ad esempio, se una 6CO con una Durata Valida di 10 minuti viene ricevuta al tempo T, e il router include questo in un RA che invia al tempo T+5 minuti, la Durata Valida nella 6CO che invia sarà di soli 5 minuti.

8.1.5. Invio di Router Advertisement

Quando la distribuzione multihop viene eseguita utilizzando messaggi RA, i router DEVONO garantire che l'ABRO rimanga sempre insieme ai prefissi e alle informazioni di contesto ricevuti con quell'ABRO. Quindi, se il router ha ricevuto il prefisso P1 con un ABRO che dice che proviene da un 6LBR, e il prefisso P2 da un altro 6LBR, allora il router NON DEVE includere i due prefissi nello stesso messaggio RA. Il prefisso P1 DEVE essere in un RA che include un ABRO dal primo 6LBR, ecc. Notare che più 6LBR potrebbero annunciare le stesse informazioni di prefisso e contesto, ma devono comunque essere associati ai 6LBR che li hanno annunciati.

I router inviano periodicamente RA come in [RFC4861]. Questo è a beneficio degli altri router che ricevono i prefissi e le informazioni di contesto. I router rispondono anche agli RS inviando messaggi RA unicast. In entrambi i casi, si applica il vincolo di cui sopra di mantenere l'ABRO insieme ai 'suoi' prefissi e informazioni di contesto.

Quando un router riceve nuove informazioni da un 6LBR, cioè, o sente da un nuovo 6LBR (un nuovo indirizzo 6LBR nell'ABRO) o il numero di versione ABRO di un 6LBR esistente è aumentato, allora è utile inviare alcuni aggiornamenti attivati. La raccomandazione è di comportarsi come quando un'interfaccia è diventata un'interfaccia di annuncio come descritto in [RFC4861], cioè, inviare fino a tre messaggi RA. Questo garantisce una rapida propagazione delle nuove informazioni a tutti i 6LR.

8.2. Rilevamento Indirizzi Duplicati Multihop

L'ARO può essere utilizzato, oltre a registrare un indirizzo in un 6LR, per far verificare al 6LR che l'indirizzo non sia utilizzato da qualche altro host noto al 6LR. Tuttavia, ciò non è sufficiente in una topologia route-over (o in una LoWPAN con più 6LBR), poiché qualche host collegato a un altro 6LR potrebbe utilizzare lo stesso indirizzo. Potrebbero esserci modi diversi per i 6LR di coordinare tale rilevamento di indirizzi duplicati in futuro, o gli indirizzi potrebbero essere assegnati utilizzando un server DHCPv6 che verifica l'unicità come parte dell'assegnazione.

Questa specifica offre una tecnica semplice sostituibile per 6LR e 6LBR per eseguire il DAD che riutilizza le informazioni dall'ARO nei messaggi DAR e DAC. Questa tecnica non è necessaria quando l'ID di Interfaccia nell'indirizzo è basato su un EUI-64, poiché si presume che questi siano globalmente unici. La tecnica presume che o i 6LR si registrino con tutti i 6LBR o la rete utilizzi qualche meccanismo fuori ambito per mantenere sincronizzate le tabelle DAD nei 6LBR.

Il meccanismo DAD multihop viene utilizzato in modo sincrono la prima volta che un indirizzo viene registrato con un particolare 6LR. Cioè, l'ARO non viene restituito all'host finché il DAD multihop non è stato completato contro i 6LBR. Per le registrazioni esistenti nel 6LR, il DAD multihop deve essere ripetuto contro i 6LBR per garantire che la voce per l'indirizzo nei 6LBR non scada, ma ciò può essere fatto in modo asincrono con la risposta agli host. Un metodo per ottenere ciò è tracciare quanto rimane della durata che il 6LR ha registrato con i 6LBR e ri-registrarsi con il 6LBR quando questa durata sta per scadere.

Per il DAD multihop sincrono, il 6LR esegue alcuni controlli aggiuntivi per garantire di avere un NCE che può utilizzare per rispondere all'host quando riceve una risposta da un 6LBR. Ciò consiste nel verificare l'esistenza di un NCE già esistente (Tentative o Registered) per l'Indirizzo Registrato con un EUI-64 diverso. Se esiste un tale NCE Registered, allora il 6LR DOVREBBE rispondere che l'indirizzo è un duplicato. Se esiste un tale NCE Tentative, allora il 6LR DOVREBBE ignorare silenziosamente l'ARO, affidandosi così alla ritrasmissione dell'ARO da parte dell'host. Questo è necessario per gestire il caso in cui più host cercano di registrare lo stesso indirizzo IPv6 contemporaneamente. Se non esiste alcun NCE, allora il 6LR DEVE creare un NCE Tentative con l'EUI-64 e lo SLLAO. Questa voce sarà utilizzata per inviare la risposta all'host quando il 6LBR risponde positivamente.

Quando un 6LR riceve un NS contenente un ARO con una Durata di Registrazione diversa da zero e non ha alcun NCE Registered esistente, allora con questo meccanismo il 6LR invocherà il DAD multihop sincrono.

Il 6LR invierà in unicast un messaggio DAR a uno o più 6LBR, dove il DAR contiene l'indirizzo dell'host nel campo Indirizzo Registrato. Il DAR sarà inoltrato dai 6LR fino a raggiungere il 6LBR; quindi, il suo campo Hop Limit IPv6 non sarà 255 quando ricevuto dal 6LBR. Il 6LBR risponderà con un messaggio DAC, che avrà un hop limit inferiore a 255 quando raggiungerà il 6LR.

Quando il 6LR riceve il DAC dal 6LBR, cercherà un NCE (Tentative o Registered) corrispondente (stesso indirizzo IP ed EUI-64). Se non viene trovata alcuna voce, allora il DAC viene ignorato silenziosamente. Se viene trovata una voce e il DAC aveva Status=0, allora il 6LR contrassegnerà l'NCE Tentative come Registered. In tutti i casi, quando viene trovata una voce, allora il 6LR risponderà all'host con un NA, copiando i campi Status ed EUI-64 dal DAC a un ARO nell'NA. Nel caso in cui lo stato sia un errore, allora l'indirizzo IP di destinazione dell'NA è derivato dal campo EUI-64 del DAC.

Un NCE Tentative DOVREBBE scadere TENTATIVE_NCE_LIFETIME secondi dopo che è stato creato per consentire a un altro host di tentare di registrare l'indirizzo IPv6.

8.2.1. Convalida del Messaggio per DAR e DAC

Un nodo DEVE scartare silenziosamente qualsiasi messaggio DAR e DAC ricevuto per il quale almeno uno dei seguenti controlli di validità non è soddisfatto:

• Se il messaggio include un'intestazione di autenticazione IP, il messaggio si autentica correttamente.
• Il Checksum ICMP è valido.
• Il Codice ICMP è 0.
• La Lunghezza ICMP (derivata dalla lunghezza IP) è 32 o più byte.
• L'Indirizzo Registrato non è un indirizzo multicast.
• Tutte le opzioni incluse hanno una lunghezza maggiore di zero.
• L'indirizzo sorgente IP non è l'indirizzo non specificato, né è un indirizzo multicast.

Il contenuto del campo Riservato e di qualsiasi opzione non riconosciuta DEVE essere ignorato. Futuri cambiamenti retrocompatibili al protocollo possono specificare il contenuto del campo Riservato o aggiungere nuove opzioni; cambiamenti non retrocompatibili possono utilizzare valori di Codice diversi.

Notare che a causa dell'inoltro dei messaggi DAR e DAC tra il 6LR e il 6LBR, non c'è controllo hop-limit alla ricezione per questi tipi di messaggi ICMPv6.

8.2.2. Strutture Dati Concettuali

Un 6LBR che implementa il DAD multihop deve mantenere un certo stato separato dalla Cache dei Vicini. Chiamiamo questa struttura dati concettuale tabella DAD. È indicizzata dall'indirizzo IPv6 -- l'Indirizzo Registrato nel DAR -- e contiene l'EUI-64 e la Durata di Registrazione dell'host che sta utilizzando quell'indirizzo.

8.2.3. 6LR che Invia una Richiesta di Indirizzo Duplicato

Quando un 6LR che implementa il DAD multihop riceve un NS da un host, e soggetto ai controlli di cui sopra, il 6LR forma e invia un DAR ad almeno un 6LBR. Il DAR contiene le seguenti informazioni:

• Nell'indirizzo sorgente IPv6, un indirizzo globale del 6LR.
• Nell'indirizzo di destinazione IPv6, l'indirizzo del 6LBR.
• Nell'hop limit IPv6, MULTIHOP_HOPLIMIT.
• Il campo Status DEVE essere impostato a zero.
• L'EUI-64 e la Durata di Registrazione sono copiati dall'ARO ricevuto dall'host.
• L'Indirizzo Registrato impostato all'indirizzo IPv6 dell'host, cioè, il mittente dell'NS scatenante.

Quando un 6LR riceve un NS da un host con una Durata di Registrazione pari a zero, allora, oltre a rimuovere l'NCE per l'host come specificato nella Sezione 6, un DAR viene inviato ai 6LBR come sopra.

Un router NON DEVE modificare la Cache dei Vicini come risultato della ricezione di un DAR.

8.2.4. 6LBR che Riceve una Richiesta di Indirizzo Duplicato

Quando un 6LBR che implementa il DAD multihop sostituibile riceve un DAR da un 6LR, esegue la convalida del messaggio specificata nella Sezione 8.2.1. Se il DAR è valido, il 6LBR procede a cercare l'Indirizzo di Registrazione nella tabella DAD. Se viene trovata una voce e l'EUI-64 registrato è diverso dall'EUI-64 nel DAR, allora restituisce un NA DAC con lo Status impostato a 1 ('Indirizzo Duplicato'). Altrimenti, restituisce un DAC con Status impostato a zero e aggiorna la durata.

Se non viene trovata alcuna voce nella tabella DAD e la Durata di Registrazione è diversa da zero, allora viene creata una voce e l'EUI-64 e l'Indirizzo Registrato dal DAR sono memorizzati in quella voce.

Se viene trovata una voce nella tabella DAD, l'EUI-64 corrisponde e la Durata di Registrazione è zero, allora la voce viene eliminata dalla tabella.

In entrambi i casi di cui sopra, il 6LBR forma un DAC con le informazioni copiate dal DAR e il campo Status è impostato a zero. Il DAC viene inviato indietro al 6LR, cioè, indietro alla sorgente del DAR. L'hop limit IPv6 è impostato a MULTIHOP_HOPLIMIT.

8.2.5. Elaborazione di una Conferma di Indirizzo Duplicato

Quando un 6LR che implementa il DAD multihop riceve un messaggio DAC, allora prima convalida il messaggio secondo la Sezione 8.2.1. Per un DAC valido, se non c'è alcun NCE Tentative corrispondente all'Indirizzo Registrato e all'EUI-64, allora il DAC viene ignorato silenziosamente. Altrimenti, le informazioni nel DAC e nell'NCE Tentative vengono utilizzate per formare un NA da inviare all'host. Il codice Status è copiato dal DAC all'ARO che viene inviato all'host. Nel caso in cui il DAC indichi un errore (lo Status è diverso da zero), l'NA viene restituito all'host come descritto nella Sezione 6.5.2, e l'NCE Tentative per l'Indirizzo Registrato viene rimosso. Altrimenti, viene trasformato in un NCE Registered.

Un router NON DEVE modificare la Cache dei Vicini come risultato della ricezione di un DAC, a meno che non ci sia un NCE Tentative corrispondente all'indirizzo IPv6 e all'EUI-64.

8.2.6. Recupero dai Guasti

Se non c'è risposta da un 6LBR dopo RETRANS_TIMER [RFC4861], allora il 6LR ritrasmetterebbe il DAR al 6LBR fino a MAX_UNICAST_SOLICIT [RFC4861] volte. Dopo di ciò, il 6LR DOVREBBE rispondere all'host con uno Status ARO di zero.