{"id":624,"date":"2018-02-13T01:43:50","date_gmt":"2018-02-13T00:43:50","guid":{"rendered":"http:\/\/www.instruyete.org\/?p=624"},"modified":"2020-03-29T14:56:32","modified_gmt":"2020-03-29T12:56:32","slug":"ipv6-ula-adressen-auf-dual-boot-rechnern","status":"publish","type":"post","link":"https:\/\/www.instruyete.org\/?p=624","title":{"rendered":"IPv6 ULA Adressen auf Dual-Boot Rechnern"},"content":{"rendered":"

Der Verbrauch aller verf\u00fcgbaren IPv4 Adressen zwingt allm\u00e4hlich die ISPs (Internet Service Provider) den Kunden nicht mehr exklusiv eine IPv4 Adresse – weder dauerhaft noch tempor\u00e4r – zur Verf\u00fcgung zu stellen. Stattdessen wird der begrenzte IPv4 Adressraum mit NAT<\/strong> (Network Adress Translation) auf ISP-Level<\/strong> erweitert – das sog. Carrier Grade NAT<\/em>.
\nF\u00fcr den Kunden bedeutet dies, dass er nicht mehr \u00fcber eine stabile IPv4 Adresse verf\u00fcgt, sondern nur noch \u00fcber eine stabile – wenn auch sich tempor\u00e4r \u00e4ndernde – IPv6 Adresse. Der Zugriff auf IPv4-only Webdienste erfolgt \u00fcblicherweise mit DS-Lite Tunnels<\/strong> in denen IPv4 Adressen in IPv6 Tunnel bis zum Provider gelangen, der dann mittels Carrier Grade NAT dem Paket eine momentan verf\u00fcgbare \u00f6ffentliche IPv4 Adresse zuweist und eine Zuordnungstabelle f\u00fchrt, um den Response dem urspr\u00fcnglichen Anfrager zur\u00fcckzuleiten.<\/p>\n

Auf Kundenseite impliziert dieses Verfahren den Einsatz von IPv6 – mindestens auf Router-Level. Wobei durch Router-Propagation<\/em> auch jeder Client hinter dem Router eine \u00f6ffentliche IPv6 Adresse erhalten kann und performante IPv6 Verbindungen – ohne NAT und Zuordnungstabellen – aufbauen kann.
\nDie Entscheidung, ob der Zugriff auf eine URL mit IPv4 oder IPv6 erfolgt, trifft das Betriebssystem, vorausgesetzt der hostname<\/em> l\u00e4sst sich durch den verantwortlichen Nameserver in eine IPv4 und IPv6 Adresse aufl\u00f6sen. Da dies aber immer h\u00e4ufiger der Fall ist, steigen auch die IPv6 Anfragen durch alle Netzwerke….<\/p>\n

…was der Grund f\u00fcr mich war auch im privaten Netzwerk durch den lokalen Nameserver alle hosts auf IPv6 aufzul\u00f6sen. Da die GUA<\/strong> (Global Unicast Address) sich aber t\u00e4glich \u00e4ndert und ich zudem im privaten Netzwerk auch nur private (also nicht geroutete) Adressen verwenden will, trage ich dort die stabilen ULAs<\/strong> (Unique Local Address) ein, die eben nicht \u00fcber eine Gateway Grenze geroutet werden.
\nDiese Adressen bestehen aus einem standardisierten 8bit Prefix (fd00::\/8), gefolgt von einer Global+Subnet ID, die im Normalfall im Router eingestellt wird und durch diesen propagiert (Router Advertisement) wird. Die folgende Grafik zeigt den Aufbau der GLAs und ULAs<\/p>\n

\"Zeigt<\/a><\/p>\n

Die niederwertigen 64bits werden lokal durch EUI-64 <\/strong>(Extended Unique Identifier) eingestellt – auch bekannt als Interface ID<\/em>. Dies passiert \u00fcberlicherweise mittels SLAAC<\/strong> (Stateless Address Autoconfiguration). Die EUI-64 besteht in der einfachsten Form aus einer MAC-Adresse (48bit) erweitert durch ein mittiges Einsetzen von 0xfffe. Dadurch entstehen permanente IPv6 Adressen – im Falle der ULA sogar dauerhaft permanent, da sich der Prefix – bestehend aus Global ID + Subnet ID – nicht \u00e4ndert. Flankiert werden diese permanenten Adressen durch die Privacy Extensions for Stateless Address Autoconfiguration in IPv6<\/em> gem\u00e4\u00df RFC4941<\/strong>. Diese erzeugen einen zuf\u00e4lligen Adressbestandteil auf der Interface ID und die damit gewonnen zus\u00e4tzlichen tempor\u00e4ren IPv6 Adressen<\/strong> k\u00f6nnen f\u00fcr ausgehende Verbindungen genutzt werden um eine vergr\u00f6\u00dferte Privatsph\u00e4re zu erhalten.<\/p>\n

Bis zu diesem Punkt ist aus Administrationssicht alles in Ordnung. Schwierig wurde es mit der Einf\u00fchrung des RFC7217<\/strong> A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)<\/em>. Dieser sieht vor, die stabilen IPv6 Adressen im Bereich der EUI-64 Interface ID nicht mehr aufgrund der MAC ID zu generieren. An sich w\u00e4re das nicht schlimm, da die Adressen ja immer noch stabil sind und daher in eine DNS Konfiguration eingetragen werden k\u00f6nnen. Schwierig wird es aber wenn eine IPv6 Adresse eines Client-Netzwerkports auf einem Dual-Boot Rechner pl\u00f6tzlich anders lautet, da bspw. Linux und macOS den RFC7217 anwenden und auf unterschiedliche IPv6 Adressen kommen. Das l\u00e4sst sich in einer DNS Konfiguration nicht mehr abbilden, es sei denn man vergibt auf dem Dual-Boot Rechner unterschiedliche Hostnamen (und IPv4 Adressen), wobei dann auf OSI-Level 2 eine ARP Adresse auf unterschiedliche IPv6 Adressen verzweigt, was ev. bei einem Switch zu Problemen f\u00fchrt.<\/p>\n

Abhilfe schafft hier, auf Betriebssystemebene die Anwendung der RFC7217 zu verhindern<\/strong>, was bei genauerer Betrachtung die Privatsph\u00e4re nicht wesentlich beintr\u00e4chtigt, da die tempor\u00e4ren Adressen gem\u00e4\u00df RFC4941 immer noch existieren und dar\u00fcber hinaus der Footprint eines Anwenders durch viele andere Erkennungsmerkmale gewonnen werden kann (oder bspw. durch uBlock Origin<\/em> verhindert werden kann).
\nDies Abschaltung der RFC7217 Implementationen wird mit folgenden Kommandos erreicht (Quelle: https:\/\/www.fz-juelich.de\/SharedDocs\/Downloads\/IAS\/JSC\/DE\/tki\/tki-0412.pdf?__blob=publicationFile<\/a>)<\/p>\n