Deutsche Glasfaser IPv6 Routing Problem

Dein LAN-Präfix scheint 2a00:6020:9842:1000::/56 zu sein?
Oder wurde dir, wie in einem anderen Problemfall, von DG nur ein LAN-Präfix der Größe /64 (konkret: 2a00:6020:9842:1002::/64) zugewiesen?

Es sieht so aus, als würde dein LAN-Präfix seitens DG aktuell nicht zu dem BNG-Cluster (der für 2a00:6020:9800::/41 zuständig ist) geroutet, an dem dein Anschluss hängt. Der Range 2a00:6020:9800::/112, in dem sich die WAN-Adressen der Kunden-Anschlüsse befinden (bei dir: 2a00:6020:9800::26d) scheint hingegen korrekt geroutet zu werden.

Das könnte man evtl. verifizieren, indem du die Firewall deines OPNsense für ICMPv6-Echo zu einem LAN-Gerät deiner Wahl öffnest und das WAN-Interface deines OPNsense so konfigurierst, dass es eine ICMPv6-Fehlermeldung für "Time exceeded" sendet, wenn es ICMPv6-Pakete verwirft, die es wegen ablaufendem Hop-Count nicht ins LAN weiterleiten kann. Dann müsste dein Router bei funktionierendem IPv6 in Traceroutes von außen (z.B. von hier) zur IPv6-Adresse deines LAN-Gerätes auftauchen.

Wenn dein Router in dieses Traceroutes hingegen nicht auftaucht, wäre das m.E. ein Beleg für meine Vermutung.

Ok, du bekommst einen /56 als LAN-Präfix - so sollte es sein.

Und es scheint so zu sein, dass du mit jedem Reconnect eine neue Kombination von LAN-Präfix (jetzt: 2a00:6020:9842:f00::/56) und WAN-Adresse (jetzt 2a00:6020:9800::26c) bekommst - ob das auf einen Fehler hindeutet (bei Anschlüssen nach altem Adresskonzept bekommt man nach Reconnects i.d.R. stets dieselben IPv6-Adressen), oder ob das Bestandteil eben dieses neuen Konzepts ist (das vermute ich, siehe dieser DG-Anschluss mit RIPE-Atlas-Probe, für den auch das neue Konzept gilt), vermag ich nicht zu sagen.

Zitat von themaze

Ich habe gerade eben einen Freund der im gleiche Ort mit dem gleichen DG Ausbautrupp angeschlossen wurde, gefragt, ob er mir einen Traceroute von seinem Rechner schicken kann. Sein PC zeigt das gleiche Ergebnis. fc00::1 als 2. Hop und dann nichts.

Das heißt. der Freund hat das gleiche Problem wie du? Oder kann er nur deine Adressen nicht erreichen, IPv6-Ziele im Internet aber schon?

Ich kann von meinem DG-Anschluss deine WAN-Adresse (2a00:6020:9800::26c) aktuell auch nicht pingen, normalerweise erreicht man andere DG-Kundenanschlüsse. Aber möglicherweise ist diese Adresse ja schon nicht mehr aktuell.

Viel schlauer werde ich durch deine gezeigten Ergebnisse nicht.

Vielleicht (nur zur Kontrolle) noch folgende Frage: Du hast ja schon diverse Paketmitschnitte am WAN-Port gemacht. Siehst du dort in regelmäßigen Zeitabständen (default so alle 10 Min) sog. Router-Advertisments, die die DG-Gegenstelle sendet (Suchfilter in Wireshark: icmpv6.type==134). Falls ja, zeig mal den ICMPv6-Inhalt eines RA.

Zitat von themaze

Ich habe seit der Anschluss besteht (Ende Oktober), immer eine neue Adresse bekommen wenn ich mich neu verbinde. Das veränderte verhalten ist jetzt, dass ich nicht bei jedem Reconnect eine neue Adresse bekomme, sondern nur wenn dieser ein paar Stunden her ist.

Danke für die Klarstellung - mit dem neuen Konzept wirft DG also die "quasistatischen" IPv6-Adressen über Bord, vermeintlich zugunsten von Privacy.

Frage: Führt DG jetzt auch in gewissen Zeitabständen Zwangstrennungen durch, um dir neue IPv6-Adressen zu verpassen?

Zitat von themaze

Zu erwähnen ist dass mein Router ein DCHPv6-Release zu den Adressen schickt bevor er sie erneut Anfragt.

So sollte es sein.

Zitat von themaze

Habe gerade einen Mitschnitt gemacht, hier eine RA der Gegenstelle:

Das sieht alles gut aus. Wichtig sind das gesetzte M-Flag und eine Router lifetime >0. Der Wert 4500s ist dabei recht lang (bei meinem DG-Anschluss sind es 1800s). Vermutlich werden RA daher auch nur in großen Zeitabständen (etwa alle 25 Min.?) erhalten?

Dein Router leitet daraus das IPv6-Standardgateway fe80::22 ab, das zeigt er evtl. auch irgendwo in der Web-GUI oder an der Console (Auslesen der IPv6-Routingtabelle, dort die Default-Route "::/0 next hop fe80::22") an.

Was du als Nachweis gegenüber DG (dort dem 2nd-Level-Support, so sie einen haben) machen kannst:

• Starte an einem LAN-PC (in mehreren Terminalfenstern) Dauerpings auf mehrere "well known" IPv6-Ziele, z.B. unter Windows:
  ping -6 -t google.com
  ping -6 -t facebook.com
  ping -6 -t wikipedia.org
• Führe einen Paketmitschnitt am WAN-Port des Routers durch und lass den vielleicht eine Minute laufen.

In der Anzeige des Mitschnitts mittels Wireshark setze des Ansichtsfilter icmpv6.

Du müsstest dann sehen, dass der Router die Pings des LAN-PC über die WAN-Strecke zur DG-Gegenstelle (verpackt in Ethernet-Frames mit der Ethernet-Zieladresse: 20:00:00:00:32:02, hat der Router durch NS/NA (MAC-Adressauflösung) aus der Gateway-Adresse fe80::22 ermittelt) sendet, von dort aber niemals Ping-Antworten zurück kommen. Das wäre der sichere Beleg, dass dein Router korrekt arbeitet und das (Rückwärts-)Routing-Problem auf der Seite der DG liegt.

Deine ICMPv6-WAN.zip bzw. der zugehörige Screenshot sind für jeden technisch versierten Netzwerker bzw. Sachverständigen ein klarer Beweis, dass es in der DG-internen Infrastruktur ein Problem mit dem (Rückwärts-)Routing deines PD-LAN-Präfix gibt. Es ist dabei wichtig, eine Auswahl prominenter IPv6-Ziele auszuwählen, damit sich DG nicht herausreden kann, dass die Ziele bzgl. IPv6 nicht zuverlässig antworten würden. Andere gute Ziele wären bspw. die 13 DNS-Root-Nameserver (a.root-servers.net - m.root-servers.net).

Ja, mit dem 1st-Level-DG-Support ist es schwierig, die scheinen nur angelernte Kenntnisse zu Glasfaser-Problemen (also L1-L2) zu haben. Jedes Problem ab L3 (z.B. IPv4 geht, IPv6 aber nicht) führt zu Überforderung bzw. wird dann kochrezeptartig mit unpassenden/sinnlosen Lösungsvorschlägen zu L2-Problemem (z.B. Router und/oder Modem zurücksetzen) aus der Textbausteinsammlung beantwortet.

Ich würde zur Schonung der eigenen Nerven vermeiden, mich dort wegen dieses Problems telefonisch zu melden. Alles nur schriftlich via deren Ticket-System. Und wenn ein Ticket ohne Lösung einfach geschlossen wird, ein neues mit Bezug auf alle vorher geschlossenen Tickets aufmachen.

Deine ZIP-Datei nebst Screenshot würde ich an ein Ticket anhängen.

Wichtig für Regress-Forderungen (solche würde ich in dem Ticket auch androhen) ist auch das Datum des ersten Tickets zu dem Problem, weil es den Startpunkt des Zeitraumes markiert, ab dem die laut Leistungsbeschreibung/AGB zugesagte und bezahlte Leistung (IPv6) eben nicht zur Verfügung steht.

HubeBube hat hier schon an verschiedenen Stellen erläutert, wie man in solchen Situationen am besten vorgeht.

Da die IPv6-Problematik ja nicht abschließend gelöst wird, bin ich an deiner Stelle sogar geneigt bei der BNetzA die Schlichtungsstelle zu kontaktieren: https://www.bundesnetzagentur.de/TK-Schlichtung

Schließlich verweigert dir Deutsche Glasfaser trotz mehrfacher Aufforderung deinerseits, Du lieferst sogar Belege bezüglich des technischen Problemes, eine vertraglich zugesicherten Leistung.

Offensichtlich hat die Schlichtungsstelle aktuell sehr viel zu tun, deshalb ist dieser Weg eine zusätzliche Option und kein Ersatz für die Vorgehensweise bei auftretenden Störungen, sprich: Ticket via DG Portal offen halten durch den Punkt "Nachfrage zu Ticket #...".

Noch ein Nachtrag zu ICMPv6-WAN.zip:

Der Mitschnitt enthält auch 8 ICMPv6-Errors (Wireshark-Filter: icmpv6.type==1) des Typs 1 (Destination Unreachable) mit dem Code 1 (Administratively prohibited):

Deine Versuche, von deiner LAN-IPv6-Adresse 2a00:6020:9842:f02:7d80:ff4:59e6:f151 eine TCP-Connection zu [2a00:6020:9841:8245::4c51]:443 aufzubauen (vermutlich das DG-Kundennetz deines erwähnten Freundes), werden von dessen Router (mit der WAN-Adresse=2a00:6020:9800::1e1) geblockt. Dieser sendet daraufhin den erwähnten ICMPv6-Error (von seiner WAN-Adresse) an deine LAN-IPv6-Adresse zurück.

Das bedeutet:

Der BNG-Cluster, an dem eure Anschlüsse hängen, kennt eure PD-LAN-Präfixe (deiner: 2a00:6020:9842:f00::/56 - der deines Freundes: 2a00:6020:9841:8200::/56), und kann sie untereinander routen. Beide LAN-Präfixe liegen im übergeordneten Block 2a00:6020:9800::/41 - /41 ist nach meinen Analysen bei DG die Grundgröße pro BNG-Cluster, an dem theoretisch maximal 2^(56-41) = 32.767 Kundenanschlüsse hängen können (-1 für dem ersten /56, in dem die WAN-Adressen der Anschlüsse liegen).

Wie schon weiter oben von mir vermutet, fehlen in der DG-Infrastruktur "hinter" dem BNG-Cluster offenbar Routing-Informationen, die eurer beide PD-LAN-Präfixe zu dem zuständigen BNG-Cluster forwarden. Der Block für die WAN-Adressen (2a00:6020:9800::/56 bzw. genauer: 2a00:6020:9800::/112) scheint allerdings sehr wohl zu diesem BNG-Cluster geroutet zu werden.

Andererseits würde ich nicht erwarten, dass DG die einzelnen Sub-Ranges so selektiv routet - mit einer einzigen Route für den Gesamtblock 2a00:6020:9800::/41 wäre es ja auch getan - insofern etwas verwunderlich.

Mich wundert noch ein wenig die IPv6-LAN-Adresse des Freundes: 2a00:6020:9841:8245::/64. Wenn der den PD-Block 2a00:6020:9841:8200::/56 zugewiesen bekommen hat, wäre er mit dem Index 45 für die daraus abgeleitete /64-LAN-Adresse recht weit weg von der 0, die z.B. eine Fritzbox wählt. Hat der Freund tatsächlich ein PD-LAN-Präfix der Größe /56 zugewiesen bekommen? Oder hat er tatsächlich nur den minimalen Block der Größe /64 (also konkret 2a00:6020:9841:8245::/64) von der DG erhalten? Dieses Phänomen gab es kürzlich in einem anderen Fall.

Zitat von themaze

Anhand des Suffixes erkenne ich dass es mein Reverseproxy ist.

Die scheinst ein komplexeres strukturiertes LAN mit mehreren LAN-Segmenten (VLANs) und evtl. nachgelagerten Routern zu betreiben?

So etwas ist m.E. nicht gut verträglich mit wechselnden IPv6-LAN-Präfixen - da muss man sich (zu) sehr darauf verlassen, dass die dynamischen Prozesse, die mit einem Präfix-Wechsel ausgelöst werden, auch zuverlässig funktionieren (z.B. nachgelagerte IPv6-PD an sekundäre LAN-Router, DynDNS für von außen erreichbare LAN-Instanzen, dynamische Anpassung von Firewall-/Proxy-Regeln, usw.)

In solchen Fällen wäre m.E. ein Business-Anschluss mit festen IPv6-Adressen die bessere Wahl.

Das ist dann wohl das LAN-Interface deines Routers.

Hier das Ping-Ergebnis an meinem DG-Anschluss

Und so sieht es aus Sicht von London und Amsterdam aus:

Aber es bestätigt meine Vermutung aus #11.

Zitat von themaze

Gibt es Business Tarife (von der DG) mit fixen Prefixen für Ottonormalos?

Kann ich nicht sagen - aber DG berät dich hier bestimmt hervorragend bei der Auswahl eines geeigneten Business-Tarifs.
Mir ist jedenfalls nicht bekannt, dass DG gegen einen geringfügigen Aufpreis feste IPv6-Adressen an Privat-Anschlüssen bereitstellt.

Zitat von themaze

In der Tat habe ich ein komplexeres Netzwerk aber nur einen OPNsense Router welcher direkt am Modem hängt mit mehreren Netzwerke. Das mit den Interfaces ist soweit kein Problem bei wechselnden Adressen. Nur Jetzt wo IPv6 ins und vom Internet Tot ist, ist das nervig.

Vielleicht noch ein Hinweis, aber vermutlich muss ich dir das gar nicht erzählen:

Ich würde parallel zu dynamisch zugewiesenen globalen IPv6-Adressen im LAN noch permanent ULA (fd00::/8 -> fdxx:xxxx:xxxx::/48 (xx:xxxx:xxxx auswürfeln) -> LAN1: fdxx:xxxx:xxxx:1::/64, LAN2: fdxx:xxxx:xxxx:2::/64, LAN3: fdxx:xxxx:xxxx:3::/64, ...) verwenden.

Die sind fest und immer verfügbar. Sie werden bei rein LAN-interner Kommunikation bevorzugt genutzt und sind dynamisch in einem lokalen DNS-Server registrier- und somit in einer LAN-internen DNS-Domain komfortabel auflösbar . Voraussetzung ist bei allen Endgeräten allerdings eine aktuelle Default Policy Table (kann man sich unter Windows via netsh int ipv6 show pref anzeigen lassen), die einen Eintrag für fc00::/7 enthält - zur Not muss man diesen von Hand ergänzen, falls das jeweilige System dafür eine Schnittstelle bietet (problematisch bei IOT-Geräten wie Druckern usw., aber die spricht man halt zur Not ausschließlich via IPv4 an)

So könntest du das Inside-Interface deines Proxies (falls "one-armed" ULA als secondary IPv6 address) stets über eine feste ULA adressieren.

Von O2 aus haengt es am selben Hop: