Danke für die Infos. Das überschneidet sich alles mit dem was ich hier sehe.
Hier noch die Vergleichsquelle:
Thread "Kein Traffic über IPv6 möglich (Deutsche Glasfaser)" vom 01.11.2024.
Dort der Fall von sh0rty beginnend mit #115 am 23.01.2026 und sein Paket-Mitschnitt in #119.
Übrigens: In dem Paketmitschnitt, den ich gerade in meinem letzten Beitrag erwähnt habe, lautet der DHCPv4 Server Identifier ebenfalls 192.168.101.1.
Die ipv6 link local von der die Pakete kommen ist fe80::22, also nicht nach EUI-64. Und die mac Addresse passt auch nicht zur server duid. Die ist 20:00:12:....
fe80::22 scheint (an Anschlüssen neuerer Art) die universell vom BNG eingesetzte linklokale (software-generierte) Adresse auf dem Interface zu einem Kundenanschluss zu sein - von dieser Adresse werden auch die RA gesendet, und sie ist somit das dynamisch gelernte Standardgateway.
Ich habe gerade mal in einen Paketmitschnitt eines anderen Falls hier aus dem Forum geschaut: Dort beginnt die zur Adresse fe80::22 gehörende MAC-Adresse mit 20:00:10. Ein OUI-Lookup findet sowohl für 20:00:12 als auch für 20:00:10 keinen Treffer - ich gehe davon aus, dass auch diese MAC-Adressen software-generiert sind.
Die Server-DUID in einem DHCPv6-Paket muss auch nichts mit der MAC-Adresse im Ethernet-Header zu tun haben. Im erwähnten Paketmitschnitt lautet die MAC-Adresse des DUID-Typs 3: 80:b9:46:f0:0d:30 (OUI = Nokia).
ich finde nur "Nokia" als OUI in der DUID des DHCP-Servers "merkwürdig".
Korrigiere: Gar nicht merkwürdig: Nokia -> ehemals N3K -> Cygna Labs ist ein Hersteller u.a. von Enterprise DDI-Lösungen (Aktuell "VitalQIP"), wäre also nicht ungewöhnlich für einen DHCP-Server.
Möglich, aber warum sollten die sich weitere Komplexität einhandeln? Ein Standard ONT ist halt eigentlich super simpel.
Oder nicht im ONT, sondern irgendwo nachgelagert im Pfad zum BNG. Aber ja, ist nur eine möglicherweise blöde Idee. Und was sich DG dabei denken könnte, vermag ich nicht zu beurteilen, ich finde nur "Nokia" als OUI in der DUID des DHCP-Servers "merkwürdig".
DHCPv6 Server mac address (laut DUID): VMware
Ja, das kann ich für meinen Anschluss nach "altem" IPv6-Adressvergabe-Verfahren bestätigen, OUI=00:50:56 (VMware) - Der DHCP-Server ist also eine VM auf ESX.
These: Bei deinem "neuen" Anschluss sitzt womöglich ein DHCP- bzw. DHCPv6-Relay im ONT. Du siehst also nicht den "eigentlichen" DHCP- bzw. DHCPv6-Server (im BNG), sondern nur das dazwischen hängende Relay im ONT.
Aber auf PPPoE hab ich eher keine Lust.
Gibt es bei DG ja auch nicht. Will nur andeuten, dass ein ISP auf Basis von PPP evtl. bessere Möglichkeiten hat, Zwangstrennungen zeitlich zu steuern als ein ISP mit IPoE - dem bleiben nur die Mittel, die DHCP bzw. DHCPv6 bieten. Bei DHCPv6 gäbe es dazu konzeptionell "Reconfigure"-Messages, aber diesbezüglich scheinen evtl. nicht alle Home-Router mitzuspielen. Auch eine bzgl. IPv6 mustergültige Fritzbox hatte vormals an dieser Ecke Probleme - siehe diesen Heise-Artikel.
1&1 (DS-Lite via PPPoE, oder auf Wunsch auch DualStack via PPPoE) scheint das besser zu machen: Dort folgt eine Zwangstrennung auf PPP-Ebene, und zwar täglich in den frühen Morgenstunden, zumindest gemäß meinen Beobachtungen zu einigen RIPE-Atlas-Probes an solchen Anschlüssen.
Zu DUID und DHCPv4 - danke für die Info, kannte ich noch nicht. RFC4361 gibt wohl Aufschluss dazu.
Hm, meines Wissens verwendet DHCPv4 keine DUIDs - ist ein reines DHCPv6-Thema.
Außerdem gibt es absolut keinen Grund dafür. Es ist ja nicht so, dass DG IPv6 Adressen einspart wenn sie das machen.
Naja, da setzt sich wieder mal die Privacy-Fraktion durch.
Aber ich erwarte das ich nicht in unregelmäßigen Abständen einfach so mein DHCPv6-Lease verliere, sogar bevor die aktuelle Gültigkeit abgelaufen ist.
Bekommst du zeitgleich auch eine neue IPv4-WAN-Adresse (aus 100.64.0.0/10)? Oder wechselt die unabhängig von IPv6 zu anderen Zeitpunkten und in anderen Zeitabständen?
Wenn schon, dann sollte DG so etwas nachts zwischen 03:00 und 05:00 machen. Unter Tage ist das nicht akzeptabel.
Vielleicht kannst du in deinem Router per Scheduler einen Trenn-/Reconnect-Task z.B. 03:00 alle 24h definieren? In der Hoffnung, dass DG dir dann für die nächsten 24h stets die Leases verlängert?
Alle paar Tage verliere ich den ipv6 prefix und kriege einen neuen. Passiert in unregelmäßigen Abständen. Das letzte mal vor 2 Tagen.
Ja, du hast einen DG-Anschluss, bei dem DG IPv6-Adressen nach einer "neuen" Systematik vergibt, vgl. #104, deinen Präfix 2a00:61e0:9d00::/41 hatte ich seinerzeit dort ergänzt (jetzt kann man ältere Beiträge ja nicht mehr ändern).
Das bedeutet, dass du im Gegensatz zur "alten" Systematik keine "quasi-statischen" IPv6-Adressen mehr bekommst. Das Verhalten kann man auch bei einigen RIPE-Atlas-Probes an solchen Neu-Anschlüssen der DG sehen, z.b. #29306, #53014, #1001325, #1014833.
Die Änderungsraten sind dabei sehr unterschiedlich. Ich vermute mal, dass du bei einer "Neu-Verbindung", die du selbst im Router auslöst, neue IPv6-Adressen bekommst. Oder der DHCPv6-Server der DG verweigert in bestimmten Zeitabständen einen DHCPv6-Renew mit einem NAK, so dass dein Router im Anschluss einen neuen DHCPv6-Exchange startet, im Zuge dessen neue IPv6-Adressen zugewiesen werden. Ein Paket-Mitschnitt dazu würde mich interessieren.
Irgendwann geht es dann einfach - das wurde auch schon in ähnlich gelagerten Fällen hier im Forum beobachtet. Dann wünsche ich dir mal, dass das auch so bleibt.
Ja, hast du recht. Sollten wir beenden. Die IETF-Position dieser Nebendiskussion ist wohl in RFC7421 nachzulesen.
aber in der 6man Mailing-Liste bist Du mir noch nicht aufgefallen.
Muss man deiner Meinung nach gleich in dieser Liga spielen, um fundierte IPv6-Sachkenntnisse zu besitzen?
Nun mal halb lang, ich habe schon Deine IETF Hausaufgaben fuer Dich gemacht.
Habe den Inhalt deiner verlinkten Quelle gelesen. Da geht es aber primär um die völlig andere Fragestellung, wie viele IPv6-Adressen ein Host aus einem gegebenen Präfix ableiten können soll. Der Autor fordert da ~1k (warum auch immer), woraus dann folgt, dass für die dafür erforderlichen 10 Bits eine Präfixlänge maximal 128-10=118 betragen darf, sofern man mal Prefix-Längen >64 zulassen wollte. Warum man letzteres aber tun sollte, geht aus der Quelle nicht hervor. Insofern ist sie keine valide Referenz zu dieser Fragestellung.
Meinungen, muss man auch nicht mit validen Essenzen unterfuettern koennen, im Gegensatz zu Faktenaussagen.
Naja, was soll man denn von Meinungen halten, die nicht begründet werden? Dann habe ich doch keinen Ansatzpunkt für eine Reflexion, sei dies nun als bestätigende oder widersprechende Aussage. Aber vielleicht erwarte ich hier zu viel. Nichts für ungut.
Dabei werden wir es wohl belassen muessen.
Das ist aber schwach. Wenn man hier Erwartungen oder Meinung äußert, sollte man sie auch valide mit Essenz unterfüttern können.
Wähle aus, welche Kategorien Du erlaubst. Für jede Kategorie kannst Du über „Details anzeigen“ sehen, welche Cookies und Skripte konkret geladen werden, welche Empfänger beteiligt sind und wie lange gespeichert wird.
Weitere Informationen: Datenschutzerklärung · Impressum
