6. Messaggio di controllo RPL ICMPv6
Questo documento definisce il messaggio di controllo RPL, un nuovo messaggio ICMPv6 [RFC4443]. Un messaggio di controllo RPL è identificato da un codice e composto da una base che dipende dal codice (e una serie di opzioni).
La maggior parte dei messaggi di controllo RPL ha l'ambito di un collegamento. L'unica eccezione è per i messaggi DAO / DAO-ACK in modalità Non-Storing, che vengono scambiati utilizzando un indirizzo unicast su più hop e quindi utilizzano indirizzi globali o unique-local sia per l'indirizzo sorgente che per quello di destinazione. Per tutti gli altri messaggi di controllo RPL, l'indirizzo sorgente è un indirizzo link-local e l'indirizzo di destinazione è l'indirizzo multicast di tutti i nodi RPL o un indirizzo unicast link-local della destinazione. L'indirizzo multicast di tutti i nodi RPL è un nuovo indirizzo con un valore di ff02::1a.
In conformità con [RFC4443], il messaggio di controllo RPL è costituito da un'intestazione ICMPv6 seguita da un corpo del messaggio. Il corpo del messaggio è composto da una base del messaggio e possibilmente da un numero di opzioni come illustrato nella Figura 6.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Base .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Option(s) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: RPL Control Message
Il messaggio di controllo RPL è un messaggio informativo ICMPv6 con un Tipo di 155.
Il campo Codice identifica il tipo di messaggio di controllo RPL. Questo documento definisce i codici per i seguenti tipi di messaggi di controllo RPL (vedere la Sezione 20.2)):
-
0x00: Sollecitazione informazioni DODAG (DIS) (Sezione 6.2)
-
0x01: Oggetto informazioni DODAG (DIO) (Sezione 6.3)
-
0x02: Oggetto annuncio destinazione (DAO) (Sezione 6.4)
-
0x03: Riconoscimento oggetto annuncio destinazione (DAO-ACK) (Sezione 6.5)
-
0x80: Sollecitazione informazioni DODAG sicura (Sezione 6.2.2)
-
0x81: Oggetto informazioni DODAG sicuro (Sezione 6.3.2)
-
0x82: Oggetto annuncio destinazione sicuro (Sezione 6.4.2)
-
0x83: Riconoscimento oggetto annuncio destinazione sicuro (Sezione 6.5.2)
-
0x8A: Controllo coerenza (Sezione 6.6)
Se un nodo riceve un messaggio di controllo RPL con un campo Codice sconosciuto, il nodo DEVE scartare il messaggio senza alcuna ulteriore elaborazione, PUÒ sollevare un avviso di gestione e NON DEVE inviare alcun messaggio in risposta.
Il checksum viene calcolato come specificato in [RFC4443]. È impostato su zero per le operazioni di sicurezza RPL specificate di seguito e calcolato una volta che il resto del contenuto del messaggio RPL, inclusi i campi di sicurezza, è tutto impostato.
Il bit di ordine superiore (0x80) del codice indica se il messaggio RPL ha la sicurezza abilitata. I messaggi RPL sicuri hanno un formato per supportare la riservatezza e l'integrità, illustrato nella Figura 7.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Security .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Base .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Option(s) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Secure RPL Control Message
Il resto di questa sezione descrive i formati Base dei messaggi di controllo RPL attualmente definiti seguiti dalle opzioni dei messaggi di controllo RPL attualmente definite.
6.1. Campi di sicurezza RPL
Ogni messaggio RPL ha una variante sicura. Le varianti sicure forniscono integrità e protezione dalla riproduzione, nonché riservatezza opzionale e protezione dai ritardi. Poiché la sicurezza copre il messaggio di base e le opzioni, nei messaggi protetti le informazioni di sicurezza si trovano tra il checksum e la base, come mostrato nella Figura 7.
Il livello di sicurezza e gli algoritmi in uso sono indicati nei messaggi di protocollo come descritto di seguito:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Reserved | Algorithm |KIM|Resvd| LVL | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Key Identifier .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Security Section
I codici di autenticazione dei messaggi (MAC) e le firme forniscono l'autenticazione sull'intero messaggio di controllo RPL ICMPv6 non protetto, inclusa la sezione Sicurezza con tutti i campi definiti, ma con il checksum ICMPv6 temporaneamente impostato su zero. La crittografia fornisce la riservatezza del messaggio RPL ICMPv6 protetto a partire dal primo byte dopo la sezione Sicurezza e continuando fino all'ultimo byte del pacchetto. La trasformazione di sicurezza produce un messaggio RPL ICMPv6 protetto con l'inclusione dei campi crittografici (MAC, firma, ecc.). In altre parole, la trasformazione di sicurezza stessa (ad esempio, la firma e/o l'algoritmo in uso) descriverà in dettaglio come incorporare i campi crittografici nel pacchetto protetto. La sezione Sicurezza stessa non trasporta esplicitamente quei campi crittografici. L'uso della sezione Sicurezza è ulteriormente dettagliato nelle Sezioni 19 e 10.
Counter is Time (T): : Se il flag Time del contatore è impostato, il campo Counter è un timestamp. Se il flag è cancellato, il contatore è un contatore incrementale. La Sezione 10.5 descrive i dettagli del flag 'T' e del campo Counter.
Reserved: : Campo inutilizzato a 7 bit. Il campo DEVE essere inizializzato a zero dal mittente e DEVE essere ignorato dal ricevitore.
Security Algorithm (Algorithm): : Il campo Algoritmo di sicurezza specifica lo schema di crittografia, MAC e firma utilizzato dalla rete. I valori supportati di questo campo sono i seguenti:
+-----------+-------------------+------------------------+
| Algorithm | Encryption/MAC | Signature |
+-----------+-------------------+------------------------+
| 0 | CCM with AES-128 | RSA with SHA-256 |
| 1-255 | Unassigned | Unassigned |
+-----------+-------------------+------------------------+
Figure 9: Security Algorithm (Algorithm) Encoding
La Sezione 10.9 descrive gli algoritmi in maggior dettaglio.
Key Identifier Mode (KIM): : La modalità identificatore chiave è un campo a 2 bit che indica se la chiave utilizzata per la protezione dei pacchetti è determinata implicitamente o esplicitamente e indica la particolare rappresentazione del campo Identificatore chiave. La modalità identificatore chiave è impostata su uno dei valori della tabella seguente:
+------+-----+-----------------------------+------------+
| Mode | KIM | Meaning | Key |
| | | | Identifier |
| | | | Length |
| | | | (octets) |
+------+-----+-----------------------------+------------+
| 0 | 00 | Group key used. | 1 |
| | | Key determined by Key Index | |
| | | field. | |
| | | | |
| | | Key Source is not present. | |
| | | Key Index is present. | |
+------+-----+-----------------------------+------------+
| 1 | 01 | Per-pair key used. | 0 |
| | | Key determined by source | |
| | | and destination of packet. | |
| | | | |
| | | Key Source is not present. | |
| | | Key Index is not present. | |
+------+-----+-----------------------------+------------+
| 2 | 10 | Group key used. | 9 |
| | | Key determined by Key Index | |
| | | and Key Source Identifier. | |
| | | | |
| | | Key Source is present. | |
| | | Key Index is present. | |
+------+-----+-----------------------------+------------+
| 3 | 11 | Node's signature key used. | 0/9 |
| | | If packet is encrypted, | |
| | | it uses a group key, Key | |
| | | Index and Key Source | |
| | | specify key. | |
| | | | |
| | | Key Source may be present. | |
| | | Key Index may be present. | |
+------+-----+-----------------------------+------------+
Figure 10: Key Identifier Mode (KIM) Encoding
Nella modalità 3 (KIM=11), la presenza o l'assenza della sorgente chiave e dell'identificatore chiave dipende dal livello di sicurezza (LVL) descritto di seguito. Se il livello di sicurezza indica che c'è crittografia, allora i campi sono presenti; se indica che non c'è crittografia, allora i campi non sono presenti.
Resvd: : Campo inutilizzato a 3 bit. Il campo DEVE essere inizializzato a zero dal mittente e DEVE essere ignorato dal ricevitore.
Security Level (LVL): : Il livello di sicurezza è un campo a 3 bit che indica la protezione del pacchetto fornita. Questo valore può essere adattato in base al pacchetto e consente vari livelli di autenticità dei dati e, facoltativamente, di riservatezza dei dati. Il campo KIM indica se vengono utilizzate le firme e il significato del campo Livello. Si noti che i valori assegnati del livello di sicurezza non sono necessariamente ordinati: un valore più alto di LVL non equivale necessariamente a una maggiore sicurezza. Il livello di sicurezza è impostato su uno dei valori nelle tabelle seguenti:
+---------------------------+
| KIM=0,1,2 |
+-------+--------------------+------+
| LVL | Attributes | MAC |
| | | Len |
+-------+--------------------+------+
| 0 | MAC-32 | 4 |
| 1 | ENC-MAC-32 | 4 |
| 2 | MAC-64 | 8 |
| 3 | ENC-MAC-64 | 8 |
| 4-7 | Unassigned | N/A |
+-------+--------------------+------+
+---------------------+
| KIM=3 |
+-------+---------------+-----+
| LVL | Attributes | Sig |
| | | Len |
+-------+---------------+-----+
| 0 | Sign-3072 | 384 |
| 1 | ENC-Sign-3072 | 384 |
| 2 | Sign-2048 | 256 |
| 3 | ENC-Sign-2048 | 256 |
| 4-7 | Unassigned | N/A |
+-------+---------------+-----+
Figure 11: Security Level (LVL) Encoding
L'attributo MAC indica che il messaggio ha un MAC della lunghezza specificata. L'attributo ENC indica che il messaggio è crittografato. L'attributo Sign indica che il messaggio ha una firma della lunghezza specificata.
Flags: : Campo inutilizzato a 8 bit riservato ai flag. Il campo DEVE essere inizializzato a zero dal mittente e DEVE essere ignorato dal ricevitore.
Counter: : Il campo Counter indica il valore a 4 ottetti non ripetitivo utilizzato per costruire il meccanismo crittografico che implementa la protezione dei pacchetti e consente la fornitura di sicurezza semantica. Vedere la Sezione 10.9.1.
Key Identifier: : Il campo Key Identifier indica quale chiave è stata utilizzata per proteggere il pacchetto. Questo campo fornisce vari livelli di granularità della protezione dei pacchetti, incluse chiavi peer-to-peer, chiavi di gruppo e chiavi di firma. Questo campo è rappresentato come indicato dal campo Key Identifier Mode ed è formattato come segue:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Key Source .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Key Index .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Key Identifier
Key Source: : Il campo Key Source, quando presente, indica l'identificatore logico dell'originatore di una chiave di gruppo. Quando presente, questo campo ha una lunghezza di 8 byte.
Key Index: : Il campo Key Index, quando presente, consente l'identificazione univoca di chiavi diverse con lo stesso originatore. È responsabilità di ciascun originatore della chiave assicurarsi che le chiavi utilizzate attivamente che emette abbiano indici chiave distinti e che tutti gli indici chiave abbiano un valore diverso da 0x00. Il valore 0x00 è riservato per una chiave condivisa preinstallata. Quando presente, questo campo ha una lunghezza di 1 byte.
I bit non assegnati della sezione Sicurezza sono riservati. DEVONO essere impostati a zero durante la trasmissione e DEVONO essere ignorati durante la ricezione.
6.2. Sollecitazione informazioni DODAG (DIS)
Il messaggio di sollecitazione informazioni DODAG (DIS) può essere utilizzato per sollecitare un oggetto informazioni DODAG da un nodo RPL. Il suo utilizzo è analogo a quello di una sollecitazione router come specificato in IPv6 Neighbor Discovery; un nodo può utilizzare DIS per sondare il suo vicinato alla ricerca di DODAG vicini. La Sezione 8.3 descrive come i nodi rispondono a un DIS.
6.2.1. Formato dell'oggetto base DIS
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | Option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: The DIS Base Object
Flags: : Campo inutilizzato a 8 bit riservato ai flag. Il campo DEVE essere inizializzato a zero dal mittente e DEVE essere ignorato dal ricevitore.
Reserved: : Campo inutilizzato a 8 bit. Il campo DEVE essere inizializzato a zero dal mittente e DEVE essere ignorato dal ricevitore.
I bit non assegnati della Base DIS sono riservati. DEVONO essere impostati a zero durante la trasmissione e DEVONO essere ignorati durante la ricezione.
6.2.2. DIS sicuro
Un messaggio DIS sicuro segue il formato nella Figura 7, dove il formato di base è il messaggio DIS mostrato nella Figura 13.
6.2.3. Opzioni DIS
Il messaggio DIS PUÒ trasportare opzioni valide.
Questa specifica consente al messaggio DIS di trasportare le seguenti opzioni:
- 0x00 Pad1
- 0x01 PadN
- 0x07 Informazioni sollecitate
6.3. Oggetto informazioni DODAG (DIO)
L'oggetto informazioni DODAG trasporta informazioni che consentono a un nodo di scoprire un'istanza RPL, apprendere i suoi parametri di configurazione, selezionare un insieme genitore DODAG e mantenere il DODAG.
6.3.1. Formato dell'oggetto base DIO
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |Version Number | Rank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|0| MOP | Prf | DTSN | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
Figure 14: The DIO Base Object
Grounded (G): : Il flag Grounded 'G' indica se il DODAG pubblicizzato può soddisfare l'obiettivo definito dall'applicazione. Se il flag è impostato, il DODAG è a terra (Grounded). Se il flag è cancellato, il DODAG è fluttuante (Floating).
Mode of Operation (MOP): : Il campo Mode of Operation (MOP) identifica la modalità di funzionamento dell'istanza RPL come amministrativamente fornita e distribuita dalla radice DODAG. Tutti i nodi che si uniscono al DODAG devono essere in grado di onorare il MOP per partecipare pienamente come router, altrimenti devono unirsi solo come foglia. MOP è codificato come nella figura seguente:
+-----+-----------------------------------------------------+
| MOP | Description |
+-----+-----------------------------------------------------+
| 0 | No Downward routes maintained by RPL |
| 1 | Non-Storing Mode of Operation |
| 2 | Storing Mode of Operation with no multicast support |
| 3 | Storing Mode of Operation with multicast support |
| | |
| | All other values are unassigned |
+-----+-----------------------------------------------------+
Un valore di 0 indica che i messaggi di annuncio di destinazione sono disabilitati e il DODAG mantiene solo rotte verso l'alto.
Figure 15: Mode of Operation (MOP) Encoding
DODAGPreference (Prf): : Un intero senza segno a 3 bit che definisce quanto è preferibile la radice di questo DODAG rispetto ad altre radici DODAG all'interno dell'istanza. DAGPreference varia da 0x00 (meno preferito) a 0x07 (più preferito). Il valore predefinito è 0 (meno preferito). La Sezione 8.2 descrive come DAGPreference influenza l'elaborazione DIO.
Version Number: : Intero senza segno a 8 bit impostato dalla radice DODAG sul DODAGVersionNumber. La Sezione 8.2 descrive le regole per i DODAGVersionNumber e come influenzano l'elaborazione DIO.
Rank: : Intero senza segno a 16 bit che indica il rango DODAG del nodo che invia il messaggio DIO. La Sezione 8.2 descrive come viene impostato il rango e come influenza l'elaborazione DIO.
RPLInstanceID: : Campo a 8 bit impostato dalla radice DODAG che indica di quale istanza RPL fa parte il DODAG.
Destination Advertisement Trigger Sequence Number (DTSN): : Intero senza segno a 8 bit impostato dal nodo che emette il messaggio DIO. Il flag Destination Advertisement Trigger Sequence Number (DTSN) viene utilizzato come parte della procedura per mantenere le rotte verso il basso. I dettagli di questo processo sono descritti nella Sezione 9.
Flags: : Campo inutilizzato a 8 bit riservato ai flag. Il campo DEVE essere inizializzato a zero dal mittente e DEVE essere ignorato dal ricevitore.
Reserved: : Campo inutilizzato a 8 bit. Il campo DEVE essere inizializzato a zero dal mittente e DEVE essere ignorato dal ricevitore.
DODAGID: : Indirizzo IPv6 a 128 bit impostato da una radice DODAG che identifica in modo univoco un DODAG. Il DODAGID DEVE essere un indirizzo IPv6 instradabile appartenente alla radice DODAG.
I bit non assegnati della Base DIO sono riservati. DEVONO essere impostati a zero durante la trasmissione e DEVONO essere ignorati durante la ricezione.
6.3.2. DIO sicuro
Un messaggio DIO sicuro segue il formato nella Figura 7, dove il formato di base è il messaggio DIO mostrato nella Figura 14.
6.3.3. Opzioni DIO
Il messaggio DIO PUÒ trasportare opzioni valide.
Questa specifica consente al messaggio DIO di trasportare le seguenti opzioni:
- 0x00 Pad1
- 0x01 PadN
- 0x02 Contenitore metrico DAG
- 0x03 Informazioni di routing
- 0x04 Configurazione DODAG
- 0x08 Informazioni sul prefisso
6.4. Oggetto annuncio destinazione (DAO)
L'oggetto annuncio destinazione (DAO) viene utilizzato per propagare le informazioni sulla destinazione verso l'alto lungo il DODAG. In modalità Storing, il messaggio DAO è unicast dal figlio al/i genitore/i selezionato/i. In modalità Non-Storing, il messaggio DAO è unicast alla radice DODAG. Il messaggio DAO può facoltativamente, su richiesta esplicita o errore, essere riconosciuto dalla sua destinazione con un messaggio di riconoscimento annuncio destinazione (DAO-ACK) al mittente del DAO.
6.4.1. Formato dell'oggetto base DAO
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |K|D| Flags | Reserved | DAOSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID* +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
The '*' denotes that the DODAGID is not always present, as described
below.
Figure 16: The DAO Base Object
RPLInstanceID: : Campo a 8 bit che indica l'istanza della topologia associata al DODAG, come appreso dal DIO.
K: : Il flag 'K' indica che il destinatario dovrebbe inviare un DAO-ACK. (Vedere la Sezione 9.3.)
D: : Il flag 'D' indica che il campo DODAGID è presente. Questo flag DEVE essere impostato quando viene utilizzato un RPLInstanceID locale.
Flags: : I 6 bit rimanenti inutilizzati nel campo Flags sono riservati ai flag. Il campo DEVE essere inizializzato a zero dal mittente e DEVE essere ignorato dal ricevitore.
Reserved: : Campo inutilizzato a 8 bit. Il campo DEVE essere inizializzato a zero dal mittente e DEVE essere ignorato dal ricevitore.
DAOSequence: : Incrementato a ogni messaggio DAO univoco da un nodo ed echeggiato nel messaggio DAO-ACK.
DODAGID (optional): : Intero senza segno a 128 bit impostato da una radice DODAG che identifica in modo univoco un DODAG. Questo campo è presente solo quando il flag 'D' è impostato. Questo campo è in genere presente solo quando è in uso un RPLInstanceID locale, al fine di identificare il DODAGID associato all'RPLInstanceID. Quando è in uso un RPLInstanceID globale, questo campo non deve essere presente.
I bit non assegnati della Base DAO sono riservati. DEVONO essere impostati a zero durante la trasmissione e DEVONO essere ignorati durante la ricezione.
6.4.2. DAO sicuro
Un messaggio DAO sicuro segue il formato nella Figura 7, dove il formato di base è il messaggio DAO mostrato nella Figura 16.
6.4.3. Opzioni DAO
Il messaggio DAO PUÒ trasportare opzioni valide.
Questa specifica consente al messaggio DAO di trasportare le seguenti opzioni:
- 0x00 Pad1
- 0x01 PadN
- 0x05 Target RPL
- 0x06 Informazioni di transito
- 0x09 Descrittore target RPL
Un caso speciale del messaggio DAO, denominato No-Path, viene utilizzato in modalità Storing per cancellare lo stato di routing verso il basso che è stato fornito tramite l'operazione DAO. Il No-Path trasporta un'opzione Target e un'opzione Informazioni di transito associata con una durata di 0x00000000 per indicare una perdita di raggiungibilità a quel Target.
6.5. Riconoscimento oggetto annuncio destinazione (DAO-ACK)
Il messaggio DAO-ACK viene inviato come pacchetto unicast da un destinatario DAO (un genitore DAO o una radice DODAG) in risposta a un messaggio DAO unicast.
6.5.1. Formato dell'oggetto base DAO-ACK
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |D| Reserved | DAOSequence | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID* +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
The '*' denotes that the DODAGID is not always present, as described
below.
Figure 17: The DAO ACK Base Object
RPLInstanceID: : Campo a 8 bit che indica l'istanza della topologia associata al DODAG, come appreso dal DIO.
D: : Il flag 'D' indica che il campo DODAGID è presente. Questo verrebbe in genere impostato solo quando viene utilizzato un RPLInstanceID locale.
Reserved: : Il campo a 7 bit, riservato ai flag.
DAOSequence: : Incrementato a ogni messaggio DAO da un nodo ed echeggiato nel DAO-ACK dal destinatario. La DAOSequence viene utilizzata per correlare un messaggio DAO e un messaggio DAO ACK e non deve essere confusa con la sequenza di percorso dell'opzione Informazioni di transito associata a un determinato Target verso il basso del DODAG.
Status: : Indica il completamento. Lo stato 0 è definito come accettazione incondizionata in questa specifica. I restanti valori di stato sono riservati come codici di rifiuto. Nessun codice di stato di rifiuto è definito in questa specifica, sebbene i codici di stato DOVREBBERO essere allocati secondo le seguenti linee guida nelle specifiche future:
* 0: Accettazione incondizionata (cioè, il nodo che riceve il DAO-ACK non viene rifiutato).
* 1-127: Non un rifiuto definitivo; il nodo che invia il DAO-ACK è disposto ad agire come genitore, ma si suggerisce al nodo ricevente di trovare e utilizzare un genitore alternativo.
* 127-255: Rifiuto; il nodo che invia il DAO-ACK non è disposto ad agire come genitore.
DODAGID (optional): : Intero senza segno a 128 bit impostato da una radice DODAG che identifica in modo univoco un DODAG. Questo campo è presente solo quando il flag 'D' è impostato. In genere, questo campo è presente solo quando è in uso un RPLInstanceID locale al fine di identificare il DODAGID associato all'RPLInstanceID. Quando è in uso un RPLInstanceID globale, questo campo non deve essere presente.
I bit non assegnati della Base DAO-ACK sono riservati. DEVONO essere impostati a zero durante la trasmissione e DEVONO essere ignorati durante la ricezione.
6.5.2. DAO-ACK sicuro
Un messaggio DAO-ACK sicuro segue il formato nella Figura 7, dove il formato di base è il messaggio DAO-ACK mostrato nella Figura 17.
6.5.3. Opzioni DAO-ACK
Questa specifica non definisce alcuna opzione da trasportare nel messaggio DAO-ACK.
6.6. Controllo coerenza (CC)
Il messaggio CC viene utilizzato per controllare i contatori dei messaggi sicuri ed emettere risposte di sfida. Un messaggio CC DEVE essere inviato come messaggio RPL protetto.
6.6.1. Formato dell'oggetto base CC
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |R| Flags | CC Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
Figure 18: The CC Base Object
RPLInstanceID: : Campo a 8 bit che indica l'istanza della topologia associata al DODAG, come appreso dal DIO.
R: : Il flag 'R' indica se il messaggio CC è una risposta. Un messaggio con il flag 'R' cancellato è una richiesta; un messaggio con il flag 'R' impostato è una risposta.
Flags: : I 7 bit rimanenti inutilizzati nel campo Flags sono riservati ai flag. Il campo DEVE essere inizializzato a zero dal mittente e DEVE essere ignorato dal ricevitore.
CC Nonce: : Intero senza segno a 16 bit impostato da una richiesta CC. La risposta CC corrispondente include lo stesso valore nonce CC della richiesta.
DODAGID: : Campo a 128 bit, contiene l'identificatore della radice DODAG.
Destination Counter: : Valore intero senza segno a 32 bit che indica la stima del mittente del valore attuale del contatore di sicurezza della destinazione. Se il mittente non ha una stima, DOVREBBE impostare il campo Destination Counter a zero.
I bit non assegnati della Base CC sono riservati. DEVONO essere impostati a zero durante la trasmissione e DEVONO essere ignorati durante la ricezione.
Il valore Destination Counter consente ai nodi nuovi o recuperati di risincronizzarsi tramite scambi di messaggi CC. Questo è importante per garantire che un valore del contatore non venga ripetuto per una data chiave di sicurezza anche in caso di dispositivi che si riprendono da un guasto che ha creato una perdita dello stato del contatore. Ad esempio, laddove viene ricevuta una richiesta CC o un altro messaggio RPL con un contatore inizializzato all'interno della sezione Sicurezza del messaggio, la fornitura del Contatore in entrata all'interno del messaggio di risposta CC consente al nodo richiedente di reimpostare il proprio Contatore in uscita su un valore maggiore dell'ultimo valore ricevuto dal nodo rispondente; il Contatore in entrata verrà aggiornato anche dalla risposta CC ricevuta.
6.6.2. Opzioni CC
Questa specifica consente al messaggio CC di trasportare le seguenti opzioni:
- 0x00 Pad1
- 0x01 PadN
6.7. Opzioni del messaggio di controllo RPL
6.7.1. Formato generico dell'opzione del messaggio di controllo RPL
Le opzioni del messaggio di controllo RPL seguono tutte questo formato:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
| Option Type | Option Length | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
Figure 19: RPL Option Generic Format
Option Type: : Identificatore a 8 bit del tipo di opzione. I valori del tipo di opzione sono assegnati da IANA (vedere la Sezione 20.4.)
Option Length: : Intero senza segno a 8 bit, che rappresenta la lunghezza in ottetti dell'opzione, esclusi i campi Tipo e Lunghezza opzione.
Option Data: : Un campo a lunghezza variabile che contiene dati specifici per l'opzione.
Durante l'elaborazione di un messaggio RPL contenente un'opzione per la quale il valore Tipo opzione non è riconosciuto dal ricevitore, il ricevitore DEVE ignorare silenziosamente l'opzione non riconosciuta e continuare a elaborare l'opzione successiva, gestendo correttamente eventuali opzioni rimanenti nel messaggio.
Le opzioni del messaggio RPL possono avere requisiti di allineamento. Seguendo la convenzione in IPv6, le opzioni con requisiti di allineamento sono allineate in un pacchetto in modo tale che i valori multi-ottetto all'interno del campo Dati opzione di ciascuna opzione cadano su confini naturali (cioè, i campi di larghezza n ottetti sono posizionati a un multiplo intero di n ottetti dall'inizio dell'intestazione, per n = 1, 2, 4 o 8).
6.7.2. Pad1
L'opzione Pad1 PUÒ essere presente nei messaggi DIS, DIO, DAO, DAO-ACK e CC e il suo formato è il seguente:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type = 0x00 |
+-+-+-+-+-+-+-+-+
Figure 20: Format of the Pad1 Option
L'opzione Pad1 viene utilizzata per inserire un singolo ottetto di riempimento nel messaggio per consentire l'allineamento delle opzioni. Se è richiesto più di un ottetto di riempimento, l'opzione PadN dovrebbe essere utilizzata anziché più opzioni Pad1.
NOTA! Il formato dell'opzione Pad1 è un caso speciale: non ha né i campi Lunghezza opzione né Dati opzione.
6.7.3. PadN
L'opzione PadN PUÒ essere presente nei messaggi DIS, DIO, DAO, DAO-ACK e CC e il suo formato è il seguente:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
| Type = 0x01 | Option Length | 0x00 Padding...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
Figure 21: Format of the Pad N Option
L'opzione PadN viene utilizzata per inserire due o più ottetti di riempimento nel messaggio per consentire l'allineamento delle opzioni. I dati dell'opzione PadN DEVONO essere ignorati dal ricevitore.
Option Type: : 0x01
Option Length: : Per N ottetti di riempimento, dove 2 <= N <= 7, il campo Lunghezza opzione contiene il valore N-2. Una Lunghezza opzione di 0 indica un riempimento totale di 2 ottetti. Una Lunghezza opzione di 5 indica un riempimento totale di 7 ottetti, che è la dimensione massima di riempimento consentita con l'opzione PadN.
Option Data: : Per N (N > 1) ottetti di riempimento, i Dati opzione sono costituiti da N-2 ottetti a valore zero.
6.7.4. Contenitore metrico DAG
L'opzione Contenitore metrico DAG PUÒ essere presente nei messaggi DIO o DAO e il suo formato è il seguente:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
| Type = 0x02 | Option Length | Metric Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
Figure 22: Format of the DAG Metric Container Option
Il Contenitore metrico DAG viene utilizzato per segnalare le metriche lungo il DODAG. Il Contenitore metrico DAG può contenere un numero di metriche e vincoli discreti di nodo, collegamento e percorso aggregato specificati in [RFC6551] come scelto dall'implementatore.
Il Contenitore metrico DAG PUÒ apparire più di una volta nello stesso messaggio di controllo RPL, ad esempio, per adattarsi a un caso d'uso in cui i Dati metrici sono più lunghi di 256 byte. Maggiori informazioni sono in [RFC6551].
L'elaborazione e la propagazione del Contenitore metrico DAG sono regolate da funzioni di policy specifiche dell'implementazione.
Option Type: : 0x02
Option Length: : Il campo Lunghezza opzione contiene la lunghezza in ottetti dei Dati metrici.
Metric Data: : L'ordine, il contenuto e la codifica dei dati del Contenitore metrico DAG sono come specificato in [RFC6551].
6.7.5. Informazioni di routing
L'opzione Informazioni di routing (RIO) PUÒ essere presente nei messaggi DIO e trasporta le stesse informazioni del RIO IPv6 Neighbor Discovery (ND) come definito in [RFC4191]. La radice di un DODAG è autorevole per l'impostazione di tali informazioni e le informazioni rimangono invariate mentre vengono propagate lungo il DODAG. Un router RPL può trasformarlo banalmente in un'opzione ND da pubblicizzare nelle proprie RA in modo che un nodo collegato al router RPL finirà per utilizzare il DODAG per il quale la radice ha la migliore preferenza per la destinazione di un pacchetto. Oltre alla semantica ND esistente, è possibile per una funzione obiettivo utilizzare queste informazioni per favorire un DODAG la cui radice è più preferita per una destinazione specifica. Il formato dell'opzione è leggermente modificato (Tipo, Lunghezza, Prefisso) per essere trasportato come opzione RPL come segue:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x03 | Option Length | Prefix Length |Resvd|Prf|Resvd|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Prefix (Variable Length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Format of the Route Information Option
Il RIO viene utilizzato per indicare che la connettività al prefisso di destinazione specificato è disponibile dalla radice DODAG.
Nel caso in cui un messaggio di controllo RPL debba specificare la connettività a più di una destinazione, il RIO può essere ripetuto.
[RFC4191] dovrebbe essere consultato come riferimento autorevole rispetto al RIO. Le descrizioni dei campi sono trascritte qui per comodità:
Option Type: : 0x03
Option Length: : Variabile, lunghezza dell'opzione in ottetti esclusi i campi Tipo e Lunghezza. Si noti che questa lunghezza è espressa in unità di singoli ottetti, a differenza di IPv6 ND.
Prefix Length: : Intero senza segno a 8 bit. Il numero di bit iniziali nel prefisso che sono validi. Il valore varia da 0 a 128. Il campo Prefisso ha il numero di byte dedotto dal campo Lunghezza opzione, che deve essere almeno la Lunghezza prefisso. Si noti che in RPL, ciò significa che il campo Prefisso può avere lunghezze diverse da 0, 8 o 16.
Prf: : Intero con segno a 2 bit. La preferenza di rotta indica se preferire il router associato a questo prefisso rispetto ad altri, quando sono stati ricevuti più prefissi identici (per router diversi). Se viene ricevuto il valore Riservato (10), il RIO DEVE essere ignorato. Per [RFC4191], il valore Riservato (10) NON DEVE essere inviato. ([RFC4191] limita la Preferenza a soli tre valori per rafforzare il fatto che non è una metrica.)
Resvd: : Due campi inutilizzati a 3 bit. DEVONO essere inizializzati a zero dal mittente e DEVONO essere ignorati dal ricevitore.
Route Lifetime: : Intero senza segno a 32 bit. La lunghezza del tempo in secondi (rispetto al momento in cui viene inviato il pacchetto) in cui il prefisso è valido per la determinazione della rotta. Un valore di tutti i bit a uno (0xFFFFFFFF) rappresenta l'infinito.
Prefix: : Campo a lunghezza variabile contenente un indirizzo IP o un prefisso di un indirizzo IPv6. Il campo Lunghezza prefisso contiene il numero di bit iniziali validi nel prefisso. I bit nel prefisso dopo la lunghezza del prefisso (se presenti) sono riservati e DEVONO essere inizializzati a zero dal mittente e ignorati dal ricevitore. Si noti che in RPL, questo campo può avere lunghezze diverse da 0, 8 o 16.
I bit non assegnati del RIO sono riservati. DEVONO essere impostati a zero durante la trasmissione e DEVONO essere ignorati durante la ricezione.
6.7.6. Configurazione DODAG
L'opzione Configurazione DODAG PUÒ essere presente nei messaggi DIO e il suo formato è il seguente:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x04 |Opt Length = 14| Flags |A| PCS | DIOIntDoubl. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DIOIntMin. | DIORedun. | MaxRankIncrease |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MinHopRankIncrease | OCP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Def. Lifetime | Lifetime Unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Format of the DODAG Configuration Option
L'opzione Configurazione DODAG viene utilizzata per distribuire le informazioni di configurazione per l'operazione DODAG attraverso il DODAG.
Le informazioni comunicate in questa opzione sono generalmente statiche e immutabili all'interno del DODAG, quindi non è necessario includerle in ogni DIO. Queste informazioni sono configurate alla radice DODAG e distribuite in tutto il DODAG con l'opzione Configurazione DODAG. I nodi diversi dalla radice DODAG NON DEVONO modificare queste informazioni durante la propagazione dell'opzione Configurazione DODAG. Questa opzione PUÒ essere inclusa occasionalmente dalla radice DODAG (come determinato dalla radice DODAG) e DEVE essere inclusa in risposta a una richiesta unicast, ad esempio un messaggio di sollecitazione informazioni DODAG (DIS) unicast.
Option Type: : 0x04
Option Length: : 14
Flags: : I 4 bit rimanenti inutilizzati nel campo Flags sono riservati ai flag. Il campo DEVE essere inizializzato a zero dal mittente e DEVE essere ignorato dal ricevitore.
Authentication Enabled (A): : Flag a 1 bit che descrive la modalità di sicurezza della rete. Il bit descrive se un nodo deve autenticarsi con un'autorità chiave prima di unirsi alla rete come router. Se il DIO non è un DIO sicuro, il bit 'A' DEVE essere zero.
Path Control Size (PCS): : Intero senza segno a 3 bit utilizzato per configurare il numero di bit che possono essere allocati al campo Path Control (vedere la Sezione 9.9). Si noti che quando PCS viene consultato per determinare la larghezza del campo Path Control, viene aggiunto un valore di 1, cioè un valore PCS di 0 risulta in 1 bit attivo nel campo Path Control. Il valore predefinito di PCS è DEFAULT_PATH_CONTROL_SIZE.
DIOIntervalDoublings: : Intero senza segno a 8 bit utilizzato per configurare Imax del timer Trickle DIO (vedere la Sezione 8.3.1). Il valore predefinito di DIOIntervalDoublings è DEFAULT_DIO_INTERVAL_DOUBLINGS.
DIOIntervalMin: : Intero senza segno a 8 bit utilizzato per configurare Imin del timer Trickle DIO (vedere la Sezione 8.3.1). Il valore predefinito di DIOIntervalMin è DEFAULT_DIO_INTERVAL_MIN.
DIORedundancyConstant: : Intero senza segno a 8 bit utilizzato per configurare k del timer Trickle DIO (vedere la Sezione 8.3.1). Il valore predefinito di DIORedundancyConstant è DEFAULT_DIO_REDUNDANCY_CONSTANT.
MaxRankIncrease: : Intero senza segno a 16 bit utilizzato per configurare DAGMaxRankIncrease, l'aumento consentito del rango a supporto della riparazione locale. Se DAGMaxRankIncrease è 0, allora questo meccanismo è disabilitato.
MinHopRankIncrease: : Intero senza segno a 16 bit utilizzato per configurare MinHopRankIncrease come descritto nella Sezione 3.5.1. Il valore predefinito di MinHopRankInc è DEFAULT_MIN_HOP_RANK_INCREASE.
Objective Code Point (OCP): : Intero senza segno a 16 bit. Il campo OCP identifica l'OF ed è gestito da IANA.
Reserved: : Campo inutilizzato a 7 bit. Il campo DEVE essere inizializzato a zero dal mittente e DEVE essere ignorato dal ricevitore.
Default Lifetime: : Intero senza segno a 8 bit. Questa è la durata che viene utilizzata come predefinita per tutte le rotte RPL. È espressa in unità di Lifetime Unit, ad esempio, la durata predefinita in secondi è (Default Lifetime) * (Lifetime Unit).
Lifetime Unit: : Intero senza segno a 16 bit. Fornisce l'unità in secondi utilizzata per esprimere le durate delle rotte in RPL. Per reti molto stabili, possono essere ore o giorni.
6.7.7. Target RPL
L'opzione Target RPL PUÒ essere presente nei messaggi DAO e il suo formato è il seguente:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x05 | Option Length | Flags | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Target Prefix (Variable Length) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: Format of the RPL Target Option
L'opzione Target RPL viene utilizzata per indicare un indirizzo IPv6 di destinazione, un prefisso o un gruppo multicast raggiungibile o interrogato lungo il DODAG. In un DAO, l'opzione Target RPL indica la raggiungibilità.
Un'opzione Target RPL PUÒ facoltativamente essere accoppiata con un'opzione Descrittore target RPL (Figura 30) che qualifica il target.
Un insieme di una o più opzioni Informazioni di transito (Sezione 6.7.8) PUÒ seguire direttamente un insieme di una o più opzioni Target in un messaggio DAO (dove ciascuna opzione Target PUÒ essere accoppiata con un'opzione Descrittore target RPL come sopra). La struttura del messaggio DAO, che descrive in dettaglio come le opzioni Target vengono utilizzate insieme alle opzioni Informazioni di transito, è ulteriormente descritta nella Sezione 9.4.
L'opzione Target RPL può essere ripetuta se necessario per indicare più target.
Option Type: : 0x05
Option Length: : Variabile, lunghezza dell'opzione in ottetti esclusi i campi Tipo e Lunghezza.
Flags: : Campo inutilizzato a 8 bit riservato ai flag. Il campo DEVE essere inizializzato a zero dal mittente e DEVE essere ignorato dal ricevitore.
Prefix Length: : Intero senza segno a 8 bit. Numero di bit iniziali validi nel prefisso IPv6.
Target Prefix: : Campo a lunghezza variabile che identifica un indirizzo di destinazione IPv6, un prefisso o un gruppo multicast. Il campo Lunghezza prefisso contiene il numero di bit iniziali validi nel prefisso. I bit nel prefisso dopo la lunghezza del prefisso (se presenti) sono riservati e DEVONO essere impostati a zero durante la trasmissione e DEVONO essere ignorati durante la ricezione.
6.7.8. Informazioni di transito
L'opzione Informazioni di transito PUÒ essere presente nei messaggi DAO e il suo formato è il seguente:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x06 | Option Length |E| Flags | Path Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Sequence | Path Lifetime | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| |
+ Parent Address* +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The '*' denotes that the DODAG Parent Address subfield is not always
present, as described below.
Figure 26: Format of the Transit Information Option
L'opzione Informazioni di transito viene utilizzata da un nodo per indicare gli attributi per un percorso verso una o più destinazioni. Le destinazioni sono indicate da una o più opzioni Target che precedono immediatamente l'opzione (o le opzioni) Informazioni di transito.
L'opzione Informazioni di transito può essere utilizzata da un nodo per indicare i suoi genitori DODAG a un antenato che sta raccogliendo informazioni di routing DODAG, in genere, allo scopo di costruire percorsi di origine. Nella modalità operativa Non-Storing, questo antenato sarà la radice DODAG e questa opzione è trasportata dal messaggio DAO. Nella modalità operativa Storing, il sottocampo Indirizzo genitore DODAG non è necessario, poiché il messaggio DAO viene inviato direttamente al genitore. La lunghezza dell'opzione viene utilizzata per determinare se il sottocampo Indirizzo genitore DODAG è presente o meno.
Un nodo non-storing che ha più di un genitore DAO PUÒ includere un'opzione Informazioni di transito per ciascun genitore DAO come parte dell'operazione di annuncio di destinazione non-storing. Il nodo può distribuire i bit nel campo Path Control tra diversi gruppi di genitori DAO al fine di segnalare una preferenza tra i genitori. Tale preferenza può influenzare la decisione della radice DODAG quando si seleziona tra genitori/percorsi alternativi per la costruzione di percorsi verso il basso.
Una o più opzioni Informazioni di transito DEVONO essere precedute da una o più opzioni Target RPL. In questo modo, l'opzione Target RPL indica il nodo figlio e l'opzione (o le opzioni) Informazioni di transito elenca i genitori DODAG. La struttura del messaggio DAO, che descrive ulteriormente in dettaglio come le opzioni Target vengono utilizzate insieme alle opzioni Informazioni di transito, è ulteriormente descritta nella Sezione 9.4.
Un tipico nodo non-storing utilizzerà più opzioni Informazioni di transito e invierà il messaggio DAO così formato direttamente alla radice. Un tipico nodo storing utilizzerà un'opzione Informazioni di transito senza campo genitore e invierà il messaggio DAO così formato, con ulteriori aggiustamenti, al Path Control come descritto più avanti, a uno o più genitori.
Ad esempio, in una modalità operativa Non-Storing, sia Tgt(T) un'opzione Target per un Target T. Sia Trnst(P) un'opzione Informazioni di transito che contiene un indirizzo genitore P. Si consideri il caso di un nodo non-storing N che pubblicizza i target di proprietà N1 e N2 e ha i genitori P1, P2 e P3. In tal caso, ci si aspetterebbe che il messaggio DAO contenga la sequenza ((Tgt(N1), Tgt(N2)), (Trnst(P1), Trnst(P2), Trnst(P3))), in modo tale che il gruppo di opzioni Target {N1, N2} sia descritto dalle opzioni Informazioni di transito come avente i genitori {P1, P2, P3}. Il nodo non-storing indirizzerebbe quindi quel messaggio DAO direttamente alla radice DODAG e inoltrerebbe quel messaggio DAO attraverso uno dei genitori DODAG: P1, P2 o P3.
Option Type: : 0x06
Option Length: : Variabile, a seconda che il sottocampo Indirizzo genitore DODAG sia presente o meno.
External (E): : Flag a 1 bit. Il flag 'E' è impostato per indicare che il router genitore ridistribuisce target esterni nella rete RPL. Un Target esterno è un Target che è stato appreso tramite un protocollo alternativo. I target esterni sono elencati nelle opzioni Target che precedono immediatamente l'opzione Informazioni di transito. Non ci si aspetta che un Target esterno supporti messaggi e opzioni RPL.
Flags: : I 7 bit rimanenti inutilizzati nel campo Flags sono riservati ai flag. Il campo DEVE essere inizializzato a zero dal mittente e DEVE essere ignorato dal ricevitore.
Path Control: : Campo di bit a 8 bit. Il campo Path Control limita il numero di genitori DAO a cui può essere inviato un messaggio DAO che pubblicizza la connettività a una destinazione specifica, oltre a fornire alcune indicazioni di preferenza relativa. Il limite fornisce un certo limite al fan-out complessivo del messaggio DAO nella LLN. L'assegnazione e l'ordinamento dei bit nel Path Control serve anche a comunicare la preferenza. Non tutti questi bit possono essere abilitati in base al PCS nella Configurazione DODAG. Il campo Path Control è diviso in quattro sottocampi che contengono due bit ciascuno: PC1, PC2, PC3 e PC4, come illustrato nella Figura 27. I sottocampi sono ordinati per preferenza, con PC1 che è il più preferito e PC4 il meno preferito. All'interno di un sottocampo, non c'è ordine di preferenza. Raggruppando i genitori (come in ECMP) e ordinandoli, i genitori possono essere associati a bit specifici nel campo Path Control in un modo che comunica la preferenza.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|PC1|PC2|PC3|PC4|
+-+-+-+-+-+-+-+-+
Figure 27: Path Control Preference Subfield Encoding
Path Sequence: : Intero senza segno a 8 bit. Quando un'opzione Target RPL viene emessa dal nodo che possiede il prefisso Target (cioè, in un messaggio DAO), quel nodo imposta la Path Sequence e incrementa la Path Sequence ogni volta che emette un'opzione Target RPL con informazioni aggiornate.
Path Lifetime: : Intero senza segno a 8 bit. La lunghezza del tempo in Lifetime Unit (ottenute dall'opzione Configurazione) in cui il prefisso è valido per la determinazione della rotta. Il periodo inizia quando viene vista una nuova Path Sequence. Un valore di tutti i bit a uno (0xFF) rappresenta l'infinito. Un valore di tutti i bit a zero (0x00) indica una perdita di raggiungibilità. Un messaggio DAO che contiene un'opzione Informazioni di transito con una Path Lifetime di 0x00 per un Target viene indicato come No-Path (per quel Target) in questo documento.
Parent Address (optional): : Indirizzo IPv6 del genitore DODAG del nodo che ha originariamente emesso l'opzione Informazioni di transito. Questo campo potrebbe non essere presente, come in base alla modalità operativa DODAG (Storing o Non-Storing) e indicato dalla lunghezza dell'opzione Informazioni di transito.
I bit non assegnati dell'opzione Informazioni di transito sono riservati. DEVONO essere impostati a zero durante la trasmissione e DEVONO essere ignorati durante la ricezione.
6.7.9. Informazioni sollecitate
L'opzione Informazioni sollecitate PUÒ essere presente nei messaggi DIS e il suo formato è il seguente:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x07 |Opt Length = 19| RPLInstanceID |V|I|D| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version Number |
+-+-+-+-+-+-+-+-+
Figure 28: Format of the Solicited Information Option
L'opzione Informazioni sollecitate viene utilizzata da un nodo per richiedere messaggi DIO da un sottoinsieme di nodi vicini. L'opzione Informazioni sollecitate può specificare un numero di criteri predicati che devono essere soddisfatti da un nodo ricevente. Questo viene utilizzato dal richiedente per limitare il numero di risposte da nodi "non interessanti". Questi predicati influenzano se un nodo reimposta il suo timer Trickle DIO, come descritto nella Sezione 8.3.
L'opzione Informazioni sollecitate contiene flag che indicano quali predicati un nodo dovrebbe controllare quando decide se reimpostare il suo timer Trickle. Un nodo reimposta il suo timer Trickle quando tutti i predicati sono veri. Se un flag è impostato, allora il nodo RPL DEVE controllare il predicato associato. Se un flag è cancellato, allora il nodo RPL NON DEVE controllare il predicato associato. (Se un flag è cancellato, il nodo RPL presume che il predicato associato sia vero.)
Option Type: : 0x07
Option Length: : 19
V: : Il flag 'V' è il predicato Versione. Il predicato Versione è vero se il DODAGVersionNumber del ricevitore corrisponde al Numero di versione richiesto. Se il flag 'V' è cancellato, allora il campo Versione non è valido e il campo Versione DEVE essere impostato a zero durante la trasmissione e ignorato al momento della ricezione.
I: : Il flag 'I' è il predicato InstanceID. Il predicato InstanceID è vero quando l'attuale RPLInstanceID del nodo RPL corrisponde all'RPLInstanceID richiesto. Se il flag 'I' è cancellato, allora il campo RPLInstanceID non è valido e il campo RPLInstanceID DEVE essere impostato a zero durante la trasmissione e ignorato al momento della ricezione.
D: : Il flag 'D' è il predicato DODAGID. Il predicato DODAGID è vero se l'insieme genitore del nodo RPL ha lo stesso DODAGID del campo DODAGID. Se il flag 'D' è cancellato, allora il campo DODAGID non è valido e il campo DODAGID DEVE essere impostato a zero durante la trasmissione e ignorato al momento della ricezione.
Flags: : I 5 bit rimanenti inutilizzati nel campo Flags sono riservati ai flag. Il campo DEVE essere inizializzato a zero dal mittente e DEVE essere ignorato dal ricevitore.
Version Number: : Intero senza segno a 8 bit contenente il valore di DODAGVersionNumber che viene sollecitato quando valido.
RPLInstanceID: : Intero senza segno a 8 bit contenente l'RPLInstanceID che viene sollecitato quando valido.
DODAGID: : Intero senza segno a 128 bit contenente il DODAGID che viene sollecitato quando valido.
I bit non assegnati dell'opzione Informazioni sollecitate sono riservati. DEVONO essere impostati a zero durante la trasmissione e DEVONO essere ignorati durante la ricezione.
6.7.10. Informazioni sul prefisso
L'opzione Informazioni sul prefisso (PIO) PUÒ essere presente nei messaggi DIO e trasporta le informazioni specificate per l'opzione Informazioni sul prefisso IPv6 ND in [RFC4861], [RFC4862] e [RFC6275] per l'uso da parte dei nodi RPL e degli host IPv6. In particolare, un nodo RPL può utilizzare questa opzione allo scopo di configurazione automatica dell'indirizzo senza stato (SLAAC) da un prefisso pubblicizzato da un genitore come specificato in [RFC4862] e pubblicizzare il proprio indirizzo come specificato in [RFC6275]. La radice di un DODAG è autorevole per l'impostazione di tali informazioni. Le informazioni vengono propagate lungo il DODAG invariate, con l'eccezione che un router RPL può sovrascrivere l'ID interfaccia se il flag 'R' è impostato per indicare il suo indirizzo completo nel PIO. Il formato dell'opzione è modificato (Tipo, Lunghezza, Prefisso) per essere trasportato come opzione RPL come segue:
Se l'unico effetto desiderato di un PIO ricevuto in un DIO è fornire l'indirizzo globale del nodo genitore al nodo ricevente, allora il mittente reimposta i bit 'A' e 'L' e imposta il bit 'R'. Al ricevimento, l'RPL non configurerà automaticamente un indirizzo o una rotta connessa dal prefisso [RFC4862]. Come in tutti i casi, quando il bit 'L' non è impostato, il nodo RPL PUÒ includere il prefisso nei PIO che invia ai suoi figli.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x08 |Opt Length = 30| Prefix Length |L|A|R|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: Format of the Prefix Information Option
Il PIO può essere utilizzato per distribuire il prefisso in uso all'interno del DODAG, ad esempio, per la configurazione automatica dell'indirizzo.
[RFC4861] e [RFC6275] dovrebbero essere consultati come riferimento autorevole rispetto al PIO. Le descrizioni dei campi sono trascritte qui per comodità:
Option Type: : 0x08
Option Length: : 30. Si noti che questa lunghezza è espressa in unità di singoli ottetti, a differenza di IPv6 ND.
Prefix Length: : Intero senza segno a 8 bit. Il numero di bit iniziali nel campo Prefisso che sono validi. Il valore varia da 0 a 128. Il campo Lunghezza prefisso fornisce le informazioni necessarie per la determinazione on-link (quando combinato con il flag 'L' nel PIO). Assiste anche con la configurazione automatica dell'indirizzo come specificato in [RFC4862], per la quale potrebbero esserci più restrizioni sulla lunghezza del prefisso.
L: : Flag on-link a 1 bit. Quando impostato, indica che questo prefisso può essere utilizzato per la determinazione on-link. Quando non impostato, l'annuncio non fa alcuna dichiarazione sulle proprietà on-link o off-link del prefisso. In altre parole, se il flag 'L' non è impostato, un nodo RPL NON DEVE concludere che un indirizzo derivato dal prefisso è off-link. Cioè, NON DEVE aggiornare un'indicazione precedente che l'indirizzo è on-link. Un nodo RPL che agisce come router NON DEVE propagare un PIO con il flag 'L' impostato. Un nodo RPL che agisce come router PUÒ propagare un PIO con il flag 'L' non impostato.
A: : Flag di configurazione automatica dell'indirizzo a 1 bit. Quando impostato, indica che questo prefisso può essere utilizzato per la configurazione dell'indirizzo senza stato come specificato in [RFC4862]. Quando entrambi i protocolli (ND RA e RPL DIO) vengono utilizzati per trasportare PIO sullo stesso collegamento, è possibile utilizzarne uno per SLAAC da parte di un nodo RPL. È anche possibile rendere uno dei protocolli non idoneo per l'operazione SLAAC forzando il flag 'A' a 0 per i PIO trasportati in quel protocollo.
R: : Flag indirizzo router a 1 bit. Quando impostato, indica che il campo Prefisso contiene un indirizzo IPv6 completo assegnato al router mittente che può essere utilizzato come genitore in un'opzione target. Il prefisso indicato sono i primi bit di Lunghezza prefisso del campo Prefisso. L'indirizzo IPv6 del router ha lo stesso ambito e si conforma agli stessi valori di durata del prefisso pubblicizzato. Questo uso del campo Prefisso è compatibile con il suo uso nella pubblicità del prefisso stesso, poiché l'annuncio del prefisso utilizza solo i bit iniziali. L'interpretazione di questo bit di flag è quindi indipendente dall'elaborazione richiesta per i bit di flag on-link (L) e configurazione automatica dell'indirizzo (A).
Reserved1: : Campo inutilizzato a 5 bit. DEVE essere inizializzato a zero dal mittente e DEVE essere ignorato dal ricevitore.
Valid Lifetime: : Intero senza segno a 32 bit. La lunghezza del tempo in secondi (rispetto al momento in cui viene inviato il pacchetto) in cui il prefisso è valido allo scopo della determinazione on-link. Un valore di tutti i bit a uno (0xFFFFFFFF) rappresenta l'infinito. La Valid Lifetime è utilizzata anche da [RFC4862].
Preferred Lifetime: : Intero senza segno a 32 bit. La lunghezza del tempo in secondi (rispetto al momento in cui viene inviato il pacchetto) in cui gli indirizzi generati dal prefisso tramite la configurazione automatica dell'indirizzo senza stato rimangono preferiti [RFC4862]. Un valore di tutti i bit a uno (0xFFFFFFFF) rappresenta l'infinito. Vedere [RFC4862]. Si noti che il valore di questo campo NON DEVE superare il campo Valid Lifetime per evitare di preferire indirizzi che non sono più validi.
Reserved2: : Questo campo è inutilizzato. DEVE essere inizializzato a zero dal mittente e DEVE essere ignorato dal ricevitore.
Prefix: : Un indirizzo IPv6 o un prefisso di un indirizzo IPv6. Il campo Lunghezza prefisso contiene il numero di bit iniziali validi nel prefisso. I bit nel prefisso dopo la lunghezza del prefisso sono riservati e DEVONO essere inizializzati a zero dal mittente e ignorati dal ricevitore. Un router NON DOVREBBE inviare un'opzione prefisso per il prefisso link-local e un host DOVREBBE ignorare tale opzione prefisso. Un nodo non-storing DOVREBBE astenersi dal pubblicizzare un prefisso finché non possiede un indirizzo di quel prefisso, e quindi DOVREBBE pubblicizzare il suo indirizzo completo in questo campo, con il flag 'R' impostato. I figli di un nodo che pubblicizza così un indirizzo completo con il flag 'R' impostato possono quindi utilizzare quell'indirizzo per determinare il contenuto del sottocampo Indirizzo genitore DODAG dell'opzione Informazioni di transito.
I bit non assegnati del PIO sono riservati. DEVONO essere impostati a zero durante la trasmissione e DEVONO essere ignorati durante la ricezione.
6.7.11. Descrittore target RPL
L'opzione Target RPL PUÒ essere immediatamente seguita da un descrittore opaco che qualifica quello specifico target.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x09 |Opt Length = 4 | Descriptor
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Descriptor (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: Format of the RPL Target Descriptor Option
L'opzione Descrittore target RPL viene utilizzata per qualificare un target, qualcosa che a volte viene chiamato "tagging".
Al massimo, può esserci un descrittore per target. Il descrittore è impostato dal nodo che inietta il Target nella rete RPL. DEVE essere copiato ma non modificato dai router che propagano il Target verso l'alto lungo il DODAG nei messaggi DAO.
Option Type: : 0x09
Option Length: : 4
Descriptor: : Intero senza segno a 32 bit. Opaco.