LOOP:
Ich glaube, dein IPv6 Präfix wird bei DG ungültig, während es deinem Anschiuss noch zugeordnet ist (Eyeball-Test: nur IPv4). Dann weist dir DG einen neuen IPv6-Präfix zu (man sollte eigentlich immer denselben bekommen, das ist nicht normal), der eine Weile funktioniert (Eyeball-Test: auch IPv6), bis das Spiel wieder von vorne beginnt.
GOTO LOOP
Das koennte eine IPv6/Happy Eyeballs Problem sein
Dafür gäbe es einen Test unter http://he.test-ipv6.com/
Zur Info und passend zum Thema:
Es ist soeben RFC9797 erschienen: "Randomized and Changing Media Access Control (MAC) Addresses: Context, Network Impacts, and Use Cases". Es behandelt unter dem Kürzel RCM (Randomized and Changing MAC addresses) das, was hier im Thread in Apple's Implementierung als "Private WLAN-Adressen" referenziert wurde und dessen Charakteristika vermutlich durch Appendix A3 des RFC abgedeckt sind.
Insbesondere behandelt Chapter 6 in Bezug auf Network Services die damit einher gehenden Probleme ("loss of device identification" bei Wechsel der MAC-Adresse).
Es geht in dem RFC allerdings _nicht_ um IPv6-Interface-IDs (IID) - bezügliche RFC (RFC7217 und RFC8981) werden zwar als Informative References benannt, im RFC-Text jedoch in einem Kontext zitiert, der nichts mit dem in diesem Thread behandelten Problem zu tun hat, nämlich dass ein stable IID laut RFC7217 vom LAN-Präfix abhängt, für das er generiert wird.
Oder anders formuliert:
RCM verschärfen das Problem mit daraus abgeleiteten stable IPv6 IIDs zwar, die Abschaltung von RCM (aka "Private WMAN-Adressen" bei Apple) löst es allein aber nicht, da es zusätzlich durch die Abhängigkeit des Generierungs-Algorithmus von stable IIDs vom LAN-Präfix (mit-) verursacht wird.
Nach meinem Verständnis wird doch aber beim Einsatz von Splittern massiv überbucht. Bei einem 1:32 Split bleiben von 2,5 Gbit Downstream gerade mal 80 MBit pro Teilnehmer. Das ist natürlich Worst-Case gerechnet und nicht alle Kunden nutzen die "großen" Tarife. Aber im Prinzip reichen doch schon 3-4 Nutzer mit 1Gbit-Tarif damit nicht jeder seine Anschlussleistung erhält oder habe ich da einen Denkfehler?
Genau zu diesem Ergebnis bin ich ebenfalls gekommen, als ich mich erstmals mit GPON befasst habe und irritiert war, zu diesem vermeintlichen "Denkfehler" im Web wenig bis gar nichts Konkretes zu finden. In der Praxis scheint es bisher offenbar so gut wie nie vorzukommen, dass die Summe der gleichzeitig von allen Anschlüssen am selben Splitter genutzten Bandbreite über einen längeren Zeitraum die Maximalbandbreite vollständig ausnutzen würde.
Zusätzlich kommt dazu, dass man bei Glasfaser den Split recht einfach verkleinern kann, dazu muss im Pop nur ein Teil der Fasern auf eine andere "Backbone-Faser" verbunden werden. Fasern dafür dürfte es noch überzählige geben, wenn nicht zieht man eine neue Leitung mit mehr Fasern ein.
Beste Antwort! Das habe ich mir seinerzeit auch gedacht. Fragt sich nur, ob der Provider das aus freien Stücken macht, wenn sein Monitoring ihm signalisiert, dass die mittlere genutzte Gesamtbandbreite am Splitter bestimmte obere Limits überschreitet.
Bei wechselndem Präfix wird eh neu nummeriert, was für einen Unterschied macht es da, wenn der Interface-Identifier dann sich auch ändert?
Host-Einträge anhand der Interface-ID bei einem DynDNS-Anbieter und IPv6-Freigaben in der Fritzbox müssen bei Präfixwechsel nicht angepasst werden, wenn der Interface-Identifier dabei konstant bleibt. Andernfalls muss man leider beides anpassen.
Na ja, ich meint den Austausch des Prefixes per NAT, fuer mich ist das ein Spezialfall von generellem NAPT. Und nein diese Form von NAT66 ist nichts was die IETF sehen moechte, IMHO ist das eine Konsequenz daraus, dass die IETF seit Jahren einige (ihr selbst) offensichtliche IPv6 Probleme nicht ordentlich geloest hat (Hotfail zwischen verschiedenen IPv6 Uplinks, bei denen die IPv6 Routen eines ploetzlich verschwundenen Links noch lange in den Endpunkten aktiv bleiben und genutzt werden was zu Konnektibvitaetsproblemen fuehrt, NAT66 ist da eine echte Loesung wenn auch weder elegant noch im Geiste von IPv6).
Du meinst hier vermutlich "IPv6 Multihoming"- das ist ja auch bei IPv4 ein Problem, mit dem Unterschied, dass NAT als Lösungsoption dort akzeptiert ist. Bei IPv6 gibt's wohl nat-freie Lösungsansätze, siehe z.B. RFC7157, habe mich damit aber noch nicht befasst, um hierzu wirklich etwas sagen zu können. Ich kenne hier nur die Mercedes-Lösung mit provider-unabhängigem IPv4/IPv6-Space in Verbindung mit BGP - aber das ist natürlich nichts für das KMU-Umfeld.
Auch hier Jain...ich bin da mehr ein ein Fan von https://datatracker.ietf.org/doc/id/draft-c…ntifiers-02.txt RFC7217 und Modified EUI-64 sind IMHO beide fuer Heimnetze nicht gut geeignet.
Ah, danke. Jetzt weiß ich auch endlich, was du vormals mit "Tokenised Identifiers" meintest - den Draft kannte ich noch nicht. Stimme zu, wäre eine gute Lösung. Vielleicht wird daraus ja noch ein RFC ...
Das ist fuer den Fall um den es hier geht ein "stabiles" Netz mit haeufig wechselndem Prefix halt nicht die richtige Loesung... die Grundannahme ist, wenn das Prefix wechselt, wechselt das Netz und das macht in Heimnetzen halt fier Serverdienste nur wenig Sinn.
Das sehe ich auch so.
Was die IETF damit foerdert ist dass Endnutzer GUAs ignorieren, lokal mit stabilen ULAs arbeiten und diese dann mit NET66 mit dem jeweils aktivem Prefix versehen... Aber gerade bei den IPv6 RFC sehe schon mal Bike-Shedding und versuch Nutzer umzuerziehen.
Das sehe ich nicht so. Ich unterstelle der IETF keine (durch welche Zielvorstellungen auch immer begründete) Agenda, mit der sie "Nutzer umerziehen" will. Schon gar nicht die Idee, ULA am CPE-Router via NPTv6 (RFC6296, falls du das mit "NET66" gemeint hast) auf GUA zu übersetzen. Btw.: Die Bedeutung des mir bisher unbekannten Begriffs "Bike-Shedding" musste ich erst mal nachlesen, danke für das Schließen dieser meiner Bildungslücke.
Ich sehe die Summe aller RFC als riesigen Baustein-Kasten, aus dem man sich bedienen kann, um für die Anwendung sinnvolle und standardisierte Lösungen zu bauen. Es liegt, wie auch schon von HubeBube festgestellt, also vor allem an den Implementierern von IPv6 in die jeweiligen Betriebssysteme, um für ein darunter betriebenes System/Gerät sinnvolle Konfigurationsoptionen zu ermöglichen.
Bezüglich IPv6-Konfiguration per SLAAC sollte es für den Nutzer eines Gerätes also idealerweise folgende Einstell-Möglichkeiten geben, weil nur der Nutzer (bzw. dessen Netz-Admin) am besten weiß, wofür er das Gerät benutzen will:
Die Motivation, Serverdienste in SOHO-Netzen an ISP-Privatanschlüssen möglichst zu unterbinden, liegt eher bei den ISP. Denn die möchten dafür gerne ihre deutlich höherpreisigen Business-Tarife mit festem IPv6-Präfix verkaufen.
Schließlich noch zu "lokal mit stabilen ULAs arbeiten": Das nutze ich zusätzlich in meinem LAN seit eh und je, ist doch sehr sinnvoll, sich für die rein LAN-interne Kommunikation wenigsten darauf verlassen zu können, wenn der ISP mal wieder den GUA-Präfix wechselt oder ggf. auch mal gar keinen liefert (das soll bei DG ja ab und zu mal vorkommen).
welchen Grund sollte es geben diese Requests abzublocken?
Vielleicht blocken sie alle DUID-types (also 2 und 4), die _nicht_ die Link-Layer address enthalten. Evtl. weil sie auf Basis der DUID-types 1 und 3 und der darin enthaltenen Link-Layer address künftig ihre Sperr-Logik für MAC-Adressen am Kundenanschluss realisieren wollen,
Persoenlich bin ich kein Fan von RFC7217 zumindest nicht im Kontext von Heimnetzwerken mit haeufigem Prefix-Wechsel, aber vielleicht ist mir nur nicht klar welches Bedrohungsmodell dem RFC zugrunde liegt.
Nunja, das bescheibt die "Introduction" von RFC7217 doch ziemlich ausführlich:
Wichtigste Passage daraus:
In scenarios in which temporary addresses are deliberately not used
(possibly for any of the aforementioned reasons), all a host is left
with is the stable addresses that have typically been generated from
the underlying hardware addresses. In such scenarios, it may still
be desirable to have addresses that mitigate address-scanning attacks
and that, at the very least, do not reveal the host's identity when
roaming from one network to another -- without complicating the
operation of the corresponding networks.Sinngemaß: Dort, wo man IPv6 privacy extensions bei einer Konfiguration mit SLAAC aus vorgenannten Gründen nicht nutzen möchte, will man nun halt ersatzweise die Privacy von "stable addresses" verbessern bzw. "address-scanning attacks" erschweren.
Aber auch, wenn IPv6 privacy extensions weiterhin verwendet werden, sieht man folgenden Verbesserungsbedarf für die parallel vorhandenen "stable addresses":
However, even with temporary addresses in place, a number of issues
remain to be mitigated. Namely,
o since temporary addresses [RFC4941] do not eliminate the use of
fixed identifiers for server-like functions, they only partially
mitigate host-tracking and activity correlation across networks
(see [ADDR-GEN-PRIVACY] for some example attacks that are still
possible with temporary addresses).
o since temporary addresses [RFC4941] do not replace the traditional
SLAAC addresses, an attacker can still leverage patterns in SLAAC
addresses to greatly reduce the search space for "alive" nodes
[GONT-DEEPSEC2011] [CPNI-IPV6] [IPV6-RECON].
Hence, there is a motivation to improve the properties of "stable"
addresses regardless of whether or not temporary addresses are
employed.Hä? Tieferer Sinn?
Tja, ich habe auch nur gestaunt. Leider kann ich den Hinweistext des Popups in den NAS-Logs nicht mehr finden, um den genauen Wortlaut wiederzugeben. In den Release Notes der Firmware heißt es zu den IPv6-Änderungen - Zitat:
Network & Virtual Switch
Die Erwähnung eines "secret key" deute ich als Hinweis, dass man die Generierung von IPv6-IIDs für temporary addresses (privacy extensions) RFC8981 implementiert hat. Einen nahezu identischen Algorithmus mit einem "secret key" enthält auch RFC7217 für die Generierung von stable IIDs, aber das hat man offenbar nicht gemeint bzw. implementiert.
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.
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:
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:
Nur für die GUA wird zusätzlich gemäß IPv6 privacy extensions eine temporäre GUA generiert:
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:
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 ...
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.
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:
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
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:
| # | PD-Block (/56) Kunden-Anschluss aus: | WAN-Port-Adresse aus: |
|---|---|---|
| 1. | 2a00:6020:7380::/41 (2a00:6020:7380:100::/56 - 2a00:6020:73ff:ff00::/56) | 2a00:6020:7380::/112 (2a00:6020:7380::WXYZ) |
| 2. | 2a00:6020:7680::/41 (2a00:6020:7680:100::/56 - 2a00:6020:76ff:ff00::/56) | 2a00:6020:7680::/112 (2a00:6020:7680::WXYZ) |
| 3. | 2a00:6020:7800::/41 (2a00:6020:7800:100::/56 - 2a00:6020:787f:ff00::/56) | 2a00:6020:7800::/112 (2a00:6020:7800::WXYZ) |
| 4. | 2a00:6020:7880::/41 (2a00:6020:7880:100::/56 - 2a00:6020:78ff:ff00::/56) | 2a00:6020:7880::/112 (2a00:6020:7880::WXYZ) |
| 5. | 2a00:6020:8f00::/41 (2a00:6020:8f00:100::/56 - 2a00:6020:8f7f:ff00::/56) | 2a00:6020:8f00::/112 (2a00:6020:8f00::WXYZ) |
Liegt dein Anschluss in einem dieser Bereiche?
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.
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.
weil man anhand der MAC den Hersteller des NIC erkennen kann.
Ja, und?
Wähle aus, welche Kategorien Du erlaubst. Für jede Kategorie kannst Du über „Details anzeigen“ sehen, welche Cookies und Skripte konkret geladen werden, welche Empfänger beteiligt sind und wie lange gespeichert wird.
Weitere Informationen: Datenschutzerklärung · Impressum
