Netzwerk

IPv6-Subnetzplanung, die mitwächst

Eine gute IPv6-Planung investiert Bits in verständliche Hierarchien, Routenzusammenfassung und Platz für Veränderung. Knapp ist nicht mehr die Zahl der Hostadressen, sondern ein Ordnungssystem, das auch Jahre nach der ersten Tabelle noch trägt.

Auf normalen Links bleibt /64 gesetzt

Für gewöhnliche LANs, VLANs und WLAN-Segmente vergibst du ein /64. Damit bleiben 64 Bit für den Interface Identifier, genau wie es Stateless Address Autoconfiguration, Neighbor Discovery, Privacy Addresses und viel Hostsoftware voraussetzen. Ein /80 mag nach vertrauter IPv4-Sparsamkeit hübsch aussehen, kauft betrieblich aber nichts und stört Mechanismen, die mit einem 64-Bit-Interfacefeld rechnen. Ein /56 auf einem einzelnen VLAN ist am anderen Ende falsch: Es versteckt 256 normale Link-Präfixe in einer Broadcast-Domain.

Es gibt enge Ausnahmen. Punkt-zu-Punkt-Verbindungen zwischen Routern werden teils mit /127 nummeriert, Loopbacks meist mit /128. Das sind bewusste Infrastrukturkonventionen, keine Vorlagen für Nutzernetze. Delegiert ein Provider einem Standort nur ein /64, lässt sich darunter nicht sauber subnetten. Verteile dieses Präfix nicht über mehrere Layer-2-Domänen und greife nicht reflexartig zu IPv6-NAT. Fordere eine geroutete Delegation in brauchbarer Größe: Ein /56 liefert 256 /64-Netze, ein /48 deren 65.536.

Vom delegierten Präfix aus Ebenen budgetieren

Halte zuerst fest, welches Präfix du tatsächlich kontrollierst und ob es provideraggregierbar, portabel oder nur vorübergehend ist. Angenommen, die Organisation erhält 2001:db8:1200::/40. Die nächsten acht Bit können 256 Standorte als /48 bezeichnen; jeder Standort besitzt danach 16 Bit für 65.536 /64-Links. Das ergibt zwei klare Ebenen: Das Backbone fasst die Organisation zusammen, regionales Routing einen Standort, und die Zugangsnetze erhalten die Standardgröße. Mit dem CIDR/Subnetz-Rechner prüfst du Grenzen und eine begrenzte Vorschau der Kindpräfixe, bevor Zahlen in Routerkonfigurationen landen.

Rechne Kapazität in Bits statt mit auswendig gelernten Beispielen. Der Schritt von /40 auf /48 verbraucht acht Bit und erzeugt 256 gleich große Blöcke. Von /48 auf /56 entstehen pro Standort wieder 256 Blöcke; die letzten acht Bit bis /64 ergeben je /56 256 LANs. Gib jeder Ebene genug Raum für die realistische Lebensdauer des Designs und lasse zwischen Regionen Werte frei. Dieser Leerraum ist keine Verschwendung. Er erlaubt Wachstum am selben Ort, ohne ein zweites, nicht zusammenhängendes Präfix und damit eine zusätzliche Route einzuführen.

Nibble-Grenzen halten den Plan lesbar

Eine hexadezimale Ziffer steht für vier Bit. Präfixlängen, die durch vier teilbar sind — /32, /36, /40, /44, /48, /52, /56, /60 und /64 — liegen deshalb auf sichtbaren Hex-Grenzen. Ein Operator erkennt die signifikanten Ziffern ohne Teil-Nibbles in Binärwerte umzuwandeln. Das Protokoll verlangt diese Ausrichtung nicht; auch /51 ist gültig. Als Betriebskonvention zahlt sie sich aber bei Routingstörungen, Firewall-Reviews, Reverse-DNS-Delegationen und handgeschriebenen Changes aus.

Nutze diese Lesbarkeit für Hierarchie, nicht für eine Enzyklopädie. Innerhalb eines Standort-/48 enthält das vierte Hextett die 16-Bit-Subnetz-ID. Eine erste Ziffer könnte die Zone, die zweite die Funktion und die letzten beiden das Segment bezeichnen; daraus entsteht etwa 2001:db8:1201:2307::/64. Halte den Schlüssel kurz. Gebäude, Stockwerk, Rack, Mandant, Umgebung, Sicherheitsklasse und VLAN-Nummer gleichzeitig in vier Hex-Ziffern zu pressen ergibt eine scheinbar sprechende Adresse, deren Aussage beim ersten Umzug falsch wird.

Standorte und VLANs nach Routinggrenzen ordnen

Eine skalierbare Hierarchie folgt dem Routing. Ein Standort oder eigenständig gerouteter Campus erhält einen zusammenhängenden Block; darunter liegen Bereiche für Region, Dienste oder Sicherheitszonen. Braucht eine Niederlassung heute höchstens 60 VLANs, lässt ein /56 mit 256 /64-Netzen reichlich sauberes Wachstum. Für einen großen Campus kann ein /48 angemessen sein, obwohl fast alles leer bleibt. Entscheidend ist, dass Upstream-Router eine Standortzusammenfassung statt hunderter Access-Präfixe annoncieren und Störungen oder Policy-Wechsel an einer im Adressplan sichtbaren Grenze enden.

Leite die IPv6-Subnetz-ID nicht automatisch aus der dezimalen VLAN-ID ab, außer die Konvention hilft den Betreibern wirklich. VLAN 120 als hexadezimales 0078, optisch dezimales 0120 oder als Zone-plus-VLAN sind drei verschiedene Regeln. Alle funktionieren, bis Teams stillschweigend unterschiedliche erwarten. Entscheide einmal, dokumentiere Beispiele und teste Automation gegen genau diese Schreibweise. Reserviere außerdem zusammenhängende Bereiche für Infrastruktur, Transit, Nutzer, Voice, WLAN, Labor und Zukunft. Benannte Reserven verhindern, dass ein „erstes freies Präfix“-Allocator verwandte Netze über den ganzen Standort verteilt.

IPv4-Knappheitsdenken gehört nicht ins neue Design

IPv4 belohnt enges Packen, weil Adressen knapp sind und NAT überlappende Privaträume erträglich erscheinen lässt. Bei IPv6 liegen die Anreize anders. Die Subnetzgröße bleibt gewöhnlich /64; üppig ist die Zahl der Subnetze. Für ein Drucker-LAN ein /120 zu wählen oder „nutzbare Hosts“ zu zählen bringt keinen Preis. IPv6 kennt keine Broadcast-Adresse, und die astronomische Adresszahl eines /64 ist kein Kapazitätsziel. Grenzen setzen Layer-2-Architektur, Neighbor Discovery, Switch-Tabellen, Sicherheitsregeln und betriebliche Vernunft, lange bevor Interface Identifier knapp werden.

Baue auch NAT nicht als Adresskonzept nach. Stabile interne Präfixe, klares Routing, Host-Firewalls und zustandsbehaftete Filterung am Rand schaffen Trennung, ohne Topologie hinter Übersetzung zu verstecken. Providergebundener Adressraum wirft allerdings die Frage nach Renumbering auf. Halte Präfixwerte deshalb in Konfigurationsmanagement, DNS und Policy-Objekten zentral, statt Literale überall zu kopieren. Wenn Multihoming oder Providerunabhängigkeit portablen Raum rechtfertigen, plane die daraus entstehende Routingverantwortung mit. Reichlich Adressen beseitigen einen Engpass, nicht die Pflicht zu Route Hygiene, Ingress Filtering und Ownership.

Dokumentation ist Teil der Zuteilung

Eine Vergabe ist erst fertig, wenn ihr Zweck festgehalten ist. Für jeden Block gehören kanonisches Präfix, Zweck, Parent, Standort, Routing-Verantwortung, Sicherheitszone, Lebenszyklusstatus, Vergabedatum, Quelldelegation und Kontakt ins IPAM. Bei jedem /64 kommen VLAN oder Link, Gateway-Konvention, Adressierungsverfahren, DHCPv6- beziehungsweise Router-Advertisement-Policy und DNS-Verantwortung hinzu. Reservierungen sind echte Objekte, keine leeren Tabellenzeilen. Leere Flächen wirken auf Automation verfügbar; eine benannte Reserve besitzt Grund und Eigentümer.

Das IPAM sollte maßgeblich sein und, wo praktikabel, Eingaben für Router, Firewalls, DNS und Monitoring erzeugen. Changes müssen Überlappungen, Kinder außerhalb ihres Parents, Nutzerlinks ungleich /64 und Zuteilungen über Reservatsgrenzen ablehnen. Prüfe öffentlich relevante Präfixe zusätzlich aus externer Sicht: Was ist meine IP? zeigt, welche Familie und Adresse ein Request tatsächlich verwendete; der DNSSEC-Validator liefert bei signiertem Reverse- oder Service-DNS Evidenz zu DS, DNSKEY, RRSIG und Resolverstatus. Beide ersetzen kein IPAM. Ein belastbarer Plan ist der, bei dem Dokumentation, Routen und Records auch nach dem Weggang des ursprünglichen Architekten übereinstimmen.