3. Panoramica del protocollo (Protocol Overview)

Queste ottimizzazioni di Neighbor Discovery sono applicabili sia alle configurazioni mesh-under sia a quelle route-over. In una configurazione mesh-under esistono solo 6LoWPAN Border Routers e host; non vi sono router 6LoWPAN nelle topologie mesh-under.

La parte più importante delle ottimizzazioni è l’evoluta interazione host-to-router che consente nodi in sleep e evita l’uso di messaggi Neighbor Discovery in multicast, eccetto nel caso in cui un host trovi un insieme iniziale di router predefiniti e nel caso in cui ripeta tale determinazione quando tale insieme di router è diventato irraggiungibile.

Il protocollo fornisce inoltre la compressione dell’intestazione [RFC6282] trasportando informazioni di compressione dell’intestazione in una nuova opzione nei messaggi Router Advertisement.

Inoltre, vi sono meccanismi separati che possono essere usati tra 6LR e 6LBR per eseguire la Duplicate Address Detection multi-hop e la distribuzione delle informazioni di prefisso e di contesto di compressione dai 6LBR a tutti i 6LR, che a loro volta usano meccanismi Neighbor Discovery normali per veicolare tali informazioni agli host.

Il protocollo è progettato in modo tale che l’interazione host-to-router non sia influenzata dalla configurazione del 6LoWPAN; l’interazione host-to-router è la stessa in una configurazione mesh-under e in una configurazione route-over.

3.1. Estensioni a RFC 4861 (Extensions to RFC 4861)

Questo documento specifica le seguenti ottimizzazioni ed estensioni a IPv6 Neighbor Discovery [RFC4861]:

Aggiornamento delle informazioni di Router Advertisement iniziato dall’host. Ciò elimina la necessità di Router Advertisements periodici o non sollecitati dai router verso gli host.
Non viene eseguita la Duplicate Address Detection (DAD) se vengono usati indirizzi IPv6 basati su EUI-64 (poiché tali indirizzi sono assunti globalmente unici).
La DAD è opzionale se DHCPv6 è usato per assegnare indirizzi.
Un nuovo meccanismo di registrazione dell’indirizzo che usa una nuova Address Registration Option tra host e router. Ciò elimina la necessità per i router di usare Neighbor Solicitations in multicast per trovare gli host e supporta host in sleep. Ciò consente inoltre di usare lo/gli stesso/i prefisso/i di indirizzi IPv6 in un 6LoWPAN route-over. Fornisce l’interfaccia host-to-router per la Duplicate Address Detection.
Una nuova opzione di Router Advertisement, la 6LoWPAN Context Option, per le informazioni di contesto usate da 6LoWPAN header compression.
Un nuovo meccanismo per eseguire la Duplicate Address Detection su un 6LoWPAN route-over usando i nuovi messaggi Duplicate Address Request e Duplicate Address Confirmation.
Nuovi meccanismi per distribuire prefissi e informazioni di contesto su una rete route-over che usa una nuova Authoritative Border Router Option per controllare il flooding delle modifiche di configurazione.
Vengono introdotte alcune nuove costanti di protocollo predefinite e alcune costanti di protocollo Neighbor Discovery esistenti vengono ottimizzate.

3.2. Assegnazione degli indirizzi (Address Assignment)

Gli host in un 6LoWPAN configurano i propri indirizzi IPv6 come specificato in [RFC4861] e [RFC4862] sulla base delle informazioni ricevute nei messaggi Router Advertisement. L’uso del flag M (managed address configuration) in questa ottimizzazione è tuttavia più restrittivo rispetto a [RFC4861]. Quando il flag M è impostato, si assume che un host usi DHCPv6 per assegnare qualsiasi indirizzo non EUI-64. Quando il flag M non è impostato, i nodi nel LoWPAN supportano la Duplicate Address Detection; pertanto un host può usare in modo sicuro il meccanismo di registrazione dell’indirizzo per verificare l’unicità degli indirizzi non EUI-64.

I 6LR MAY usare gli stessi meccanismi per configurare i propri indirizzi IPv6.

I 6LBR sono responsabili della gestione del/dei prefisso/i assegnato/i al 6LoWPAN, usando configurazione manuale, DHCPv6 Prefix Delegation [RFC3633] o altri meccanismi. In un LoWPAN isolato, un prefisso Unique Local Address (ULA) [RFC4193] SHOULD essere generato dal 6LBR.

3.3. Interazione host-router (Host-to-Router Interaction)

Un host invia messaggi Router Solicitation all’avvio e anche quando la Neighbor Unreachability Detection (NUD) di uno dei suoi router predefiniti fallisce.

Gli host ricevono messaggi Router Advertisement che tipicamente contengono l’Authoritative Border Router Option (ABRO) e possono opzionalmente contenere una o più 6LoWPAN Context Options (6COs) in aggiunta alle Prefix Information Options (PIOs) esistenti come descritto in [RFC4861].

Quando un host ha configurato un indirizzo IPv6 non link-local, registra tale indirizzo con uno o più dei suoi router predefiniti usando l’Address Registration Option (ARO) in un messaggio NS. L’host sceglie una lifetime della registrazione e ripete periodicamente l’ARO (prima che la lifetime scada) per mantenere la registrazione. La lifetime dovrebbe essere scelta in modo da mantenere la registrazione anche mentre un host è in sleep. Analogamente, i nodi mobili che cambiano spesso il proprio punto di attacco dovrebbero usare una lifetime opportunamente breve. Vedere la Sezione 5.5 per i dettagli di registrazione e la Sezione 9 per le costanti di protocollo.

La registrazione fallisce quando un ARO viene restituito all’host con uno Status non nullo. Una ragione può essere che il router determina che l’indirizzo IPv6 è già usato da un altro host, ossia da un host con un EUI-64 diverso. Ciò può essere usato per supportare indirizzi non basati su EUI-64, come indirizzi IPv6 temporanei [RFC4941] o indirizzi basati su un Interface ID che è un indirizzo corto IEEE 802.15.4 a 16 bit. Il fallimento può verificarsi anche se la Neighbor Cache su quel router è piena.

La ri-registrazione di un indirizzo può essere combinata con la Neighbor Unreachability Detection (NUD) del router, poiché entrambi usano messaggi Neighbor Solicitation in unicast. Ciò rende efficiente quando un host si sveglia per inviare un pacchetto e deve sia eseguire la NUD per verificare che il router sia ancora raggiungibile sia aggiornare la propria registrazione con il router.

La risposta a una registrazione dell’indirizzo potrebbe non essere immediata, poiché nelle configurazioni route-over il 6LR potrebbe eseguire la Duplicate Address Detection verso il 6LBR. Un host ritrasmette l’Address Registration Option finché non viene riconosciuta tramite la ricezione di un’Address Registration Option.

Come parte delle ottimizzazioni, la risoluzione dell’indirizzo non viene eseguita multicasting messaggi Neighbor Solicitation come in [RFC4861]. Invece, i router mantengono Neighbor Cache Entries per tutti gli indirizzi IPv6 registrati. Se l’indirizzo non è nella Neighbor Cache del router, allora l’indirizzo o non esiste, o è assegnato a un host collegato a un altro router nel 6LoWPAN, oppure è esterno al 6LoWPAN. In una configurazione route-over, il protocollo di routing viene usato per instradare tali pacchetti verso la destinazione.

3.4. Interazione router-router (Router-to-Router Interaction)

La nuova interazione router-to-router è solo per la configurazione route-over in cui sono presenti 6LR. Vedere anche la Sezione 1.4.

I 6LR MUST comportarsi come un host durante l’avvio del sistema e la configurazione dei prefissi inviando messaggi Router Solicitation e autoconfigurando i propri indirizzi IPv6, a differenza dei router in [RFC4861].

Quando vengono usate la disseminazione multi-hop di prefissi e contesto, i 6LR memorizzano l’ABRO, le 6CO e le informazioni di prefisso ricevute (direttamente o indirettamente) dai 6LBR e ridistribuiscono tali informazioni nel Router Advertisement che inviano ad altri 6LR o che inviano agli host in risposta a un Router Solicitation. Nell’ABRO c’è un campo Version Number (vedere la Sezione 4.3), che è usato per limitare il flooding delle informazioni aggiornate tra i 6LR.

Un 6LR può eseguire la Duplicate Address Detection verso uno o più 6LBR usando i nuovi messaggi Duplicate Address Request (DAR) e Duplicate Address Confirmation (DAC), che trasportano le informazioni dall’Address Registration Option. I messaggi DAR e DAC saranno inoltrati tra il 6LR e i 6LBR; pertanto la regola [RFC4861] di verifica hop limit=255 non si applica ai messaggi DAR e DAC. Tali messaggi DAD multi-hop MUST NOT modificare alcuna Neighbor Cache Entry sui router, poiché non abbiamo i benefici di sicurezza forniti dalla verifica hop limit=255.

3.5. Gestione della Neighbor Cache (Neighbor Cache Management)

L’uso di registrazioni esplicite con lifetime, insieme al desiderio di non multicastare messaggi Neighbor Solicitation per gli host, implica che si gestiscano le Neighbor Cache Entries (NCEs) in modo leggermente diverso rispetto a [RFC4861]. Ciò produce tre diversi tipi di NCE e i tipi specificano come tali voci possono essere rimosse:

Garbage-collectible (garbage-collectible): Voci soggette alle regole normali in [RFC4861] che consentono la garbage collection quando la memoria è scarsa.
Registered (registered): Voci che hanno una lifetime di registrazione esplicita e vengono mantenute finché tale lifetime scade o finché non vengono esplicitamente deregistrate.
Tentative (tentative): Voci temporanee con una breve lifetime, che tipicamente vengono convertite in voci Registered.

Si noti che il tipo della NCE è ortogonale agli stati specificati in [RFC4861].

Quando un host interagisce con un router inviando Router Solicitations, ciò produce una NCE Tentative. Una volta che un router ha fatto registrare con successo un nodo presso di sé, il risultato è una NCE Registered. Quando i router inviano RA agli host e quando i router ricevono messaggi RA o ricevono messaggi NS in multicast da altri router, il risultato è NCE Garbage-collectible. Può esserci un solo tipo di NCE alla volta per un indirizzo IP.

Le Neighbor Cache Entries sui router possono inoltre essere aggiunte o cancellate da un protocollo di routing usato nel 6LoWPAN. Ciò è utile se il protocollo di routing trasporta gli indirizzi di livello link dei router vicini. A seconda dei dettagli di tali protocolli di routing, tali NCE potrebbero essere Registered o Garbage-collectible.