7. Comportamento del Router di Bordo
Un 6LBR gestisce l'invio di RA e l'elaborazione di NS dagli host come specificato sopra nella Sezione 6. Un 6LBR DOVREBBE includere sempre un ABRO negli RA che invia, elencando se stesso come indirizzo 6LBR. Ciò richiede che il 6LBR mantenga il numero di versione in uno storage stabile e aumenti il numero di versione quando alcune informazioni nei suoi RA cambiano. Le informazioni il cui cambiamento influenza la versione si trovano nei PIO (i prefissi o le loro durate) e nelle 6CO (i prefissi, i CID o le durate).
Inoltre, un 6LBR è in qualche modo configurato con il prefisso o i prefissi assegnati alla LoWPAN e li annuncia negli RA come in [RFC4861]. Nel caso di route-over, quei prefissi possono essere disseminati a tutti i 6LR utilizzando la tecnica discussa nella Sezione 8.1. Tuttavia, potrebbero esserci meccanismi al di fuori dell'ambito di questo documento che possono essere utilizzati come sostituto per la disseminazione dei prefissi nella topologia route-over (vedi Sezione 1.4).
Se la 6LoWPAN utilizza la compressione dell'intestazione [RFC6282] con contesto, allora il 6LBR deve gestire i CID e annunciarli negli RA includendo 6CO nei suoi RA in modo che gli host direttamente collegati siano informati sui CID. Di seguito, specifichiamo le cose da considerare quando il 6LBR deve aggiungere, rimuovere o modificare le informazioni di contesto. Nel caso di route-over, le informazioni di contesto sono disseminate a tutti i 6LR utilizzando la tecnica discussa nella Sezione 8, a meno che una specifica diversa non fornisca un sostituto per questa distribuzione multihop.
7.1. Determinazione del Prefisso
Il prefisso o i prefissi utilizzati in una LoWPAN possono essere configurati manualmente o possono essere acquisiti utilizzando la Delega del Prefisso DHCPv6 [RFC3633]. Per una LoWPAN che è isolata dalla rete in modo permanente o occasionale, il 6LBR può assegnare un prefisso ULA utilizzando [RFC4193]. Il prefisso ULA dovrebbe essere memorizzato in uno storage stabile in modo che lo stesso prefisso venga utilizzato dopo un guasto del 6LBR. Se la LoWPAN ha più 6LBR, allora dovrebbero essere configurati con lo stesso set di prefissi. Il set di prefissi è incluso nei messaggi RA come specificato in [RFC4861].
7.2. Configurazione e Gestione del Contesto
Se la 6LoWPAN utilizza la compressione dell'intestazione [RFC6282] con contesto, allora il 6LBR deve essere configurato con le informazioni di contesto e i relativi CID. Se la LoWPAN ha più 6LBR, allora DEVONO essere configurati con le stesse informazioni di contesto e CID. Come notato in [RFC6282], mantenere la coerenza delle informazioni di contesto è cruciale per garantire che i pacchetti vengano decompressi correttamente.
Le informazioni di contesto trasportate nei messaggi RA hanno origine nei 6LBR e devono essere disseminate a tutti i router e host all'interno della LoWPAN. Gli RA includono una 6CO per ogni contesto.
Per la disseminazione delle informazioni di contesto utilizzando la 6CO, DOVREBBE essere utilizzato un ciclo di vita rigoroso per garantire che le informazioni di contesto rimangano sincronizzate in tutta la LoWPAN. Nuove informazioni di contesto DOVREBBERO essere introdotte nella LoWPAN con C=0, per garantire che siano note a tutti i nodi che potrebbero dover eseguire la decompressione dell'intestazione basata su queste informazioni di contesto. Solo quando è ragionevole presumere che queste informazioni siano state disseminate con successo, DOVREBBE essere inviata un'opzione con C=1, abilitando l'uso effettivo delle informazioni di contesto per la compressione.
Viceversa, per evitare la situazione in cui i nodi inviano pacchetti che fanno uso di valori precedenti dei contesti -- il che risulterebbe in ambiguità quando si riceve un pacchetto che utilizza un contesto modificato di recente -- i vecchi valori di un contesto DOVREBBERO essere messi fuori uso per un po' prima che nuovi valori vengano assegnati a questo specifico contesto. Cioè, in preparazione per un cambio di informazioni di contesto, la sua disseminazione DOVREBBE continuare per almeno MIN_CONTEXT_CHANGE_DELAY con C=0. Solo quando è ragionevole presumere che il fatto che il contesto sia ora non valido sia stato disseminato con successo, il CID dovrebbe essere tolto dalla disseminazione o riutilizzato con un campo Prefisso di Contesto diverso. In quest'ultimo caso, la disseminazione del nuovo valore DOVREBBE iniziare nuovamente con C=0, come sopra.