6. ICMPv6 RPL-Steuernachricht
Dieses Dokument definiert die RPL-Steuernachricht, eine neue ICMPv6 [RFC4443] Nachricht. Eine RPL-Steuernachricht wird durch einen Code identifiziert und besteht aus einer Basis, die vom Code abhängt (und einer Reihe von Optionen).
Die meisten RPL-Steuernachrichten haben den Geltungsbereich eines Links. Die einzige Ausnahme sind die DAO / DAO-ACK-Nachrichten im Non-Storing-Modus, die unter Verwendung einer Unicast-Adresse über mehrere Hops ausgetauscht werden und daher globale oder Unique-Local-Adressen sowohl für die Quell- als auch für die Zieladressen verwenden. Für alle anderen RPL-Steuernachrichten ist die Quelladresse eine Link-Local-Adresse, und die Zieladresse ist entweder die All-RPL-Nodes-Multicast-Adresse oder eine Link-Local-Unicast-Adresse des Ziels. Die All-RPL-Nodes-Multicast-Adresse ist eine neue Adresse mit einem Wert von ff02::1a.
In Übereinstimmung mit [RFC4443] besteht die RPL-Steuernachricht aus einem ICMPv6-Header, gefolgt von einem Nachrichtenkörper. Der Nachrichtenkörper besteht aus einer Nachrichtenbasis und möglicherweise einer Anzahl von Optionen, wie in Abbildung 6 dargestellt.
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
Die RPL-Steuernachricht ist eine ICMPv6-Informationsnachricht mit einem Typ von 155.
Das Code-Feld identifiziert den Typ der RPL-Steuernachricht. Dieses Dokument definiert Codes für die folgenden RPL-Steuernachrichtentypen (siehe Abschnitt 20.2)):
-
0x00: DODAG-Informationsanforderung (DIS) (Abschnitt 6.2)
-
0x01: DODAG-Informationsobjekt (DIO) (Abschnitt 6.3)
-
0x02: Zielankündigungsobjekt (DAO) (Abschnitt 6.4)
-
0x03: Zielankündigungsobjekt-Bestätigung (DAO-ACK) (Abschnitt 6.5)
-
0x80: Sichere DODAG-Informationsanforderung (Abschnitt 6.2.2)
-
0x81: Sicheres DODAG-Informationsobjekt (Abschnitt 6.3.2)
-
0x82: Sicheres Zielankündigungsobjekt (Abschnitt 6.4.2)
-
0x83: Sichere Zielankündigungsobjekt-Bestätigung (Abschnitt 6.5.2)
-
0x8A: Konsistenzprüfung (Abschnitt 6.6)
Wenn ein Knoten eine RPL-Steuernachricht mit einem unbekannten Code-Feld empfängt, MUSS der Knoten die Nachricht ohne weitere Verarbeitung verwerfen, KANN einen Management-Alarm auslösen und DARF KEINE Nachrichten als Antwort senden.
Die Prüfsumme wird wie in [RFC4443] angegeben berechnet. Sie wird für die unten angegebenen RPL-Sicherheitsoperationen auf Null gesetzt und berechnet, sobald der Rest des Inhalts der RPL-Nachricht einschließlich der Sicherheitsfelder festgelegt ist.
Das höherwertige Bit (0x80) des Codes gibt an, ob für die RPL-Nachricht Sicherheit aktiviert ist. Sichere RPL-Nachrichten haben ein Format zur Unterstützung von Vertraulichkeit und Integrität, wie in Abbildung 7 dargestellt.
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
Der Rest dieses Abschnitts beschreibt die derzeit definierten Basisformate für RPL-Steuernachrichten, gefolgt von den derzeit definierten RPL-Steuernachrichtenoptionen.
6.1. RPL-Sicherheitsfelder
Jede RPL-Nachricht hat eine sichere Variante. Die sicheren Varianten bieten Integrität und Wiedereinspielschutz sowie optional Vertraulichkeit und Verzögerungsschutz. Da die Sicherheit sowohl die Basisnachricht als auch die Optionen abdeckt, liegen die Sicherheitsinformationen in gesicherten Nachrichten zwischen der Prüfsumme und der Basis, wie in Abbildung 7 gezeigt.
Die Sicherheitsstufe und die verwendeten Algorithmen werden in den Protokollnachrichten wie unten beschrieben angegeben:
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
Message Authentication Codes (MACs) und Signaturen bieten Authentifizierung über die gesamte ungesicherte ICMPv6 RPL-Steuernachricht, einschließlich des Sicherheitsabschnitts mit allen definierten Feldern, jedoch mit der vorübergehend auf Null gesetzten ICMPv6-Prüfsumme. Verschlüsselung bietet Vertraulichkeit der gesicherten RPL ICMPv6-Nachricht beginnend beim ersten Byte nach dem Sicherheitsabschnitt und bis zum letzten Byte des Pakets. Die Sicherheitstransformation ergibt eine gesicherte ICMPv6 RPL-Nachricht unter Einbeziehung der kryptografischen Felder (MAC, Signatur usw.). Mit anderen Worten, die Sicherheitstransformation selbst (z. B. die verwendete Signatur und/oder der Algorithmus) beschreibt detailliert, wie die kryptografischen Felder in das gesicherte Paket integriert werden. Der Sicherheitsabschnitt selbst trägt diese kryptografischen Felder nicht explizit. Die Verwendung des Sicherheitsabschnitts wird in den Abschnitten 19 und 10 näher erläutert.
Counter is Time (T): : Wenn das Zeit-Flag des Zählers gesetzt ist, ist das Counter-Feld ein Zeitstempel. Wenn das Flag gelöscht ist, ist der Zähler ein inkrementierender Zähler. Abschnitt 10.5 beschreibt die Details des 'T'-Flags und des Counter-Feldes.
Reserved: : 7-Bit unbenutztes Feld. Das Feld MUSS vom Absender auf Null initialisiert und vom Empfänger ignoriert werden.
Security Algorithm (Algorithm): : Das Sicherheitsalgorithmus-Feld gibt das Verschlüsselungs-, MAC- und Signaturschema an, das das Netzwerk verwendet. Unterstützte Werte dieses Feldes sind wie folgt:
+-----------+-------------------+------------------------+
| Algorithm | Encryption/MAC | Signature |
+-----------+-------------------+------------------------+
| 0 | CCM with AES-128 | RSA with SHA-256 |
| 1-255 | Unassigned | Unassigned |
+-----------+-------------------+------------------------+
Figure 9: Security Algorithm (Algorithm) Encoding
Abschnitt 10.9 beschreibt die Algorithmen detaillierter.
Key Identifier Mode (KIM): : Der Schlüsselkennungsmodus ist ein 2-Bit-Feld, das angibt, ob der für den Paketschutz verwendete Schlüssel implizit oder explizit bestimmt wird, und die spezielle Darstellung des Schlüsselkennungsfeldes angibt. Der Schlüsselkennungsmodus wird auf einen der Werte aus der folgenden Tabelle gesetzt:
+------+-----+-----------------------------+------------+
| 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
Im Modus 3 (KIM=11) hängt das Vorhandensein oder Fehlen der Schlüsselquelle und der Schlüsselkennung von der unten beschriebenen Sicherheitsstufe (LVL) ab. Wenn die Sicherheitsstufe angibt, dass eine Verschlüsselung vorliegt, sind die Felder vorhanden; wenn sie angibt, dass keine Verschlüsselung vorliegt, sind die Felder nicht vorhanden.
Resvd: : 3-Bit unbenutztes Feld. Das Feld MUSS vom Absender auf Null initialisiert und vom Empfänger ignoriert werden.
Security Level (LVL): : Die Sicherheitsstufe ist ein 3-Bit-Feld, das den bereitgestellten Paketschutz angibt. Dieser Wert kann pro Paket angepasst werden und ermöglicht unterschiedliche Stufen der Datenauthentizität und optional der Datenvertraulichkeit. Das KIM-Feld gibt an, ob Signaturen verwendet werden, und die Bedeutung des Level-Feldes. Beachten Sie, dass die zugewiesenen Werte der Sicherheitsstufe nicht unbedingt geordnet sind – ein höherer Wert von LVL bedeutet nicht unbedingt erhöhte Sicherheit. Die Sicherheitsstufe wird auf einen der Werte in den folgenden Tabellen gesetzt:
+---------------------------+
| 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
Das MAC-Attribut gibt an, dass die Nachricht einen MAC der angegebenen Länge hat. Das ENC-Attribut gibt an, dass die Nachricht verschlüsselt ist. Das Sign-Attribut gibt an, dass die Nachricht eine Signatur der angegebenen Länge hat.
Flags: : 8-Bit unbenutztes Feld, reserviert für Flags. Das Feld MUSS vom Absender auf Null initialisiert und vom Empfänger ignoriert werden.
Counter: : Das Counter-Feld gibt den nicht wiederholenden 4-Oktett-Wert an, der verwendet wird, um den kryptografischen Mechanismus zu konstruieren, der den Paketschutz implementiert und die Bereitstellung semantischer Sicherheit ermöglicht. Siehe Abschnitt 10.9.1.
Key Identifier: : Das Key Identifier-Feld gibt an, welcher Schlüssel zum Schutz des Pakets verwendet wurde. Dieses Feld bietet verschiedene Granularitätsstufen des Paketschutzes, einschließlich Peer-to-Peer-Schlüsseln, Gruppenschlüsseln und Signaturschlüsseln. Dieses Feld wird wie durch das Key Identifier Mode-Feld angegeben dargestellt und ist wie folgt formatiert:
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: : Das Key Source-Feld gibt, wenn vorhanden, den logischen Identifikator des Urhebers eines Gruppenschlüssels an. Wenn vorhanden, ist dieses Feld 8 Bytes lang.
Key Index: : Das Key Index-Feld ermöglicht, wenn vorhanden, die eindeutige Identifizierung verschiedener Schlüssel mit demselben Urheber. Es liegt in der Verantwortung jedes Schlüsselurhebers sicherzustellen, dass aktiv verwendete Schlüssel, die er ausgibt, unterschiedliche Schlüsselindizes haben und dass alle Schlüsselindizes einen Wert ungleich 0x00 haben. Der Wert 0x00 ist für einen vorinstallierten, gemeinsamen Schlüssel reserviert. Wenn vorhanden, ist dieses Feld 1 Byte lang.
Nicht zugewiesene Bits des Sicherheitsabschnitts sind reserviert. Sie MÜSSEN bei der Übertragung auf Null gesetzt und beim Empfang ignoriert werden.
6.2. DODAG-Informationsanforderung (DIS)
Die DODAG-Informationsanforderung (DIS)-Nachricht kann verwendet werden, um ein DODAG-Informationsobjekt von einem RPL-Knoten anzufordern. Ihre Verwendung ist analog zu der einer Router-Anforderung, wie in IPv6 Neighbor Discovery spezifiziert; ein Knoten kann DIS verwenden, um seine Nachbarschaft nach nahegelegenen DODAGs zu sondieren. Abschnitt 8.3 beschreibt, wie Knoten auf eine DIS reagieren.
6.2.1. Format des DIS-Basisobjekts
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: : 8-Bit unbenutztes Feld, reserviert für Flags. Das Feld MUSS vom Absender auf Null initialisiert und vom Empfänger ignoriert werden.
Reserved: : 8-Bit unbenutztes Feld. Das Feld MUSS vom Absender auf Null initialisiert und vom Empfänger ignoriert werden.
Nicht zugewiesene Bits der DIS-Basis sind reserviert. Sie MÜSSEN bei der Übertragung auf Null gesetzt und beim Empfang ignoriert werden.
6.2.2. Sichere DIS
Eine sichere DIS-Nachricht folgt dem Format in Abbildung 7, wobei das Basisformat die in Abbildung 13 gezeigte DIS-Nachricht ist.
6.2.3. DIS-Optionen
Die DIS-Nachricht KANN gültige Optionen enthalten.
Diese Spezifikation erlaubt, dass die DIS-Nachricht die folgenden Optionen enthält:
- 0x00 Pad1
- 0x01 PadN
- 0x07 Angeforderte Informationen
6.3. DODAG-Informationsobjekt (DIO)
Das DODAG-Informationsobjekt enthält Informationen, die es einem Knoten ermöglichen, eine RPL-Instanz zu entdecken, ihre Konfigurationsparameter zu lernen, einen DODAG-Elternsatz auszuwählen und den DODAG zu warten.
6.3.1. Format des DIO-Basisobjekts
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): : Das Grounded 'G'-Flag gibt an, ob der angekündigte DODAG das anwendungsdefinierte Ziel erfüllen kann. Wenn das Flag gesetzt ist, ist der DODAG geerdet (Grounded). Wenn das Flag gelöscht ist, ist der DODAG schwebend (Floating).
Mode of Operation (MOP): : Das Mode of Operation (MOP)-Feld identifiziert den Betriebsmodus der RPL-Instanz, wie administrativ an der DODAG-Wurzel bereitgestellt und verteilt. Alle Knoten, die dem DODAG beitreten, müssen in der Lage sein, den MOP zu honorieren, um vollständig als Router teilzunehmen, oder sie müssen nur als Leaf beitreten. MOP ist wie in der folgenden Abbildung codiert:
+-----+-----------------------------------------------------+
| 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 |
+-----+-----------------------------------------------------+
Ein Wert von 0 gibt an, dass Zielankündigungsnachrichten deaktiviert sind und der DODAG nur Aufwärtsrouten unterhält.
Figure 15: Mode of Operation (MOP) Encoding
DODAGPreference (Prf): : Eine 3-Bit-Ganzzahl ohne Vorzeichen, die definiert, wie bevorzugt die Wurzel dieses DODAG im Vergleich zu anderen DODAG-Wurzeln innerhalb der Instanz ist. DAGPreference reicht von 0x00 (am wenigsten bevorzugt) bis 0x07 (am meisten bevorzugt). Der Standardwert ist 0 (am wenigsten bevorzugt). Abschnitt 8.2 beschreibt, wie DAGPreference die DIO-Verarbeitung beeinflusst.
Version Number: : 8-Bit-Ganzzahl ohne Vorzeichen, die von der DODAG-Wurzel auf die DODAGVersionNumber gesetzt wird. Abschnitt 8.2 beschreibt die Regeln für DODAGVersionNumbers und wie sie die DIO-Verarbeitung beeinflussen.
Rank: : 16-Bit-Ganzzahl ohne Vorzeichen, die den DODAG-Rang des Knotens angibt, der die DIO-Nachricht sendet. Abschnitt 8.2 beschreibt, wie der Rang festgelegt wird und wie er die DIO-Verarbeitung beeinflusst.
RPLInstanceID: : 8-Bit-Feld, das von der DODAG-Wurzel gesetzt wird und angibt, zu welcher RPL-Instanz der DODAG gehört.
Destination Advertisement Trigger Sequence Number (DTSN): : 8-Bit-Ganzzahl ohne Vorzeichen, die von dem Knoten gesetzt wird, der die DIO-Nachricht ausgibt. Das Flag Destination Advertisement Trigger Sequence Number (DTSN) wird als Teil des Verfahrens zur Wartung von Abwärtsrouten verwendet. Die Details dieses Prozesses werden in Abschnitt 9 beschrieben.
Flags: : 8-Bit unbenutztes Feld, reserviert für Flags. Das Feld MUSS vom Absender auf Null initialisiert und vom Empfänger ignoriert werden.
Reserved: : 8-Bit unbenutztes Feld. Das Feld MUSS vom Absender auf Null initialisiert und vom Empfänger ignoriert werden.
DODAGID: : 128-Bit-IPv6-Adresse, die von einer DODAG-Wurzel gesetzt wird und einen DODAG eindeutig identifiziert. Die DODAGID MUSS eine routingfähige IPv6-Adresse sein, die zur DODAG-Wurzel gehört.
Nicht zugewiesene Bits der DIO-Basis sind reserviert. Sie MÜSSEN bei der Übertragung auf Null gesetzt und beim Empfang ignoriert werden.
6.3.2. Sicheres DIO
Eine sichere DIO-Nachricht folgt dem Format in Abbildung 7, wobei das Basisformat die in Abbildung 14 gezeigte DIO-Nachricht ist.
6.3.3. DIO-Optionen
Die DIO-Nachricht KANN gültige Optionen enthalten.
Diese Spezifikation erlaubt, dass die DIO-Nachricht die folgenden Optionen enthält:
- 0x00 Pad1
- 0x01 PadN
- 0x02 DAG-Metrik-Container
- 0x03 Routing-Informationen
- 0x04 DODAG-Konfiguration
- 0x08 Präfix-Informationen
6.4. Zielankündigungsobjekt (DAO)
Das Zielankündigungsobjekt (DAO) wird verwendet, um Zielinformationen entlang des DODAG nach oben zu propagieren. Im Storing-Modus wird die DAO-Nachricht vom Kind an den/die ausgewählten Elternteil(e) per Unicast gesendet. Im Non-Storing-Modus wird die DAO-Nachricht per Unicast an die DODAG-Wurzel gesendet. Die DAO-Nachricht kann optional, auf explizite Anforderung oder bei Fehler, von ihrem Ziel mit einer Zielankündigungsbestätigung (DAO-ACK)-Nachricht an den Absender des DAO bestätigt werden.
6.4.1. Format des DAO-Basisobjekts
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: : 8-Bit-Feld, das die Topologieinstanz angibt, die dem DODAG zugeordnet ist, wie aus dem DIO gelernt.
K: : Das 'K'-Flag gibt an, dass vom Empfänger erwartet wird, ein DAO-ACK zurückzusenden. (Siehe Abschnitt 9.3.)
D: : Das 'D'-Flag gibt an, dass das DODAGID-Feld vorhanden ist. Dieses Flag MUSS gesetzt sein, wenn eine lokale RPLInstanceID verwendet wird.
Flags: : Die 6 Bits, die im Flags-Feld unbenutzt bleiben, sind für Flags reserviert. Das Feld MUSS vom Absender auf Null initialisiert und vom Empfänger ignoriert werden.
Reserved: : 8-Bit unbenutztes Feld. Das Feld MUSS vom Absender auf Null initialisiert und vom Empfänger ignoriert werden.
DAOSequence: : Wird bei jeder eindeutigen DAO-Nachricht von einem Knoten inkrementiert und in der DAO-ACK-Nachricht wiederholt.
DODAGID (optional): : 128-Bit-Ganzzahl ohne Vorzeichen, die von einer DODAG-Wurzel gesetzt wird und einen DODAG eindeutig identifiziert. Dieses Feld ist nur vorhanden, wenn das 'D'-Flag gesetzt ist. Dieses Feld ist typischerweise nur vorhanden, wenn eine lokale RPLInstanceID verwendet wird, um die DODAGID zu identifizieren, die der RPLInstanceID zugeordnet ist. Wenn eine globale RPLInstanceID verwendet wird, muss dieses Feld nicht vorhanden sein.
Nicht zugewiesene Bits der DAO-Basis sind reserviert. Sie MÜSSEN bei der Übertragung auf Null gesetzt und beim Empfang ignoriert werden.
6.4.2. Sicheres DAO
Eine sichere DAO-Nachricht folgt dem Format in Abbildung 7, wobei das Basisformat die in Abbildung 16 gezeigte DAO-Nachricht ist.
6.4.3. DAO-Optionen
Die DAO-Nachricht KANN gültige Optionen enthalten.
Diese Spezifikation erlaubt, dass die DAO-Nachricht die folgenden Optionen enthält:
- 0x00 Pad1
- 0x01 PadN
- 0x05 RPL-Ziel
- 0x06 Transitinformationen
- 0x09 RPL-Zieldeskriptor
Ein Sonderfall der DAO-Nachricht, als No-Path bezeichnet, wird im Storing-Modus verwendet, um den Abwärts-Routing-Zustand zu löschen, der durch den DAO-Betrieb bereitgestellt wurde. Der No-Path trägt eine Target-Option und eine zugehörige Transit-Information-Option mit einer Lebensdauer von 0x00000000, um einen Verlust der Erreichbarkeit zu diesem Target anzuzeigen.
6.5. Zielankündigungsobjekt-Bestätigung (DAO-ACK)
Die DAO-ACK-Nachricht wird als Unicast-Paket von einem DAO-Empfänger (einem DAO-Elternteil oder einer DODAG-Wurzel) als Antwort auf eine Unicast-DAO-Nachricht gesendet.
6.5.1. Format des DAO-ACK-Basisobjekts
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: : 8-Bit-Feld, das die Topologieinstanz angibt, die dem DODAG zugeordnet ist, wie aus dem DIO gelernt.
D: : Das 'D'-Flag gibt an, dass das DODAGID-Feld vorhanden ist. Dies würde typischerweise nur gesetzt werden, wenn eine lokale RPLInstanceID verwendet wird.
Reserved: : Das 7-Bit-Feld, reserviert für Flags.
DAOSequence: : Wird bei jeder DAO-Nachricht von einem Knoten inkrementiert und im DAO-ACK vom Empfänger wiederholt. Die DAOSequence wird verwendet, um eine DAO-Nachricht und eine DAO-ACK-Nachricht zu korrelieren, und darf nicht mit der Pfadsequenz der Transit-Information-Option verwechselt werden, die einem bestimmten Ziel im DODAG zugeordnet ist.
Status: : Gibt den Abschluss an. Status 0 ist in dieser Spezifikation als uneingeschränkte Akzeptanz definiert. Die verbleibenden Statuswerte sind als Ablehnungscodes reserviert. In dieser Spezifikation sind keine Ablehnungsstatuscodes definiert, obwohl Statuscodes gemäß den folgenden Richtlinien in zukünftigen Spezifikationen zugewiesen werden SOLLTEN:
* 0: Uneingeschränkte Akzeptanz (d. h. der Knoten, der das DAO-ACK empfängt, wird nicht abgelehnt).
* 1-127: Keine direkte Ablehnung; der Knoten, der das DAO-ACK sendet, ist bereit, als Elternteil zu fungieren, aber dem empfangenden Knoten wird empfohlen, stattdessen einen alternativen Elternteil zu finden und zu verwenden.
* 127-255: Ablehnung; der Knoten, der das DAO-ACK sendet, ist nicht bereit, als Elternteil zu fungieren.
DODAGID (optional): : 128-Bit-Ganzzahl ohne Vorzeichen, die von einer DODAG-Wurzel gesetzt wird und einen DODAG eindeutig identifiziert. Dieses Feld ist nur vorhanden, wenn das 'D'-Flag gesetzt ist. Typischerweise ist dieses Feld nur vorhanden, wenn eine lokale RPLInstanceID verwendet wird, um die DODAGID zu identifizieren, die der RPLInstanceID zugeordnet ist. Wenn eine globale RPLInstanceID verwendet wird, muss dieses Feld nicht vorhanden sein.
Nicht zugewiesene Bits der DAO-ACK-Basis sind reserviert. Sie MÜSSEN bei der Übertragung auf Null gesetzt und beim Empfang ignoriert werden.
6.5.2. Sicheres DAO-ACK
Eine sichere DAO-ACK-Nachricht folgt dem Format in Abbildung 7, wobei das Basisformat die in Abbildung 17 gezeigte DAO-ACK-Nachricht ist.
6.5.3. DAO-ACK-Optionen
Diese Spezifikation definiert keine Optionen, die von der DAO-ACK-Nachricht getragen werden.
6.6. Konsistenzprüfung (CC)
Die CC-Nachricht wird verwendet, um sichere Nachrichtenzähler zu überprüfen und Challenge-Responses auszugeben. Eine CC-Nachricht MUSS als gesicherte RPL-Nachricht gesendet werden.
6.6.1. Format des CC-Basisobjekts
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: : 8-Bit-Feld, das die Topologieinstanz angibt, die dem DODAG zugeordnet ist, wie aus dem DIO gelernt.
R: : Das 'R'-Flag gibt an, ob die CC-Nachricht eine Antwort ist. Eine Nachricht mit gelöschtem 'R'-Flag ist eine Anforderung; eine Nachricht mit gesetztem 'R'-Flag ist eine Antwort.
Flags: : Die 7 Bits, die im Flags-Feld unbenutzt bleiben, sind für Flags reserviert. Das Feld MUSS vom Absender auf Null initialisiert und vom Empfänger ignoriert werden.
CC Nonce: : 16-Bit-Ganzzahl ohne Vorzeichen, die von einer CC-Anforderung gesetzt wird. Die entsprechende CC-Antwort enthält denselben CC-Nonce-Wert wie die Anforderung.
DODAGID: : 128-Bit-Feld, enthält den Identifikator der DODAG-Wurzel.
Destination Counter: : 32-Bit-Ganzzahlwert ohne Vorzeichen, der die Schätzung des Absenders über den aktuellen Sicherheitszählerwert des Ziels angibt. Wenn der Absender keine Schätzung hat, SOLLTE er das Destination Counter-Feld auf Null setzen.
Nicht zugewiesene Bits der CC-Basis sind reserviert. Sie MÜSSEN bei der Übertragung auf Null gesetzt und beim Empfang ignoriert werden.
Der Destination Counter-Wert ermöglicht es neuen oder wiederhergestellten Knoten, sich durch CC-Nachrichtenaustausch neu zu synchronisieren. Dies ist wichtig, um sicherzustellen, dass ein Zählerwert für einen bestimmten Sicherheitsschlüssel nicht wiederholt wird, selbst im Falle von Geräten, die sich von einem Fehler erholen, der einen Verlust des Zählerstatus verursacht hat. Wenn beispielsweise eine CC-Anforderung oder eine andere RPL-Nachricht mit einem initialisierten Zähler innerhalb des Nachrichtensicherheitsabschnitts empfangen wird, ermöglicht die Bereitstellung des eingehenden Zählers innerhalb der CC-Antwortnachricht dem anfordernden Knoten, seinen ausgehenden Zähler auf einen Wert zurückzusetzen, der größer ist als der letzte vom antwortenden Knoten empfangene Wert; der eingehende Zähler wird auch aus der empfangenen CC-Antwort aktualisiert.
6.6.2. CC-Optionen
Diese Spezifikation erlaubt, dass die CC-Nachricht die folgenden Optionen enthält:
- 0x00 Pad1
- 0x01 PadN
6.7. RPL-Steuernachrichtenoptionen
6.7.1. Allgemeines Format der RPL-Steuernachrichtenoption
RPL-Steuernachrichtenoptionen folgen alle diesem 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: : 8-Bit-Identifikator des Typs der Option. Die Option Type-Werte werden von der IANA zugewiesen (siehe Abschnitt 20.4.)
Option Length: : 8-Bit-Ganzzahl ohne Vorzeichen, die die Länge der Option in Oktetten darstellt, ohne die Felder Option Type und Length.
Option Data: : Ein Feld variabler Länge, das optionsspezifische Daten enthält.
Bei der Verarbeitung einer RPL-Nachricht, die eine Option enthält, für die der Option Type-Wert vom Empfänger nicht erkannt wird, MUSS der Empfänger die nicht erkannte Option stillschweigend ignorieren und mit der Verarbeitung der folgenden Option fortfahren, wobei alle verbleibenden Optionen in der Nachricht korrekt behandelt werden.
RPL-Nachrichtenoptionen können Ausrichtungsanforderungen haben. Nach der Konvention in IPv6 werden Optionen mit Ausrichtungsanforderungen in einem Paket so ausgerichtet, dass Multi-Oktett-Werte innerhalb des Option Data-Feldes jeder Option auf natürliche Grenzen fallen (d. h. Felder der Breite n Oktette werden an einem ganzzahligen Vielfachen von n Oktetten vom Beginn des Headers platziert, für n = 1, 2, 4 oder 8).
6.7.2. Pad1
Die Pad1-Option KANN in DIS-, DIO-, DAO-, DAO-ACK- und CC-Nachrichten vorhanden sein, und ihr Format ist wie folgt:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type = 0x00 |
+-+-+-+-+-+-+-+-+
Figure 20: Format of the Pad1 Option
Die Pad1-Option wird verwendet, um ein einzelnes Oktett Füllmaterial in die Nachricht einzufügen, um die Ausrichtung der Optionen zu ermöglichen. Wenn mehr als ein Oktett Füllmaterial erforderlich ist, sollte die PadN-Option anstelle mehrerer Pad1-Optionen verwendet werden.
HINWEIS! Das Format der Pad1-Option ist ein Sonderfall – sie hat weder Option Length- noch Option Data-Felder.
6.7.3. PadN
Die PadN-Option KANN in DIS-, DIO-, DAO-, DAO-ACK- und CC-Nachrichten vorhanden sein, und ihr Format ist wie folgt:
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
Die PadN-Option wird verwendet, um zwei oder mehr Oktette Füllmaterial in die Nachricht einzufügen, um die Ausrichtung der Optionen zu ermöglichen. PadN-Optionsdaten MÜSSEN vom Empfänger ignoriert werden.
Option Type: : 0x01
Option Length: : Für N Oktette Füllmaterial, wobei 2 <= N <= 7, enthält das Option Length-Feld den Wert N-2. Eine Option Length von 0 gibt eine Gesamtfüllung von 2 Oktetten an. Eine Option Length von 5 gibt eine Gesamtfüllung von 7 Oktetten an, was die maximale Füllgröße ist, die mit der PadN-Option zulässig ist.
Option Data: : Für N (N > 1) Oktette Füllmaterial bestehen die Option Data aus N-2 nullwertigen Oktetten.
6.7.4. DAG-Metrik-Container
Die DAG-Metrik-Container-Option KANN in DIO- oder DAO-Nachrichten vorhanden sein, und ihr Format ist wie folgt:
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
Der DAG-Metrik-Container wird verwendet, um Metriken entlang des DODAG zu melden. Der DAG-Metrik-Container kann eine Reihe von diskreten Knoten-, Link- und aggregierten Pfadmetriken und Einschränkungen enthalten, die in [RFC6551] spezifiziert sind, wie vom Implementierer gewählt.
Der DAG-Metrik-Container KANN mehr als einmal in derselben RPL-Steuernachricht erscheinen, zum Beispiel, um einen Anwendungsfall zu berücksichtigen, bei dem die Metric Data länger als 256 Bytes sind. Weitere Informationen finden sich in [RFC6551].
Die Verarbeitung und Verbreitung des DAG-Metrik-Containers wird durch implementierungsspezifische Richtlinienfunktionen geregelt.
Option Type: : 0x02
Option Length: : Das Option Length-Feld enthält die Länge der Metric Data in Oktetten.
Metric Data: : Die Reihenfolge, der Inhalt und die Codierung der DAG-Metrik-Container-Daten sind wie in [RFC6551] spezifiziert.
6.7.5. Routing-Informationen
Die Routing-Informations-Option (RIO) KANN in DIO-Nachrichten vorhanden sein und trägt dieselben Informationen wie die IPv6 Neighbor Discovery (ND) RIO, wie in [RFC4191] definiert. Die Wurzel eines DODAG ist maßgeblich für das Setzen dieser Informationen, und die Informationen bleiben unverändert, wenn sie den DODAG hinunter propagiert werden. Ein RPL-Router kann sie trivial in eine ND-Option zurückwandeln, um sie in seinen eigenen RAs anzukündigen, so dass ein an den RPL-Router angeschlossener Knoten den DODAG verwendet, für den die Wurzel die beste Präferenz für das Ziel eines Pakets hat. Zusätzlich zur bestehenden ND-Semantik ist es für eine Zielfunktion möglich, diese Informationen zu verwenden, um einen DODAG zu bevorzugen, dessen Wurzel für ein bestimmtes Ziel am meisten bevorzugt wird. Das Format der Option wird leicht modifiziert (Typ, Länge, Präfix), um als RPL-Option wie folgt getragen zu werden:
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
Die RIO wird verwendet, um anzugeben, dass Konnektivität zum angegebenen Zielpräfix von der DODAG-Wurzel verfügbar ist.
Für den Fall, dass eine RPL-Steuernachricht Konnektivität zu mehr als einem Ziel angeben muss, kann die RIO wiederholt werden.
[RFC4191] sollte als maßgebliche Referenz in Bezug auf die RIO konsultiert werden. Die Feldbeschreibungen werden hier der Bequemlichkeit halber transkribiert:
Option Type: : 0x03
Option Length: : Variabel, Länge der Option in Oktetten ohne die Felder Type und Length. Beachten Sie, dass diese Länge im Gegensatz zu IPv6 ND in Einheiten von einzelnen Oktetten ausgedrückt wird.
Prefix Length: : 8-Bit-Ganzzahl ohne Vorzeichen. Die Anzahl der führenden Bits im Präfix, die gültig sind. Der Wert reicht von 0 bis 128. Das Prefix-Feld hat die Anzahl der Bytes, die aus dem Option Length-Feld abgeleitet wird, die mindestens die Prefix Length sein muss. Beachten Sie, dass dies in RPL bedeutet, dass das Prefix-Feld Längen ungleich 0, 8 oder 16 haben kann.
Prf: : 2-Bit-Ganzzahl mit Vorzeichen. Die Routenpräferenz gibt an, ob der diesem Präfix zugeordnete Router gegenüber anderen bevorzugt werden soll, wenn mehrere identische Präfixe (für verschiedene Router) empfangen wurden. Wenn der Reserviert (10)-Wert empfangen wird, MUSS die RIO ignoriert werden. Gemäß [RFC4191] DARF der Reserviert (10)-Wert NICHT gesendet werden. ([RFC4191] beschränkt die Präferenz auf nur drei Werte, um zu unterstreichen, dass es sich nicht um eine Metrik handelt.)
Resvd: : Zwei 3-Bit unbenutzte Felder. Sie MÜSSEN vom Absender auf Null initialisiert und vom Empfänger ignoriert werden.
Route Lifetime: : 32-Bit-Ganzzahl ohne Vorzeichen. Die Zeitdauer in Sekunden (relativ zur Zeit, zu der das Paket gesendet wird), die das Präfix für die Routenbestimmung gültig ist. Ein Wert von nur Eins-Bits (0xFFFFFFFF) stellt Unendlichkeit dar.
Prefix: : Feld variabler Länge, das eine IP-Adresse oder ein Präfix einer IPv6-Adresse enthält. Das Prefix Length-Feld enthält die Anzahl der gültigen führenden Bits im Präfix. Die Bits im Präfix nach der Präfixlänge (falls vorhanden) sind reserviert und MÜSSEN vom Absender auf Null initialisiert und vom Empfänger ignoriert werden. Beachten Sie, dass dieses Feld in RPL Längen ungleich 0, 8 oder 16 haben kann.
Nicht zugewiesene Bits der RIO sind reserviert. Sie MÜSSEN bei der Übertragung auf Null gesetzt und beim Empfang ignoriert werden.
6.7.6. DODAG-Konfiguration
Die DODAG-Konfigurations-Option KANN in DIO-Nachrichten vorhanden sein, und ihr Format ist wie folgt:
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
Die DODAG-Konfigurations-Option wird verwendet, um Konfigurationsinformationen für den DODAG-Betrieb über den DODAG zu verteilen.
Die in dieser Option kommunizierten Informationen sind im Allgemeinen statisch und unveränderlich innerhalb des DODAG, daher ist es nicht notwendig, sie in jedes DIO aufzunehmen. Diese Informationen werden an der DODAG-Wurzel konfiguriert und im gesamten DODAG mit der DODAG-Konfigurations-Option verteilt. Andere Knoten als die DODAG-Wurzel DÜRFEN diese Informationen NICHT ändern, wenn sie die DODAG-Konfigurations-Option propagieren. Diese Option KANN gelegentlich von der DODAG-Wurzel aufgenommen werden (wie von der DODAG-Wurzel bestimmt) und MUSS als Antwort auf eine Unicast-Anforderung, z. B. eine Unicast-DODAG-Informationsanforderung (DIS)-Nachricht, aufgenommen werden.
Option Type: : 0x04
Option Length: : 14
Flags: : Die 4 Bits, die im Flags-Feld unbenutzt bleiben, sind für Flags reserviert. Das Feld MUSS vom Absender auf Null initialisiert und vom Empfänger ignoriert werden.
Authentication Enabled (A): : 1-Bit-Flag, das den Sicherheitsmodus des Netzwerks beschreibt. Das Bit beschreibt, ob sich ein Knoten bei einer Schlüsselautorität authentifizieren muss, bevor er als Router dem Netzwerk beitritt. Wenn das DIO kein sicheres DIO ist, MUSS das 'A'-Bit Null sein.
Path Control Size (PCS): : 3-Bit-Ganzzahl ohne Vorzeichen, die verwendet wird, um die Anzahl der Bits zu konfigurieren, die dem Path Control-Feld zugewiesen werden können (siehe Abschnitt 9.9). Beachten Sie, dass bei der Konsultation von PCS zur Bestimmung der Breite des Path Control-Feldes ein Wert von 1 addiert wird, d. h. ein PCS-Wert von 0 führt zu 1 aktiven Bit im Path Control-Feld. Der Standardwert von PCS ist DEFAULT_PATH_CONTROL_SIZE.
DIOIntervalDoublings: : 8-Bit-Ganzzahl ohne Vorzeichen, die verwendet wird, um Imax des DIO-Trickle-Timers zu konfigurieren (siehe Abschnitt 8.3.1). Der Standardwert von DIOIntervalDoublings ist DEFAULT_DIO_INTERVAL_DOUBLINGS.
DIOIntervalMin: : 8-Bit-Ganzzahl ohne Vorzeichen, die verwendet wird, um Imin des DIO-Trickle-Timers zu konfigurieren (siehe Abschnitt 8.3.1). Der Standardwert von DIOIntervalMin ist DEFAULT_DIO_INTERVAL_MIN.
DIORedundancyConstant: : 8-Bit-Ganzzahl ohne Vorzeichen, die verwendet wird, um k des DIO-Trickle-Timers zu konfigurieren (siehe Abschnitt 8.3.1). Der Standardwert von DIORedundancyConstant ist DEFAULT_DIO_REDUNDANCY_CONSTANT.
MaxRankIncrease: : 16-Bit-Ganzzahl ohne Vorzeichen, die verwendet wird, um DAGMaxRankIncrease zu konfigurieren, die zulässige Erhöhung des Rangs zur Unterstützung der lokalen Reparatur. Wenn DAGMaxRankIncrease 0 ist, ist dieser Mechanismus deaktiviert.
MinHopRankIncrease: : 16-Bit-Ganzzahl ohne Vorzeichen, die verwendet wird, um MinHopRankIncrease wie in Abschnitt 3.5.1 beschrieben zu konfigurieren. Der Standardwert von MinHopRankInc ist DEFAULT_MIN_HOP_RANK_INCREASE.
Objective Code Point (OCP): : 16-Bit-Ganzzahl ohne Vorzeichen. Das OCP-Feld identifiziert die OF und wird von der IANA verwaltet.
Reserved: : 7-Bit unbenutztes Feld. Das Feld MUSS vom Absender auf Null initialisiert und vom Empfänger ignoriert werden.
Default Lifetime: : 8-Bit-Ganzzahl ohne Vorzeichen. Dies ist die Lebensdauer, die als Standard für alle RPL-Routen verwendet wird. Sie wird in Einheiten von Lifetime Units ausgedrückt, z. B. ist die Standardlebensdauer in Sekunden (Default Lifetime) * (Lifetime Unit).
Lifetime Unit: : 16-Bit-Ganzzahl ohne Vorzeichen. Liefert die Einheit in Sekunden, die verwendet wird, um Routenlebensdauern in RPL auszudrücken. Für sehr stabile Netzwerke können dies Stunden bis Tage sein.
6.7.7. RPL-Ziel
Die RPL-Target-Option KANN in DAO-Nachrichten vorhanden sein, und ihr Format ist wie folgt:
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
Die RPL-Target-Option wird verwendet, um eine Ziel-IPv6-Adresse, ein Präfix oder eine Multicast-Gruppe anzugeben, die entlang des DODAG erreichbar ist oder abgefragt wird. In einem DAO zeigt die RPL-Target-Option Erreichbarkeit an.
Eine RPL-Target-Option KANN optional mit einer RPL-Target-Descriptor-Option (Abbildung 30) gepaart werden, die das Ziel qualifiziert.
Eine Reihe von einer oder mehreren Transit-Information-Optionen (Abschnitt 6.7.8) KANN direkt auf eine Reihe von einer oder mehreren Target-Optionen in einer DAO-Nachricht folgen (wobei jede Target-Option wie oben mit einer RPL-Target-Descriptor-Option gepaart sein KANN). Die Struktur der DAO-Nachricht, die detailliert beschreibt, wie Target-Optionen in Verbindung mit Transit-Information-Optionen verwendet werden, wird in Abschnitt 9.4 weiter beschrieben.
Die RPL-Target-Option kann nach Bedarf wiederholt werden, um mehrere Ziele anzugeben.
Option Type: : 0x05
Option Length: : Variabel, Länge der Option in Oktetten ohne die Felder Type und Length.
Flags: : 8-Bit unbenutztes Feld, reserviert für Flags. Das Feld MUSS vom Absender auf Null initialisiert und vom Empfänger ignoriert werden.
Prefix Length: : 8-Bit-Ganzzahl ohne Vorzeichen. Anzahl der gültigen führenden Bits im IPv6-Präfix.
Target Prefix: : Feld variabler Länge, das eine IPv6-Zieladresse, ein Präfix oder eine Multicast-Gruppe identifiziert. Das Prefix Length-Feld enthält die Anzahl der gültigen führenden Bits im Präfix. Die Bits im Präfix nach der Präfixlänge (falls vorhanden) sind reserviert und MÜSSEN bei der Übertragung auf Null gesetzt und beim Empfang ignoriert werden.
6.7.8. Transitinformationen
Die Transit-Information-Option KANN in DAO-Nachrichten vorhanden sein, und ihr Format ist wie folgt:
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
Die Transit-Information-Option wird von einem Knoten verwendet, um Attribute für einen Pfad zu einem oder mehreren Zielen anzugeben. Die Ziele werden durch eine oder mehrere Target-Optionen angegeben, die unmittelbar vor der/den Transit-Information-Option(en) stehen.
Die Transit-Information-Option kann von einem Knoten verwendet werden, um seine DODAG-Eltern einem Vorfahren anzuzeigen, der DODAG-Routing-Informationen sammelt, typischerweise zum Zwecke der Konstruktion von Quellrouten. Im Non-Storing-Betriebsmodus ist dieser Vorfahre die DODAG-Wurzel, und diese Option wird von der DAO-Nachricht getragen. Im Storing-Betriebsmodus wird das DODAG Parent Address-Unterfeld nicht benötigt, da die DAO-Nachricht direkt an das Elternteil gesendet wird. Die Optionslänge wird verwendet, um zu bestimmen, ob das DODAG Parent Address-Unterfeld vorhanden ist oder nicht.
Ein Non-Storing-Knoten, der mehr als ein DAO-Elternteil hat, KANN eine Transit-Information-Option für jedes DAO-Elternteil als Teil der Non-Storing-Zielankündigungsoperation einschließen. Der Knoten kann die Bits im Path Control-Feld auf verschiedene Gruppen von DAO-Eltern verteilen, um eine Präferenz unter den Eltern zu signalisieren. Diese Präferenz kann die Entscheidung der DODAG-Wurzel beeinflussen, wenn sie zwischen den alternativen Eltern/Pfaden für den Aufbau von Abwärtsrouten wählt.
Eine oder mehrere Transit-Information-Optionen MÜSSEN von einer oder mehreren RPL-Target-Optionen vorangestellt werden. Auf diese Weise gibt die RPL-Target-Option den Kindknoten an, und die Transit-Information-Option(en) zählt/zählen die DODAG-Eltern auf. Die Struktur der DAO-Nachricht, die weiter detailliert, wie Target-Optionen in Verbindung mit Transit-Information-Optionen verwendet werden, wird in Abschnitt 9.4 weiter beschrieben.
Ein typischer Non-Storing-Knoten verwendet mehrere Transit-Information-Optionen und sendet die so gebildete DAO-Nachricht direkt an die Wurzel. Ein typischer Storing-Knoten verwendet eine Transit-Information-Option ohne Elternfeld und sendet die so gebildete DAO-Nachricht mit zusätzlichen Anpassungen an Path Control, wie später detailliert, an ein oder mehrere Elternteile.
Zum Beispiel sei im Non-Storing-Betriebsmodus Tgt(T) eine Target-Option für ein Ziel T. Sei Trnst(P) eine Transit-Information-Option, die eine Elternadresse P enthält. Betrachten Sie den Fall eines Non-Storing-Knotens N, der die selbst besessenen Ziele N1 und N2 ankündigt und Eltern P1, P2 und P3 hat. In diesem Fall würde erwartet, dass die DAO-Nachricht die Sequenz ((Tgt(N1), Tgt(N2)), (Trnst(P1), Trnst(P2), Trnst(P3))) enthält, so dass die Gruppe der Target-Optionen {N1, N2} durch die Transit-Information-Optionen als die Eltern {P1, P2, P3} habend beschrieben wird. Der Non-Storing-Knoten würde diese DAO-Nachricht dann direkt an die DODAG-Wurzel adressieren und diese DAO-Nachricht über einen der DODAG-Eltern weiterleiten: P1, P2 oder P3.
Option Type: : 0x06
Option Length: : Variabel, abhängig davon, ob das DODAG Parent Address-Unterfeld vorhanden ist oder nicht.
External (E): : 1-Bit-Flag. Das 'E'-Flag wird gesetzt, um anzuzeigen, dass der Eltern-Router externe Ziele in das RPL-Netzwerk neu verteilt. Ein externes Ziel ist ein Ziel, das über ein alternatives Protokoll gelernt wurde. Die externen Ziele sind in den Target-Optionen aufgeführt, die unmittelbar vor der Transit-Information-Option stehen. Von einem externen Ziel wird nicht erwartet, dass es RPL-Nachrichten und -Optionen unterstützt.
Flags: : Die 7 Bits, die im Flags-Feld unbenutzt bleiben, sind für Flags reserviert. Das Feld MUSS vom Absender auf Null initialisiert und vom Empfänger ignoriert werden.
Path Control: : 8-Bit-Bitfeld. Das Path Control-Feld begrenzt die Anzahl der DAO-Eltern, an die eine DAO-Nachricht, die Konnektivität zu einem bestimmten Ziel ankündigt, gesendet werden kann, und liefert auch einen Hinweis auf die relative Präferenz. Die Grenze bietet eine gewisse Begrenzung für das gesamte DAO-Nachrichten-Fan-Out im LLN. Die Zuweisung und Reihenfolge der Bits im Path Control dient auch dazu, Präferenz zu kommunizieren. Nicht alle dieser Bits sind möglicherweise gemäß PCS in der DODAG-Konfiguration aktiviert. Das Path Control-Feld ist in vier Unterfelder unterteilt, die jeweils zwei Bits enthalten: PC1, PC2, PC3 und PC4, wie in Abbildung 27 dargestellt. Die Unterfelder sind nach Präferenz geordnet, wobei PC1 am meisten bevorzugt und PC4 am wenigsten bevorzugt wird. Innerhalb eines Unterfeldes gibt es keine Präferenzreihenfolge. Durch Gruppierung der Eltern (wie in ECMP) und deren Anordnung können die Eltern bestimmten Bits im Path Control-Feld in einer Weise zugeordnet werden, die Präferenz kommuniziert.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|PC1|PC2|PC3|PC4|
+-+-+-+-+-+-+-+-+
Figure 27: Path Control Preference Subfield Encoding
Path Sequence: : 8-Bit-Ganzzahl ohne Vorzeichen. Wenn eine RPL-Target-Option von dem Knoten ausgegeben wird, der das Zielpräfix besitzt (d. h. in einer DAO-Nachricht), setzt dieser Knoten die Path Sequence und inkrementiert die Path Sequence jedes Mal, wenn er eine RPL-Target-Option mit aktualisierten Informationen ausgibt.
Path Lifetime: : 8-Bit-Ganzzahl ohne Vorzeichen. Die Zeitdauer in Lifetime Units (aus der Konfigurationsoption erhalten), die das Präfix für die Routenbestimmung gültig ist. Der Zeitraum beginnt, wenn eine neue Path Sequence gesehen wird. Ein Wert von nur Eins-Bits (0xFF) stellt Unendlichkeit dar. Ein Wert von nur Null-Bits (0x00) zeigt einen Verlust der Erreichbarkeit an. Eine DAO-Nachricht, die eine Transit-Information-Option mit einer Path Lifetime von 0x00 für ein Ziel enthält, wird in diesem Dokument als No-Path (für dieses Ziel) bezeichnet.
Parent Address (optional): : IPv6-Adresse des DODAG-Elternteils des Knotens, der ursprünglich die Transit-Information-Option ausgegeben hat. Dieses Feld ist möglicherweise nicht vorhanden, wie gemäß dem DODAG-Betriebsmodus (Storing oder Non-Storing) und durch die Länge der Transit-Information-Option angezeigt.
Nicht zugewiesene Bits der Transit-Information-Option sind reserviert. Sie MÜSSEN bei der Übertragung auf Null gesetzt und beim Empfang ignoriert werden.
6.7.9. Angeforderte Informationen
Die Solicited Information-Option KANN in DIS-Nachrichten vorhanden sein, und ihr Format ist wie folgt:
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
Die Solicited Information-Option wird von einem Knoten verwendet, um DIO-Nachrichten von einer Teilmenge benachbarter Knoten anzufordern. Die Solicited Information-Option kann eine Reihe von Prädikatskriterien angeben, die von einem empfangenden Knoten erfüllt werden müssen. Dies wird vom Anforderer verwendet, um die Anzahl der Antworten von "uninteressanten" Knoten zu begrenzen. Diese Prädikate beeinflussen, ob ein Knoten seinen DIO-Trickle-Timer zurücksetzt, wie in Abschnitt 8.3 beschrieben.
Die Solicited Information-Option enthält Flags, die angeben, welche Prädikate ein Knoten prüfen soll, wenn er entscheidet, ob er seinen Trickle-Timer zurücksetzen soll. Ein Knoten setzt seinen Trickle-Timer zurück, wenn alle Prädikate wahr sind. Wenn ein Flag gesetzt ist, dann MUSS der RPL-Knoten das zugehörige Prädikat prüfen. Wenn ein Flag gelöscht ist, dann DARF der RPL-Knoten das zugehörige Prädikat NICHT prüfen. (Wenn ein Flag gelöscht ist, nimmt der RPL-Knoten an, dass das zugehörige Prädikat wahr ist.)
Option Type: : 0x07
Option Length: : 19
V: : Das 'V'-Flag ist das Versionsprädikat. Das Versionsprädikat ist wahr, wenn die DODAGVersionNumber des Empfängers mit der angeforderten Version Number übereinstimmt. Wenn das 'V'-Flag gelöscht ist, ist das Version-Feld nicht gültig und das Version-Feld MUSS bei der Übertragung auf Null gesetzt und beim Empfang ignoriert werden.
I: : Das 'I'-Flag ist das InstanceID-Prädikat. Das InstanceID-Prädikat ist wahr, wenn die aktuelle RPLInstanceID des RPL-Knotens mit der angeforderten RPLInstanceID übereinstimmt. Wenn das 'I'-Flag gelöscht ist, ist das RPLInstanceID-Feld nicht gültig und das RPLInstanceID-Feld MUSS bei der Übertragung auf Null gesetzt und beim Empfang ignoriert werden.
D: : Das 'D'-Flag ist das DODAGID-Prädikat. Das DODAGID-Prädikat ist wahr, wenn der Elternsatz des RPL-Knotens dieselbe DODAGID wie das DODAGID-Feld hat. Wenn das 'D'-Flag gelöscht ist, ist das DODAGID-Feld nicht gültig und das DODAGID-Feld MUSS bei der Übertragung auf Null gesetzt und beim Empfang ignoriert werden.
Flags: : Die 5 Bits, die im Flags-Feld unbenutzt bleiben, sind für Flags reserviert. Das Feld MUSS vom Absender auf Null initialisiert und vom Empfänger ignoriert werden.
Version Number: : 8-Bit-Ganzzahl ohne Vorzeichen, die den Wert der DODAGVersionNumber enthält, der angefordert wird, wenn gültig.
RPLInstanceID: : 8-Bit-Ganzzahl ohne Vorzeichen, die die RPLInstanceID enthält, die angefordert wird, wenn gültig.
DODAGID: : 128-Bit-Ganzzahl ohne Vorzeichen, die die DODAGID enthält, die angefordert wird, wenn gültig.
Nicht zugewiesene Bits der Solicited Information-Option sind reserviert. Sie MÜSSEN bei der Übertragung auf Null gesetzt und beim Empfang ignoriert werden.
6.7.10. Präfix-Informationen
Die Prefix Information-Option (PIO) KANN in DIO-Nachrichten vorhanden sein und trägt die Informationen, die für die IPv6 ND Prefix Information-Option in [RFC4861], [RFC4862] und [RFC6275] zur Verwendung durch RPL-Knoten und IPv6-Hosts spezifiziert sind. Insbesondere kann ein RPL-Knoten diese Option zum Zwecke der Stateless Address Autoconfiguration (SLAAC) aus einem von einem Elternteil angekündigten Präfix verwenden, wie in [RFC4862] spezifiziert, und seine eigene Adresse wie in [RFC6275] spezifiziert ankündigen. Die Wurzel eines DODAG ist maßgeblich für das Setzen dieser Informationen. Die Informationen werden unverändert den DODAG hinunter propagiert, mit der Ausnahme, dass ein RPL-Router die Interface-ID überschreiben KANN, wenn das 'R'-Flag gesetzt ist, um seine vollständige Adresse im PIO anzugeben. Das Format der Option wird leicht modifiziert (Typ, Länge, Präfix), um als RPL-Option wie folgt getragen zu werden:
Wenn der einzige gewünschte Effekt eines empfangenen PIO in einem DIO darin besteht, die globale Adresse des Elternknotens dem empfangenden Knoten bereitzustellen, setzt der Absender die 'A'- und 'L'-Bits zurück und setzt das 'R'-Bit. Nach Erhalt wird RPL keine Adresse oder verbundene Route aus dem Präfix automatisch konfigurieren [RFC4862]. Wie in allen Fällen KANN der RPL-Knoten, wenn das 'L'-Bit nicht gesetzt ist, das Präfix in PIOs aufnehmen, die er an seine Kinder sendet.
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
Das PIO kann verwendet werden, um das innerhalb des DODAG verwendete Präfix zu verteilen, z. B. für die Adressautoconfiguration.
[RFC4861] und [RFC6275] sollten als maßgebliche Referenz in Bezug auf das PIO konsultiert werden. Die Feldbeschreibungen werden hier der Bequemlichkeit halber transkribiert:
Option Type: : 0x08
Option Length: : 30. Beachten Sie, dass diese Länge im Gegensatz zu IPv6 ND in Einheiten von einzelnen Oktetten ausgedrückt wird.
Prefix Length: : 8-Bit-Ganzzahl ohne Vorzeichen. Die Anzahl der führenden Bits im Prefix-Feld, die gültig sind. Der Wert reicht von 0 bis 128. Das Prefix Length-Feld liefert notwendige Informationen für die On-Link-Bestimmung (wenn kombiniert mit dem 'L'-Flag im PIO). Es unterstützt auch die Adressautoconfiguration wie in [RFC4862] spezifiziert, für die es möglicherweise mehr Einschränkungen bezüglich der Präfixlänge gibt.
L: : 1-Bit On-Link-Flag. Wenn gesetzt, zeigt es an, dass dieses Präfix für die On-Link-Bestimmung verwendet werden kann. Wenn nicht gesetzt, macht die Ankündigung keine Aussage über On-Link- oder Off-Link-Eigenschaften des Präfixes. Mit anderen Worten, wenn das 'L'-Flag nicht gesetzt ist, DARF ein RPL-Knoten NICHT schließen, dass eine aus dem Präfix abgeleitete Adresse Off-Link ist. Das heißt, er DARF KEINE vorherige Angabe aktualisieren, dass die Adresse On-Link ist. Ein RPL-Knoten, der als Router fungiert, DARF ein PIO mit gesetztem 'L'-Flag NICHT propagieren. Ein RPL-Knoten, der als Router fungiert, KANN ein PIO mit nicht gesetztem 'L'-Flag propagieren.
A: : 1-Bit Autonomous Address-Configuration-Flag. Wenn gesetzt, zeigt es an, dass dieses Präfix für die Stateless Address Configuration wie in [RFC4862] spezifiziert verwendet werden kann. Wenn beide Protokolle (ND RAs und RPL DIOs) verwendet werden, um PIOs auf demselben Link zu tragen, ist es möglich, eines von beiden für SLAAC durch einen RPL-Knoten zu verwenden. Es ist auch möglich, eines der beiden Protokolle für den SLAAC-Betrieb ungeeignet zu machen, indem das 'A'-Flag für PIOs, die in diesem Protokoll getragen werden, auf 0 gesetzt wird.
R: : 1-Bit Router Address-Flag. Wenn gesetzt, zeigt es an, dass das Prefix-Feld eine vollständige IPv6-Adresse enthält, die dem sendenden Router zugewiesen ist und als Elternteil in einer Target-Option verwendet werden kann. Das angegebene Präfix sind die ersten Prefix Length-Bits des Prefix-Feldes. Die Router-IPv6-Adresse hat denselben Geltungsbereich und entspricht denselben Lebensdauerwerten wie das angekündigte Präfix. Diese Verwendung des Prefix-Feldes ist kompatibel mit seiner Verwendung bei der Ankündigung des Präfixes selbst, da die Präfixankündigung nur die führenden Bits verwendet. Die Interpretation dieses Flag-Bits ist somit unabhängig von der Verarbeitung, die für die On-Link (L) und Autonomous Address-Configuration (A) Flag-Bits erforderlich ist.
Reserved1: : 5-Bit unbenutztes Feld. Es MUSS vom Absender auf Null initialisiert und vom Empfänger ignoriert werden.
Valid Lifetime: : 32-Bit-Ganzzahl ohne Vorzeichen. Die Zeitdauer in Sekunden (relativ zur Zeit, zu der das Paket gesendet wird), die das Präfix zum Zwecke der On-Link-Bestimmung gültig ist. Ein Wert von nur Eins-Bits (0xFFFFFFFF) stellt Unendlichkeit dar. Die Valid Lifetime wird auch von [RFC4862] verwendet.
Preferred Lifetime: : 32-Bit-Ganzzahl ohne Vorzeichen. Die Zeitdauer in Sekunden (relativ zur Zeit, zu der das Paket gesendet wird), die Adressen, die aus dem Präfix über Stateless Address Autoconfiguration generiert wurden, bevorzugt bleiben [RFC4862]. Ein Wert von nur Eins-Bits (0xFFFFFFFF) stellt Unendlichkeit dar. Siehe [RFC4862]. Beachten Sie, dass der Wert dieses Feldes das Valid Lifetime-Feld NICHT überschreiten DARF, um zu vermeiden, dass Adressen bevorzugt werden, die nicht mehr gültig sind.
Reserved2: : Dieses Feld ist unbenutzt. Es MUSS vom Absender auf Null initialisiert und vom Empfänger ignoriert werden.
Prefix: : Eine IPv6-Adresse oder ein Präfix einer IPv6-Adresse. Das Prefix Length-Feld enthält die Anzahl der gültigen führenden Bits im Präfix. Die Bits im Präfix nach der Präfixlänge sind reserviert und MÜSSEN vom Absender auf Null initialisiert und vom Empfänger ignoriert werden. Ein Router SOLLTE KEINE Präfixoption für das Link-Local-Präfix senden, und ein Host SOLLTE eine solche Präfixoption ignorieren. Ein Non-Storing-Knoten SOLLTE davon absehen, ein Präfix anzukündigen, bis er eine Adresse dieses Präfixes besitzt, und dann SOLLTE er seine vollständige Adresse in diesem Feld ankündigen, wobei das 'R'-Flag gesetzt ist. Die Kinder eines Knotens, der eine vollständige Adresse mit gesetztem 'R'-Flag so ankündigt, können diese Adresse dann verwenden, um den Inhalt des DODAG Parent Address-Unterfeldes der Transit-Information-Option zu bestimmen.
Nicht zugewiesene Bits des PIO sind reserviert. Sie MÜSSEN bei der Übertragung auf Null gesetzt und beim Empfang ignoriert werden.
6.7.11. RPL-Zieldeskriptor
Der RPL-Target-Option KANN unmittelbar ein undurchsichtiger Deskriptor folgen, der dieses spezifische Ziel qualifiziert.
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
Die RPL-Target-Descriptor-Option wird verwendet, um ein Ziel zu qualifizieren, etwas, das manchmal als "Tagging" bezeichnet wird.
Höchstens kann es einen Deskriptor pro Ziel geben. Der Deskriptor wird von dem Knoten gesetzt, der das Target in das RPL-Netzwerk injiziert. Er MUSS von Routern kopiert, aber nicht modifiziert werden, die das Target in DAO-Nachrichten den DODAG hinauf propagieren.
Option Type: : 0x09
Option Length: : 4
Descriptor: : 32-Bit-Ganzzahl ohne Vorzeichen. Undurchsichtig.