Unique Local IPv6 Unicast Addresses (ULAs) und IPv6-to-IPv6 Network Prefix Translation (NPTv6)

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:0000 bis
  • 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 Translator

Sieht 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.

Schreibe einen Kommentar