Moderne Netze und IT-Anforderungen an Gebäudetechnik – Ein Konflikt?

Bei fast jeder Netzwerkplanung stellen wir uns (oder den Anwendungsverantwortlichen) die Frage, welche Anforderungen das Netzwerk erfüllen muss, um die benötigten Anwendungen ideal abbilden zu können. Die entsprechenden Anforderungen reichen von Eigenheiten der Netzarchitektur wie Ausfallsicherheit durch Redundanzen bis hin zu technischen Vorgaben wie verfügbaren Bitraten, maximalen Latenzen etc. Auch hinsichtlich des logischen Designs kann es Anforderungen zur Bildung von VLANs bzw. Subnetzen geben.

Anforderungen können je nach Anwendung und Gewerk dabei sehr unterschiedlich ausfallen und auch unterschiedliche Netzwerk-Architekturen voraussetzen. So fordert man regelmäßig eine Netzwerksegmentierung und getrennte logische Netze. Im Bereich der Gebäudetechnik hingegen ergibt sich schon mal die Forderung nach einem flachen Layer-2-Netz, das alle Geräte eines bestimmten Typs beinhaltet. Bacnet/IP ist ein Protokoll aus diesem Bereich, das diese Anforderung manchmal notwendig macht.

Die Anforderungen der IT- bzw. der Netzwerktechnik an die Anwendungen und die anzuschließenden Geräte umfassen technische Parameter der hardware- und softwareseitigen Schnittstelle. Diese zielen darauf ab, dass sich an das Netzwerk angeschlossene Geräte in das bereitgestellte Netzwerk integrieren. Sie basieren auf üblichen Standards und sind in der Netzwerktechnik, insbesondere in der klassischen Büro-IT, meist erfüllbar. In Bereichen wie der Gebäudetechnik kann dies aber eine Herausforderung darstellen.

Anforderungen, die das Netzwerk an Endgeräte richtet, stellen selten Probleme dar. Tatsächlich verliert man diese deswegen manchmal in der Planung aus dem Fokus. Mindest-Datenraten oder Forderungen wie beispielsweise Autonegotiation der Datenübertragungsrate sind für moderne Endgeräte selten problematisch. Dennoch kann es hier insbesondere bei Altgeräten, Produktionsnetzen oder Gebäudetechnik sinnvoll sein, diese Aspekte genauer zu betrachten.

In der Praxis sehen wir Probleme häufiger bei der Erfüllung derartiger Anforderungen, wenn sie die IT-Sicherheit betreffen. So fordert man mittlerweile regelmäßig, dass Endgeräte sich zertifikatsbasiert am Netzwerk authentifizieren können, um Network Access Control einzusetzen. Dies ist im Altbestand oder auch der Gebäudetechnik heute immer noch nicht der Normalfall. Das Einspielen von Zertifikaten ist oftmals nicht vorgesehen.

Es lohnt sich also, mögliche Anforderungen zu betrachten und Probleme abzuwägen.

Wir werden uns hierbei auf ein Beispiel aus einem unserer Projekte konzentrieren, bei dem es erhebliche Diskussionen zwischen den Gebäudetechnik-Planern und der IT-Abteilung gab.

Hierbei wurden vonseiten des Netzwerk-Betreibers konkrete Anforderungen an die Anbindungen der Endgeräte und an die Kommunikation der Anwendungen gestellt. Mögliche Anforderungen umfassten hierbei:

Autonegotiation gemäß IEEE 802.3

• Es werden bestimmte Datenraten gefordert, da das Netzwerk auf bestimmte Datenraten ausgelegt ist (insbesondere im Server-Bereich z.B. 1/10/25 Gbit/s (RJ45 oder SFP+ über LC-LC-Kabel).
• Endgeräte-Anbindung im Campus erfolgt mittels 100/1.000 Mbit/s (RJ45-Stecker).
• Anwendungen tolerieren eine eingeschränkte Maximum Transmit Unit (z.B. 1280 Bytes).
• Endgeräte und zugehörige Server können in unterschiedlichen Subnetzen sein.
• Eine Anwendung ist auch bei blockiertem Gratuitous ARP lauffähig.

Das System muss DHCP unterstützen (auch über DHCP-Relays).

• Die Authentifizierung kann vom Client mittels IEEE 802.1X mit PEAP (EAP-TLS) erfolgen.
• Unterstützung von IPv4 und IPv6 (IPv4-only, IPv6-only und Dual-Stack)

Hinsichtlich der Gebäudetechnik und technischen Gebäudeausrüstung (TGA) sind diese Anforderungen entsprechend zu beurteilen. Hierbei wird man feststellen, dass einige dieser Anforderungen keine besondere Herausforderung für moderne TGA-Geräte darstellen. Andere Anforderungen muss man genauer untersuchen. Dabei wird man auf mögliche Probleme für die Umsetzung stoßen.

In einem konkreten Projekt vom vergangenen Jahr stellte die IT-Abteilung sehr ähnliche Anforderungen an alle ans Netzwerk anzuschließenden Geräte. Hierbei fielen einige Anforderungen auf, welche insbesondere im Bereich der Gebäudetechnik schwierig zu erfüllen waren. Während es für die meisten technischen Bedingungen durchaus eine Lösung gab, auch wenn diese ggfs. die Herstellerwahl beeinflusste, war die Forderung zur Kompatibilität mit der geplanten IPv6-Einführung in diesem Bereich nach aktuellem Stand nicht erfüllbar.

Betroffene Komponenten der TGA

Im Bereich der Gebäudetechnik können verschiedene Geräte von den Netzwerk-Anforderungen betroffen sein. Wie bereits in einigen unserer Artikel [1, 2, 3] beschrieben, wird regelmäßig zwischen verschiedenen Ebenen unterschieden.

Diese sind:

• Management-Ebene
• Automations- oder Steuerungsebene
• Feldebene

Auf jeder dieser Ebenen kann netzwerkbasierte Kommunikation zum Einsatz kommen. Hierbei gibt es verschiedene Alternativen, welche zum Teil auf IP aufsetzen. Hinsichtlich einer technischen Erläuterung sei auf unsere vorherigen Veröffentlichungen zu diesem Thema verwiesen.

An dieser Stelle sei angemerkt, dass in vielen heutigen Implementierungen ein Kommunikationsbruch zwischen der Nutzeranwendung oder dem Bediengerät und der zu steuernden Komponente erfolgt. Die Steuerungsbefehle werden an eine Raumautomationsstation gerichtet, welche die Steuerung des Endgeräts übernimmt. Daher kann die Kommunikation der Ebenen in vielen Fällen voneinander losgelöst betrachtet werden und unterschiedliche Protokolle nutzen.

Grundsätzlich müssen Anforderungen für die Netzwerkkommunikation durch Management-Systeme, die Kommunikation zwischen Management und Automationsstation und die Kommunikation zwischen Automationsstation und den eigentlichen Sensoren bzw. Aktoren (Motoren etc.) erfüllt werden. Für Anforderungen aus Sicht des Netzwerks sind hier nur netzwerkbasierte Kommunikationsprotokolle relevant.

Es ist aber durchaus möglich, dass nicht jede dieser Kommunikationen netzwerkbasiert stattfindet. So ist auch eine Bus- oder „Zweidraht“-basierte Anbindung von Sensoren und Aktoren möglich und üblich.

Für unsere Betrachtungen sind nur die über Ethernet oder IP kommunizierenden Endgeräte relevant. Daher kann man Geräte der Feldebene meist ausklammern. Im Allgemeinen können die Anforderungen auch auf diese Komponenten zutreffen. Von den Netzwerkanforderungen betroffen sind in einem modernen Gebäude die Komponenten der Automations-/Steuerungsebene und der Managementebene.

Besteht nun Konfliktpotential hinsichtlich der Anforderungen?

Müssen wir nun tatsächlich Konflikte erwarten, wenn es um die Anforderungen an TGA-Geräte geht? Die kurze Antwort: Ja, häufig aber nur wenige. Die praktikable Antwort: In den meisten Projekten sind diese eher von untergeordneter Relevanz. Und die ausführliche Antwort, die auch mal notwendig ist, kann wie folgt aussehen:

Das Konfliktpotential hängt sehr von den beteiligten Parteien aufseiten der IT und TGA und der Kommunikation zwischen den Parteien ab. Tatsächlich haben wir in verschiedenen Projekten schon erhebliches Konfliktpotential diesbezüglich erlebt. An dieser Stelle wollen wir die zwischenmenschliche Ebene ausblenden und uns auf die technische Ebene konzentrieren.

Vor allem für Sensoren und Aktoren der Feldebene sind die Anforderungen häufig nicht erfüllbar. Wie oben bereits erläutert sind diese oftmals nicht auf das Netzwerk angewiesen und können daher bei einer Betrachtung ignoriert werden.

Anforderungen hinsichtlich Datenraten, Autonegotiation etc. lassen sich meist von allen relevanten Geräten erfüllen und stellen daher selten eine große Herausforderung dar. Betrachtet man jedoch die Forderung nach subnetzübergreifender Kommunikation, ist dies zumindest beim Einsatz von BACnet/IP zu beachten. Konkret nutzt BACnet/IP Broadcasts, welche nicht subnetzübergreifend funktionieren. Die daraus resultierende Einschränkung der Kommunikation ist dadurch zu lösen, dass sogenannte BACnet Broadcast Management Devices (BBMD) eingesetzt werden. Diese ermöglichen eine subnetzübergreifende Kommunikation auch mit BACnet/IP.

Die Forderung nach der Unterstützung von DHCP ist im Bereich der Feld- und Automationsebene ebenfalls nicht immer erfüllbar. Auch auf der Steuerungsebene kann eine DHCP-Unterstützung nicht durchgehend vorausgesetzt werden, sodass eine manuelle Konfiguration mitunter notwendig ist.

Hinsichtlich der Authentifizierung mittels IEEE 802.1X zeigt die Projekterfahrung deutlich, dass Gebäudetechnik-Geräte häufig keine zertifikatsbasierte Authentisierung unterstützen. Dies gilt für Sensoren und Aktoren auf der Feldebene, doch auch für Steuerungs- und Management-Stationen. Im Rahmen einer Herstelleranfrage an verschiedene Produzenten im erwähnten Projekt war eine Unterstützung für Komponenten der Automationsebene allerdings gegeben.

IPv6-Fähigkeit als zukünftiger Problemfall?

In diesem Projekt war die Forderung nach IPv6-Fähigkeit der größte Konflikt.

Jeder IT-Verantwortliche hat sicherlich schon mal das Thema IPv6 auf der Agenda gehabt und in vielen Fällen auch zeitnah wieder beiseitegelegt. Häufig geschieht dies mit dem Argument, dass IPv4 für den internen Betrieb ausreichend verfügbar ist, dass IPv6 nicht benötigt wird und ohnehin lediglich die Komplexität des Netzwerkbetriebs erhöht. Diesen Anmerkungen kann man oft auch nicht widersprechen. Ein internes Netzwerk hat selten zwingende Gründe, IPv6 zu nutzen, und die Komplexität des Netzbetriebs erhöht sich zumindest so lange, wie sowohl IPv4 als auch IPv6 betrieben werden müssen.

Häufig wird argumentiert, dass nicht alle Endgeräte oder Anwendungen IPv6 unterstützen. Im Bereich der Büro-IT mag das ein vorgeschobenes Argument sein, da hier eine fehlende IPv6-Fähigkeit eher die Ausnahme ist. Im Bereich von Produktions- oder Gebäudetechniknetzen ist die Nutzung von IPv6 oftmals nur eingeschränkt oder gar nicht möglich.

Somit kann man bereits erahnen, dass die Forderung nach IPv6-Unterstützung durch TGA-Endgeräte problematisch sein kann. Im vorliegenden Projekt ergab sich daher in Anbetracht der geplanten Lebensdauer der Gebäudetechnik die Forderung, dass bereits jetzt alle Geräte auf einen IPv6-only-Betrieb vorbereitet sein müssten. Keiner der namhaften Gebäudetechnik-Hersteller erfüllt diese Anforderung derzeit vollständig. Eine Erfüllung der Forderung nach IPv6 in der Gebäudetechnik kann an dieser Stelle nur verneint werden.

Heutige Netzwerkkomponenten sind sowohl IPv4- als auch IPv6-fähig. Dies gilt ebenso für die Server-Hardware und Betriebssysteme, welche in der TGA zum Management eingesetzt werden. Allerdings ist eine Unterstützung der Software häufig nicht gegeben.

In den meisten Projekten spielt IPv6 für die Gebäudetechnik kaum eine Rolle. Hier war das aufgrund der konkreten Forderungen des Bauherren aber anders: Es war gefordert, dass in einem absehbaren Zeitraum auf IPv4 verzichtet werden soll. Für die vorliegende Argumentation nehmen wir diese Forderung als gegeben hin – unabhängig davon, wie überzogen sie erscheinen mag.

Daher galt:

• IPv4-only, IPv6-only und Dual-Stack-Kommunikation wird unterstützt.
• Hinsichtlich der Priorisierung wird in der Software ein Happy-Eyeball-Mechanismus zur Auswahl des genutzten Protokolls gefordert.
• Alle konfigurierbaren Netzwerkparameter müssen auch als IPv6-Parameter konfigurierbar sein.
• Jede über IPv4 verfügbare Funktion muss ebenfalls über IPv6 verfügbar sein.
• DHCP und DNS sind von der Software zu nutzen (statt statisch zu konfigurierender IP-Adressen).
• Für Nutzer besteht kein nennenswerter Unterschied zwischen IPv4 und IPv6.

Die Forderungen waren in Empfehlungen öffentlicher Dokumente bzw. für die öffentliche Verwaltung begründet, da die IT-Abteilung sich daran orientieren wollte:

• Leitlinie und weitere Dokumente des Bundesamts für Sicherheit in der Informationstechnik (BSI)[5]: Leitlinie IPv6[6], Sichere Anbindung lokaler Netze an das Internet [7], Konzeption von IPv6-Netzen, Effekte von IPv6 auf reine IPv4-Netze
• Architekturrichtlinie für die IT des Bundes[2]
• Beschlusssachen zur IT-Steuerung Bund Nr. 2020/14 und 2020/13
• IPv6-Profile für die Öffentliche Verwaltung des Bundesverwaltungsamts

Die Leitlinien und weiteren Dokumente des BSI als allgemeine Handlungsempfehlungen legen den Fokus vor allem auf den Aufbau einer sicheren Netzwerkinfrastruktur. Das BSI fordert: „Bei der Beschaffung und Entwicklung neuer Hard- und Software muss auf die IPv6-Fähigkeit der Produkte geachtet werden. […]“ [6]. Grundsätzlich ist IPv4 ab einer weitgehenden Umsetzung von IPv6 als Altlast zu betrachten, welche zu vermeiden ist. Da diese Dokumente keine zwingende Vorgabe zur zeitnahen Umsetzung reiner IPv6-Netze beinhalten, ist eine grundlegende Nutzung von IPv4 weiterhin möglich. Als Zielvorgabe stellt dies dennoch eine deutliche Empfehlung dar.

IPv6 muss gemäß der Leitlinie für IT des Bundes verwendet werden: „IT-Systeme, Verfahren und Infrastrukturen müssen mit IPv6, und damit ohne IPv4 Adressen, vollständig funktionsfähig sein.“ [2] Insbesondere wird gefordert, dass dies für Neubeschaffungen gilt und bestehende Systeme im Rahmen der Systempflege IPv6-fähig gemacht werden. Es wird klargestellt, dass „für den technischen Übergang der parallele Einsatz von IPv6 und IPv4 notwendig ist.“ [2].

Hinsichtlich der Anforderungen wird dies vonseiten der IT abgefragt, doch zeigt die Projekterfahrung, dass sowohl Planer und Lieferanten als auch Hersteller im Bereich der Gebäudetechnik eine IPv6-Fähigkeit hier häufig verneinen. Aufgrund des fehlenden Bedarfs vonseiten des TGA-Gewerks wird IPv6 meist nicht berücksichtigt.

Nicht selten wird von einer ausreichenden Trennung des Netzwerkbereichs der TGA von anderen Netzen ausgegangen, sodass die entsprechenden Komponenten auch bei einem langfristig in Betracht zu ziehenden IPv6-Einsatz im IT-Netz in den getrennten Netzsegmenten weiterhin IPv4 nutzen können.

Es gibt Varianten der in der TGA eingesetzten Protokolle, welche IPv6 unterstützen. So könnten BACnet/IPv6 und BACnet/SC zum Einsatz kommen. Tatsächlich gab es zum Zeitpunkt des genannten Projekts aber kein Produkt, das diese entsprechend auf allen Ebenen nutzt. Abhängig vom konkreten Anwendungsfall gibt es etablierte TGA-Protokolle wie Zigbee, die IPv6 ohnehin unterstützen (siehe hierzu auch [4]).

Es bleibt abzuwarten und zu hoffen, dass sich die Systemlandschaft im Bereich der TGA weiterentwickelt. Fast alle Hersteller gaben an, dass sie eine Umsetzung von IPv6 planen, diese jedoch zeitlich noch nicht festgelegt sei.

Bedeutet dies nun, dass IPv6 gar nicht eingeführt wird oder dass langfristig ein Dual-Stack betrieben wird? Und wie geht man damit um, dass IPv4 bei der Migration zu IPv6 irgendwann deaktiviert werden soll?

Bevor wir dies beantworten, vergegenwärtigen wir uns noch einmal den üblichen Ablauf einer IPv6-Einführung. Zu Beginn steht eine Konzeptphase, in der die grundlegende Architektur und insbesondere ein Migrationszeitplan geplant werden. Solch ein Zeitplan beinhaltet die schrittweise Einführung eines Dual-Stack-Betriebs, bei dem sowohl IPv4 als auch IPv6 genutzt werden können. Im Endeffekt soll dieser Dual-Stack-Betrieb langfristig durch einen reinen IPv6-Betrieb abgelöst werden.

Innerhalb der Dual-Stack-Phase müssen viele Betriebsaufgaben für beide Protokolle durchgeführt werden. Ebenso werden Aufgaben wie Troubleshooting komplexer. Viele IPv6-Migrationskonzepte sehen daher vor, dass eine IPv6-only-Fähigkeit geprüft werden und dann gegebenenfalls eine entsprechende Umsetzung fortschreiten sollte. Abhängig von den eigenen betrieblichen Prozessen, Anwendungen etc. kann ein Dual-Stack-Betrieb über einen Zeitraum von 10 bis 15 Jahren erforderlich sein.

Innerhalb dieser Phase wäre es völlig ausreichend, wenn Endgeräte entweder IPv4 oder IPv4 und IPv6 unterstützen würden. In diesem Falle könnten alle Endgeräte unabhängig von der Protokollversion miteinander kommunizieren. Lediglich die Kommunikation zwischen Geräten, die nur IPv6 unterstützen, und reinen IPv4-Geräten wäre nicht möglich.

Dennoch kann es sinnvoll sein, klare zeitliche Ziele zu definieren. So hat der Bund für die Netze des Bundes eine IPv6-Strategie definiert, nach der eine Umsetzung des Dual-Stack-Betriebs bis 2025 und eine reine IPv6-Umgebung bis 2030 vorgesehen ist. Genau genommen stellen die Netze des Bundes das Weitverkehrsnetz und darüber angebotene Dienste für Bundesbehörden dar. Dies betrifft also nicht zwingend die Netze innerhalb einzelner Behörden. Dennoch bieten solche Vorgaben die Möglichkeit, sich daran zu orientieren. So haben verschiedene Behörden eigene Vorgaben für interne Netze sehr ähnlich ausgestaltet.

Insbesondere zählen hierzu die Herstellung der IPv6-Fähigkeit für das WAN und angebundene Rechenzentren bis 2025 und eine Abschaltung von IPv4 bis 2030. Dies ergibt sich aus den Beschlüssen 2020/13 [6] und 2020/14 [5] des IT-Beirats. Ein direkter Bezug auf die Gebäudetechnik besteht nicht explizit, sofern diese nicht über das WAN kommuniziert.

Eine zentrale Frage ist, ob ein derart strikter Zeitplan überhaupt einzuhalten ist.

Abhängig von der Größe und Komplexität des Netzwerks und der gesamten IT-Landschaft (Netzwerkkomponenten, Endgeräte, Server und Software) können die Umsetzung von IPv6 und die vollständige Ablösung von IPv4 zeitlich sehr unterschiedlich ausfallen.

In IPv6-Konzeptionsprojekten sehen hierbei viele Kunden wie bereits erwähnt einen Zeitraum von mehreren Jahren vor. Meist wird davon ausgegangen, dass in deutlich abgrenzbaren, lokalen Netzen ein sogenannter Inselbetrieb von IPv4 oder Dual-Stack langfristig notwendig sein wird.

Angesichts des für die Konfiguration, Überwachung und auch bei Fehlersuchen entstehenden Aufwands, wenn zwei Protokolle bereitgestellt werden, ist die Zielsetzung einer Ablösung der IPv4-Konfiguration nachvollziehbar und sinnvoll.

Hinsichtlich des Zeitablaufs sei hier beispielhaft die Entwicklung des Anteils der IPv6-Anfragen an Google-Internet-Seiten angeführt [7]. Dieser beträgt Stand April 2025 ca. 48 % des Datenverkehrs weltweit. In derselben Quelle wird ebenfalls angegeben, dass in Deutschland eine IPv6-Unterstützung von Internetverbindungen in Höhe von 75,56 % (Stand 21.04.2025) gegeben ist. In Abbildung 1 ist ersichtlich, wie dieser sich in der Vergangenheit entwickelt hat. Ebenfalls ist erkennbar, dass in 4 Jahren ungefähr 15 % bis 20 % Zuwachs (weltweit) festgestellt wurde. Hier dargestellte IPv6-Verbindungen können sowohl aus reinen IPv6-Netzen als auch aus Dual-Stack-Netzen stammen, welche weiterhin IPv4 unterstützen. Eine weitgehende IPv6-Durchdringung benötigt also einen erheblichen Zeitrahmen. Sicherlich lassen sich diese Zahlen nicht auf individuelle Netze übertragen. Sie zeigen aber dennoch die globale Entwicklung und geben einen Eindruck, wie ein solcher Verlauf aussehen kann.

Auch wenn zukünftige Entwicklungen nicht final eingeschätzt werden können, deuten sowohl unsere Projekterfahrungen als auch die Statistiken der Internetdienstleister wie Google darauf hin, dass eine vollständige Durchdringung von IPv6 in allen Bereichen und allen Anwendungen nicht in den nächsten 10 Jahren zu erwarten ist. Ein zeitlicher Rahmen wie im Bereich der Netze des Bundes ist daher als ambitioniert zu bezeichnen.

Für die meisten Netzwerke zeigt sich somit eine längerfristige Migration. Insbesondere für Geräte oder Netzbereiche, welche nicht über ein IPv6-only WAN kommunizieren, wäre eine Forderung nach IPv6-only-Betrieb technisch nicht notwendig. Wenn man beim Betrieb des Netzes oder des WANs jedoch durch den Zeitplan des Betreibers eine Deadline gesetzt bekommt, kann zumindest für Anwendungen, die über diesen Weg erreichbar sein müssen, diese Deadline ebenfalls gelten.

Erfahrungsgemäß ergeben sich in weiten Teilen Migrationswege, bei denen IPv6-fähige Teilnetze, in denen nur IPv6-fähige Geräte und Anwendungen betrieben werden, ohne IPv4 auskommen können. Hier kann somit Betriebsaufwand durch Vereinfachung der Konfiguration und durch Komplexitätsreduktion verringert werden. Im Büro- oder Teilen des Rechenzentrumsumfelds ist eine frühzeitige Umsetzung möglich, sobald angebundene Systeme ebenfalls IPv6 unterstützen.

Um trotz dieses Widerspruchs zu den gestellten Anforderungen die Auswirkungen auf andere Netze zu minimieren und den Betriebsaufwand in weiten Teilen auf einen reinen IPv6-Betrieb auszurichten, sind die Bereiche mit IPv4-Kommunikation einzugrenzen.

Die meisten genannten Anforderungen können als Stand der Technik wahrgenommen werden, wenn es um Komponenten und Systeme geht, welche den Büro-Bereichen oder auch der eigentlichen IT zuzuordnen sind. Besonders in der Netzwerktechnik und bei modernen Endgeräten in diesen Bereichen sind die Vorgaben üblich und damit auch marktgängig.

Gemäß unserer Projekterfahrung gibt es allerdings Gewerke, bei denen dies pauschal nicht zutrifft und die daher differenzierter angeschaut werden müssen. Dazu zählen einerseits Produktionsumgebungen in der Industrie sowie die hier betrachtete TGA und Gebäudetechnik-Umgebung. Aus unserer Sicht kann von einer Marktgängigkeit, insbesondere von IPv6, in diesem Sektor nicht bei allen Anforderungen ausgegangen werden.

Ein Teil der Anforderungen kann im Rahmen der Beschaffung der TGA-Komponenten berücksichtigt oder durch einfache Ersatzmaßnahmen (z.B. manuelle IP-Konfiguration statt DHCP) umgesetzt werden. Die Forderung nach IPv6-Fähigkeit gestaltet sich jedoch deutlich schwieriger.

Die Nutzung einer alternativen Anbindung der Feldebene (z.B. Zweidraht oder Bus-Techniken) kann im Einzelfall geprüft werden, wenn IPv4 vermieden werden soll. Es empfiehlt sich im konkreten Projekt aufgrund der strikten Forderungen des IT-Betreibers eine möglichst zeitnahe Einführung von IPv6 für die Management- und Steuerungs- bzw. Automatisierungsebene. Die Anbindung der nachgelagerten Systeme bleibt IPv4-basiert, sofern diese auf LAN-Technik beruht.

Eine weitreichende Einschränkung des IPv4-Verkehrs wäre somit möglich, ohne die Anwendung unnötig einzuschränken. Zukünftig erwartet man hier daher eine IPv4-Insellösung mit entsprechenden Transitionsmechanismen. Um einen Zugriff auf Management- und Steuerungs-Systeme auf IPv6-Basis zu ermöglichen, müsste dann zu gegebenem Zeitpunkt für den Zugriff auf TGA-Systeme ein Gateway (NAT64 und DNS64) implementiert und betrieben werden.

Die Netzbereiche, in denen IPv4-Datenverkehr benötigt wird und die kein IPv6 nutzen, sind als getrennte Inseln zu verstehen, welche lediglich über die oben beschriebenen Gateways von IPv6-basierten Endgeräten aus erreichbar sind. Im Rahmen der Umsetzung sind verschiedene Rahmenbedingungen und Parameter zu berücksichtigen. Hierzu gehört beispielsweise, dass bestimmte Protokolle nicht über diese Gateways hinweg kommunizieren sollten, da dies nicht zuverlässig funktioniert. So sollten sich BACnet/IP-Geräte direkt auf Basis einer einzigen IP-Version ansprechen können.

Zusammenfassend gilt, dass Anforderungen sowohl von Anwendungen und Geräten an das Netzwerk als auch umgekehrt gestellt werden müssen. Diese müssen im Hinblick auf ihre Sinnhaftigkeit genau geprüft werden. Am Beispiel der Forderung nach IPv6-Fähigkeit mit Verzicht auf IPv4 ist zu erkennen, dass eine zu strikte Interpretation entsprechender Vorgaben möglicherweise nicht umsetzbar ist. Alternative Lösungsansätze für die Netzwerkarchitektur können entsprechend umgesetzt werden.

Abschließend stellt sich die Frage, ob die hier betrachteten sehr strikten technischen Forderungen überhaupt sinnvoll sind. Sofern diese aber bestehen oder vorgegeben sind, wie es beispielsweise für die Netze des Bundes gilt, muss man sich damit auseinandersetzen und entsprechende Umsetzungen prüfen und planen.

Es empfiehlt sich also, einerseits die Anforderungen des Netzwerks an Endgeräte nicht nur mit der klassischen IT-Brille zu sehen, sondern kritisch für andere Gewerke zu bewerten. Andererseits ist zu erwarten, dass langfristig auch Anforderungen wie IPv6-Fähigkeit und ggf. sogar der Betrieb in einem reinen IPv6-Netz umsetzbar sein müssen. Eine rechtzeitige Planung ist hierbei eine Voraussetzung, um Konflikte zu vermeiden.

Verweise

[1] J. Dams, Anforderungen aus der Gebäudetechnik – TGA-Protokolle in strukturierten Netzen als Herausforderung, Netzwerk Insider Juni 2022, https://www.comconsult.com/anfroderungen-aus-der-gebaeudetechnik-tga-protokolle/

[2] J. Dams, Bauprojekte und die Planung des Netzes, Netzwerk Insider Juli 2024, https://www.comconsult.com/bauprojekte-und-die-planung-des-netzes/

[3] Andreas Kaup, Sichere Kommunikationsprotokolle in der Gebäudeautomation – im Fokus: BACnet Secure Connect, Netzwerk Insider März 2024, https://www.comconsult.com/sichere-kommunikationsprotokolle-in-der-gebaeudeautomation-im-fokus-bacnet-secure-connect/

[4] Oliver Flüs und Thomas Steil, „IPv6 does Matter“ – Bewegung im IoT-Bereich mit Matter 1.2, https://www.comconsult.com/ipv6-does-matter-bewegung-im-iot-bereich-mit-matter-1-2/

[5] Konferenz der IT-Beauftragten der Ressorts, „Beschluss der Konferenz der IT-Beauftragten der Ressorts vom 11. November 2020, [2020/14],“. [Online]. Available: https://www.cio.bund.de/SharedDocs/downloads/Webs/CIO/DE/it-beirat/beschluesse/2020_14_Beschluss_Konferenz_IT-Beauftragte.pdf?__blob=publicationFile&v=1. [Zugriff am 11.06.2024].

[6] Konferenz der IT-Beauftragten der Ressorts, „Beschluss der Konferenz der IT-Beauftragten der Ressorts vom 11. November 2020, [2020/13],“. [Online]. Available: https://www.cio.bund.de/SharedDocs/downloads/Webs/CIO/DE/it-beirat/beschluesse/2020_13_Beschluss_Konferenz_IT-Beauftragte.pdf?__blob=publicationFile&v=1. [Zugriff am 11.06.2024].

[7] Google, „IPv6 Statistiken,“ [Online]. Available: https://www.google.com/intl/de/ipv6/statistics.html. [Zugriff am 19.04.2025].