1. Einführung (Introduction)

Das Dokument IPv6-over-IEEE 802.15.4 [RFC4944] spezifiziert, wie IPv6 über ein IEEE 802.15.4-Netz übertragen wird, mithilfe einer Adaptionsschicht, die zwischen der Media Access Control (MAC)-Schicht und der IP-Netzwerkschicht sitzt. Ein Link in einem Low-power Wireless Personal Area Network (LoWPAN) ist durch verlustbehaftet, energiearm, niedrige Bitrate und kurze Reichweite charakterisiert; viele Knoten sparen Energie durch lange Schlafperioden. Multicast, wie es in IPv6 Neighbor Discovery (ND) [RFC4861] verwendet wird, ist in einem solchen drahtlosen, energiearmen und verlustbehafteten Netz nicht wünschenswert. Zudem sind LoWPAN-Links von Natur aus asymmetrisch und nicht transitiv. Ein LoWPAN besteht potenziell aus einer großen Anzahl sich überlappender Funkreichweiten. Obwohl eine gegebene Funkreichweite Broadcast-Fähigkeiten hat, ist die Aggregation dieser Reichweiten eine komplexe Non-Broadcast Multiple Access (NBMA)-Struktur [RFC2491] mit im Allgemeinen keinen LoWPAN-weiten Multicast-Fähigkeiten. Link-local Scope wird in Wirklichkeit durch Erreichbarkeit und Funkstärke definiert. Daher können wir ein LoWPAN als aus Links mit undetermined connectivity properties (unbestimmten Konnektivitätseigenschaften) wie in [RFC5889] bestehend betrachten, zusammen mit den entsprechenden dort definierten Annahmen des Adressmodells.

Diese Spezifikation führt die folgenden Optimierungen für IPv6 Neighbor Discovery [RFC4861] ein, die speziell auf energiearme und verlustbehaftete Netze wie LoWPANs ausgerichtet sind:

Vom Host initiierte Interaktionen, um schlafende Hosts zu ermöglichen.
Eliminierung der multicastbasierten Adressauflösung für Hosts.
Eine Host-Adressregistrierungsfunktion unter Verwendung einer neuen Option in Unicast Neighbor Solicitation (NS)- und Neighbor Advertisement (NA)-Nachrichten.
Eine neue Neighbor-Discovery-Option, um 6LoWPAN-Headerkompressionskontext an Hosts zu verteilen.
Multihop-Verteilung von Präfixen und 6LoWPAN-Headerkompressionskontext.
Multihop Duplicate Address Detection (DAD), die zwei neue ICMPv6-Nachrichtentypen verwendet.

Die beiden Multihop-Punkte können durch einen Routingprotokollmechanismus substituiert werden, falls gewünscht; siehe Abschnitt 1.4.

Das Dokument definiert drei neue ICMPv6-Nachrichtenoptionen: die Address Registration Option (ARO), die Authoritative Border Router Option (ABRO) und die 6LoWPAN Context Option (6CO). Es definiert außerdem zwei neue ICMPv6-Nachrichtentypen: Duplicate Address Request (DAR) und Duplicate Address Confirmation (DAC).

1.1. Schwächen von IPv6 Neighbor Discovery (The Shortcomings of IPv6 Neighbor Discovery)

IPv6 Neighbor Discovery [RFC4861] stellt mehrere wichtige Mechanismen bereit, die für Router Discovery, Adressauflösung, Duplicate Address Detection und Redirect-Nachrichten sowie Präfix- und Parametererkennung verwendet werden.

Nach dem Einschalten und der Initialisierung des Netzes in IPv6-Ethernetnetzen tritt ein Knoten der solicited-node Multicast-Adresse auf der Schnittstelle bei und führt dann Duplicate Address Detection (DAD) für die erworbene link-lokale Adresse durch, indem er eine solicited-node Multicast-Nachricht auf den Link sendet. Danach sendet er Multicast-Nachrichten an die all-routers Multicast-Adresse, um Router Advertisements (RAs) anzufordern. Wenn der Host ein gültiges RA mit gesetztem A-Flag (autonomous address configuration) erhält, autokonfiguriert er die IPv6-Adresse mit dem im RA angekündigten Präfix. Außerdem senden IPv6-Router üblicherweise periodisch RAs im Netz. RAs werden an die all-nodes Multicast-Adresse gesendet. Knoten senden Neighbor Solicitation/Neighbor Advertisement-Nachrichten, um die IPv6-Adresse des Ziels auf dem Link aufzulösen. Die für die Adressauflösung verwendeten Neighbor Solicitation-Nachrichten sind Multicast. Das Verfahren zur Duplicate Address Detection sowie die Verwendung periodischer Router Advertisement-Nachrichten setzen voraus, dass die Knoten die meiste Zeit eingeschaltet und erreichbar sind.

In Neighbor Discovery finden die Router Hosts, indem sie annehmen, dass ein Subnetzpräfix auf eine Broadcast-Domäne abbildet, und dann Neighbor Solicitation-Nachrichten multicast senden, um den Host und seine Link-Layer-Adresse zu finden. Außerdem setzt die multicastbasierten DAD voraus, dass alle Hosts, die IPv6-Adressen aus demselben Präfix autokonfigurieren, mittels link-lokaler Multicast-Nachrichten erreicht werden können.

Beachte, dass das L-(on-link)-Bit in der Prefix Information Option (PIO) in Neighbor Discovery auf Null gesetzt werden kann, wodurch der Host keine Multicast Neighbor Solicitation (NS)-Nachrichten für die Adressauflösung anderer Hosts verwendet, aber Router weiterhin Multicast-NS-Nachrichten verwenden, um Hosts zu finden.

Aufgrund der verlustbehafteten Natur drahtloser Kommunikation und einer sich ändernden Funkumgebung kann sich die Menge der Knoten auf einem IPv6-Link durch externe physikalische Faktoren ändern. Somit ist der Link oft instabil, und die Knoten erscheinen bewegt, ohne sich zwingend physisch zu bewegen.

Ein LoWPAN kann zwei Arten von Link-Layer-Adressen verwenden: 16-bit short addresses und 64-bit unique addresses wie in [RFC4944] definiert. Darüber hinaus ist die verfügbare Link-Layer-Payload-Größe in der Größenordnung von weniger als 100 Bytes; daher ist Headerkompression sehr nützlich.

Unter Berücksichtigung der obigen Eigenschaften in einem LoWPAN und des Protokolldesigns von IPv6 Neighbor Discovery [RFC4861] sind einige Optimierungen und Erweiterungen von Neighbor Discovery nützlich für die breite Bereitstellung von IPv6 über energiearme und verlustbehaftete Netze (Beispiel: 6LoWPAN und andere homogene energiearme Netze).

1.2. Anwendbarkeit (Applicability)

In Abschnitt 1 sieht [RFC4861] ein Dokument vor, das den Betrieb von IP über einen bestimmten Linktyp abdeckt und eine Ausnahme von der ansonsten allgemeinen Anwendbarkeit von unverändertem [RFC4861] definiert. Die vorliegende Spezifikation verbessert die Nutzung von IPv6 Neighbor Discovery für LoWPANs, um Energie und Rechenleistung solcher Knoten zu sparen. Dieses Dokument aktualisiert daher [RFC4944], um die Verwendung der hier definierten Optimierungen festzulegen.

Die Anwendbarkeit dieser Spezifikation ist auf LoWPANs beschränkt, in denen alle Knoten im Subnetz diese Optimierungen homogen implementieren. Obwohl angemerkt wird, dass einige dieser Optimierungen auch außerhalb von 6LoWPANs nützlich sein können, z. B. in allgemeinen IPv6 Low-Power and Lossy Networks und möglicherweise sogar in Kombination mit [RFC4861], liegt die Verwendung solcher Kombinationen außerhalb des Geltungsbereichs dieses Dokuments.

In diesem Dokument spezifizieren wir eine Menge von Verhaltensweisen zwischen Hosts und Routern in LoWPANs. Eine Implementierung, die diesem Dokument entspricht, MUST diese Verhaltensweisen implementieren. Das Dokument spezifiziert außerdem eine Menge von Verhaltensweisen (Multihop-Präfix- oder Kontextverteilung und separat Multihop Duplicate Address Detection), die in route-over-Konfigurationen benötigt werden. Eine Implementierung dieser Spezifikation MUST diese Teile unterstützen, es sei denn, die Implementierung unterstützt eine alternative ("substitute") aus einer anderen Spezifikation.

Die in diesem Dokument beschriebenen Optimierungen gelten für unterschiedliche Topologien. Sie sind am nützlichsten für route-over- und mesh-under-Konfigurationen in Mesh-Topologien. Star-Topologie-Konfigurationen werden jedoch ebenfalls von den Optimierungen profitieren, aufgrund reduzierter Signalisierung, robuster Behandlung des nichttransitiven Links und Informationen zum Headerkompressionskontext.

1.3. Ziele und Annahmen (Goals and Assumptions)

Das Dokument hat die folgenden Hauptziele und Annahmen.

Ziele (Goals):

Neighbor Discovery mit einem Mechanismus optimieren, der minimal und dennoch ausreichend für den Betrieb in mesh-under- und route-over-Konfigurationen ist.
Signalisierung minimieren, indem Multicast-Flooding vermieden und die Verwendung von Link-Scope-Multicast-Nachrichten reduziert wird.
Schnittstellen zwischen Hosts und ihren Standardroutern optimieren.
Unterstützung für schlafende Hosts bereitstellen.
Kontextinformationen an Hosts verteilen, wie es für 6LoWPAN header compression [RFC6282] benötigt wird.
Kontextinformationen und Präfixinformationen vom Rand zu allen Routern in einem LoWPAN verbreiten.
Einen Multihop Duplicate Address Detection-Mechanismus bereitstellen, der für route-over-LoWPANs geeignet ist.

Annahmen (Assumptions):

64-bit Extended Unique Identifier (EUI-64) [EUI64]-Adressen sind global eindeutig, und das LoWPAN ist homogen.
Alle Knoten im Netz haben eine EUI-64 Interface ID, um Adressautokonfiguration durchzuführen und doppelte Adressen zu erkennen.
Die Link-Layer-Technologie wird als energiearm und verlustbehaftet angenommen und zeigt undetermined connectivity, wie IEEE 802.15.4 [RFC4944]. Der Adressregistrierungsmechanismus könnte jedoch auch für andere Link-Layer-Technologien nützlich sein.
Ein 6LoWPAN ist so konfiguriert, dass es ein oder mehrere globale IPv6-Adresspräfixe teilt, damit Hosts zwischen Routern im LoWPAN wechseln können, ohne ihre IPv6-Adressen zu ändern.
Bei Verwendung des Multihop-DAD-Mechanismus (Abschnitt 8.2) registriert sich jeder 6LoWPAN Router (6LR) bei allen im LoWPAN verfügbaren 6LoWPAN Border Routers (6LBRs).
Wenn IEEE 802.15.4 16-bit short addresses verwendet werden, wird eine Technik eingesetzt, um die Eindeutigkeit dieser Link-Layer-Adressen sicherzustellen. Das könnte mittels DHCPv6, Address-Registration-Option-basierter Duplicate Address Detection (in Abschnitt 8.2 spezifiziert) oder anderen Techniken außerhalb des Geltungsbereichs dieses Dokuments erfolgen.
Um die Eindeutigkeit von Adressen (siehe Abschnitt 5.4 von [RFC4862]) zu bewahren, die nicht von einem EUI-64 abgeleitet sind, müssen sie entweder im gesamten LoWPAN auf dieselbe Weise zugewiesen oder auf Duplikate geprüft werden. Das kann durch DHCPv6 für die Zuweisung und/oder durch den in Abschnitt 8.2 spezifizierten Duplicate Address Detection-Mechanismus (oder andere zu diesem Zweck entwickelte Protokolle) erfolgen.
Damit 6LoWPAN header compression [RFC6282] korrekt funktioniert, muss der Kompressionskontext für alle Hosts, 6LRs und 6LBRs übereinstimmen, die ein gegebenes Paket senden, empfangen oder weiterleiten können. Wenn Abschnitt 8.1 zur Verteilung von Kontextinformationen verwendet wird, bedeutet dies, dass alle 6LBRs die von ihnen verteilten Kontextinformationen innerhalb eines einzelnen LoWPAN koordinieren müssen.
Diese Spezifikation beschreibt den Betrieb von ND innerhalb eines einzelnen LoWPAN. Die gleichzeitige Teilnahme eines Knotens an mehreren LoWPANs kann möglich sein, liegt aber außerhalb des Geltungsbereichs dieses Dokuments.
Da das LoWPAN seine Präfix(e) im gesamten Netz teilt, ist die Mobilität von Knoten innerhalb des LoWPAN transparent. Inter-LoWPAN-Mobilität liegt außerhalb des Geltungsbereichs dieses Dokuments.

1.4. Substituierbare Funktionen (Substitutable Features)

Dieses Dokument definiert die Optimierung von Neighbor-Discovery-Nachrichten für die Host-Router-Schnittstelle und führt zwei neue Mechanismen in einer route-over-Topologie ein.

Sofern nicht anders spezifiziert (in einem Dokument, das ein Routingprotokoll definiert, das in einem 6LoWPAN verwendet wird), gilt dieses Dokument für Netze mit jedem Routingprotokoll. Da das Routingprotokoll jedoch gute alternative Mechanismen bereitstellen kann, definiert dieses Dokument bestimmte Funktionen als "substitutable", was bedeutet, dass sie durch eine Routingprotokoll-Spezifikation substituiert werden können, die Mechanismen bereitstellt, die denselben Gesamteffekt erzielen.

Die Funktionen, die substituierbar sind (einzeln oder als Gruppe):

Multihop-Verteilung von Präfixen und 6LoWPAN-Headerkompressionskontext
Multihop Duplicate Address Detection

Somit gehen Multihop-Präfixverteilung (die ABRO) und die 6LoWPAN Context Option (6CO) zur Verteilung von Headerkompressionskontexten Hand in Hand. Wenn eine Substitution für eine davon beabsichtigt ist, dann MUST beides substituiert werden.

Leitlinien für Funktionsimplementierung und -deployment werden in Abschnitt 14.