{"id":1813,"date":"2024-03-10T14:14:19","date_gmt":"2024-03-10T13:14:19","guid":{"rendered":"https:\/\/grupp-web.de\/cms\/?p=1813"},"modified":"2024-03-10T17:58:10","modified_gmt":"2024-03-10T16:58:10","slug":"unique-local-ipv6-unicast-addresses-ulas","status":"publish","type":"post","link":"https:\/\/grupp-web.de\/cms\/2024\/03\/10\/unique-local-ipv6-unicast-addresses-ulas\/","title":{"rendered":"Unique Local IPv6 Unicast Addresses (ULAs) und IPv6-to-IPv6 Network Prefix Translation (NPTv6)"},"content":{"rendered":"\n<p>Ausgehend von der Frage \u201c<em>warum nehmen wir nicht einfach ULAs, konfigurieren am Router die Network Prefix Translation for IPv6 (NPTv6) nach RFC6296<\/em>\u201d, entstand die nachfolgende ausf\u00fchrlichere Betrachtung. Nach der Einf\u00fchrung in ULAs wird NPTv6 und dessen &#8222;Showstopper&#8220; betrachtet.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Einf\u00fchrung in ULAs<\/h2>\n\n\n\n<p>Offizieller Standard f\u00fcr &#8222;Unique Local IPv6 Unicast Addresses&#8220; ist <a href=\"https:\/\/datatracker.ietf.org\/doc\/html\/rfc4193\" data-type=\"link\" data-id=\"https:\/\/datatracker.ietf.org\/doc\/html\/rfc4193\" target=\"_blank\" rel=\"noreferrer noopener\">RFC 4193<\/a>. Nachfolgend wird die g\u00e4ngige, aber verk\u00fcrzte Schreibweise &#8222;<em>Unique Local Addresses (ULAs)<\/em>&#8220; verwendet.<\/p>\n\n\n\n<p>Die Definition des ULA-Adressraums ist <code>fc00::\/7<\/code>. Um den daraus resultierenden Adressraum ableiten zu k\u00f6nnen, schreibt man das erste Byte, also die Hexadezimal-Ziffer <code>fc<\/code>, als Bin\u00e4rzahl und erh\u00e4lt <code>1111 1100<\/code>. Die Prefix-Length legt nun fest, dass die ersten 7 Bit dieses Werts f\u00fcr ULAs fixiert sind (also <code>1111 110<\/code>) und nur das letzte Bit, das Bit #8, variabel ist. Das erste Byte von ULAs ist also die Bit-Kombination <code>1111 1100<\/code> oder <code>1111 1101<\/code>, bzw. in hexadezimaler Schreibweise <code>fc<\/code> und <code>fd<\/code>.<\/p>\n\n\n\n<p>Das Bit #8 hat aber gleichzeitig eine besondere Bedeutung! Der Wert 1 definiert lokal vergebene Adressen, w\u00e4hrend 0 f\u00fcr global vergebene ULAs nicht definiert und f\u00fcr zuk\u00fcnftige Spezifikationen zur\u00fcckgehalten ist (siehe <a href=\"https:\/\/datatracker.ietf.org\/doc\/html\/rfc4193#section-3.2\" data-type=\"link\" data-id=\"https:\/\/datatracker.ietf.org\/doc\/html\/rfc4193#section-3.2\" target=\"_blank\" rel=\"noreferrer noopener\">RFC 4193, Absatz 3.2<\/a>). Oder anders ausgedr\u00fcckt: Aktuell ist der per offiziellem Standard nutzbare ULA-Bereich fd00::\/8.<\/p>\n\n\n\n<p>Somit umfasst der ULA-Bereich rein rechnerisch alle Adressen im Bereich<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li> <code>fd00:0000:0000:0000:0000:0000:0000:0000<\/code> bis <\/li>\n\n\n\n<li> <code>fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff<\/code> <\/li>\n<\/ul>\n\n\n\n<p>Unter Beachtung der auch f\u00fcr ULAs geltenden Bit-Bereiche von IPv6 &#8230;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code lang=\"adoc\" class=\"language-adoc\">| 7 bits |1|  40 bits   |  16 bits  |          64 bits           |\n+--------+-+------------+-----------+----------------------------+\n| Prefix |L| Global ID  | Subnet ID |        Interface ID        |\n+--------+-+------------+-----------+----------------------------+<\/code><\/pre>\n\n\n\n<p>&#8230; stehen also f\u00fcr eine Site (einen Standort) weitere 40 Bits im Global-ID-Bereich zur eindeutigen Identifizierung bzw. Adressvergabe zur Verf\u00fcgung. Dieser 40 Bit wert soll eigentlich entsprechend dem <a href=\"https:\/\/datatracker.ietf.org\/doc\/html\/rfc4193#section-3.2.2\" data-type=\"link\" data-id=\"https:\/\/datatracker.ietf.org\/doc\/html\/rfc4193#section-3.2.2\" target=\"_blank\" rel=\"noreferrer noopener\">Abschnitt 3.2.2 im RFC 4193<\/a> pseudo-zuf\u00e4llig vergeben werden. Idee dahinter ist, dass unterschiedliche Sites mit hoher Wahrscheinlichkeit keine Adress\u00fcberlappung haben und untereinander ein Routing einrichten k\u00f6nnen.<\/p>\n\n\n\n<p>F\u00fcr Sites \/ Standorte nutzbar sind somit Netze im Bereich &#8230;<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li> <code>fd00:0000:0000::\/48<\/code> (bzw. <code>fd00::\/48<\/code>) bis <\/li>\n\n\n\n<li> <code>fdff:ffff:ffff::\/48<\/code> <\/li>\n<\/ul>\n\n\n\n<p>Die verbleibenden 16-Bit bis zur 64-Bit-Grenze (der dahinter liegende Bereich ist f\u00fcr Unicast-Adressen fest als Interface-ID festgelegt) ist als &#8222;Subnet ID&#8220; bekannt. Der Begriff &#8222;Subnet&#8220; darf hier nicht mit dem Begriff Subnet bei IPv4 gleichgesetzt werden. IPv6-Netze mit Unicast-Adressen haben eine fixe Prefix-L\u00e4nge von \/64 (siehe relevanten Standard <a href=\"https:\/\/datatracker.ietf.org\/doc\/html\/rfc3513\" data-type=\"link\" data-id=\"https:\/\/datatracker.ietf.org\/doc\/html\/rfc3513\" target=\"_blank\" rel=\"noreferrer noopener\">RFC 3513<\/a>) und Subnetting im Verst\u00e4ndnis von IPv4 kann nicht stattfinden. Subnet bedeutet bei IPv6 somit nur die Festlegung der &#8222;16 Bit Subnet ID&#8220; um f\u00fcr ein Netz innerhalb eines Standorts eine eindeutige Kennung zu haben.<\/p>\n\n\n\n<p>Langer Rede, kurzer Sinn: Werden f\u00fcr einen Standort &#8222;Unique Local IPv6 Unicast Addresses&#8220; (kurz ULAs) geplant, ist aus dem <code>fd::\/8<\/code>-Bereich m\u00f6glichst zuf\u00e4llig ein \/48-Netz zu verwenden. Aus diesem \/48-Netz werden f\u00fcr die einzelnen Netze des Standorts jeweils \/64-Netze verwendet, die alle den gleichen \/48-Prefix haben! Die damit 2^16 m\u00f6glichen Netze innerhalb eines Standorts erscheinen allgemein ausreichend :-).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">IPv6-to-IPv6 Network Prefix Translation<\/h2>\n\n\n\n<p>W\u00e4hrend es f\u00fcr IPv6 kein NAT im Sinne von IPv4-NAT gibt, existieren doch Ideen wie &#8222;IPv6-to-IPv6 Network Prefix Translation&#8220; in Form des experimentellen <a href=\"https:\/\/datatracker.ietf.org\/doc\/html\/rfc6296\" target=\"_blank\" rel=\"noreferrer noopener nofollow\">RFCs 6296<\/a>. Hierbei wird, ohne den Aufwand aufw\u00e4ndiger Verwaltungstabellen im Router, einfach nur der Netz-Pr\u00e4fix ausgetauscht. Bei ausgehenden Pakten wird also der \/64-Pr\u00e4fix der ULA-Adresse durch den GUA-\/64-Pr\u00e4fix des Netzes ersetzt, bei eingehenden Paketen erfolgt das Gegenteil.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code lang=\"adoc\" class=\"language-adoc\">               External Network:  Prefix = 2001:0DB8:0001:\/48\n                   --------------------------------------\n                                     |\n                                     |\n                              +-------------+\n                              |     NPTv6   |\n                              |  Translator |\n                              +-------------+\n                                     |\n                                     |\n                   --------------------------------------\n               Internal Network:  Prefix = FD01:0203:0405:\/48\n\n                       Figure 1: A Simple Translator<\/code><\/pre>\n\n\n\n<p>Sieht prima aus, wird auch trotz des experimentellen Status angewandt, hat aber auch negative Seiten!<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Probleme mit NPTv6?<\/h3>\n\n\n\n<p>Ein Gegenargument gegen &#8222;<em>ULA mit NPTv6 only<\/em>&#8220; ist: Alle h\u00f6heren Protokolle die ihre IPv6-Client-Adresse oberhalb von Layer-3 verwenden haben damit Probleme.<\/p>\n\n\n\n<p>Im Netz wird als Beispiel meist prim\u00e4r IPsec aufgef\u00fchrt. Das hat kryptographische Pr\u00fcfsummen 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.<\/p>\n\n\n\n<p>Es gibt weitere Problembeschreibungen, z.B. wenn man f\u00fcr Lastverteilung mehrere WAN-Provider hat und die IP-Pakete unterschiedliche Wege nehmen k\u00f6nnen. Dann kann z.B. die Firewall eine Antwort (eingehende Daten) auf ein Paket erhalten zu dem die Anfrage \u00fcber eine andere IPv6-Adresse raus ging. Statefull Firewalls, die nur &#8222;related Traffic&#8220; ins Netz lassen, also Datenverkehr der zu einer von Innen ge\u00f6ffneten Verbindung geh\u00f6rt, blockieren hier.<\/p>\n\n\n\n<p>Auch f\u00fcr Layer-7-Firewalls, h\u00e4ufig als <em>Application Layer Gateways (ALG)<\/em> bezeichnet, werden Probleme beschrieben. Es muss ggf., je nach unterst\u00fctztem Protokoll ein passendes Protokoll-Modul bereitgestellt werden das diesen Mechanismus kennt.<\/p>\n\n\n\n<p>Trotzdem werden auch von Profis viele Vorteile dieses Setups (also Netze mit ULAs und NPTv6) beschrieben. Man darf dann aber Protokolle die \u00c4rger machen nicht verwenden. Die argumentieren auch damit, dass die Ende-zu-Ende-Adressierung, ohne Adressmanipulationen, zwar der Idealzustand w\u00e4re, aber unter Sicherheitsaspekten eben auch nicht der Weisheit letzter Schluss w\u00e4re. Die verlegen dann die Endpoint-Security wieder an den Netzeingang. Andere halten das wiederum f\u00fcr keine gute Idee.<\/p>\n\n\n\n<p>Vermutlich ist diese Problematik auch einer der Gr\u00fcnde (der Grund?) warum dieser Mechanismus und der im Juni 2011 erstellte RFC nach wie vor in der Kategorie &#8222;Experimental&#8220; rangieren.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Fazit &#8211; gezielt f\u00fcr den Bildungsbereich<\/h2>\n\n\n\n<p>Und damit komme ich zum Fazit f\u00fcr mich, unter Ber\u00fccksichtigung als Lehrkraft und Fortbildner: Man kann das zwar machen, aber ob man gerade in der Lehre, wenn Sch\u00fcler:innen damit komplett neu anfangen, diese nicht \u00fcberfordert (<a href=\"https:\/\/de.wikipedia.org\/wiki\/Ranschburg-Ph%C3%A4nomen\" rel=\"noopener noreferrer nofollow\">https:\/\/de.wikipedia.org\/wiki\/Ranschburg-Ph\u00e4nomen<\/a>), w\u00e4re zu \u00fcberlegen. Das ist dar\u00fcber hinaus auch eine Frage der verf\u00fcgbaren Unterrichtszeit. Wenn ich den Sch\u00fcler:innen &#8230;<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>erst mal GUAs, und vor allem LLAs und ihre Bedeutung beibringen kann,<\/li>\n\n\n\n<li>IPv6-Routing, und alles was eben IPv6-Grundlagen ausmacht &#8230;<\/li>\n\n\n\n<li>die das dann alles verstanden und verinnerlicht haben,<\/li>\n\n\n\n<li>ich ihnen dann noch Dinge wie IPsec nahe gebracht habe, sie das Problem mit NATing dort verstanden haben,<\/li>\n\n\n\n<li>Split-Horizon-DNS kennen, &#8230;<\/li>\n<\/ul>\n\n\n\n<p>dann kann ich auch Netze mit ULAs und NPTv6 einf\u00fchren. Aber hat man als Lehrkraft diese Zeit, und selbst die n\u00f6tigen fachlichen Grundlagen, &#8230;? Speziell bei der Zeitfrage d\u00fcrfte das in den meisten F\u00e4llen wohl eher nicht der Fall sein!<\/p>\n\n\n\n<p>Und damit gerade f\u00fcr die Lehre folgender Vorschlag: Wenn man unbedingt ULAs verwenden m\u00f6chte, dann w\u00e4re es eher sinnvoll nicht nur exklusiv mit ULAs und NPTv6 zu arbeiten. Statt dessen w\u00e4re ein Setup mit &#8230;<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li> Global Unicast Adressen (GUAs) f\u00fcr den Internet-Zugang, <\/li>\n\n\n\n<li> Unique Local Adressen (ULAs) f\u00fcr internen, deterministischen Zugriff,<\/li>\n\n\n\n<li> den bei IPv6 immer erforderlichen Link Local Adressen (LLAs)<\/li>\n\n\n\n<li> und mit der Erl\u00e4uterung eins Split-Horizon-DNS <\/li>\n<\/ul>\n\n\n\n<p>&#8230; passend. Wobei Split-Horizon-DNS dann schon wieder ein eigenes gro\u00dfes Thema ist und z.B. in der Simulationssoftware Packet Tracer u.a. gar nicht funktioniert.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Ausgehend von der Frage \u201cwarum nehmen wir nicht einfach ULAs, konfigurieren am Router die Network Prefix Translation for IPv6 (NPTv6) nach RFC6296\u201d, entstand die nachfolgende ausf\u00fchrlichere Betrachtung. Nach der Einf\u00fchrung in ULAs wird NPTv6 und dessen &#8222;Showstopper&#8220; betrachtet. Einf\u00fchrung in ULAs Offizieller Standard f\u00fcr &#8222;Unique Local IPv6 Unicast Addresses&#8220; ist RFC 4193. Nachfolgend wird die &#8230; <a title=\"Unique Local IPv6 Unicast Addresses (ULAs) und IPv6-to-IPv6 Network Prefix Translation (NPTv6)\" class=\"read-more\" href=\"https:\/\/grupp-web.de\/cms\/2024\/03\/10\/unique-local-ipv6-unicast-addresses-ulas\/\" aria-label=\"Mehr Informationen \u00fcber Unique Local IPv6 Unicast Addresses (ULAs) und IPv6-to-IPv6 Network Prefix Translation (NPTv6)\">Weiterlesen<\/a><\/p>\n","protected":false},"author":1,"featured_media":1824,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[21,22,23],"class_list":["post-1813","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cisco-academy","tag-ipv6","tag-rechnernetze","tag-unterricht"],"_links":{"self":[{"href":"https:\/\/grupp-web.de\/cms\/wp-json\/wp\/v2\/posts\/1813","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/grupp-web.de\/cms\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/grupp-web.de\/cms\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/grupp-web.de\/cms\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/grupp-web.de\/cms\/wp-json\/wp\/v2\/comments?post=1813"}],"version-history":[{"count":8,"href":"https:\/\/grupp-web.de\/cms\/wp-json\/wp\/v2\/posts\/1813\/revisions"}],"predecessor-version":[{"id":1828,"href":"https:\/\/grupp-web.de\/cms\/wp-json\/wp\/v2\/posts\/1813\/revisions\/1828"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/grupp-web.de\/cms\/wp-json\/wp\/v2\/media\/1824"}],"wp:attachment":[{"href":"https:\/\/grupp-web.de\/cms\/wp-json\/wp\/v2\/media?parent=1813"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/grupp-web.de\/cms\/wp-json\/wp\/v2\/categories?post=1813"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/grupp-web.de\/cms\/wp-json\/wp\/v2\/tags?post=1813"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}