Speicher: Achillesverse von IPv6 – Microsysteme

Kommentieren Drucken
Teil 2 von 3 aus der Serie "Speicher: Achillesverse von IPv6"

Schon mal was von Contiki gehört? Bevor Sie jetzt zu Ihrem Diercke Schulatlas greifen oder bei Karl May nachlesen: eine Alternative zu Contiki ist das Tiny OS. Dieser Name sagt schon eher, worum es geht: Betriebssysteme für Kleinstgeräte, Sensoren und Aktoren. Also eben jenen Elementen, die in Zukunft einen Großteil des IoT ausmachen werden. Beide OS unterstützen seit geraumer Zeit auch IPv6, allerdings nicht in seiner „Reinform“. Dieser Artikel befasst sich mit den Herausforderungen, die durch das Zusammenspiel von Microsystemen und IPv6 entstehen.

Besonderheiten von Microsystemen
Microsysteme stellen Entwickler von Hardware und Protokollen vor eine ganze Reihe von Herausforderungen, die auch noch je nach Anwendungsgebiet unterschiedlich sind: extreme Temperatur, Wasserunempfindlichkeit, Erschütterungsfestigkeit…
Für die Protokolle sind die Umwelteinflüsse natürlich egal, IPv6 funktioniert im Vakuum und bei 1600°C. Trotzdem gibt es eine Reihe von Anforderungen an kleine Systeme, die Rückwirkung auf die Protokolle haben:

  • Wenig Speicher
    Wie viel Speicher ein Microsystem wirklich benötigt, ist natürlich davon abhängig, welche Aufgaben es erfüllt. Es ist klar, dass ein Temperatursensor, der gelegentlich seinen aktuellen Messwert an eine zentrale Sammelstelle meldet, weit weniger Intelligenz und damit RAM benötigt als die Sammelstelle, die Verbindungen zu vielen Sensoren managed. Trotzdem werden beide mit demselben OS betrieben, das jedoch an die Bedingungen angepasst wird. So benötigt der Temperatursensor keinen Treiber für den Drucksensor und umgekehrt. Um trotzdem mal einen Wert zu nennen: Contiki gibt an, dass der Speicherbedarf inkl. der IPv6 und wireless Unterstützung bei 10 kB RAM und 30 kB ROM liegt (vgl. http://www.contiki-os.org/#why). Bei Tiny OS dürfte der Wert noch darunter liegen.
    Granz recht, ihr C64 hatte mehr Speicher.
  • Geringer Stromverbrauch
    Eine weitere Besonderheit dieser Geräte ist, dass viele von ihnen so wenig Strom wie möglich verbrauchen dürfen, insbesondere dann, wenn sie mit Batterien betrieben werden.
    „Dauerhaft online“ ist somit keine Option. Vielmehr werden die Sensoren und Aktoren lange „Schlafphasen“ haben.
  • Kleine Pakete, da unzuverlässige Übertragung
    Wir sind es eigentlich gewohnt, dass Pakete nicht oder zumindest nur sehr selten „kaputt“ gehen. Um möglichst effektiv zu arbeiten, sind die Pakete möglichst groß.
    Es wird jedoch eine Menge von (wireless) Kleinstgeräten geben, auf die das nicht zutreffen wird, da sie in „kritischen“ Umgebungen eingesetzt werden oder mobil sind. Große Pakete hätten keine Chance, in Gänze übertragen zu werden.
    Beispiel: angenommen durchschnittlich erwischt es jedes 500ste Byte. Dann haben Pakete mit einer Länge von 1500 Bytes, wie Ethernet sie zulässt, so gut wie keine Chance jemals übertragen zu werden. Durchschnittlich werden 3 Byte pro Paket fehlerhaft ankommen. Liegt die maximale Paketlänge hingegen bei 127 Bytes, dann erwischt es im Schnitt nur jedes vierte Paket.
  • Kleine Pakete, da wenig Daten
    Wenn man an Aktoren und Sensoren denkt, sind die zu übertragenden Datenmengen aber meist auch gering: die Temperatur, der Druck, die Beschleunigung, Licht an, Licht aus, …
    Große Pakete zur Übertragungsoptimierung sind somit gar nicht notwendig.

Anforderungen von IPv6
Die genannten Anforderungen an kleine „Dinge“ kollidieren mit Anforderungen / Annahmen von IPv6. Ohne Anspruch auf Vollständigkeit wären einige davon:

  • Mindest-MTU 1280 Bytes
    IPv6 „erwartet“, dass Pakete mindestens 1280 Bytes groß sein können. Typische Layer 2 Techniken, die im Umfeld von Kleinstgeräten genutzt werden, wie IEEE802.15.4 (Wireless Personal Area Networks), haben eine MTU von 127 Bytes. Also ziemlich genau ein Zehntel dessen, was IPv6 erwartet.
  • Mangelnder Platz im Paket
    Bei einer MTU von 127 Byte bleibt nicht viel Platz über, wenn alle Header unkomprimiert genutzt würden.

Abbildung 1 zeigt anschaulich das Verhältnis von Overhead zu Nutzdaten. Insbesondere sticht ins Auge, dass der IPv6 Header mehr Platz beansprucht als für Nutzdaten überbleiben. Rechnerisch stehen nicht mal 26% für die zu übertragenden Daten zur Verfügung.

  • „Ständige“ Router Advertisements
    Bei IPv6 werden regelmäßig vom Router RAs gesendet. Außerdem sendet ein Router als Antwort auf jedes Router Solicitation einer beliebigen Station eines Subnetzes, ein RA an die Multicast-Adresse „All Nodes“.
    Diese Anforderung von IPv6 kollidiert offensichtlich mit dem Stromsparmodus der Kleinstsysteme, da sich diese oft im Schlaf befinden und so die RAs nicht bekämen.
  • Mehrere IPv6 Adressen pro Interface
    Anders als IPv4 gibt sich IPv6 nicht mit einer Adresse pro Gerät zufrieden. Vielmehr werden pro Interface mehrere Adressen registriert. Zunächst einmal wären da die Link-Lokalen fe80:: Adressen. Hinzu kommt noch mindestens eine routbare Adresse, sei es als globale Adresse oder als ULA. Dann wäre da noch die Loopback Adresse ::1. Zumindest für die Link-Lokale und die globale Adresse muss auch noch die entsprechende SNMA (Solicitated Node Multicast Adresse) registriert werden.
    Weitere Multicastadressen müssen ebenfalls registriert werden / bekannt sein und bearbeitet werden. Mindestens schon mal die „All Node“ Multicastadresse.
    Jede dieser Adressen ist auch nicht mehr 4, sondern jetzt 16 Byte lang. Was Speicher frisst.
  • IPv6 Adressen anderer Geräte
    Neben den eigenen müssen auch noch IPv6 Adressen anderer Geräte inklusive deren Layer 2 Adressen gespeichert werden. Zumindest schon mal von Default Gateway und, falls es nicht ein und dasselbe Gerät ist, auch von mindestens einer Kontroller-Station.
    Je nach Topologieform und Art der Anwendung kommt da nochmal einiges an Adress-Pärchen zusammen.
    Das wiederum kollidiert mit der Anforderung möglichst wenig Speicher zu verbrauchen.
  • Speicher für obligatorische Protokoll-Funktionen

Anders als bei IPv4 ist die Duplicate Address Detection (DAD) obligatorisch. Router Solicitations und Router Advertisements sind neu, das gab es bislang gar nicht. Für diese neuen Routinen müssen die Funktionen im Betriebssystem hinterlegt werden, was ROM verbraucht. Außerdem müssen die Funktionen natürlich auch bearbeitet werden, d.h. RAM muss während der Funktionsaufrufe zur Verfügung stehen.
All das sind keine „großen“, speicherhungrigen Prozesse, aber wenn man von 10kByte RAM ausgeht, sind auch kleine Mengen gleich ein signifikanter Anteil. Außerdem benötigt jeder Funktionsaufruf natürlich Strom: ohne arbeiten die Prozessoren nun mal nicht.
Wie bereits gesagt, sind dies nur einige der Herausforderungen, denen sich die Protokollentwickler stellen mussten und auch noch stellen müssen. Bislang beschäftigte man sich bei der IETF primär mit den wireless Umgebungen. Diese Arbeitsgruppe ist aber mittlerweile geschlossen, da man erkannt hat, dass es neben wireless auch noch andere Layer 2 Verfahren mit ähnlichen Problemen gibt. Darum kümmert sich die neue 5lo Arbeitsgruppe, die eine weitergefasste Charta hat.

Fazit
Anders als bei den großen Internet-Knoten aus Teil 1, ist Speicher nicht das einzige Problem, das es für IPv6 bei Microsystemen zu lösen gilt. Jedoch ist Speicher auch hier ein zentrales Thema, denn gerade in diesem Umfeld wird jedes Byte, das verbaut wird, gezählt und auch gezahlt.

« Teil 1: Speicher: Achillesverse von IPv6 – InfrastrukturTeil 3: Speicher: Achillesverse von IPv6 – Sicherheit »


zugeordnete Kategorien: IP und IPv6, LAN
zugeordnete Tags: , , , ,

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.