Derzeit habe ich noch eine Interface IP aus dem 2a00:6020:1000:41:: Block und quasi-statische IPv6.
Da müsstest du so im PLZ-Gebiet 66xxx/67xxx (SL/RP) liegen (IPv6-Range 2a00:6020:5080::/41) - ich habe noch nicht gesehen, dass dort auf das "neue" Adresskonzept umgestellt wird.
Korrektur:
In SL gibt es tatsächlich eine RIPE-Atlas-Probe (#29306), die an einem DG-Anschluss mit "neuem" Adresskonzept hängt (IPv6-Range 2a00:6020:5380::/41).
Die Gegenstelle sendet NS und und NA
Ist denn in den NA der Gegenstelle das R-Flag gesetzt? Ich vermute mal, nein. Denn andernfalls hätte die Unify-Selbst-Konstruktion der Gateway-Adresse evtl. funktioniert.
Die default route kam trotzdem per RA
Wieso "trotzdem"? In Verbindung mit DHCPv6 (das im Gegensatz zu DHCPv4 keine "Gateway-Option" kennt), muss die Default-Route immer aus RA gelernt werden. Wenn die Gegenstelle keine sendet (=> Problem liegt auf DG-Seite), dann hast du eben kein Default-Gateway.
Sendet die Gegenstelle denn NS und antwortet sie mit NA auf die von deinem Router gesendeten NS?
Man könnte zur Grobmessung der Bandbreite der LAN-Verbindung zwischen PC und Fritzbox eine iperf-Messung durchführen:
In meinem Fall (Fritzbox 5590) mit Gigabit-Ethernet zu meinem LAN-Windows-PC erhalte ich folgendes Ergebnis:
D:\Downloads\Software\Tools\IPerf\V.2.2.1>iperf -c fritz.box -p 4711
------------------------------------------------------------
Client connecting to fritz.box, TCP port 4711
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.178.10 port 63404 connected with 192.168.178.1 port 4711
[ ID] Interval Transfer Bandwidth
[ 1] 0.00-10.02 sec 1.06 GBytes 912 Mbits/secDer Wert unter "Bandwidth" sollte nicht deutlich kleiner als 1000 Mbit/s sein.
Vielleicht klappt es mit der automatischen Geschwindigkeitsaushandlung zwischen LAN-Adapter des PC und dem LAN3-Port der FB nicht so recht. Deshalb in den Treiber-Einstellungen des LAN-Adapters versuchsweise mal von "Automatisch" auf "1 GBit/s full duplex" umstellen.
Nur Clients, die DNSSEC validierende DNS-Server in ihrer Konfiguration (üblicherweise im Router) hatten sind auf die Probleme gestoßen.
Zumindest wurde somit offenbar, dass die dynamisch von der DG zugewiesen DNS-Server (richtiger ist eigentlich der Begriff "DNS-Resolver") dnscache001.dg-w.de (185.22.44.50, 2a00:6020:100::1) und dnscache002.dg-w.de (185.22.44.50, 2a00:6020:200::1) validierende Resolver sind (was ja sehr gut ist). Denn mit diesen hatte ich das Problem gestern auch (aber erst, nachdem "de"-Einträge in deren Cache nach TTL-Ablauf gelöscht wurden), mit meinem lokal am Client installierten und für die DNS-Auflösung benutzten validierenden Resolver "unbound" bemerkte ich das Problem hingegen früher.
Hier der Erklärbar von Heise per Video.
Versuche es in den IPv6-Einstellungen mal mit der Konfiguration "Native IPv4-Anbindung verwenden" - das ist die empfohlene Einstellung an einem DG-Anschluss (ändert nur die Reihenfolge: erst IPv4 via DHCP, dann IPv6 via DHCPv6 - so gefällt es DG besser, andersherum dauert es erfahrungsgemäß deutlich länger).
Aber ja: Die DHCP-/DHCPv6-Fehlermeldungen deuten klar auf eine Fehlersituation bei der DG hin, sofern du deinerseits zuvor nichts geändert hast.
Alles anzeigenHeute neue Anweisung von Deutsche Glasfaser bekommen und direkt ausprobiert:
Öffnen Sie die Benutzeroberfläche, indem Sie http://fritz.box in Ihrem Browser eingeben.
Melden Sie sich mit Ihrem FRITZ!Box-Passwort an.
Gehen Sie zu Internet → Zugangsdaten → IPv6.
Aktivieren Sie IPv6:Setzen Sie ein Häkchen bei „IPv6-Unterstützung aktiv“
Wählen Sie „Native IPv6-Anbindung verwenden“
Falls dies nicht angezeigt wird, wählen Sie „IPv6-Anbindung über Tunnelprotokoll“ (z.?B. 6to4)
Klicken Sie anschließend auf Übernehmen.
Das ist also eine Anweisung der "Deutsche Glasfaser" - die sollte eigentlich wissen, dass keine der Tunnel-Lösungen an ihrem Anschluss funktionieren würde:
Mit scheint, der Service-Mitarbeiter der DG hat hier eine KI-Antwort einfach ohne irgendeinen Funken von Verständnis an seinen Kunden weitergegeben - schöne neue Welt.
aber hab deinen Text in chatGPT reingeworfen plus meine "ip a" Ausgabe
Na, dann hoffe ich mal, dass das, was immer du als Ergebnis der KI-Aktion irgendwo konfiguriert hast, auch von Dauer ist.
Ehrlich gesagt: Mich gruselt es vor einer Zukunft, in der Menschen auf Basis irgendwelcher KI-Ergebnisse, die sie nicht verstanden haben, irgendetwas produzieren, das sie genauso wenig verstehen, geschweige denn in der Lage wären, Fehler, die dieses KI-generierte Produkt seinerseits produziert, mangels Wissen bzw. Verständnis zu analysieren und zu beheben.
Eine Fritzbox richtet eine Freigabe anhand dessen ein, was sie als sog. "IPv6-Interface-ID" des freizugebenden Gerätes (falls man es anhand seines Gerätenamens auswählt) interpretiert. Seitdem man aus Gründen vermeintlicher Privacy jedoch seitens der Geräte zunehmend die Verwendung von aus einer festen Geräte-MAC-Adresse abgeleiteten "Modified EUI64" als IPv6-Interface-ID vermeidet (erkennbar an der Zeichenkette "ff:fe" in deren Mitte), ist für die Fritzbox leider nicht mehr klar, welche der mehreren Interface-IDs die richtige ist.
Korrekt wäre die "IPv6-GUA", aber leider kann das bei fehlender "ff:fe"-Zeichenkette auch der Identifier sein, den die Fritzbox als "IPv6-GUA-Temporary" führt.
Man muss deshalb am freizugebenden Gerät selbst ermitteln, was deren permanente globale IPv6-Adresse ist und deren Interface-ID (die hinteren 64 Bits) manuell in der Fritzbox in der Heimnetz-Konfiguration des Gerätes als deren IPv6-Interface-ID eintragen (d.h. überschreiben, falls abweichend).
Sodann muss man noch hoffen, dass das Gerät es mit der Privacy nicht auf die Spitze treibt und auch noch in bestimmten Zeitabständen und/oder nach Neustarts ihre MAC-Adresse und somit ihre "permanente" IPv6-Interface-ID ständig ändert. Das wäre "der Tod" jeder Freigabe in einem vorgelagerten Internet-Router, denn die lebt davon, dass sich zumindest die "IPv6-Interface-ID" des freizugebenden Gerätes niemals ändert.
Falls das Ziel direkt mit der IPv6-Adresse angesprochen wird, darauf achten, dass die Adresse in [] gesetzt werden muss:
http://[2a00:...]:12947
Zur DHCPv6-Leasedauer:
An meinem DG-Anschluss (nach "altem" Adress-Standard) zeigt ein Paketmitschnitt den folgenden Inhalt einer DHCPv6-Reply-Message:
DHCPv6
Message type: Reply (7)
Transaction ID: 0x1855ea
Client Identifier
Server Identifier
Identity Association for Non-temporary Address
Option: Identity Association for Non-temporary Address (3)
Length: 40
IAID: 553eb839
T1: 1800 <--
T2: 2880 <--
IA Address
Option: IA Address (5)
Length: 24
IPv6 address: 2a00:6020:1000:██::████
Preferred lifetime: 3600 <--
Valid lifetime: 3600 <--
DNS recursive name server
Identity Association for Prefix Delegation
Option: Identity Association for Prefix Delegation (25)
Length: 41
IAID: 553eb839
T1: 1800 <--
T2: 2880 <--
IA Prefix
Option: IA Prefix (26)
Length: 25
Preferred lifetime: 3600 <--
Valid lifetime: 3600 <--
Prefix length: 56 <--
Prefix address: 2a00:6020:4███:██00::Sowohl für die WAN-Port-Adresse des Routers (IA_NA) als auch für den LAN-PD-Block (IA_PD) gilt:
Leasedauer = "Preferred lifetime" = "Valid lifetime" = 3600s.
Laut DHCPv6-Standard ergeben sich daraus die folgenden Werte für den ...
Die IA_PD "Prefix length" beträgt standardmäßig /56
Zur Erinnerung:
Um zu verhindern, dass die Leasedauer abläuft und die IPv6-Adressen damit ungültig werden, sendet der Router rechtzeitig (nach Ablauf von T1) einen DHCPv6-Renew-Request, der vom DHCPv6-Server (der die Lease zugeteilt hat - wie unter "Server Identifier" angegeben) üblicherweise mit einem DHCPv6-Reply beantwortet wird. Das setzt die Leasedauer wieder auf den Maximalwert.
Erhält der Router keine Antwort, so sendet er nach Ablauf von T2 einen DHCPv6-Rebind-Request, der sich diesmal jedoch unspezifisch an alle erreichbaren DHCPv6-Server richtet (sofern es mehrere gibt), in der Hoffnung, dass evtl. ein anderer DHCPv6-Server die Lease verlängert (habe ich in Paketmitschnitten am DG-Anschluss auch schon gesehen).
Erst wenn auch ein DHCPv6-Rebind-Request unbeantwortet bleibt, läuft die Leasedauer ab, und der Router verliert seine IPv6-Adressen. Er startet anschließend einen neuen DHCPv6-Exchange - aber es kommt bis zum Erhalt neuer Adressen zu einer Netzunterbrechung.
Eine kurze Leasedauer von 600s skaliert entsprechend auch T1 (300s) und T2 (480s) nach unten. Es läuft dann im Vergleich zum Standardfall eben alles 6-fach öfter.
----------------------------------------------------------------------------------
Warum DG an neueren Anschlüssen die Leasedauer so signifikant absenkt und auch nur noch einen LAN-PD-Block der Größe /64 spendiert, erscheint mir rätselhaft. Auch die quasi-permanente Adresszuweisung scheint hier wegzufallen, alle paar Tage werden geänderte Adressen zugewiesen.
Ich habe gerade festgestellt das meine Leitung von ehemals 1000/500 MBit zu 50/25 Mbit.
Das liegt am relativistischen Effekt der Zeit-Dilatation im Wurmloch. 
Also habe ich gerade Schrödingers Internetanschluss. Keine Ahnung wie, von wem und warum aber irgendwie (noch) da.
Der Transitionsprozess ist vermutlich in einem Wurmloch stecken geblieben. Jetzt sind beide Zugängen auf ewig miteinander verschränkt.
Für die noch ausstehende Beseitigung des 2. Problems (de. --- missing AAAA glue ---> nshost2.de.) gäbe es noch einen Extra-Applaus:
Leider besteht das Problem immer noch ...
Ich will jetzt nicht belehrend wirken, aber einige Punkte deiner Darstellung sind nicht so ganz eindeutig oder ein Fehler:
3. Gateway fe80::22 (MAC: 20:00:10:38:40:93) leitet KEINE Pakete weiter
Kann sein (in ausgehender Richtung zum Internet). Möglich ist aber auch, dass das Gateway deine ausgehenden Daten zum Internet-Ziel weiterleitet, aber die Antworten vom jeweiligen Internet-Server zwar bis zum AS60294 der DG zurück gelangen, im Netz der DG aber nicht zu deinem BNG/Anschluss zurück geroutet werden.
5. Ständige Neighbor Solicitation-Wiederholungen
Das ist kein Fehler.
Das Gateway antwortet auf Neighbor Discovery, aber routet keine Pakete.
Dies ist ein BNG/ONT-Konfigurationsproblem, NICHT ein Router-Problem.
wie oben (5.) Es ist vermutlich auch kein BNG/ONT-Problem, sondern ein (Rückwärts-)Routing-Problem innerhalb des DG-Netzes (aus deiner Sicht "hinter" dem BNG)
Nachtrag:
Insbesondere wäre auch der /64 als PD-LAN-Präfix zu monieren (sollte doch wohl ein /56 sein), und die extrem kurzen Leasedauern von nur 10min für WAN-IPv4 und WAN-IPv6/PD-LAN - das ist nicht normal.
sh0rty :
Habe deinen Paketmitschnitt angeschaut.
Ergebnisse:
Ansonsten sehr ungewöhnlich:
Du bekommst für's LAN nur einen PD-Block der Größe /64 - üblich wäre ein /56. Auch sind die Leasedauern für WAN-Adresse und LAN-Präfix mit 600s (10min) extrem kurz, so dass sie alle paar (5) Minuten per DHPv6-Renew erneuert werden müssen.
DHCPv6-Verlauf und RS/RA (Router lifetime = 4500s, M-Flag gesetzt) sind soweit normal, da gäbe es nichts zu beanstanden - allenfalls, dass das erste (und im Mitschnitt einzige) RA erst nach 16s zu sehen ist, nachdem dein Router 4 RS im Abstand von 4s gesendet hat.
Nachtrag:
Das heißt das sollte am Glasfaseranschluss meiner Eltern dann normalerweise das gleiche Verhalten auftreten sonst kann es da schon Probleme geben, wenn ich das richtig verstanden habe.
Exakt! Weil, wenn das dort nicht funktioniert, dann kann es auch mit dem VPN-Aufbau nicht klappen.
Seid ihr hier nicht ein wenig auf dem Holzweg?
Wenn über die Fritze nur die VPN-Verbindung sporadisch nicht aufgebaut werden kann, man ansonsten aber auf das Internet zugreifen kann - dann sollte bei der D.Giga doch die WAN-MAC-Adresse der Fritze bekannt und akzeptiert sein (sofern diese überhaupt erforderlich ist), denn andernfalls wäre die direkte Internetnutzung doch auch nicht möglich.
Wie ist denn in der Windows-Konfiguration der VPN-Verbindung der Peer-Server in der Firma angegeben: Als Domain-Name oder als IP-Adresse?
Wenn die VPN-Verbindung nicht aufgebaut werden kann:
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
