Beiträge von ::1

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.

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

Aus Erfahrung ist mir bekannt, dass IPsec-VPN mit CGNAT Probleme haben kann, obwohl es mittels NAT-Traversal (4500\udp) prinzipiell funktionieren sollte. Mit SSLvpn sieht es da besser aus, wenn man statt DTLS (UDP) besser TLS (TCP) verwendet. Das Problem sind vermutlich zu kurze UDP-Session-Dauern am CGNAT.

Am besten wäre aber eine VPN-Lösung, die über IPv6 tunnelt. Muss die VPN-Gegenstelle (hier Check Point) aber unterstützen - bzw. der Firmen-Admin muss es konfigurieren ...

Zitat von CruxTheFirst

Ich vermute mal, diese Mail der DG ist die typische "Ist in Arbeit" Mail bevor das Ticket geschlossen wird mit "kein Problem gefunden / liegt am Router des Kunden" ?

Das ist exakt derselbe Text, den ich zuletzt im Rahmen einer Mail an alle betroffenen Kunden wegen einer Störung (genauer "Update zur Störung in Ihrem Glasfasernetz") in meinem Anschlussgebiet erhalten habe (18.03.-19.03.2025). Also absolut gar nichts Individuelles, deinen spezifischen Fall betreffend.

Zitat von CruxTheFirst

meine WAN Adresse war bisher in 2a00:6020:1000:PQ::/112 (Mit PD-Block aus 2a00:6020:5000::/41)

Ok, dann befindest du dich am "Frankfurt-BNG-Cluster1" der DG. Der deckt die beiden folgenden /41-Blöcke ab:

1. 2a00:6020:5000::/41 mit WAN-Port-Adressen aus 2a00:6020:1000:40::/112 (BNG=2a00:6020:ffff:ffff::d)
2. 2a00:6020:5080::/41 mit WAN-Port-Adressen aus 2a00:6020:1000:41::/112 (BNG=2a00:6020:ffff:ffff::e)

Im ersten Block findet man für AS60294 der DG die RIPE Atlas-Probe 10214 (2a00:6020:5047:4300:a2f3:c1ff:fec4:5c01) und im zweiten Block die Probe 53040 (2a00:6020:509f:e00:1:90ff:fecf:b1a1).

Beide Probes sind "Connected" und senden/empfangen IPv6-Daten.

Scheint also zumindest kein BNG-weites Problem vorzuliegen - es beträfe somit nur einzelne Kundenanschlüsse in den genannten Ranges

Zitat von CruxTheFirst

keine IPv6 Adresse mehr (Eppertshausen/ Kreis Darmstadt-Dieburg)

Frage:

Lag die IPv6-Adresse deines Router-WAN-Ports bisher im IPv6-Range 2a00:6020:1000::/48 (in der Regel liegt die IPv6-Adresse dann genauer in einem /112-Block der Form: 2a00:6020:1000:PQ::/112, d.h. die WAN-Port-Adresse lautet 2a00:6020:1000:PQ::WXYZ)?

Falls nicht, dann liegt dein Anschluss vermutlich in einem der Bereiche, in dem DG offenbar eine neue/modifizierte IPv6-Adressierungssystematik einführt, und in denen es vermehrt zu IPv6-Problemen kommt, wie diverse Fälle hier im Forum zeigen.

Auffällig sind diesbezüglich laut meinen Beobachtungen bisher folgende IPv6-Ranges:

Liegt dein Anschluss in einem dieser Bereiche?

Zitat von UschiM

Selbst falls ich irgendwann eine IPv6-Adresse bekomme, ist es also möglich, dass ich trotzdem nicht von außerhalb auf meine Fritzbox zugreifen kann.

War das (in Bezug auf eine gemietete Fritzbox) eine Frage oder eine Feststellung?

Ehrlich gesagt weiß ich nicht, welchen Restriktionen ein Mietrouter unterliegt, sprich wie weit die Konfigurationsmöglichkeiten speziell für Zugriffe von außen ggf. eingeschränkt sind. Wenn DG hier Restriktionen durchsetzen wollte, müsste sie ja mit einem modifizierten FRITZ!OS-Image arbeiten, das glaube ich aber eher nicht. Ich denke, es wird hier lediglich TR-069 zur Fernkonfiguration genutzt.

Vielleicht gibt es hier im Forum diesbezüglich Kundige, die hierzu Licht ins Dunkel bringen können.

Zitat von UschiM

Habe auch schon überlegt, ob ich mir testweise eine Fritzbox bei der Dt. Glasfaser miete. Wenn IPv6 dann immer noch nicht läuft, habe ich auf jeden Fall bessere Karten beim Nachweis.

Ja. das sollte man meinem. Ich erinnere mich aber auch an einen anderen, ähnlich gelagerten Fall hier im Forum: Dort hat DG den Kunden trotz Mietrouter auch ohne IPv6 sitzen lassen.

Nachtrag: Siehe hier.

Zitat von pufferueberlauf

weil man anhand der MAC den Hersteller des NIC erkennen kann.

Ja, und?

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.

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

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

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.

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

Er muss seinem Mac beibringen, wie er Privacy Extensions im OS aktiviert. Andernfalls taucht das Zugriffsproblem erneut auf.

? Meintest du "deaktiviert" ? Aber wieso sollte er sich um Aktivierung/Deaktivierung bemühen? Aktuell sind sie wohl aktiviert. Er muss lediglich herausfinden, welche seiner Interface-Adressen die permanente ist: Er hat pro globalem Präfix eine permanente und bei aktiven privacy extensions zusätzlich eine temporäre Adresse - die temporäre ersetzt m.W. nicht die permanente (obwohl ich irgendwo im Hinterkopf habe, dass sich das künftig ändern soll - muss noch mal in den neuesten RFC dazu recherchieren - falls ja, und in MACOS schon so implementiert, hast du recht).

Zitat von HubeBube

Erreicht man bei MacOS das Deaktivieren der IPv6 Privacy Extension durch Änderungen der WiFi Einstellungen?

"IPv6-Privacy Extensions" und "Apple Private WLAN-Adressen" haben nicht miteinander zu tun. Letzteres ist ein proprietäres Apple-Feature (Infos siehe hier). Ich kannte das bisher auch nicht - ich hatte mich nur gewundert, dass das iPad meiner Frau in der Fritzbox alle paar Wochen verschwindet und als neues unbekanntes Gerät mit anderer MAC-Adresse wieder erscheint - bin dem seinerzeit nachgegangen und auf dieses Feature als Folge rollierender MAC-Adressen gestoßen.

Wenn du "private WLAN-Adressen" abgeschaltet hast, dann sollte dein MAC-Book nur eine einzige, dauerhafte MAC-Adresse aufweisen.

Aus der generiert das System pro zugewiesenem IPv6-Präfix (fe80::/64, 2a00:6020:4798:b100::/64, evtl. fd00::/64) nach einem Algorithmus auch eine feste/dauerhafte IPv6-Interface-ID. Die für 2a00:6020:4798:b100::/64 zugewiesene feste IPv6-Interface-ID ist für die Freigabe zu verwenden. Sie muss auch nach jedem Neustart dieselbe sein.

Daneben kann es bei aktivierten "IPv6 privacy extensions" für die globalen Präfixe (2a00:6020:4798:b100::/64 + evtl. fd00::/64) zusätzliche IPv6-Adressen geben, die temporäre Interface-IDs verwenden. Diese ändern sich von Zeit zu Zeit und dürfen nicht für Freigaben verwendet werden. Die Adresse, die du z.B. bei https://test-ipv6.com/ im Webbrowser am MAC-Book angezeigt bekommst, ist dessen temporäre Adresse.

Btw.: Du hättest 2a00:xxxx:4798:b100:: besser so maskiert: 2a00:6020:47YY:YY00::

Die YYYY sind individuell für deinen DG-Anschluss, xxxx=6020 ist hingegen allgemein bekannt für DG-Anschlüsse.

Zitat von ZimmerZoltan

Jetzt die Frage. Da das Rotieren der Adresse am Mac deaktiviert ist, sollte die Interface ID immer gleich bleiben. Wenn ich jetzt DynDNS verwende, sollte ich mir doch einen permanenten Link aufbauen können oder

Ja, dann hast du mit der dritten von den Vieren offenbar die permanente erwischt. Deine Frage ist mit "Ja" zu beantworten, sofern deine DynDNS-Lösung auch wirklich diese Adresse deines MAC-Books (und nicht etwa die IPv6-Adresse vom WAN-Port des Routers) beim DnyDNS-Provider registriert.