IPv6 und IoT

IPv6 – wo stehen wir?

IPv6 ist alles andere als eine neue Erfindung. In Schulungen der ComConsult wurden bereits in den späten 1990er-Jahren im „was gibt es Neues“-Teil erste Einblicke gegeben. Die Internet Engineering Task Force IETF hat mit ihren Standardisierungsaktivitäten über Requests for Comments (RFCs) zu IPv6, also früh, auf die knapper werdenden IPv4-Adressvorräte reagiert.

Nachdem Basics und unter IPv4 etablierte Dienste wie DNS und DHCP über RFCs zur v6-Variante aus dem Draft-Stadium herausgewachsen waren (ca. 2005 bis 2007), gab es am Markt bei IPv6-fähigen IT-Produkten Bewegung. Es folgten sogar Herstelleraussagen zur priorisierten Produktentwicklung auf IPv6-Basis.

Die Bedeutung der Verwendung von IP-Netzen nahm parallel unaufhaltsam zu. World Wide Web als selbstverständliche Informationsquelle, VoIP, erste Ideen eines Internet of Things mit vielen IoT-Netzteilnehmern erhöhten den Druck beim Adressbedarf.

Der Countdown bis zum Fehlen benötigter öffentlich verwendbarer IPv4-Adressen lief. Entsprechende Meldungen wurden eindringlicher formuliert und zuletzt sogar in allgemeinen Nachrichtensendungen gebracht.

Fake News waren das nicht: Anfang 2011 wurde der verbliebene IPv4-Adressraum gleichmäßig an die weltweit regionalen Vergabestellen verteilt. Im November 2019 hat das unter anderem für Europa zuständige RIPE NCC seinen Vorrat aufgebraucht. Es kann seitdem nur noch minimale IPv4-Adressblöcke auf Warteliste und auf Basis von Rückläufern vergeben.

Also: Wer in 2021 neu ans Internet will, braucht eine IPv6-Adresse für sein Gerät? Wer eine moderne Netzinfrastruktur aufbaut, wird sofort IPv6 einführen und strategisch dorthin migrieren müssen? Wer auf IPv4 verharrt, schließt sich bald vom Internet und von neuen Produktangeboten aus und lebt demnächst in der elektronischen Steinzeit? Ist das so?

Fragt man IT-Planer und -Betreiber zu Projekten und IT-Betrieb der letzten Jahre, lautet die Antwort oftmals: „Produktauswahlen haben IPv6 berücksichtigt, gezielt genutzt wird IPv6 noch nicht“. Die Generation „Smartphone always online“ fragt in Gastumgebungen zielsicher nach „WLAN“ und meint eigentlich Zugang zu einem Netz mit Internetanschluss. Nach IPv6 wird nicht gefragt, wozu auch: „Internet geht, wenn man Netz hat“, und die fallweise genutzte IP-Version merkt man gar nicht.

Warum ist das so − früheren Vorhersagen zum Trotz?

Einflussgrößen, über deren Kommentierung vor dem „Verschlafen von IPv6“ gewarnt wurde, waren doch wichtige Parameter aus der Praxis.

Jedoch waren die Prognosen dazu teilweise falsch! Tatsächliches Hersteller- und Providerverhalten bieten verschiedene Optionen, in internen Netzen vorerst noch auf IPv4-only zu setzen. Dies gilt inklusive der durch die Corona-Pandemie zur Standard-Ausstattung mutierten Webkonferenz- und Collaborations-Dienste.

Die notwendige Umsetzung zwischen IPv4- und IPv6-Kommunikationspartner kann man über Komponenten im eigenen Perimeter zum Internet lösen. Diese muss man nicht zwingend selbst betreiben (Outsourcing). Man kann auch gleich die eigene Sichtbarkeit für IPv6-Nutzer und die Erreichbarkeit von IPv6-Websites als Teil einer Providerdienstleistung, über die man ans Internet gebracht wird, delegieren.

Der knappe Vorrat an nicht-privaten IPv4-Adressen wurde und wird zudem mühselig gestreckt. Intensiver Einsatz der eigentlich als Behelfslösung einzustufenden Network Address Translation NAT wird trotz des damit verbundenen Problem- und Pannenpotenzials nicht gescheut. Ebenso wird der betriebliche und organisatorische Aufwand, der mit Rückgabe oder direktem Inhaberwechsel registrierter IPv4-Adressen verbunden ist, in Kauf genommen.

Für die Betreiber sind das keine angenehmen Lösungswege. Mit solchen Umgehungslösungen, die einen Einstieg in IPv6-Ende-zu-Ende aufschieben, sind Probleme und Mehraufwand verbunden. Manche Lösungen sind knifflig und bei intensiver Nutzung potenziell störanfällig. Manche Detailprobleme sind gar nicht lösbar – unzufriedene Kundschaft droht. Bewertung: Hier wird eine Galgenfrist für IPv6-Aufschieber erkämpft und nicht eine mit SLA-Qualität zu dauerhaft günstigen Service-Preisen realisierbare Alternative geschaffen.

Einsatzerfahrung durch aktive Nutzung von IPv6, auch Ende-zu-Ende in internen Netzen, ist mittlerweile gegeben. Eine „das ist alles noch zu neu und unzuverlässig“-Argumentation trägt immer weniger.  Dies kann man daran erkennen, dass wesentliche IETF-RFCs zu IPv6 durch neuere Versionen kontinuierlich aktualisiert bzw. sogar abgelöst worden sind.

Beispiele, die ein entsprechendes Signal geben, sind etwa:

• RFC 8106 Router Advertisement Options für DNS Configuration
  Dieser in 2017 erschienene Standard ist die nochmalige Aktualisierung von RFC 6106, der in 2010 eine bereits in 2007 zur Diskussion gestellte Idee auf den Standards Track der IETF hob. Durch ein Router Advertisement können Teilnehmer in angeschlossenen IP-Subnetzen Informationen zu verfügbaren DNS-Servern erhalten (DNS RA). Wer dies einsetzt, braucht keinen DHCPv6-Server und keine DHCPv6-Relays, um derartige Informationen zu verteilen.
  IPv6-vernetzte Geräte können auch ohne DHCP-Server netzwerkfähig gemacht werden, indem IPv6-Adressen aufbauend auf Router Advertisements erzeugt und über Neighbor Discovery lokale Default Gateways gelernt werden.
  RFC 8106 berücksichtigt offenbar Erkenntnisse aus 10 Jahren. Ohne Praxis-Input hätte man es beim Stand von RFC 6106 belassen können.
  RFC 8106 zieht ursprüngliche Empfehlungen zurück, die den Implementierer einschränkten bzw. für den Betreiber erheblichen Aufwand bedeuten konnten. So wird die Absicherung von Neighbor Discovery  über SEcure Neighbor Discovery  (SEND) nicht mehr als deutliche Empfehlung ausgesprochen, sondern nur noch als Option beschrieben. Wer ein Produktangebot unter Berufung auf diesen RFC anbieten will, hat so mehr Gestaltungsfreiheit.

• RFC 8504 IPv6 node requirement aus 2019 erhebt die Themen einer mit RFC 4294 (2006) beginnende Kette von „informational“ RFCs gleichen Titels in eine neue Kategorie.
  Wer auf Basis dieses RFCs IPv6-Software implementiert bzw. einsetzt, kann sich auf einen Erkenntnisstand abstützen, der jetzt formal als „Best Current Practices“ eingestuft ist.
  In RFC 8504 erfolgende Aktualisierungen gegenüber dem Vorgänger RFC 6434 greifen dabei zum Beispiel das schon erwähnte Thema DNS RA vs. DHCPv6 auf.
  Sofern eine IP-Software-Implementierung DHCPv6 umfasst, soll sie gemäß RFC 8504 DNS-relevante Optionen umfassen, die auf dem DHCPv6-Client die Verwaltung von Listen erfordert. Andererseits wird gefordert, dass jede IPv6-Client-Lösung die DNS RA unterstützen soll.
  Wer also IPv6-Software schlank halten will, kann konform zu RFC 8504 auf DHCPv6-Unterstützung, inklusive der DNS-Listen-Optionen, verzichten.

Einverstanden, RFCs sollten erst einmal die Hersteller lesen. Für deren Kunden ist das zunächst langweilig und meist weit weg von ihrem Kerngeschäft.

Aber: Die gezielt herausgepickten Beispiele setzen für die Praxis wichtige Zeichen.

Die herstellerübergreifend gedachten RFC-Spezifikationen formulieren Vorgaben und Empfehlungen aus mehrjähriger Praxis mit IPv6. Sie bieten dabei Möglichkeiten für schlanke Implementierungen und vereinfachte Betriebsmodelle für IP-basierte Vernetzung.

Dies kann neue Impulse für IPv6-basierte Angebote geben. Eine parallele Entwicklung und zugehöriger Support für IPv4 und IPv6 sind für die Hersteller und die Support-Strukturen allerdings teuer.

Kommt es hier eventuell zu ersten Produktpaketen, die ihre volle Stärke nur bei IPv6-Vernetzung ausspielen?

IoT als treibender Bedarf für IPv6 – oder doch nicht?

Die Idee eines Internet der Dinge ist nicht brandneu. Neue Lösungen sollen auf Basis einer Vernetzung flexibel und deutlich intelligenter eingesetzt werden können als isolierte Geräte und Maschinenaufbauten. Drängen solche Lösungen ans IP-basierte Netz, kann das mit sehr großen Anzahlen an neuen Netzanschlüssen und IP-Adressen verbunden sein.

Warum ein Internetanschluss Teil der Idee ist: Die Ansprechbarkeit solcher Lösungen auch von außerhalb des eigenen privaten Netzes erweitert die Möglichkeiten, die IoT-Komponenten in eine digitale Gesamtlösung einzubinden.

Statt alle Intelligenz auf das einzelne Gerät oder eine interne Infrastruktur bringen zu müssen, können Wartung und Hersteller-Support, Rückmeldungen bzgl. Nutzererfahrungen, Sprachsteuerung usw. flexibler ermöglicht und um Neues erweitert werden.

Doch auch klassische Aufgaben wie zentrale Zusammenführung von Meldungen, zentrale Steuerung, Monitoring und Management einer IoT-Gesamtlösung können öffentlich nutzbare Adressen sinnvoll machen.

Wenn die zentralen Werkzeuge oder gleich die Wahrnehmung der damit zu erledigenden Aufgaben ausgelagert werden sollen, ist das sogar ohne NAT via Internet realisierbar (geeignet abgesichert, versteht sich). Wer als Hersteller solche Optionen sofort oder als spätere Ausbaustufe ermöglichen will, berücksichtigt aktuelle as-a-Service- und Cloud-artige Betriebsmodelle.

Derartige Angebote zu IoT-Lösungen „aus der Cloud“ sind auch keine Spekulation, es gibt sie − oft sogar als vom Anbieter favorisierte Variante.

Kommt hier also der Druck auf den Adressbedarf, der mit Notlösungen zur Streckung der IPv4-Reichweite nicht aufgefangen werden kann?

Prognosen, die mit den Meldungen zum beschriebenen Countdown bzgl. registrierbarer IPv4-Adressen einhergingen, haben IoT klar als so wirkenden Technologie-Trend gesehen. Klingt schlüssig, kann jedoch auch nicht ganz so zwingend sein, siehe die Praxis:

Lösungen im Bereich Smart Technologies sind schon da. Das Produktangebot wird stetig größer und richtet sich nicht nur an den Consumer-Markt. Geschäftskunden-Produktlösungen für intelligente Gebäudetechnik fallen nicht unter „kleine Lösungen für den innovativen Hausgebrauch“ und werden in größeren Projekten zur Modernisierung oder Ersteinrichtung von Gebäuden eingesetzt.

Trotzdem erhält man von befragten Planern und Betreibern entsprechender Umgebungen oft die Antwort: IPv6 werde dafür nicht genutzt. Die Möglichkeit sei Netzwerk-seitig vorbereitet, evtl. schon ein IPv6-Adresskonzept da, das auch den IoT-Bereich grob berücksichtigt, aber mehr nicht.

Ein anderer Versuch, sich ein Bild zu machen, kann über Produktrecherchen und Sichtung technischer Informationen zu Produkten erfolgen. Nutzt man hier einfache Suchmuster wie „IPv6“, kann man ebenfalls den ersten Eindruck bekommen, IPv6 spiele in solchen Marktsegmenten keine ernstzunehmende Rolle.

Waren also auch hier alle Prognosen falsch und wird IPv4 hier ebenfalls erfolgreich „gestreckt“? Oder stimmt gar der Verdacht, dass Hersteller sich mehrheitlich zu einem von IP-Netzen unabhängigen alternativen Weg entschlossen haben? Was wird denn dann zur Vernetzung eingesetzt?

Als Erläuterungsversuche bekommt man auf Nachfrage Antworten wie „Zigbee, und das braucht kein IP auf der Netzwerkebene“. Wer diese Antwort aus einem konkreten Projekt gibt, wird den Fall durchaus wahrheitsgemäß berichten. Man darf daraus allerdings keine falschen Schlüsse ziehen und unkritisch verallgemeinern. Recherchiert man genauer, stellt man fest:

• Installationen der beschriebenen Art ohne IP-Kommunikation nutzen Zigbee oder eine andere drahtlose Vernetzungsbasis, etwa Bluetooth, für kleinere Aufbauten.
• Das Zentrum solcher Aufbauten ist oft eine zentrale Komponente, die etliche Intelligenz auf sich vereinigt und zudem als Gateway zum Rest der (IP-basiert vernetzten!) Umgebung wirkt.

Für erste vorsichtige Startversionen von IoT-Produkten, die auch nur kleinere Anschlusszahlen abdecken müssen, kann man das erfolgreich so machen.

Wichtige Anforderungen wie Skalierbarkeit, Ausfallsicherheit durch Redundanz und Kombinierbarkeit verschiedener Hersteller sind bei den so möglichen Topologien aber erschwert. Die zentrale Komponente wird zum kritischen Faktor: Man kann sie leicht mit Aufgaben überfrachten und zum Engpass werden lassen. Als Single-Point-of-Failure in einfachen Aufbauten ist sie dann ein Betriebsrisiko.

Stellt sie die Verbindung in Richtung übrige Netzinfrastruktur und Internet her, kommt hier ein neuer Anschluss als Ausgangspunkt wichtiger Kommunikation ins bestehende Netz. Hier sind klassische Sicherheitsfragen zu klären.  Der zentrale IoT-Knotenpunkt wird auch hier einen Teil der Maßnahmen mittragen müssen. Wenn das ein offensichtlich betrieblich brisanter Cocktail werden kann, warum sollte man dann diese Komponenten auch noch zum Mittelpunkt einer Vernetzungsstruktur machen und dabei auf bewährte Netzprotokolle wie IP verzichten?

Wird herstellerseitig absichtlich ohne IP verfahren, um etwa von der IETF unabhängig zu sein und eigene Ideen an den Markt zu bringen? Hat die IETF verschlafen, Detailprobleme von IoT-Netzen über entsprechende Working-Group-Aktivitäten aufzugreifen, sodass sich Hersteller zum Alleingang gezwungen sehen? Beide Annahmen sind falsch!

IoT-Lösungen, insbesondere bei drahtloser Vernetzung, haben technische Besonderheiten. Flexibel und zahlreich Adressen zur Verfügung zu stellen ist nur Teil der Aufgabenstellung der bedarfsgerechten Vernetzung. IPv6 ist da ohne optimierende Optionen keine ideale Basis:

In etlichen praxisrelevanten IoT-Konstellationen wird drahtlos vernetzt, um kurze und in der Praxis dann oft fliegend verlegte Kabelverbindungen zu vermeiden. Ein solches Drahtlosnetzwerk ist im Sinne der Zielsetzung auf sehr kurze Distanzen beschränkt.

Das IEEE hat diese Konstellation unter dem Begriff Wireless Personal Area Network (WPAN) über eine eigene 802.15-Working Group aufgegriffen. Beispielsweise setzt Zigbee auf den in IEEE 802.15.4 für geringe WPAN-Übertragungsraten erfolgten Spezifikationen auf. Es bietet eine Basis, 802.15.4-basierende Lösungen verschiedener Hersteller interoperabel zu machen.

Da in WPAN die drahtlos zu überbrückenden Entfernungen gering sind, ist eine hohe Sendeleistung nicht notwendig. Teure und platzraubende Netzteile sind da nicht erste Wahl für die Stromversorgung. Batteriebetriebene IoT-Teilnehmer sind deutlich handlicher und auch möglich. Allerdings entsteht hier eine Betriebs- und Logistik-Herausforderung − gerade bei insgesamt hoher Stückzahl solcher Teilnehmer. Die Notwendigkeit häufiger Batteriewechsel muss vermieden werden.

Geringer Energieverbrauch ist also eine wichtige Anforderung, ein gängiger Begriff dazu lautet: Low-Power WPANs, kurz LoWPANs.

IPv6-Header mit langen 128-Bit-Adressen sind da nicht gerade attraktiv!

Es klingt auch für nicht-Experten plausibel, wenn man vereinfachend sagt: Ein Mehr an zu übertragender Information benötigt wegen des aufwändigeren Sendevorgangs auch mehr Energie. Mögliche Vorteile, punktuell Betriebsaufgaben wie die Adressverteilung über IPv6-Features zu vereinfachen, verblassen daneben. Ohne eine Lösung für das Energieproblem stechen solche IPv6-Trümpfe nicht.

Die IETF hat den Bedarf durchaus frühzeitig erkannt, siehe etwa den informational RFC 4919 von 2007. Dieser erfasst das Low-Energy-Thema und weitere WPAN-Spezifika, formuliert Ziele und benennt dazu Herausforderungen, die über geeignete IPv6-Optionen zu meistern sind. Zwei wesentliche Hausaufgaben dieser Art sind eine geschickte Header-Kompression sowie ein wenig geschwätziges Routing-Protokoll, das WPAN-Mesh-Netze ermöglicht. Natürlich darf die Nutzung solcher Lösungen nicht ihrerseits die Energiebilanz wieder verderben. Das klingt nach einem kniffligen Problem, an dem man auch scheitern könnte.

IoT-relevante Aktivitäten der IPv6-Standardisierung – es gibt sie!

Ein problematisierender informational RFC schafft noch keine Lösungen. Tatsächlich hat die bei der IETF als 6LoWPAN (für: IPv6 over LoWPAN) überschriebene Aufgabenliste mehrere RFC-Update-Ketten in Gang gesetzt. Der aktuelle Stand ist noch relativ frisch:

• Neues zur Headerkompression bietet insbesondere ein RFC 8066 aus 2017.
• Offenbar wurden für 6LoWPANs ebenfalls Optimierungen an IPv6 Neighbor Discovery (ND) als nötig angesehen.
  Dieses Thema wurde entlang einer Kette RFC 4944 (Transmission of IPv6 Packets over IEEE 802.15.3 Networks, 2007) – RFC 6775 (ND Optimization for 6LoWPANs, 2012) – RFC 8505 (punktuelle Erweiterungen, 2018) bearbeitet. Sicherheitsrelevante Aktualisierung über RFCs 8928 (Ende 2020) runden die Ergebnisse ab.
• Als schlankes Routing-Protokoll im Sinne des Mesh-Bedarfs wurde das IPv6 Routing Protocol for Low-Power and Lossy Networks, kurz RPL, entwickelt.
  Startpunkt der Standardisierung ist hier ein RFC 6550 aus 2012. Die Aufgabenstellung wurde jedoch schon eher in Angriff genommen. Der diesem RFC vorausgegangene Draft wurde rekordverdächtige 18-mal „verlängert“. RFC 9008 und 9010 aus April 2021 steuern dann ganz aktuelle Updates bei.
  Die Anforderung einer optimierten Routing-Basis für 6LoWPAN-Mesh-Netze war also offenbar sehr anspruchsvoll.

Was soll diese RFC-Historie an dieser Stelle?

Sie zeigt, dass die besondere IPv6-Problematik einer wichtigen Konstellation zur IoT-Vernetzung frühzeitig erkannt wurde. Sie führt vor, dass auch hier Verbesserungen in die letzten Standardisierungsstände eingeflossen sind, denen erste Praxiserfahrung vorausgeht. Die Phase von Brainstorming und ersten Versuchen ist Vergangenheit. Man kann davon ausgehen, dass interessierte Hersteller bei solchen Spezifikationsständen nicht wegen eines „grüne Banane”-Verdachts zurückschrecken.

Genauer betrachtet kann man sogar festhalten, dass die einstige ZigBee-Allianz, eine Herstellervereinigung, auch frühzeitig auf optimierte Standards für IPv6 gesetzt hat. Bereits in 2012 wurde mit der ZigBee-IP-Spezifikation, die 6LoWPAN berücksichtigt, der Grundstein gelegt. Die zwischenzeitlich für 6LoWPAN über neueste RFCs verfügbaren Updates können in neuere ZigBee-IP-Implementierungen einfließen.

Aus Sicht eines ordentlichen Implementierungszyklus mit Tests und Pilotierungen bis zur Marktreife sind die oben genannten RFC-Beispiele noch sehr neu (deshalb auch die obigen Datumsangaben zu den RFCs). Man muss beobachten, ob und wann die entsprechenden RFCs in technischen Unterlagen zu ZigBee-Implementierungen referenziert werden. Die Arbeitsbasis ist aber da.

Die Chance, aktuelle IETF-Best-Current-Practices referenzieren und trotzdem „schlanke“ IPv6-stacks realisieren zu können, werden Hersteller ebenfalls als verbesserte Rahmenbedingungen zur Kenntnis nehmen. Die zu Beginn aufgeführten allgemeinen RFC-News-Beispiele waren daher auch mit Blick auf die IoT-Thematik gewählt.

Weitere Fakten dieser Art: Es gibt für Bluetooth-basierte WPANs ebenfalls IETF-Aktivitäten zur spezifischen IPv6-Optimierung.

• Für sternförmige Architekturen existiert ein RFC 7668 IPv6 over Bluetooth® Low Energy aus 2015, der auf eine Nutzung des Low-Energy-Features „Bluetooth Smart“ mittels 6LoWPAN-Techniken abzielt.
• Die Arbeiten der zuständigen IETF Working Group 6lo mit Blick auf eine Bluetooth®-basierte Mesh-Vernetzung sind noch nicht ganz im Standards Track angekommen.
  Ein Draft zum Thema IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP (kurz: 6lo-blemesh oder einfach blemesh) wurde erstmals in 2016 veröffentlicht. Der aktuelle Draft-Zwischenstand hat die laufende Nr. 10 und datiert von April 2021. Hier müssen wohl noch ein paar Nüsse geknackt werden, doch es wird aktiv daran gearbeitet.

Weitere Initiativen und Spezifikationen zur Vernetzung von IoT-artigen Produkten, auch verschiedener Hersteller, sind ebenfalls IPv6-basiert vorgegangen.

Aktuell machen dazu etwa „Thread“ und “Matter” in der Fachpresse von sich reden.

In beiden Fällen sind wichtige und zahlreiche Hersteller direkt beteiligt, siehe https://www.threadgroup.org/) und „https://csa-iot.org/  bzw. https://zigbeealliance.org/news_and_articles/chip-is-now-matter/ ).

Wie geht es weiter?

IoT hatte bislang aus verschiedenen Gründen nicht die prognostizierte Zugkraft, um in Kundenumgebungen einen Beschäftigen mit IPv6 zu forcieren.

Die Einschätzung, das werde aufgrund des entsprechenden Herstellerverhaltens noch lange so bleiben, kann aber ein Irrtum mit unangenehmen Folgen sein. Um sich da nicht überraschen zu lassen und dann Lehrgeld durch hektische Projekte oder am eigenen Bedarf vorbeigehende Produktwahlen zu treffen, muss man aufmerksam sein.

Es reicht nicht, moderne Netztechnik mit IPv6-Fähigkeit zu verwenden, auf der bei Bedarf IPv6 vom IoT-Teilnetz zum Internetzugang „schnell“ aktiv geschaltet werden könnte.

Womöglich kommt über Entwicklungen der dargestellten Art IPv6 durch die Seitentür ins Haus. Passt man hier nicht auf, hat man kein eigenes IPv6-Know-how aufgebaut, wohl eine wie oben skizziert wichtige IoT-Komponente als Mittelpunkt einer IPv6-Kommunikation. Diese übernimmt dann etwa Funktionen eines IPv6-Routers (RA-Versand).

Will man so eine Lösung mangels eigenen Know-hows als Black Box in der Hoffnung auf störungsfreies „Plug-and-Work“-Verhalten einführen?

Die ComConsult-Erfahrung aus Fehlersuche-Dienstleistungen zeigt: Wenn es bei vernetzten Lösungen klemmt, ist das Wissen der Netz- und Kommunikationsspezialisten gefragt. Das gilt auch, wenn die Ursachen bei Konfigurationsmöglichkeiten vernetzter Geräte liegen und man erst einmal die Einstellmöglichkeiten verstehen muss.

Wer beabsichtigt, IoT-Lösungen in seiner Produktivumgebung einzuführen, hat wichtige Hausaufgaben zu erledigen:

• Man sollte mindestens auf plausibel zugesicherte und betrieblich beherrschbare Update-Möglichkeiten der Produkte achten. Nur dann lassen sich neue IPv6-basierte IoT-Optionen bei erreichter Marktreife nutzen, ohne womöglich größere Teile schon verbauter IoT-Hardware vorzeitig austauschen zu müssen.
• Um zu erkennen, wohin und wie sich ein interessantes IoT-Marktangebot und bestimmte Hersteller entwickeln, muss man keine trockenen RFCs lesen und alles verstehen.
  Bezeichnungen und Abkürzungen wie im Artikel vorgeführt müssen aber soweit bekannt sein, dass man Produkte, Hersteller- und Anbieterinformationen einordnen und gezielt Fragen zur IPv6-Verwendung oder einer Roadmap stellen kann.
  Mit IPv6-Grundverständnis kann man dann abwägen, welche Architekturen und Betriebsmodelle, die man gebrauchen kann und sich zutraut, mit welchen Produktkandidaten möglich sind.