Zusammenfassung

  • Die pseudozufällige 40-Bit-Global-ID aus RFC 4193 sorgt dafür, dass unabhängig erzeugte ULA-Präfixe mit sehr hoher Wahrscheinlichkeit verschieden sind; sie registriert oder zertifiziert sie nicht.
  • „Global“ bezeichnet den angestrebten Eindeutigkeitsraum, nicht weltweite Erreichbarkeit. ULA-Routen gehören in einen Standort oder in ausdrücklich vereinbarte Standortkopplungen.
  • Bei einer Fusion oder einem VPN muss aus Wahrscheinlichkeit ein Prüfbeleg werden: alle /48 vergleichen, Routen und DNS begrenzen, Sicherheit getrennt nachweisen und Rückbau oder Umnummerierung festlegen.

Ein Netzplan zeigt zwei unterschiedliche Präfixe unter fd. Für die Projektleitung ist das eine grüne Ampel: keine Überschneidung, also kann die Kopplung beginnen. Für einen belastbaren Betriebsentscheid ist es zunächst nur eine starke Vermutung.

Die Vermutung ist absichtlich stark. RFC 4193 erschien im Oktober 2005 als Proposed Standard von Robert Hinden und Brian Haberman. Sie definiert IPv6 Unique Local Addresses im Bereich FC00::/7. Nach dem Präfix folgen ein L-Bit, eine 40 Bit lange Global-ID, eine 16-Bit-Subnet-ID und die 64-Bit-Interface-ID. L=1 kennzeichnet die lokal zugewiesene Form; deshalb liegt die heute definierte Konstruktion unter FD00::/8.

Für die Global-ID ist kein Antrag vorgesehen. Der Betreiber erzeugt sie pseudozufällig und darf weder fortlaufende noch allgemein bekannte Werte verwenden. Als Verfahren schlägt die RFC vor, einen Zeitwert mit einer systemspezifischen Kennung zu verbinden, SHA-1 zu berechnen und die niedrigsten 40 Bit zu übernehmen.

Die Hashfunktion liefert dabei keine kryptografische Vertrauenszusage. Sie authentisiert keinen Betreiber, verbirgt das Präfix nicht und signiert kein Eigentum. Sie verteilt voneinander unabhängige Entscheidungen über einen großen Zahlenraum.

Die Wahrscheinlichkeitstabelle der RFC begrenzt die Aussage. Bei zwei unabhängig erzeugten IDs beträgt die geschätzte Kollisionschance ungefähr 1,81 × 10^-12; bei 10.000 IDs etwa 4,54 × 10^-5. Das sind Modellwerte, keine Messung der heutigen Nutzung. Sie machen eine weltweite Abstimmung vor jeder lokalen Nummerierung unnötig. Sobald die beiden tatsächlichen Inventare einer Fusion vorliegen, ersetzen sie deren Vergleich nicht.

Auch „Global-ID“ darf nicht mit globalem Routing verwechselt werden. Global ist der Anspruch auf Eindeutigkeit über Verwaltungsgrenzen hinweg. Das aktuelle IANA-Register für besondere IPv6-Verwendungen führt fc00::/7 als gültige Quell- und Zieladresse sowie als weiterleitbar, aber nicht global erreichbar. Eine Eintragung in dieses Register garantiert zudem keine Erreichbarkeit in einer konkreten Umgebung.

Reichweite entsteht durch Regeln

RFC 4193 sieht ULA innerhalb eines Standorts oder zwischen bewusst verbundenen Standorten vor. Das Internet-Routing soll FC00::/7 standardmäßig ignorieren. An Standortgrenzen sind ULA-Routen und -Pakete in beide Richtungen zu filtern. Eine gewollte Kopplung sollte die benötigten /48 oder spezifischeren Routen einzeln freigeben, nicht den ganzen Adressbereich.

Damit ist ULA nicht von selbst eingeschlossen. Router können die Pakete weiterleiten, Tunnel können sie transportieren, und eine falsche Redistribution kann Routen verbreiten. Die Grenze besteht aus Filter, Topologie, Vereinbarung und Überwachung — nicht aus dem ersten Byte.

Für DNS gilt eine eigene Grenze. Wegen der nicht garantierten Eindeutigkeit rät RFC 4193 davon ab, ULA-AAAA- oder PTR-Einträge im globalen DNS zu veröffentlichen. Reverse-Anfragen dürfen die globale DNS-Infrastruktur nicht erreichen. Eine Netzintegration muss daher interne autoritative Zonen, Split Views, Forwarder, Reverse-Zonen und Namensabhängigkeiten von Anwendungen erfassen.

Das /48 konfiguriert auch keine Endgeräte. Router Advertisements, DHCPv6, manuelle Vergabe, Subnetzplanung und Namenspflege bleiben getrennte Aufgaben. RFC 5375 beschreibt die gleichzeitige Verwendung von ULA und globalen IPv6-Adressen. Daraus folgt keine Empfehlung für NAT in IPv6.

Sicherheit ist ebenfalls separat. Dienste brauchen Authentisierung und Autorisierung, Verkehrsbeziehungen brauchen Firewall-Regeln, Routenquellen brauchen Vertrauen und Vorfälle brauchen Protokolle. RFC 4193 weist ULA keine inhärente Sicherheit zu. Eine lokale Adresse belegt weder Identität noch Zugriffsrecht.

Die Reparatur des unklaren „Standorts“

RFC 3879 hatte die früheren Site-Local-Adressen verworfen. Der Begriff Standort besaß keine einheitliche Grenze: Gebäude, Rechenzentren, Niederlassungen und Partner konnten je nach Anwendung anders zusammengefasst werden. Präfixe gelangten nach außen, Anwendungen wählten den falschen Scope, und beim Zusammenschluss zweier Netze fehlte eine unterscheidbare lokale Kennung.

Die erzeugte Global-ID behebt diesen Teil des Problems ohne eine universelle Vergabestelle. Unabhängige Standorte können sich nummerieren und werden bei einer späteren Kopplung wahrscheinlich bereits unterschiedliche Präfixe besitzen. RFC 5375 nennt diesen Vorteil für Leaks und Fusionen: Eine sofortige Umnummerierung wird seltener.

Ausgeschlossen ist sie nicht. RFC 4193 rät von weltweitem ULA-Routing ab, weil niemand Eindeutigkeit garantiert und die Routen nicht sinnvoll aggregiert werden können. Treffen zwei gleiche IDs hinter einer neuen Verbindung aufeinander, kann Verkehr ausfallen oder das falsche System erreichen. Die Seltenheit des Ereignisses begrenzt den Schaden nicht.

Auch die persönliche Zuschreibung bleibt gemeinschaftlich. Haberman schrieb die RFC mit Hinden; der Text dankt weiteren Beteiligten. Die offizielle Fotoseite der abgeschlossenen IETF-IPv6-Arbeitsgruppe identifiziert Haberman und nennt beide als Vorsitzende. Die Internet Society stellte ihn im August 2026 als ihren Board-Vorsitzenden, Distinguished Engineer bei Fastly, Mitglied des NetDev-Leitungsgremiums und langjährigen IETF-Teilnehmer mit früher Arbeit an einer IPv6-Routerplattform vor. Dieser Werdegang liefert Kontext; die technischen Grenzen stammen aus den Standards.

Der Betriebsbeleg für den Zusammenschluss

Zuerst werden sämtliche aktiven und reservierten ULA-/48 beider Seiten erfasst. Dazu gehören Produktion, Labore, Cloud-Netze, Notfallumgebungen, ruhende VPN-Partner und in Anwendungen oder Vorlagen eingetragene Adressen. Anschließend werden die vollständigen Werte verglichen. Die Wahrscheinlichkeit begründet Zuversicht vor der Bestandsaufnahme; bei vorliegenden Daten ist der direkte Test stärker.

Für jedes Präfix wird die Herkunft dokumentiert: Zeitpunkt, Verfahren, Art der Systemkennung und verantwortliches Team. Sensible Geräteinformationen müssen nicht offengelegt werden. Erkennbar sein muss jedoch, ob Tochtergesellschaften dieselbe Vorlage kopiert haben. Eine Kopie ist keine unabhängige Zufallsentscheidung.

Danach folgt die Routenzulassung. Der Beleg nennt Verbindung, erlaubte Präfixe, Next Hops, Import- und Exportfilter, Überwachungsverantwortung und Rücknahmehandlung. Tests weisen nach, dass der Rest von FC00::/7 abgewiesen wird und kein Internet-Peer eine ULA-Ankündigung erhält.

DNS und Adressauswahl werden gesondert geprüft. Unterschiedliche IDs verhindern keine identischen internen Zonennamen. Ebenso kann eine Anwendung eine unerreichbare ULA einer funktionierenden globalen Adresse vorziehen. Autoritative Zonen, Views, Resolverpfade, Reverse-Auflösung und Auswahlregeln gehören deshalb in dieselbe Freigabe.

Der Sicherheitsnachweis enthält andere Fragen: Welche Identität prüft der Dienst? Welche Regel erlaubt den Fluss? Welche Routenquelle gilt als vertrauenswürdig? Welches Protokoll erklärt einen Missbrauch? „ULA“ ist auf keine davon eine Antwort.

Schließlich wird vor der Umschaltung der Ausstieg festgelegt. Eine Kollision kann eine Umnummerierung verlangen, ein externes Announcement den sofortigen Rückzug, ein DNS-Leak die Trennung eines Resolverpfads. Hart codierte Adressen können die Kopplung bis zur Reparatur verhindern. Rückbaubarkeit macht auch das seltene Ereignis beherrschbar.

Heng Lus Primat des laufenden Codes ordnet die Beweise: Routingtabellen, Paketpfade, DNS-Antworten und Anwendungstests zeigen Verhalten; Architekturzeichnungen bleiben Verwaltungsnachweise. Seine minimale Anfangsspezifikation fordert gerade genug gemeinsame Information, um die Verbindung sicher und umkehrbar zu machen, ohne lokale Gestaltung zu zentralisieren.

Die 40 Bit sind somit kein fehlender Zuteilungsbeleg. Sie sind ein Mittel, getrennte Netze ohne zentrale Erlaubnis entstehen zu lassen. Sobald diese Netze eine Grenze teilen, müssen ihre Betreiber den konkreten Beleg selbst herstellen.

Quellen