Ausgehend von der Frage “warum nehmen wir nicht einfach ULAs, konfigurieren am Router die Network Prefix Translation for IPv6 (NPTv6) nach RFC6296”, entstand die nachfolgende ausführlichere Betrachtung. Nach der Einführung in ULAs wird NPTv6 und dessen „Showstopper“ betrachtet.
Einführung in ULAs
Offizieller Standard für „Unique Local IPv6 Unicast Addresses“ ist RFC 4193. Nachfolgend wird die gängige, aber verkürzte Schreibweise „Unique Local Addresses (ULAs)“ verwendet.
Die Definition des ULA-Adressraums ist fc00::/7. Um den daraus resultierenden Adressraum ableiten zu können, schreibt man das erste Byte, also die Hexadezimal-Ziffer fc, als Binärzahl und erhält 1111 1100. Die Prefix-Length legt nun fest, dass die ersten 7 Bit dieses Werts für ULAs fixiert sind (also 1111 110) und nur das letzte Bit, das Bit #8, variabel ist. Das erste Byte von ULAs ist also die Bit-Kombination 1111 1100 oder 1111 1101, bzw. in hexadezimaler Schreibweise fc und fd.
Das Bit #8 hat aber gleichzeitig eine besondere Bedeutung! Der Wert 1 definiert lokal vergebene Adressen, während 0 für global vergebene ULAs nicht definiert und für zukünftige Spezifikationen zurückgehalten ist (siehe RFC 4193, Absatz 3.2). Oder anders ausgedrückt: Aktuell ist der per offiziellem Standard nutzbare ULA-Bereich fd00::/8.
Somit umfasst der ULA-Bereich rein rechnerisch alle Adressen im Bereich
-
fd00:0000:0000:0000:0000:0000:0000:0000bis -
fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
Unter Beachtung der auch für ULAs geltenden Bit-Bereiche von IPv6 …
| 7 bits |1| 40 bits | 16 bits | 64 bits |
+--------+-+------------+-----------+----------------------------+
| Prefix |L| Global ID | Subnet ID | Interface ID |
+--------+-+------------+-----------+----------------------------+… stehen also für eine Site (einen Standort) weitere 40 Bits im Global-ID-Bereich zur eindeutigen Identifizierung bzw. Adressvergabe zur Verfügung. Dieser 40 Bit wert soll eigentlich entsprechend dem Abschnitt 3.2.2 im RFC 4193 pseudo-zufällig vergeben werden. Idee dahinter ist, dass unterschiedliche Sites mit hoher Wahrscheinlichkeit keine Adressüberlappung haben und untereinander ein Routing einrichten können.
Für Sites / Standorte nutzbar sind somit Netze im Bereich …
-
fd00:0000:0000::/48(bzw.fd00::/48) bis -
fdff:ffff:ffff::/48
Die verbleibenden 16-Bit bis zur 64-Bit-Grenze (der dahinter liegende Bereich ist für Unicast-Adressen fest als Interface-ID festgelegt) ist als „Subnet ID“ bekannt. Der Begriff „Subnet“ darf hier nicht mit dem Begriff Subnet bei IPv4 gleichgesetzt werden. IPv6-Netze mit Unicast-Adressen haben eine fixe Prefix-Länge von /64 (siehe relevanten Standard RFC 3513) und Subnetting im Verständnis von IPv4 kann nicht stattfinden. Subnet bedeutet bei IPv6 somit nur die Festlegung der „16 Bit Subnet ID“ um für ein Netz innerhalb eines Standorts eine eindeutige Kennung zu haben.
Langer Rede, kurzer Sinn: Werden für einen Standort „Unique Local IPv6 Unicast Addresses“ (kurz ULAs) geplant, ist aus dem fd::/8-Bereich möglichst zufällig ein /48-Netz zu verwenden. Aus diesem /48-Netz werden für die einzelnen Netze des Standorts jeweils /64-Netze verwendet, die alle den gleichen /48-Prefix haben! Die damit 2^16 möglichen Netze innerhalb eines Standorts erscheinen allgemein ausreichend :-).
IPv6-to-IPv6 Network Prefix Translation
Während es für IPv6 kein NAT im Sinne von IPv4-NAT gibt, existieren doch Ideen wie „IPv6-to-IPv6 Network Prefix Translation“ in Form des experimentellen RFCs 6296. Hierbei wird, ohne den Aufwand aufwändiger Verwaltungstabellen im Router, einfach nur der Netz-Präfix ausgetauscht. Bei ausgehenden Pakten wird also der /64-Präfix der ULA-Adresse durch den GUA-/64-Präfix des Netzes ersetzt, bei eingehenden Paketen erfolgt das Gegenteil.
External Network: Prefix = 2001:0DB8:0001:/48
--------------------------------------
|
|
+-------------+
| NPTv6 |
| Translator |
+-------------+
|
|
--------------------------------------
Internal Network: Prefix = FD01:0203:0405:/48
Figure 1: A Simple TranslatorSieht prima aus, wird auch trotz des experimentellen Status angewandt, hat aber auch negative Seiten!
Probleme mit NPTv6?
Ein Gegenargument gegen „ULA mit NPTv6 only“ ist: Alle höheren Protokolle die ihre IPv6-Client-Adresse oberhalb von Layer-3 verwenden haben damit Probleme.
Im Netz wird als Beispiel meist primär IPsec aufgeführt. Das hat kryptographische Prüfsummen in der Payload die den IP-Header mit einem Hash eingerechnet haben (HMAC). Die knallen dann bei NPTv6 so vor die Wand wie schon bei IPv4-NAT.
Es gibt weitere Problembeschreibungen, z.B. wenn man für Lastverteilung mehrere WAN-Provider hat und die IP-Pakete unterschiedliche Wege nehmen können. Dann kann z.B. die Firewall eine Antwort (eingehende Daten) auf ein Paket erhalten zu dem die Anfrage über eine andere IPv6-Adresse raus ging. Statefull Firewalls, die nur „related Traffic“ ins Netz lassen, also Datenverkehr der zu einer von Innen geöffneten Verbindung gehört, blockieren hier.
Auch für Layer-7-Firewalls, häufig als Application Layer Gateways (ALG) bezeichnet, werden Probleme beschrieben. Es muss ggf., je nach unterstütztem Protokoll ein passendes Protokoll-Modul bereitgestellt werden das diesen Mechanismus kennt.
Trotzdem werden auch von Profis viele Vorteile dieses Setups (also Netze mit ULAs und NPTv6) beschrieben. Man darf dann aber Protokolle die Ärger machen nicht verwenden. Die argumentieren auch damit, dass die Ende-zu-Ende-Adressierung, ohne Adressmanipulationen, zwar der Idealzustand wäre, aber unter Sicherheitsaspekten eben auch nicht der Weisheit letzter Schluss wäre. Die verlegen dann die Endpoint-Security wieder an den Netzeingang. Andere halten das wiederum für keine gute Idee.
Vermutlich ist diese Problematik auch einer der Gründe (der Grund?) warum dieser Mechanismus und der im Juni 2011 erstellte RFC nach wie vor in der Kategorie „Experimental“ rangieren.
Fazit – gezielt für den Bildungsbereich
Und damit komme ich zum Fazit für mich, unter Berücksichtigung als Lehrkraft und Fortbildner: Man kann das zwar machen, aber ob man gerade in der Lehre, wenn Schüler:innen damit komplett neu anfangen, diese nicht überfordert (https://de.wikipedia.org/wiki/Ranschburg-Phänomen), wäre zu überlegen. Das ist darüber hinaus auch eine Frage der verfügbaren Unterrichtszeit. Wenn ich den Schüler:innen …
- erst mal GUAs, und vor allem LLAs und ihre Bedeutung beibringen kann,
- IPv6-Routing, und alles was eben IPv6-Grundlagen ausmacht …
- die das dann alles verstanden und verinnerlicht haben,
- ich ihnen dann noch Dinge wie IPsec nahe gebracht habe, sie das Problem mit NATing dort verstanden haben,
- Split-Horizon-DNS kennen, …
dann kann ich auch Netze mit ULAs und NPTv6 einführen. Aber hat man als Lehrkraft diese Zeit, und selbst die nötigen fachlichen Grundlagen, …? Speziell bei der Zeitfrage dürfte das in den meisten Fällen wohl eher nicht der Fall sein!
Und damit gerade für die Lehre folgender Vorschlag: Wenn man unbedingt ULAs verwenden möchte, dann wäre es eher sinnvoll nicht nur exklusiv mit ULAs und NPTv6 zu arbeiten. Statt dessen wäre ein Setup mit …
- Global Unicast Adressen (GUAs) für den Internet-Zugang,
- Unique Local Adressen (ULAs) für internen, deterministischen Zugriff,
- den bei IPv6 immer erforderlichen Link Local Adressen (LLAs)
- und mit der Erläuterung eins Split-Horizon-DNS
… passend. Wobei Split-Horizon-DNS dann schon wieder ein eigenes großes Thema ist und z.B. in der Simulationssoftware Packet Tracer u.a. gar nicht funktioniert.