6. Comportamento del router per 6LR e 6LBR (Router Behavior for 6LRs and 6LBRs)

Sia i 6LR sia i 6LBR mantengono la Neighbor Cache [RFC4861] in base agli ARO che ricevono nei messaggi NA dagli host, ai pacchetti ND da altri nodi e, potenzialmente, a un protocollo di routing usato nel 6LoWPAN come descritto nella Sezione 3.5.

I router SHOULD NOT fare garbage-collect delle Registered NCE (vedi Sezione 3.4), poiché devono conservarle fino alla scadenza della Registration Lifetime. Analogamente, se la NUD sul router determina che l’host è UNREACHABLE (in base alla logica in [RFC4861]), la NCE SHOULD NOT essere eliminata ma piuttosto mantenuta fino alla scadenza della Registration Lifetime. Un ARO rinnovato dovrebbe marcare l’entry di cache come STALE. Pertanto, per i router 6LoWPAN, la Neighbor Cache non si comporta come una cache. Invece, si comporta come un registro di tutti gli indirizzi host collegati al router.

I router MAY implementare l’estensione Default Router Preference (Prf) [RFC4191] e usarla per indicare all’host se il router è un 6LBR o un 6LR. Se ciò è implementato, allora i 6LR senza una rotta verso un border router MUST impostare Prf a (11) per bassa preferenza, gli altri 6LR MUST impostare Prf a (00) per preferenza normale, e i 6LBR MUST impostare Prf a (01) per alta preferenza.

6.1. Azioni vietate (Forbidden Actions)

Anche se un router in una topologia route-over può raggiungere sia un host sia un altro target, a causa della propagazione radio generalmente non può sapere se l’host può raggiungere direttamente l’altro target. Pertanto, non può assumere che Redirect funzioni davvero da un host a un altro. Pertanto, SHOULD NOT inviare messaggi Redirect. L’unica potenziale eccezione a questo "SHOULD NOT" è quando il deployment/implementazione ha un modo per sapere come l’host può raggiungere il target previsto. Quindi è RECOMMENDED che l’implementazione di default non invii messaggi Redirect ma possa essere configurabile quando il deployment lo richiede. Al contrario, per le topologie mesh-under, le stesse considerazioni sui Redirect si applicano come in [RFC4861].

Un router MUST NOT impostare il flag L (on-link) nei PIO, poiché ciò potrebbe indurre gli host a inviare NS multicast.

6.2. Inizializzazione dell’interfaccia (Interface Initialization)

Il comportamento di inizializzazione dell’interfaccia router di un 6LBR è lo stesso di [RFC4861]. Tuttavia, in uno scenario di configurazione dinamica (vedi Sezione 8.1), un 6LR si avvia come non-router e attende di ricevere l’advertisement per configurare prima il proprio indirizzo di interfaccia, prima di impostare le proprie interfacce come advertising interfaces e diventare un router.

6.3. Elaborazione di una Router Solicitation (Processing a Router Solicitation)

Un router elabora i messaggi RS come specificato in [RFC4861]. Le differenze riguardano l’inclusione di ABRO nei messaggi RA e l’uso esclusivo di RA in unicast. Se un 6LR ha ricevuto un ABRO da un 6LBR, allora includerà quell’opzione senza modificarla nei messaggi RA che invia. E, se il 6LR ha ricevuto RA — sia con le stesse informazioni di prefisso e contesto sia con informazioni diverse — da un 6LBR differente, allora dovrà mantenere separatamente tali prefissi e informazioni di contesto in modo che i RA che il 6LR invia mantengano l’associazione tra l’ABRO e le informazioni di prefisso e contesto. Il router può determinare quale 6LBR ha originato i prefissi e le informazioni di contesto dal campo 6LBR Address nell’ABRO. Quando un router ha informazioni legate a più ABRO, un singolo RS produrrà più RA, ciascuno contenente un ABRO differente.

Quando la ABRO Valid Lifetime associata a un 6LBR va in timeout, tutte le informazioni relative a quel 6LBR MUST essere rimosse. Come nota di implementazione, si raccomanda che i RA vengano inviati con una frequenza sufficientemente maggiore della ABRO Valid Lifetime, in modo che la perdita di un RA non comporti la rimozione di tutte le informazioni relative a un 6LBR.

Un RS potrebbe essere ricevuto da un host che non ha ancora registrato il proprio indirizzo presso il router. Pertanto, il router MUST NOT modificare una NCE esistente in base al SLLAO del RS. Tuttavia, un router MAY creare una Tentative NCE in base al SLLAO. Una tale Tentative NCE SHOULD scadere in TENTATIVE_NCE_LIFETIME secondi, a meno che una registrazione non la converta in una Registered NCE.

Un 6LR o 6LBR MUST includere un SLLAO nei RA che invia; ciò è richiesto affinché gli host conoscano l’indirizzo link-layer del router. Diversamente da [RFC4861], il valore massimo del campo Router Lifetime del RA MAY essere fino a 0xFFFF (circa 18 ore).

Diversamente da [RFC4861], che suggerisce RA multicast, questa specifica migliora lo scambio inviando sempre RA in unicast in risposta ai RS. Ciò è possibile, poiché il RS include sempre un SLLAO, che è usato dal router per unicasta-re il RA.

6.4. Router Advertisements periodici (Periodic Router Advertisements)

Un router non ha bisogno di inviare alcun messaggio RA periodico, poiché gli host solleciteranno informazioni aggiornate inviando RS prima che le lifetime scadano.

Tuttavia, se i router usano i RA per distribuire informazioni di prefisso e/o di contesto attraverso una topologia route-over, ciò potrebbe richiedere messaggi RA periodici. Tali RA sono inviati usando i parametri configurabili MinRtrAdvInterval e MaxRtrAdvInterval come per [RFC4861].

6.5. Elaborazione di una Neighbor Solicitation (Processing a Neighbor Solicitation)

Un router gestisce i messaggi NS come specificato in [RFC4861], con una logica aggiuntiva descritta in questa sezione per gestire l’ARO.

In aggiunta alla normale validazione di un NS e delle sue opzioni, l’ARO (se presente) è verificato come segue. Se il campo Length non è due, o se il campo Status non è zero, allora il NS è ignorato silenziosamente.

Se l’indirizzo sorgente del NS è l’indirizzo unspecified, o se non è incluso alcun SLLAO, allora qualunque ARO incluso è ignorato, cioè il NS è elaborato come se non contenesse un ARO.

6.5.1. Verifica dei duplicati (Checking for Duplicates)

Se il NS contiene un ARO valido, allora il router ispeziona la propria Neighbor Cache sull’interfaccia di arrivo per vedere se è un duplicato. Non è un duplicato se (1) non esiste alcuna NCE per l’indirizzo IPv6 sorgente del NS o (2) esiste una tale NCE e l’EUI-64 è lo stesso. Altrimenti, è un indirizzo duplicato. Si noti che se la multihop DAD (Sezione 8.2) è usata, allora i controlli sono leggermente diversi per tenere conto delle Tentative NCE. Nel caso sia un indirizzo duplicato, il router risponde con un messaggio NA in unicast con il campo ARO Status impostato a uno (per indicare che l’indirizzo è un duplicato) come descritto nella Sezione 6.5.2. In questo caso, non c’è alcuna modifica alla Neighbor Cache.

6.5.2. Ritorno degli errori di registrazione dell’indirizzo (Returning Address Registration Errors)

Gli errori di registrazione dell’indirizzo non vengono rimandati all’indirizzo sorgente del NS a causa di un possibile rischio di collisione dell’indirizzo L2. Invece, il NA è inviato all’indirizzo IPv6 link-local con la parte Interface ID derivata dal campo EUI-64 dell’ARO come per [RFC4944]. In particolare, ciò significa che il bit universal/local deve essere invertito. Il NA è formattato con una copia dell’ARO dal NS, ma con il campo Status impostato per indicare l’errore appropriato.

L’errore è inviato all’indirizzo link-local con l’Interface ID derivato dall’EUI-64. Quindi, se l’ARO era da e per un short address, la destinazione L2 per il NA con l’errore ARO sarà l’indirizzo unico a 64 bit.

6.5.3. Aggiornamento della Neighbor Cache (Updating the Neighbor Cache)

Se l’ARO non ha portato al rilevamento di un indirizzo duplicato come sopra, allora, se la Registration Lifetime è non-zero, il router crea (se non esisteva) o aggiorna (altrimenti) una NCE per l’indirizzo IPv6 sorgente del NS. Se la Neighbor Cache è piena e deve essere creata una nuova entry, allora il router risponde con un NA in unicast con il campo ARO Status impostato a due (per indicare che la Neighbor Cache del router è piena) come descritto nella Sezione 6.5.2.

La Registration Lifetime e l’EUI-64 sono registrati nella NCE. Un NA in unicast viene quindi inviato in risposta al NS. Questo NA SHOULD includere una copia dell’ARO, con il campo Status impostato a zero. Un TLLAO (Target Link-Layer Address Option) [RFC4861] non è richiesto nel NA, poiché l’host conosce già l’indirizzo link-layer del router dai RA.

Se l’ARO contiene una Registration Lifetime pari a zero, allora qualunque NCE esistente per l’indirizzo IPv6 sorgente del NS MUST essere eliminata e un NA inviato come sopra.

Se la Registration Lifetime in una NCE scade, allora il router MUST eliminare l’entry di cache.

L’aggiunta e la rimozione di Registered NCE risulterebbero nella notifica al protocollo di routing.

Nota: Se la multihop DAD sostituibile (Sezione 8.2) è usata, allora l’aggiornamento della Neighbor Cache è leggermente diverso a causa delle Tentative NCE.

6.5.4. Determinazione del prossimo hop (Next-Hop Determination)

Per consegnare un pacchetto destinato a un 6LN registrato presso un router, la determinazione del prossimo hop è leggermente diversa per i router rispetto agli host (vedi Sezione 5.6). La tabella di routing è consultata per determinare l’indirizzo IP del prossimo hop. Una Registered NCE determina se l’indirizzo IP del prossimo hop è on-link. È responsabilità del protocollo di routing del router mantenere informazioni on-link sui propri neighbor registrati. Le Tentative NCE MUST NOT essere usate per determinare lo status on-link dei nodi registrati.

6.5.5. Risoluzione degli indirizzi tra router (Address Resolution between Routers)

Deve esserci un meccanismo da qualche parte affinché i router scoprano gli indirizzi link-layer l’uno dell’altro. Se il protocollo di routing usato tra i router fornisce questo, allora non c’è bisogno che i router usino l’ARO tra loro. Altrimenti, i router SHOULD usare l’ARO. Quando i router usano l’ARO per registrarsi tra loro e la multihop DAD (Sezione 8.2) è in uso, bisogna fare attenzione a garantire che non ci sia un flood di messaggi che trasportano ARO inviati al 6LBR man mano che ciascun router sente un ARO dai propri router vicini. I dettagli per questo scenario sono fuori dallo scope di questo documento.

I router MAY anche usare NS multicast come in [RFC4861] per risolvere gli indirizzi link-layer l’uno dell’altro. Quindi, i router MAY multicasta-re NS per altri router, per esempio, come risultato della ricezione di un aggiornamento del protocollo di routing. I router MUST rispondere ai NS multicast. Ciò implica che i router MUST unirsi agli indirizzi multicast solicited-node come specificato in [RFC4861].