20. IANA-Überlegungen
20.1. RPL-Kontrollnachricht
Die RPL-Kontrollnachricht ist ein ICMP-Informationsnachrichtentyp, der verwendet werden soll, um DODAG-Informationsobjekte, DODAG-Informationsanforderungen und Zielanzeigeobjekte zur Unterstützung des RPL-Betriebs zu übertragen.
Die IANA hat ein ICMPv6-Typnummernregister definiert. Der Typwert für die RPL-Kontrollnachricht ist 155.
20.2. Neues Register für RPL-Kontrollcodes
Die IANA hat ein Register, RPL-Kontrollcodes, für das Code-Feld der ICMPv6-RPL-Kontrollnachricht erstellt.
Neue Codes dürfen nur durch eine IETF-Überprüfung zugewiesen werden. Jeder Code wird mit den folgenden Eigenschaften verfolgt:
-
Code
-
Beschreibung
-
Definierende RFC
Die folgenden Codes sind derzeit definiert:
| Code | Beschreibung | Referenz |
|---|---|---|
| 0x00 | DODAG-Informationsanforderung | Dieses Dokument |
| 0x01 | DODAG-Informationsobjekt | Dieses Dokument |
| 0x02 | Zielanzeigeobjekt | Dieses Dokument |
| 0x03 | Zielanzeigeobjekt-Bestätigung | Dieses Dokument |
| 0x80 | Sichere DODAG-Informationsanforderung | Dieses Dokument |
| 0x81 | Sicheres DODAG-Informationsobjekt | Dieses Dokument |
| 0x82 | Sicheres Zielanzeigeobjekt | Dieses Dokument |
| 0x83 | Sichere Zielanzeigeobjekt-Bestätigung | Dieses Dokument |
| 0x8A | Konsistenzprüfung | Dieses Dokument |
20.3. Neues Register für den Betriebsmodus (MOP)
Die IANA hat ein Register für den 3-Bit-Betriebsmodus (MOP) erstellt, der in der DIO-Basis enthalten ist.
Neue Werte dürfen nur durch eine IETF-Überprüfung zugewiesen werden. Jeder Wert wird mit den folgenden Eigenschaften verfolgt:
-
Betriebsmoduswert
-
Fähigkeitsbeschreibung
-
Definierende RFC
Derzeit sind vier Werte definiert:
| MOP-Wert | Beschreibung | Referenz |
|---|---|---|
| 0 | Keine Abwärtsrouten, die von RPL verwaltet werden | Dieses Dokument |
| 1 | Nicht-speichernder Betriebsmodus | Dieses Dokument |
| 2 | Speichernder Betriebsmodus ohne Multicast-Unterstützung | Dieses Dokument |
| 3 | Speichernder Betriebsmodus mit Multicast-Unterstützung | Dieses Dokument |
Der Rest des Bereichs, dezimal 4 bis 7, ist derzeit nicht zugewiesen.
20.4. RPL-Kontrollnachrichtenoptionen
Die IANA hat ein Register für die RPL-Kontrollnachrichtenoptionen erstellt.
Neue Werte dürfen nur durch eine IETF-Überprüfung zugewiesen werden. Jeder Wert wird mit den folgenden Eigenschaften verfolgt:
-
Wert
-
Bedeutung
-
Definierende RFC
| Wert | Bedeutung | Referenz |
|---|---|---|
| 0x00 | Pad1 | Dieses Dokument |
| 0x01 | PadN | Dieses Dokument |
| 0x02 | DAG-Metrik-Container | Dieses Dokument |
| 0x03 | Routing-Informationen | Dieses Dokument |
| 0x04 | DODAG-Konfiguration | Dieses Dokument |
| 0x05 | RPL-Ziel | Dieses Dokument |
| 0x06 | Transitinformationen | Dieses Dokument |
| 0x07 | Angeforderte Informationen | Dieses Dokument |
| 0x08 | Präfixinformationen | Dieses Dokument |
| 0x09 | Zieldeskriptor | Dieses Dokument |
20.5. Objective Code Point (OCP) Register
Die IANA hat ein Register erstellt, um den Codespace des Objective Code Point (OCP)-Feldes zu verwalten.
In dieser Spezifikation sind keine OCPs definiert.
Neue Codes dürfen nur durch eine IETF-Überprüfung zugewiesen werden. Jeder Code wird mit den folgenden Eigenschaften verfolgt:
-
Code
-
Beschreibung
-
Definierende RFC
20.6. Neues Register für den Sicherheitsabschnitt-Algorithmus
Die IANA hat ein Register für die Werte des 8-Bit-Algorithmusfeldes im Sicherheitsabschnitt erstellt.
Neue Werte dürfen nur durch eine IETF-Überprüfung zugewiesen werden. Jeder Wert wird mit den folgenden Eigenschaften verfolgt:
-
Wert
-
Verschlüsselung/MAC
-
Signatur
-
Definierende RFC
Derzeit ist der folgende Wert definiert:
| Wert | Verschlüsselung/MAC | Signatur | Referenz |
|---|---|---|---|
| 0 | CCM mit AES-128 | RSA mit SHA-256 | Dieses Dokument |
20.7. Neues Register für die Sicherheitsabschnitt-Flags
Die IANA hat ein Register für das 8-Bit-Sicherheitsabschnitt-Flags-Feld erstellt.
Neue Bitnummern dürfen nur durch eine IETF-Überprüfung zugewiesen werden. Jedes Bit wird mit den folgenden Eigenschaften verfolgt:
-
Bitnummer (Zählung ab Bit 0 als höchstwertiges Bit)
-
Fähigkeitsbeschreibung
-
Definierende RFC
Derzeit ist kein Bit für das Sicherheitsabschnitt-Flags-Feld definiert.
20.8. Neues Register für Sicherheitsstufen pro KIM
Die IANA hat ein Register für das 3-Bit-Sicherheitsstufenfeld (LVL) pro zugewiesenem KIM-Wert erstellt.
Für einen gegebenen KIM-Wert dürfen neue Stufen nur durch eine IETF-Überprüfung zugewiesen werden. Jede Stufe wird mit den folgenden Eigenschaften verfolgt:
-
Stufe
-
KIM-Wert
-
Beschreibung
-
Definierende RFC
Die folgenden Stufen pro KIM-Wert sind derzeit definiert:
| Stufe | KIM-Wert | Beschreibung | Referenz |
|---|---|---|---|
| 0 | 0 | Siehe Abbildung 11 | Dieses Dokument |
| 1 | 0 | Siehe Abbildung 11 | Dieses Dokument |
| 2 | 0 | Siehe Abbildung 11 | Dieses Dokument |
| 3 | 0 | Siehe Abbildung 11 | Dieses Dokument |
| 0 | 1 | Siehe Abbildung 11 | Dieses Dokument |
| 1 | 1 | Siehe Abbildung 11 | Dieses Dokument |
| 2 | 1 | Siehe Abbildung 11 | Dieses Dokument |
| 3 | 1 | Siehe Abbildung 11 | Dieses Dokument |
| 0 | 2 | Siehe Abbildung 11 | Dieses Dokument |
| 1 | 2 | Siehe Abbildung 11 | Dieses Dokument |
| 2 | 2 | Siehe Abbildung 11 | Dieses Dokument |
| 3 | 2 | Siehe Abbildung 11 | Dieses Dokument |
| 0 | 3 | Siehe Abbildung 11 | Dieses Dokument |
| 1 | 3 | Siehe Abbildung 11 | Dieses Dokument |
| 2 | 3 | Siehe Abbildung 11 | Dieses Dokument |
| 3 | 3 | Siehe Abbildung 11 | Dieses Dokument |
20.9. Neues Register für DODAG-Informationsanforderungs- (DIS) Flags
Die IANA hat ein Register für das DIS- (DODAG-Informationsanforderungs-) Flags-Feld erstellt.
Neue Bitnummern dürfen nur durch eine IETF-Überprüfung zugewiesen werden. Jedes Bit wird mit den folgenden Eigenschaften verfolgt:
-
Bitnummer (Zählung ab Bit 0 als höchstwertiges Bit)
-
Fähigkeitsbeschreibung
-
Definierende RFC
Derzeit ist kein Bit für das DIS- (DODAG-Informationsanforderungs-) Flags-Feld definiert.
20.10. Neues Register für die DODAG-Informationsobjekt- (DIO) Flags
Die IANA hat ein Register für das 8-Bit-DODAG-Informationsobjekt- (DIO) Flags-Feld erstellt.
Neue Bitnummern dürfen nur durch eine IETF-Überprüfung zugewiesen werden. Jedes Bit wird mit den folgenden Eigenschaften verfolgt:
-
Bitnummer (Zählung ab Bit 0 als höchstwertiges Bit)
-
Fähigkeitsbeschreibung
-
Definierende RFC
Derzeit ist kein Bit für die DIS- (DODAG-Informationsanforderungs-) Flags definiert.
20.11. Neues Register für die Zielanzeigeobjekt- (DAO) Flags
Die IANA hat ein Register für das 8-Bit-Zielanzeigeobjekt- (DAO) Flags-Feld erstellt.
Neue Bitnummern dürfen nur durch eine IETF-Überprüfung zugewiesen werden. Jedes Bit wird mit den folgenden Eigenschaften verfolgt:
-
Bitnummer (Zählung ab Bit 0 als höchstwertiges Bit)
-
Fähigkeitsbeschreibung
-
Definierende RFC
Die folgenden Bits sind derzeit definiert:
| Bitnummer | Beschreibung | Referenz |
|---|---|---|
| 0 | DAO-ACK-Anforderung (K) | Dieses Dokument |
| 1 | DODAGID-Feld ist vorhanden (D) | Dieses Dokument |
20.12. Neues Register für die Zielanzeigeobjekt- (DAO) Bestätigungs-Flags
Die IANA hat ein Register für das 8-Bit-Zielanzeigeobjekt- (DAO) Bestätigungs-Flags-Feld erstellt.
Neue Bitnummern dürfen nur durch eine IETF-Überprüfung zugewiesen werden. Jedes Bit wird mit den folgenden Eigenschaften verfolgt:
-
Bitnummer (Zählung ab Bit 0 als höchstwertiges Bit)
-
Fähigkeitsbeschreibung
-
Definierende RFC
Das folgende Bit ist derzeit definiert:
| Bitnummer | Beschreibung | Referenz |
|---|---|---|
| 0 | DODAGID-Feld ist vorhanden (D) | Dieses Dokument |
20.13. Neues Register für die Konsistenzprüfungs- (CC) Flags
Die IANA hat ein Register für das 8-Bit-Konsistenzprüfungs- (CC) Flags-Feld erstellt.
Neue Bitnummern dürfen nur durch eine IETF-Überprüfung zugewiesen werden. Jedes Bit wird mit den folgenden Eigenschaften verfolgt:
-
Bitnummer (Zählung ab Bit 0 als höchstwertiges Bit)
-
Fähigkeitsbeschreibung
-
Definierende RFC
Das folgende Bit ist derzeit definiert:
| Bitnummer | Beschreibung | Referenz |
|---|---|---|
| 0 | CC-Antwort (R) | Dieses Dokument |
20.14. Neues Register für die DODAG-Konfigurationsoptions-Flags
Die IANA hat ein Register für das 8-Bit-DODAG-Konfigurationsoptions-Flags-Feld erstellt.
Neue Bitnummern dürfen nur durch eine IETF-Überprüfung zugewiesen werden. Jedes Bit wird mit den folgenden Eigenschaften verfolgt:
-
Bitnummer (Zählung ab Bit 0 als höchstwertiges Bit)
-
Fähigkeitsbeschreibung
-
Definierende RFC
Die folgenden Bits sind derzeit definiert:
| Bitnummer | Beschreibung | Referenz |
|---|---|---|
| 4 | Authentifizierung aktiviert (A) | Dieses Dokument |
| 5-7 | Pfadkontrollgröße (PCS) | Dieses Dokument |
20.15. Neues Register für die RPL-Zieloptions-Flags
Die IANA hat ein Register für das 8-Bit-RPL-Zieloptions-Flags-Feld erstellt.
Neue Bitnummern dürfen nur durch eine IETF-Überprüfung zugewiesen werden. Jedes Bit wird mit den folgenden Eigenschaften verfolgt:
-
Bitnummer (Zählung ab Bit 0 als höchstwertiges Bit)
-
Fähigkeitsbeschreibung
-
Definierende RFC
Derzeit ist kein Bit für die RPL-Zieloptions-Flags definiert.
20.16. Neues Register für die Transitinformationsoptions-Flags
Die IANA hat ein Register für das 8-Bit-Transitinformationsoptions- (TIO) Flags-Feld erstellt.
Neue Bitnummern dürfen nur durch eine IETF-Überprüfung zugewiesen werden. Jedes Bit wird mit den folgenden Eigenschaften verfolgt:
-
Bitnummer (Zählung ab Bit 0 als höchstwertiges Bit)
-
Fähigkeitsbeschreibung
-
Definierende RFC
Die folgenden Bits sind derzeit definiert:
| Bitnummer | Beschreibung | Referenz |
|---|---|---|
| 0 | Extern (E) | Dieses Dokument |
20.17. Neues Register für die Angeforderte-Informationsoptions-Flags
Die IANA hat ein Register für das 8-Bit-Angeforderte-Informationsoptions- (SIO) Flags-Feld erstellt.
Neue Bitnummern dürfen nur durch eine IETF-Überprüfung zugewiesen werden. Jedes Bit wird mit den folgenden Eigenschaften verfolgt:
-
Bitnummer (Zählung ab Bit 0 als höchstwertiges Bit)
-
Fähigkeitsbeschreibung
-
Definierende RFC
Die folgenden Bits sind derzeit definiert:
| Bitnummer | Beschreibung | Referenz |
|---|---|---|
| 0 | Versionsprädikat-Übereinstimmung (V) | Dieses Dokument |
| 1 | Instanz-ID-Prädikat-Übereinstimmung (I) | Dieses Dokument |
| 2 | DODAGID-Prädikat-Übereinstimmung (D) | Dieses Dokument |
20.18. ICMPv6: Fehler im Quellrouting-Header
In einigen Fällen gibt RPL eine ICMPv6-Fehlernachricht zurück, wenn eine Nachricht nicht wie in ihrem Quellrouting-Header angegeben zugestellt werden kann. Diese ICMPv6-Fehlernachricht lautet "Fehler im Quellrouting-Header".
Die IANA hat ein ICMPv6-"Code"-Feldregister für ICMPv6-Nachrichtentypen definiert. ICMPv6-Nachrichtentyp 1 beschreibt "Ziel unerreichbar"-Codes. Der Code "Fehler im Quellrouting-Header" wurde aus dem ICMPv6-Codefeldregister für ICMPv6-Nachrichtentyp 1 zugewiesen, mit einem Codewert von 7.
20.19. Link-Local Scope Multicast-Adresse
Die Regeln für die Zuweisung neuer IPv6-Multicast-Adressen sind in [RFC3307] definiert. Diese Spezifikation erfordert die Zuweisung einer neuen permanenten Multicast-Adresse mit einem Link-Local-Scope für RPL-Knoten namens all-RPL-nodes, mit einem Wert von ff02::1a.