Deutsche Glasfaser IPv6 mit FritzBox 7590 und Erreichbarkeit des internen Servers über Port 30000

    Ich habe etwas nachgelesen. Die Privacy Extension zu deaktivieren geht mit einem Script und muss ja bei jedem Neustarte ausgeführt werden. Alternativ könnte ich noch eine feste IPv6 und Interface ID manuelle vergeben. Dann wäre ich erreichbar bis zum Adresswechsel durch den Provider. Am besten wäre es wenn die Fritzbox für die Portfreigabe automatisch die Interface ID vom Mac bekäme...

    Zitat von HubeBube

    Ich sehe bei aktivierten PE auch keine wesentliche Verbesserung beim Datenschutz, das ist jedoch nur meine persönliche Meinung.

    Sehe ich auch so. Und das System kann bei deaktiverten PE dann nicht umhin, bei einer SLAAC-Konfiguration eine permanente IPv6-Adresse zu generieren. Dies sollte nach den aktuellen Empfehlungen gemäß RFC8064 bzw. RFC7217 erfolgen.

    Aber nochmal:

    Solange auf einem System eine stabile/permanente IPv6-Adresse für die Inbound-Adressierung von Services zur Verfügung steht, stört es nicht, wenn auf dem System zusätzlich noch eine temporäre IPv6-Adresse wegen aktivierten "Privacy Extensions" vorhanden ist - letztere müssen dann auch nicht deaktiviert werden, um einen Zugriff auf Services über die stabile/permanente IPv6-Adresse zu ermöglichen.

    Kritisch wird es erst, wenn das System bei einer SLAAC-Konfiguration nur noch temporäre, jedoch keine stabile/permanente Adresse mehr generiert. Dies soll laut RFC8981-Chapter 5 möglich (aber wohl konfigurierbar) sein - Zitat:

    Allows hosts to employ only temporary addresses. [RFC4941] assumed that temporary addresses were configured in addition to stable addresses. This document does not imply or require the configuration of stable addresses; thus, implementations can now configure both stable and temporary addresses or temporary addresses only.

    Zitat von ZimmerZoltan

    Ich habe etwas nachgelesen. Die Privacy Extension zu deaktivieren geht mit einem Script und muss ja bei jedem Neustarte ausgeführt werden.

    Lösungen sind in #18 verlinkt.

    Zitat von ZimmerZoltan

    Alternativ könnte ich noch eine feste IPv6 und Interface ID manuelle vergeben. Dann wäre ich erreichbar bis zum Adresswechsel durch den Provider.

    Schlechte Idee, den Grund hierfür hast Du ja selbst genannt.

    Zitat von ZimmerZoltan

    Am besten wäre es wenn die Fritzbox für die Portfreigabe automatisch die Interface ID vom Mac bekäme...

    In einer IPv6 Konfiguration gibt die Firewall der Fritze lediglich die IPv6 Adresse für den Zugriff auf dein Heimnetz frei, sinnvoll ist es zusätzlich den erforderlichen Port zu benennen.

    Mit einer bloßen Portfreigabe erreichst du gar nichts!

    Portfreigaben (auf der public IP Adresse der Fritze) in Verbindung mit Portforwarding gibt es nur bei IPv4 (in unserem Kontext).

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von ZimmerZoltan

    Alternativ könnte ich noch eine feste IPv6 und Interface ID manuelle vergeben. Dann wäre ich erreichbar bis zum Adresswechsel durch den Provider. Am besten wäre es wenn die Fritzbox für die Portfreigabe automatisch die Interface ID vom Mac bekäme...

    Also wenn die permanente Interface-ID tatsächlich stets konstant wäre (ist sie ggf. leider nicht, siehe nächster Absatz), dann musst du nur sicherstellen, dass diese Interface-ID in der FB (Heimnetz | Netzwerk) für das Gerät (Details für Gerät | Register Heimnetz) auch als "IPv6-Interface-ID" vermerkt ist. Wenn du bei der Freigabe dann dein Gerät auswählst, wird genau diese "IPv6-Interface-ID" für die Freigabe verwendet.

    Der Punkt ist nur: Sofern im MAC-Book bereits RFC7217 implementiert ist, hängt die permanente "IPv6-Interface-ID" leider auch vom LAN-Präfix ab, für den sie generiert/verwendet wird. Bei einem Präfix-Wechsel durch den Provider (ist bei DG allerdings sehr selten - bei mir in 4 Jahren erst einmal nach einem DG-Wartungstermin vorgekommen) wird sich also leider auch die permanente "IPv6-Interface-ID" ändern, weil in deren Generierungs-Algorithmus das LAN-Präfix mit einfließt. Falls die Fritzbox diese Änderung der permanenten "IPv6-Interface-ID" nicht dynamisch aktualisiert (und dies auch für die bestehende Freigabe berücksichtigt), wirst du sie dort manuell anpassen müssen.

    Auch für eine DynDNS-Lösung (sofern der DynDNS-Client nicht direkt auf deinem MAC-Book läuft) hat das Implikationen, denn üblicherweise aktualisiert diese nur den sich ändernden LAN-Präfix, während du auf der Website des DynDNS-Anbieters die Liste der permanenten "IPv6-Interface-ID", denen das LAN-Präfix voranzustellen ist, manuell einpflegen musst.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    kurzes update

    Das mit dem Script funktioniert. Auch nach einem Neustart bleibt die Interface ID erhalten.

    Für den Zugriff habe ich den Dienst dynv6 verwendet, dort kann man eine feste Interface ID einstellen. Somit sollte der Zugriff immer funktionieren. In der fritzbox muss man nur die adresse für den rebound schutz eintragen

    Anleitung wurde nach chatgpt genutzt :)

    ✅ Methode: Dauerhafte IPv6-Adresse per Startscript

    1. Manuelle Adresse per ifconfig (temporär, zum Testen)

    Beispiel:

    Code
    bashKopierenBearbeitensudo ifconfig en0 inet6 2001:db8:abcd::123 prefixlen 64 add
    Zitat

    en0 ist typischerweise das Ethernet- oder WLAN-Interface. Mit ifconfig kannst du prüfen, welches aktiv ist.

    2. Script für automatische Zuweisung beim Booten

    Du erstellst ein LaunchDaemon, das beim Systemstart das ifconfig-Kommando erneut ausführt.

    a. Script anlegen

    Code
    bashKopierenBearbeitensudo nano /usr/local/bin/set_static_ipv6.sh

    Inhalt:

    Code
    bashKopierenBearbeiten#!/bin/bash
ifconfig en0 inet6 2001:db8:abcd::123 prefixlen 64 add

    Speichern mit CTRL+O, Enter, dann CTRL+X.

    Rechte setzen:

    Code
    bashKopierenBearbeitensudo chmod +x /usr/local/bin/set_static_ipv6.sh

    b. LaunchDaemon erstellen

    Code
    bashKopierenBearbeitensudo nano /Library/LaunchDaemons/com.custom.set_static_ipv6.plist

    Inhalt:

    Rechte setzen:

    Code
    bashKopierenBearbeitensudo chown root:wheel /Library/LaunchDaemons/com.custom.set_static_ipv6.plist
sudo chmod 644 /Library/LaunchDaemons/com.custom.set_static_ipv6.plist

    Daemon laden:

    Code
    bashKopierenBearbeitensudo launchctl load /Library/LaunchDaemons/com.custom.set_static_ipv6.plist

    🔁 Test nach Neustart

    Starte deinen Mac neu und prüfe dann mit:

    Code
    bashKopierenBearbeitenifconfig en0

    Du solltest die manuell gesetzte Adresse sehen.

    Wenn ich es richtig verstehe, führt das Skript einfach eine statische IPv6-Adresszuweisung durch. Bei einem Präfix-Wechsel durch die DG fällst du damit auf die Nase. Das Skript sollte doch dazu dienen, die Privacy-Extensions abzuschalten. Ist aus meiner Sicht zwar nicht nötig, schadet aber auch nicht. Viel nützlicher wäre es, wenn es eine Möglichkeit gäbe, die Interface-ID nach der Ur-Methode "modified EUI64" setzen zu lassen (mit dem ff:fe in der Mitte).

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Yep, bei einem irgendwann folgenden Prefix-Wechsel fällt man gehörig auf die Nase und kann sich nicht mehr erinnern warum:(.

    Dann hoffen wir alle mal, das nicht 2001:db8 verwendet wurde, dass funktioniert nämlich nicht.

    chmod +x /usr/local/bin/set_static_ipv6.sh ist ja auch so eine Sache. Warum soll alles und jedes auf dieser Welt die Berechtigung erhalten das Script auszuführen? Nun ja, das unterscheidet die künstliche von der natürlichen Intelligenz... Es erschließt sich schon allein nicht, warum an einer Stelle der Modus mit +x und an anderer Stelle oktal angegeben wird.

    Btw ist der MS Copilot für das Erstellen von Scripts und Programmcode eigentlich die erste Wahl. Diese KI hat GitHub als Trainingsbasis, schließlich gehört diese Plattform MS.

    ::1 Für die MS Powershell habe ich vor Jahren mal etwas gescripted, das MAC-Adressen im IEEE 802, Unix und Cisco Format in EUI-64 wandelt. Nicht schön, jedoch funktional.

    Zitat von ::1

    Viel nützlicher wäre es, wenn es eine Möglichkeit gäbe, die Interface-ID nach der Ur-Methode "modified EUI64" setzen zu lassen (mit dem ff:fe in der Mitte).

    Besser waere tokenized interface identifier, weil die MAC Adresse ins Internet zu leaken sub-optimal ist (damit kann man die Endpunkt Identitaet einfach tracken, egal welches Praefix gerade genutzt wird)... Ja stabiler IPv6 Interface Identifier ist nuetzlich, aber noch nuetzlicher wenn man diesen vorsaetzlich aendern kann ;)

    Zitat von pufferueberlauf

    Besser waere tokenized interface identifier, weil die MAC Adresse ins Internet zu leaken sub-optimal ist (damit kann man die Endpunkt Identitaet einfach tracken, egal welches Praefix gerade genutzt wird)... Ja stabiler IPv6 Interface Identifier ist nuetzlich, aber noch nuetzlicher wenn man diesen vorsaetzlich aendern kann

    Veto: Diese Adresse würde ja nur für Inbound-Service-Zugriffe verwendet. Für outbound initiierten Traffic (der Internet konsumierende User am PC) würde ja die zusätzliche temporäre Adresse genutzt, sofern man die privacy extensions nicht deaktiviert hat. Deshalb sollte man die auch aktiv lassen, wenn einem die Privacy wichtig ist.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von pufferueberlauf

    Selbst dann ist es sub-optimal die MAC oeffentlich bekannt zu machen... weil man anhand der MAC den Hersteller des NIC erkennen kann.

    Tja, einen Tod muss man halt sterben, wenn man meint, an einem per SLAAC konfiguierten End-User-Device (MAC-Book) einen Service in die Welt exponieren zu müssen. Ich finde die Idee ja auch nicht sonderlich gut.

    Zitat von pufferueberlauf

    Besser waere tokenized interface identifier

    Was verstehst du darunter?

    Ich kenne als aktuellstes Verfahren zur Generierung einer stable IID das in RFC7217 beschriebene. Das scheint auch im MAC-Book schon implementiert zu sein (genaues weiß man nicht). Dieses Verfahren hat aber eben leider das "Problem", dass in den Algorithmus zur Generierung der stable IID das LAN-Präfix einfließt, für das die stable IID generiert werden soll. Das ist in dem Fall, dass DG bzw. der ISP einen neuen PD-Block zuweist, leider kontraproduktiv, weil sich damit eben auch die stable IID mit ändert - mit entsprechendem manuellen Anpassungs-Aufwand für die FB-Freigabe und DynDNS. Das ist so gar nicht im Sinne des Erfinders. Deshalb mein Vorschlag, sofern möglich, als stable IID die modified EUI64 zu verwenden - die ist garantiert konstant, auch nach Zuweisung eines neuen PD-Blocks. Unter Windows kann man modified EUI64 mit dem Kommando netsh int ipv6 set glob rand=dis erzwingen - ob es ein Pendant unter MAC-OS gibt, weiß ich leider nicht.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Hier mal ein Update zu der ganzen Thematik:

    Da ich im Besitz eines iPad Air (iPadOS 18.5) in Verbindung mit einer FRITZ!Box 7590 bin, konnte ich diverse Aspekte eruieren. Die Ergebnisse lassen sich sicherlich auf ein MacBook mit macOS übertragen.


    Zur Funktion "Private WLAN-Adressen auf Apple-Geräten":

    Diese Funktion ist hier erklärt. Sie hat demnach zunächst erst Mal nicht unmittelbar etwas mit IPv6-Adressen zu tun, sondern bezieht sich auf die MAC-Adresse des WLAN-Adapters. Sie ist zudem Apple-proprietär!

    Die Option "Private WLAN-Adresse" in den Einstellungen zum WLAN-Adapter kennt drei Werte:

    1. Aus: Auf Layer 2-Netzwerkebene (Ethernet/WLAN) wird die physische MAC-Adresse des WLAN-Adapters verwendet. Diese ist dann im WLAN für benachbarte Geräte sichtbar, was in öffentlichen WLANs privacy-relevant ist.
    2. Statisch/Fixiert: Die physische MAC-Adresse des WLAN-Adapters wird nicht verwendet. Stattdessen wird eine alternative MAC-Adresse generiert (eben eine "Private WLAN-Adresse"), mit der die physische MAC-Adresse des WLAN-Adapters überschrieben wird. Diese Ersatz-Adresse ist innerhalb eines WLANs, mit dem das Gerät verbunden ist, stets konstant und dort für benachbarte Geräte sichtbar. Wechselt man zu einem anderen WLAN, wird für dieses eine andere "Private WLAN-Adresse" generiert, die wiederum für jenes WLAN konstant ist.
    3. Rotierend: Wie "Statisch/Fixiert", jedoch wird zusätzlich alle 2 Wochen eine neue "Private WLAN-Adresse" pro WLAN generiert.

    Im Fazit kann man dieses Feature als "Privacy Extensions" für MAC-Adressen interpretieren.


    IPv6-Adressen auf Apple-Geräten mit SLAAC:

    Ein Apple-Gerät (zumindest mein oben genanntes iPad Air) generiert "stable" (also feste) SLAAC-Adressen offenbar gemäß RFC7217. Und in den dort beschriebenen Generierungs-Algorithmus für stable Interface-IDs (IID) scheint die MAC-Adresse des LAN-Adapters einzufließen (siehe Parameter "Net_Iface" und Anhang A3 des RFC). Das konnte ich durch Variation der Einstellungen für "Private WLAN-Adresse" verifizieren, weil dabei jeweils andere stable IIDs generiert wurden.

    Wenn man also eine feste globale IPv6-Adresse benötigt (zumindest in Bezug auf deren IID; ein variabler IPv6-Präfix muss per DynDNS behandelt werden), muss für "Private WLAN-Adresse" die Option "Rotierend" abgeschaltet werden. Ob man die Einstellung "Aus" oder "Statisch/Fixiert" wählt, ist egal.

    Wichtig: In keinem Fall lässt sich die MAC-Adresse [die physische (bei Einstellung "Aus") oder die private (bei Einstellung "Statisch/Fixiert")] aus der generierten IID herauslesen! Die MAC-Adresse fließt zwar in den Generierungs-Algortihmus der IID ein, jedoch nicht so, dass man sie anschließend aus der IID wieder herauslesen könnte (wie bei modified EUI64).

    Das iPad generiert pro IPv6-Präfix eine andere feste IID, mit aktiven ULA (fdXX:XXXX:XXXX::/64), der GUA des Providers (DG: 2a00:6020:PQWX:YZ00::/64 und dem linklokalen Präfix (LLA) fe80::/64 ergeben sich also 3 feste IPv6-Adressen mit unterschiedlichen IIDs:

    • GUA: 2a00:6020:PQWX:YZ00:[IID-1]
    • ULA: fdXX:XXXX:XXXX:0:[IID-2]
    • LLA: fe80::[IID-3]

    Nur für die GUA wird zusätzlich gemäß IPv6 privacy extensions eine temporäre GUA generiert:

    • GUA: 2a00:6020:PQWX:YZ00:[IID-temp]

    Wenn man also aus dem Internet einen Service auf dem Apple-Gerät erreichen möchte, so ist im vorgelagerten Router (hier: FRITZ!Box) eine IPv6-Freigabe für GUA: 2a00:6020:PQWX:YZ00:[IID-1] einzurichten.


    Apple-Gerät aus Sicht der FRITZ!Box:

    Eine FRITZ!Box (prinzipiell aber jeder Router) hat mit den nach RFC7217 generierten SLAAC-Adressen das prinzipielle Problem, anhand deren IID nicht erkennen zu können, welche von ihnen "stable", und welche "temporary" (aufgrund IPv6 privacy extensions) sind.

    Unter "Heimnetz | Netzwerk | [Gerät - Bearbeiten] | Heimnetz" listet sie die IPv6-Adressen des gewählten Geräts auf und qualifiziert diese mit den selbsterklärenden Attributen IPv6-GUA, IPv6-ULA, IPv6-LLA, IPv6-GUA-temporary, IPv6-ULA-temporary und IPv6-LLA-temporary (wobei letztere sinnfrei sind, denn es werden nach den Standards keine temporären linklokalen Adressen generiert).

    Diese Attribut-Zuordnung kann aber nur gesichert bestimmt werden, wenn die IPv6-Adressen mit dem modified EUI64-Verfahren generiert wurden, denn dann erkennt man stable IIDs daran, dass sie in der Mitte das Muster "ff:fe" aufweisen und darüber hinaus für GUA, ULA und LLA gleich sind. Jede von modified EUI64 abweichende IID (eine, die mittig nicht das Muster "ff:fe" aufweist) muss in diesem Fall folglich eine "temporary" Adresse sein. In dieser Konstellation ist auch das Feld "IPv6-Interface-ID" der FRITZ!Box für das betrachtete Gerät eindeutig als die IID mit dem Muster "ff:fe" in der Mitte bestimmbar - diese ID ist relevant, wenn man im Rahmen einer Freigabe das Gerät anhand dieser ID auswählt.

    Bei den nach RFC7217 generierten SLAAC-Adressen eines Apple-Geräts qualifiziert die FRITZ!Box nur die linklokale Adresse als "IPv6-LLA" und leitet aus deren IID den Wert der "IPv6-Interface-ID" ab. Alle anderen Adressen werden als "IPv6-GUA-temporary" oder "IPv6-ULA-temporary" qualifiziert.


    Als Anwender, der nun eine IPv6-Freigabe für das Gerät einrichten möchte, bedeutet das:

    1. Bei der Geräte-Auswahl im Freigabe-Dialog darf das Gerät nicht anhand der "IPv6-Interface-ID" ausgewählt werden - diese ist definitiv falsch, denn das würde eine Freigabe für die IPv6-Adresse GUA: 2a00:6020:PQWX:YZ00:[IID-3] (mit der IID der linklokalen Adresse) erzeugen, nicht jedoch für die GUA: 2a00:6020:PQWX:YZ00:[IID-1] (mit der stable IID der GUA), die hier benötigt wird.
    2. Der Anwender muss herausfinden, welche von den beiden DG-GUAs 2a00:6020:PQWX:YZ00:[IID-1] und 2a00:6020:PQWX:YZ00:[IID-temp] die stable Adresse ist.

    Um den Punkt 2 zu klären, habe ich am WAN-Port der FRITZ!Box einen Paketmitschnitt durchgeführt, während ich im Browser am iPad eine Website aufgerufen habe. Im Paketmitschnitt konnte ich dann sehen, welche der beiden GUAs das iPad dafür verwendet hat - das muss dann die temporäre GUA 2a00:6020:PQWX:YZ00:[IID-temp] sein, die nach dem Standard für die IPv6 privacy extensions für outbound Connections verwendet wird. Die andere (nicht verwendete) GUA ist folglich die gesuchte 2a00:6020:PQWX:YZ00:[IID-1], für die die IPv6-Freigabe einzurichten ist.

    Mit deren [IID-1] habe ich anschließend das Feld "IPv6-Interface-ID" manuell überschrieben, damit ich eine korrekte Freigabe erzeuge, wenn ich das Gerät im Freigabe-Dialog anhand ihrer "IPv6-Interface-ID" auswähle - alternativ kann man aber die IID der Freigabe-Adresse auch im Freigabe-Dialog manuell mit dem korrekten Wert [IID-1] überschreiben. Fun Fact: Wenn man die "IPv6-Interface-ID" manuell mit einer IID überschreibt, wird die zugehörige IPv6-GUA-temporary zu einer IPv6-GUA hochgestuft, während die IPv6-LLA, aus der die "IPv6-Interface-ID" zuvor abgeleitet wurde, zu einer IPv6-LLA-temporary herabgestuft wird (hierzu siehe meinen Kommentar weiter oben).


    DynDNS-Lösung:

    Nach all diesen Vorbemerkungen würde man nun noch DynDNS konfigurieren, indem mal beim DynDNS-Anbieter einen Host-Eintrag für das Apple-Gerät anhand deren fester [IID-1] generiert, und die FRITZ!Box dem DynDNS-Anbieter die ggf. wechselnden DG-GUA-Präfixe melden lässt.


    Abschließende Preisfrage:

    Wird man nach einem DG-Präfix-Wechsel aus dem Internet über den DynDNS-FQDN noch auf die Freigabe/das Apple-Gerät zugreifen können?


    Die frustrierende Antwort:

    Leider nein:

    In den Algorithmus gemäß RFC7217 zur Generierung einer IID fließt nämlich leider auch das LAN-Präfix ein, für das die IID generiert wird. Wenn sich das LAN-Präfix also ändert, ändert sich somit auch die dafür generierte IID.

    In der Folge muss in der FRITZ!Box der Wert für die "IPv6-Interface-ID" des Geräts bzw. die Freigabe für die geänderte IID angepasst werden. Beim DynDNS-Anbieter muss entsprechend der Host-Eintrag für das Gerät angepasst werden.


    Fazit:

    Die Generierung von "stable" Interface-IDs gemäß RFC7217 erweist sich für per SLAAC konfiguriere Endgeräte (Standard in privaten Heimnetzen) als kontraproduktiv für Freigaben, wenn das Netz providerseitig nicht mit festen IPv6-Präfixen versorgt wird.

    Einen Ausweg bietet in diesem Fall nur noch der Rückgriff auf modified EUI64 (sofern das Freigabe-Gerät dies ermöglicht), da eine damit generierte IID wirklich statisch ist und auch einen Präfixwechsel unbeschadet "überlebt".

    3 Mal editiert, zuletzt von ::1 (21. Juni 2025 um 11:58)

    Vielen Dank für diese Erörterung und Untersuchung von iOS Geräten. Zumindest für die Version 18.5.

    Die Einschränkung bezüglich SLAAC und RFC7217 gilt ja nicht nur für Äpfelchen, sondern für alle Devices, die modified EUI64 nicht unterstützen.

    Im Umkehrschluss dazu sollte jeder, der Dienste aus dem Internet zugänglich machen möchte, Geräte (NAS,...) verwenden, die auch für diesen Zweck herstellerseitig vorgesehen wurden. Alles andere ist nur mit Spezialkonfigurationen betreibbar, erhöht den Wartungsaufwand und ist ohne tiefes Verständnis nicht sicher und stabil betreibbar.

    Allerdings ist das kein IPv6-Problem, sondern mangelndes Bewusstsein für IPv6 auf der Seite der Hardwarehersteller. IPv6 wird IPv4 ablösen, genauso wie wir nicht mehr in einer Kutsche (im Regelfall) von A nach B fahren, sondern mit einem Kfz.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von HubeBube

    Im Umkehrschluss dazu sollte jeder, der Dienste aus dem Internet zugänglich machen möchte, Geräte (NAS,...) verwenden, die auch für diesen Zweck herstellerseitig vorgesehen wurden.

    Zitat von HubeBube

    Allerdings ist das kein IPv6-Problem, sondern mangelndes Bewusstsein für IPv6 auf der Seite der Hardwarehersteller.

    Dem kann ich voll und ganz zustimmen.

    Beispiel:

    Ich besitze ein NAS des Herstellers QNAP (TS-231P). Das letzte Firmware-Update auf "QTS 5.2.5.3145" enthielt bezüglich IPv6 die folgende wirklich grandiose Verschlimmbesserung:

    Das Gerät generiert bei IPv6-Konfiguration per SLAAC pro Präfix (ULA, GUA) keine festen/permanenten IIDs mehr, sondern nur noch temporäre gemäß IPv6 privacy extensions. Da ich das Gerät per Zeitsteuerung nachts herunterfahren lasse, weist es nach morgentlichem Aufwachen nun stets auch geänderte IIDs auf. Für ein vor allem als "Server" genutztes Gerät ist das wirklich sehr sinnig.

    Unmittelbar nach dem Update der Firmware poppte in dem NAS-GUI auch ein Hinweisfenster auf, dass man (sinngemäß) IPv6 als unsicher betrachte und man es deaktivieren möge.

    Für den IPv6-Zugriff aus dem LAN habe ich das NAS-Interface nun statisch mit einer ULA-Adresse versehen.