Zum Hauptinhalt springen

RFC 4944 - Transmission of IPv6 Packets over IEEE 802.15.4 Networks (Übertragung von IPv6-Paketen über IEEE 802.15.4-Netzwerke)

  • Status: Proposed Standard
  • Veröffentlicht: September 2007
  • Stream: IETF
  • Errata: Keine Errata

Zusammenfassung (Abstract)​

Dieses Dokument beschreibt das Rahmenformat (Frame Format) für die Übertragung von IPv6-Paketen über IEEE 802.15.4-Netzwerke sowie die Methoden zur Bildung von IPv6-verbindungslokalen Adressen (Link-Local Addresses) und zustandslosen automatisch konfigurierten Adressen (Stateless Autoconfiguration Addresses) über IEEE 802.15.4-Netzwerken. Zusätzliche Spezifikationen umfassen ein einfaches Header-Komprimierungsschema (Header Compression Scheme) unter Verwendung gemeinsamer Kontexte sowie Bestimmungen für die Paketübermittlung in IEEE 802.15.4-Mesh-Netzwerken (Mesh Networks).

Inhaltsverzeichnis (Contents)​

Anhänge (Appendices)​

Verwandte Ressourcen​

1. Introduction (Einleitung)​

Der IEEE 802.15.4-Standard [ieee802.15.4] richtet sich an drahtlose Netzwerke mit geringem Stromverbrauch (Low-Power Personal Area Networks). Dieses Dokument definiert das Rahmenformat (Frame Format) für die Übertragung von IPv6 [RFC2460]-Paketen über IEEE 802.15.4-Netzwerke sowie die Methoden zur Bildung von IPv6-verbindungslokalen Adressen (Link-Local Addresses) und zustandslosen automatisch konfigurierten Adressen (Statelessly Autoconfigured Addresses) über IEEE 802.15.4-Netzwerken. Da IPv6 Paketgrößen unterstützen muss, die weit über der maximalen Rahmengröße von IEEE 802.15.4 liegen, wird eine Anpassungsschicht (Adaptation Layer) definiert. Dieses Dokument definiert auch den Header-Komprimierungsmechanismus (Header Compression), der erforderlich ist, um IPv6 über IEEE 802.15.4-Netzwerke praktikabel zu machen, sowie die Bestimmungen für die Paketübermittlung in IEEE 802.15.4-Mesh-Netzwerken (Meshes). Die vollständige Spezifikation des Mesh-Netzwerk-Routings (das verwendete spezifische Protokoll, die Interaktion mit der Nachbarschaftserkennung usw.) liegt jedoch außerhalb des Geltungsbereichs dieses Dokuments.

1.1. Requirements Notation (Anforderungsnotation)​

Die Schlüsselwörter „MUSS" (MUST), „DARF NICHT" (MUST NOT), „ERFORDERLICH" (REQUIRED), „SOLL" (SHALL), „SOLL NICHT" (SHALL NOT), „SOLLTE" (SHOULD), „SOLLTE NICHT" (SHOULD NOT), „EMPFOHLEN" (RECOMMENDED), „KANN" (MAY) und „OPTIONAL" (OPTIONAL) in diesem Dokument sind gemäß [RFC2119] zu interpretieren.

1.2. Terms Used (Verwendete Begriffe)​

AES: Advanced Encryption Scheme (Erweitertes Verschlüsselungsschema)

CSMA/CA: Carrier Sense Multiple Access / Collision Avoidance (Trägererfassungs-Mehrfachzugriff / Kollisionsvermeidung)

FFD: Full Function Device (Gerät mit vollem Funktionsumfang)

GTS: Guaranteed Time Service (Garantierter Zeitschlitzdienst)

MTU: Maximum Transmission Unit (Maximale Übertragungseinheit)

MAC: Media Access Control (Medienzugriffssteuerung)

PAN: Personal Area Network (Persönliches Netzwerk)

RFD: Reduced Function Device (Gerät mit reduziertem Funktionsumfang)

2. IEEE 802.15.4 Mode for IP (IEEE 802.15.4-Modus für IP)​

IEEE 802.15.4 definiert vier Rahmentypen (Frame Types): Beacon-Rahmen (Beacon Frames), MAC-Befehlsrahmen (MAC Command Frames), Bestätigungsrahmen (Acknowledgement Frames) und Datenrahmen (Data Frames). IPv6-Pakete MÜSSEN (MUST) in Datenrahmen übertragen werden. Datenrahmen können optional eine Bestätigung (Acknowledgement) anfordern. In Übereinstimmung mit [RFC3819] wird EMPFOHLEN (RECOMMENDED), IPv6-Pakete in Rahmen zu übertragen, die eine Bestätigung anfordern, um die Verbindungsschicht-Wiederherstellung (Link-Layer Recovery) zu unterstützen.

IEEE 802.15.4-Netzwerke können Beacon-fähig (Beacon-Enabled) oder nicht-Beacon-fähig (Nonbeacon-Enabled) sein [ieee802.15.4]. Letzteres ist ein optionaler Modus, in dem Geräte über die Beacons eines sogenannten Koordinators (Coordinator) synchronisiert werden. Dies ermöglicht die Verwendung von Superrahmen (Superframes), innerhalb derer ein wettbewerbsfreier Garantierter Zeitschlitzdienst (Guaranteed Time Service, GTS) realisiert werden kann. Dieses Dokument erfordert NICHT (NOT REQUIRE), dass IEEE-Netzwerke im Beacon-fähigen Modus betrieben werden. In nicht-Beacon-fähigen Netzwerken werden Datenrahmen (einschließlich der Rahmen, die IPv6-Pakete tragen) über die wettbewerbsbasierte, nicht-zeitgeschlitzte CSMA/CA-Kanalzugriffsmethode (Contention-Based Channel Access Method of Unslotted CSMA/CA) gesendet.

In nicht-Beacon-fähigen Netzwerken werden Beacons nicht zur Synchronisation verwendet. Sie sind jedoch weiterhin nützlich für die Verbindungsschicht-Geräteerkennung (Link-Layer Device Discovery), um Assoziierungs- (Association) und Disassoziierungsereignisse (Disassociation Events) zu unterstützen. Dieses Dokument EMPFIEHLT (RECOMMENDS), Beacons zur Unterstützung dieser Funktionen zu konfigurieren. Eine weitere Empfehlung ist, diese Ereignisse auf der IPv6-Schicht verfügbar zu machen, um die Erkennung der Netzwerkanbindung (Network Attachment) zu unterstützen, ein Problem, das die IETF zum Zeitpunkt der Erstellung dieses Dokuments untersuchte.

Diese Spezifikation erlaubt Rahmen, bei denen die Quell- oder Zieladresse (oder beide) weggelassen (Elided) werden. Die in diesem Dokument definierten Mechanismen ERFORDERN (REQUIRE), dass sowohl Quell- als auch Zieladresse im IEEE 802.15.4-Rahmen-Header (Frame Header) enthalten sein müssen. Quell- oder Ziel-PAN-ID-Felder können ebenfalls enthalten sein.

3. Addressing Modes (Adressierungsmodi)​

IEEE 802.15.4 definiert mehrere Adressierungsmodi (Addressing Modes): Es erlaubt die Verwendung von IEEE 64-Bit-Erweiterungsadressen (64-bit Extended Addresses) oder (nach einem Assoziierungsereignis) innerhalb eines PAN eindeutiger 16-Bit-Adressen [ieee802.15.4]. Dieses Dokument unterstützt sowohl 64-Bit-Erweiterungsadressen als auch 16-Bit-Kurzadressen (Short Addresses).

Für die Verwendung innerhalb von 6LoWPAN legt dieses Dokument zusätzliche Einschränkungen für das Format der 16-Bit-Kurzadressen fest (über die von IEEE 802.15.4 auferlegten Einschränkungen hinaus), wie in Abschnitt 12 festgelegt. Da Kurzadressen von Natur aus vorübergehend (Transient) sind, ist besondere Sorgfalt geboten: Da sie während eines Assoziierungsereignisses durch die PAN-Koordinatorfunktion (PAN Coordinator Function) zugewiesen werden, sind ihre Gültigkeit und Eindeutigkeit auf die Lebensdauer dieser Assoziation beschränkt. Dies kann durch das Ablaufen der Assoziation oder durch einen Ausfall des PAN-Koordinators verkürzt werden. Aufgrund der Skalierbarkeitsprobleme, die durch diese zentralisierte Zuweisung und den einzelnen Ausfallpunkt (Single Point of Failure) beim PAN-Koordinator entstehen, sollten Betreiber die Vor- und Nachteile der Erweiterung solcher Netzwerke auf Basis von Kurzadressen sorgfältig abwägen (und die notwendigen Mechanismen implementieren). Natürlich sind IEEE 64-Bit-Erweiterungsadressen möglicherweise nicht von diesen Mängeln betroffen, teilen jedoch weiterhin die übrigen Skalierbarkeitsprobleme in Bezug auf Routing, Erkennung, Konfiguration usw.

Dieses Dokument geht davon aus, dass ein PAN einem bestimmten IPv6-Link (IPv6 Link) zugeordnet ist. Dies entspricht der Empfehlung, dass gemeinsam genutzte Netzwerke Verbindungsschicht-Subnetz-Broadcasts [RFC3819] unterstützen sollten. Streng genommen existiert in IPv6 Multicast (Multicast) statt Broadcast (Broadcast). IEEE 802.15.4 selbst unterstützt jedoch kein Multicast. Daher MÜSSEN (MUST) IPv6-Schicht-Multicast-Pakete als Verbindungsschicht-Broadcast-Rahmen in IEEE 802.15.4-Netzwerken übertragen werden. Dies MUSS (MUST) so erfolgen, dass Broadcast-Rahmen nur von Geräten innerhalb des spezifischen PAN des betreffenden Links beachtet werden. Gemäß Abschnitt 7.5.6.2 von [ieee802.15.4] wird dies wie folgt erreicht:

  1. Der Rahmen MUSS (MUST) einen Ziel-PAN-Identifikator (Destination PAN Identifier) enthalten, und dieser MUSS (MUST) mit der PAN-ID des betreffenden Links übereinstimmen.

  2. Der Rahmen MUSS (MUST) eine kurze Zieladresse (Short Destination Address) enthalten, und diese MUSS (MUST) mit der Broadcast-Adresse (0xffff) übereinstimmen.

Darüber hinaus DARF (MUST) die Unterstützung der IPv6-Multicast-Adresszuordnung gemäß Abschnitt 9 NUR in Mesh-Konfigurationen (Mesh Configuration) verwendet werden. Die vollständige Spezifikation solcher Funktionen liegt außerhalb des Geltungsbereichs dieses Dokuments.

Wie üblich erfahren Hosts IPv6-Präfixe über Router-Ankündigungen (Router Advertisements), wie in [RFC4861] beschrieben.

4. Maximum Transmission Unit (Maximale Übertragungseinheit)​

Die MTU-Größe für IPv6-Pakete über IEEE 802.15.4 beträgt 1280 Oktette (Octets). Ein vollständiges IPv6-Paket passt jedoch nicht in einen einzigen IEEE 802.15.4-Rahmen. 802.15.4-Protokolldateneinheiten (Protocol Data Units) haben unterschiedliche Größen, abhängig davon, wie viel Overhead vorhanden ist [ieee802.15.4]. Ausgehend von der maximalen physikalischen Schicht-Paketgröße von 127 Oktetten (aMaxPHYPacketSize) und dem maximalen Rahmen-Overhead von 25 (aMaxFrameOverhead) ergibt sich eine maximale Rahmengröße der Medienzugriffssteuerungsschicht (Media Access Control Layer) von 102 Oktetten. Verbindungsschicht-Sicherheit (Link-Layer Security) verursacht weiteren Overhead, im schlimmsten Fall (21 Oktette Overhead bei AES-CCM-128, 9 bzw. 13 bei AES-CCM-32 und AES-CCM-64), sodass nur noch 81 Oktette verfügbar bleiben. Dies liegt deutlich unter der minimalen IPv6-Paketgröße von 1280 Oktetten, und gemäß Abschnitt 5 der IPv6-Spezifikation [RFC2460] MUSS (MUST) eine Fragmentierungs- und Reassemblierungsanpassungsschicht (Fragmentation and Reassembly Adaptation Layer) in den Schichten unterhalb der IP-Schicht bereitgestellt werden. Eine solche Schicht wird in Abschnitt 5 unten definiert.

Da der IPv6-Header außerdem 40 Oktette lang ist, verbleiben für Protokolle der oberen Schicht (wie UDP) nur noch 41 Oktette. Letzteres verwendet 8 Oktette im Header, sodass für Anwendungsdaten (Application Data) nur noch 33 Oktette verbleiben. Darüber hinaus ist, wie oben erwähnt, eine Fragmentierungs- und Reassemblierungsschicht erforderlich, die weitere Oktette verbraucht.

Die obigen Überlegungen führen zu den folgenden zwei Beobachtungen:

  1. Eine Anpassungsschicht MUSS (MUST) bereitgestellt werden, um die Anforderungen an die minimale IPv6-MTU zu erfüllen. Es wird jedoch erwartet, dass (a) die meisten Anwendungen von IEEE 802.15.4 keine so großen Pakete verwenden werden, und (b) kleinere Anwendungsnutzlasten (Application Payloads) in Kombination mit geeigneter Header-Komprimierung (Header Compression) Pakete erzeugen werden, die in einen einzigen IEEE 802.15.4-Rahmen passen. Die Begründung für diese Anpassungsschicht geht über die bloße IPv6-Konformität hinaus, da bestimmte Anwendungsaustausche (z. B. Konfiguration oder Bereitstellung (Provisioning)) wahrscheinlich Paketgrößen erzeugen, die eine geringe Anzahl von Fragmentierungen erfordern.

  2. Obwohl die obigen Platzberechnungen den schlimmsten Fall zeigen, weisen sie darauf hin, dass Header-Komprimierung nahezu unvermeidlich ist. Da erwartet wird, dass die meisten (wenn nicht alle) Anwendungen von IP über IEEE 802.15.4 Header-Komprimierung verwenden werden, wird diese in Abschnitt 10 unten definiert.

5. LoWPAN Adaptation Layer and Frame Format (LoWPAN-Anpassungsschicht und Rahmenformat)​

Die in diesem Abschnitt definierten Kapselungsformate (Encapsulation Formats, im Folgenden als „LoWPAN-Kapselung" bezeichnet) sind die Nutzlast in IEEE 802.15.4-MAC-Protokolldateneinheiten (Protocol Data Unit, PDU). Die LoWPAN-Nutzlast (z. B. ein IPv6-Paket) folgt unmittelbar auf diesen Kapselungs-Header.

Alle über IEEE 802.15.4 übertragenen LoWPAN-gekapselten Datagramme (Datagrams) werden mit einem Kapselungs-Header-Stapel (Encapsulation Header Stack) als Präfix versehen. Jeder Header im Header-Stapel enthält einen Header-Typ (Header Type), gefolgt von null oder mehr Header-Feldern. Im IPv6-Header enthält der Stapel in folgender Reihenfolge: Adressierung (Addressing), Hop-by-Hop-Optionen (Hop-by-Hop Options), Routing (Routing), Fragmentierung (Fragmentation), Zieloptionen (Destination Options) und schließlich die Nutzlast [RFC2460]; im LoWPAN-Header ist eine ähnliche Header-Sequenz: Mesh-Netzwerk (L2)-Adressierung, Hop-by-Hop-Optionen (einschließlich L2-Broadcast/Multicast), Fragmentierung und schließlich die Nutzlast.

Typische Header-Stapel-Beispiele:

LoWPAN-gekapseltes IPv6-Datagramm:

+---------------+-------------+---------+
| IPv6 Dispatch | IPv6 Header | Payload |
+---------------+-------------+---------+

Fall mit Mesh-Adressierung und Fragmentierung:

+-------+-------+-------+-------+---------+---------+---------+
| M Typ | M Hdr | F Typ | F Hdr | HC1 Dsp | HC1 Hdr | Payload |
+-------+-------+-------+-------+---------+---------+---------+

Wenn mehrere LoWPAN-Header im selben Paket verwendet werden, MÜSSEN (MUST) sie in folgender Reihenfolge erscheinen: Mesh-Adressierungs-Header, Broadcast-Header, Fragmentierungs-Header.

5.1. Dispatch Type and Header (Dispatch-Typ und Header)​

Der Dispatch-Typ wird durch die ersten zwei Bits „01" definiert, wobei ein 6-Bit-Selektor den darauf folgenden Header-Typ identifiziert.

Dispatch-Wert-Bitmuster:

  • 00 xxxxxx - NALP: Kein LoWPAN-Rahmen
  • 01 000001 - IPv6: Unkomprimierte IPv6-Adresse
  • 01 000010 - LOWPAN_HC1: HC1-komprimiertes IPv6
  • 01 010000 - LOWPAN_BC0: BC0-Broadcast
  • 01 111111 - ESC: Zusätzliches Dispatch-Byte
  • 10 xxxxxx - MESH: Mesh-Netzwerk-Header
  • 11 000xxx - FRAG1: Erster Fragmentierungs-Header
  • 11 100xxx - FRAGN: Nachfolgender Fragmentierungs-Header

5.2. Mesh Addressing Type and Header (Mesh-Adressierungstyp und Header)​

Der Mesh-Typ wird durch die ersten zwei Bits „10" definiert:

|1 0|V|F|HopsLft| originator address, final address

Felddefinitionen:

  • V: 1 Bit, 0 bedeutet Absenderadresse ist 64 Bit, 1 bedeutet 16-Bit-Kurzadresse
  • F: 1 Bit, 0 bedeutet endgültige Zieladresse ist 64 Bit, 1 bedeutet 16-Bit-Kurzadresse
  • Hops Left: 4 Bit, wird bei jeder Weiterleitung dekrementiert, bei 0 wird das Paket verworfen. 0xF bedeutet, dass ein 8-Bit-Erweiterungsfeld folgt
  • Originator Address: Verbindungsschichtadresse des Absenders
  • Final Destination Address: Verbindungsschichtadresse des endgültigen Ziels

5.3. Fragmentation Type and Header (Fragmentierungstyp und Header)​

Wenn ein Datagramm nicht in einen einzigen 802.15.4-Rahmen passt, SOLL (SHALL) es in Verbindungsschicht-Fragmente aufgeteilt werden. Alle Fragmente außer dem letzten MÜSSEN (MUST) ein Vielfaches von 8 Bytes sein.

Erster Fragmentierungs-Header (FRAG1):

|1 1 0 0 0| datagram_size | datagram_tag |

Nachfolgender Fragmentierungs-Header (FRAGN):

|1 1 1 0 0| datagram_size | datagram_tag |
|datagram_offset|

Felddefinitionen:

  • datagram_size: 11 Bit, kodiert die Gesamtgröße des IP-Pakets (vor der Verbindungsschicht-Fragmentierung). Für IPv6 ist der Wert Payload Length + 40
  • datagram_tag: 16 Bit, alle Fragmente desselben Datagramms haben denselben Tag; der Sender erhöht diesen Wert für aufeinanderfolgende Datagramme
  • datagram_offset: 8 Bit, Fragmentierungsversatz in Einheiten von 8 Bytes, erscheint nur in nachfolgenden Fragmenten

Reassemblierungsregeln:

Der Empfänger identifiziert Fragmente, die zum selben Datagramm gehören, anhand folgender Informationen:

  1. 802.15.4-Quelladresse des Senders (oder Mesh-Absenderadresse)
  2. 802.15.4-Adresse des Ziels (oder endgültige Mesh-Zieladresse)
  3. datagram_size
  4. datagram_tag

Der Reassemblierungs-Timeout MUSS (MUST) auf maximal 60 Sekunden gesetzt werden. Bei Erkennung eines Disassoziierungsereignisses MÜSSEN (MUST) alle teilweise reassemblierten Fragmente verworfen werden.

6. Stateless Address Autoconfiguration (Zustandslose Adressautokonfiguration)​

Dieser Abschnitt definiert, wie ein IPv6-Schnittstellenidentifikator (Interface Identifier) ermittelt wird.

Der Schnittstellenidentifikator [RFC4291] für eine IEEE 802.15.4-Schnittstelle kann auf dem EUI-64-Identifikator [EUI64] basieren, der dem IEEE 802.15.4-Gerät zugewiesen ist. In diesem Fall wird der Schnittstellenidentifikator gemäß der Spezifikation „IPv6 over Ethernet" [RFC2464] aus dem EUI-64 gebildet.

Alle 802.15.4-Geräte haben eine IEEE EUI-64-Adresse, aber auch 16-Bit-Kurzadressen (Abschnitte 3 und 12) sind möglich. In diesen Fällen wird eine „Pseudo-48-Bit-Adresse" (Pseudo 48-bit Address) wie folgt gebildet. Zunächst werden die linksseitigen 32 Bits gebildet, indem 16 Null-Bits an die 16-Bit-PAN-ID angehängt werden (oder, falls die PAN-ID nicht bekannt ist, können 16 Null-Bits verwendet werden). Dies ergibt folgendes 32-Bit-Feld:

16_bit_PAN:16_zero_bits

Anschließend werden diese 32 Bits mit der 16-Bit-Kurzadresse verkettet. Dies ergibt folgende 48-Bit-Adresse:

32_bits_as_specified_previously:16_bit_short_address

Der Schnittstellenidentifikator wird gemäß der Spezifikation „IPv6 over Ethernet" [RFC2464] aus dieser 48-Bit-Adresse gebildet. Im resultierenden Schnittstellenidentifikator SOLL (SHALL) jedoch das „Universal/Local" (U/L)-Bit auf null gesetzt werden, um der Tatsache Rechnung zu tragen, dass dies kein global eindeutiger Wert ist. Für beide Adressformate DARF (MUST NOT) die Null-Adresse NICHT verwendet werden.

Manuell oder durch Software gesetzte abweichende MAC-Adressen KÖNNEN (MAY) zur Ableitung des Schnittstellenidentifikators verwendet werden. Wenn eine solche MAC-Adresse verwendet wird, sollte ihre globale Eindeutigkeitseigenschaft im Wert des U/L-Bits widergespiegelt werden.

Das IPv6-Adresspräfix für die zustandslose Autokonfiguration [RFC4862] für IEEE 802.15.4-Schnittstellen MUSS (MUST) 64 Bit lang sein.

9. Multicast Address Mapping (Multicast-Adresszuordnung)​

Die Funktionalität in diesem Abschnitt DARF (MUST) NUR in Mesh-fähigen LoWPANs verwendet werden. IPv6-Pakete mit einer Multicast-Zieladresse (DST), bestehend aus sechzehn Oktetten DST[1] bis DST[16], werden an folgende 802.15.4-16-Bit-Multicast-Adresse übertragen:

                   0                   1
                   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  |1 0 0|DST[15]* |   DST[16]     |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Abbildung 8: Multicast-Adresszuordnungsformat

Hierbei bezieht sich DST[15]* auf die letzten 5 Bits des Oktetts DST[15], d. h. die Bits 3–7 innerhalb von DST[15]. Das anfängliche 3-Bit-Muster „100" folgt dem 16-Bit-Adressformat für Multicast-Adressen (Abschnitt 12).

Dies ermöglicht die Unterstützung von Multicast innerhalb von 6LoWPAN-Netzwerken, aber die vollständige Spezifikation einer solchen Unterstützung liegt außerhalb des Geltungsbereichs dieses Dokuments. Beispielmechanismen umfassen: Flooding (Überflutung), kontrolliertes Flooding (Controlled Flooding), Unicast zum PAN-Koordinator usw. Es wird erwartet, dass dies durch verschiedene Mesh-Routing-Mechanismen festgelegt wird.

10. Header Compression (Header-Komprimierung)​

Es gibt umfangreiche veröffentlichte und laufende Standardisierungsarbeiten zur Header-Komprimierung. Die Header-Komprimierung für IPv6 über IEEE 802.15.4 unterliegt jedoch anderen Einschränkungen, die im Folgenden zusammengefasst werden:

  • Bestehende Arbeiten gehen von vielen Datenströmen (Flows) zwischen beliebigen zwei Geräten aus. Hier gehen wir von einem sehr einfachen und kontextarmen (Low-Context) Header-Komprimierungsstil aus. Obwohl dieser unabhängig von Datenströmen funktioniert (es kann mehrere geben), verwendet er keinen für einen bestimmten Datenstrom spezifischen Kontext. Daher kann er nicht den Komprimierungsgrad erreichen, den Schemata erzielen, die für jeden zu komprimierenden Datenstrom einen separaten Kontext aufbauen.

  • Angesichts der sehr begrenzten Paketgröße ist eine Integration der Schicht-2- und Schicht-3-Komprimierung sehr wünschenswert, was traditionell nicht gemacht wurde (obwohl sich dies jetzt durch die ROHC (RObust Header Compression, Robuste Header-Komprimierung)-Arbeitsgruppe ändert).

  • Es wird erwartet, dass IEEE 802.15.4-Geräte in Mehrsprung-Netzwerken (Multi-Hop Networks) eingesetzt werden. Die Header-Komprimierung in Mesh-Netzwerken unterscheidet sich jedoch vom üblichen Punkt-zu-Punkt-Verbindungsszenario, in dem Kompressor und Dekompressor direkt und exklusiv miteinander kommunizieren. In IEEE 802.15.4-Netzwerken ist es sehr wünschenswert, dass Geräte header-komprimierte Pakete über beliebige ihrer Nachbarn senden können, mit möglichst wenig vorherigem Kontextaufbau.

Alle neuen Paketformate, die für die Header-Komprimierung benötigt werden, verwenden das in Abschnitt 5 definierte Basispaketformat durch Verwendung verschiedener Dispatch-Werte (Dispatch Values).

Header-Komprimierung kann dazu führen, dass Ausrichtungen nicht auf Oktett-Grenzen fallen. Da Hardware typischerweise keine Daten in Einheiten kleiner als ein Oktett übertragen kann, muss Auffüllung (Padding) verwendet werden. Das Auffüllen erfolgt wie folgt: Zunächst wird die gesamte zusammenhängende Reihe komprimierter Header angeordnet (dieses Dokument definiert nur IPv6- und UDP-Header-Komprimierungsschemata, aber andere Schemata können anderswo definiert werden). Dann werden nach Bedarf Null-Bits hinzugefügt, um auf Oktett-Grenzen auszurichten. Dies kompensiert jede potenzielle Fehlausrichtung durch Header-Komprimierung, sodass nachfolgende Felder (z. B. unkomprimierte Header oder Datennutzlast) an Oktett-Grenzen beginnen und normal fortfahren.

10.1. Encoding of IPv6 Header Fields (Kodierung von IPv6-Header-Feldern)​

Durch den Beitritt zum selben 6LoWPAN-Netzwerk teilen Geräte einen gewissen Zustand. Dies ermöglicht die Komprimierung von Headern, ohne explizit einen Komprimierungskontextzustand aufbauen zu müssen. Daher behält die 6LoWPAN-Header-Komprimierung keinen Datenstromzustand; stattdessen stützt sie sich auf Informationen, die mit dem gesamten Link zusammenhängen. Die folgenden IPv6-Header-Werte werden in 6LoWPAN-Netzwerken als häufig erwartet, daher ist der HC1-Header so konstruiert, dass er sie von Anfang an effizient komprimiert:

  • Version ist IPv6
  • Sowohl IPv6-Quell- als auch Zieladresse sind verbindungslokal (Link Local)
  • Der IPv6-Schnittstellenidentifikator (untere 64 Bits) der Quell- oder Zieladresse kann aus der Schicht-2-Quell- und Zieladresse abgeleitet werden (dies ist natürlich nur für Schnittstellenidentifikatoren möglich, die aus der zugrunde liegenden 802.15.4-MAC-Adresse abgeleitet wurden)
  • Die Paketlänge kann aus Schicht 2 (dem „Frame Length"-Feld in der IEEE 802.15.4-PPDU) oder dem „datagram_size"-Feld im Fragmentierungs-Header (falls vorhanden) abgeleitet werden
  • Traffic Class und Flow Label sind beide null
  • Next Header ist UDP, ICMP oder TCP

Das einzige Feld im IPv6-Header, das immer vollständig übertragen werden muss, ist Hop Limit (Sprungzähler, 8 Bit). Je nachdem, wie gut ein Paket diesem häufigen Fall entspricht, können verschiedene Felder möglicherweise nicht komprimiert werden und müssen daher „inline" (In-Line) übertragen werden (Abschnitt 10.3.1). Dieser häufige IPv6-Header (wie oben beschrieben) kann auf 2 Oktette komprimiert werden (1 Oktett für die HC1-Kodierung, 1 Oktett für Hop Limit), anstatt 40 Oktette.

Ein solches Paket kann im LOWPAN_HC1-Format komprimiert werden, indem der Dispatch-Wert von LOWPAN_HC1 verwendet wird, gefolgt vom LOWPAN_HC1-Header-„HC1-Kodierungs"-Feld (8 Bit), das die verschiedenen unten gezeigten Kombinationen kodiert.

                       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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | HC1 encoding  |     Non-Compressed fields follow...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Abbildung 9: LOWPAN_HC1 (Häufige komprimierte Header-Kodierung)

Die durch die „HC1-Kodierung" kodierten Adressfelder werden wie folgt interpretiert:

  • PI: Präfix inline übertragen (Prefix carried in-line)
  • PC: Präfix komprimiert (Prefix compressed, verbindungslokales Präfix angenommen)
  • II: Schnittstellenidentifikator inline übertragen (Interface identifier carried in-line)
  • IC: Schnittstellenidentifikator weggelassen (Interface identifier elided, kann aus der entsprechenden Verbindungsschichtadresse abgeleitet werden)

HC1-Kodierung (von Bit 0 bis Bit 7):

IPv6-Quelladresse (Bits 0 und 1):

  • 00: PI, II
  • 01: PI, IC
  • 10: PC, II
  • 11: PC, IC

IPv6-Zieladresse (Bits 2 und 3):

  • 00: PI, II
  • 01: PI, IC
  • 10: PC, II
  • 11: PC, IC

Traffic Class und Flow Label (Bit 4):

  • 0: Unkomprimiert; vollständige 8-Bit-Traffic-Class und 20-Bit-Flow-Label werden gesendet
  • 1: Traffic Class und Flow Label sind null

Next Header (Bits 5 und 6):

  • 00: Unkomprimiert; vollständige 8 Bits werden gesendet
  • 01: UDP
  • 10: ICMP
  • 11: TCP

HC2-Kodierung (Bit 7):

  • 0: Keine weiteren Header-Komprimierungsbits
  • 1: Auf die HC1-Kodierung folgen weitere Header-Komprimierungsbits gemäß dem HC2-Kodierungsformat. Bits 5 und 6 bestimmen, welche möglichen HC2-Kodierungen gelten (z. B. UDP-, ICMP- oder TCP-Kodierung).

10.2. Encoding of UDP Header Fields (Kodierung von UDP-Header-Feldern)​

Die Bits 5 und 6 von LOWPAN_HC1 ermöglichen die Komprimierung des Next-Header-Feldes im IPv6-Header (für UDP, TCP und ICMP). Jeder dieser Protokoll-Header kann weiter komprimiert werden. Dieser Abschnitt erklärt, wie der UDP-Header selbst komprimiert wird. Die HC2-Kodierung in diesem Abschnitt ist die HC_UDP-Kodierung, die nur gilt, wenn Bits 5 und 6 in HC1 anzeigen, dass das Protokoll nach dem IPv6-Header UDP ist.

Die HC_UDP-Kodierung ermöglicht die Komprimierung folgender Felder im UDP-Header: Quellport (Source Port), Zielport (Destination Port) und Länge (Length). Das Prüfsummenfeld (Checksum) des UDP-Headers wird nicht komprimiert und daher vollständig übertragen. Das unten definierte Schema ermöglicht die Komprimierung des UDP-Headers auf 4 Oktette statt der ursprünglichen 8 Oktette.

Das einzige UDP-Header-Feld, dessen Wert aus anderweitig verfügbaren Informationen abgeleitet werden kann, ist Length. Alle anderen Felder müssen vollständig oder in teilweise komprimierter Form inline übertragen werden (Abschnitt 10.3.2).

                       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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |HC_UDP encoding|     Fields carried in-line follow...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Abbildung 10: HC_UDP (Häufige komprimierte UDP-Header-Kodierung)

„HC_UDP-Kodierung" für UDP (von Bit 0 bis Bit 7):

UDP-Quellport (Bit 0):

  • 0: Unkomprimiert, inline übertragen
  • 1: Auf 4 Bits komprimiert. Der tatsächliche 16-Bit-Quellport wird berechnet als: P + short_port-Wert. Der Wert von P ist die Zahl 61616 (0xF0B0). short_port wird als 4-Bit-Wert inline übertragen

UDP-Zielport (Bit 1):

  • 0: Unkomprimiert, inline übertragen
  • 1: Auf 4 Bits komprimiert. Der tatsächliche 16-Bit-Zielport wird berechnet als: P + short_port-Wert. Der Wert von P ist die Zahl 61616 (0xF0B0). short_port wird als 4-Bit-Wert inline übertragen

Length (Bit 2):

  • 0: Unkomprimiert, inline übertragen
  • 1: Komprimiert, die Länge wird aus den IPv6-Header-Längeninformationen berechnet. Der Wert des UDP-Längenfeldes entspricht der Payload Length des IPv6-Headers abzüglich der Länge aller Erweiterungs-Header, die zwischen IPv6-Header und UDP-Header vorhanden sind

Reserviert (Bits 3 bis 7)

10.3. Non-Compressed Fields (Unkomprimierte Felder)​

10.3.1. Non-Compressed IPv6 Fields (Unkomprimierte IPv6-Felder)​

Dieses Schema ermöglicht die Komprimierung des IPv6-Headers in unterschiedlichem Maße. Daher müssen nur die unkomprimierten Felder gesendet werden, nicht der gesamte (Standard-)IPv6-Header. Nachfolgende Header (angegeben durch das Next-Header-Feld im ursprünglichen IPv6-Header) folgen unmittelbar auf die unkomprimierten IPv6-Felder.

Das unkomprimierte IPv6-Feld, das immer vorhanden sein MUSS (MUST), ist Hop Limit (8 Bit). Dieses Feld MUSS (MUST) immer auf die Kodierungsfelder folgen (z. B. die „HC1-Kodierung" wie in Abbildung 9 gezeigt, möglicherweise einschließlich anderer zukünftiger Kodierungsfelder). Andere unkomprimierte Felder MÜSSEN (MUST) auf Hop Limit in der durch die „HC1-Kodierung" implizierten Reihenfolge folgen, genau in der oben (Abschnitt 10.1) gezeigten Reihenfolge: Quelladresspräfix (64 Bit) und/oder Schnittstellenidentifikator (64 Bit), Zieladresspräfix (64 Bit) und/oder Schnittstellenidentifikator (64 Bit), Traffic Class (8 Bit), Flow Label (20 Bit) und Next Header (8 Bit). Der tatsächliche nächste Header (z. B. UDP, TCP, ICMP usw.) folgt auf die unkomprimierten Felder.

10.3.2. Non-Compressed and Partially Compressed UDP Fields (Unkomprimierte und teilweise komprimierte UDP-Felder)​

Dieses Schema ermöglicht die Komprimierung des UDP-Headers in unterschiedlichem Maße. Daher müssen nur die unkomprimierten oder teilweise komprimierten Felder gesendet werden, nicht der gesamte (Standard-)UDP-Header.

Unkomprimierte oder teilweise komprimierte Felder im UDP-Header MÜSSEN (MUST) immer auf den IPv6-Header und alle zugehörigen Inline-Felder folgen. Alle vorhandenen UDP-Header-Inline-Felder MÜSSEN (MUST) in derselben Reihenfolge erscheinen, in der die entsprechenden Felder im normalen UDP-Header [RFC0768] erscheinen, also: Quellport, Zielport, Länge und Prüfsumme. Wenn der Quell- oder Zielport in der „short_port"-Notation (wie im komprimierten UDP-Header angegeben) dargestellt wird, nimmt die Inline-Portnummer 4 Bits statt 16 Bits ein.

Obwohl erwartet wird, dass 802.15.4-Netzwerke allgemein Mesh-Routing (Mesh Routing) verwenden werden, definiert die IEEE 802.15.4-2003-Spezifikation [ieee802.15.4] keine solche Fähigkeit. In diesem Szenario führen Geräte mit vollem Funktionsumfang (Full Function Devices, FFDs) Ad-hoc- oder Mesh-Routing-Protokolle aus, um ihre Routing-Tabellen zu füllen (außerhalb des Geltungsbereichs dieses Dokuments). In diesem Mesh-Szenario müssen zwei Geräte nicht direkt erreichbar sein, um miteinander zu kommunizieren. Unter diesen Geräten wird der Sender als „Absender" (Originator) und der Empfänger als „endgültiges Ziel" (Final Destination) bezeichnet. Das Absendergerät kann andere Zwischengeräte als Weiterleitungsknoten (Forwarders) in Richtung des endgültigen Ziels verwenden. Um diese Rahmenübermittlung per Unicast zu realisieren, müssen neben den Hop-by-Hop-Quell- und Zieladressen auch die Verbindungsschichtadressen des Absenders und des endgültigen Ziels enthalten sein.

Dieser Abschnitt definiert, wie die Übermittlung von Schicht-2-Rahmen in einem Mesh-Netzwerk realisiert wird, gegeben die Ziel-Verbindungsschichtadresse des „endgültigen Ziels".

Die Mesh-Übermittlung wird realisiert, indem ein Mesh-Adressierungs-Header (Mesh Addressing Header) vor alle anderen Header in der LoWPAN-Kapselung (Abschnitt 5) eingefügt wird, einschließlich nicht-fragmentierter und fragmentierter Header; vollständiger IPv6-Header; oder komprimierter IPv6-Header gemäß Abschnitt 10 oder anderswo definiert.

Wenn ein Knoten ein Paket über den Standard-Mesh-Weiterleitungsknoten übermitteln möchte (d. h. weil er keine direkte Erreichbarkeit zum Ziel hat), MUSS (MUST) er einen Mesh-Adressierungs-Header einfügen, in dem die Verbindungsschichtadresse des Absenders auf seine eigene gesetzt ist und die Verbindungsschichtadresse des endgültigen Ziels auf das endgültige Ziel des Pakets gesetzt ist. Er setzt die Quelladresse im 802.15.4-Header auf seine eigene Verbindungsschichtadresse und legt die Verbindungsschichtadresse des Weiterleitungsknotens in das Zieladressfeld des 802.15.4-Headers. Schließlich überträgt er das Paket.

Wenn ein Knoten einen Rahmen mit einem Mesh-Adressierungs-Header empfängt, MUSS (MUST) er das „Final Destination"-Feld des Mesh-Adressierungs-Headers betrachten, um das tatsächliche Ziel zu bestimmen. Wenn der Knoten selbst das endgültige Ziel ist, verarbeitet er das Paket auf normale Weise. Wenn er nicht das endgültige Ziel ist, dekrementiert das Gerät das „Hops Left"-Feld; wenn das Ergebnis null ist, wird das Paket verworfen. Andernfalls fragt der Knoten seine Verbindungsschicht-Routing-Tabelle ab, bestimmt, was der nächste Hop in Richtung des endgültigen Ziels sein soll, und legt diese Adresse in das Zieladressfeld des 802.15.4-Headers. Schließlich ändert der Knoten die Quelladresse im 802.15.4-Header auf seine eigene Verbindungsschichtadresse und überträgt das Paket.

Obwohl Knoten an einem Mesh-Routing-Protokoll teilnehmen MÜSSEN (MUST), um als Weiterleitungsknoten zu fungieren, gibt es keine solche Anforderung für die bloße Nutzung der Mesh-Weiterleitung. Es wird erwartet, dass nur „Geräte mit vollem Funktionsumfang" (FFDs) als Router im Mesh-Netzwerk teilnehmen. „Geräte mit reduziertem Funktionsumfang" (Reduced Function Devices, RFDs) beschränken sich darauf, FFDs zu entdecken und sie für alle Weiterleitungen zu verwenden, ähnlich wie IP-Hosts typischerweise einen Standard-Router für den gesamten Off-Link-Verkehr verwenden. Für ein RFD, das Mesh-Übermittlung verwendet, ist der „Weiterleitungsknoten" immer ein geeignetes FFD.

11.1. LoWPAN Broadcast (LoWPAN-Broadcast)​

Zusätzliche Mesh-Routing-Funktionalität wird mit einem Routing-Header (Routing Header) kodiert, der unmittelbar auf den Mesh-Header folgt. Insbesondere besteht der Broadcast-Header aus dem LOWPAN_BC0-Dispatch gefolgt von einem Sequenznummer (Sequence Number)-Feld. Die Sequenznummer wird verwendet, um doppelte Pakete zu erkennen (und hoffentlich zu unterdrücken).

                       1
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0|1|LOWPAN_BC0 |Sequence Number|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Abbildung 11: Broadcast-Header

Felddefinitionen:

Sequence Number (Sequenznummer): Dieses 8-Bit-Feld SOLL (SHALL) jedes Mal inkrementiert werden, wenn der Absender ein neues Mesh-Broadcast- oder Multicast-Paket sendet. Die vollständige Spezifikation, wie dieses Feld zu behandeln ist, liegt außerhalb des Geltungsbereichs dieses Dokuments.

Weitere Implikationen solcher Mesh-Schicht-Broadcasts, z. B. ob sie einem kontrollierten Flooding-Mechanismus zugeordnet werden oder ihre Rolle bei der Topologieerkennung, liegen außerhalb des Geltungsbereichs dieses Dokuments.

Zusätzliche Mesh-Routing-Fähigkeiten, wie die Angabe von Mesh-Routing-Protokollen, Quell-Routing usw., können durch die Definition zusätzlicher Routing-Header ausgedrückt werden, die im Header-Stapel vor Fragmentierungs- oder Adressierungs-Headern stehen. Die vollständige Spezifikation solcher Mesh-Routing-Fähigkeiten liegt außerhalb des Geltungsbereichs dieses Dokuments.

12. IANA Considerations (IANA-Überlegungen)​

Dieses Dokument erstellt zwei neue IANA-Register (IANA Registries), wie unten beschrieben. Zukünftige Zuweisungen in diesen Registern werden gemäß der Richtlinie „Specification Required" (Spezifikation erforderlich) [RFC2434] über die IANA koordiniert. Es wird erwartet, dass diese Richtlinie es anderen (Nicht-IETF-)Organisationen erleichtert, Zuweisungen zu erhalten.

Dispatch-Typ-Feld-Register (Dispatch Type Field Registry)​

Dieses Dokument erstellt ein neues IANA-Register für das Dispatch-Typ-Feld (Dispatch Type Field), das in den Header-Definitionen in Abschnitt 5 gezeigt wird. Dieses Dokument definiert Werte für IPv6, LOWPAN_HC1-Header-Komprimierung, BC0-Broadcast und zwei Escape-Modi (NALP für „kein LoWPAN-Rahmen", ESC erlaubt zusätzliche Dispatch-Bytes). Dieses Dokument definiert dieses Feld als 8 Bit lang. Der Wert 00xxxxxx ist reserviert und wird nicht verwendet, was insgesamt 192 verschiedene Werte ermöglicht, was ausreichend sein sollte. Wenn andere Header-Komprimierungsformate als HC1 definiert werden oder wenn zusätzliche TCP-, ICMP-HC2-Formate definiert werden, wird erwartet, dass diese die reservierten Dispatch-Werte nach LOWPAN_HC1 verwenden. Wenn zusätzliche Mesh-Übermittlungsformate definiert werden, verwenden diese die reservierten Werte nach LOWPAN_BC0.

16-Bit-Kurzadressen-Register (16-bit Short Address Registry)​

Dieses Dokument erstellt ein neues IANA-Register für das 16-Bit-Kurzadressfeld, das in 6LoWPAN-Paketen verwendet wird.

                   0                   1
                   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  |     16-bit short Address      |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Abbildung 12: 16-Bit-Kurzadressformat

Dieses Register MUSS (MUST) die Adresse 0xffff (die 16-Bit-Broadcast-Adresse, die von allen Geräten akzeptiert wird, die den aktuellen Kanal abhören) und 0xfffe enthalten, wie in [ieee802.15.4] definiert. Darüber hinaus MÜSSEN (MUST) 16-Bit-Kurzadressen innerhalb eines 6LoWPAN-Netzwerks diesem Format folgen (Bitfelder von 0 bis 7 referenziert), wobei „x" ein Platzhalter für nicht spezifizierte Bitwerte ist:

Bereich 1, 0xxxxxxxxxxxxxxx: Wenn die 16-Bit-Adresse eine Unicast-Adresse (Unicast Address) ist, SOLL (SHALL) das erste Bit (Bit 0) null sein. Dies lässt 15 Bits für die eigentliche Adresse.

Bereich 2, 100xxxxxxxxxxxxx: Wenn die 16-Bit-Adresse eine Multicast-Adresse (Multicast Address) ist (siehe Abschnitt 9), SOLLEN (SHALL) die Bits 0, 1 und 2 diesem Muster folgen. Dies lässt 13 Bits für die eigentliche Multicast-Adresse.

Bereich 3, 101xxxxxxxxxxxxx: Dieses Muster der Bits 0, 1 und 2 ist reserviert. Zukünftige Zuweisungen sollten der oben genannten Richtlinie folgen.

Bereich 4, 110xxxxxxxxxxxxx: Dieses Muster der Bits 0, 1 und 2 ist reserviert. Zukünftige Zuweisungen sollten der oben genannten Richtlinie folgen.

Bereich 5, 111xxxxxxxxxxxxx: Dieses Muster der Bits 0, 1 und 2 ist reserviert. Zukünftige Zuweisungen sollten der oben genannten Richtlinie folgen.

13. Security Considerations (Sicherheitsüberlegungen)​

Die Methode zur Ableitung von Schnittstellenidentifikatoren (Interface Identifiers) aus EUI-64-MAC-Adressen ist darauf ausgelegt, globale Eindeutigkeit zu wahren, wo immer möglich. Es gibt jedoch keinen Schutz gegen Duplikate durch versehentliche oder gefälschte Zuweisungen.

Die Nachbarschaftserkennung (Neighbor Discovery) in IEEE 802.15.4-Links kann anfällig für die in [RFC3756] beschriebenen Bedrohungen sein. Mesh-Routing wird in IEEE 802.15.4-Netzwerken als weit verbreitet erwartet. Dies bedeutet zusätzliche Bedrohungen durch Ad-hoc-Routing gemäß [KW03]. IEEE 802.15.4 bietet einige Fähigkeiten für die Verbindungsschicht-Sicherheit. Wenn möglich und praktikabel, wird Benutzern dringend empfohlen, solche Vorkehrungen zu nutzen. Dies würde die oben genannten Bedrohungen mindern.

Es wird erwartet, dass ein erheblicher Teil der IEEE 802.15.4-Geräte immer innerhalb ihres PAN kommunizieren wird (d. h. in IPv6-Terminologie innerhalb ihres Links). Als Reaktion auf Kosten- und Stromverbrauchsüberlegungen und in Übereinstimmung mit dem IEEE 802.15.4-Modell für „Geräte mit reduziertem Funktionsumfang" (Reduced Function Devices, RFDs) werden diese Geräte typischerweise den minimal notwendigen Funktionsumfang implementieren. Daher kann die Sicherheit solcher Geräte weitgehend auf den Mechanismen basieren, die IEEE 802.15.4 auf der Verbindungsschicht definiert. Letztere definieren jedoch nur AES-Modi (Advanced Encryption Standard, Erweiterter Verschlüsselungsstandard) zur Authentifizierung oder Verschlüsselung von IEEE 802.15.4-Rahmen, insbesondere ohne Angabe der Schlüsselverwaltung (möglicherweise gruppenorientiert). Weitere Probleme, die in realen Einsatzszenarien zu lösen sind, betreffen die sichere Konfiguration und Verwaltung. Obwohl die vollständige Situation außerhalb des Geltungsbereichs dieses Dokuments liegt, müssen solche Überlegungen beim Einsatz von IEEE 802.15.4-Netzwerken berücksichtigt werden. Natürlich wird auch erwartet, dass einige IEEE 802.15.4-Geräte (die sogenannten „Geräte mit vollem Funktionsumfang" oder „FFDs") Koordinations- oder Integrationsfunktionen implementieren. Diese können regelmäßig mit Off-Link-IPv6-Peers kommunizieren (zusätzlich zu den häufigeren On-Link-Austauschen). Solche IPv6-Geräte werden voraussichtlich gängige Mechanismen (z. B. IPsec, TLS usw.) verwenden, um ihre Ende-zu-Ende-Kommunikation zu schützen.

14. Acknowledgements (Danksagungen)​

Dank gilt den Autoren von RFC 2464 und RFC 2734, da Teile dieses Dokuments nach deren Vorbild verfasst wurden. Geoff Mulligan wird für hilfreiche Diskussionen gedankt, die zur Gestaltung dieses Dokuments beigetragen haben. Die Vorschläge von Erik Nordmark waren entscheidend für den Abschnitt zur Header-Komprimierung. Dank gilt auch Shoichi Sakane, Samita Chakrabarti, Vipul Gupta, Carsten Bormann, Ki-Hyung Kim, Mario Mao, Phil Levis, Magnus Westerlund und Jari Arkko.