Zusammenfassung

  • Die drei Adressblöcke aus RFC 1918 dürfen ohne Abstimmung mit IANA oder einer Internet Registry mehrfach verwendet werden. Eindeutigkeit besteht nur innerhalb eines Unternehmens oder einer koordinierten Gruppe.
  • Bei einer Fusion können deshalb zwei zuvor korrekte lokale Zuweisungen im gemeinsamen Netz mehrdeutig werden. RFC 1918 nennt die notwendige Umnummerierung ausdrücklich als Nachteil des Modells.
  • Routing, Namensauflösung, Übersetzung, Authentisierung und Anwendungserfolg belegen unterschiedliche Sachverhalte. Erreichbarkeit allein stellt die verlorene Endpunktidentität nicht wieder her.

Der Zuständigkeitsraum war die zweite Spalte

Solange Unternehmen A und B getrennt arbeiteten, genügte in jeder Dokumentation eine Zeile wie 10.14.5.9 – Server. Der Name des Unternehmens stand nicht im Adressfeld, weil Ordner, Kabel, Router und Administratoren den Kontext lieferten. Die lokale Tabelle hatte nur einen passenden Datensatz.

Mit der ersten Kopplung wird aus zwei Tabellen eine Entscheidungsfläche. Ein Paket enthält weiterhin nur die Adresse. Es sagt nicht, aus welchem alten Plan seine Bedeutung stammt. Wer beide Netze unverändert in eine Routingdomäne übernimmt, entfernt die Spalte, die bisher für Eindeutigkeit sorgte.

Die bekannte Lesart von RFC 1918 beginnt bei drei Zahlenbereichen. Die wichtigere Lesart beginnt bei der Frage, wo Eindeutigkeit gelten muss. Das Dokument verlagerte Koordination vom globalen Vorfeld in einen möglichen späteren Integrationszeitpunkt. Lokale Freiheit und zukünftige Bereinigung sind zwei Seiten derselben Konstruktion.

Der Einwand war Teil der Entstehungsgeschichte

RFC 1597 schlug im März 1994 private Adressierung für Geräte vor, die keine unmittelbare Netzschichtverbindung zu anderen Unternehmen oder zum gesamten Internet benötigten. Interne Terminals, Anzeigen und Routerinterfaces konnten TCP/IP nutzen, ohne für jede Maschine eine weltweit eindeutige Adresse zu verbrauchen.

RFC 1627 widersprach im Juli. Die Autoren hielten eine globale Adresssemantik für ein architektonisches Gut und bezweifelten, dass sich der zukünftige Kommunikationsbedarf vorhersagen lasse. Unternehmen kooperieren, fusionieren oder öffnen vormals interne Dienste. Bekannte Server, Softwarelizenzen und Konfigurationen können eine Adresse verfestigen. Der Text nennt eine Umnummerierung bei Apple; Anzahl, Kosten und vollständiges Ergebnis werden durch das vorliegende Quellenpaket nicht unabhängig bestätigt. Belegt ist damit die damalige Position, nicht eine allgemeine Schadensstatistik.

Im Februar 1996 ersetzte RFC 1918 als BCP 5 sowohl RFC 1597 als auch die Kritik. Eliot Lear war Mitautor beider später zusammengeführten Seiten der Debatte: RFC 1627 und RFC 1918. Der BCP erklärte das Kollisionsargument nicht für gegenstandslos. Er übernahm es in die Nachteile und hielt dennoch an wiederverwendbarem Raum fest.

Damit wurde ein Risiko nicht übersehen, sondern bewertet. Die Praxis entschied, dass der Nutzen lokaler Flexibilität die mögliche spätere Umnummerierung rechtfertigte.

Drei Blöcke, keine weltweite Rangfolge

RFC 1918 benennt 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16. Ein Unternehmen darf daraus Adressen wählen, ohne IANA oder eine Registry zu koordinieren. Dasselbe dürfen andere Unternehmen. Ein Wert ist nur im jeweiligen Unternehmen oder in einer Gruppe eindeutig, die ihre Verwendung ausdrücklich abstimmt.

Die heutige IANA-Liste führt alle drei Bereiche als Private-Use und nicht global erreichbar. Daraus folgt kein Vorrang für den frühesten Nutzer. Die Frage, wem ein privates /24 „wirklich gehört“, verfehlt die technische Vereinbarung: Mehrfachnutzung ist ihr Zweck.

Damit sie funktioniert, müssen mehrere Grenzen zusammenfallen. Private Routen sollen nicht über Verbindungen zwischen Unternehmen verbreitet werden. Pakete mit privaten Quell- oder Zieladressen sollen diese Grenzen nicht überschreiten. Indirekte Verweise, insbesondere DNS-Einträge, sollen im Unternehmen bleiben. Sobald ein Name ein größeres Publikum erreicht als der Adressplan unterscheiden kann, geht der notwendige Kontext verloren.

Privat bedeutet auch nicht authentisiert. RFC 1918 behandelt Sicherheitsfragen ausdrücklich nicht. Filter und Gateways können das Expositionsprofil beeinflussen; die Adresse selbst weist weder einen Benutzer noch einen Dienst nach.

Die Fusionsklausel verteilt keine Schuld

Der Text beschreibt, dass unkoordiniert betriebene private Internets beim Zusammenschluss doppelte Adressen enthalten können und betroffene Hosts dann umnummeriert werden müssen. Auch eine spätere IP-Verbindung zwischen Organisationen birgt dieses Risiko. Zufällige Wahl interner Teilblöcke soll die Wahrscheinlichkeit mindern, ist aber weder Kollisionsfreiheit noch Koordinationsverfahren.

Eine Integrationsentscheidung darf deshalb nicht auf dem Alter der beiden Adresspläne beruhen. Zu klären sind Änderbarkeit, Abhängigkeiten, Dienstkritikalität, operative Zuständigkeit, Nachweisbarkeit und Ausfallkosten. Ein Segment kann umnummeriert, über einen Proxy erreicht, durch Übersetzung abgeschirmt oder weiterhin getrennt werden. Unterschiedliche Dienste dürfen unterschiedliche Antworten erhalten.

RFC 1918 nennt beim Wechsel eines Hosts zwischen privatem und öffentlichem Status nicht nur die IP-Adresse, sondern auch DNS und Konfigurationsdateien auf anderen Hosts. DHCP kann mechanische Arbeit senken. Es bestimmt nicht, welche Identität ein Geschäft schützen muss und wer die Wiederherstellung bestätigt.

Das Address Realm benennt den fehlenden Kontext

RFC 2663 definierte 1999 ein Address Realm als Netzwerkdomäne, in der Adressen eindeutig vergeben sind und Routing die zugehörigen Einheiten findet. Damit wird die unsichtbare zweite Spalte explizit: Adresse plus Realm.

Traditionelles NAT verbindet einen privaten und einen externen Bereich durch Umschreiben, setzt jedoch nicht überlappende Räume voraus. Ist derselbe Wert auf beiden Seiten belegt, beschreibt RFC 2663 Twice NAT, bei dem Quell- und Zieladresse geändert werden können. Für jede Seite entsteht eine passende Darstellung der anderen. Die ursprüngliche Privatadresse wird dadurch nicht global eindeutig.

RFC 3022 erläutert Basic NAT als Abbildung von Adressgruppen und NAPT als Abbildung einschließlich Transportkennungen. Hin- und Rückverkehr müssen konsistenten Übersetzungszustand passieren. Wechselt ein Fluss auf ein Gerät ohne diesen Zustand, kann er abbrechen. Das Verfahren verbirgt bestimmte Änderungen vor Hosts, nimmt der IP-Adresse aber Bedeutung von Ende zu Ende und verlagert Wissen ins Netz.

Der Übersetzungszustand wird damit zum Beleg. Ohne ursprüngliches Realm, Zeitpunkt, Protokoll, innere und äußere Darstellung sowie zuständiges Gerät lässt sich ein späterer Logeintrag nicht eindeutig einem Host zuordnen.

Ein erfolgreicher Test kann zum falschen Host führen

RFC 5684 erschien 2010 als Independent Submission, nicht als IETF-Standardspezifikation. Er untersucht überlappende private Räume hinter verschachtelten NATs und bei Fernzugriffs-VPNs. Ein Beispiel zeigt, wie eine für einen übergeordneten DNS-Resolver angekündigte Adresse lokal von einem anderen Host belegt ist und die Anfrage deshalb am falschen Ort endet. Ähnliches kann zwischen einem lokalen und einem erwarteten Unternehmensdienst geschehen.

Der Text nennt dies mistaken end host identity. Der Fehler ist gefährlich, weil nicht zwingend ein Timeout entsteht. Irgendein Dienst kann antworten. Für seine konkreten Szenarien empfiehlt das Dokument nicht überlappende oder globale Adressen für bestimmte kritische Dienste sowie Ende-zu-Ende-Authentisierung anstelle bloßen Vertrauens in Quell-IP-Adressen.

RFC 5684 liefert keine Häufigkeit für Unternehmensfusionen. Seine Rolle ist begrenzt, aber wichtig: Es zeigt einen Mechanismus, bei dem Transporterfolg und richtige Identität auseinanderfallen. Konfiguration belegt eine lokale Zuweisung, Routing einen Pfad, die Abbildung eine Übersetzung, ein Berechtigungsnachweis den Peer und die Anwendung das Ergebnis. Diese Nachweise sind nicht austauschbar.

Shared Address Space folgt einem anderen Geltungsbereich

RFC 6598 reservierte 2012 100.64.0.0/10 als Shared Address Space zwischen Carrier-Grade-NAT eines Providers und Kundeneinrichtungen. Er grenzt diesen Raum ausdrücklich vom privaten Unternehmensraum aus RFC 1918 ab. Die IANA-Tabelle kennzeichnet beide als besondere, nicht weltweit erreichbare Adressen, doch Betreiber und Zweck unterscheiden sich.

„Innen“ ist kein einheitliches Gebiet. Heimnetz, Unternehmensnetz und Providerbereich sind verschiedene Realms. Wer nur die Eigenschaft „nicht global erreichbar“ betrachtet, verliert genau die Zuständigkeit, die eine wiederverwendete Adresse eindeutig macht.

RFC 1918 schwächte Eindeutigkeit nicht ab. Er beschränkte ihre erforderliche Reichweite. Zwei getrennte Netze konnten deshalb gleichzeitig korrekt sein. Nach ihrer Verbindung braucht die gemeinsame Umgebung eine neue Wahrheit: einen neuen Adressplan, nachvollziehbare Übersetzungen oder weiter bestehende Grenzen — und für kritische Kommunikation einen Nachweis des tatsächlichen Gegenübers.

Quellen