IPv6 und das IoT

2 Kommentare Drucken

Das Internet der Dinge wird gerne angeführt, um IPv6 als unausweichlich zu proklamieren. Der Grund: viele Dinge brauchen viele Adressen. Doch greift diese Betrachtungsweise deutlich zu kurz! Dinge sind nun mal keine humanoiden User. Mit dem Internet of Things (IoT) kommen daher Anforderungen auf das Internet aber auch auf die Intranets von Unternehmen zu, die es so noch nicht gab. Einige dieser Anforderungen zeichnen sich schon jetzt am Horizont ab, andere werden hinzukommen.

Das erste Gespräch, das ich auf dem ersten ComConsult IPv6 Forum geführt habe, war mit Mitarbeitern eines mittelständischen Unternehmens, das Thermen herstellt. Deren wichtigste Frage war: wie viel mehr Speicher benötigen wir, wenn wir unsere Geräte auf IPv6 umstellen? Als einfacher „User“ dieser Geräte überrascht einen diese Frage: Speicher kostet doch so gut wie nichts. Und doch, denkt man darüber nach, so zeigt diese Anekdote einige interessante Aspekte vom Zusammenhang zwischen „Dingen“ und IPv6 auf:

  1. Gerade Hersteller von „Dingen“ müssen sich frühzeitig mit IPv6 intensiv beschäftigen.
  2. Geräte haben andere Anforderungen als Menschen.
  3. IPv6 hat Auswirkungen auf die verbaute Hardware.

Bevor man die Anforderungen des IoT betrachten kann, sollte man zunächst mal definieren, was diese „Dinge“ eigentlich sind. Im Sinne dieses Artikels handelt es sich um Gegenstände, die

  • ein IP-Interface haben,
  • mit dem Inter- oder Intranet verbunden sind,
  • sehr spezifische Funktionen erfüllen,
  • auch ohne Userinteraktion kommunizieren.

Beispiele wären:

  • Fernwartung
    Das betrifft alle möglichen Gerätschaften, von der angesprochen Gastherme, über Autos bis hin zu Containerkränen in Häfen. Statt regelmäßiger Wartungsintervalle melden diese Geräte spezifische Kenndaten an die Wartungsunternehmen, aus denen man entnehmen kann, ob eine Wartung fällig ist und bestenfalls sogar, welche Komponenten ausgetauscht werden müssen.
  • Gebäudesicherung
    Alarme werden noch heute oft per ISDN an die Sicherheitsfirmen übermittelt. Aber ISDN ist eine aussterbende Technik. Hinzu kommt, dass die Datenraten schon langen nicht mehr ausreichen, um heutige Anforderungen zu erfüllen. Denken wir nur an Überwachungskameras, bei denen schon der Datenstrom einer einzelnen die Kapazität einer ISDN-Leitung bei weitem übersteigt.
  • Gebäudesteuerung
    Bügeleisen nicht ausgeschaltet? Heizung nicht in den Urlaubsmodus versetzt? Jeder kennt diese Fragen. Eine App auf dem Smartphone und schon kann man die Steckdose ausschalten oder die Temperatur der Heizungsanlage noch vom Urlaubsort aus reduzieren. So verspricht es uns bereits heute die Werbung.
  • Sensor- und Steuertechnik
    Bereits seit vielen Jahren sind Sensoren in der Produktion an Netzwerke angeschlossen. Lange dominierten hier proprietäre Busverfahren. Zunehmend geht aber auch hier die Entwicklung zu den Standards Ethernet und IP.
  • „Ein-Knopf-Anwendungen“
    Es gibt eine Vielzahl von Anwendungen, die quasi digital sind, da sie nur zwei Zustände kennen: Not-Aus, Mann über Bord, Tor auf / Tor zu. Diese lassen sich über den Druck eines einzelnen Knopfes steuern. Auch hier wird IP zunehmend an Bedeutung gewinnen. Sicher wird das nicht bei den lebenswichtigen Anwendungen anfangen (Not-Aus), aber ein einfacher Tor auf / Tor zu Knopf erfüllt dieselbe Funktion. Ist die Technik dann erprobt und ausgereift, wird eines Tages aus dem Auf-Zu-Knopf ein Not-Alarm.
  • Autos
    Neben der Server-Client- kommt noch die Client-Client-Kommunikation hinzu. Miteinander kommunizierende Autos sind keine ferne Science-Fiction mehr, sondern sind bereits in der Entwicklung.
    Hinzu kommt die Kommunikation im Fahrzeug: eine Unmenge von Sensoren und Reglern reden miteinander. Auch hier geht die Entwicklung in Richtung Ethernet und IP.
  • Medizintechnik
    Schon heute sind viele Geräte eines Krankenhauses an das Intranet angebunden: radiologische Geräte, Überwachungsmonitore, etc. Salopp gesprochen, wird es bei der Medizintechnik eine ähnliche Entwicklung geben wie bei der Fernwartung: Sensoren werden bei gefährdeten Personen lebenswichtige Funktionen überwachen und im Bedarfsfall den Notruf auslösen.

Diese Geräte unterscheiden sich signifikant von denen, die man bislang mit dem Internet verbindet: PCs, Server, Smartphones und Tablets.

Wesentliche Unterschiede zu diesen „klassischen“ Geräten sind:

  • Eingeschränkte, spezifische Funktionalität
    Ein Temperaturfühler benötigt kein Betriebssystem mit graphischer Oberfläche und ein Alarmknopf keine USB-Schnittstelle. Während ihres gesamten Lebenszyklus wird sich ihre Funktion nicht ändern und auch nicht erweitert werden. Ein Softwareupdate kann aus einem Alarmknopf nun mal keinen Temperaturfühler machen.
  • Langlebigkeit
    Tauscht man PCs oder Smartphones relativ regelmäßig gegen neue Geräte aus, so leben Gasthermen verglichen damit ewig.
  • Bauformen
    Es ist offensichtlich, dass man sich kein iPhone als Türöffner an die Wand hängt, und dass ein Tablet zu groß ist für die Vielzahl benötigter Sensoren in einem Auto. Platz- und Gewichtsparen sind wesentliche Anforderungen bei der Entwicklung. In Autos müssen Sensor- und Regeltechnik stoßfest sein, Gegensprechanlagen wiederum wasserdicht gegen Regen.
  • Eingeschränktes Userinterface
    Einen Gegensprechanlage als „Userinterface“ zu bezeichnen ist schon hoch gegriffen, der ABS-Sensor im Auto hat gar keines mehr. Bestenfalls können die Entwickler über Terminal-Session noch darauf zugreifen. Der eigentliche User ist der Sensor selbst.
  • Funktionsspezifische Kommunikationsformen und –anforderungen
    In der Mess- und Regeltechnik gibt es sehr genaue Anforderungen an Ausfallsicherheit, Umschaltzeiten und Delay. Ob und wann ABS greift, kann über Leben und Tod entscheiden. Der ursprüngliche Best-Effort Ansatz von IP oder Ethernet ist dafür völlig ungeeignet.
  • Client-Client-Kommunikation
    Sei es bei der Haussteuerung, den Smartgrids oder der Auto-Auto-Kommunikation, die sich in der Entwicklung befindet: die Ära, in der ein Client mit der Kommunikation beginnt und der Server antwortet, geht zu Ende. Client-Client und Server-Client-Verbindungen werden zunehmen.

Was bedeuten nun diese Unterschiede für Netzwerke insb. in Hinblick auf IPv6?
Nicht nur das IoT ändert die Inter- und Intranet-Paradigmen, auch IPv6 macht das. Wäre der einzige Unterschied, dass IPv6 „nur“ 4x längere Adressen hat, müsste man sich nicht weiter damit beschäftigen. Fakt ist aber, dass es im Hinblick auf obige Anforderungen des IoT einige Probleme löst, dafür aber auch neue aufwirft.

Gelöst werden insbesondere zwei Anforderungen: ausreichend Adressen für alle Dinge, die da kommen werden, und die Wiedereinführung der Any-to-Any-Kommunikation.

Soweit die gute Nachricht, nun die schlechten:

Die Bauform bedingt kleine Prozessoren und wenig Speicher. Man kann es fast als Naturgesetz betrachten, dass jedes Betriebssystem-Update mehr Speicher braucht als das davor. Hinzu kommt, dass während des Updates erheblich mehr Speicher gebraucht wird. Die Geräte laufen so wie sie ausgeliefert wurden bis sie verschrottet werden. Bei größeren kann ggf. noch die Platine getauscht werden, bei Alarmknöpfen wohl eher nicht. Darum ist bei vielen sehr kleinen Geräten/Sensoren überhaupt nicht vorgesehen, dass es ein Update gibt.
Nimmt an nun noch die Langlebigkeit solcher Komponenten hinzu, folgt daraus, dass diese möglichst bald auch IPv6 unterstützen müssen, wenn sie in 15 Jahren noch funktionieren sollen. Ist der Speicherbedarf von IPv4 aber noch relativ deterministisch und gering, so ist das bei IPv6 erheblich mehr. IPv6 Interface habe nicht mehr wie bei IPv4 eine einzelne IP Adresse. Link-Locale und globale Adresse machen zusammen schon zwei. Hinzu kommen die Reservierungen für Muliticasts, insbesondere den eigenen SNMA-Multicasts, Routing-Einträge, Neighbor-Tables, etc.

Um dieses Problem zu adressieren, müssen zum einen die Entwickler der Komponenten genügend Speicher vorsehen, wobei ihnen heute niemand sagen kann, wie viel mehr das im Vergleich zu IPv4 ist. Zum anderen müssen Adresskonzepte und auch Adressänderungskonzepte diese spezielle Problematik berücksichtigen.

IPv6 sieht ebenso wenig wie IPv4 einen deterministischen Transport vor. Hat eine Anwendung entsprechende Anforderungen an Ausfallsicherheit, maximaler Umschaltzeit, Delay und Bandbreite, so müssen diese durch die Layer 2 Protokolle gelöst werden.
Ein weiteres, aktuelles Problem sind die „neuen“ Angriffsvektoren. Viele sind schon bekannt, aber deren Lösungen sind in den Standardlibraries der Programmiersoftware oder den Betriebssystemen noch nicht implementiert oder behoben. D.h. Geräte, die mit diesen Sicherheitslücken ausgeliefert werden, werden diese Lücken auch in 15 Jahren noch haben. Jedes Netzdesign muss das berücksichtigen und entsprechende Schutzzonen für die „Dinge“ bereitstellen. Das bedeutet aber, dass das alte IPv4 Design u.U. nicht auf IPv6 übertragbar ist.

zugeordnete Kategorien: IP und IPv6, LAN, Virtualisierung, Web-Techniken
zugeordnete Tags: , , ,

Sie fanden diesen Beitrag interessant? Sie können



2 Kommentare zu "IPv6 und das IoT":

  1. Hauser Kurt schreibt:

    Ja, ein sehr guter Artikel.

    Es ist für mich als Dozent im Themengebiet Kommunikationstechnik sehr wertvoll, dass Spezialisten gezielt solchen Fragen nachgehen und treffende, ausgezeichnete Zusammenfassungen zu den Fragen verfassen.

  2. Wolfgang Rameil schreibt:

    Äusserst interessanter Artikel!

    Bravo und Danke schön

    Wolfgang Rameil

Anmerkungen, Fragen, Kommentare, Lob und Kritik:

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

*

.