Naja, das ist IMHO etwas ueberraschend, entweder 0000:80fe:: ist beabsichtigt oder Euer NOC sollte versuchen eine nachvollziehbare Erklaerung dafuer zu finden, und wenn es am Vorleister liegt dann muss der Vorleister halt Eurem NOC eine nachvollziehbare Erklaerung liefern. Das einfach so mit einem Schulterzucken hinzunehmen erscheint mit etwas “zu entspannt”.

Wenn wir mal davon ausgehen, dass weder @aufhaxer, noch @almightyloaf noch ich Sicherheitsforscher sind und daher kaum echte Erfahrung im Bewerten von potentiellen Sicherheitsluecken haben, ist es vielleicht etwas optimistisch aus unserer Unfaehigkeit auf die Schnelle einen Exploit zu erfinden zu schliessen, das ganze waere ein gutartiges Phaenomen. Versteh mich nicht falsch ich finde es grossartig, dass Du Dich darum gekuemmert hast und ich vermute auch die Technik/das NOC wird im Hintergrund mehr machen/gemacht haben als das nur abzunicken, aber ich bin nicht sicher ob die kommunizierte Coolness tatsaechlich die beste Strategie waere.

@pufferueberlauf0 Wenn ich hier mit euch schreibe denke ich, ich bin hier der Blinde, der mit euch über Farbe spricht, um das mal etwas bildlich greifbarer zu beschreiben .

Ich bin mir aber sicher, dass die Kolleg:innen diesen Part  

Wenn wir mal davon ausgehen, dass weder @aufhaxer, noch @almightyloaf noch ich Sicherheitsforscher sind und daher kaum echte Erfahrung im Bewerten von potentiellen Sicherheitsluecken haben, ist es vielleicht etwas optimistisch aus unserer Unfaehigkeit auf die Schnelle einen Exploit zu erfinden zu schliessen, das ganze waere ein gutartiges Phaenomen

durchaus in Ihre Analyse mit einbezogen und bewertet haben 

Dennoch nehme ich eure Bedenken dazu der Vollständigkeit halber auf jeden Fall noch mal mit und werde das an entsprechender Stelle anbringen.

VG Matze 

Dazu nicht zu vernachlässigen, dass Routerhersteller (bzw. mindestens 2 davon: Netgate (für pfSense) und OpenWRT) ja irgendwo erwarten dass Internet Service Providers sich am Standard halten, somit folglich die Firewall so vorkonfigurieren, wie bei aufhaxer, pufferueberlauf0 und bei mir.

Sehr wahrscheinlich machen das auch mehr als die beiden oben genannten Hersteller, aber bei denen haben wir geprüft dass die Aussage stimmt.

Somit wären die Kunden die Router einsetzen, die nicht-standard Konfigurationen sperren, vom Problem betroffen. Die meisten natürlich ohne es zu merken - “dank” IPv4 fallback.

Daher sehe ich es wie pufferueberlauf0, wenn es nicht von eure Technik kommt (was durchaus möglich ist, ich glaube auch nicht dass Router Advertisements gross geroutet werden sollten, daher könnten sie relativ Kundennah “generiert werden”), muss man den Vorleister dazu animieren seine Infrastruktur auf die Reihe zu bekommen.

Letztendlich haben wir hier ja nicht genügend Futter um zu behaupten es läge z.B. am BNG, indem man mehrere Anschlüsse in der Umgebung mit verschiedenen Internet Service Providers (darunter auch Internetprodukte des Infrastrukturbetreibers), aber gleichen BNG monitort etc… Wäre dies der Fall, gäbe es dann durchaus möglicherweise andere Kanäle die man ansprechen könnte, aber o2 ist hier als Vertragspartner der Ansprechpartner, auch für Fremdinfrastruktur. Ggf. sollte o2 dann mithilfe der Bundesnetzagentur einen eventuell Kooperationsunwillgen Infrastrukturbetreiber es schmackhaft machen zu kooperieren, wenn o2 dadurch seine Produkte nicht einwandfrei an seine Kunden bringen kann.

Hallo Matze et al.,

ich beobachte dasselbe Problem (VDSL 250 MBit, München), was meiner Meinung nach doch sehr auf “ein Fehler im Einflussbereich von O2” hinweist. Hier ist eine Unifi Dream Machine Pro betroffen, die ebenfalls über eine Firewall-Regel die DHCPv6-Antworten verwirft. Bei mir hilft leider nicht, eine Firewall-Accept-Regel einzufügen, offensichtlich erwarten weitere Schichten in der Implementierung eine RFC-Konformität.

Ich würde mich freuen, wenn man/Du (nochmals) bei der Fachabteilung anklopft, für mich ist so kein IPv6 nutzbar. Im Januar soll Glasfaser über O2 verfügbar werden und ich plante ein Upgrade, aber so werde ich wohl einen anderen Anbieter wählen…

Moinsn,

ich bin von dem Problem nicht betroffen, da ich (aktuell) gar kein o2 DSL habe. Ich mache aber seit 15 Jahren embedded Software und habe in der Zeit schon viele Pferde, äh compiler kotzen sehen.

Wie @pufferueberlauf0 ja bereits korrekt beschrieben hat ist 0:80fe die little endian Repräsentierung von fe80:0. Als Softwerker war mein erster Gedanke: Softwarebug.

@o2_Matze Computersysteme kennen keine “Anomalien”, Computer die frei von Software- und Hardwarefehlern sind, sind deterministisch. Allerdings ist meistens Erstgenanntes nicht gegeben. Deine “Anomalie” ist also ein Euphemismus für Softwarebug (oder, aber eher unwahrscheinlicher Hardwarebug).

Aber egal, ihr habt doch sicherlich bzw. euer Netzwerkteam einen Bugtracker? Kannst du da keines erstellen?. Hier mit Formulierungshilfe:

In unpredictable circumstances the Telefonica core network responses to dhcpv6 client requests from customer’s endpoint with an invalid src address (0000:80fe... instead of fe80:0000 which is obviously fe80::0000 written as little endian) causing customer’s endpoints to correctly drop the specific packets. Once the incorrect src address is used subsequent responses do also have the incorrect address. Customers discovered the issue because they lose their IPv6 connectivity after a while

Grüße

Stefan

Ich möchte kurz erwähnen, ich habe das Problem ebenfalls. Router ist FreeBSD mit PF als Firewall. Auch hier hat eine Anpassung der Firewall geholfen. Das Problem aus Sicht von dhcp6c mit einem Advertise von einer ominösen 0:80fe:: Adresse:

# dhcp6c -Dfc /usr/local/etc/dhcp6c.conf pppoe0
...
Nov/02/2024 00:09:21: send solicit to ff02::1:2%pppoe0
Nov/02/2024 00:09:21: reset a timer on pppoe0, state=SOLICIT, timeo=0, retrans=1091
Nov/02/2024 00:09:21: receive advertise from 0:80fe::1689:cbff:fe2c:1be9 on pppoe0
Nov/02/2024 00:09:21: get DHCP option client ID, len 14
Nov/02/2024 00:09:21:   DUID: 00:01:00:01:27:d7:6c:f1:00:e0:67:22:3e:c0
Nov/02/2024 00:09:21: get DHCP option server ID, len 14
Nov/02/2024 00:09:21:   DUID: 00:01:00:01:2c:b1:b3:e2:14:89:cb:2c:1b:e9
Nov/02/2024 00:09:21: get DHCP option preference, len 1
Nov/02/2024 00:09:21:   preference: 0
Nov/02/2024 00:09:21: get DHCP option IA_PD, len 54
Nov/02/2024 00:09:21:   IA_PD: ID=1, T1=86400, T2=138240
Nov/02/2024 00:09:21: get DHCP option IA_PD prefix, len 25
Nov/02/2024 00:09:21:   IA_PD prefix: 2a02:3100:xxxx:xxxx::/56 pltime=172800 vltime=259200
Nov/02/2024 00:09:21: get DHCP option status code, len 9
Nov/02/2024 00:09:21:   status code: success
...

Das ist kein Sicherheitsproblem, es ist einfach nur kaputt. Es scheint für viele hier inklusive mir zu funktionieren, weil sie das technische Verständnis haben und sich ihre Router so konfigurieren lassen, dass auch kaputte Konfigurationen auf der Providerseite funktionieren. 

Warum kann ich sagen, das ist kaputt? RFC 3513. Diese Adresse wäre eine Globale Unicast Adresse mit den ersten 3 Bits auf 0 gesetzt. Das könnte dann entweder eine GUA sein, die eine IPv4 Adresse kodiert oder eine NSAP Adresse. Beides ist hier aber eindeutig nicht der Fall und ergäbe im Kontext von DHCP auch genau gar keinen Sinn...

Zudem entpricht wie von anderen bereits erwähnt 0000:80fe: exakt der erwarteten Link-Local Adresse beginnend mit fe80:0000: wenn man fehlerhaft zwischen little und big endian konvertiert.

Warum kann ich sagen, das ist kaputt? RFC 3513. Diese Adresse wäre eine Globale Unicast Adresse mit den ersten 3 Bits auf 0 gesetzt. Das könnte dann entweder eine GUA sein, die eine IPv4 Adresse kodiert oder eine NSAP Adresse. Beides ist hier aber eindeutig nicht der Fall und ergäbe im Kontext von DHCP auch genau gar keinen Sinn…

Das Problem scheint zu sein, dass das NOC hier nur auf Sicherheitsluecken anspringt… 

Ich finde erstaunlicher an der ganzen Sache, dass da kein Interesse kommuniziert wird der Sache auf den Grund zu gehen. Es ist eine Sache wenn O2 (oder ein Vorleister wie die Telekom) bewusst und mit voller Absicht mit 0000:80fe: arbeitet (und auch ungluecklich aber fuer mich nachvollziehbar wenn der eigentliche Grund selber nicht an End-Kunden kommuniziert wird, aber zumindest ein “wissen wir, machen wir mit Absicht” sollte man schon weiter geben), aber eine komplett andere wenn O2 denkt fe80:0000: zu senden, aber 0000:80fe: kommt an… Das sollte, zumindest meinen Laienverstaendnis nach, das O2-NOC in den Sherlock Holmes Modus versetzen… aber hey, vielleicht haben die groessere Feuer zu loeschen und schlicht keine Zeit fuer kleinere Problemchen fuer die wenigen Kunden denen das auffaellt einen Work-Around gefunden haben. ;) 

Wird IMHO Zeit, dass BEREC und BNetzA regelkonform funktionierendes IPv6 als nincht-optionalen Bestendteil eines Internetzugangs festlegen… aber das halte ich generell fuier eine gute Idee, und O2, 0:80fe: Praefix hin, 0:80fe: Praefix her, ist IMHO bei IPv6 klar auf der Seite der ISPs die das richtige machen (z.B. im Vergleich zu den ISPs die IPv4-only per CG-NAT anbieten...)

Jaein, den Hop-Limit wäre hier interessant, in der reine Theorie, und von dem was ich so lesen konnte, dürften diese Pakete auch nicht wirklich geroutet werden. Aber ich möchte eine Fehlinterpretation von RFC4861 meinerseits nicht ausschliessen.

Wenn die Pakete nicht geroutet werden dürften, o2 auf ihre Seite keine Fehlkonfiguration entdeckt und zusätzlich Layer 3 BitStream im Einsatz ist, könnte man durchaus, in meinen Augen, den Vorleister hier in Betracht ziehen. Jedoch ist das Sache von o2, da o2 für uns als Vertragspartner eben auch die Kontaktstelle ist bei Störungen. Wie o2 letztendlich sein Produkt realisiert, ist ja aus Kundensicht erstmal weniger relevant.

o2 bzw. Telefonica scheint durchaus, mindestens hier, recht IPv6-Friendly zu sein. Sie hatten auch auf der Corporate Webseite den IPv6-Siegel, haben IPv6 ins Mobilfunknetz recht proaktiv aktiviert etc. Ebenso sind die meisten o2 Seiten (Corporate, o2online, community, ...) per IPv6 erreichbar.

Fehlt nur noch das proaktive aktivieren von IPv6 bei den älteren “Festnetz”-Verträgen die es noch nicht haben :)

Da kommt es auf das Verständnis von “Einflussbereich” an. Ich hab ja absichtlich nicht “Verursacher” geschrieben - ich hoffe doch, dass O2 auch Einfluss auf Vorleister hat.

So. Meine letzte Antwort ist jetzt 3 Wochen her und wollte mal wieder reinschauen, ob sich was getan hat zu dem Thema und bin doch erstaunt (aber nicht wirklich überrascht), dass es sowohl in diesem Thread, als auch in einem anderen Thread hier im Forum doch noch einige Leute mehr betrifft.

Es ist zwar schmeichelnd, so Honig um den Bart geschmiert zu bekommen und ich den Einsatz der Moderatoren hier durchaus schätze, aber es ist schade, dass es seitens O2 sehr wenig Kommunikation zu dem Thema gibt. Aktuell sammeln sich die Beschwerden, aber keine Antworten…

Ich muss leider sagen, dass ich meine Aussage, “Ich kann damit Leben”, ehrlich gesagt aktuell bereue und gerne revidieren möchte.

Angesichts der Tatsache, dass aktuell sogar Kunden mit FritzBoxen Probleme mit der Verbindung haben und ich nicht einmal im Entferntesten abschätzen kann, wie die Dunkelziffer dahingehen aussieht, möchte ich gerne wissen, wie man denn dem Thema mehr Druck verleihen kann ​@o2_Matze ?

Es scheint ja genug Menschen zu geben, die hier die Expertise aufweisen um in diesem Thema zu helfen. Warum wird das nicht gentuzt? Pauschal hören sich die offiziellen Aussagen danach an, als wär das Problem nicht Seitens O2 zu finden und defakto der User beschuldigt. Die aktuelle Datenlage die sich hier im Forum findet zeigt aber m.E. was anderes auf. Es sind so viele Variationen an Setups, dass es an den Einzelnen Leuten nicht liegen kann. Sogar FritzBoxen sind betroffen.
Entweder die Infrastruktur von O2, der darunterliegende Reseller der Physischen Infrastruktur, oder ein Zulieferer von HW/SW machen da IMHO aktuell Probleme.

Je mehr Zeit vergeht zu dem Thema, finde ich es umso mehr eine Schlamperei sein Netz nicht RFC Konform zu betreiben. Ich will eigentlich weg von dem Workaround, den meine Mitstreiter und ich hier einbauen müssen. Und da schätze ich mich glücklich, dass ich einen habe. Andere können nichts tun außer damit zu leben solange O2 der Vertragspartner ist.

Wenn es hilft, hier jeden Tag einen TCPdump Ausschnitt zu posten und das Thema aktuell zu halten, mach ich das.
Wenn es hilft, jeden Tag am Telefon Terror zu machen, mach ich das.
Wenn es hilft die BNetzA zu aktivieren, mach ich das.

Ein Update seitens O2 wäre glaube ich hier gerne gesehen. Zumindest mal, ob man an dem Thema dran ist oder nicht.

P.S. ​@o2_Matze deine Ausführungen hören sich an, als würden die Leute mit Ahnung die nächsten Jahre sterben. Ich kann nur für mich sprechen und sagen: Nach aktuellem Stand darf ich noch länger arbeiten bis zur Rente, als ich bisher gelebt habe. Ich hoffe also doch in der Zeit die nächste Generation mit aufbauen zu können. :)

​@o2_Matze: Vielleicht ist auch von Interesse, dass das Thema jetzt auch die Aufmerksamkeit von Fefes Blog gefunden hat: https://blog.fefe.de/?ts=99d87b8b

Zu Fefe und seiner Reichweite im Technikbereich kann man ja mal googlen… ;-)

Update: Oder für die “Faulen”: https://de.wikipedia.org/wiki/Fefes_Blog

Hmm da bin ich mir aber nicht so sicher, ob das eine mit dem anderen zu tun hat.

Es gibt halt dort erstmal keine Anzeichen, dass es an fehlerhaft (wahrscheinlich durch diesen Big/Little Endian Thema) ankommende IPv6 Source Adressen liegt.

Heisst für mich kann der im oben verlinkten Thread vorhandenen Problem auch durch etwas anderes verursacht werden, als das worüber man hier diskutiert.

Es dürfte aber mittels eines komptatiblen DOCSIS Modem prüfbar sein, imo.

Ein Packetcapture ware auch im (SOL) Fehlerfall interessant…

​@Tumblebit Na klar kenn ich den Felix (leider nicht persönlich), die frühen Folgen seines Alternativlos Podcasts hab ich damals immer zum Einschlafen gehört, die sind legendär. Ich mag den sehr, ganz unumstritten ist er in der Szene ja nicht, aber die Fachexpertise und einen großen Unterhaltungswert kann man ihm sicher nicht absprechen. 

Ich hab zwar immer noch das Gefühl, das wir hier über einen Fehler sprechen, der nur auftritt, wenn Weihnachten in einem Schaltjahr auf einen Dienstag fällt und den man wirklich explizit suchen muss, da er sonst gar nicht auffallen oder stören wurde und nur eine Handvoll User tangiert, ich bin aber auch schlau genug zu erkennen, das ich ggf. die Tragweite dieses Fehler gar nicht kompetent genug einschätzen kann  

Daher schicke ich das ganze noch mal an einen anderen internen Verteiler zur Draufsicht, mit dem Hinweis, das Fefe das ganze auch nicht schick findet und schaue mal, was die Kolleg:innen mir antworten. 

Beste Grüße Matze

Hallo ​@o2_Matze ,

vielen Dank, dass Du Dich der Sache nochmals annimmst!

Ich kann für mich sagen, dass der Fehler reproduzierbar immer auftritt, nicht nur wenn Weihnachten mit Zusatzbedingungen ist. Und er verhindert bei mir die Nutzung von IPv6, was ich nicht explizit suchen musste, sondern was mich zur Suche veranlasst hat. Und es stört durchaus: Ich kann diese Technologie nicht nutzen.

Man kann sich jetzt so aufstellen, dass man (vermutlich korrekterweise) nur eine kleine, technisch versierte Gruppe als Betroffene sieht - aber das sind diejenigen, die die weniger technikaffinen Nutzer als Experten zu Rate ziehen, wenn es um die Frage geht: Bei welchem Anbieter soll ich mir denn meinen Anschluss holen? Was kannst Du empfehlen?

Bisher war meine Antwort: Geht zu O2, da bin ich auch, der Service ist gut, Internet ist schnell, es gibt Dual Stack statt CGNAT oder DSLite.
Ich würde mich freuen, wenn ich jetzt noch hinzufügen könnte: O2 nimmt auch Fehlermeldungen von Nutzern ernst und geht Ihnen nach und fixt sie. Im Augenblick klingt es eher wie: Deren IPv6 ist kaputt und es kümmert sie nicht.

Update: Ich habe gerade mal wieder einen schnellen Test gemacht, das Problem mit den DHCP6-Nachrichten von der falschen Adresse besteht immer noch.
ABER: Dazwischen hat sich eine ICMPv6-Router-Advertisement-Nachricht geschlichen. Und siehe da, diese hat die korrekte Adresse!

0:80fe::f6e4:51ff:fed3:bcbd ← Adresse der DHCP-Nachricht
fe80::f6e4:51ff:fed3:bcbd ← Adresse der RA-Nachricht

Offensichtlich gibt es also ein Modul, was die korrekte Adresse verwendet, was meiner Ansicht nach nur noch deutlicher unterstreicht, dass die Adressierung der DHCP-Nachricht ein Defekt ist.

Vielleicht hilft diese Information auch in der Diskussion mit der Technik, ich hoffe es!

 ​@Tumblebit Lieben Dank für fixe Antwort Hierzu:

möchte ich kurz anmerken, das wir jede Fehlermeldung ernst nehmen. Meine Antwort lässt sich sicher in die Richtung interpretieren, das wir das nicht tun. Dies ist sicher meiner Form und Wortwahl geschuldet, daher Excusez Moi, das war mitnichten meine Absicht und wahrscheinlich eher der vielen Fragenzeichen geschuldet, die sich jedes mal vor meinem geistigen Auge auftun, wenn ich hier den Thread überfliege (das wäre ich, nur weniger attraktiv und eher noch 50 % more confused) 

VG Matze

Da hätte ich mich wohl genauer ausdrücken sollen. Ich bezog mich eher auf diese Aussage:

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

Dass Du uns hier überhaupt Rede und Antwort stehst, halte ich nicht für selbstverständlich und daher lobenswert. Aber von “der Fachabteilung” fühle ich mich nicht gerade ernst genommen…
Ich hoffe, die zusätzlichen Informationen (siehe Router-Advertisement-Nachricht oben) helfen Dir, für uns zu kämpfen!

Moin in die Runde,

da hier ja offensichtlich noch betroffene User gesucht werden, möchte ich mich hier auch einmal zu Wort melden.

Ich habe an meinem Mikrotik CCR2004-16G-2S+ das selbe Problem habe. Das ist natürlich ein etwas professionelleres Gerät, an dem ich die RFC Non-Compliance von O2 explizit umschiffen konnte, bin mit dieser Lösung allerdings auch sehr unglücklich. Solche RFCs existieren nicht zum Spaß und sind mehr oder minder die Gesetze der IT.

Noch ist das alles unproblematisch, da die Masse der Consumer Hardware die RFC Compliance nicht erzwingt, aber ich gebe einfach mal zu bedenken, was passieren würde, wenn sie das auf einmal tut.

Geht O2 dann zu AVM und sagt: Yo baut das mal eben wieder so um, dass unser RFC widriges Setup mit eurer Hardware funktioniert, weil uns unsere Kunden gerade die Bude einrennen?

Das ist einerseits nicht gut fürs Image des Unternehmens und andererseits ist in dieser Situation offensichtlich, wer schuld ist: nämlich O2.

Ein Unternehmen dieser Größe sollte eigentlich ein Change Management vorweisen können und darüber sollte in etwa nachvollziehbar sein, wann das Problem durch welche Aktion eingeführt wurde. Und etwaige Vor-Dienstleister sollten das im Regelfall auch haben.

Das nur als ein paar Hinweise von mir als einer von vielen Berufs-ITlern hier in diesem Thread.

Gruß,
who

Naja, genau bei den Punkt ist es nicht ganz klar. Router Advertisements sollen möglichst nicht geroutet werden, wiederum nutzt o2 L3-BSA, was relativ Kundenfern ist, im Vergleich zu (z.B.) L2-BSA.

Daher habe ich da durchaus erstmal wenig Probleme damit, wenn o2 auf ihre Seite keinen Fehler findet. Allerdings müsste o2 dann zusammen mit ihre Infrastrukturbetreiber die Sache analysieren, sofern o2 belegen kann dass auf ihre Seite der Fehler nicht besteht.

Was wir nicht wissen, ist wie und wie tief die relevante Abteilung geprüft hat, genauso wenig wie es bei Anschlüssen anderer Wettbewerber auf dem gleichen BNG aussieht.

Jedenfalls stellt sich o2 hier aber auch nicht so, als wären sie die Besten, es sei alles top und es wird nichts dran gemacht oder geschaut, sondern es wird ja aktiv und konstruktiv das Thema angegangen, auch wenn es sicherlich schneller/besser gehen könnte etc.

o2 hat aber auch sicherlich dringendere Baustellen, als eine die ein normaler Kunde kaum/gar nicht spürt, egal wie unschön das jetzt sein mag. Trotzdem teile ich auch wiederum deine Meinung, es wäre schön wenn o2 sich hier stärker profiliert, aber da macht man schon die büchse der Pandora auf, wofür (vermutlich) die verfügbaren Ressourcen einfach nicht reichen.

​@almightyloaf Hm, habt ihr vielleicht Freunde oder Bekannte aus euren “Informatikerkreisen” bei anderen DSL Anbietern, die auch mal so einen Troubleshoot laufen lassen könnten, um dann zu schauen, wie sich der Fehler bei Provider XYZ darstellt? Andere Providerkunden zu finden, die über den gleichen BNG laufen ist sicher nicht so einfach, aber vielleicht habt ihr Glück?  

​@whoami0501 Wow, für was braucht man denn im normalen Leben ein Mikrotik CCR2004-16G-2S+? 

Für den Privatgebraucht und die Standardanwendungen ist das aber schon etwas überdimensioniert, oder nicht? Also ganz erst gemeinte Frage. Was machst du mit so einem krassen Raumschiff 

Auf jeden Fall vielen Dank für deine Infos und deine Meldung, umso mehr wir da an validen Daten haben umso besser, falls wir am Ende diese doch für Tickets oder die weitere Recherche brauchen. 

VG Matze

Naja, mein Anschluss ist bisher von diesem Problem nicht betroffen, ich konnte lediglich prüfen, dass standardmässig mein Router ebenfalls Pakete die nicht von einer Adresse im Bereich von fe80::/10 gesendet  werden verwerfen würde, so wie eben auch bei (z.B.) pufferueberlauf0 mit OpenWRT.

Allerdings fehlt mir ebenfalls die Möglichkeit, andere Anschlüsse im selben PON ausreichend zu monitoren, jedoch gab es hierzu auch kein Bedarf, da ich die Probleme an meinem Anschluss bisher auch (erstmal) anderweitig eingrenzen konnte.

Kurzes Update: Wir haben unsere Fühler in alle Richtungen ausgestreckt und die Anfragen laufen, da wir hier aber über ein hochkomplexes Spezialthema sprechen braucht das ganze entsprechend, habt daher bitte (etwas mehr) Geduld (als sonst) mit uns  

Lieben Dank.

VG Matze 

Schließe mich an, gleiches Problem hier. Aber nicht immer. Passiert seit ein paar Wochen, hatte schonmal gesucht und nachdem es heute wieder passiert war, glücklicherweise diesen Thread hier gefunden.

Nach einem Neustart meines Servers klappt die erste Verbidung bislang immer.

Jede Nacht komme ich der Zwangstrennung durch einen “/bin/kill -HUP $(cat /var/run/ppp0.pid)” zuvor.

Spätestens nach ein paar Tagen tritt dann das Phänomen Byte-order-verkehre LL-Adresse für DHCPv6-Replies auf. (Weiter habe ich noch nicht geschaut, also ob ich auch schon eine verdrehte Adresse als lokale LL-Adresse bekomme, was das pppd-Log dazu sagt etc. - Server muss laufen, Familie...)

Ein Neustart des Servers und es ist erstmal wieder ok.

Das Erlauben der verdrehten Adresse in der Firewall könnte durchaus problematisch sein. Ich habe meine NFT-Regel entsprechend angepasst:

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

Daraus wird aber dummerweise (nft list-ruleset):

ip6 saddr { ::/16, fe80::/10 } ip6 daddr { ::/16, fe80::/10 } udp sport 547 udp dport 546 accept

Und das ist möglicherweise nicht so schön. ;)

Sind IPv6-Adressen mit 0000:: überhaupt gültig? Hab jetzt nicht geschaut.

Viele Grüße

Sven

Hi ​@Gong1234 

Willkommen zurück nach so langer Zeit hier in unserer o2 Community

Ich persönlich hatte auf deine Frage

keine Antwort, ein Kollege schrieb mir dazu gerade

“0000:: Adressen mit solch einem Präfix sind gültig und werden bei bestimmten Begebenheiten innerhalb von IPv6 verwendet.”

Ich bin jetzt nicht schlauer als vorher, aber vielleicht hilft dir der Satz ja weiter

VG Matze 

P.S  At all 

Anfrage ist weiterhin on going, ich bzw. wir haben euch nicht vergessen