6. Message de contrôle ICMPv6 RPL
Ce document définit le message de contrôle RPL, un nouveau message ICMPv6 [RFC4443]. Un message de contrôle RPL est identifié par un code et composé d'une base qui dépend du code (et d'une série d'options).
La plupart des messages de contrôle RPL ont la portée d'un lien. La seule exception concerne les messages DAO / DAO-ACK en mode non-stockage, qui sont échangés à l'aide d'une adresse unicast sur plusieurs sauts et utilisent donc des adresses globales ou locales uniques pour les adresses source et de destination. Pour tous les autres messages de contrôle RPL, l'adresse source est une adresse lien-local, et l'adresse de destination est soit l'adresse multicast de tous les nœuds RPL, soit une adresse unicast lien-local de la destination. L'adresse multicast de tous les nœuds RPL est une nouvelle adresse avec une valeur de ff02::1a.
Conformément à la [RFC4443], le message de contrôle RPL se compose d'un en-tête ICMPv6 suivi d'un corps de message. Le corps du message est composé d'une base de message et éventuellement d'un certain nombre d'options, comme illustré à la figure 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
Le message de contrôle RPL est un message d'information ICMPv6 avec un type de 155.
Le champ Code identifie le type de message de contrôle RPL. Ce document définit des codes pour les types de messages de contrôle RPL suivants (voir la section 20.2)) :
-
0x00 : Sollicitation d'informations DODAG (DIS) (Section 6.2)
-
0x01 : Objet d'informations DODAG (DIO) (Section 6.3)
-
0x02 : Objet de publicité de destination (DAO) (Section 6.4)
-
0x03 : Acquittement d'objet de publicité de destination (DAO-ACK) (Section 6.5)
-
0x80 : Sollicitation d'informations DODAG sécurisée (Section 6.2.2)
-
0x81 : Objet d'informations DODAG sécurisé (Section 6.3.2)
-
0x82 : Objet de publicité de destination sécurisé (Section 6.4.2)
-
0x83 : Acquittement d'objet de publicité de destination sécurisé (Section 6.5.2)
-
0x8A : Vérification de cohérence (Section 6.6)
Si un nœud reçoit un message de contrôle RPL avec un champ Code inconnu, le nœud DOIT rejeter le message sans aucun traitement supplémentaire, PEUT déclencher une alerte de gestion et NE DOIT PAS envoyer de messages en réponse.
La somme de contrôle est calculée comme spécifié dans la [RFC4443]. Elle est mise à zéro pour les opérations de sécurité RPL spécifiées ci-dessous et calculée une fois que le reste du contenu du message RPL, y compris les champs de sécurité, est entièrement défini.
Le bit d'ordre élevé (0x80) du code indique si la sécurité est activée pour le message RPL. Les messages RPL sécurisés ont un format prenant en charge la confidentialité et l'intégrité, illustré à la figure 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
Le reste de cette section décrit les formats de base de message de contrôle RPL actuellement définis, suivis des options de message de contrôle RPL actuellement définies.
6.1. Champs de sécurité RPL
Chaque message RPL a une variante sécurisée. Les variantes sécurisées assurent l'intégrité et la protection contre la relecture ainsi que la confidentialité et la protection contre les retards en option. Parce que la sécurité couvre le message de base ainsi que les options, dans les messages sécurisés, les informations de sécurité se trouvent entre la somme de contrôle et la base, comme indiqué à la figure 7.
Le niveau de sécurité et les algorithmes utilisés sont indiqués dans les messages de protocole comme décrit ci-dessous :
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
Les codes d'authentification de message (MAC) et les signatures assurent l'authentification sur l'ensemble du message de contrôle ICMPv6 RPL non sécurisé, y compris la section Sécurité avec tous les champs définis, mais avec la somme de contrôle ICMPv6 temporairement mise à zéro. Le chiffrement assure la confidentialité du message ICMPv6 RPL sécurisé en commençant au premier octet après la section Sécurité et en continuant jusqu'au dernier octet du paquet. La transformation de sécurité produit un message RPL ICMPv6 sécurisé avec l'inclusion des champs cryptographiques (MAC, signature, etc.). En d'autres termes, la transformation de sécurité elle-même (par exemple, la signature et/ou l'algorithme utilisé) détaillera comment incorporer les champs cryptographiques dans le paquet sécurisé. La section Sécurité elle-même ne porte pas explicitement ces champs cryptographiques. L'utilisation de la section Sécurité est décrite plus en détail dans les sections 19 et 10.
Counter is Time (T): : Si le drapeau Time du compteur est défini, alors le champ Counter est un horodatage. Si le drapeau est effacé, alors le compteur est un compteur incrémentiel. La section 10.5 décrit les détails du drapeau 'T' et du champ Counter.
Reserved: : Champ inutilisé de 7 bits. Le champ DOIT être initialisé à zéro par l'expéditeur et DOIT être ignoré par le récepteur.
Security Algorithm (Algorithm): : Le champ Algorithme de sécurité spécifie le chiffrement, le MAC et le schéma de signature utilisés par le réseau. Les valeurs prises en charge de ce champ sont les suivantes :
+-----------+-------------------+------------------------+
| Algorithm | Encryption/MAC | Signature |
+-----------+-------------------+------------------------+
| 0 | CCM with AES-128 | RSA with SHA-256 |
| 1-255 | Unassigned | Unassigned |
+-----------+-------------------+------------------------+
Figure 9: Security Algorithm (Algorithm) Encoding
La section 10.9 décrit les algorithmes plus en détail.
Key Identifier Mode (KIM): : Le mode d'identificateur de clé est un champ de 2 bits qui indique si la clé utilisée pour la protection des paquets est déterminée implicitement ou explicitement et indique la représentation particulière du champ Identificateur de clé. Le mode d'identificateur de clé est défini sur l'une des valeurs du tableau ci-dessous :
+------+-----+-----------------------------+------------+
| 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
En mode 3 (KIM=11), la présence ou l'absence de la source de clé et de l'identificateur de clé dépend du niveau de sécurité (LVL) décrit ci-dessous. Si le niveau de sécurité indique qu'il y a un chiffrement, alors les champs sont présents ; s'il indique qu'il n'y a pas de chiffrement, alors les champs ne sont pas présents.
Resvd: : Champ inutilisé de 3 bits. Le champ DOIT être initialisé à zéro par l'expéditeur et DOIT être ignoré par le récepteur.
Security Level (LVL): : Le niveau de sécurité est un champ de 3 bits qui indique la protection des paquets fournie. Cette valeur peut être adaptée par paquet et permet différents niveaux d'authenticité des données et, éventuellement, de confidentialité des données. Le champ KIM indique si les signatures sont utilisées et la signification du champ Niveau. Notez que les valeurs attribuées du niveau de sécurité ne sont pas nécessairement ordonnées - une valeur plus élevée de LVL n'équivaut pas nécessairement à une sécurité accrue. Le niveau de sécurité est défini sur l'une des valeurs des tableaux ci-dessous :
+---------------------------+
| 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'attribut MAC indique que le message a un MAC de la longueur spécifiée. L'attribut ENC indique que le message est chiffré. L'attribut Sign indique que le message a une signature de la longueur spécifiée.
Flags: : Champ inutilisé de 8 bits réservé aux drapeaux. Le champ DOIT être initialisé à zéro par l'expéditeur et DOIT être ignoré par le récepteur.
Counter: : Le champ Counter indique la valeur de 4 octets non répétitive utilisée pour construire le mécanisme cryptographique qui met en œuvre la protection des paquets et permet de fournir une sécurité sémantique. Voir la section 10.9.1.
Key Identifier: : Le champ Identificateur de clé indique quelle clé a été utilisée pour protéger le paquet. Ce champ fournit divers niveaux de granularité de la protection des paquets, y compris les clés peer-to-peer, les clés de groupe et les clés de signature. Ce champ est représenté comme indiqué par le champ Mode d'identificateur de clé et est formaté comme suit :
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: : Le champ Source de clé, lorsqu'il est présent, indique l'identificateur logique de l'initiateur d'une clé de groupe. Lorsqu'il est présent, ce champ a une longueur de 8 octets.
Key Index: : Le champ Index de clé, lorsqu'il est présent, permet d'identifier de manière unique différentes clés avec le même initiateur. Il est de la responsabilité de chaque initiateur de clé de s'assurer que les clés activement utilisées qu'il émet ont des index de clé distincts et que tous les index de clé ont une valeur différente de 0x00. La valeur 0x00 est réservée à une clé partagée préinstallée. Lorsqu'il est présent, ce champ a une longueur de 1 octet.
Les bits non attribués de la section Sécurité sont réservés. Ils DOIVENT être mis à zéro lors de la transmission et DOIVENT être ignorés lors de la réception.
6.2. Sollicitation d'informations DODAG (DIS)
Le message de sollicitation d'informations DODAG (DIS) peut être utilisé pour solliciter un objet d'informations DODAG auprès d'un nœud RPL. Son utilisation est analogue à celle d'une sollicitation de routeur telle que spécifiée dans la découverte de voisins IPv6 ; un nœud peut utiliser DIS pour sonder son voisinage à la recherche de DODAG proches. La section 8.3 décrit comment les nœuds répondent à un DIS.
6.2.1. Format de l'objet de 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: : Champ inutilisé de 8 bits réservé aux drapeaux. Le champ DOIT être initialisé à zéro par l'expéditeur et DOIT être ignoré par le récepteur.
Reserved: : Champ inutilisé de 8 bits. Le champ DOIT être initialisé à zéro par l'expéditeur et DOIT être ignoré par le récepteur.
Les bits non attribués de la base DIS sont réservés. Ils DOIVENT être mis à zéro lors de la transmission et DOIVENT être ignorés lors de la réception.
6.2.2. DIS sécurisé
Un message DIS sécurisé suit le format de la figure 7, où le format de base est le message DIS illustré à la figure 13.
6.2.3. Options DIS
Le message DIS PEUT porter des options valides.
Cette spécification permet au message DIS de porter les options suivantes :
- 0x00 Pad1
- 0x01 PadN
- 0x07 Information sollicitée
6.3. Objet d'informations DODAG (DIO)
L'objet d'informations DODAG contient des informations qui permettent à un nœud de découvrir une instance RPL, d'apprendre ses paramètres de configuration, de sélectionner un ensemble parent DODAG et de maintenir le DODAG.
6.3.1. Format de l'objet de 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): : Le drapeau Grounded 'G' indique si le DODAG annoncé peut satisfaire l'objectif défini par l'application. Si le drapeau est défini, le DODAG est ancré (Grounded). Si le drapeau est effacé, le DODAG est flottant (Floating).
Mode of Operation (MOP): : Le champ Mode de fonctionnement (MOP) identifie le mode de fonctionnement de l'instance RPL tel qu'il est administrativement provisionné et distribué par la racine DODAG. Tous les nœuds qui rejoignent le DODAG doivent être en mesure d'honorer le MOP afin de participer pleinement en tant que routeur, sinon ils ne doivent se joindre qu'en tant que feuille. Le MOP est codé comme dans la figure ci-dessous :
+-----+-----------------------------------------------------+
| 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 |
+-----+-----------------------------------------------------+
Une valeur de 0 indique que les messages de publicité de destination sont désactivés et que le DODAG ne maintient que des routes vers le haut.
Figure 15: Mode of Operation (MOP) Encoding
DODAGPreference (Prf): : Un entier non signé de 3 bits qui définit la préférence de la racine de ce DODAG par rapport aux autres racines DODAG au sein de l'instance. DAGPreference va de 0x00 (le moins préféré) à 0x07 (le plus préféré). La valeur par défaut est 0 (le moins préféré). La section 8.2 décrit comment DAGPreference affecte le traitement DIO.
Version Number: : Entier non signé de 8 bits défini par la racine DODAG sur le DODAGVersionNumber. La section 8.2 décrit les règles pour les DODAGVersionNumbers et comment elles affectent le traitement DIO.
Rank: : Entier non signé de 16 bits indiquant le rang DODAG du nœud envoyant le message DIO. La section 8.2 décrit comment le rang est défini et comment il affecte le traitement DIO.
RPLInstanceID: : Champ de 8 bits défini par la racine DODAG qui indique de quelle instance RPL le DODAG fait partie.
Destination Advertisement Trigger Sequence Number (DTSN): : Entier non signé de 8 bits défini par le nœud émettant le message DIO. Le drapeau DTSN (Destination Advertisement Trigger Sequence Number) est utilisé dans le cadre de la procédure de maintien des routes vers le bas. Les détails de ce processus sont décrits à la section 9.
Flags: : Champ inutilisé de 8 bits réservé aux drapeaux. Le champ DOIT être initialisé à zéro par l'expéditeur et DOIT être ignoré par le récepteur.
Reserved: : Champ inutilisé de 8 bits. Le champ DOIT être initialisé à zéro par l'expéditeur et DOIT être ignoré par le récepteur.
DODAGID: : Adresse IPv6 de 128 bits définie par une racine DODAG qui identifie de manière unique un DODAG. Le DODAGID DOIT être une adresse IPv6 routable appartenant à la racine DODAG.
Les bits non attribués de la base DIO sont réservés. Ils DOIVENT être mis à zéro lors de la transmission et DOIVENT être ignorés lors de la réception.
6.3.2. DIO sécurisé
Un message DIO sécurisé suit le format de la figure 7, où le format de base est le message DIO illustré à la figure 14.
6.3.3. Options DIO
Le message DIO PEUT porter des options valides.
Cette spécification permet au message DIO de porter les options suivantes :
- 0x00 Pad1
- 0x01 PadN
- 0x02 Conteneur de métriques DAG
- 0x03 Informations de routage
- 0x04 Configuration DODAG
- 0x08 Informations de préfixe
6.4. Objet de publicité de destination (DAO)
L'objet de publicité de destination (DAO) est utilisé pour propager les informations de destination vers le haut le long du DODAG. En mode stockage, le message DAO est envoyé en unicast par l'enfant au(x) parent(s) sélectionné(s). En mode non-stockage, le message DAO est envoyé en unicast à la racine DODAG. Le message DAO peut éventuellement, sur demande explicite ou erreur, être acquitté par sa destination avec un message d'acquittement de publicité de destination (DAO-ACK) renvoyé à l'expéditeur du DAO.
6.4.1. Format de l'objet de 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: : Champ de 8 bits indiquant l'instance de topologie associée au DODAG, telle qu'apprise à partir du DIO.
K: : Le drapeau 'K' indique que le destinataire doit renvoyer un DAO-ACK. (Voir la section 9.3.)
D: : Le drapeau 'D' indique que le champ DODAGID est présent. Ce drapeau DOIT être défini lorsqu'un RPLInstanceID local est utilisé.
Flags: : Les 6 bits restant inutilisés dans le champ Flags sont réservés aux drapeaux. Le champ DOIT être initialisé à zéro par l'expéditeur et DOIT être ignoré par le récepteur.
Reserved: : Champ inutilisé de 8 bits. Le champ DOIT être initialisé à zéro par l'expéditeur et DOIT être ignoré par le récepteur.
DAOSequence: : Incrémenté à chaque message DAO unique provenant d'un nœud et répété dans le message DAO-ACK.
DODAGID (optional): : Entier non signé de 128 bits défini par une racine DODAG qui identifie de manière unique un DODAG. Ce champ n'est présent que lorsque le drapeau 'D' est défini. Ce champ n'est généralement présent que lorsqu'un RPLInstanceID local est utilisé, afin d'identifier le DODAGID associé au RPLInstanceID. Lorsqu'un RPLInstanceID global est utilisé, ce champ n'a pas besoin d'être présent.
Les bits non attribués de la base DAO sont réservés. Ils DOIVENT être mis à zéro lors de la transmission et DOIVENT être ignorés lors de la réception.
6.4.2. DAO sécurisé
Un message DAO sécurisé suit le format de la figure 7, où le format de base est le message DAO illustré à la figure 16.
6.4.3. Options DAO
Le message DAO PEUT porter des options valides.
Cette spécification permet au message DAO de porter les options suivantes :
- 0x00 Pad1
- 0x01 PadN
- 0x05 Cible RPL
- 0x06 Informations de transit
- 0x09 Descripteur de cible RPL
Un cas particulier du message DAO, appelé No-Path, est utilisé en mode stockage pour effacer l'état de routage vers le bas qui a été provisionné via l'opération DAO. Le No-Path porte une option Cible et une option Informations de transit associée avec une durée de vie de 0x00000000 pour indiquer une perte d'accessibilité à cette Cible.
6.5. Acquittement d'objet de publicité de destination (DAO-ACK)
Le message DAO-ACK est envoyé sous forme de paquet unicast par un destinataire DAO (un parent DAO ou une racine DODAG) en réponse à un message DAO unicast.
6.5.1. Format de l'objet de 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: : Champ de 8 bits indiquant l'instance de topologie associée au DODAG, telle qu'apprise à partir du DIO.
D: : Le drapeau 'D' indique que le champ DODAGID est présent. Cela ne serait généralement défini que lorsqu'un RPLInstanceID local est utilisé.
Reserved: : Le champ de 7 bits, réservé aux drapeaux.
DAOSequence: : Incrémenté à chaque message DAO provenant d'un nœud, et répété dans le DAO-ACK par le destinataire. La DAOSequence est utilisée pour corréler un message DAO et un message DAO ACK et ne doit pas être confondue avec la séquence de chemin de l'option Informations de transit qui est associée à une cible donnée vers le bas du DODAG.
Status: : Indique l'achèvement. Le statut 0 est défini comme une acceptation inconditionnelle dans cette spécification. Les valeurs de statut restantes sont réservées comme codes de rejet. Aucun code de statut de rejet n'est défini dans cette spécification, bien que les codes de statut DOIVENT être alloués selon les directives suivantes dans les spécifications futures :
* 0 : Acceptation inconditionnelle (c'est-à-dire que le nœud recevant le DAO-ACK n'est pas rejeté).
* 1-127 : Pas un rejet pur et simple ; le nœud envoyant le DAO-ACK est prêt à agir en tant que parent, mais il est suggéré au nœud récepteur de trouver et d'utiliser un autre parent à la place.
* 127-255 : Rejet ; le nœud envoyant le DAO-ACK ne veut pas agir en tant que parent.
DODAGID (optional): : Entier non signé de 128 bits défini par une racine DODAG qui identifie de manière unique un DODAG. Ce champ n'est présent que lorsque le drapeau 'D' est défini. En règle générale, ce champ n'est présent que lorsqu'un RPLInstanceID local est utilisé afin d'identifier le DODAGID associé au RPLInstanceID. Lorsqu'un RPLInstanceID global est utilisé, ce champ n'a pas besoin d'être présent.
Les bits non attribués de la base DAO-ACK sont réservés. Ils DOIVENT être mis à zéro lors de la transmission et DOIVENT être ignorés lors de la réception.
6.5.2. DAO-ACK sécurisé
Un message DAO-ACK sécurisé suit le format de la figure 7, où le format de base est le message DAO-ACK illustré à la figure 17.
6.5.3. Options DAO-ACK
Cette spécification ne définit aucune option à porter par le message DAO-ACK.
6.6. Vérification de cohérence (CC)
Le message CC est utilisé pour vérifier les compteurs de messages sécurisés et émettre des défis-réponses. Un message CC DOIT être envoyé en tant que message RPL sécurisé.
6.6.1. Format de l'objet de 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: : Champ de 8 bits indiquant l'instance de topologie associée au DODAG, telle qu'apprise à partir du DIO.
R: : Le drapeau 'R' indique si le message CC est une réponse. Un message avec le drapeau 'R' effacé est une demande ; un message avec le drapeau 'R' défini est une réponse.
Flags: : Les 7 bits restant inutilisés dans le champ Flags sont réservés aux drapeaux. Le champ DOIT être initialisé à zéro par l'expéditeur et DOIT être ignoré par le récepteur.
CC Nonce: : Entier non signé de 16 bits défini par une demande CC. La réponse CC correspondante comprend la même valeur de nonce CC que la demande.
DODAGID: : Champ de 128 bits, contient l'identificateur de la racine DODAG.
Destination Counter: : Valeur entière non signée de 32 bits indiquant l'estimation de l'expéditeur de la valeur actuelle du compteur de sécurité de la destination. Si l'expéditeur n'a pas d'estimation, il DEVRAIT mettre le champ Destination Counter à zéro.
Les bits non attribués de la base CC sont réservés. Ils DOIVENT être mis à zéro lors de la transmission et DOIVENT être ignorés lors de la réception.
La valeur Destination Counter permet aux nœuds nouveaux ou récupérés de se resynchroniser via des échanges de messages CC. Ceci est important pour s'assurer qu'une valeur de compteur n'est pas répétée pour une clé de sécurité donnée, même en cas de récupération de périphériques après une panne ayant créé une perte d'état de compteur. Par exemple, lorsqu'une demande CC ou un autre message RPL est reçu avec un compteur initialisé dans la section Sécurité du message, la fourniture du compteur entrant dans le message de réponse CC permet au nœud demandeur de réinitialiser son compteur sortant à une valeur supérieure à la dernière valeur reçue par le nœud répondant ; le compteur entrant sera également mis à jour à partir de la réponse CC reçue.
6.6.2. Options CC
Cette spécification permet au message CC de porter les options suivantes :
- 0x00 Pad1
- 0x01 PadN
6.7. Options de message de contrôle RPL
6.7.1. Format générique des options de message de contrôle RPL
Les options de message de contrôle RPL suivent toutes ce format :
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: : Identificateur de 8 bits du type d'option. Les valeurs de type d'option sont attribuées par l'IANA (voir la section 20.4.)
Option Length: : Entier non signé de 8 bits, représentant la longueur en octets de l'option, sans compter les champs Type et Longueur d'option.
Option Data: : Un champ de longueur variable qui contient des données spécifiques à l'option.
Lors du traitement d'un message RPL contenant une option pour laquelle la valeur Type d'option n'est pas reconnue par le récepteur, le récepteur DOIT ignorer silencieusement l'option non reconnue et continuer à traiter l'option suivante, en gérant correctement toutes les options restantes dans le message.
Les options de message RPL peuvent avoir des exigences d'alignement. Suivant la convention IPv6, les options avec des exigences d'alignement sont alignées dans un paquet de telle sorte que les valeurs multi-octets dans le champ Données d'option de chaque option tombent sur des limites naturelles (c'est-à-dire que les champs de largeur n octets sont placés à un multiple entier de n octets du début de l'en-tête, pour n = 1, 2, 4 ou 8).
6.7.2. Pad1
L'option Pad1 PEUT être présente dans les messages DIS, DIO, DAO, DAO-ACK et CC, et son format est le suivant :
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type = 0x00 |
+-+-+-+-+-+-+-+-+
Figure 20: Format of the Pad1 Option
L'option Pad1 est utilisée pour insérer un seul octet de remplissage dans le message afin de permettre l'alignement des options. Si plus d'un octet de remplissage est requis, l'option PadN doit être utilisée plutôt que plusieurs options Pad1.
NOTE ! Le format de l'option Pad1 est un cas particulier - il n'a ni champ Longueur d'option ni champ Données d'option.
6.7.3. PadN
L'option PadN PEUT être présente dans les messages DIS, DIO, DAO, DAO-ACK et CC, et son format est le suivant :
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'option PadN est utilisée pour insérer deux octets ou plus de remplissage dans le message afin de permettre l'alignement des options. Les données de l'option PadN DOIVENT être ignorées par le récepteur.
Option Type: : 0x01
Option Length: : Pour N octets de remplissage, où 2 <= N <= 7, le champ Longueur d'option contient la valeur N-2. Une longueur d'option de 0 indique un remplissage total de 2 octets. Une longueur d'option de 5 indique un remplissage total de 7 octets, qui est la taille de remplissage maximale autorisée avec l'option PadN.
Option Data: : Pour N (N > 1) octets de remplissage, les données d'option sont constituées de N-2 octets de valeur zéro.
6.7.4. Conteneur de métriques DAG
L'option Conteneur de métriques DAG PEUT être présente dans les messages DIO ou DAO, et son format est le suivant :
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
Le conteneur de métriques DAG est utilisé pour signaler des métriques le long du DODAG. Le conteneur de métriques DAG peut contenir un certain nombre de métriques et de contraintes discrètes de nœud, de lien et de chemin agrégé spécifiées dans [RFC6551] selon le choix de l'implémenteur.
Le conteneur de métriques DAG PEUT apparaître plus d'une fois dans le même message de contrôle RPL, par exemple, pour s'adapter à un cas d'utilisation où les données de métrique sont supérieures à 256 octets. Plus d'informations sont dans [RFC6551].
Le traitement et la propagation du conteneur de métriques DAG sont régis par des fonctions de politique spécifiques à l'implémentation.
Option Type: : 0x02
Option Length: : Le champ Longueur d'option contient la longueur en octets des données de métrique.
Metric Data: : L'ordre, le contenu et le codage des données du conteneur de métriques DAG sont tels que spécifiés dans [RFC6551].
6.7.5. Informations de routage
L'option Informations de routage (RIO) PEUT être présente dans les messages DIO, et elle porte les mêmes informations que le RIO de découverte de voisins IPv6 (ND) tel que défini dans [RFC4191]. La racine d'un DODAG fait autorité pour définir ces informations et les informations sont inchangées lors de leur propagation vers le bas du DODAG. Un routeur RPL peut trivialement les transformer en une option ND pour les annoncer dans ses propres RA afin qu'un nœud attaché au routeur RPL finisse par utiliser le DODAG pour lequel la racine a la meilleure préférence pour la destination d'un paquet. En plus de la sémantique ND existante, il est possible pour une fonction objectif d'utiliser ces informations pour favoriser un DODAG dont la racine est la plus préférée pour une destination spécifique. Le format de l'option est légèrement modifié (Type, Longueur, Préfixe) afin d'être porté comme une option RPL comme suit :
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
Le RIO est utilisé pour indiquer que la connectivité au préfixe de destination spécifié est disponible à partir de la racine DODAG.
Dans le cas où un message de contrôle RPL peut avoir besoin de spécifier la connectivité à plus d'une destination, le RIO peut être répété.
[RFC4191] doit être consulté comme référence faisant autorité en ce qui concerne le RIO. Les descriptions des champs sont transcrites ici pour plus de commodité :
Option Type: : 0x03
Option Length: : Variable, longueur de l'option en octets à l'exclusion des champs Type et Longueur. Notez que cette longueur est exprimée en unités d'octets uniques, contrairement à IPv6 ND.
Prefix Length: : Entier non signé de 8 bits. Le nombre de bits de tête dans le préfixe qui sont valides. La valeur va de 0 à 128. Le champ Préfixe a le nombre d'octets déduit du champ Longueur d'option, qui doit être au moins la Longueur du préfixe. Notez que dans RPL, cela signifie que le champ Préfixe peut avoir des longueurs autres que 0, 8 ou 16.
Prf: : Entier signé de 2 bits. La préférence de route indique s'il faut préférer le routeur associé à ce préfixe par rapport aux autres, lorsque plusieurs préfixes identiques (pour différents routeurs) ont été reçus. Si la valeur Réservé (10) est reçue, le RIO DOIT être ignoré. Selon [RFC4191], la valeur Réservé (10) NE DOIT PAS être envoyée. ([RFC4191] restreint la Préférence à seulement trois valeurs pour renforcer le fait que ce n'est pas une métrique.)
Resvd: : Deux champs inutilisés de 3 bits. Ils DOIVENT être initialisés à zéro par l'expéditeur et DOIVENT être ignorés par le récepteur.
Route Lifetime: : Entier non signé de 32 bits. La durée en secondes (par rapport au moment où le paquet est envoyé) pendant laquelle le préfixe est valide pour la détermination de la route. Une valeur de tous les bits à un (0xFFFFFFFF) représente l'infini.
Prefix: : Champ de longueur variable contenant une adresse IP ou un préfixe d'une adresse IPv6. Le champ Longueur du préfixe contient le nombre de bits de tête valides dans le préfixe. Les bits dans le préfixe après la longueur du préfixe (le cas échéant) sont réservés et DOIVENT être initialisés à zéro par l'expéditeur et ignorés par le récepteur. Notez que dans RPL, ce champ peut avoir des longueurs autres que 0, 8 ou 16.
Les bits non attribués du RIO sont réservés. Ils DOIVENT être mis à zéro lors de la transmission et DOIVENT être ignorés lors de la réception.
6.7.6. Configuration DODAG
L'option Configuration DODAG PEUT être présente dans les messages DIO, et son format est le suivant :
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'option Configuration DODAG est utilisée pour distribuer les informations de configuration pour le fonctionnement DODAG via le DODAG.
Les informations communiquées dans cette option sont généralement statiques et immuables au sein du DODAG, il n'est donc pas nécessaire de les inclure dans chaque DIO. Ces informations sont configurées à la racine DODAG et distribuées dans tout le DODAG avec l'option Configuration DODAG. Les nœuds autres que la racine DODAG NE DOIVENT PAS modifier ces informations lors de la propagation de l'option Configuration DODAG. Cette option PEUT être incluse occasionnellement par la racine DODAG (tel que déterminé par la racine DODAG), et DOIT être incluse en réponse à une demande unicast, par exemple un message unicast de sollicitation d'informations DODAG (DIS).
Option Type: : 0x04
Option Length: : 14
Flags: : Les 4 bits restant inutilisés dans le champ Flags sont réservés aux drapeaux. Le champ DOIT être initialisé à zéro par l'expéditeur et DOIT être ignoré par le récepteur.
Authentication Enabled (A): : Drapeau de 1 bit décrivant le mode de sécurité du réseau. Le bit décrit si un nœud doit s'authentifier auprès d'une autorité clé avant de rejoindre le réseau en tant que routeur. Si le DIO n'est pas un DIO sécurisé, le bit 'A' DOIT être zéro.
Path Control Size (PCS): : Entier non signé de 3 bits utilisé pour configurer le nombre de bits pouvant être alloués au champ Path Control (voir la section 9.9). Notez que lorsque PCS est consulté pour déterminer la largeur du champ Path Control, une valeur de 1 est ajoutée, c'est-à-dire qu'une valeur PCS de 0 entraîne 1 bit actif dans le champ Path Control. La valeur par défaut de PCS est DEFAULT_PATH_CONTROL_SIZE.
DIOIntervalDoublings: : Entier non signé de 8 bits utilisé pour configurer Imax de la minuterie Trickle DIO (voir la section 8.3.1). La valeur par défaut de DIOIntervalDoublings est DEFAULT_DIO_INTERVAL_DOUBLINGS.
DIOIntervalMin: : Entier non signé de 8 bits utilisé pour configurer Imin de la minuterie Trickle DIO (voir la section 8.3.1). La valeur par défaut de DIOIntervalMin est DEFAULT_DIO_INTERVAL_MIN.
DIORedundancyConstant: : Entier non signé de 8 bits utilisé pour configurer k de la minuterie Trickle DIO (voir la section 8.3.1). La valeur par défaut de DIORedundancyConstant est DEFAULT_DIO_REDUNDANCY_CONSTANT.
MaxRankIncrease: : Entier non signé de 16 bits utilisé pour configurer DAGMaxRankIncrease, l'augmentation autorisée du rang à l'appui de la réparation locale. Si DAGMaxRankIncrease est 0, alors ce mécanisme est désactivé.
MinHopRankIncrease: : Entier non signé de 16 bits utilisé pour configurer MinHopRankIncrease comme décrit à la section 3.5.1. La valeur par défaut de MinHopRankInc est DEFAULT_MIN_HOP_RANK_INCREASE.
Objective Code Point (OCP): : Entier non signé de 16 bits. Le champ OCP identifie l'OF et est géré par l'IANA.
Reserved: : Champ inutilisé de 7 bits. Le champ DOIT être initialisé à zéro par l'expéditeur et DOIT être ignoré par le récepteur.
Default Lifetime: : Entier non signé de 8 bits. C'est la durée de vie qui est utilisée par défaut pour toutes les routes RPL. Elle est exprimée en unités d'unités de durée de vie, par exemple, la durée de vie par défaut en secondes est (Durée de vie par défaut) * (Unité de durée de vie).
Lifetime Unit: : Entier non signé de 16 bits. Fournit l'unité en secondes qui est utilisée pour exprimer les durées de vie des routes dans RPL. Pour les réseaux très stables, cela peut être des heures à des jours.
6.7.7. Cible RPL
L'option Cible RPL PEUT être présente dans les messages DAO, et son format est le suivant :
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'option Cible RPL est utilisée pour indiquer une adresse IPv6 cible, un préfixe ou un groupe multicast qui est accessible ou interrogé le long du DODAG. Dans un DAO, l'option Cible RPL indique l'accessibilité.
Une option Cible RPL PEUT éventuellement être associée à une option Descripteur de cible RPL (Figure 30) qui qualifie la cible.
Un ensemble d'une ou plusieurs options Informations de transit (Section 6.7.8) PEUT suivre directement un ensemble d'une ou plusieurs options Cible dans un message DAO (où chaque option Cible PEUT être associée à une option Descripteur de cible RPL comme ci-dessus). La structure du message DAO, détaillant comment les options Cible sont utilisées conjointement avec les options Informations de transit, est décrite plus en détail à la section 9.4.
L'option Cible RPL peut être répétée si nécessaire pour indiquer plusieurs cibles.
Option Type: : 0x05
Option Length: : Variable, longueur de l'option en octets à l'exclusion des champs Type et Longueur.
Flags: : Champ inutilisé de 8 bits réservé aux drapeaux. Le champ DOIT être initialisé à zéro par l'expéditeur et DOIT être ignoré par le récepteur.
Prefix Length: : Entier non signé de 8 bits. Nombre de bits de tête valides dans le préfixe IPv6.
Target Prefix: : Champ de longueur variable identifiant une adresse de destination IPv6, un préfixe ou un groupe multicast. Le champ Longueur du préfixe contient le nombre de bits de tête valides dans le préfixe. Les bits dans le préfixe après la longueur du préfixe (le cas échéant) sont réservés et DOIVENT être mis à zéro lors de la transmission et DOIVENT être ignorés lors de la réception.
6.7.8. Informations de transit
L'option Informations de transit PEUT être présente dans les messages DAO, et son format est le suivant :
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'option Informations de transit est utilisée par un nœud pour indiquer des attributs pour un chemin vers une ou plusieurs destinations. Les destinations sont indiquées par une ou plusieurs options Cible qui précèdent immédiatement l'option (ou les options) Informations de transit.
L'option Informations de transit peut être utilisée par un nœud pour indiquer ses parents DODAG à un ancêtre qui collecte des informations de routage DODAG, généralement, dans le but de construire des routes source. En mode de fonctionnement non-stockage, cet ancêtre sera la racine DODAG, et cette option est portée par le message DAO. En mode de fonctionnement stockage, le sous-champ Adresse parent DODAG n'est pas nécessaire, car le message DAO est envoyé directement au parent. La longueur de l'option est utilisée pour déterminer si le sous-champ Adresse parent DODAG est présent ou non.
Un nœud non-stockage qui a plusieurs parents DAO PEUT inclure une option Informations de transit pour chaque parent DAO dans le cadre de l'opération de publicité de destination non-stockage. Le nœud peut distribuer les bits du champ Contrôle de chemin entre différents groupes de parents DAO afin de signaler une préférence parmi les parents. Cette préférence peut influencer la décision de la racine DODAG lors de la sélection parmi les parents/chemins alternatifs pour la construction de routes vers le bas.
Une ou plusieurs options Informations de transit DOIVENT être précédées d'une ou plusieurs options Cible RPL. De cette manière, l'option Cible RPL indique le nœud enfant et l'option (ou les options) Informations de transit énumère les parents DODAG. La structure du message DAO, détaillant plus en détail comment les options Cible sont utilisées conjointement avec les options Informations de transit, est décrite plus en détail à la section 9.4.
Un nœud non-stockage typique utilisera plusieurs options Informations de transit et enverra le message DAO ainsi formé directement à la racine. Un nœud de stockage typique utilisera une option Informations de transit sans champ parent et enverra le message DAO ainsi formé, avec des ajustements supplémentaires, au Contrôle de chemin comme détaillé plus loin, à un ou plusieurs parents.
Par exemple, dans un mode de fonctionnement non-stockage, notons Tgt(T) une option Cible pour une Cible T. Notons Trnst(P) une option Informations de transit contenant une adresse parent P. Considérons le cas d'un nœud non-stockage N qui annonce les cibles auto-détenues N1 et N2 et a des parents P1, P2 et P3. Dans ce cas, le message DAO devrait contenir la séquence ((Tgt(N1), Tgt(N2)), (Trnst(P1), Trnst(P2), Trnst(P3))), de sorte que le groupe d'options Cible {N1, N2} est décrit par les options Informations de transit comme ayant les parents {P1, P2, P3}. Le nœud non-stockage adresserait alors ce message DAO directement à la racine DODAG et transférerait ce message DAO via l'un des parents DODAG : P1, P2 ou P3.
Option Type: : 0x06
Option Length: : Variable, selon que le sous-champ Adresse parent DODAG est présent ou non.
External (E): : Drapeau de 1 bit. Le drapeau 'E' est défini pour indiquer que le routeur parent redistribue des cibles externes dans le réseau RPL. Une Cible externe est une Cible qui a été apprise via un autre protocole. Les cibles externes sont répertoriées dans les options Cible qui précèdent immédiatement l'option Informations de transit. Une Cible externe ne devrait pas prendre en charge les messages et options RPL.
Flags: : Les 7 bits restant inutilisés dans le champ Flags sont réservés aux drapeaux. Le champ DOIT être initialisé à zéro par l'expéditeur et DOIT être ignoré par le récepteur.
Path Control: : Champ de bits de 8 bits. Le champ Contrôle de chemin limite le nombre de parents DAO auxquels un message DAO annonçant la connectivité à une destination spécifique peut être envoyé, tout en fournissant une indication de préférence relative. La limite fournit une certaine limite sur la sortance globale des messages DAO dans le LLN. L'affectation et l'ordre des bits dans le Contrôle de chemin servent également à communiquer la préférence. Tous ces bits ne peuvent pas être activés selon le PCS dans la Configuration DODAG. Le champ Contrôle de chemin est divisé en quatre sous-champs qui contiennent deux bits chacun : PC1, PC2, PC3 et PC4, comme illustré à la figure 27. Les sous-champs sont classés par préférence, PC1 étant le plus préféré et PC4 étant le moins préféré. Au sein d'un sous-champ, il n'y a pas d'ordre de préférence. En regroupant les parents (comme dans ECMP) et en les ordonnant, les parents peuvent être associés à des bits spécifiques dans le champ Contrôle de chemin d'une manière qui communique la préférence.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|PC1|PC2|PC3|PC4|
+-+-+-+-+-+-+-+-+
Figure 27: Path Control Preference Subfield Encoding
Path Sequence: : Entier non signé de 8 bits. Lorsqu'une option Cible RPL est émise par le nœud propriétaire du préfixe Cible (c'est-à-dire dans un message DAO), ce nœud définit la Séquence de chemin et incrémente la Séquence de chemin chaque fois qu'il émet une option Cible RPL avec des informations mises à jour.
Path Lifetime: : Entier non signé de 8 bits. La durée en Unités de durée de vie (obtenues à partir de l'option Configuration) pendant laquelle le préfixe est valide pour la détermination de la route. La période commence lorsqu'une nouvelle Séquence de chemin est vue. Une valeur de tous les bits à un (0xFF) représente l'infini. Une valeur de tous les bits à zéro (0x00) indique une perte d'accessibilité. Un message DAO qui contient une option Informations de transit avec une Durée de vie de chemin de 0x00 pour une Cible est appelé No-Path (pour cette Cible) dans ce document.
Parent Address (optional): : Adresse IPv6 du parent DODAG du nœud ayant émis à l'origine l'option Informations de transit. Ce champ peut ne pas être présent, comme selon le Mode de fonctionnement DODAG (Stockage ou Non-Stockage) et indiqué par la longueur de l'option Informations de transit.
Les bits non attribués de l'option Informations de transit sont réservés. Ils DOIVENT être mis à zéro lors de la transmission et DOIVENT être ignorés lors de la réception.
6.7.9. Information sollicitée
L'option Information sollicitée PEUT être présente dans les messages DIS, et son format est le suivant :
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'option Information sollicitée est utilisée par un nœud pour demander des messages DIO à un sous-ensemble de nœuds voisins. L'option Information sollicitée peut spécifier un certain nombre de critères de prédicat à faire correspondre par un nœud récepteur. Ceci est utilisé par le demandeur pour limiter le nombre de réponses des nœuds "non intéressants". Ces prédicats affectent si un nœud réinitialise sa minuterie Trickle DIO, comme décrit à la section 8.3.
L'option Information sollicitée contient des drapeaux qui indiquent quels prédicats un nœud doit vérifier lorsqu'il décide de réinitialiser sa minuterie Trickle. Un nœud réinitialise sa minuterie Trickle lorsque tous les prédicats sont vrais. Si un drapeau est défini, alors le nœud RPL DOIT vérifier le prédicat associé. Si un drapeau est effacé, alors le nœud RPL NE DOIT PAS vérifier le prédicat associé. (Si un drapeau est effacé, le nœud RPL suppose que le prédicat associé est vrai.)
Option Type: : 0x07
Option Length: : 19
V: : Le drapeau 'V' est le prédicat Version. Le prédicat Version est vrai si le DODAGVersionNumber du récepteur correspond au Numéro de version demandé. Si le drapeau 'V' est effacé, alors le champ Version n'est pas valide et le champ Version DOIT être mis à zéro lors de la transmission et ignoré lors de la réception.
I: : Le drapeau 'I' est le prédicat InstanceID. Le prédicat InstanceID est vrai lorsque le RPLInstanceID actuel du nœud RPL correspond au RPLInstanceID demandé. Si le drapeau 'I' est effacé, alors le champ RPLInstanceID n'est pas valide et le champ RPLInstanceID DOIT être mis à zéro lors de la transmission et ignoré lors de la réception.
D: : Le drapeau 'D' est le prédicat DODAGID. Le prédicat DODAGID est vrai si l'ensemble parent du nœud RPL a le même DODAGID que le champ DODAGID. Si le drapeau 'D' est effacé, alors le champ DODAGID n'est pas valide et le champ DODAGID DOIT être mis à zéro lors de la transmission et ignoré lors de la réception.
Flags: : Les 5 bits restant inutilisés dans le champ Flags sont réservés aux drapeaux. Le champ DOIT être initialisé à zéro par l'expéditeur et DOIT être ignoré par le récepteur.
Version Number: : Entier non signé de 8 bits contenant la valeur de DODAGVersionNumber qui est sollicitée lorsqu'elle est valide.
RPLInstanceID: : Entier non signé de 8 bits contenant le RPLInstanceID qui est sollicité lorsqu'il est valide.
DODAGID: : Entier non signé de 128 bits contenant le DODAGID qui est sollicité lorsqu'il est valide.
Les bits non attribués de l'option Information sollicitée sont réservés. Ils DOIVENT être mis à zéro lors de la transmission et DOIVENT être ignorés lors de la réception.
6.7.10. Informations de préfixe
L'option Informations de préfixe (PIO) PEUT être présente dans les messages DIO, et porte les informations spécifiées pour l'option Informations de préfixe IPv6 ND dans [RFC4861], [RFC4862] et [RFC6275] pour une utilisation par les nœuds RPL et les hôtes IPv6. En particulier, un nœud RPL peut utiliser cette option aux fins de l'autoconfiguration d'adresse sans état (SLAAC) à partir d'un préfixe annoncé par un parent comme spécifié dans [RFC4862], et annoncer sa propre adresse comme spécifié dans [RFC6275]. La racine d'un DODAG fait autorité pour définir ces informations. Les informations sont propagées vers le bas du DODAG sans modification, à l'exception qu'un routeur RPL peut écraser l'ID d'interface si le drapeau 'R' est défini pour indiquer son adresse complète dans le PIO. Le format de l'option est modifié (Type, Longueur, Préfixe) afin d'être porté comme une option RPL comme suit :
Si le seul effet souhaité d'un PIO reçu dans un DIO est de fournir l'adresse globale du nœud parent au nœud récepteur, alors l'expéditeur réinitialise les bits 'A' et 'L' et définit le bit 'R'. À la réception, le RPL n'autoconfigurera pas une adresse ou une route connectée à partir du préfixe [RFC4862]. Comme dans tous les cas, lorsque le bit 'L' n'est pas défini, le nœud RPL PEUT inclure le préfixe dans les PIO qu'il envoie à ses enfants.
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
Le PIO peut être utilisé pour distribuer le préfixe utilisé à l'intérieur du DODAG, par exemple, pour l'autoconfiguration d'adresse.
[RFC4861] et [RFC6275] doivent être consultés comme référence faisant autorité en ce qui concerne le PIO. Les descriptions des champs sont transcrites ici pour plus de commodité :
Option Type: : 0x08
Option Length: : 30. Notez que cette longueur est exprimée en unités d'octets uniques, contrairement à IPv6 ND.
Prefix Length: : Entier non signé de 8 bits. Le nombre de bits de tête dans le champ Préfixe qui sont valides. La valeur va de 0 à 128. Le champ Longueur du préfixe fournit les informations nécessaires pour la détermination sur le lien (lorsqu'il est combiné avec le drapeau 'L' dans le PIO). Il aide également à l'autoconfiguration d'adresse comme spécifié dans [RFC4862], pour laquelle il peut y avoir plus de restrictions sur la longueur du préfixe.
L: : Drapeau sur le lien de 1 bit. Lorsqu'il est défini, il indique que ce préfixe peut être utilisé pour la détermination sur le lien. Lorsqu'il n'est pas défini, l'annonce ne fait aucune déclaration sur les propriétés sur le lien ou hors lien du préfixe. En d'autres termes, si le drapeau 'L' n'est pas défini, un nœud RPL NE DOIT PAS conclure qu'une adresse dérivée du préfixe est hors lien. C'est-à-dire qu'il NE DOIT PAS mettre à jour une indication précédente selon laquelle l'adresse est sur le lien. Un nœud RPL agissant en tant que routeur NE DOIT PAS propager un PIO avec le drapeau 'L' défini. Un nœud RPL agissant en tant que routeur PEUT propager un PIO avec le drapeau 'L' non défini.
A: : Drapeau de configuration d'adresse autonome de 1 bit. Lorsqu'il est défini, il indique que ce préfixe peut être utilisé pour la configuration d'adresse sans état comme spécifié dans [RFC4862]. Lorsque les deux protocoles (ND RA et RPL DIO) sont utilisés pour porter des PIO sur le même lien, il est possible d'utiliser l'un ou l'autre pour SLAAC par un nœud RPL. Il est également possible de rendre l'un ou l'autre protocole inéligible pour l'opération SLAAC en forçant le drapeau 'A' à 0 pour les PIO portés dans ce protocole.
R: : Drapeau d'adresse de routeur de 1 bit. Lorsqu'il est défini, il indique que le champ Préfixe contient une adresse IPv6 complète attribuée au routeur émetteur qui peut être utilisée comme parent dans une option cible. Le préfixe indiqué est les premiers bits de Longueur du préfixe du champ Préfixe. L'adresse IPv6 du routeur a la même portée et est conforme aux mêmes valeurs de durée de vie que le préfixe annoncé. Cette utilisation du champ Préfixe est compatible avec son utilisation dans l'annonce du préfixe lui-même, puisque l'annonce de préfixe n'utilise que les bits de tête. L'interprétation de ce bit de drapeau est donc indépendante du traitement requis pour les bits de drapeau sur le lien (L) et de configuration d'adresse autonome (A).
Reserved1: : Champ inutilisé de 5 bits. Il DOIT être initialisé à zéro par l'expéditeur et DOIT être ignoré par le récepteur.
Valid Lifetime: : Entier non signé de 32 bits. La durée en secondes (par rapport au moment où le paquet est envoyé) pendant laquelle le préfixe est valide aux fins de la détermination sur le lien. Une valeur de tous les bits à un (0xFFFFFFFF) représente l'infini. La durée de vie valide est également utilisée par [RFC4862].
Preferred Lifetime: : Entier non signé de 32 bits. La durée en secondes (par rapport au moment où le paquet est envoyé) pendant laquelle les adresses générées à partir du préfixe via l'autoconfiguration d'adresse sans état restent préférées [RFC4862]. Une valeur de tous les bits à un (0xFFFFFFFF) représente l'infini. Voir [RFC4862]. Notez que la valeur de ce champ NE DOIT PAS dépasser le champ Durée de vie valide pour éviter de préférer des adresses qui ne sont plus valides.
Reserved2: : Ce champ est inutilisé. Il DOIT être initialisé à zéro par l'expéditeur et DOIT être ignoré par le récepteur.
Prefix: : Une adresse IPv6 ou un préfixe d'une adresse IPv6. Le champ Longueur du préfixe contient le nombre de bits de tête valides dans le préfixe. Les bits dans le préfixe après la longueur du préfixe sont réservés et DOIVENT être initialisés à zéro par l'expéditeur et ignorés par le récepteur. Un routeur NE DEVRAIT PAS envoyer d'option de préfixe pour le préfixe lien-local, et un hôte DEVRAIT ignorer une telle option de préfixe. Un nœud non-stockage DEVRAIT s'abstenir d'annoncer un préfixe jusqu'à ce qu'il possède une adresse de ce préfixe, et ensuite il DEVRAIT annoncer son adresse complète dans ce champ, avec le drapeau 'R' défini. Les enfants d'un nœud qui annonce ainsi une adresse complète avec le drapeau 'R' défini peuvent alors utiliser cette adresse pour déterminer le contenu du sous-champ Adresse parent DODAG de l'option Informations de transit.
Les bits non attribués du PIO sont réservés. Ils DOIVENT être mis à zéro lors de la transmission et DOIVENT être ignorés lors de la réception.
6.7.11. Descripteur de cible RPL
L'option Cible RPL PEUT être immédiatement suivie d'un descripteur opaque qui qualifie cette cible spécifique.
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'option Descripteur de cible RPL est utilisée pour qualifier une cible, ce qui est parfois appelé "étiquetage".
Au plus, il peut y avoir un descripteur par cible. Le descripteur est défini par le nœud qui injecte la Cible dans le réseau RPL. Il DOIT être copié mais non modifié par les routeurs qui propagent la Cible vers le haut du DODAG dans les messages DAO.
Option Type: : 0x09
Option Length: : 4
Descriptor: : Entier non signé de 32 bits. Opaque.