DSL IPv6 PD DHCPv6 eventueller Fehler seitens O2

Dann versuche ich mal zu helfen.

Zunächst muss man verstehen, dass es die Möglichkeit gibt IPv6-Adresse nach einem festgelegten Schema zu verkürzen (siehe https://datatracker.ietf.org/doc/html/rfc4291#section-2.2). Statt

2001:DB8:0000:0000:0008:8000:200C:417A oder 0000:0000:0000:0000:0000:0000:0000:1

schreibt man dann komprimiert

2001:DB8::8:800:200C:417A oder ::1 

Das heißt konkret:

1. Führende Nullen werden weggelassen: 0008 → 8
2. Blöcke mit nur Nullen werden komplett leer gelassen: :0000: → ::
3. Aufeinanderfolgende, leere Blöcke werden ebenso zusammengefasst: :::: → ::

Die zweite Sache, die man verstehen muss ist die Kennzeichnung für Netzwerke (https://datatracker.ietf.org/doc/html/rfc4291#section-2.3). In den Beispielen oben haben wir immer genau eine Adresse genommen, will man aber ein Netzwerk definieren, so muss man ja einen Block von Adressen spezifizieren. Hier schreibt man hinter die Adresse einen Slash (/) und die Anzahl der Bits von vorne, die fix sind. Zum Beispiel

2001:0DB8:0:CD30::/64

Die ersten 64 Bit sind festgelegt, jeder Block hat 16 Bit, also sind die ersten vier Blöcke fix.

Schaut man jetzt in die Liste der IANA (https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml), so findet man den Eintrag:

::/8     Reserved by IETF

Ich verstehe das so: Alles was mit den ersten acht Bit gleich “0” anfängt ist von der IETF reserviert. Oder aufgedröselt, jede Adresse die dem folgen Schema entspricht:

00xx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

Und da fällt ja 0000:: nach meiner Auffassung rein. Daher sollte nur die IETF Adressen in diesem Bereich vergeben. Die einzigen, mir bekannten Adressen sind in https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml gelistet: Die Unspecified Address (alles Null) und die Loopback-Adresse (ganz hinten eine 1).

Meiner Meinung nach gilt daher: 0000::-Adressen sind zwar gültig, dürfen aber nicht einfach so von jedem benutzt werden. Insofern hat der Kollege recht, insbesondere mit der Einschränkung “bei bestimmten Begebenheiten” - dies schließt IMHO DHCP nicht mit ein. :)

Hope that helps.

​@Tumblebit, danke für den Hinweis auf die 16 bit je Block. War mir durchgerutscht heute früh. Wenn ich das Ruleset wie folgt anpasse:

ip6 saddr { fe80::/10, 0:80fe::/32 } ip6 daddr { fe80::/10, 0:80fe::/32 } udp sport 547 udp dport 546 accept

ist alles korrekt (wenn auch unschön). Mal sehen, ob der Workaround damit soweit funktioniert. Eigentlich muss das Problem aber an anderer Stelle gelöst werden.

Ich war mir nicht sicher, ob das Problem nicht doch bei mir liegt, weil es nach einem Server-Neustart ja bislang immer erstmal funktioniert. Kann aber auch Zufall sein.

Guten Abend zusammen \o/ 

Ein kurzes Lebenszeichen von mir, ich hab mich nicht aus dem Staub gemacht, es gibt mich noch 😁

Wir haben jetzt an den richtigen Türen geklopft, es hat halt bei diesem crazy Fehlerbild etwas gedauert, bis wir jemanden gefunden hatten, der uns weiterhelfen konnte 💥 

Gute Nachricht zuerst: Die Kolleg:innen konnten den Fehler jetzt dieses mal tatsächlich nachstellen und reproduzieren \o/  (Ich bin mir sicher, das ich beim ersten Versuch zur Klärung das ganze nur zu dilettantisch übermittelt hatte, sonst hatte das sicher auch schon vorher geklappt). 

Zur Lösung müssen wir hier wohl mit irgendwelchen Herstellen Hand in Hand arbeiten und an gewissen Stellen aktiv werden. Ich kann mir vorstellen, dass ihr es ganz genau wissen wollt, ich war aber erst mal happy, das ich überhaupt was vermelden kann, daher wollte ich die Kollegen auch nicht mit vielen weiteren Fragen nerven 😄 Ich vermute mal, das an irgendeiner Stelle der Hersteller eines Netzelements /Servers / whatever irgendwas patchen oder updaten oder einfach nur neu konfigurieren muss, daran wird jetzt aber gearbeitet.

Da ich jetzt weiß, wen ich fragen muss, kann ich versuchen an detaillierte Infos zu kommen, ich möchte aber nichts versprechen, seht es mir nach 😄

Beste Grüße und einen schönen zweiten Advent morgen \o/

Matze

Hallo zusammen,

neues Jahr, neues Glück (oder so)
Vielleicht wird das Problem auch kurzerhand behoben? 🙃

Ich habe dieses Problem erst seit einigen Monaten, es muss also auch eine Umstellung gegeben haben, die zu dem Problem geführt hat.

Leider scheint es bei meinem UniFi Router auch nicht zu genügen, den Traffic explizit in der Firewall freizugeben. Wahrscheinlich wird das Paket dann also später verworfen, beispielsweise vom DHCP Client Dienst (wäre ja auch richtig so, da nicht RFC-konforme Antwort).

Viele Grüße

Julian

​@o2_Matze, gibt’s was Neues?

Hi ​@Loredo82 

Willkommen in unserer o2 Community, schön dass du uns hier gefunden hast  😊

Gute Nachricht zuerst: Die Kolleg:innen konnten den Fehler jetzt dieses mal tatsächlich nachstellen und reproduzieren \o/ 

Zur Lösung müssen wir hier wohl mit irgendwelchen Herstellen Hand in Hand arbeiten und an gewissen Stellen aktiv werden

Das hat immer noch Bestand. Dieser doch sehr wilde Fehler (ich stelle jetzt mal die steile These auf, das es sicher nur eine Hand voll Kunden gibt, die das Problem überhaupt tangiert 😄 ) ist an die Verantwortlichen im Transportnetz weitergeben und wird dort weiter untersucht und im Rahmen eines Updates / Patch / Fix hoffentlich mittelfristig korrigiert werden können. 

Erfahrungsgemäß würde ich da aber immer in Quartalen rechnen (und meine Meldung an die Kolleg:innen ist gute fünf Wochen her). Bedeutet, dass ihr da vermutlich noch ein wenig Geduld haben müsstet.    

VG Matze 

ich stelle jetzt mal die steile These auf, das es sicher nur eine Hand voll Kunden gibt, die das Problem überhaupt tangiert 😄

[...]

Erfahrungsgemäß würde ich da aber immer in Quartalen rechnen

Ich habe nun hin und her überlegt und muss sagen: Ich finde diese Aussage ziemlich frech.

Hat O2 in Deutschland tatsächlich so wenig DSL Kunden, dass nur eine Hand voll einen eigenen Router verwenden, der sich an Standards hält und die IT-Sicherheit herstellt? Ich glaube nicht.

Ich weiß sehr wohl, dass in Konzernen die Mühlen langsam malen können. Gleichwohl geht das bei ernsten Themen auch anders. Natürlich muss man dafür auch die entsprechenden Daten erheben, um den Ernst der Lage auch tatsächlich zu sehen. Klar, wer kein Sammelticket anlegt, unter dem solche Anfragen gesammelt werden oder gar mal in die Logfiles schaut, von wie vielen Routern denn ungewöhnlich viele DHCPv6 Anfragen kommen, der tut sich leicht das Thema einfach abzubügeln.

Nachdem meine Tickets beim Support allesamt geschlossen wurden nach dem Motto “won’t fix” und mir hier auch vermittelt wird, dass man gerne die Product Group (wie es Neudeutsch ja so schön heißt) gerne vor externen Störfaktoren schützen möchte, suche ich mir besser einen neuen DSL Anbieter.

Nach fast 20 Jahren als Kunde bei O2 wird es wohl allerhöchste Zeit. Der Umstieg auf Glasfaser steht ohnehin an, die liegt schon im Keller. O2 wird da keine Rolle mehr spielen.

Hallo ​@Loredo82 

Es tut mir leid, wenn dir das ganze als frech vorgekommen ist. So war es mitnichten gemeint. Falls der Eindruck entstanden sein sollte großes Sorry, da bitte ich um Entschuldigung. Ich denke hier im Thread sollte doch durchaus erkennbar sein, das ich diesen Fehler immer wieder an unsere IT reportet und dort mit Nachdruck eure Interessen vertreten habe. Daraus resultierend konnte das ganze am Ende ja auch reproduziert und an entsprechende Stellen zur Korrektur weitergeleitet werden. Dennoch wirst du mir doch zustimmen, dass dieser Fehler sehr spezifisch ist und sicher nur einen sehr sehr kleinen Teil unserer User überhaupt betrifft. 

Hinsichtlich meiner “Quartalseinschätzung” sind das einfach “geschätzte” Erfahrungswerte, da die Lösung selber nicht mehr in unserer Hand liegt, sondern extern geschehen muss. 

Ich klopf aber gerne noch bei den Kolleg:innen an und versuche da an eine Wasserstandsmeldung zu kommen. 

VG Matze 

Dennoch wirst du mir doch zustimmen, dass dieser Fehler sehr spezifisch ist und sicher nur einen sehr sehr kleinen Teil unserer User überhaupt betrifft.

Ich würde das eher so formulieren, dass es einen kleinen Teil der User bemerkt. Naja, es ist ja auch nicht überall das Problem vorhanden (bei mir z.B. nicht, obwohl mein Router/Firewall die Pakete laut dem Ruleset verwerfen würde), was für deine Aussage spricht. Allerdings ist mir halt nicht bekannt, ob die üblichen Kundenrouter (o2 HomeBox, AVM FRITZ!Box, ...) diese fehlerhafte Pakete verwerfen würden oder nicht, das hätte sicherlich einen grossen Einfluss auf die menge an Kunden, die potenziell betroffen wären ohne es zu spüren.

dass man gerne die Product Group (wie es Neudeutsch ja so schön heißt) gerne vor externen Störfaktoren schützen möchte, suche ich mir besser einen neuen DSL Anbieter.

Das ist IMHO gut so. Änderungen mit massivem Druck durchzuprügeln endet selten gut.

An sich ist es ein Problem, ja, die Pakete sollten so nicht adressiert werden. Allerdings gibt es Workarounds und das IPv4 Internet ist ja nach wie vor vollständig vorhanden, so dass der potenzielle “schaden” recht minimal ausfällt. Demnach finde ich es durchaus richtig so, dass Telefonica ihre Experten ein stückweit von “äusserliche Störfaktoren” schützt, so dass sie (hoffentlich) dadurch besser arbeiten können, was allen Telefonica Kunden zugutekommt.

Telefonica ist bei weitem nicht perfekt, sie haben durchaus einige Baustellen, das möchte ich hier auch nochmal betonen. Allerdings muss man auch nicht unbedingt übertreiben.

Matze schrieb

Dennoch wirst du mir doch zustimmen, dass dieser Fehler sehr spezifisch ist und sicher nur einen sehr sehr kleinen Teil unserer User überhaupt betrifft.

almightyloaf schieb

Ich würde das eher so formulieren, dass es einen kleinen Teil der User bemerkt. 

Guter Punkt ​@almightyloaf da hätte ich sauberer formulieren müssen. Eigentlich wollte ich damit auch nur sagen, dass dieser (zugegeben) unschöne Fehler den Großteil unserer Kunden gar nicht tangiert, da sie ihn gar nicht bemerken und somit strenggenommen auch nicht betroffen sind, denn sie können surfen, streamen, mailen oder über die Playstation & Xbox zocken und machen vielleicht sogar alles gleichzeitig.

Nichtsdestotrotz bleiben wir da weiter am Ball. Meine Anfrage ist gestern rausgegangen, ich hoffe nun das ich Anfang /Mitte der kommenden Woche dazu ein Update erhalte.  

VG Matze  

Danke für den Post, jetzt weiß ich endlich warum IPv6 bei mir nicht mehr geht…

Ich nutze ein Cloud Gateway von Ubiquity und bekomme keine IPv6 mit DHCPv6 und prefix delegation. Tcpdump zeigt mir die gleiche 0:80fe Adresse an.

Was mir aufgefallen ist, wenn ich statt DHCPv6, SLAAC auswähle erhält mein Gateway eine IPv6, prefix delegation an die Subnets funktioniert aber leider trotzdem nicht.

Ich versuche jetzt erst mal mit den Firewall regeln herumzuspielen um den Workaround zum laufen zu bekommen.

Was mir aufgefallen ist, wenn ich statt DHCPv6, SLAAC auswähle erhält mein Gateway eine IPv6, prefix delegation an die Subnets funktioniert aber leider trotzdem nicht.

Telefonica verweist auf 1TR112 der Telekom, in der steht, dass DHCP (neben PPPoE) anwendung findet. Es ist beim Punkt 9.3.1.2 und 9.4.1.1 so definiert. Funktioniert aber mit SLAAC offensichtlich auch. Ob das absicht oder versehen ist, weiss ich nicht.

Hallo zusammen.

Die Kolleg:innen haben mir noch mal mitgeteilt, dass eine Lösung in Sicht ist, aufgrund der Abhängigkeiten von diversen Stellen aber leider keine kurzfristige, daher kann ich euch Stand heute keinen direkten Termin nennen. 

Der Fehler wird aber nicht unter den Tisch gekehrt, es wird weiter proaktiv an der Korrektur gearbeitet.

Aktuell kann ich euch also nur um Geduld bitten.

Danke für eurer Verständnis. 

VG Matze 

Moin zusammen,

Danke erstmal an ​@o2_Matze, dass du da so hartnäckig dranbleibst an dem Thema und bei deinen Kollegen bist.

Wäre natürlich schön, wenn das sofort gefixt wäre, aber da es scheinbar von einem Zulieferer kommt, hilft anscheinend nur Geduld.

Ich seh und habe ja auch darauf gehofft, dass die Techniker von O2 schon Interesse dran haben, dass ihr Netz ordentlich funktioniert. Man kann ihnen höchstens vorwerfen, dass sie es nicht selbst gefunden haben, aber man hat nur so viel Zeit am Tag und kann nicht alle Kombinationen testen bei jeder Änderung am Netz. Sorry, wenn ich da mal zuvor etwas hart ins Gericht gegangen bin mit O2.

Ich bin jedenfalls gespannt was es dann am Ende im Detail war(falls wir da teilhaben dürfen und es erfahren).

Hi ​@aufhaxer 

Danke für deine Rückmeldung 🙌

Sorry, wenn ich da mal zuvor etwas hart ins Gericht gegangen bin mit O2.

Alles fein, wir sind ja offen für Kritik, gerne auch mal maximal kritisch, solange diese auch konstruktiv, fair und respektvoll ist. Zurückblickend würde ich sagen, dass du diesen Pfad nie verlassen hast, daher alles cool 😄👍

Ich bin jedenfalls gespannt was es dann am Ende im Detail war(falls wir da teilhaben dürfen und es erfahren).

Auch da versuche ich das maximale an Info für euch rauszuholen, wenn es denn dann soweit ist. Ich bleibe da also am Ball. Ich möchte aber nichts versprechen, ab und an halten sich die Kolleg:innen auch etwas bedeckter, ich bleibe aber hartnäckig investigativ unterwegs 😄

VG Matze 

Ich wunderte mich auch, warum ich einfach kein ipv6-Präfix über meine Glasfaserverbindung bekommen konnte, bis ich dieses Thema fand und eine Ausnahme zur Firewall hinzufügte:

Auch hier kommt der dhcp-Lease anscheinend von einer „Nicht-Standard“-IP-Adresse, die mit 0:80fe beginnt:

Das ist natürlich kein großes Problem, aber ärgerlich oder zumindest verwirrend für Leute, die einen Router mit einer standardmäßig strikt eingestellten Firewall haben.

Das Problem ist also noch nicht gelöst, aber ich werde es weiterhin regelmäßig überprüfen, bis sich etwas ändert.

Das Problem ist also noch nicht gelöst

​@yllwfsh Ja, das ganze ist noch on going. Mir wurde nichts verbindliches zugesagt, aber es schwebte mal Ende Q1/Anfang Q2 durch den Raum, daher bleiben auch wir weiter gespannt wie sich das ganze entwickelt. 

VG Matze   

Hoffentlich kommt eine Lösung, UniFi Router wie die Dream Machines machen das mit einer Firewall Regel nicht mit und somit gibt es da derzeit keine Chance auf IPv6...

​@mkar Ich bin da guter Dinge, dass eine Lösung gefunden wird, allerdings ist es da Provider und Hersteller übergreifend schon mit viel Aufwand verbunden, gerade wenn diverse Abteilungen mit eingebunden sind, daher zieht sich das alles auch ein wenig, wir bleiben da aber weiter am Ball.

VG Matze    

Mir wurde nichts verbindliches zugesagt, aber es schwebte mal Ende Q1/Anfang Q2 durch den Raum

Hallo ​@o2_Matze,

ein weiterer Monat ist rum, inzwischen vier Monate seit die Kollegen das Problem bestätigt haben. Gibt es inzwischen Neuigkeiten?

​@Tumblebit Ich klopfe gerne noch mal bei den Kolleg:innen an, ich gehe aber davon aus, dass der Fehler noch besteht, da hier ja nicht nur bei uns geschraubt wird, sondern auch beim Zulieferer Updates gefahren werden müssen.

VG Matze

​@o2_Matze 

O2 ist da ein richtiger Kulturbereicherer!

„Warten auf Godot“ auf die digitale Version umgesetzt! ;)

Gut Dinge will eben Weile haben, wobei ich hier auch finde, dass das ganze langsam mal gefixt werden könnte 😕 

Da die Lösung allerdings nicht Inhouse bei uns erstellt wird, sind wir da eben noch auf dritte Parteien angewiesen, was es eben immer auch noch mal schwieriger und aufwendiger macht. 

VG Matze 

​@o2_Matze 

Ganz ehrlich?

Ich bin zu arm, um mir immer nur das Billigste zu leisten! Das gilt auch für Hardware, speziell aus China!

--

OffTopic:

;)

/OffTopic:

Edit o2_Matze 11.04.25 17:50 politischen Offtopic Talk entfernt