5. Comportamento dell'host (Host Behavior)

5. Comportamento dell’host (Host Behavior)

Gli host in un LoWPAN usano l’ARO nei messaggi NS che inviano come modo per mantenere la Neighbor Cache nei router, rimuovendo così la necessità di NS multicast per effettuare la risoluzione degli indirizzi. A differenza di [RFC4861], gli host avviano l’aggiornamento delle informazioni che ricevono nei RA inviando RS prima che le informazioni scadano. Infine, quando la NUD indica che uno o tutti i router di default sono diventati irraggiungibili, l’host usa RS per trovare un nuovo insieme di router di default.

5.1. Azioni vietate (Forbidden Actions)

Un host MUST NOT inviare un messaggio NS in multicast.

5.2. Inizializzazione dell’interfaccia (Interface Initialization)

Quando l’interfaccia su un host è inizializzata, essa segue la specifica in [RFC4861]. Un indirizzo link-local viene formato sulla base dell’identificatore EUI-64 [EUI64] assegnato all’interfaccia come per [RFC4944] o per l’appropriato documento IP-over-foo per il collegamento, e poi l’host invia messaggi RS come descritto in [RFC4861], Sezione 6.3.7.

Non c’è bisogno di unirsi all’indirizzo multicast solicited-node, poiché nessuno multicasta NS in questo tipo di rete. Un host MUST unirsi all’indirizzo multicast all-nodes.

5.3. Invio di un Router Solicitation (Sending a Router Solicitation)

Il RS è formattato come specificato in [RFC4861] e inviato all’indirizzo multicast IPv6 all-routers (vedere [RFC4861], Sezione 6.3.7 per i dettagli). Un SLLAO MUST essere incluso per abilitare RA unicast in risposta. Un indirizzo sorgente unspecified MUST NOT essere usato nei messaggi RS.

Se il livello link supporta un modo per inviare pacchetti a una sorta di indirizzo anycast di livello link all-routers, allora ciò MAY essere usato per trasportare questi pacchetti a un router.

Poiché gli host non dipendono dai RA multicast per scoprire i router, gli host devono ritrasmettere intelligentemente RS ogni volta che l’elenco dei router di default è vuoto, uno dei router di default diventa irraggiungibile, o la durata di vita dei prefissi e dei contesti nel precedente RA sta per scadere. Il tasso di ritrasmissioni RECOMMENDED è di inviare inizialmente fino a 3 (MAX_RTR_SOLICITATIONS) messaggi RS separati da almeno 10 secondi (RTR_SOLICITATION_INTERVAL) come specificato in [RFC4861], e poi passare a ritrasmissioni più lente. Dopo le ritrasmissioni iniziali, l’host SHOULD eseguire un backoff esponenziale binario troncato (truncated binary exponential backoff) [ETHERNET] del timer di ritrasmissione per ogni ritrasmissione successiva, troncando l’aumento del timer di ritrasmissione a 60 secondi (MAX_RTR_SOLICITATION_INTERVAL). In tutti i casi, le ritrasmissioni di RS sono terminate quando un RA è ricevuto. Vedere la Sezione 9 per le costanti di protocollo.

5.4. Elaborazione di un Router Advertisement (Processing a Router Advertisement)

L’elaborazione dei RA è come in [RFC4861], con l’aggiunta della gestione della 6CO e del trigger della registrazione dell’indirizzo quando un nuovo indirizzo è stato configurato. Inoltre, l’SLLAO MUST essere incluso nel RA. A differenza di [RFC4861], il valore massimo del campo Router Lifetime del RA MAY essere fino a 0xFFFF (circa 18 ore).

Se l’host dovesse ricevere erroneamente un PIO con il flag L (on-link) impostato, allora quel PIO MUST essere ignorato.

5.4.1. Address Configuration (Configurazione dell’indirizzo)

La configurazione dell’indirizzo segue [RFC4862]. Per un indirizzo non derivato da un EUI-64, il flag M del RA determina come l’indirizzo può essere configurato. Se il flag M è impostato nel RA, allora DHCPv6 MUST essere usato per assegnare l’indirizzo. Se il flag M non è impostato, allora l’indirizzo può essere configurato con qualsiasi altro mezzo (e la duplicate detection viene eseguita come parte del processo di registrazione).

Una volta che un indirizzo è stato configurato, esso sarà registrato inviando in unicast un NS con una ARO a uno o più router.

5.4.2. Storing Contexts (Memorizzazione dei contesti)

L’host mantiene una struttura dati concettuale per le informazioni di contesto che riceve dai router. Questa struttura è chiamata context table. Include il CID, il prefisso (dal campo Context Prefix nella 6CO), il bit Compression e il Valid Lifetime. Un’entry della context table che ha il bit Compression a zero è usata per la decompressione quando si ricevono pacchetti ma MUST NOT essere usata per la compressione quando si inviano pacchetti.

Quando una 6CO è ricevuta in un RA, è usata per aggiungere o aggiornare le informazioni nella context table. Se il campo CID nella 6CO corrisponde a un’entry esistente della context table, allora quell’entry viene aggiornata con le informazioni della 6CO. Se il campo Valid Lifetime nella 6CO è zero, allora l’entry viene eliminata immediatamente.

Se non c’è un’entry corrispondente nella context table e il campo Valid Lifetime è non nullo, allora un nuovo contesto viene aggiunto alla context table. La 6CO è usata per aggiornare l’entry creata.

Quando il 6LBR cambia le informazioni di contesto, un host potrebbe non accorgersene immediatamente. E nel caso peggiore, un host potrebbe avere informazioni di contesto obsolete. Per questa ragione, i 6LBR usano le raccomandazioni nella Sezione 7.2 per gestire con attenzione il ciclo di vita del contesto. I nodi dovrebbero fare attenzione nell’uso della compressione d’intestazione nei messaggi RA che includono 6CO.

5.4.3. Maintaining Prefix and Context Information (Mantenimento delle informazioni di prefisso e contesto)

Le informazioni di prefisso scadono come specificato in [RFC4861]. Quando il Valid Lifetime per un’entry della context table scade, l’entry viene posta in modalità solo ricezione (receive-only), che è l’equivalente di ricevere una 6CO per quel contesto con C=0. L’entry è mantenuta in modalità solo ricezione per un periodo pari al doppio del Router Lifetime di default, dopo di che l’entry viene rimossa.

Un host dovrebbe ispezionare le varie durate di vita per determinare quando dovrebbe avviare l’invio di un RS per chiedere eventuali aggiornamenti delle informazioni. Le durate di vita che contano sono il Router Lifetime di default, il Valid Lifetime nei PIO e il Valid Lifetime nella 6CO. L’host SHOULD inviare in unicast uno o più RS al router ben prima che scada la più breve di tali durate di vita (tra tutti i prefissi e tutti i contesti) e poi passare a messaggi RS multicast se non c’è risposta agli unicast. Il comportamento di ritrasmissione per gli RS è specificato nella Sezione 5.3.

5.5. Registrazione e Neighbor Unreachability Detection (Registration and Neighbor Unreachability Detection)

Gli host inviano messaggi NS unicast per registrare i loro indirizzi IPv6 e anche per eseguire NUD per verificare che i loro router di default siano ancora raggiungibili. La registrazione è eseguita dall’host includendo una ARO nel NS che invia. Anche se l’host non ha dati da inviare, ma si aspetta che altri tentino di inviare pacchetti verso l’host, l’host deve mantenere le proprie NCE nei router. Questo è fatto inviando messaggi NS con una ARO al router ben prima della scadenza del Registration Lifetime. I messaggi NS sono ritrasmessi fino a MAX_UNICAST_SOLICIT volte usando un timeout minimo di RETRANS_TIMER finché l’host riceve un messaggio NA con una ARO.

Gli host che ricevono messaggi RA da più router di default SHOULD tentare di registrarsi con più di uno di essi per aumentare la robustezza della rete.

Si noti che i probe NUD possono essere soppressi da conferme di raggiungibilità dai protocolli di trasporto o dalle applicazioni come specificato in [RFC4861].

Quando un host sa che non userà più un router con cui è registrato, SHOULD de-registrarsi dal router inviando un NS con una ARO contenente una durata di vita pari a 0. Per gestire il caso in cui un host perda involontariamente la connettività con il router di default, l’host SHOULD usare un Registration Lifetime sufficientemente basso.

5.5.1. Sending a Neighbor Solicitation (Invio di un Neighbor Solicitation)

L’host attiva l’invio di messaggi NS contenenti una ARO quando un nuovo indirizzo è configurato, quando scopre un nuovo router di default, o ben prima che il Registration Lifetime scada. Un tale NS MUST includere un SLLAO, poiché il router deve registrare l’indirizzo di livello link dell’host. Un indirizzo sorgente unspecified MUST NOT essere usato nei messaggi NS.

5.5.2. Processing a Neighbor Advertisement (Elaborazione di un Neighbor Advertisement)

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

In aggiunta alla normale validazione di un NA e delle sue opzioni, l’ARO (se presente) è verificata come segue. Se il campo Length non è due, l’opzione è ignorata silenziosamente. Se il campo EUI-64 non corrisponde all’EUI-64 dell’interfaccia, l’opzione è ignorata silenziosamente.

Se il campo Status è zero, allora la registrazione dell’indirizzo ha avuto successo. L’host salva il Registration Lifetime dall’ARO per usarlo per attivare un nuovo NS ben prima che la durata di vita scada. Se il campo Status non è uguale a zero, la registrazione dell’indirizzo è fallita.

5.5.3. Recovering from Failures (Recupero dai fallimenti)

La procedura per mantenere le informazioni di raggiungibilità su un vicino è la stessa di [RFC4861], Sezione 7.3, con l’eccezione che la risoluzione degli indirizzi non è eseguita.

La procedura di registrazione dell’indirizzo può fallire per due ragioni: non si riceve alcuna risposta ai NS (fallimento NUD) oppure si riceve una ARO con uno Status di fallimento (Status > 0). Nel caso di fallimento NUD, l’entry per quel router verrà rimossa; dunque, la registrazione dell’indirizzo non è più importante. Quando si riceve una ARO con un campo Status non nullo, questo indica che la registrazione per quell’indirizzo è fallita. Uno Status di fallimento pari a uno indica che è stato rilevato un indirizzo duplicato e viene seguita la procedura descritta in [RFC4862], Sezione 5.4.5. L’host MUST NOT usare l’indirizzo che ha tentato di registrare. Se l’host ha registrazioni valide con altri router, queste MUST essere rimosse registrandosi con ciascuno usando una ARO lifetime pari a zero.

Un codice Status pari a due indica che la Neighbor Cache di quel router è piena. In questo caso, l’host SHOULD rimuovere questo router dalla propria lista di router di default e tentare di registrarsi con un altro router. Se la lista dei router di default dell’host è vuota, deve tornare a inviare RS come specificato nella Sezione 5.3.

Altri codici di fallimento possono essere definiti in documenti futuri.

5.6. Determinazione del next-hop (Next-Hop Determination)

L’indirizzo IP del next-hop per una destinazione è determinato come segue. Le destinazioni verso il prefisso link-local (fe80::) sono sempre inviate sul collegamento verso quella destinazione. Si assume che gli indirizzi link-local siano formati come specificato nella Sezione 5.2 a partire dall’EUI-64 e che la risoluzione degli indirizzi non sia eseguita. I pacchetti sono inviati a destinazioni link-local invertendo la procedura nell’Appendix A di [RFC4291].

Gli indirizzi multicast sono considerati on-link e sono risolti come specificato in [RFC4944] o nel documento IP-over-foo appropriato. Si noti che [RFC4944] definisce solo come rappresentare un indirizzo di destinazione multicast nell’header LoWPAN. Il supporto per scope multicast più ampi del link-local richiede un appropriato algoritmo di routing multicast.

Tutti gli altri prefissi sono assunti off-link [RFC5889]. Gli indirizzi anycast sono sempre considerati off-link. Essi sono quindi inviati a uno dei router nella lista dei router di default.

Un nodo LoWPAN non è tenuto a mantenere un minimo di un buffer per vicino come specificato in [RFC4861], poiché i pacchetti non sono mai accodati mentre si attende la risoluzione degli indirizzi.

5.7. Risoluzione degli indirizzi (Address Resolution)

Il meccanismo di registrazione dell’indirizzo e l’SLLAO nei messaggi RA forniscono uno stato a priori sufficiente in router e host per risolvere un indirizzo IPv6 nel suo associato indirizzo di livello link. Poiché tutti i prefissi eccetto il prefisso link-local e gli indirizzi multicast sono sempre assunti off-link, la risoluzione degli indirizzi basata su multicast tra vicini non è necessaria.

Gli indirizzi di livello link per i vicini sono memorizzati in NCE [RFC4861]. Per ottenere la compressione LoWPAN, la maggior parte degli indirizzi globali è formata usando un indirizzo di livello link. Pertanto, un host può ridurre l’uso di memoria ottimizzando questo caso e memorizzando informazioni sull’indirizzo di livello link solo se esso differisce dall’indirizzo di livello link corrispondente all’Interface ID dell’indirizzo IPv6 (cioè differisce in più del solo bit on-link/global invertito).

5.8. Sleep (Sleeping)

È spesso vantaggioso per gli host alimentati a batteria nei LoWPAN mantenere un basso duty cycle. Le ottimizzazioni descritte in questo documento consentono agli host di andare in sleep, come ulteriormente descritto in questa sezione. I router potrebbero voler mettere in cache traffico destinato a un host che sta dormendo, ma tale funzionalità è fuori dallo scopo di questo documento.

5.8.1. Picking an Appropriate Registration Lifetime (Scelta di un Registration Lifetime appropriato)

Poiché tutti i messaggi ND sono iniziati dagli host, questo consente a un host di dormire o essere altrimenti irraggiungibile tra gli scambi di messaggi NS/NA. L’ARO allegata ai messaggi NS indica a un router di mantenere valida la NCE per quell’indirizzo per il periodo nel campo Registration Lifetime. Un host dovrebbe scegliere un tempo di sleep appropriato alle proprie caratteristiche energetiche e impostare un Registration Lifetime maggiore del tempo di sleep per assicurare che la registrazione venga rinnovata con successo (considerando, ad esempio, la deriva dell’orologio e il tempo aggiuntivo per potenziali ritrasmissioni della ri-registrazione). La configurazione esterna di un host dovrebbe anche considerare la stabilità della rete (quanto rapidamente cambia la topologia) quando sceglie il proprio tempo di sleep (e quindi il Registration Lifetime). Una rete dinamica richiede un tempo di sleep più breve in modo che i router non mantengano NCE non valide per i nodi più a lungo del necessario.

5.8.2. Behavior on Wakeup (Comportamento al risveglio)

Quando un host si risveglia da un periodo di sleep, SHOULD rinfrescare le proprie registrazioni di indirizzo correnti che scadranno prima del prossimo risveglio. Questo viene fatto inviando messaggi NS con una ARO come descritto nella Sezione 5.5.1. L’host potrebbe anche dover rinfrescare le proprie informazioni di prefisso e contesto inviando un nuovo RS unicast (il Router Lifetime massimo è circa 18 ore, mentre il Registration Lifetime massimo è circa 45,5 giorni). Se dopo il risveglio l’host (usando NUD) determina che alcuni o tutti i precedenti router di default sono diventati irraggiungibili, allora l’host invierà RS multicast per scoprire nuovi router di default e riavviare il processo di registrazione dell’indirizzo.