Welche IPv4-Adressbereiche sind reserviert oder privat – und wie berechne ich Subnetze und Host-Anzahlen?

IPv4-Reservierungen und Sonderbereiche: private Netze (RFC 1918), Loopback, Link-Local/APIPA, Multicast, Broadcast und Carrier-Grade-NAT im Detail

IPv4 kennt neben öffentlich routbaren Adressen eine Reihe fest definierter Sonderbereiche. Diese Netze erfüllen klar abgegrenzte Aufgaben: interne Adressierung ohne Internet-Routing, lokale Autokonfiguration ohne DHCP, Test- und Loopback-Verkehr, Gruppenzustellung via Multicast oder die Provider-seitige Adresskonsolidierung durch Carrier-Grade-NAT (CGN). Für Planung, Troubleshooting und Sicherheitsregeln ist entscheidend, welche Bereiche niemals im öffentlichen Internet erscheinen sollten, welche nur innerhalb eines Layer-2-Segments funktionieren und welche Adressen in Routing-Tabellen bewusst gefiltert werden.

Private IPv4-Netze nach RFC 1918

Die RFC-1918-Bereiche sind für private Netze reserviert und werden im öffentlichen Internet nicht geroutet. Sie eignen sich für Heimnetze, Unternehmens-LANs, Labore, Management-Netze und viele Overlay-/Tenant-Designs. Da dieselben Bereiche an vielen Orten parallel verwendet werden, entstehen bei Standortkopplungen und Migrationsprojekten häufig Konflikte (Overlapping Subnets), die eine saubere Adressplanung oder NAT-/Translation-Konzepte erzwingen. In Firewalls und Edge-Routern sollten RFC-1918-Quellen und -Ziele auf externen Schnittstellen grundsätzlich verworfen werden (Anti-Spoofing).

Innerhalb dieser Netze gelten die üblichen Regeln der Unicast-Adressierung. In klassischen Subnetzen sind Netzwerk- und Broadcast-Adresse nicht als Hostadresse nutzbar; bei Punkt-zu-Punkt-Verbindungen werden häufig /31-Netze eingesetzt, bei denen beide Adressen nutzbar sind (RFC 3021). Router-Default-Netze wie 192.168.0.0/24 oder 192.168.1.0/24 sind funktional, erhöhen aber in VPN- oder Remote-Access-Szenarien die Wahrscheinlichkeit für Überschneidungen.

Loopback und „this host on this network“

Der Loopback-Bereich 127.0.0.0/8 dient ausschließlich der lokalen Kommunikation innerhalb eines Hosts. Konventionell wird 127.0.0.1 als localhost verwendet, technisch sind jedoch alle Adressen aus 127.0.0.0/8 Loopback. Pakete zu diesen Zielen dürfen den Host nicht verlassen; ein Auftauchen von 127.0.0.0/8 auf einem physischen Interface weist auf Fehlkonfiguration oder Spoofing hin.

Für die Bootstrapping-Phase existiert 0.0.0.0 als unspezifizierte Adresse (z. B. als Quelle vor Adresskonfiguration oder als Default-Route-Ziel 0.0.0.0/0). Das gesamte Netz 0.0.0.0/8 ist historisch als „this network“ reserviert und wird nicht normal geroutet. In Filterregeln sollte eingehender Verkehr mit Quellen aus 0.0.0.0/8 verworfen werden.

Link-Local/APIPA (169.254.0.0/16)

Link-Local-Adressen aus 169.254.0.0/16 werden für automatische Adressierung ohne DHCP oder statische Konfiguration verwendet (APIPA). Der Bereich ist nicht routbar; Kommunikation funktioniert nur innerhalb desselben Layer-2-Segments. Betriebssysteme wählen eine Adresse typischerweise zufällig aus 169.254.1.0–169.254.254.255 und prüfen mittels ARP auf Kollisionen, bevor sie die Adresse aktiv nutzen.

In Unternehmensnetzen ist das Auftreten von 169.254.0.0/16 auf Clients häufig ein Symptom: DHCP nicht erreichbar, falsches VLAN, Port-Security, fehlerhafte Relay-Konfiguration oder gebrochene Trunks. In Cloud- und Virtualisierungsumgebungen kann Link-Local hingegen gezielt eingesetzt werden, etwa für Nachbarschaftsdienste oder als isolierte Management-Pfade innerhalb eines Hosts; dabei bleibt die Nicht-Routbarkeit ein zentrales Sicherheitsmerkmal.

Multicast (224.0.0.0/4) und Broadcast

Multicast-Adressen (224.0.0.0–239.255.255.255) adressieren Empfängergruppen. 224.0.0.0/24 ist für „link-local“ Multicast reserviert und wird nicht geroutet (z. B. Routing-Protokolle und Discovery-Mechanismen). Administrativ begrenzter Multicast liegt in 239.0.0.0/8 und eignet sich für organisationsinterne Anwendungen, weil er konzeptionell dem privaten Adressraum ähnelt. Multicast benötigt passende Netzwerkunterstützung (IGMP/MLD-Snooping, PIM oder kontrollierte Flooding-Domänen), sonst drohen unnötige Last und schwer nachvollziehbare Störungen.

Broadcast existiert in IPv4 in zwei Formen: der „limited broadcast“ 255.255.255.255 (nur im lokalen Netz) und der gerichtete Broadcast pro Subnetz (host bits alle 1, z. B. 192.168.1.255 bei /24). Viele Router blockieren gerichtete Broadcasts standardmäßig (Smurf-Schutz). DHCP nutzt Broadcasts in frühen Phasen (z. B. DHCPDISCOVER), was die korrekte L2-/Relay-Konfiguration besonders relevant macht.

• Link-local Multicast: 224.0.0.0/24 bleibt auf dem lokalen Segment; typische Protokolle nutzen feste Gruppenadressen innerhalb dieses Bereichs.
• Administrativ begrenzter Multicast: 239.0.0.0/8 für organisationsinterne Streams, mit klarer Abgrenzung zu globalem Multicast.
• Limited Broadcast: 255.255.255.255 wird nicht geroutet und eignet sich nur für lokale Discovery-/Bootstrap-Mechanismen.
• Gerichteter Broadcast: pro Subnetz die höchste Adresse (z. B. 10.20.30.255 bei 10.20.30.0/24); häufig in ACLs/Router-Defaults gesperrt.

Carrier-Grade-NAT (100.64.0.0/10) und Abgrenzung zu RFC 1918

Der Adressblock 100.64.0.0/10 ist für Shared Address Space bei Carrier-Grade-NAT reserviert (RFC 6598). Provider setzen ihn zwischen Customer-Premises-Equipment und Provider-Netz ein, um viele Anschlüsse hinter wenigen öffentlichen IPv4-Adressen zu bündeln. Der Bereich ist nicht für das öffentliche Internet gedacht, aber auch kein RFC-1918-Ersatz: Bei Standortvernetzung, IP-Whitelisting oder Telemetrie kann 100.64.0.0/10 unerwartet auftauchen und muss in Diagnose- und Filterkonzepten berücksichtigt werden.

In der Praxis wird 100.64.0.0/10 häufig in Traceroutes oder als WAN-Adresse am Router sichtbar. Eingehende Verbindungen aus dem Internet funktionieren bei CGN ohne zusätzliche Mechanismen (Port-Control-Protokolle oder statische Mappings) in der Regel nicht, weil die öffentliche Adresse geteilt wird und der Provider die Portzuordnung kontrolliert. Für Security-Logging ist relevant, dass eine öffentliche Quell-IP bei CGN ohne Port-Informationen keinen eindeutigen Anschluss identifiziert; Systeme sollten daher Quellport und Zeitstempel mit hoher Genauigkeit erfassen.

Subnetting als Rechenwerkzeug: CIDR-Notation, Subnetzmasken, Netz-/Broadcast-Adressen und Host-Anzahlen pro Präfix (inklusive Tabellen und Randfälle)

CIDR und Subnetzmasken: zwei Schreibweisen, ein Präfix

Subnetting basiert auf der Trennung einer IPv4-Adresse in Netzanteil und Hostanteil. In CIDR-Notation beschreibt das Präfix /n die Anzahl der gesetzten Bits in der Subnetzmaske (Netzbits). Eine Adresse mit /24 nutzt 24 Bits für das Netz und 8 Bits für Hosts; die zugehörige Subnetzmaske lautet 255.255.255.0. Die klassische Punktnotation der Maske ist damit lediglich eine alternative Darstellung desselben Präfixes.

Für die Praxis ist wichtig: Präfixe teilen den Adressraum in gleich große Blöcke. Die Blockgröße ergibt sich aus den verbleibenden Hostbits (32 - n). Je größer das Präfix (je näher an /32), desto kleiner das Subnetz. CIDR erlaubt dabei beliebige Präfixlängen; an Klassengrenzen (A/B/C) ist nichts mehr gebunden.

Netzadresse, Broadcast-Adresse und Hostbereich korrekt bestimmen

Die Netzadresse entsteht, indem im Hostanteil alle Bits auf 0 gesetzt werden. Die Broadcast-Adresse setzt im Hostanteil alle Bits auf 1. Dazwischen liegt der Hostbereich. Beispiel: 192.168.10.34/27. Ein /27-Netz hat eine Blockgröße von 32 Adressen; im letzten Oktett beginnen die Netze bei 0, 32, 64, 96, 128, 160, 192, 224. Die Adresse .34 liegt damit im Block 32–63: Netzadresse 192.168.10.32, Broadcast 192.168.10.63, nutzbare Hosts .33–.62.

Ein robuster Rechenweg für beliebige Präfixe nutzt die Maske als Bitoperation: Netz = IP AND Maske; Broadcast = Netz OR (NOT Maske). In Umgebungen mit wenig Fehlertoleranz (Routing, Firewall-Regeln, IPAM) ist diese Denke präziser als das Arbeiten „nach Gefühl“ mit Oktettgrenzen.

• Blockgröße im relevanten Oktett: Block = 256 - Maskenwert (z. B. bei /26 ist die Maske 255.255.255.192, Blockgröße 256-192=64).
• Netzstart finden (Oktettmethode): Host-Oktett durch Blockgröße teilen, abrunden, mit Blockgröße multiplizieren (z. B. 198.51.100.170/28 → Blockgröße 16 → Netzstart 160).
• Broadcast ableiten: Broadcast = Netzstart + Blockgröße - 1 (z. B. Netzstart 160 bei /28 → Broadcast 175).
• Hostanzahl (typisch): Hosts = 2^(32-n) - 2 für klassische IPv4-Subnetze, weil Netz- und Broadcast-Adresse nicht an Hosts vergeben werden.

Randfälle: /31, /32 sowie Broadcast-Fallstricke

Nicht jedes Präfix folgt der üblichen „minus zwei“-Logik. Für Punkt-zu-Punkt-Verbindungen erlaubt RFC 3021 den Einsatz von /31: Beide Adressen sind nutzbar, es gibt keine separate Netz- oder Broadcast-Adresse im klassischen Sinn. Das reduziert Adressverschwendung auf Links, die ohnehin nur zwei Endpunkte benötigen. Ob ein /31 funktioniert, hängt von der Geräteunterstützung ab; moderne Router, Switches (Layer 3) und viele Betriebssystem-Stacks beherrschen das zuverlässig.

/32 bezeichnet eine Host-Route: genau eine Adresse, typischerweise für Loopbacks, Management-Endpoints oder als Ziel in Routingtabellen. In Firewalls und ACLs ist /32 die präziseste Form einer Einzeladresse. Umgekehrt sind „alle Hosts“ in einem Subnetz keine einzelne Adresse, sondern eine Menge; dafür werden Netzbereiche in CIDR oder Adressobjekte verwendet.

Broadcast ist mehrdeutig, wenn Begriffe unsauber verwendet werden. Directed Broadcast ist die Broadcast-Adresse eines konkreten Subnetzes (z. B. 10.1.2.255 in einem 10.1.2.0/24). Limited Broadcast ist 255.255.255.255 und bleibt im lokalen Layer-2-Segment; Router leiten sie nicht weiter. Viele Router sperren Directed Broadcasts standardmäßig, um Smurf-artige Verstärkungsangriffe zu verhindern. Subnetting-Berechnungen sollten deshalb stets zwischen „Broadcast im Subnetz“ und „Broadcast im Segment“ unterscheiden.

Typische Fehlkonfigurationen beim Subnetting (und wie sie entstehen)

Fehlerbilder wirken oft wie „sporadische“ Netzwerkprobleme, haben aber deterministische Ursachen in Maske, Gateway oder Adressplanung. Besonders häufig sind inkonsistente Präfixe innerhalb desselben Layer-2-Segments: Ein Client mit /24 und ein anderer mit /25 sehen unterschiedliche On-Link-Ziele, was ARP-Verhalten, Default-Gateway-Nutzung und damit die Erreichbarkeit verfälscht. Auch falsch gesetzte DHCP-Optionen (Maske, Router, Routen) können ein ansonsten korrektes Subnetz unbrauchbar machen.

• Maske passt nicht zum Gateway: Client im 192.168.1.0/24, Gateway aber in 192.168.0.0/24 → Gateway liegt aus Sicht des Clients off-link; oft endet das in fehlender Standardroute oder ARP ins Leere.
• Überlappende Subnetze: Zwei Routen wie 10.0.0.0/16 und 10.0.128.0/17 ohne klare Absicht → Longest-Prefix-Match greift, aber Policy-Routing, NAT oder Firewall-Objekte können dadurch unerwartete Pfade erzwingen.
• Netz-/Broadcast versehentlich vergeben: Hostadresse entspricht Netzadresse oder Broadcast-Adresse (z. B. .0 oder .255 bei /24) → manche Stacks akzeptieren es, andere nicht; Diagnose wird dadurch unnötig kompliziert.
• /31 auf nicht unterstütztem Link: Ein Endpunkt erwartet klassisches Broadcast-Verhalten → Link bleibt instabil oder Nachbarerkennung scheitert; Abhilfe schafft /30 oder ein Firmware-/OS-Update, sofern möglich.

Praxis und Fehlersuche: typische Heimrouter-Standardnetze, Unternehmens- und Cloud-Szenarien, NAT-Randbedingungen sowie häufige Fehlkonfigurationen und deren Symptome

Heimrouter-Standardnetze und Kollisionen im Alltag

In Heim- und Kleinstumgebungen dominieren wenige IPv4-Standardnetze, weil Router- und Mesh-Hersteller ab Werk häufig identische RFC-1918-Defaults setzen. Diese Bequemlichkeit wird in der Praxis zur Fehlerquelle, sobald mehrere private Netze über VPN, Site-to-Site-Tunnel oder „Kaskadierung“ (z. B. Provider-Router vor eigenem Router) miteinander verbunden werden. Die typische Folge sind überlappende Adressräume, die Routingentscheidungen unmöglich machen: Pakete werden in das „falsche“ lokale Segment geschickt, statt über den Tunnel zu laufen, oder Rückwege fehlen durch asymmetrisches Routing.

Bei doppeltem NAT (Double NAT) bleibt lokaler Internetzugang oft scheinbar stabil, während eingehende Verbindungen, Portweiterleitungen, VoIP, bestimmte Spiele oder Peer-to-Peer-Protokolle ausfallen. Zusätzlich erschweren unterschiedliche DHCP-Server in Reihe die Fehlersuche, wenn Endgeräte abwechselnd Leases aus verschiedenen Bereichen beziehen oder DNS-Resolver inkonsistent sind.

Unternehmensszenarien: Segmentierung, Routing und typische Stolpersteine

In Unternehmensnetzen entstehen Fehlerbilder seltener durch die Wahl von 10/8 oder 172.16/12 an sich, sondern durch inkonsistente Segmentierung und unerwartete Summarization. Häufig werden VLANs nach Organisationslogik nummeriert, während die IP-Planung nach Verfügbarkeit wächst. Werden später Routen zusammengefasst (z. B. mehrere /24 zu einem /20), können unabsichtlich Bereiche „mitgeroutet“ werden, die lokal gar nicht existieren, oder es entstehen Blackholes, wenn Teilnetze in anderen Standorten doch belegt sind.

DNS und DHCP bilden dabei die zentralen Diagnosepunkte: Eine scheinbar „nur“ langsame Anmeldung oder sporadische Applikationsfehler sind oft DNS-Symptome, ausgelöst durch falsche Suchdomänen, nicht erreichbare Resolver oder Split-Horizon-Konflikte. Bei DHCP ist besonders relevant, ob Relay (IP Helper) korrekt gesetzt ist und ob mehrere DHCP-Server unkoordiniert im selben Broadcast-Domain antworten.

• ARP-/IP-Konflikt: Mehrere Geräte nutzen dieselbe Adresse; sichtbar über arp -a (Windows) oder ip neigh (Linux) mit wechselnden MAC-Zuordnungen.
• DHCP-Fehlkonfiguration: Falsches Standardgateway oder DNS verteilt; prüfen mit ipconfig /all (Windows) bzw. nmcli dev show oder resolvectl status (Linux, je nach Distribution).
• Routen-/Summarization-Problem: Ziele in Teilbereichen „verschwinden“; verifizieren mit tracert 10.20.30.40 oder traceroute 10.20.30.40 sowie Routingtabelle via route print (Windows) bzw. ip route (Linux).
• MTU/Fragmentierung über Tunnel: TLS/SMB/VoIP bricht ab, Ping geht nur mit kleinen Paketen; testen mit ping -f -l 1472 8.8.8.8 (Windows) oder ping -M do -s 1472 8.8.8.8 (Linux) und MTU/MSS-Clamping am Edge prüfen.
• VLAN-Leak / falsche Tagging-Policies: Geräte landen im falschen Netz, erhalten „falsche“ DHCP-Leases; Switch-Port-Konfiguration und Trunks kontrollieren, Client-Seite über ipconfig bzw. ip addr plausibilisieren.

Cloud und Hybrid: überlappende RFC-1918-Bereiche und Routing-Domänen

In Cloud-VPC/VNet-Designs treten Kollisionen besonders häufig auf, weil On-Premises historisch gewachsene RFC-1918-Pläne existieren und Cloud-Quickstarts gerne in „bequemen“ 10.0.0.0/16 starten. Überlappende CIDRs verhindern dann Transit-Gateways, Peering oder sauberes Route-Propagation. Selbst wenn ein Cloud-Anbieter technisch ein Overlap zulässt, bleibt die Kommunikation ohne NAT oder Proxying in der Regel nicht eindeutig routbar.

Hinzu kommen in Hybrid-Szenarien mehrere Routing-Domänen: lokale VRFs, SD-WAN-Overlays, Cloud-Router und Kubernetes-CNI-Netze. Besonders Kubernetes kann kollidieren, wenn Pod- oder Service-CIDRs (häufig ebenfalls RFC-1918) unbeabsichtigt in vorhandene Unternehmensbereiche fallen. Die Symptome ähneln klassischen Overlaps: einzelne Subnetze sind erreichbar, andere nicht; Verbindungen funktionieren nur in eine Richtung; Name Resolution zeigt auf Ziele, die über den falschen Pfad geroutet werden.

• Adressplanung in Hybrid-Umgebungen: Cloud-CIDRs so wählen, dass sie garantiert nicht mit On-Prem, Partnernetzen und typischen CNI-CIDRs kollidieren; konservativ sind dedizierte 172.16.0.0/12- oder 10/8-Teilblöcke mit zentraler Vergabe und dokumentierter Reservierung.
• Diagnosepfad bei Overlap-Verdacht: Lokale Zielroute prüfen (ip route get 10.0.1.10), danach NAT/Firewall-Logs und Cloud-Route-Tables; bei „kurzen“ Traceroutes endet der Weg oft am ersten Router, der das Ziel als lokal betrachtet.
• Kubernetes-Kollisionen: Pod-/Service-Netze gegen Unternehmens-CIDRs abgleichen; bei NodePort/Ingress-Problemen zusätzlich externe Load-Balancer und Security-Groups/NSGs auf Rückwege prüfen.

NAT-Randbedingungen: CGNAT, Hairpinning, Portweiterleitung und Protokollbesonderheiten

NAT löst Adressknappheit, verschiebt aber Zustandslogik in den Übergangspunkt und macht Erreichbarkeit abhängig von Portabbildungen, Timeouts und Protokollverhalten. Bei Carrier-Grade NAT fehlt typischerweise eine öffentlich routbare IPv4-Adresse am Anschluss; eingehende Verbindungen sind dann ohne zusätzliche Mechanismen (z. B. VPN-Overlay, Reverse-Proxy, Portmapper des Providers) nicht zuverlässig möglich. Erkennbar ist CGNAT häufig daran, dass die WAN-Adresse des Routers aus 100.64.0.0/10 stammt und sich von der extern sichtbaren Adresse unterscheidet.

In lokalen Netzen beeinflusst NAT zudem Hairpinning (NAT-Loopback): Der Zugriff auf einen eigenen Dienst über die öffentliche Adresse funktioniert nur, wenn der Router Hairpin-NAT implementiert oder internes DNS den Hostnamen auf die interne Adresse auflöst. Fehlt beides, sind Dienste „von innen“ nicht erreichbar, von außen jedoch schon. Weitere Klassiker sind zu knappe NAT-State-Timeouts (insbesondere bei UDP), fehlerhafte ALG-Funktionen sowie fragmentierte Pakete durch unpassende MTU in Kombination mit Tunneln.

• CGNAT-Indiz am WAN-Interface: WAN-Adresse im Bereich 100.64.0.0/10; zusätzlich Abgleich der externen IPv4 über https://ifconfig.me oder https://api.ipify.org (falls Zugriff erlaubt) zeigt eine abweichende Adresse.
• Hairpinning-Problem: Interner Zugriff auf FQDN/öffentliche IP scheitert, externer Zugriff funktioniert; Abhilfe über Split-DNS (intern A-Record auf private IP) oder Routerfunktion „NAT-Loopback“.
• Portweiterleitung vs. doppeltes NAT: Weiterleitung im „inneren“ Router reicht nicht, wenn davor ein weiteres NAT existiert; notwendig sind entweder Bridge/Exposed-Host am äußeren Gerät oder End-to-End-VPN.
• Protokollabhängige Effekte: UDP-basierte Anwendungen reagieren empfindlich auf NAT-Timeouts; bei sporadischen Abbrüchen helfen Capture/Logs sowie gezielte Tests mit iperf3 (TCP/UDP) zur Reproduktion unter Last.

Häufige Fehlkonfigurationen und typische Symptome (schnelle Zuordnung)

APIPA-Adressen aus 169.254.0.0/16 (Windows häufig 169.254.x.x) bleiben ein verlässlicher Hinweis auf fehlgeschlagenen DHCP-Bezug oder Link-Probleme, sind aber nicht automatisch ein physischer Defekt: VLAN-Fehlzuordnung, 802.1X-Fehlschlag, falscher SSID-Modus oder ein blockierter DHCP-Relay erzeugen identische Ergebnisse. Umgekehrt kann eine „korrekt“ wirkende RFC-1918-Adresse trügerisch sein, wenn Gateway und DNS aus einem falschen Segment stammen. Eine saubere Diagnose trennt deshalb konsequent Layer-2 (Link/VLAN), Layer-3 (IP/Route) und Namensauflösung.