IPv6 ULA - sinnvolle Architektur oder Relikt aus einer Übergangszeit?
31.05.2026 7 Min. Lesezeit
Kaum ein Thema sorgt in IPv6-Diskussionen regelmäßig für so viele Grundsatzdebatten wie Unique Local Addresses, kurz ULA. Während die einen sie als unverzichtbaren Bestandteil eines sauberen IPv6-Designs betrachten, sehen andere darin die Rückkehr alter IPv4-Denkmuster, die man mit IPv6 eigentlich hinter sich lassen wollte.
Interessanterweise verlaufen diese Diskussionen oft erstaunlich emotional. Das liegt vermutlich daran, dass ULA nicht nur eine technische Entscheidung darstellen, sondern auch eine grundsätzliche Frage berühren: Wie soll ein modernes IPv6-Netz eigentlich aufgebaut sein?
Wer sich mit MPLS , Routing-Architekturen und größeren Netzdesigns beschäftigt, wird früher oder später zwangsläufig über diese Frage stolpern. Und wie so oft gibt es keine universell richtige Antwort. Es gibt lediglich unterschiedliche Anforderungen, unterschiedliche Betriebsmodelle und unterschiedliche Erfahrungen.
Gerade deshalb lohnt es sich, einen Blick darauf zu werfen, warum ULA überhaupt entstanden sind, welche Probleme sie lösen sollten und warum ihre Rolle heute deutlich differenzierter betrachtet wird als noch vor einigen Jahren.
Der historische Hintergrund
Um ULA zu verstehen, muss man zunächst einen Schritt zurückgehen und sich erinnern, aus welcher Zeit IPv6 ursprünglich stammt.
In der IPv4-Welt existierten private Adressbereiche nach RFC 1918. Die bekannten Netze 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16 ermöglichten es Unternehmen, interne Netze unabhängig von öffentlich routbaren Adressen aufzubauen.
Diese Adressbereiche wurden zum Fundament nahezu jeder Unternehmensinfrastruktur.
Mit IPv6 sollte vieles anders werden.
Plötzlich standen nicht mehr einige tausend oder einige Millionen Adressen zur Verfügung, sondern praktisch unerschöpfliche Mengen. Die ursprüngliche Vision war einfach: Jedes Gerät erhält eine global eindeutige Adresse. NAT verschwindet. Die künstliche Trennung zwischen internen und externen Adressen wird überflüssig.
Aus dieser Perspektive betrachtet wirken private Adressbereiche zunächst wie ein Konzept, das man gar nicht mehr benötigt.
Die Realität erwies sich jedoch als etwas komplizierter.
Warum man überhaupt über lokale IPv6-Adressen nachdachte
Bereits früh stellte sich die Frage, ob wirklich jedes interne System zwingend globale IPv6-Adressen erhalten sollte.
Nicht weil Adressen knapp wären.
Sondern weil Netzwerke manchmal Anforderungen besitzen, die nichts mit Adressknappheit zu tun haben.
Was passiert beispielsweise, wenn ein Unternehmen den Provider wechselt?
Was passiert, wenn ein Standort temporär keine globale IPv6-Konnektivität besitzt?
Was passiert mit internen Management-Netzen, Backbone-Strukturen oder Routing-Endpunkten, die unabhängig von einem ISP existieren sollen?
Genau aus diesen Überlegungen entstand zunächst das Konzept der Site Local Addresses.
Diese verwendeten den Bereich FEC0::/10 und sollten das IPv6-Pendant zu RFC-1918-Netzen darstellen.
Die Idee war gut gemeint.
Die Umsetzung war es weniger.
Das Scheitern von Site Local
Das Problem von Site Local bestand darin, dass niemand wirklich definierte, was eine “Site” eigentlich ist.
Für den einen war eine Site ein Gebäude.
Für den anderen ein Campus.
Für den nächsten das gesamte Unternehmen.
Die Folge waren erhebliche Routing-Probleme.
Sobald mehrere Organisationen miteinander verbunden wurden, entstanden Adressüberschneidungen und Unklarheiten über die Gültigkeitsbereiche der Adressen.
Letztlich erkannte die IPv6-Community, dass Site Local mehr Probleme erzeugte als löste.
Das Konzept wurde verworfen.
An seine Stelle trat ULA.
Was ULA eigentlich ist
ULA verwendet den Präfix FC00::/7, wobei in der Praxis fast ausschließlich FD00::/8 genutzt wird.
Anders als bei klassischen privaten IPv4-Adressen wird dabei ein zufällig generierter Global Identifier verwendet.
Dadurch entstehen Präfixe wie:
fd42:8e6a:c9f1::/48
oder
fd73:1b2c:7d99::/48
Der Gedanke dahinter ist elegant.
Während praktisch jedes Unternehmen irgendwann ein 10.0.0.0/8-Netz verwendet hat und Adressüberschneidungen nahezu garantiert sind, ist die Wahrscheinlichkeit identischer ULA-Präfixe extrem gering.
ULA-Adressen sind damit lokal verwendbar, ohne die typischen Skalierungsprobleme klassischer privater IPv4-Adressräume mitzubringen.
Zumindest in der Theorie.
Die Argumente für ULA
Wer ULA einsetzt, verfolgt meist ein sehr konkretes Ziel: die Entkopplung interner Infrastruktur von externen Providern.
Das Argument begegnet einem besonders häufig bei Routing-Protokollen.
Nehmen wir einen MPLS-Core, ein Datacenter-Fabric oder eine größere Firewall-Landschaft.
Die Router-IDs, BGP-Sessions, Management-Endpunkte und Monitoring-Systeme existieren unabhängig davon, welcher Internetprovider aktuell genutzt wird.
Wird das Unternehmen renummeriert, weil ein Providerwechsel stattfindet, möchte man nicht gleichzeitig die gesamte Infrastruktur neu adressieren.
Hier entfalten ULA ihren größten Charme.
Die Infrastruktur erhält stabile interne Adressen, die dauerhaft bestehen bleiben.
Globale Präfixe können kommen und gehen, ohne dass die eigentliche Netzarchitektur angepasst werden muss.
Gerade Betreiber größerer Umgebungen schätzen diese Eigenschaft.
Für sie sind ULA weniger ein Sicherheitsmechanismus als vielmehr ein Werkzeug zur Stabilisierung der Infrastruktur.
Die Argumente gegen ULA
Ebenso nachvollziehbar sind allerdings die Gegenargumente.
IPv6 wurde schließlich genau deshalb entwickelt, um die Probleme künstlicher Adresshierarchien zu beseitigen.
Wenn ausreichend globale Adressen vorhanden sind, warum sollte man dann überhaupt noch zusätzliche Adressräume einführen?
Viele Betreiber argumentieren, dass ULA lediglich unnötige Komplexität erzeugen.
Ein Gerät besitzt plötzlich mehrere Adressen.
DNS-Einträge werden komplizierter.
Troubleshooting wird schwieriger.
Firewall-Regeln müssen mehrere Präfixe berücksichtigen.
Monitoring-Systeme sehen unterschiedliche Quelladressen.
Anstatt die Infrastruktur zu vereinfachen, entstehen zusätzliche Ebenen, die dokumentiert und verstanden werden müssen.
Diese Kritik ist keineswegs unberechtigt.
Denn jedes zusätzliche Adresskonzept erhöht die Komplexität eines Netzwerks.
Und Komplexität ist selten kostenlos.
Die Erfahrungen der letzten Jahre
Betrachtet man die letzten zehn bis fünfzehn Jahre IPv6-Praxis, zeigt sich ein interessantes Bild.
Die ursprünglich befürchteten Massen-Renummerierungen sind deutlich seltener eingetreten als erwartet.
Viele Unternehmen besitzen heute Provider Independent Adressräume oder langfristig stabile Provider-Präfixe.
Gleichzeitig haben moderne Betriebssysteme gelernt, problemlos mit mehreren IPv6-Adressen gleichzeitig umzugehen.
Die technischen Hürden sind also deutlich geringer geworden.
In der Praxis haben sich daher zwei Lager herausgebildet.
Das erste Lager setzt konsequent auf Global Unicast Adressen für alles.
Server, Clients, Router und Infrastruktur erhalten ausschließlich globale Präfixe.
Das Design bleibt maximal einfach.
Das zweite Lager nutzt ULA gezielt für Infrastrukturkomponenten und interne Dienste, während Endgeräte zusätzlich globale Adressen erhalten.
Interessanterweise hat sich gerade dieser Mischbetrieb als besonders verbreitet erwiesen.
Wo ULA heute tatsächlich Sinn ergeben
Besonders überzeugend finde ich ULA dort, wo Infrastruktur dauerhaft von externer Konnektivität entkoppelt werden soll.
Loopback-Adressen von Routern gehören für mich eindeutig in diese Kategorie.
Ebenso interne BGP-Sessions, MPLS-Komponenten, Management-Endpunkte oder Monitoring-Systeme.
Diese Systeme existieren unabhängig davon, welche globalen Präfixe aktuell genutzt werden.
Eine stabile ULA-Adresse kann hier durchaus einen architektonischen Vorteil darstellen.
Vor allem in größeren Netzen mit mehreren Standorten oder komplexen Routing-Domänen.
Wo ich ULA eher kritisch sehe
Weniger überzeugend finde ich ULA auf klassischen Client-Netzen.
Wenn ein Arbeitsplatzrechner ohnehin globale IPv6-Konnektivität benötigt, entsteht durch zusätzliche ULA-Adressen oft nur begrenzter Mehrwert.
Der Verwaltungsaufwand steigt.
Die Fehlersuche wird komplexer.
Der eigentliche Nutzen bleibt dagegen häufig überschaubar.
An dieser Stelle wirkt ULA manchmal wie der Versuch, vertraute IPv4-Muster künstlich nach IPv6 zu übertragen.
Und genau dort sollte man kritisch hinterfragen, ob man tatsächlich ein Problem löst oder lediglich alte Gewohnheiten fortführt.
Was heute als Best Practice gilt
Die moderne IPv6-Welt hat sich weitgehend von dogmatischen Positionen verabschiedet.
Kaum jemand behauptet noch, dass ULA grundsätzlich falsch seien.
Ebenso wenig wird heute behauptet, dass jedes Netz zwingend ULA benötigt.
Die aktuelle Empfehlung lässt sich eher als situationsabhängiger Pragmatismus beschreiben.
Für Endgeräte und produktive Services sind globale IPv6-Adressen meist vollkommen ausreichend.
Für Infrastrukturkomponenten, Routing-Systeme, Management-Netze und langfristig stabile interne Dienste kann ULA hingegen durchaus sinnvoll sein.
Entscheidend ist weniger die konkrete Wahl des Adressraums als die Konsistenz des Designs.
Ein Netzwerk, das konsequent auf globale Adressen setzt, kann hervorragend funktionieren.
Ein Netzwerk mit klar definiertem ULA-Konzept kann ebenfalls hervorragend funktionieren.
Probleme entstehen meist dort, wo beides ohne klare Strategie vermischt wird.
Mein Fazit
Ich verstehe die Argumente beider Seiten.
Die IPv6-Idee, alles global adressierbar zu machen, besitzt eine gewisse Eleganz. Sie reduziert Komplexität und vermeidet viele Altlasten aus der IPv4-Welt.
Gleichzeitig habe ich über die Jahre genügend Infrastrukturen gesehen, bei denen stabile, providerunabhängige Adressen einen echten operativen Mehrwert bieten.
Deshalb betrachte ich ULA heute ähnlich wie Loopback-Adressen.
Nicht als Pflicht.
Nicht als Allheilmittel.
Aber als Werkzeug.
Und wie bei jedem Werkzeug hängt der Nutzen davon ab, wo und warum man es einsetzt.
Wer ULA ausschließlich deshalb verwendet, weil man früher private IPv4-Netze genutzt hat, sollte seine Motivation hinterfragen.
Wer ULA gezielt einsetzt, um Infrastruktur von externen Präfixen zu entkoppeln und langfristige Stabilität zu schaffen, kann damit sehr elegante Designs bauen.
Die eigentliche Frage lautet daher nicht, ob ULA gut oder schlecht sind.
Die eigentliche Frage lautet, welches Problem man lösen möchte.
Und genau wie so oft im Netzwerkdesign beginnt eine gute Architektur nicht mit einer Adresse, sondern mit einer klaren Vorstellung davon, wie das Netz in fünf oder zehn Jahren aussehen soll.