DSL IPv6 PD DHCPv6 eventueller Fehler seitens O2

Wie kommst du auf einem Juniper Router? Meinst du eventuell die MX960 die die Telekom als BNGs einsetzt? Da o2 L3-BSA schaltet, dürfte die identifikation des Routers von o2 mittels MAC Adresse eher schwierig sein, oder?

Tatsache. Das hab ich jetzt in meiner Eile übersehen zu prüfen. Wenn man die FE80 Adresse zurück auf die MAC rechnet, kommt tatsächlich raus, dass es eine andere Marke sein könnte.

Von der FE80 Adresse auszugehen ist natürlich auch Quark, da die natürlich auch auf sonst was gesetzt werden kann. Daher nicht genau festzustellen was für ein Router es ist, stimmt. :)

Auf jeden Fall Danke für die Korrektur!

Edit o2_Kathi 17.11.24 Vollzitat entfernt

War eher Neugier, aber ich fürchte die Netzstruktur hindert uns da irgendwie ausfindig zu machen welcher Hersteller tatsächlich dahinter liegen mag.

Allerdings konnte ich auf die schnelle auch keinen passenden IANA oder RIPE zugewiesenen Netzbereich zuordnen für “0:80fe::f6e4:51ff:fed3:bc71”, also habe ich entweder tomaten in den augen, oder es ist orgentlich neben den Standard bzw. einen Zahlendreher seitens o2 :D

Edit o2_Kathi 17.11.24 Vollzitat entfernt

Ja das hat mich auch gewundert. Am Ende des Tages ist es aber kein Problem. Mir ist es auch nur aufgefallen, da bei mir noch Legacy Zeug von OpenWrt drin war und es rausgefiltert wurde. So gesehen lags an mir, O2 hat geliefert. :)

Edit o2_Kathi 17.11.24 Vollzitat entfernt

Mmmh, Danke fuer den Hinweis, das erklaert vielleicht meine sporadischen IPv6 Probleme… hin und wieder bekomme ich keine erfolgreiche PD vielleicht aus genau diesem Grund...

Interessant wäre dann natürlich die Quell-IP Adresse(n) bei dir, weil bisher scheint die, die bei aufhaxer verwendet wird “falsch” zu sein.

Damit meine ich, es ist zwar eine IPv6 Adresse die auch gültig sein mag, aber sie ist halt weder in einem “privaten Bereich” wie z.B. FC00::/7 oder im Link Local Bereich (FE80::/64), noch in einem für ISPs zugeteilten Global Unique Bereich (wie z.B. 2a02:3000::/23). Mag zwar technisch funktionieren, und mit etwas geschiktem firewalling und routing möglicherweise keine Probleme verursachen, aber sauber ist es nicht.

Belehrt mich bitte eines besseren, aber ich bin der Ansicht, das sollte sich o2 ansehen, ob das so gewollt ist.

Da bin ich bei dir. Es funktioniert, ist aber definitiv nicht sauber.

Ich weiß nur leider auch keinen besseren Weg als hier im Forum das mal zu melden. E-Mail hab ich leider auf der Website von O2 nicht gefunden und Chat/Telefon hatte ich die letzten Tage keine Zeit…

Vielleicht kann ja ein Community Mod das mal weiterreichen, falls noch nicht geschehen. :)

Edit o2_Kathi 17.11.24 Vollzitat entfernt

Ich versuch mal das ueber tcpdump aufzuzeichnen… mal sehen was da rauskommt. Nur taucht das Problem bei mir nur sporadisch auf, da kann es etwas dauern bis ich genaueres weiss.

Hallo zusammen.

Seht es mir nach, ich hatte ein Semester Informatik an der Uni (da hatten wir noch die D-Mark) und da hab das schon alles gehasst, weil mir das zu hoch war, somit hab ich nur die Hälfte von dem verstanden was ihr so geschrieben habt.

Wenn ihr sagt, dass der Fehler noch vorliegt und da irgendwas kaputt ist tiger ich gerne mal bildlich gesehen ein paar Schreibtische ab und suche jemanden, der die Thematik besser beurteilen kann als ich 😄

VG Matze 

Die im obigen Screenshot verwendeten IPv6 Adressen sollte sich auf jeden Fall jemanden ansehen, insbesondere die hier: 0:80fe::f6e4:51ff:fed3:bc71

Ich weiss zwar nicht ob die Konfiguration in der Zwischenzeit korrigiert wurde, aber da ist durchaus etwas, nennen wir es mal so, fern vom üblichen :D

Keine Sorge, auch die meißten der studierten Informatiker in meinem Umfeld wissen nicht wovon ich rede. :D

Ich habe vor 2 Tagen es nochmal ausprobiert und ich habe weiterhin das gleiche Symptom.

Es wäre schon sehr gut, wenn sich das mal wer anschaut. Das ist eine Kategorie Fehler, den man nicht merkt, weil es “ja eh geht”, aber am Standard vorbei implementiert ist.

Ich steh gerne zur Verfügung, falls jemand von O2 mehr Informationen braucht, oder ich etwas ausprobieren soll.

Edit o2_Kathi 17.11.24 Vollzitat gekürzt

@aufhaxer Nur noch mal zur Sicherheit, damit ich den Kolleg:innen bei meiner Anfrage die korrekten Rahmendaten übermittle:

An die TAE angestöpselt ist nur dein OpenWrt Router, kein anderes Gerät was diesen Trouble verursachen könnte, oder? Also hinter dem Router nicht noch ein weiterer Router, oder vor dem Router noch ein Modem, dass die Einwahl übernimmt etc?  

Es ist noch ein Modem dazwischen. Das hat aber in dem ganzen Spiel keine Rolle außer Modem zu sein.

Alles was Ethernet angeht (inkl. Einwal mit PPPoE) macht der OpenWrt Router. Da die Pakete bereits innerhalb von PPPoE laufen scheint bis OpenWrt alles in Ordnung.

Würde mein Modem etwas durcheinander werfen, würde ich das bei vielen Anderen dingen merken.

Zudem lief alles jetzt jahrelang ohne Probleme mit den Firewall Filtern. Das Problem fiel erst vor 3-4 Wochen auf als ich keine IPv6 PD mehr bekommen habe.

Wie man im initialen Screenshot auch sehen kann, scheine ich die Adresse fe80::f6e4:51ff:fed3:bc71 ohne Probleme empfangen zu können. Es ist nur die Adresse 0:80fe::f6e4:51ff:fed3:bc71 die auf einmal meinen DHCPv6 solicit antwortet seltsam. Die sollte meiner Meinung nach nicht 0:80fe:: haben als Präfix, sondern fe80:: wie in den Paketen zuvor.

Edit o2_Kathi 17.11.24 Vollzitat entfernt

@aufhaxer Alles klar, danke für deine Rückmeldung. Ich leite das mal intern an die entsprechenden Stellen weiter. Sobald ich ein Update habe oder noch weitere Infos benötige gebe ich hier wieder Bescheid. 

VG Matze 

Mmmh, @aufhaxer Du hast den Nagel auf den Kopf getroffen… 
 

12:15:41.058909 IP6 (flowlabel 0x2d3e1, hlim 1, next-header UDP (17) payload length: 109) fe80::251e:31a:f3a4:a2ba.546 > ff02::1:2.547: dhcp6 solicit (xid=15d7ae (elapsed-time 65535) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list SNTP-servers NTP-server AFTR-Name opt_67 opt_94 opt_95 opt_96 opt_82) (client-ID hwaddr type 1 3a146014ec49) (reconfigure-accept) [|dhcp6])
12:15:41.081639 IP6 (hlim 255, next-header UDP (17) payload length: 177) 0:80fe::ae99:29ff:fe6e:30e2.547 > fe80::251e:31a:f3a4:a2ba.546: dhcp6 advertise (xid=15d7ae (client-ID hwaddr type 1 3a146014ec49) (server-ID hwaddr/time type 1 time 766106055 ac99296e30e2) (preference 0) [|dhcp6])
12:16:05.729183 IP6 (flowlabel 0x2d3e1, hlim 1, next-header UDP (17) payload length: 109) fe80::251e:31a:f3a4:a2ba.546 > ff02::1:2.547: dhcp6 solicit (xid=6e0163 (elapsed-time 0) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list SNTP-servers NTP-server AFTR-Name opt_67 opt_94 opt_95 opt_96 opt_82) (client-ID hwaddr type 1 3a146014ec49) (reconfigure-accept) [|dhcp6])
12:16:05.751160 IP6 (hlim 255, next-header UDP (17) payload length: 177) 0:80fe::ae99:29ff:fe6e:30e2.547 > fe80::251e:31a:f3a4:a2ba.546: dhcp6 advertise (xid=6e0163 (client-ID hwaddr type 1 3a146014ec49) (server-ID hwaddr/time type 1 time 766106055 ac99296e30e2) (preference 0) [|dhcp6])

Wenn ich jetzt in meiner OpenWrt firewall die DHCPv6 Regel so aendere:
 

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'
	list dest_ip 'fc00::/6'
	list src_ip 'fc00::/6'
	list src_ip '0:80fe::/6'

also 0:08fe::/6 hinzufuege, dann klappt es auch wieder mit der Praefix Delegation… (mal sehen wie lange).
Mein Bauchgefuehl sagt mir, dass O2 da grundlos ausserhalb des erwarteten agiert, aber ob das tatsaechlich ein IETF SHOULD oder gar MUST verletzt kann ich nicht sagen.

Waere schoen wenn einer von unseren guten und hilfreichen Moderatoren mal versucht bei der Netztechnik/NOC nachzufragen ob das so beabsichtigt ist und so bleiben soll, oder ob das wieder geaendert werden kann.
Der Umstand, dass die 2. Gruppe im IPv6-Prefix 80fe quasi eine Inversion von fe80 ist deutet fuer mich auf Absicht, aber wenn ich wild Spekulieren darf, die 0 in der ersten Gruppe ist vielleicht eher eine unbeabsichtigte Nebenwirkung?

Ah sehr schön. Dann bin ich nicht alleine. Danke, dass du es bestätigst.

Ich glaube die Regel für die Firewall sollte “list src_ip ‘0:80fe::/16’ heißen. damit würde man alle Sub-IPs von 0:80fe:xxxxxx zulassen.

Aktuell seh ich da keine Absicht von O2 dahinter. Durch die Nähe zu der eigentlichen IP die man erwarten würde, seh ich da ein Versehen bei der Konfiguration.

Da ein Moderator ja schon unterwegs ist und das weitergemeldet hat, heißts abwarten und Tee trinken.

Solang es deine Probleme gelöst hat passts ja. :)

Edit o2_Kathi 17.11.24 Vollzitat entfernt

Ich glaube die Regel für die Firewall sollte “list src_ip ‘0:80fe::/16’ heißen. damit würde man alle Sub-IPs von 0:80fe:xxxxxx zulassen.

Ich hatte ueber die Prefixlaenge gar nicht gross nachgedacht und einfach die vom vorhandenen Eintrag stumpf kopiert… Danke!

Wenn man schon dabei ist, fc00::/6 ist, wenn die IPv6 Unique Local Addresses (ULA) gezielt werden, auch die Präfixlänge falsch ist. Die ULA Range ist fc00::/7

https://en.wikipedia.org/wiki/Unique_local_address

scnr :)

Edit o2_Kathi 17.11.24 Vollzitat entfernt

Mir brummelt etwas der Schädel, wenn ich eure Konversation so lese. Man könnte fast den Eindruck bekommen ihr macht beruflich was mit Netzwerken und so 😁  

Aber Spaß beiseite die interne Anfrage läuft, sobald ich News für euch habe gebe ich hier ein Update. 

VG Matze 

Hallo zusammen.

Das Feedback zu meiner Anfrage ist da. Unsere Kolleg:innen konnten sich auch nicht erklären, wo der Präfix bei der fehlerhaften IPv6 Antwortadresse herkommt. Unsere Fachabteilung konnte aber keinen unmittelbaren Fehler in unserem Einflussbereich feststellen

Daher sind wir jetzt natürlich wieder am Anfang, so eine richtige Idee für einen Ansatz dazu hab ich da aber leider auch nicht. 

Besteht der Fehler denn nach wie vor? Und ist das ganze eher eine theoretische Sache, oder seht ihr da wirkliches echtes Missbrauchspotential?  

VG Matze 

Danke für’s nachfragen bei der Fachabteilung erstmal

Naja, da die Pakete (wohl) tatsächlich mit diesen fehlerhaften Präfix ankommen und es bei bestimmte Router (wie OpenWRT) zu Problemen führt, da es keinen Standard entspricht (es musste ja explizit diesen Präfix freigeschaltet werden, damit DHCP6 Pakete ankommen, sonst funktioniert IPv6 einfach nicht) ist es durchaus einen konkreten Anwendungsfall, der duch die Verwendung dieses Präfixes betroffen ist.

Missbrauchspotenzial weiss ich nicht, es bleibt aber einen präfix, der bisher (nach meinem Kenntnisstand) “nicht zur Nutzung freigegeben” ist (wie es halt Global Unique, Link Local, … präfixe sind)

Link Local Adressen (fe80::/10) werden nicht geroutet, daher dürften die immer recht Kundennah sein. Das bedeutet auch, dass die Möglichkeit besteht, dass es auf Infrastrukturanbieterseite/Bitstream hapert, dieser erledigt im Fall von L3-BSA ja auch etwas mehr für o2, als bei L2-BSA.

Da es sich aber hier ja eben nicht um eine Link Local Adresse handelt, kann es durchaus auch sein, dass diese geroutet wird, zumindest jetzt ohne Aspekte wie Hop Limit etc. zu beobachten. Ich habe mal eine Dokumentation gefunden, die sich zumindest erstmal so liest, als wäre eine Link Local Adresse als Quelle “pflicht”, sowie einen Hop Limit von 255 um auszuschliessen dass das Paket geroutet wurde.

Ich muss mir auch mal die versteckten Firewall Regeln von pfSense ansehen, ob bei mir mehr als nur Link Local Adressen erlaubt sind für DHCP6, weil ich habe das Problem (bisher) nicht. Jedoch kann ich das Problem aus 2 Gründen nicht haben:

1. Firewall lässt alles durch, auch “komische” präfixe
2. Bei mir kommen alle IPv6 DHCP6 Pakete über eine Link Local Adresse oder eine Global Unique Adresse, was dann eher in richtung “übliche Konfiguration” geht

Heisst, ich muss schauen welchen der zwei Gründen zutrifft.

Edit:

Ich habe mir mal die rules.debug Datei angesehen und folgendes (zutreffendes) gefunden:

pass in  quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type {128,133,134,135,136} ridentifier 1000000110 keep state
pass in  quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type {128,133,134,135,136} ridentifier 1000000111 keep state
pass in  quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {128,133,134,135,136} ridentifier 1000000112 keep state
pass in  quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type {128,133,134,135,136} ridentifier 1000000113 keep state

→ Es wird zu fe80::/10 nur den Traffic erlaubt, der ebenfalls von Link Local Adressen stammt, bedeutet zweiteres ist der Fall. Wäre das Problem bei mir wie bei aufhaxer und pufferueberlauf0 vorhanden, dürfte bei mir ebenfalls kein IPv6 funktionieren, da die Pakete dann gedroppt werden würden.

23.10.2024
01:42:04.080262 PPPoE  [ses 0x75] IP6 0:80fe::f6e4:51ff:fed3:bcbd.547 > fe80::x:x:x:x.546: dhcp6 advertise

@o2_Matze Sorry meine Antwort hat sich etwas verzögert, da ich beruflich in den USA war.

Das Problem besteht leider weiterhin. Oben ist ein Ausschnitt des mitgeschnittenen Traffics mit, soweit wie möglich, exaktem Timestamp versehen.

Zum Missbrauchspotenzial hat @almightyloaf bereits einiges geschrieben und habe da eigentlich kaum was zu ergänzen. Danke auch an ihn für das verlinken der Dokumentation.

Ich sehe grundsätzlich die Chance für einen Missbrauch als extrem klein an. Defakto schwäche ich durch das öffnen auf nicht-link-local Adressen primär meine Security. Als Workaround habe ich in meiner Firewall die Destination Address auf fe80::/16 gefiltert, um zumindest zu vermeiden, dass jemand theoretisch auf meine Public IPv6 ein DHCPv6 Advertisement schicken kann.

Was natürlich jederzeit passieren kann, ist ein Firmwareupdate von AVM oder dem Routerhersteller der Homespots, die wie bei mir IPs filtern. Sollte mein Problem an anderen Orten auch bestehen, würde das IPv6 an diesen Routern brechen.

Zum weiteren Vorgehen:

Da bin ich leider auch gerade überfragt. Ein anderes Modem/FritzBox mal anstecken auf meiner Seite wäre eine Möglichkeit, habe aber aktuell nichts daheim rumliegen das ich ausprobieren kann. Ich bin aber weiterhin der Meinung, dass es nicht am Modem liegt, da es vor einigen Wochen mit der aktiven Firewallregel funktioniert hat und andere IPv6 Pakete auch nicht verändert werden.

Ich würde mich anbieten mit jemanden von O2 das ganze auch mal Live am Telefon/Videokonferenz auf beiden Seiten zu debuggen und auf den Grund zu gehen. Vielleicht sieht O2 auf ihrer Seite etwas Anderes als ich bei mir empfange. Das würde zumindest die möglichen Punkte wo es schiefgeht eingrenzen.

Ansonsten könnte ich damit Leben, dass es ist, wie es ist. Da aber @pufferueberlauf0 das gleiche Problem hat, bin ich scheinbar nicht der einzige mit dem Problem.

VG aufhaxer

Ich finde die Art der Adresse immer noch auffaellig:

0000:80fe:: statt fe80:0000::

so als waeren die ersten 8 Nibbles in der Reihenfolge invertiert worden… das sieht fuer mich nicht wie ein Zufall aus, daher finde ich es verwunderlich, dass die Technik die Ursache dafuer nicht zu finden scheint, oder keine gute Erklaerung hat warum es gelegentlich zu dieser Addresse aus einem reservierten Bereich kommt.

Ich merke an, dass wenn ich fe8000 in Network-byte-order also BigEndian in little Endian convertiere ich 000080fe erhalte. Das schmeckt ein bisschen wie halb garer Code der die Byte-Order teilweise falsch handelt, z.B. wenn die Adresse auf einer Little-Endian CPU nachbearbeitet wird und dabei die Konversion vergessen wurde.

Hallo zusammen.

Ich habe nach erneuter Rückfrage bei den Kolleg:innen in der Fachabteilung noch mal Feedback bekommen. Ein Fehler unsererseits bzw in unserem Einflussbereich war nicht zu erkennen, daher werden wir hier erst mal so nichts tun können.  

Was ich mit meinen begrenzten IT Kenntnissen und Möglichkeiten aus euren Zeilen aber interpretieren konnte ist, das es sich hier zwar um eine interessante Anomalie handelt, wir  aber nicht über eine kritische Sicherheitslücke sprechen 

Ansonsten könnte ich damit Leben, dass es ist, wie es ist.  

Daher kann ich nur sagen vielen Dank für diese unfassbar spannenden Einblicke ☝😄 

Mir wird immer ganz Angst und Bange, wenn ich dran denke, dass die Kids heutzutage alle nur noch Influencer und Youtuber werden wollen und wir vermutlich -zumindest auf zukünftige IT Probleme bezogen- alle sterben werden, wenn es so unfassbar schlaue Menschen wie euch @almightyloaf @pufferueberlauf0 und @aufhaxer mit diesem detaillierter Wissen nicht mehr geben wird. Ich bekomm dann immer schlimme “Idiocracy” Vibes 🙈😁

In der Hoffnung, dass es nicht so kommen wird sage ich vielen Dank und für euch morgen einen guten Start ins Wochenende.

Gruß Matze