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:
Wobei die Nutzbarkeit via IPv4 zwar grundsätzlich gegeben, aber nicht vollkommen unberührt ist, wenn Du eine IPv6 Adresse zugeteilt bekommst, der Traffic aber nicht läuft. Ich kann mich speziell daran erinnern, dass vom Start des Mailclients, bis zum "Handshake" mit dem Server doch eine spürbar lange Zeit verging, bis man sich einig wurde. Ein Phänomen, welches bei funktionierendem IPv6 (oder eben NUR IPv4) nicht vorhanden ist.
Ja klar, Stichwort "Happy Eyeballs" (RFC6555) - deshalb solltest du IPv6 im LAN deaktivieren (z.B. das Senden von IPv6-RA im Router abschalten, so dass die LAN-Clients keine globalen IPv6-Adressen per SLAAC autokonfigurieren können), solange IPv6 DG-seitig nicht funktioniert.
also IPV6 unterstützt der VPN Client definitiv.
Und der VPN-Server in der Firma auch?
IKEv2 bzw. besser gesagt IPsec ist so eine Sache, wenn die IPsec-Verbindung mit IPv4 über einen Internet-Provider erfolgt, der ein CGNAT betreibt. In diesem Fall greift der "NAT-Traversal"-Mechanismus, d.h. die ESP-Pakete der IPsec-Verbindung werden zusätzlich in UDP verpackt und am CGNAT-Router des Providers muss dazu eine UDP-NAT-Session am Leben erhalten werden. Gelingt das nicht (zu großer Zeitabstand zwischen Keepalive-Packets/oder kein Senden von Keepalives versus UDP-Session-Timeout am CGNAT-Router), bricht die IPsec-Verbindung weg.
Deshalb wäre es besser, sofern der IPsec-Peer in der Firma IPv6 unterstützt, den IPsec-Client (was ist denn das für einer?) so zu konfigurieren, dass er bevorzugt die Verbindung zum Firmen-Peer per IPv6 aufbaut - dort gibt es die NAT-Problematik nicht und ESP-Pakete können direkt in IPv6 enkapsuliert werden.
SSLvpn statt IPsec wäre eine Alternative, die mit IPv4/CGNAT besser klar kommt (ggf. Verwendung von TLS statt DTLS).
Allerdings muss ich zugestehen, dass es merkwürdig ist, dass das Log des Firmen-Peers noch nicht mal den initialen Request des Clients anzeigt, denn der sollte dennoch sichtbar sein.
