Brauchen wir wirklich neue Netzwerkprotokolle? Die kurze Antwort lautet: „Ja sicher!“ Die bisher genutzten Netzwerkprotokolle haben überraschend gut funktioniert, und Versuche, diese zu verbessern, haben häufig keine Verbesserung gebracht. Einige kluge Köpfe haben jedoch notwendige Änderungen in den grundlegenden Protokollen festgestellt, die die Vernetzung vereinfachen könnten. Die eigentliche Frage lautet daher: Sind die Veränderungen signifikant genug, um einen Umbau der derzeitigen Protokollwelt zu rechtfertigen.
Wenn das, über das was wir verfügen, gut funktioniert, warum benötigen wir dann neue Protokolle? Analysiert man sich die Schichten, die für die Realisierung von Sicherheit, NAT, QoS und Content Management erforderlich sind, dann wird alles schnell kompliziert, da die unterschiedlichsten Schichten miteinander interagieren. IPv6 versprach uns vor 20 Jahren, die Sicherheit zu verbessern. In der Praxis mussten wir jedoch leidvoll feststellen, dass das „neue“ IP einige signifikante Sicherheitslücken (beispielsweise bei der Erkennung von Nachbarn und dem automatischen Tunneling) aufwies. Trotzdem haben einige der neuen Protokolle das Potential zur möglichen Vereinfachung der Netzwerke.
Zu den neuen Protokollen gehören:
- Named Data Networking (NDN)
- Recursive InterNetwork Architecture (RINA)
- IP Version 10
- Enhanced IP
- Easy IP (EZIP)
Named-Data-Networking (NDN)
Das Named Data Networking (NDN) stellt ein relativ neues Netzwerkprotokoll dar und soll die Art und Weise verändern, unsere Geräte (Computer, Tablets, Telefone) die Daten übermitteln. NDN definiert neue Version von Content-Centric Networkings. Die Daten werden dabei zwischen zwei Endpunkten auf Basis eindeutiger Namen (ähnlich wie URLs) übermittelt. Beispielsweise könnte ein beliebtes Online-TV-Programm über seinen Namen statt über die Server, auf denen dies gelagert wird (z.B. netflix.com oder amazon.com), referenziert werden.
Während der Name des Programms noch den Namen des Ursprünglichen Hosters enthalten kann, können die Daten an mehreren Stellen im Internet abgelegt werden. Dies beschleunigt den Zugriff auf die bereitgestellten Informationen. Daher muss man sich NDN auch als eine skalierte Version eines Content-Distribution-Netzwerks (CDN) vorstellen. Noch besser, verschiedene Versionen der gleichen Daten können unterschiedliche Namen verfügen, was den Zugriff auf bestimmte Versionen ermöglicht.
Will man mehr über diese neue Protokollwelt empfiehlt sich die in Youtube zur Verfügung gestellte Präsentation von Van Jacobson (https://www.youtube.com/watch?v=oCZMoY3q2uM&t=2488s). Eine der großen Vorteile des Named Data Networking (NDN) sind eine Kombination aus Effizienzsteigerung und erhöhter Vertrauenswürdigkeit der Daten. Ein möglicher Nachteil dieses Lösungsansatzes steckt jedoch darin, dass die Statusinformationen (beispielsweise den Pending Interest Table, eine Funktion, die den Prozess der namentlichen Suche nach Inhalten vereinfacht) des möglichen Speicherorts ebenfalls abgelegt werden müssen.
Auf den ersten Blick scheint mit dem NDN nur für das Abrufen statischer Inhalte wie Webseiten und Streaming-Medien (Video, Audio) möglich. Van Jacobson schlug vor kurzem in einem Interview vor, NDN als Ersatz für UDP zu nutzen. Auf zwei Laptops wird für die Übermittlung eines Audioanrufs (Telefonats) die Named Data Networking Mechanismen genutzt. Da die beiden Endpunkte nach der Herstellung einer Verbindung namentlich bekannt sind, kann das Telefonat auch nach dem Trennen der Ethernet-Schnittstelle fortgesetzt werden, indem NDN einen alternativen Pfad zwischen den Systemen sucht.
Das Besondere an NDN ist, dass diese Mechanismen auf jede vorhandene Infrastruktur funktionieren – sei es über IPv4, IPv6, schnelle optische Netze oder langsame Ad-hoc-Netzwerke. Um die Kommunikation über NDN beginnen zu können, müssen nur NDN-Routern in den wichtigen Teilen des Internets integriert werden. Über das Internet könnten die Daten an die Netze verteilt werden, die nah am Empfänger liegen. Nach der Meinung von Gartner befindet sich NDN derzeit noch in der Anfangsphase der Realisierung und es wird sicher noch zehn Jahre dauern, bis eine durchgehende weltweite NDN-Kommunikation umgesetzt werden kann.
Im Februar 2017 erwarb Cisco die PARC NDN-Plattform mit dem Namen Content Centric Networking (CCN). Cisco vermarktet inzwischen seine Version des „Information-centric networking“ (ICN) und plant diese zukünftig innerhalb der FD.io (Fast Data – Input/Output) Community der Linux Foundation zu öffnen. Mit der Übernahme von PARC CCN verfolgt Cisco das Ziel, die Konvergenz verschiedener Dialekte von ICN (CCN und NDN) in einer einzigen harmonisierten Version von ICN zu realisieren und so eine breitere und schnellere Einführung von ICN-basierten Lösungen zu fördern, die zur Lösung zukünftiger Netzwerkanforderungen erforderlich sind.
Aus meiner Sicht ist NDN momentan die praktikabelste aller möglichen Zukunftslösungen, weil diese Lösung einen sauberen Übergang hin zur nächsten Kommunikationsgeneration verspricht. Der große Vorteil von NDM besteht darin, dass dieser Kommunikationsmechanismus über jedes Transportmedium funktioniert und schnell an neue Anforderungen angepasst werden kann.
Recursive-InterNetwork-Architecture (RINA)
Eine weitere neue Initiative zur Ablösung der traditionellen IPv4/IPv6-Techniken wird als Recursive InterNetwork Architecture (RINA) bezeichnet. Dieses Konzept soll die Grundlagen der Vernetzung neu definieren und deren Betrieb vereinfachen. John Day, der am Design des ursprünglichen Arpanet beteiligt war, untersuchte in seinem Buch „Patterns in Network Architecture“ die Architektur des klassischen Internet-Protokolls. Seine Analyse ergab, dass die Netzwerkkommunikation immer auf den gleichen Schichten abläuft und daher als Inter-Process Communication (IPC) umgesetzt werden könnte. Dies führt in der Konsequenz zu einer großen Vereinfachung der gesamten Architektur. Der gleiche IPC-Mechanismus kann im gesamten Netzwerkstack verwendet werden. Die einzige Voraussetzung ist, dass die Parameter so eingestellt werden, dass diese sich auf verschiedene Bereiche anpassen.
Das wunderbare an RINA besteht darin, dass Zusatzfunktionen wie beispielsweise die Sicherheit, QoS, NAT, Mobilität und Multi-Homing ohne zusätzliche Funktionen und ohne zusätzliche Protokolle realisiert wird. Bereits im Jahr 1982 bewies Richard Watson, dass ein zuverlässiger Datentransport nur drei Timer benötigt, die auf der maximalen Lebensdauer des Pakets basieren (das Delta-T-Protokoll). Der Beginn und das Ende einer Verbindung werden bei dieser Lösung nicht mehr benötigt, so dass auf den SYN- und FIN-Teil einer TCP-Verbindung verzichtet werden kann. Dies würde die Geschwindigkeit des zuverlässigen Verbindungsaufbaus verkürzen. Bei Webseiten, die über mehrere Server und vielen verschiedenen Komponenten aufgebaut sind, würde dies den Seitenaufbau entscheidend beeinflussen. Außerdem werden dadurch keine SYN-Angriffe mehr möglich.
Ich habe schon oft über die Notwendigkeit geschrieben, die Vielzahl von unterschiedlichen Netzwerkprotokollen zu vereinfachen. Jede Netzwerkschicht im bestehenden TCP/IP-Modell verfügt über ein oder mehrere eindeutige Protokolle, die ordnungsgemäß konfiguriert und betrieben werden müssen, um die Anwendungen und letztlich die von den Anwendungen abhängige Geschäftsprozesse ordnungsgemäß abwickeln zu können. Wann immer wir ein neues Netzwerkproblem entdecken, lösen wir es, indem wir einen neuen Mechanismus und ein neues Protokoll zur Übermittlung der Daten entwickeln.
Es gibt mehrere Organisationen, die derzeit an der Fortentwicklung von RINA arbeiten, aber in der Fachpresse schlagen sich deren Entwicklung kaum nieder. Aus meiner Sicht wird RINA noch viele Jahre benötigen, um eine akzeptierte Implementation auf den Markt zu etablieren. Die Anzahl der Geräte, die derzeit einen IP-Stack nutzen, sind eine extrem hohe Hürde für die Realisierung von RINA. Da wir uns bereits in einer (quasi ewig dauernden) Übergangsphase zu IPv6 befinden, wird kein Kunde ein Verständnis dafür haben, ähnliche Schritt für eine RINA-Umsetzung durchführen zu müssen. Letztendlich hängt der Erfolg davon ab, wie gut wir die Probleme lösen können, die RINA uns zu lösen verspricht (QoS, NAT, Sicherheit, Mobilität). Insbesondere die Netzwerksicherheit wird ein Schlüsselfaktor sein. Bis dahin werden wir weiterhin an zusätzlichen Mechanismen arbeiten, die die TCP/IP-Probleme lösen könnten.
Internet-Protokoll Version 10 (IPv10)
Das neue IP Version 10 (IPv10) wurde in Ägypten entwickelt und inzwischen als Draft (https://tools.ietf.org/html/draft-omar-ipv10-01) veröffentlicht. Es löst das Problem, dass niemals Rechner mit unterschiedlichen Protokollversionen (IPv6 ßàmit IPv4) kommunizieren können. Dabei ist es egal, ob bei der IP-Kommunikation die realen IP-Adressen oder die logischen Rechnernamen (DNS) zwischen IPv10-Hosts genutzt werden. Bei diesem Lösungsansatz entfällt die Notwendigkeit für eine Protokollübersetzung. In einem IPv10-Paket können in einem Header beide IP-Versionen (Mischung aus IPv4 und IPv6-Adressen) enthalten sein. Somit erklärt sich auch der Name des Protokolls: IPv6 + IPv4 = IPv10. Daraus ergeben sich folgende Vorteile:
- Einführung einer effizienten Kommunikation zwischen IPv6-Hosts und IPv4-Hosts.
- Ermöglicht die Kommunikation von IPv4-Hosts zu IPv6-Hosts auch nach der Ausschöpfung des kompletten IPv4-Adressraums.
- Agiert gegenüber früheren Lösungen erheblich flexibler, da bei einer Anfrage (per Hostnamen) an ein DNS-System nur die IPv4- bzw. IPv6-Adresse (IPv6: AAAA-Record bzw. IPv4: A Record) übermittelt werden muss.
- Es entfällt die Notwendigkeit über eine Migration nachzudenken, da sowohl IPv4- als auch IPv6-Adressräume.
- Eine IPv10-Unterstützung kann auf allen Rechnern in sehr kurzer Zeit durch die Installation eines IPv10-Stacks realisiert werden.
IPv10 ermöglich die folgenden Kommunikationsarten zwischen Rechnern:
- IPv6-Hosts zu IPv4-Hosts (6 zu 4)
- IPv4-Hosts zu IPv6-Hosts (4 zu 6)
- IPv6-Hosts zu IPv6-Hosts (6 zu 6)
- IPv4-Hosts zu IPv4-Hosts (4 zu 4)
In der Praxis müssen zur Vermittlung der IPv10-Pakete in den Routern das IPv4- und das IPv6-Routing aktiviert. Empfängt ein Router ein IPv10-Paket, muss dieser die spezifische IPv6 bzw. IPv4-Routingtabelle nutzen und das Paket entsprechend der darin enthaltenen Zieladresse weiterleiten. Enthält ein empfangenes IPv10-Paket eine IPv4-Adresse im Zieladressenfeld, nutzt der Router die IPv4-Routingtabelle zur Weiterleitung des Pakets in Richtung des Zielrechners. Entsprechend nutzt der Router beim Empfang eines IPv10-Pakets mit integrierter IPv6-Adresse im Zieladressenfeld das IPv6 Routing zur Weiterleitung des betreffenden Pakets in Richtung des Ziels.
Die Version 10 des IP-Protokolls bieten zwar einen Ausweg aus dem Migrationsdilemma von IPv4 auf IPv6, aber da diese Lösung kaum Unterstützung in den USA findet, wird auch diese IP-Variante zum Stein der Weisen werden.
Enhanced-IP
Enhanced IP (www.enhancedip.org) ist mehr ein Adresserweiterungsmechanismus als ein neues Protokoll. Es verwendet die IP-Option 26, um die Größe des IPv4-Adressraums zu verdoppeln. Seit dem Jahr 2014 steht auch ein Draft bei der IETF (http://www.enhancedip.org/docs/rfcEnIP.txt) zur Verfügung.
Bestehende Netzwerkgeräte können die erweiterten IP-Adressformate problemlos verarbeiten, es sei denn, die Weiterleitung von Paketen mit dieser Option wird explizit verweigert. Das Ergebnis sind 64 Bit lange IP-Adressen. Systeme, die NAT nutzen, müssen hierfür ebenfalls gepatcht werden, um die richtige Adresskonvertierung durchführen zu können.
Die Befürworter von Enhanced IP behaupten, dass die IP-Code-Änderungen etwa 400 Zeilen lang sind und der Enhanced IP Code etwa 100 Mal kleiner als der Code für IPv6 ausfällt. Bisher kenne ich noch keine Sicherheitsanalysen von Enhanced IP. Enhanced IP erinnert mich an den TUBA-Ansatz (TCP/UDP Using Big Addresses) aus den 90er Jahren. TUBA wurde damals als eine der Alternativen zur aktuellen IPv6-Suite gehandelt. Das gemeinsame Ziel von Enhanced IP und TUBA ist die Vergrößerung des verfügbaren Adressraums.
Der Nachteil von Enhanced IP besteht darin, dass es auch eine Modifikation des IP-Stacks in allen Endknoten erfordert. Für die Befürworter dieser Lösung sind diese Änderung minimal und könnten durch kleine Patches realisiert werden. Aber genau diese Veränderungen sind die Herausforderungen der Unternehmen, an denen eine Migration scheitern kann.
Easy-IP
Easy IP ist ebenfalls ein Adresserweiterungsmechanismus. Es nutzt den vorhandenen IPv4 reservierten Adressraum von 240/4 und eine Reihe von Semi-Public Routern (SPR), um den Adressraum zu vergrößern. Die Adressierung funktioniert konzeptionell ähnlich wie die lokale Anwahl in CENTREX-Telefonanlagen. Die lokalen Nummern hinter dem SPR sind im Internet nicht sichtbar. Das globale Routing erfolgt nur auf den 240/4 Adressen.
EZIP hat den Vorteil, dass nur SPRs für den 240/4-Adressraum benötigt werden. In der Praxis findet man jedoch viele Netzwerkkomponenten, die nicht erwarten, dass Pakete aus diesem Adressraum zu ihnen übermittelt werden. Aus diesem Grund verwerfen diese Geräte die Pakete aus dem 240/4-Adressraum. Daher müssten auch diese Geräte auf Easy IP aufgerüstet werden.
Fazit
Alle dargestellten Protokolle und Protokollmechanismen befinden sich momentan in aktiver Entwicklung. Das Problem, besteht aus meiner Sicht darin, die erforderlichen Änderungen an den weltweiten Systemen zeitnah vorzunehmen. Die Lösung muss nicht für jeden Endpunkt aus der Vergangenheit einen Migrationspfad bieten, aber eine praktikable Lösung sollte für einen angemessenen Prozentsatz der globalen IPv4-Systeme funktionieren.
Wird eine der dargestellten Lösungen eine breite Akzeptanz finden? Sie hängt von der Bereitstellung der notwendigen Infrastrukturen ab. Dazu müssen die Hersteller von Endgeräten (Microsoft, RedHat, Apple, Android, Linux, etc.) und Netzwerkausrüster (Cisco, Juniper, Arista, etc.) gemeinsam an einem Strang ziehen.
Von Mathias Hein, Chief Marketing Officer bei Allegro Packets GmbH in Leipzig
#Netzpalaver #Allegro
