Tag: IPv6

Der Verbrauch aller verfügbaren IPv4 Adressen zwingt allmählich die ISPs (Internet Service Provider) den Kunden nicht mehr exklusiv eine IPv4 Adresse – weder dauerhaft noch temporär – zur Verfügung zu stellen. Stattdessen wird der begrenzte IPv4 Adressraum mit NAT (Network Adress Translation) auf ISP-Level erweitert – das sog. Carrier Grade NAT.
Für den Kunden bedeutet dies, dass er nicht mehr über eine stabile IPv4 Adresse verfügt, sondern nur noch über eine stabile – wenn auch sich temporär ändernde – IPv6 Adresse. Der Zugriff auf IPv4-only Webdienste erfolgt üblicherweise mit DS-Lite Tunnels in denen IPv4 Adressen in IPv6 Tunnel bis zum Provider gelangen, der dann mittels Carrier Grade NAT dem Paket eine momentan verfügbare öffentliche IPv4 Adresse zuweist und eine Zuordnungstabelle führt, um den Response dem ursprünglichen Anfrager zurückzuleiten.

Auf Kundenseite impliziert dieses Verfahren den Einsatz von IPv6 – mindestens auf Router-Level. Wobei durch Router-Propagation auch jeder Client hinter dem Router eine öffentliche IPv6 Adresse erhalten kann und performante IPv6 Verbindungen – ohne NAT und Zuordnungstabellen – aufbauen kann.
Die Entscheidung, ob der Zugriff auf eine URL mit IPv4 oder IPv6 erfolgt, trifft das Betriebssystem, vorausgesetzt der hostname lässt sich durch den verantwortlichen Nameserver in eine IPv4 und IPv6 Adresse auflösen. Da dies aber immer häufiger der Fall ist, steigen auch die IPv6 Anfragen durch alle Netzwerke….

…was der Grund für mich war auch im privaten Netzwerk durch den lokalen Nameserver alle hosts auf IPv6 aufzulösen. Da die GUA (Global Unicast Address) sich aber täglich ändert und ich zudem im privaten Netzwerk auch nur private (also nicht geroutete) Adressen verwenden will, trage ich dort die stabilen ULAs (Unique Local Address) ein, die eben nicht über eine Gateway Grenze geroutet werden.
Diese 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

Die niederwertigen 64bits werden lokal durch EUI-64 (Extended Unique Identifier) eingestellt – auch bekannt als Interface ID. Dies passiert überlicherweise mittels SLAAC (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 ändert. Flankiert werden diese permanenten Adressen durch die Privacy Extensions for Stateless Address Autoconfiguration in IPv6 gemäß RFC4941. Diese erzeugen einen zufälligen Adressbestandteil auf der Interface ID und die damit gewonnen zusätzlichen temporären IPv6 Adressen können für ausgehende Verbindungen genutzt werden um eine vergrößerte Privatsphäre zu erhalten.

Bis zu diesem Punkt ist aus Administrationssicht alles in Ordnung. Schwierig wurde es mit der Einführung des RFC7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC). 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äre das nicht schlimm, da die Adressen ja immer noch stabil sind und daher in eine DNS Konfiguration eingetragen werden können. Schwierig wird es aber wenn eine IPv6 Adresse eines Client-Netzwerkports auf einem Dual-Boot Rechner plötzlich anders lautet, da bspw. Linux und macOS den RFC7217 anwenden und auf unterschiedliche IPv6 Adressen kommen. Das lässt 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ührt.

Abhilfe schafft hier, auf Betriebssystemebene die Anwendung der RFC7217 zu verhindern, was bei genauerer Betrachtung die Privatsphäre nicht wesentlich beinträchtigt, da die temporären Adressen gemäß RFC4941 immer noch existieren und darüber hinaus der Footprint eines Anwenders durch viele andere Erkennungsmerkmale gewonnen werden kann (oder bspw. durch uBlock Origin verhindert werden kann).
Dies 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)

• auf Linux (ohne Network Manager, bspw. Ubuntu 14.04)

  in /etc/sysctl.conf folgendes eintragen (falls eth0 tatsächlich das richtige interface ist)
  
net.ipv6.conf.eth0.use_tempaddr = 0


• auf Linux (mit Network Manager, bspw. Ubuntu 16.04)

  user@host> nmcli conn show
  (zeigt die verfügbaren Netzwerknamen an – hier den richtigen heraussuchen, bspw. ‚Wired connection 1‘)
  user@host> nmcli conn edit 'Wired connection 1'
nmcli> save
nmcli> set ipv6.addr-gen-mode eui64
nmcli> set ipv6.ip6-privacy 0
nmcli> save
nmcli> quit

• auf macOS:
  
$ echo net.inet6.send.opmode=0 >> /etc/sysctl.conf
$ reboot