Mal wieder: Kein IPv6 bei Deutsche Glasfaser

Zitat von ::1

Ach, noch eine Idee: Um die Palo als Ursache wirklich auszuschließen, klemm doch einfach mal einen PC direkt an den Anschluss (aber erst mal 1 Stunde warten!). In deinem Packet Capture dort solltest du dann auch keine NS/NA-Kommunikation sehen, wenn es tatsächlich an DG liegt.

Das hatte ich noch letztes Jahr im Dezember gemacht, damit ich die Palo ausschließen kann. Auch mein Desktop (Windows 11 Pro) erhält zwar eine IPv6 hat aber keine Konnektivität. Ein Packet Capture hat ergeben, dass die DG nicht auf NS Nachrichten reagiert.

Ich habe auch meine alte FritzBox 7590 angeschlossen und festgestellt, dass es dabei keine Probleme gibt. Ein Packet Capture hat ergeben, dass die FritzBox (anscheinend) nicht Standardkonform arbeitet und aufgrund der eingehenden RA den Router sofort als "erreichbar" markiert.

Zitat von DaSokas

Das hatte ich noch letztes Jahr im Dezember gemacht, damit ich die Palo ausschließen kann. Auch mein Desktop (Windows 11 Pro) erhält zwar eine IPv6 hat aber keine Konnektivität. Ein Packet Capture hat ergeben, dass die DG nicht auf NS Nachrichten reagiert.

Da wir von anderen Anschlüssen wissen, dass die auch mit anderen Endgeräten (wie zum Beispiel dem Windows-PC) funktionieren, scheint das eine spezifisch abweichende Konfiguration für deinen Anschlussbereich zu sein.

Mit etwas Glück kannst du es bei DG solange eskalieren, bis du einen fähigen Techniker erwischt, der sich die IPv6-Konfiguration ansieht.

Zitat von pufferueberlauf

Allerdings vermute ich, dass die DG eigentlich vorhat funktionierendes IPv6 zu liefern und es hier kein Kampf gegen den ISP ist, sondern gegen die Prozesse des ISP die Techniker von Endkunden trennen, denn eigentlich habt ihr das selbe Interesse und IMHO waere es vielleicht hilfreich wenn die DG Technik mit Dir Kontakt aufnaehme, nicht dass meine Meinung da igendetwas aendern koennte...

Ich wurde schon einmal von der Beschwerdeabteilung kontaktiert, allerdings habe ich hier nichts weiter gehört und das dazugehörige Ticket wurde zum Schluss geschlossen, mit dem Hinweis, dass der Anschluss instand gesetzt wurde.

Als ich mit dem guten Herren der Beschwerdeabteilung gesprochen hatte, habe ich auch gesagt, dass mich die Techniker gerne direkt anrufen dürfen, falls sie meine mithilfe benötigen. Ich habe auch explizit darauf hingewiesen, dass ich 24/7 für die DG zur Verfügung stehe, weil mir die Problemlösung eben wichtig ist.

Nun zur Preisfrage: Glaubst du, dass ich von einem Techniker jemals angerufen wurde?

Zitat von pufferueberlauf

Aus eigener Erfahrung mit Problemen bei O2 muss ich sagen, dass manche Loesungen Monate in Anspruch nehmen und Endkunden wie wir meist nicht/kaum mit Zustandsupdates versorgt werden. Ich hoffe mal die Techniker der DG arbeiten still und heimlich an einer Loesung.

Das wäre ja auch vollkommen okay, wenn ich nicht immer per E-Mail darüber informiert werden würde, dass es keine Probleme gäbe und die Tickets geschlossen werden. Ich muss dann explizit ein neues Ticket mit einer "Rückfrage" zum geschlossenen Ticket eröffnen.

Das mit dem Ticketschliessen ist IMHO die Konsequenz daraus wie die Performance der Hotliner bewertet wird (vermutlich Anzahl geschlossener Ticket/Zeit, bzw. mittlere Zeit die Tickets geoeffnet bleiben.)

Zitat von DaSokas

Ich habe auch meine alte FritzBox 7590 angeschlossen und festgestellt, dass es dabei keine Probleme gibt. Ein Packet Capture hat ergeben, dass die FritzBox (anscheinend) nicht Standardkonform arbeitet und aufgrund der eingehenden RA den Router sofort als "erreichbar" markiert.

Ja, wenn ich in die Packet-Captures aus meiner Fritzbox 7590 anschaue, sehe ich folgendes Verhalten:

Bis zum Abschluss der DHCPv6-Transaktionen zum Bezug einer IPv6-Lease (IA_NA, IA_PD) sehe ich keinerlei NS/NA-Kommunikation außer denen, die die Fritzbox für ihre eigenen IPv6-Adressen im Rahmen der DAA (Duplicate Address Detection) sendet.

Die erste NS, die die Fritzbox zur Auflösung der DG-Gateway-Adresse sendet, erfolgt bereits als IPv6-Unicast an eben jene Gateway-Adresse und nicht als IPv6-Multicast an die aus der Gateway-Adresse abgeleitete SNMA (solicited node multicast address). Das deutet darauf hin, dass die Fritzbox die DG-Gateway-Adresse zusammen mit deren MAC-Adresse bereits im Neighbor-Cache hatte (statt state=STALE, offenbar schon als REACHABLE geflagt). Dort hinein kann der Eintrag aber nur durch vorangegangene, erhaltene RA des DG-Gateways gelangt sein. Eine Verwendung von SNMA sehe ich nur für NS, die das DG-Gateway an meine Fritzbox sendet, witzigerweise auf Ethernet-Ebene als Unicast an die MAC meiner Fritzbox und nicht als Ethernet-Multicast an 33:33:xx:xx:xx:xx.

Zitat von DaSokas

Ich vermute mal, dass du sowas gesucht hast?

Nö, ich suchte nach Informationen zu rein interface-basierten Filterregeln, mit denen man ND-Traffic reglementieren kann. Ganz im Sinne von Chapter 4.4 in RFC4890 bezüglich dessen, was dort als "ICMPv6 Local Configuration Traffic" bezeichnet wird - im Gegensatz zu "ICMPv6 Transit Traffic" im Chapter 4.3 (was ich in einem früheren Post als "Passthrough" bezeichnet hatte).

Aber sowas scheint es bei einer Palo nicht zu geben, wie du ja auch schon gesagt hast.

Zitat von ::1

Ja, wenn ich in die Packet-Captures aus meiner Fritzbox 7590 anschaue, sehe ich folgendes Verhalten

Genau, Nicht-Standardkonform und mein Hinweis auf den ND Prozess im RFC 4861 hat auch niemanden interessiert, weder die DG noch die BNetzA.

Ich bin sogar so weit gegangen und habe versucht der BNetzA zu erklären, dass man hier durchaus einen Router-Zwang ableiten könnte, da ich dazu gezwungen werde einen Nicht-Standardkonformen Router zu verwenden, wenn ich IPv6 verwenden möchte.

IPv6 funktioniert, aber nur wenn ich einen defekten Router verwende, den die DG auch ganz zufälligerweise ihren Kunden anbietet..

Ich zitiere hier mal die BNetzA bzgl. dieser Angelegenheit:

Zitat

Falls Sie [DaSokas] keinen intellektuellen Zugang zu dieser Thematik haben sollten, könnte Ihnen eine Internetrecherche helfen.

Sorry, ich bin gerade innerlich am Kochen..

Zitat

IPv6 funktioniert, aber nur wenn ich einen defekten Router verwende, den die DG auch ganz zufälligerweise ihren Kunden anbietet.

Oder eher so:

Dein BNG (DG-Gateway) ist bezogen auf deinen Kundenanschluss mindestens dahingehend gestört/fehlkonfiguriert, als dass es die von deiner Palo erhaltenen NS an die zu seiner Gateway-Adresse gehörende SNMA nicht mit NA beantwortet. Diesen Fehler kann zwar eine Fritzbox aufgrund nicht RFC-konformer ND-Implementierung kompensieren, nicht jedoch ein RFC-konform arbeitender Router bzw. Endgerät. Ohne die BNG-Fehlkonfiguration könnte auch deine Palo reibungslos IPv6 nutzen.

Ich könnte mir folgende Ursache am BNG vorstellen:

Für das Interface zu deinem Anschluss hat kein Join zu der Multicast-Gruppe stattgefunden, die der SNMA der link-lokalen IPv6-Adresse des DG-Gateways entspricht. Deswegen nimmt es keine an diese SNMA gerichteten NS an. Das zu überprüfen, wäre mal ein konkreter Hinweis an DG.

Dein BNG gehört wohl zum "Hannover-BNG-Cluster-2", das für deinen Anschluss zuständige BNG müsste die DG-interne Adresse 2a00:6020:ffff:ffff::13 haben.

Zitat von Taxan4711

Moinsen,

bie mir lief es so:

4.02. BNG Störung, keine IP6 erhalten, Ticket aufgemacht - wurde am 7.02. geschlossen mit dem Hinweis Störung behoben. Danach IP6 (die alte) bekommen, aber kein Inbound / Outbound Routing im BNG.

10.02. Neues Ticket aufgemacht und detailliert Fehler beschrieben mit dem Hinweis "Port am BNG falsch konfiguriert, Problem an 2nd Level weiterleiten" (im 1st Level, meist ein outsourced Callcenter, kann soetwas in der Regel nicht entstört werden).

17.02. Ticket lag immer noch unbearbeitet, per Telefon DG Vertrieb angerufen und hingewiesen, dass seit 2 Wochen der Vertrag nicht erfüllt wird verbunden mit der Frage, ob DG das beheben möchte oder ich aussergewöhnlich kündigen soll. Dann gings schnell, am nächsten Morgen ca. 2 Uhr lief das Routing wieder.

Just my 2 cents ...

Alles anzeigen

Hallo zusammen,

Danke nochmals für die hilfreichen Tipps. Seit heute morgen (und ja nur ein paar Wochen gedauert) kann ich google auf die IPv6 pingen. Nach drei weiteren Tickets (die immer wieder mit "liegt nicht an uns" abgeschlossen wurden) und zwei weiteren Telefonaten geht es jetzt. Auf der einen Seite freue ich mich, auf der anderen Seite war es unvorstellbar schwer DG klar zu machen, dass das Problem nicht auf meiner Seite war. Man wird immer mit pauschalen Antworten abgespeist.

Die Lösung aus meiner Sicht ist immer wieder ein Ticket zu öffnen / anzurufen und nicht locker zu lassen.

Schönen Sonntag an alle.

Zitat von idb

Die Lösung aus meiner Sicht ist immer wieder ein Ticket zu öffnen / anzurufen und nicht locker zu lassen.

Mein Reden. Und freundlich bleiben. Die Hotline Mitarbeiter können nichts dafür.

Zitat von DaSokas

Ich bin sogar so weit gegangen und habe versucht der BNetzA zu erklären, dass man hier durchaus einen Router-Zwang ableiten könnte, da ich dazu gezwungen werde einen Nicht-Standardkonformen Router zu verwenden, wenn ich IPv6 verwenden möchte.

Ich denke, diese Aussage meinst du nur einschränkend für den BNG-Port zu deinem Kundenanschluss, um dessen vermutete Fehlkonfiguration zu kompensieren, also jedenfalls nicht generell?

Ich habe mir mal die Mühe gemacht, neben der allgegenwärtigen Fritzbox andere Router-Modelle an allen IPv6-aktiven DG-Anschlüssen zu identifizieren, die eine RIPE-Atlas Probe betreiben (LINK).

Auf Basis der Eigenbeschreibungen im Datenfeld "Router Type" konnte ich folgende Router-Modelle identifizieren:

• OPNsense: Probe 60646
• OpenBSD: Probe 53717
• MikroTik: Probes 1359, 14149, 28932, 61286, 1006149, 1010188

Ich denke mal, unter diesen drei genannten Router-Modellen wird sich bestimmt mindestens eines befinden, das bzgl. ND standardkonform arbeitet .

Zitat von ::1

Ich denke mal, unter diesen drei genannten Router-Modellen wird sich bestimmt mindestens eines befinden, das bzgl. ND standardkonform arbeitet .

Ich habe nicht alle Router-Modelle dieser Welt an meinem Anschluss testen können und habe entsprechend auch keine Packet Captures durchgeführt und diese analysiert, entsprechend war diese Unterstellung (bewusst) weit hergeholt.

Es ging darum die DG zu einer Handlung zu zwingen.

Mit welcher Problemstellung kann ich bei diesem ipv6 Problem ein Ticket am besten eröffnen ?

Habe ebenfalls Intern keine ipv6 trotz korrekten Einstellungen

Trace 2. Hop fc00::1

Zitat von ::1

Auf Basis der Eigenbeschreibungen im Datenfeld "Router Type" konnte ich folgende Router-Modelle identifizieren:

OPNsense: Probe 60646

Ich habe jetzt meine Palo durch eine (virtuelle) OPNsense ersetzt und musste feststellen, dass die OPNsense keine Probleme mit der IPv6 Konnektivität hat. Ich muss aber gestehen, dass ich (noch) nicht herausgefunden habe, was die OPNsense anders macht als die Palo.

Ich bekomme nun wie erwartet NA Antworten des DG-GW auf NS Anfragen der OPNsense, womit das DG-GW in die ND-Table aufgenommen wird. Das Resultat ist, IPv6 funktioniert.

Da ich momentan sehr wenig Zeit habe, werde ich weitere Untersuchungen irgendwann in der Zukunft durchführen. Mich macht das schon etwas stutzig, was die genauen Unterschiede sind..

Zitat von DaSokas

Mich macht das schon etwas stutzig, was die genauen Unterschiede sind.

Ich bin immer noch nicht ganz weg von der Idee interface-bezogener Filter bei der Palo, die den ND-Traffic reglementieren ...

Siehe meine Anmerkungen in #131.

Wenn du Interesse hast, kannst du auch Traces hier hochladen und wir schauen uns das an.

bereits 3 Tickets geschlossen. 2 Stück mit FiberTwist neu starten und zurück setzen und ein Ticket das es doch einwandfrei funktioniert und es verschiedene Lösungen dafür gibt. DG dafür aber keinen Support gibt.

Wie gesagt, rein statistisch brauchst du 10 Anläufe.

Zitat von frank_m

Wie gesagt, rein statistisch brauchst du 10 Anläufe.

Ok kein Problem, ärgert mich zwar aber was macht man nicht alles.

Ich wüssete gerne mal wie ihr das Problem beschrieben habt.

Zitat von dgfeuer

Ich wüssete gerne mal wie ihr das Problem beschrieben habt.

Was ist denn genau dein Problem?

Deinen ersten beiden Meldungen (#50, #138)

Zitat

Bei mir das gleiche Problem ipv6 von extern nicht erreichbar.

...

tracert -6 ipv6.google.com

endet mit dem 2. Hop auf fc00::1

und

Zitat

Habe ebenfalls Intern keine ipv6 trotz korrekten Einstellungen

Trace 2. Hop fc00::1

würde ich entnehmen, dass bei deinem Anschluss gar keine IPv6-Kommunikation (weder outbound noch inbound) möglich ist. Bzw. hast du evtl. noch nicht mal IPv6-Adressen zugewiesen bekommen (WAN-Adresse + LAN-PD-Block)?

Alles etwas dünn, um hierzu etwas sagen zu können.