Wenn Pakete reisen lernen – Vermittlung und Transport im IP-Zeitalter

Kommunikation wird intelligent – wenn Adressen und Wege zusammenfinden

In meinem letzten Beitrag habe ich erläutert, wie elektrische Signale, physikalische Verbindungen und MAC-Adressen die Grundlage für die Netzwerkkommunikation bilden – auf Layer 1 und 2 des OSI-Modells. Dort, wo Bits übertragen und Frames vermittelt werden, geschieht Kommunikation zunächst auf der unmittelbaren, lokalen Ebene. Doch lokale Kommunikation ist nicht das, was das Internet ausmacht. Nicht das, was unsere Welt verbindet.

Denn erst wenn Daten nicht nur von A nach B im selben Netzwerksegment, sondern auch über Netzwerkgrenzen hinweg – durch Router, Providernetze, Kontinente – zuverlässig transportiert werden, wird aus Signalübertragung echte Kommunikation. Genau hier beginnt die Arbeit der Schichten 3 und 4.

In diesem Beitrag möchte ich die Rolle dieser beiden Layer – der Vermittlungsschicht (Layer 3) und der Transportschicht (Layer 4) – technisch fundiert, praxisnah und verständlich beleuchten. Ich lade Sie ein zu einem Blick hinter die Kulissen der IP-Adressierung, des Routings, der Paketverarbeitung und des Transports. Dabei werden wir uns nicht nur mit IPv4 und TCP beschäftigen, sondern auch mit Themen wie NAT, CIDR, Subnetting, Multihoming und – ja – sogar dem vergessenen IPv5.

Ich zeige, wie sich IP-Pakete ihren Weg durch das Netz bahnen, welche Entscheidungen Router dabei treffen und warum Transportprotokolle wie TCP oder UDP nicht bloß technische Details, sondern essenzielle Bausteine unserer digitalen Infrastruktur sind.

Wie immer verfolge ich dabei einen pragmatischen Ansatz: mit Beispielen, Exkursen und konkreten Anwendungsszenarien – für alle, die nicht nur verstehen wollen, dass das Internet funktioniert, sondern warum und wie.

TCP/IP – Historischer Ursprung und Grundkonzept

Bevor wir uns mit IP-Adressierung, Routing und Transportmechanismen im Detail beschäftigen, lohnt sich ein Blick zurück. Denn um zu verstehen, wie sich das Internet technisch entwickelt hat, müssen wir dorthin zurückgehen, wo alles begann: in die frühen 1970er Jahre – zum ARPANET.

Das ARPANET war das erste paketvermittelnde Computernetz der Welt. Es wurde 1969 von der Advanced Research Projects Agency (ARPA) des US-Verteidigungsministeriums initiiert – einer Forschungsbehörde, die heute als DARPA (Defense Advanced Research Projects Agency) bekannt ist.

Die Gründung der ARPA selbst geht auf ein weltpolitisches Schlüsselereignis zurück: den Sputnik-Schock von 1957. Als die Sowjetunion überraschend den ersten künstlichen Satelliten in den Orbit brachte, war das für die USA ein technologischer Weckruf – vergleichbar mit der Schockwirkung des Manhattan-Projekts in der umgekehrten Richtung. Beides zeigte: Wer technologische Sprünge frühzeitig erkennt und nutzt, verschafft sich strategische Vorteile.

Das Manhattan-Projekt selbst – die geheime Entwicklung der Atombombe während des Zweiten Weltkriegs – hatte eindrucksvoll bewiesen, was interdisziplinäre, staatlich geförderte Spitzenforschung unter Zeitdruck zu leisten vermag. Nach dem Krieg wurde dieses Prinzip in der zivil-militärischen Forschung institutionalisiert – mit der ARPA als zentraler Agentur, die gezielt visionäre Projekte förderte, lange bevor sie marktreif oder operativ einsetzbar waren.

DARPA – Geburtshelferin moderner Technologien

Neben dem ARPANET brachte ARPA (später DARPA) eine Vielzahl bahnbrechender Entwicklungen hervor, etwa:

• das satellitengestützte Navigationssystem TRANSIT – ein Vorläufer von GPS,
• frühe Forschung zu autonomen Systemen und Robotik,
• Entwicklungen im Bereich Spracherkennung, KI und maschinelles Lernen,
• sowie entscheidende Impulse für die Halbleitertechnologie und Mikroprozessorarchitektur.

Das ARPANET selbst hatte dabei ein klares Ziel: eine robuste, dezentrale Kommunikationsinfrastruktur zu schaffen, die auch bei Ausfällen einzelner Komponenten oder physikalischen Leitungen weiterarbeitet – ein Gedanke, der vor dem Hintergrund des Kalten Kriegs höchste Priorität hatte. Gleichzeitig sollte es möglich sein, unterschiedliche Netze mit verschiedenen Technologien (z.B. X.25, Satelliten, Ethernet) über ein gemeinsames Protokoll zu koppeln.

Die Geburtsstunde von TCP/IP

Zur Realisierung einer interoperablen Netzstruktur entstand in den 1970er Jahren die TCP/IP-Protokollfamilie. Unter der Leitung von Forschern wie Vinton Cerf und Robert Kahn wurde ein universeller Standard für die Kommunikation zwischen Netzen geschaffen – unabhängig von deren technischer Beschaffenheit.

Im Jahr 1981 wurden die Spezifikationen für IP (RFC 791) und TCP (RFC 793) veröffentlicht. Zwei Jahre später, am 1. Januar 1983, wurde das ARPANET vollständig auf TCP/IP umgestellt – ein Meilenstein, der heute als Geburtsstunde des modernen Internets gilt.

Zum Zeitpunkt der Umstellung umfasste das ARPANET 562 Knoten – verteilt über Universitäten, Forschungseinrichtungen und militärische Stellen. Aus heutiger Sicht mag diese Zahl überschaubar erscheinen, doch sie verdeutlicht einen wichtigen Aspekt: Die vollständige Migration war organisatorisch und technisch noch durchführbar. In einem heute global verteilten, aus Milliarden Geräten bestehenden Internet wäre ein solcher harter Schnitt praktisch unmöglich.

Diese erfolgreiche Umstellung bestätigte die Praxistauglichkeit und Skalierbarkeit des TCP/IP-Modells – und legte den Grundstein für seine weltweite Verbreitung.

TCP und IP – ein starkes Duo

Im Zentrum der TCP/IP-Protokollwelt stehen zwei Protokolle mit klarer Aufgabenverteilung:

• TCP (Transmission Control Protocol) – für eine zuverlässige, verbindungsorientierte Kommunikation auf Layer 4 des OSI-Modells
• IP (Internet Protocol) – für Adressierung und Zustellung auf Layer 3

Während IP nach dem Prinzip Best Effort arbeitet und keine Garantie für die Zustellung gibt, sorgt TCP für Verbindungsaufbau, Fehlerkorrektur, Flusskontrolle und die richtige Reihenfolge der Datenpakete.

Ein anschauliches Bild: IP bringt Ihre Nachricht in den Umschlag und gibt sie bei der Post ab. TCP sorgt dafür, dass der Briefträger sie persönlich zustellt, den Empfang bestätigen lässt – und gegebenenfalls nachfasst, falls etwas schiefläuft.

OSI vs. TCP/IP – Theorie trifft auf Praxis

Während das OSI-Modell der ISO als didaktisch saubere Schichtenstruktur entwickelt wurde, setzte sich in der Praxis der TCP/IP-Stack durch – pragmatisch, robust und implementierungsnah. Die TCP/IP-Welt unterscheidet vier funktionale Ebenen: Netzzugang, Internet, Transport und Anwendung.

Auch in diesem Beitrag bleiben wir bewusst bei der OSI-Terminologie – nicht aus Prinzip, sondern weil sie hilft, Funktionen, Abhängigkeiten und Verantwortlichkeiten systematisch einzuordnen. Alternativ kann zur Beschreibung von Netzwerkfunktionen auch das TCP/IP-Modell herangezogen werden – es ist einfach in der Praxis nur etwas unüblich.

Wenn Sie das nächste Mal eine Website aufrufen oder eine Nachricht per E-Mail oder Messenger senden, denken Sie daran: Im Hintergrund arbeiten TCP und IP unermüdlich zusammen – als Resultat jahrzehntelanger Forschung, Innovation und Zusammenarbeit zwischen staatlichen Institutionen, Wissenschaft und der technischen Community.

Die klassenbezogene Adresswelt von IPv4

Nachdem wir mit TCP/IP die Grundlagen der paketbasierten Kommunikation kennengelernt und mit Jon Postel eine prägende Figur der Internetgeschichte gewürdigt haben, tauchen wir nun tiefer in die Struktur der Adressierung ein – konkret: in die Welt der IPv4-Adressklassen, wie sie in den Anfangsjahren der Internetentwicklung definiert wurden.

Warum Klassen?

In den frühen 1980er Jahren galt es, ein einfaches, hierarchisches Schema zur Vergabe von IP-Adressen zu etablieren. Die Idee: Netzwerke unterschiedlicher Größe sollten mit passenden Adressräumen ausgestattet werden – große Institutionen mit vielen Hosts, kleinere Netzwerke mit wenigen.

Dazu wurde der IPv4-Adressraum in sogenannte Adressklassen A bis E unterteilt, praktisch verwendet wurden dabei jedoch zunächst nur IP-Adressen der Klassen A bis C zur Hostadressierung (RFC 791, 1981), später auch der Klasse D für Multicasting (RFC 1112, 1989):

Die Klassenzugehörigkeit wurde dabei binär über die Stellung der ersten Bits der IP-Adresse bestimmt:

• Klasse A → 0xxxxxxx (0.0.0.0 bis 127.255.255.255)
• Klasse B → 10xxxxxx (128.0.0.0 bis 191.255.255.255)
• Klasse C → 110xxxxx (192.0.0.0 bis 223.255.255.255)
• Klasse D → 1110xxxx (224.0.0.0 bis 239.255.255.255)
• Klasse E → 1111xxxx (240.0.0.0 bis 255.255.255.255)

Somit konnte jedes binär arbeitende System anhand der Bitkonstellation der ersten Bits einer IP-Adresse exakt die jeweilige Adressklasse der IP-Adresse bestimmen. Dies ist immens bedeutsam für die spätere Kommunikationsfähigkeit von TCP/IP in lokalen und nicht-lokalen Netzwerken.

Kein Planungsfehler – sondern angemessenes Design

Aus heutiger Perspektive mag es erstaunen, dass mit IPv4 nur rund 4,3 Milliarden Adressen zur Verfügung stehen. Doch in den 1970er und frühen 1980er Jahren musste dieser Vorrat lediglich einige Hundert bis wenige Tausend Rechner abdecken – verteilt auf zumeist wenig komplexe Netzwerke.

Die Entwickler des Protokolls handelten dabei nicht kurzsichtig, sondern technisch überlegt. Ein 32-Bit-Adressraum war in dieser Phase überdimensioniert – eine strategische Reserve für ein Netzwerk, dessen Potenzial man zwar ahnte, aber in seiner späteren Allgegenwart noch nicht abschätzen konnte.

Die Probleme zeigten sich nicht sofort, sondern entwickelten sich schleichend im Laufe der 1980er Jahre – als die Netze wuchsen, der Bedarf an flexibleren Strukturen stieg und gleichzeitig viele Adressbereiche ineffizient vergeben wurden.

Ineffizienz durch starre Klassen

Was als pragmatische Lösung begann, erwies sich zunehmend als unflexibel:

• Die Sprünge zwischen den Klassen (z.B. 256 IP-Adressen in Klasse C vs. 65.536 in Klasse B) waren zu groß.
• Unternehmen erhielten zu große Netze, von denen sie oft nur einen Bruchteil nutzten.
• Große Adressblöcke wurden frühzeitig reserviert oder blockweise verteilt – etwa an Universitäten, Großunternehmen oder Regierungsstellen.

Ein Reengineering der Adresslogik wurde notwendig.

Routing und Autonome Systeme als Katalysator

Parallel dazu entwickelte sich die Internetinfrastruktur technisch weiter. Immer mehr Betreiber verwalteten ihre eigenen Netze, und das Routing übernahm eine Schlüsselrolle. Die Idee der Autonomen Systeme (AS) setzte sich durch: Organisationen mit eigener Routingpolitik, die untereinander über das Border Gateway Protocol (BGP) kommunizierten.

Die starre Bindung an Adressklassen passte immer schlechter zu dieser Realität. Denn Routingentscheidungen sollten sich nicht mehr an starren Klassen, sondern an flexibel zugewiesenen Präfixen orientieren – und genau das war der Grundstein für das spätere CIDR-Modell (Classless Inter-Domain Routing), das in den 1990er Jahren eingeführt wurde.

Fazit: Die Adressklassen waren ein logischer, sinnvoller Startpunkt in einer überschaubaren Netzwelt. Doch mit der wachsenden Skalierung, der Differenzierung von Netzen und der zunehmenden Rolle des Routings wurde klar: Künftige Netze brauchen mehr Flexibilität – und Routing braucht Präfixe statt Klassen.

Im nächsten Abschnitt gehen wir daher der Frage nach, wie IP-Netze kommunizieren, woran ein Gerät erkennt, ob ein Ziel lokal oder entfernt ist – und welche Rolle dabei Netzwerk-IDs, Subnetzmasken und Gateways spielen.

Wie kommunizieren Hosts in IP-Netzwerken?

Nachdem wir die klassenbasierte Struktur von IPv4-Adressen kennengelernt haben, stellt sich eine entscheidende Frage: Wie erkennt ein Gerät, ob es mit einem Kommunikationspartner direkt sprechen kann – oder ob die Hilfe eines Routers benötigt wird?

Diese Unterscheidung liegt im Zentrum von Layer 3. Und solange IP-Adressen noch klassengebunden interpretiert wurden (also vor CIDR), erfolgte diese Entscheidung ausschließlich anhand der Adressklasse – ohne Subnetzmaske oder Präfixnotation.

Drei Schritte vor der Kommunikation

Bevor ein Host ein IP-Paket versendet, analysiert er anhand festgelegter Klassenregeln, wie das Ziel erreicht werden kann. Das erfolgt in drei aufeinanderfolgenden Schritten:

1. Eigene Netzwerkklasse bestimmen
   → Aus den ersten Bits der eigenen IP-Adresse (z.B. 192.168.10.25) wird die zugehörige Adressklasse ermittelt (hier: Klasse C).
   → Die Regeln der Klasse legen fest, wie viele Bits den Netzwerkanteil bilden (bei Klasse C: 24 Bit).
2. Adressklasse des Ziels bestimmen und als kompatibel annehmen
   → Auch die Zieladresse (z. B. 192.168.10.66) wird der entsprechenden Klasse zugeordnet.
   → Dabei wird angenommen, dass Sender und Empfänger derselben Netzwerkklasse angehören, sofern nicht explizit anders bekannt (z.B. über Routingtabellen).
   Ein IP-Host geht somit grundlegend davon aus, dass die Kommunikation lokal stattfindet. Entsprechend muss dazu der Zielhost in der gleichen Ethernet-Broadcastdomäne liegen und die gleiche Netzwerk-ID aufweisen. Da ist es nur folgerichtig, dass der Zielhost dann auch der gleichen Adressklasse entspringen muss. Dieses Vorgehen ist weniger Lastintensiv als die eigentliche Feststellung der Adressklasse und spart Ressourcen – immerhin befinden wir uns zeitlich am Anfang der 1980er Jahre und Computerressourcen sind begrenzt und müssen sparsam eingesetzt werden.
3. Netzwerk-IDs vergleichen
   → Aus beiden IP-Adressen wird auf Basis ihrer Klasse die jeweilige Netzwerk-ID (IP-Adresse, bei der Bit des Hostanteils auf 0 stehen)berechnet.
   → Stimmen beide Netzwerk-IDs überein, gilt das Ziel als lokal erreichbar – die Kommunikation erfolgt direkt (z.B. über ARP zur lokalen Auflösung der IP-Adresse zur MAC-Adresse des Ziels).
   → Stimmen sie nicht überein, muss das Paket an ein konfiguriertes Gateway weitergeleitet werden, oder – insofern kein Gateway eingerichtet wurde – verworfen werden.

Beispiel: Kommunikation im Klassenmodell

• Quell-IP: 192.168.10.25
• Ziel-IP: 192.168.10.66
• Beide Adressen liegen in der Klasse C
  → Netzwerkanteil: 24 Bit (192.168.10.25 / 192.168.10.66)
  → Hostanteil: Rest, hier: 8 Bit (192.168.10.25 / 192.168.10.66)
  → Netzwerk-IDs stimmen überein (192.168.10.0 = 192.168.10.0)
  → direkte Kommunikation möglich

Wäre das Ziel hingegen 172.16.0.35 (Klasse B, Netzwerkanteil 16 Bit), ergibt der Vergleich eine andere Netzwerk-ID (172.16.0.0) → Kommunikation nicht lokal, es wird ein Gateway benötigt.

Ohne Gateway – keine Kommunikation über Segmentgrenzen

Ein häufig übersehener Punkt: Ist kein Gateway konfiguriert, können IP-Pakete an fremde Netzwerke nicht versendet werden – auch wenn die Zieladresse korrekt wäre. Das Betriebssystem verwirft das Paket, da es keine Möglichkeit zur Weiterleitung kennt.

Das bedeutet:

• Lokale Kommunikation (innerhalb desselben Netzsegments) ist auch ohne Gateway möglich
• Nicht-lokale Kommunikation ist ohne Gateway-Eintrag technisch unmöglich

Dieses Verhalten ist tief in den TCP/IP-Stacks verankert – sowohl unter Windows als auch in Unix-basierten Systemen. Es erklärt u.a., warum Netzwerkverbindungen manchmal scheinbar grundlos scheitern: das Ziel ist korrekt, aber der Weg dorthin fehlt.

Fazit: Kommunikation beginnt mit Klassenzugehörigkeit

In der frühen IPv4-Welt war die Entscheidung über lokal oder entfernt eine einfache Vergleichsrechnung auf Klassenbasis. Erst mit dem Aufkommen von CIDR, Subnetting und individuellen Netzmasken wurde diese Logik deutlich flexibler – aber auch komplexer.

Im nächsten Abschnitt wechseln wir jedoch zunächst die Perspektive und betrachten das Routing im Detail: Wie funktioniert die Übergabe an ein Gateway? Wie treffen Router ihre Entscheidungen? Und was passiert eigentlich mit einem IP-Paket, das auf Reise geht?

Routing – Von der Netzwerkgrenze zum globalen Pfad

Sobald ein Host erkennt, dass sein Kommunikationsziel nicht im eigenen Netzwerksegment liegt, muss er das Paket weiterleiten lassen. Genau an dieser Stelle beginnt die Domäne der Vermittlungsschicht (Layer 3) – genauer: das Routing.

Routing ist der Prozess, mit dem IP-Pakete über Netzgrenzen hinweg an ihr Ziel geleitet werden – über Router, Backbone-Systeme und Transitnetze. Während der Absender nur das Ziel kennt, entscheiden die Router unterwegs auf Basis ihrer Routingtabellen, wohin das Paket als Nächstes gesendet wird.

Das Default Gateway – Türöffner zur Welt

Für Hosts in einem lokalen Netz ist Routing zunächst sehr einfach geregelt: Sie kennen genau ein Gateway, das sie nutzen dürfen – das sogenannte Default Gateway. Dieses ist die IP-Adresse des nächstgelegenen Routers im eigenen Netzsegment.

Regel: Kennt der Host keinen direkten Weg zum Ziel, übergibt er das Paket an sein Gateway – das entscheidet, wie es weitergeht.

Das Gateway fungiert dabei als Eingangstür zum Rest der Welt. Es nimmt das Paket entgegen, prüft die Zieladresse und sucht in seiner Routingtabelle nach einem passenden nächsten Hop – also der nächsten Instanz, die das Paket weiterverarbeiten kann.

Routingprinzip: Hop-by-Hop statt End-to-End

Ein häufiges Missverständnis: Router kennen nicht den gesamten Pfad zum Ziel. Stattdessen entscheiden sie immer nur über den nächsten Schritt – auf Basis der besten verfügbaren Route zu einem Zielpräfix (Netzwerk).

Das Routing im Internet basiert auf dem Hop-by-Hop-Prinzip:
Jeder Router trifft eine lokale Entscheidung auf Basis seiner Routingtabelle – ähnlich wie ein Navigationsgerät, das an jeder Kreuzung neu entscheidet.

Diese Tabellen können statisch gepflegt (z.B. in kleinen Netzwerken) oder dynamisch erzeugt werden – z.B. durch Protokolle wie RIP, OSPF oder BGP. Letzteres ist das zentrale Routingprotokoll zwischen Autonomen Systemen im Internet.

Beispiel: Eine Reise durch das Netz

Ein IP-Paket mit Ziel 172.217.22.14 (google.de) wird durch den Client zum Router weitergeleitet, weil die Zieladresse außerhalb des eigenen Netzwerks 192.168.5.0 liegt.

1. Das Paket wird an das Default Gateway gesendet (z.B. 192.168.5.1)
2. Der lokale Router prüft, ob er das Ziel direkt kennt. Falls nein:
3. Weiterleitung an den Upstream-Router des Providers
4. Dieser konsultiert seine globale BGP-Tabelle
5. Paket durchläuft ggf. mehrere Autonome Systeme (AS) über dedizierte Pfade
6. Am Zielnetz angekommen, wird das Paket lokal zugestellt

Jeder Router auf diesem Weg kennt nur den nächsten Schritt, nicht das gesamte Zielnetzwerk. Und dennoch funktioniert die Kommunikation in Sekundenbruchteilen und weltweit zuverlässig.

Und wenn kein Weg bekannt ist?

Wichtig: Findet ein Router keinen passenden Eintrag für das Ziel in seiner Routingtabelle – und hat auch keine Default-Route –, wird das Paket verworfen. Der Absender erhält ggf. eine ICMP-Fehlermeldung (Destination Unreachable).

Dies zeigt: Routing ist kein Ratespiel, sondern ein hochdynamischer Entscheidungsprozess auf Basis konsistenter, kontinuierlich gepflegter Informationen.

Übergang: Routing wird zum Designfaktor

Spätestens jetzt wird klar: Routing ist weit mehr als Pakete weiterschicken. Es ist ein zentrales Designinstrument für skalierbare Netze – und verlangt Entscheidungen über Netzsegmentierung, Verbindungsstrategien und Pfadoptimierung.

Doch um Routing effizient betreiben zu können, braucht es mehr als starre Klassen. Es braucht flexible Adressräume, variable Netzgrenzen – und genau das war die Motivation hinter dem Wechsel zur klassenlosen Adressierung (CIDR), mit dem wir uns im nächsten Abschnitt beschäftigen.

CIDR und die klassenlose Zukunft

Mit der rasant wachsenden Verbreitung des Internets in den 1990er Jahren wurde eines immer deutlicher: Die klassenbasierte Adresslogik war der Skalierbarkeit und Effizienz eines globalen IP-Netzes nicht mehr gewachsen. Das Internet benötigte ein Adressierungskonzept, das auf Flexibilität, Feinabstimmung und ressourcenschonende Allokation ausgelegt war.

Die Antwort war CIDR – Classless Inter-Domain Routing.

Was ist CIDR?

CIDR wurde 1993 eingeführt (RFC 1518/1519) und beschreibt ein Verfahren, bei dem Netzwerkgrenzen nicht mehr durch Klassen, sondern durch flexible Präfixlängen definiert werden. Statt sich an den starren Grenzen von Klasse A, B oder C zu orientieren, konnte man fortan beliebige Netzgrößen in Bit-Präfixnotation darstellen:

Beispiele:

• 10.0.0.0/8 → 16.777.216 Adressen (klassisch: Klasse A)
• 172.16.0.0/12 → 1.048.576 Adressen (überlappt Klasse B)
• 192.168.0.0/24 → 256 Adressen (klassisch: Klasse C)

Der Ausdruck /24 gibt an, dass die ersten 24 Bits die Netzwerk-ID bilden. Der Rest dient der Hostadressierung innerhalb dieses Netzes.

Klassenbezogene Netzmasken – Brücke zur Kompatibilität

In der Übergangszeit von der klassenbasierten zur klassenlosen Adressierung wurden zunächst die klassischen Netzgrenzen – /8, /16, /24 – in CIDR-kompatibler Notation übernommen, um die Abwärtskompatibilität zu bestehenden Systemen sicherzustellen.

Diese klassenbezogenen Netzmasken (auch „default masks“) entsprachen exakt den ursprünglichen Adressklassen:

Diese Notationen wurden von Betriebssystemen, Routern und Netzwerktools als bequeme Standardwerte übernommen – insbesondere in kleinen und mittelgroßen Netzen. Bis heute sind sie Quasi- Standards, selbst in einer vollständig CIDR-fähigen Infrastruktur.

Fazit: Auch wenn CIDR heute völlige Flexibilität erlaubt, bleiben /8, /16 und /24 tief in der Netzwerkpraxis verankert – nicht aus technischer Notwendigkeit, sondern aus Gewohnheit und Kompatibilitätsdenken.

Vorteile gegenüber klassischer Adressierung

Mit CIDR ließen sich Adressen wesentlich effizienter zuweisen, weil Netzgrößen exakt an den Bedarf angepasst werden konnten:

• Kein Overprovisioning mehr (z. B. 65.536 Adressen für 300 Hosts)
• Feingranulare Zuteilung im Rechenzentrums- und Providereinsatz
• Aggregation von Routen (Stichwort: Route Summarization)
• Grundlage für moderne Subnetting- und Supernetting-Strategien

Diese Umstellung war nicht nur ein Verwaltungsakt, sondern ein notwendiger Schritt zur Sicherung der IPv4-Ressourcen – und eine Voraussetzung für die Zukunftsfähigkeit des Internets.

CIDR und Routing: weniger ist mehr

Ein weiterer wesentlicher Vorteil von CIDR liegt im Routingsystem. Router mussten nicht mehr jeden einzelnen Zielblock separat kennen, sondern konnten ganze Netzbereiche mit einem einzigen Eintrag zusammenfassen:

Beispiel:

• Anstelle von 256 Einträgen für 192.168.0.0/24 bis 192.168.255.0/24 genügt ein Eintrag für 192.168.0.0/16

Diese Aggregation führte zu einer massiven Reduktion der Routingtabellen im Internet – eine dringend benötigte Maßnahme angesichts der explosionsartigen Zunahme an Netzsegmenten.

CIDR verdrängt Klassen – aber nicht sofort

Obwohl CIDR die Klassenlogik technisch vollständig ersetzt hat, ist das Denken in Klassen bis heute verbreitet – sei es in Tools, in alten Konfigurationen oder in der Ausbildung. Viele verbinden z.B. ein /24 reflexartig mit Klasse C – auch wenn das in der klassenlosen Welt keine Rolle mehr spielt.

Deshalb gilt: CIDR ist kein Zusatz zur Klassenzugehörigkeit, sondern ihre vollständige Ablösung. Wer CIDR verwendet, arbeitet nicht mehr mit Klassen, sondern mit präzise definierten Netzgrenzen.

Übergang zum Subnetting

CIDR schafft die Grundlage für eine weitere Schlüsseltechnik: das Subnetting. Denn erst durch die Möglichkeit, Netzwerke in beliebig große Teilnetze zu zerschneiden oder zu aggregieren, wird eine feingranulare Netzarchitektur realisierbar – abgestimmt auf Standorte, Abteilungen, Sicherheitszonen oder logische Einheiten.

Im nächsten Abschnitt widmen wir uns daher den konkreten Techniken des Subnetting und Supernetting – inklusive symmetrischer und asymmetrischer Teilnetze, Beispielrechnungen und typischer Szenarien aus der Praxis.

Subnetting und Supernetting – Netze effizient schneiden

CIDR hat die starre Welt der Adressklassen hinter sich gelassen und ermöglicht es, Netze flexibel in kleinere (Subnetting) oder größere Einheiten (Supernetting) zu unterteilen. Diese Technik ist das Rückgrat moderner Netzplanung – in Unternehmen, Rechenzentren und Internet-Backbones.

Doch so einfach Subnetting in der Theorie klingt, so wichtig ist das Verständnis der technischen Konsequenzen, insbesondere im Hinblick auf die verlorenen Adressen pro Netz und die historische Entwicklung der Subnetzgrenzen.

Warum Subnetting?

Subnetting dient der logischen Trennung eines größeren IP-Netzes in kleinere, übersichtlichere und sicherer handhabbare Einheiten:

• Trennung nach Standorten, Abteilungen oder Sicherheitszonen
• Begrenzung von Broadcast-Domänen
• Effiziente Nutzung von IP-Adressen

Beispiel: Aus 192.168.0.0/24 sollen vier Subnetze mit je 64 Adressen entstehen → Aufteilung in /26-Netze.

Netzwerk-ID und Broadcast-Adresse: zwei verlorene Adressen pro Subnetz

In jedem IP-Subnetz sind zwei Adressen reserviert und nicht für Hostkommunikation nutzbar:

1. Netzwerkadresse (Netzwerk-ID):
   Sie repräsentiert das gesamte Subnetz und ist in Routingtabellen, Konfigurationsdateien oder DHCP-Scopes sichtbar. Ein Paket darf nicht an diese Adresse gesendet werden.
2. Broadcast-Adresse:
   Diese Adresse adressiert alle Hosts im Subnetz (Limited Broadcast) und wird für Protokolle wie ARP oder DHCP verwendet. Auch diese Adresse darf keinem Endgerät zugewiesen werden.

Das bedeutet:

In jedem Subnetz sind effektiv nur 2ⁿ – 2 Adressen nutzbar, wobei n die Anzahl der Host-Bits ist.

Beispiel:

• /24 = 256 Adressen → 254 nutzbar
• /30 = 4 Adressen → 2 nutzbar
• /31 = historisch unbrauchbar (heute Sonderfall für Punkt-zu-Punkt)

Dies ist keine Besonderheit von Subnetting, sondern tritt bereits in der klassenspezifischen IP-Adressierung auf. Beim Subnetting und der damit verbundenen Unterteilung eines Netzes in mehrere kleinen Netze, wirkt sich dieser Effekt jedoch umso stärker aus.

Achtung: Netzwerk- und Broadcastadresse sind nicht an .0 oder .255 erkennbar

Ein weitverbreiteter Irrtum: Die Netzwerk-ID endet immer auf .0, und die Broadcast-Adresse immer auf .255. Das stimmt nur bei /24-Netzen.

Beispiele:

• 192.168.10.64/26 →
• Netzwerk-ID: 192.168.10.64
• Broadcast: 192.168.10.127
• 10.0.5.128/27 →
• Netzwerk-ID: 10.0.5.128
• Broadcast: 10.0.5.159

Fazit: Die Netzgrenze wird durch das Präfix bestimmt – nicht durch bestimmte Zahlenmuster am Ende der Adresse. Nur mit korrektem CIDR-Verständnis lässt sich erkennen, welche Adressen im Subnetz gültig sind.

Subnet Zero und All-One Subnet – ein historisches Relikt

Früher war es nicht erlaubt, das erste und letzte Subnetz eines größeren Netzes zu verwenden:

• Subnet Zero: Erste Teilmenge, deren Netzwerk-ID mit der ursprünglichen Hauptnetzadresse übereinstimmt (z.B. 192.168.0.0/26 aus 192.168.0.0/24)
• All-One Subnet: Letztes Subnetz, bei dem alle Host-Bits auf 1 gesetzt sind

Diese Einschränkung wurde aus Kompatibilitäts- und Interpretationsgründen im Hinblick auf die klassenbezogene IP-Adressierung eingeführt: Geräte sollten nicht Subnetzgrenzen mit Adressgrenzen verwechseln. Erst mit RFC 1878 (1995) wurde die Nutzung dieser Subnetze offiziell erlaubt (ip subnet-zero). Dieses anfängliche Verbot führte jedoch dazu, gegebene Netze in viele Subnetze zu unterteilen, um diese Verluste so gering wie möglich zu halten.

Zum einen lässt sich dieser Aspekt auch heute noch in manchen Netzwerken beobachten, wenn mitunter aus historischen und meist nicht mehr nachzuvollziehenden Gründen entsprechend kleine Subnetze verwendet werden. Zum anderen ist es jedoch auch einfach nachzuvollziehen, bis zu welchem Punkt sich diese immer granularere Unterteilung noch rechnet.

Ein Rechenexempel: Subnetze vs. Adressverlust

Je umfangreicher ein gegebenes Netz in kleinere Subnetze unterteilt wird, desto höher ist der relative Verlust durch Netzwerk- und Broadcast-Adressen. Drei konkrete Beispiele aus der heutigen Praxis auf Basis eines gegebene Netzwerks 192.168.5.0/24 mit insgesamt 256 IP-Adressen:

Würden wir jedoch hier die Regeln aus der Vergangenheit (Subnet Zero, All-One Subnet) anwenden, erhalten wir gänzlich andere Zahlen:

In einem /24-Netz, das in der Wahl der IP-Adresse einem echten Klasse C-Netzwerk entspricht (z.B. 192.168.5.0/24), verlieren wir – wie oben aufgeführt – nur zwei IP-Adressen. Unterteilen wir dieses Netz jedoch unter Verwendung einer /26-Maske in vier Netzwerke, kämen wir auf einen Verlust von 132 IP-Adressen (das Subnet Zero mit 64 IP-Adressen, insgesamt vier IP-Adressen der Subnetze 2 und 3, sowie das All-One Subnet mit ebenfalls 64 IP-Adressen).

Wie können diese Verluste nun minimiert werden? Genau – wir gestalten eben jene verlustreichen Subnetze entsprechend kleiner. Bei Verwendung einer /27-Maske erhalten wir nun eine Unterteilung in acht Subnetze mit jeweils 32 IP-Adressen, verlieren in diesem Kontext aber nur noch 76 IP-Adressen. Dies geht jedoch nicht ewig so weiter: Während wir im nächsten Teilungsschritt auf 16 Subnetze mit jeweils 16 IP-Adressen zunächst noch weniger Verlust verzeichnen, nämlich nur noch 60 IP-Adressen, nimmt anschließend der Gesamtverlust wieder zu. Nicht durch die Verluste im ersten und letzten Subnet, sondern durch den Verlust von zwei IP-Adressen pro Subnet zwischen diesen beiden Subnetzen.

Obwohl diese Regel seit 30 Jahren als veraltet gilt, hält sich in manchen Netzen jedoch noch immer die Struktur möglichst kleiner Subnetze. Liegt die Wahl dieser Aufteilung in der hier dargestellten Problematik begründet, ist diese Sichtweise heute nicht mehr zeitgemäß. Sollten keine weiteren Gründe für die spezifische Aufteilung vorliegen, kann nicht selten eine unkritische Übernahme historischer Netz-Konstrukte unterstellt werden.

Supernetting – Aggregieren statt Zerteilen

Während Subnetting Netze in kleinere Einheiten zerlegt, verfolgt Supernetting das entgegengesetzte Ziel: Mehrere zusammenhängende Netze werden zu einem größeren logischen Block zusammengefasst, um die Komplexität in Routingtabellen zu reduzieren – insbesondere bei Backbone-Providern, BGP-Konfigurationen und großen Enterprise-Netzen.

Beispiel:

• Vier benachbarte Netze 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24
  → können als 192.168.0.0/22 zusammengefasst werden

Voraussetzung: Bitkompatibilität und Adjazenz

Damit Supernetting möglich ist, müssen die zu aggregierenden Netze bestimmte Bedingungen erfüllen:

1. Benachbart im Adressraum
   → Die Netzwerke müssen direkt aufeinander folgen, ohne Lücken
2. Bitkompatibel im Netzwerkpräfix
   → Die ersten n Bits (je nach gewünschter Aggregationsstufe) müssen identisch sein
3. Grenzen auf 2ⁿ-Niveau
   → Die Anzahl der Netze muss eine Zweierpotenz sein, und das erste Netz muss auf einem passenden Block beginnen
   → Beispiel: Für ein /22 müssen vier aufeinanderfolgende /24-Netze aggregierbar sein – und das erste Netz muss bei .0 beginnen

Falsch wäre also z.B.:
Aggregation von 192.168.1.0/24 + 192.168.2.0/24 → nicht zulässig, da 192.168.1.0/24 nicht auf einer /23-Grenze beginnt

Technischer Nutzen

Supernetting wird in der Praxis u.a. genutzt für:

• Route Summarization in dynamischen Routingprotokollen (z.B. OSPF, EIGRP)
• BGP-Aggregation durch Internet Service Provider
• Vereinfachung von ACLs, Firewall-Policies und NAT-Regeln

Es reduziert den Eintragungs- und Rechenaufwand für Router erheblich und verbessert die Skalierbarkeit großer Netzwerke.

Mit dieser Aggregationstechnik am oberen Ende und dem Subnetting am unteren Ende schließt sich der Kreis: Netzarchitektur auf Layer 3 wird zur Frage des Designs – zwischen Granularität, Ressourcenschonung und strategischer Planung.

Im nächsten Abschnitt betrachten wir nun, warum es trotz aller technischen Optimierungen zur Adressknappheit im IPv4-Raum kam – und wie mit NAT (Network Address Translation) ein pragmatischer, wenn auch langfristig problematischer Lösungsweg eingeschlagen wurde.

NAT als Notlösung – Wenn Adressen knapp wurden

Trotz der Einführung von CIDR, Subnetting und effizienter Netzplanung näherte sich der IPv4-Adressraum Mitte der 1990er Jahre einem kritischen Punkt: Der ursprünglich großzügig bemessene Vorrat von rund 4,3 Milliarden Adressen war nicht für eine weltweite, private wie industrielle Nutzung konzipiert worden.

Die rasant steigende Zahl von Endgeräten – vom Arbeitsplatzrechner bis zum DSL-Router – stellte das Adressmodell vor eine simple Frage: Was tun, wenn die öffentlichen Adressen nicht mehr ausreichen?

Die Antwort lautete: NAT – Network Address Translation.

Die Idee hinter NAT

Mit NAT wurde die Adresslogik aufgebrochen – der Kernmechanismus:

Private IP-Adressen im lokalen Netz werden durch öffentliche IP-Adresse ersetzt, sobald Daten das lokale Netzwerk verlassen.

Ein NAT-fähiger Router übersetzt dabei die Quelladresse eines ausgehenden Pakets (z.B. 192.168.1.100) in eine öffentliche Adresse (z.B. 203.0.113.45) – und merkt sich intern, an welchen Host die Antwort später zurückgeleitet werden soll.

Wo kommen diese öffentlichen IP-Adressen her? Neben einer öffentlichen IP-Adresse, die der externen Schnittstelle des NAT-Routers zugewiesen ist, verwaltet der NAT-Router noch weitere öffentliche IP-Adressen aus dem gleichen Netzbereich in einem NAT-IP-Pool. Jedem internen Host, der mit einer privaten IP-Adresse kommuniziert und ein externes Ziel anspricht, wird dabei eine dieser öffentlichen IP-Adressen zugewiesen. Sind dabei alle öffentlichen IP-Adressen temporär internen IP-Adressen zugeordnet, kann kein weiterer interner Host mit einem externen Ziel kommunizieren, bis wieder eine öffentliche IP-Adresse im Pool zur Verfügung steht.

Private Adressbereiche nach RFC 1918

Damit NAT zuverlässig funktioniert, wurden 1996 im RFC 1918 offizielle Adressbereiche für den privaten Gebrauch reserviert:

Adressen aus diesen Bereichen dürfen im Internet nicht geroutet werden – und sind daher perfekt für lokale Netze mit NAT-Übergang.

PAT – NATs kleiner Bruder

In den meisten Heimnetzwerken kommt heute eine Variante von NAT zum Einsatz: das PAT (Port Address Translation) – auch NAT Overload genannt. Hierbei werden nicht nur IP-Adressen, sondern auch Quellports umgeschrieben, sodass viele interne Hosts gleichzeitig dieselbe öffentliche Adresse nutzen können – unterschieden nur durch Portnummern.

Beispiel:

• Intern: 192.168.1.5:55000 →
• Extern: 203.0.113.45:60512

Somit ist der Pool öffentlicher IP-Adressen nicht mehr notwendig und der gesamte ausgehende IP-Verkehr kann mit Hilfe der einen öffentlichen IP-Adresse des NAT-Routers übersetzt werden.

NAT war nie als Dauerlösung gedacht

NAT war von Beginn an als provisorisches Hilfsmittel konzipiert – eine pragmatische Reaktion auf einen strukturellen Engpass. Dass es sich über Jahrzehnte als De-facto-Standard halten würde, war ursprünglich nicht vorgesehen.

Doch weil IPv6 lange auf sich warten ließ und Netzbetreiber NAT in ihren Infrastrukturen tief verankerten, wurde daraus ein längerfristiger Kompromiss – mit allen Konsequenzen für Anwendungsdesign, Sicherheit und Protokollkompatibilität.

Ausblick: IPv6 als Befreiung von NAT

Mit IPv6 kehrt das Internetprotokoll zurück zu seiner ursprünglichen Idee:

Jeder Host erhält eine globale, eindeutige Adresse – ganz ohne NAT.

Im nächsten Abschnitt steigen wir daher ein in die Welt von IPv6: 128 Bit, riesige Adressräume, neue Adresslogik – und eine Netzarchitektur, die von Grund auf für moderne Kommunikation gedacht ist.

IPv6 – Der nächste Adressraum

Während NAT über Jahrzehnte hinweg als pragmatische Brückentechnologie diente, war die eigentliche Lösung längst entworfen: IPv6 – Internet Protocol Version 6, 1997 als RFC 2460 (inzwischen ersetzt durch RFC 8200) standardisiert, wurde als langfristiger Nachfolger von IPv4 konzipiert. Ziel war es nicht nur, den Adressraum drastisch zu erweitern, sondern das Protokoll von Grund auf zu modernisieren.

128 Bit für eine vernetzte Zukunft

Der wichtigste Unterschied ist augenfällig: IPv6 verwendet 128 Bit lange Adressen, im Vergleich zu den 32 Bit bei IPv4. Das ergibt einen theoretischen Adressraum von:

2¹²⁸ ≈ 3,4 × 10³⁸ Adressen → sprich: 340 Sextillionen
genug, um jedem Sandkorn der Erde mehrere IP-Adressen zuzuweisen – jeder Quadratmillimeter Erdoberfläche könnte mit mehr als 600 Milliarden IPv6-Adressen versehen werden.

Doch es geht nicht allein um Quantität. IPv6 bringt auch ein grundlegend neues Designprinzip mit:

• Hierarchische, aggregierbare Adressräume
• Globale Erreichbarkeit ohne NAT
• Integrierte Mechanismen für Autokonfiguration, Sicherheit und Mobilität

Aufbau einer IPv6-Adresse

Eine IPv6-Adresse besteht aus 8 Blöcken zu je 16 Bit, geschrieben in hexadezimaler Schreibweise:

Beispiel:
2001:0db8:85a3:0000:0000:8a2e:0370:7334

Typische Vereinfachungen:

• Führende Nullen dürfen weggelassen werden
• Einmalig dürfen zusammenhängende Nullblöcke mit :: abgekürzt werden

Ergebnis:
2001:db8:85a3::8a2e:370:7334

Adresstypen in IPv6

IPv6 kennt drei grundlegende Adresstypen:

Broadcasts entfallen vollständig – stattdessen werden Multicast-Gruppen zielgerichtet verwendet. Aber: es gibt einen All-Node Multicast!

Adressbereiche (Auszug)

Konfiguration: SLAAC und DHCPv6

Im Gegensatz zu IPv4 bietet IPv6 eingebaute Autokonfigurationsmechanismen:

• SLAAC (Stateless Address Autoconfiguration):
  Geräte generieren ihre Adresse selbstständig auf Basis des Router-Advertisements
• DHCPv6:
  Optionaler Mechanismus zur zentralen Adressvergabe und Verwaltung

Damit entfällt in vielen Szenarien die Notwendigkeit manueller Adresskonfiguration oder eines DHCP-Servers.

Kein NAT mehr – Rückkehr zur End-to-End-Kommunikation

Eine der zentralen Designentscheidungen in IPv6 war der Verzicht auf NAT. Jeder Host kann mit einer global gültigen Adresse direkt adressiert werden. Dadurch werden:

• Komplexität reduziert
• Transparenz erhöht
• Peer-to-Peer-Protokolle vereinfacht

IPv6 setzt stattdessen auf firewallbasierte Sicherheit, nicht auf Adressübersetzung.

IPv6 und NAT – kein Widerspruch?

So eindeutig die Standardsituation ist, so kontrovers wird die Realität diskutiert. In der Praxis wird vermehrt über NAT66 gesprochen – also die Anwendung von Network Address Translation auch im IPv6-Kontext.

Gründe für NAT66 aus Betreibersicht:

• Adressmaskierung zur Wahrung interner Strukturen
• Trennung von Provider- und Kundennetzen
• Failover-Szenarien beim Providerwechsel ohne Re-Addressierung
• Betriebsgewohnheiten (NAT als Sicherheitsbarriere) aus der IPv4-Welt

Kritikpunkte an NAT66:

• Verstoß gegen das End-to-End-Prinzip
• Zusätzliche Fehlerquellen und Komplexität
• Verlust von Transparenz im Netzwerkbetrieb
• Erneute Notwendigkeit von Übersetzungstabellen und Portverwaltung

Position der IETF:
NAT66 ist nicht vorgesehen und wird nicht empfohlen. Stattdessen sollen Techniken wie Prefix Delegation, Renumbering, oder Provider-Independent (PI) Adressierung eingesetzt werden.

Fazit:

IPv6 kann mit NAT umgehen – aber es braucht NAT nicht.
Die Diskussion um NAT66 zeigt vielmehr, wie tief NAT als Prinzip in Netzwerkbetrieb und Sicherheitsdenken verankert ist – auch wenn es technisch nicht mehr nötig ist.

Warum IPv6 noch nicht überall angekommen ist

Trotz aller Vorteile ist der flächendeckende Durchbruch von IPv6 langsam verlaufen. Gründe sind:

• Bestandsnetze mit funktionierendem IPv4 + NAT
• Legacy-Anwendungen und Hardware ohne IPv6-Support
• Fehlende Motivation auf Seiten kleiner Netzbetreiber

Heute wird IPv6 oft im Dual Stack betrieben: IPv4 und IPv6 parallel – bis zur vollständigen Ablösung.

Fazit: IPv6 ist kein Upgrade – es ist ein Neuanfang

IPv6 ist mehr als ein größerer Adressraum. Es ist ein architektonischer Neustart, der viele Konzepte von Grund auf neu denkt – in Richtung Skalierbarkeit, Automatisierung und globaler Interoperabilität.

Im nächsten Exkurs schauen wir auf ein Kapitel, das oft untergeht: TCP/IPv5 – das vergessene Protokoll. Warum wurde es nie der Nachfolger von IPv4, obwohl es existierte? Und welche Rolle spielte das Streaming Protocol II?

Vertiefung technischer Konzepte

IP-Kommunikation ist weit mehr als das Weiterleiten von Paketen. Unter der Oberfläche der Vermittlungs- und Transportschichten wirken zahlreiche Mechanismen, die für Effizienz, Skalierbarkeit und Funktionalität im Gesamtnetz sorgen. Wer Netzwerke nicht nur nutzt, sondern verstehen will, sollte diese Konzepte kennen – denn sie entscheiden über Stabilität, Performance und Fehlertoleranz.

MTU und Fragmentierung – Wenn Pakete zu groß sind

Die Maximum Transmission Unit (MTU) bezeichnet die maximale Paketgröße, die auf einem Übertragungsweg ohne Fragmentierung übertragen werden kann. Für Ethernet liegt diese standardmäßig bei 1.500 Byte.

Was passiert, wenn ein IP-Paket größer ist als die MTU des nächsten Netzsegments?

In IPv4 wird das Paket fragmentiert – es wird in kleinere Teile zerlegt, die einzeln übertragen und am Ziel wieder zusammengesetzt werden.

Problematisch daran:

• Fragmentierte Pakete belasten Ressourcen
• Verluste einzelner Fragmente machen das ganze Paket unbrauchbar
• Firewalls blockieren oft Fragmente aus Sicherheitsgründen

In IPv6 wird Fragmentierung nicht mehr durch Router, sondern ausschließlich durch den Absender durchgeführt – und auch nur, wenn dieser die MTU per Path MTU Discovery korrekt ermittelt.

Fazit: Optimale Paketgrößen sind zentral für die Performance.

Die Loopback-Adresse – Netzwerk ohne Netz

Die IPv4-Adresse 127.0.0.1 (und alle Adressen aus 127.0.0.0/8) stehen für das eigene Gerät – ohne Umweg über eine Netzwerkkarte.

Diese Adresse nennt man Loopback – eine Art Netzwerk-Spiegel für lokale Kommunikation, etwa für Softwaretests, lokale Server oder Diagnosen.

In IPv6 ist ::1 die entsprechende Loopback-Adresse.

Multicast – Kommunikation an viele, aber nicht alle

Multicast ist ein intelligenter Mittelweg zwischen Unicast (1:1) und Broadcast (1:alle). Ein Sender adressiert gezielt eine Gruppe von Empfängern, die sich für den Empfang registriert haben – etwa bei Videostreaming, Online-Schulungen oder Routingprotokollen.

• IPv4-Multicast-Adressen: 224.0.0.0/4
• IPv6-Multicast-Adressen beginnen mit ff00::/8

Einige bekannte IPv4-Multicast-Adressen:

Multicast setzt auf spezielle Protokolle wie IGMP (IPv4) bzw. MLD (IPv6) zur Gruppenverwaltung.

Routingprotokolle – So findet das Netz seinen Weg

Die Entscheidung, wie ein IP-Paket durch das Netz wandert, basiert auf Routingtabellen. Diese Tabellen können manuell gepflegt werden – oder durch Routingprotokolle automatisch erstellt und aktualisiert.

Routingprotokolle lassen sich grob in zwei Klassen einteilen:

• RIP: Distanzvektor, einfach, aber limitiert (max. 15 Hops)
• OSPF: Link-State, schnell konvergent, weit verbreitet in Unternehmensnetzen
• EIGRP: Cisco-proprietär, hybrid
• BGP: Rückgrat des Internets, Pfadvektor, hochskalierbar

Routing ist dynamische Topologieerkennung mit mathematischem Fundament.

Fazit: Details, die den Unterschied machen

Diese Konzepte erscheinen auf den ersten Blick technisch – doch sie entscheiden in der Praxis über:

• Stabilität (z.B. MTU-Verhalten)
• Sicherheit (z.B. Fragmentierungsvermeidung)
• Effizienz (z.B. Multicast, dynamisches Routing)
• Fehlersuche (z.B. Loopback, Route Debugging)

Ein Netzwerk ist eben mehr als nur Kabel und IP-Adressen – es ist ein System aus Regeln, Strategien und Feingefühl.

Praxisbezug / Anwendungsszenarien

Ob Unternehmensnetzwerk, Heimrouter oder Cloud-Dienst – die Mechanismen der Schichten 3 und 4 bilden überall das Rückgrat der digitalen Kommunikation. Wer IP-Routing, Adresskonzepte und Transportprotokolle versteht, erkennt schnell: Diese Grundlagen sind in nahezu jedem System operativ relevant.

Nachfolgend einige exemplarische Szenarien, die Layer 3 und 4 in Aktion zeigen:

Beispiel 1: Standortvernetzung per VPN

Ein mittelständisches Unternehmen mit Hauptsitz in Dortmund betreibt eine Außenstelle in München. Die Anbindung erfolgt über eine VPN-Verbindung auf Layer 3-Basis. Hier greifen:

• Private Adressräume nach RFC 1918 (z.B. 10.0.0.0/16)
• Routenverteilung per BGP oder statischem Routing
• NAT-Traversal, wenn an einem der Standorte IPv4-NAT eingesetzt wird
• Transportverschlüsselung via IPSec (Layer 3) oder SSL-VPN (Layer 4)

Layer 3 ermöglicht die Adressierung und Wegewahl, Layer 4 sorgt für stabile, paketorientierte Kommunikation trotz schwankender Netzqualität.

Beispiel 2: Heimnetz mit Internetzugang

Ein privates Heimnetz nutzt typischerweise:

• IPv4 mit NAT/PAT durch den Internetrouter
• Dynamische Adressvergabe via DHCP (Layer 7, aber operativ abhängig von Layer 3)
• DNS-Auflösung → UDP/TCP-Kommunikation auf Layer 4
• MTU-bezogene Paketgrößen bei DSL-Verbindungen (z.B. 1492 Byte wegen PPPoE)

Zudem arbeitet das Heimnetz mit IGMP für Multicast-Streams (z.B. IPTV) – eine Layer-3-Komponente, die meist unbemerkt aktiv ist.

Beispiel 3: Webanfrage an eine Cloud-Anwendung

Ein Client ruft über HTTPS eine Applikation bei einem Cloud-Provider auf:

1. DNS-Auflösung → TCP-Verbindung zu 198.51.100.42:443
2. TCP-Handshake auf Layer 4 → Drei-Wege-Verbindung
3. TLS-Aushandlung & Verschlüsselung
4. HTTP/2 oder HTTP/3 Datenübertragung
5. IP-Weiterleitung durch mehrere Router (Layer 3)
6. Firewall-Prüfung & NAT-Regeln am Zielsystem

Layer 3 sorgt für Erreichbarkeit. Layer 4 sorgt für Zuverlässigkeit und Fehlersicherheit. Darüber bauen alle weiteren Dienste auf.

Beispiel 4: Kubernetes und Container-Orchestrierung

Moderne Microservice-Architekturen, etwa auf Basis von Kubernetes, setzen vollständig auf Netzwerkvirtualisierung:

• Pod-interne Kommunikation über virtuelle Layer-3-Netze
• Service Discovery per DNS
• Load-Balancer auf Layer 4 (TCP-Level) oder Layer 7 (HTTP-Level)
• IP-Overlays (z. B. Flannel, Calico) zur Isolation und Adressvergabe
• NAT in Clustern für ausgehenden Internetverkehr (z.B. durch eBPF oder iptables)

Hier trifft klassische Netzwerktechnik auf moderne Automatisierung – und Layer 3/4 sind entscheidend für Skalierung und Sicherheit.

Fazit: Konzepte, die im Alltag wirken

Layer 3 und 4 erscheinen oft abstrakt – doch sie bestimmen täglich, ob und wie Systeme miteinander sprechen:

• Routen entscheiden über Erreichbarkeit
• IP-Adressierung regelt Isolation und Kommunikation
• Transportprotokolle sorgen für Integrität und Performance

Wer diese Mechanismen versteht, kann Netzwerke nicht nur administrieren – sondern gezielt gestalten, analysieren und optimieren.

Fazit und Ausblick

Kommunikation ist mehr als das bloße Versenden von Daten – sie ist ein gezieltes Navigieren durch Adressräume, Protokolle und Transportkanäle. Die Schichten 3 und 4 des OSI-Modells zeigen eindrucksvoll, dass hinter jeder erfolgreichen Verbindung eine Vielzahl koordinierter Entscheidungen steckt:

• Layer 3 (Vermittlungsschicht) sorgt dafür, dass Pakete ihren Weg durch lokale Netze, Providerinfrastrukturen und weltweite Internetpfade finden – über Adressierung, Routing und Fragmentierung.
• Layer 4 (Transportschicht) stellt sicher, dass die Daten nicht nur ankommen, sondern vollständig, korrekt und im richtigen Kontext verarbeitet werden – mit Mechanismen wie Sequenzierung, Flusskontrolle und Fehlererkennung.

Dabei wurde deutlich: Technische Konzepte wie CIDR, NAT, Multicast oder MTU sind keine akademischen Spielereien – sie sind betriebliche Realität in jeder Umgebung, von der FritzBox im Wohnzimmer bis zum BGP-Router am Internet-Backbone.

Wir haben gesehen, wie durchlässig die Grenze zwischen Theorie und Praxis ist:

• Wie historische Designentscheidungen (z.B. Adressklassen, NAT) noch heute Systemarchitekturen prägen.
• Wie vergessene Protokolle wie IPv5 ein Licht auf den Innovationsprozess werfen.
• Und wie IPv6 nicht nur ein längerer Adressraum, sondern eine Neuausrichtung des Internetdenkens ist.

Der Weg geht weiter: Schicht 5 bis 7

Mit Layer 3 und 4 endet die sogenannte transportnahe Kommunikation – von hier an bewegen wir uns in den Bereich der Sitzungs-, Darstellungs- und Anwendungsschicht:

• Wie wird aus einem TCP-Port eine sichere HTTPS-Verbindung?
• Was passiert beim Session-Management, bei Authentifizierung, Verschlüsselung und Datenserialisierung?
• Und wie lassen sich diese oberen Schichten sicher, nachvollziehbar und standardkonform betreiben?

Genau diesen Fragen werde ich mich im kommenden Beitrag widmen:

Sicherheit und Management – Die Schichten 5 bis 7 im OSI-Modell

Mit Fokus auf TLS, DNS, Firewall-Architekturen, Proxy-Mechanismen, Zertifikatsverwaltung und Trust Models beleuchte ich dort, was in der alltäglichen IT oft nur als Konfigurationsoberfläche wahrgenommen wird – aber strategisch entscheidend für Zuverlässigkeit, Vertrauen und Cyber-Resilienz ist.

Vielen Dank für Ihr Interesse

Wenn Sie bis hierher gelesen haben, dann gehören Sie zu den Menschen, die nicht nur wissen, dass es geht, sondern verstehen wollen, warum es geht – und wie.

Ich freue mich über Rückmeldungen, Anregungen oder Erfahrungen aus Ihrer eigenen Praxis – entweder hier im Blog oder über Facebook, LinkedIn oder XING.

Teil 1 verpasst?
Lesen Sie hier den Einstieg in die Reihe – mit Fokus auf Bits, Frames und physikalischer Kommunikation:
Warum jedes Bit seinen Weg braucht – Der Weg zur intelligenten Kommunikation

_{Aktualisiert am 14. Juli 2025: Der Beitrag wurde um einen Nachtrag zur aktuellen Situation rund um AFRINIC ergänzt. Die neuen Informationen beziehen sich auf Entwicklungen zwischen dem 3. und 12. Juli 2025 und wurden durch Quellen von ICANN, Heise Online und btw.media belegt.}