Beiträge von fiberv6

"Modernisierung". Vielleicht sollten sie erstmal einen funktionierenden DHCP Server schreiben.... Oder vielleicht einfach einen funktionierenden Open Source DHCP Server nutzen.

Zitat von ::1

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".

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:....

Zitat von HubeBube

Ich glaube nach wie vor an einen Konfigurationsfehler bei dem neuen Anschluss.

In RFC 6598 wird der Bereich 100.64.0.0/10 für den internen Gebrauch von Internetdienstanbietern (ISPs) bei Carrier-grade NAT (CGNAT) definiert.

Welche VMware MAC-Adressbereiche sind das bei dir?

• 00:50:56 – Standard für vSphere, ESXi und Workstation
• 00:0C:29 – Häufig bei eigenständigen ESXi-Hosts (ohne vCenter)
• 00:05:69 – Ältere ESX- oder GSX-Systeme

Bei dem "alten" funktionierende Anschluss ist es: 00:50:56:.... (VMware)
Bei dem "neuen" problematischen Anschluss ist es: 9c:e0:41:..... (Nokia)

Zitat von ::1

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.

Möglich, aber warum sollten die sich weitere Komplexität einhandeln? Ein Standard ONT ist halt eigentlich super simpel. Wenn ich die ipv4 / ipv6 von dem DHCP server pinge sind das so ca. 5.5 ms. Das wirkt mir ein bisschen hoch um vom ONT zu sein.

Hier mal ein Bild von dem ONT. Es ist kein Hersteller zu erkennen:

Laut mac Adresse : a0:c0:16:.... Sichuan Changhong Network Technologies Co., Ltd.

Auf der Box steht noch HRI-1-GPON-1

Habe seit diesem Wochenende auch Zugriff auf einen weiteren Anschluss von DG. Dieser liegt in einem Ausbaugebiet, das schon vor ein paar Jahren fertiggestellt wurde (Ich glaube ca. 2020, zumindest der DUID Type 1 des Servers zufolge). An dem Anschluss verwende ich OpenWrt. Es gibt einige interessante Unterschiede bezüglich DHCPv4 / DHCPv6. Bei diesem Anschluss scheint das IPv6 prefix stabil zu sein und es gibt keine Probleme bei renewals.

Hier mal die Unterschiede zusammengefast:

Alter Anschluss (ohne Probleme):

DHCPv6 Server mac address (laut DUID): VMware
DHCPv6 Server DUID Type 1 (mac address + time)
DHVPv4 Server IP address: im Bereich 100.64.0.0/10
DHCPv4 antwortet mir mit meiner client DUID Type 4

Neuer Anschluss (mit Problemen):

DHCPv6 Server mac address (laut DUID): Nokia
DHCPV6 Server DUID Type 3 (mac address)
DHCPv4 Server IP address: 192.168.101.1 aus RFC1918 ?!
DHCPv4 Server ignoriert client DUID

Es sieht danach aus, dass die Infrastruktur völlig anders aufgesetzt ist. Bei dem alten Anschluss ist der DHCP server eine VMware VM. Bei dem neuen Anschluss ist es irgendein Gerät von Nokia. Der neue DHCPv4 Server ignoriert die client DUID, während der der alte sie benutzt. Außerdem ist die DHPv4 Server IP völlig bescheuert aus dem RFC1918 Bereich gewählt.

Weiß jemand näheres, welche Software als DHCP Server eingesetzt wird? Ich habe was zum Nokia SR Linux DHCP server gefunden. In der Dokumentation zu diesem steht:"The recommended client identifier type is DUID type DUID-LLT or DUID-LL." https://documentation.nokia.com/outlook_jira_t…hcp-server.html

Es kann also durchaus sein, dass der Wechsel des DUID Type eine Verbesserung bringt. Bisher läuft es jedenfalls.

Ich habe jetzt den DUID Type zu Type 3 (mac address) geändert. Hat soweit schneller geklappt als gedacht. Nach 2 Minuten DHCP solicit (die ersten Versuche blieben unbeantwortet) bekam ich einen neuen lease obwohl der alte lease noch ca 40 Minuten gültig war. Seit dem klappen alle renewals. Erste Leasedauer war wie bisher 10 Minuten, danach 1 Stunde.

Der neue Lease ist auch weiterhin passend zum Schema XXXX:XXXX:XXXX:0A00::/56

Jetzt bleibt abwarten und beobachten.

Zitat von Funker

Da gibt es wesentlich bessere Fingerabdrücke die CloudFlare tracken kann und die sind völlig unabhängig davon, ob DG dir regelmäßig deinen IPv6-Lease zerschießt.

Ja Cloudflare, oder z.B. Google haben wesentlich bessere Möglichkeiten unsere Endgeräte zu tracken.

Aber nicht jeder der etwas von diesem Kuchen abhaben will ist in der selben Situation. LG oder der Hersteller eines WLAN-fähigen Toasters, die probieren andere Geräte in selben Netzwerk (oder vielleicht auch über mehrere Netze hinweg, obwohl die meisten Endgeräte das mittlerweile durch MAC-randomization unterbinden), werden über ARP/NDP alle anderen Geräte in deinem Netzwerk tracken und zusätzlich über deine öffentliche IPv4 bzw IPv6 prefix Buch führen.

Aber dagegen hilft halt ein Wechsel des prefixes oder der IPv4 nicht, da diese Geräte das ja mitkriegen.

Dann kann dein LG Fernseher dir über sein Mikrofon zuhören und diese Daten an Partner verkaufen um dir dann auf deinem Handy im selben Netzwerk passende Werbung zu schalten. Klar Google kann das besser, aber LG möchte es halt auch machen.

Zitat von pufferueberlauf

Stellt sich halt raus, dass fuer die boesen Jungs es oft reich den Haushalt zu identifizieren (gerade bei normalen Endkunden), und dafuer reicht i.d.R. das IPv6-Prefix...
Aber die 24-Stunden Trennung/IP-Neuprovisionierung ist auch keine echte Sicherheitsmassnahme, da geht es ums Ausbalanzieren von Adresspools und vermutlich auch darum Geschaeftskundentarife mit statisch-oeffentlichen IP-Adressen attraktiver zu machen.

Bei meinem DG Problem handelt es sich vermutlich eher um Inkompetenz als um ein geplantes Privacy feature. Da spricht alleine schon der DHCPv4 server mit Adresse im RFC 1918 Bereich für.

Auch ausbalancieren des Adresspools glaube ich nicht. Es ändert sich immer nur der mit "A" markierte nibble bei meinem prefix ("X bleibt immer identisch", und die Nullen auch):

XXXX:XXXX:XXXX:0A00::/56

Sieht für mich so aus als ob sie auch locker genug Platz hätten um mir ein /48 zu geben, aber ich träume 😅

Zitat von pufferueberlauf

Stellt sich halt raus, dass fuer die boesen Jungs es oft reich den Haushalt zu identifizieren (gerade bei normalen Endkunden), und dafuer reicht i.d.R. das IPv6-Prefix...

Je nach dem wer hier die "bösen Jungs" sind bringt halt ein Wechsel des prefixes auch nichts.

LG und co haben ja ein Gerät in dem Netzwerk, welches das neue prefix mitkriegt und nach Hause schicken kann....

Aber das geht vielleicht ein bisschen zu sehr vom Thema ab.

Idealerweise hätte ich gerne keine Trennung. Aber aufgrund der Privacy Argumente gibt es da ja unterschiedliche Meinungen.

Aber auf PPPoE hab ich eher keine Lust.

Zitat von Funker

Zuvörderst würde ich vermuten, dass dort irgendeine Agentic AI freidreht. Das kommt immer häufiger vor.

Wenn das der Fall ist wäre das schon sehr witzig.

"KI gesteuerter DHPCPv6 Server" war echt die Innovation die der Menschheit gefehlt hat. /s

Wenn ich es richtig sehe, ist DUID bei DHCPv4 optional und bei DHCPv6 obligatorisch.

Zitat von ::1

Hm, meines Wissens verwendet DHCPv4 keine DUIDs - ist ein reines DHCPv6-Thema.

Mein Client sendet es als Option 61 auch bei DHCPv4, ist auch erlaubt. Ob der Server sich das anguckt ist natürlich was anderes.

Zitat von ::1

Naja, da setzt sich wieder mal die Privacy-Fraktion durch.

Vielleicht, aber dann hätte ich es in regelmäßigen Abständen und nachts erwartet.

Das letzte mal was es 15.09 um 20:45, davor 14.09. 21:05, davor 06.09 21:11, davor 05.09. 15:54, davor . Also manchmal jeden Tag, dann wieder 1 Woche Ruhe. Merkwürdig.

DHCPv4 nutzt auch aktuell DUID-Type 2. Das funktioniert komplett ohne Probleme.

Zitat von ::1

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?

Nein. Die IPv4 (aus 100.64.0.0/10) ist immer konstant. Wird immer alle 30 Minuten verlängert. Sämtliche Renewals bei IPv4 haben funktioniert.

Zitat von __QT__

Ist das ein Privat oder Business Anschluss? Was ist Deine Erwartung?

Privat. Ich erwarte nicht unbedingt ein stabiles Prefix. 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. Das ich einen neuen Prefix bekomme wenn ich den ONT neustarte oder den Lease ablaufen lasse ist völlig in Ordnung.

Aber die gescheiterten Renewals sorgen halt für einen kurzzeitigen Ausfall der IPv6 Verbindung. Außerdem gibt es absolut keinen Grund dafür. Es ist ja nicht so, dass DG IPv6 Adressen einspart wenn sie das machen.

Alle paar Tage verliere ich den ipv6 prefix und kriege einen neuen. Passiert in unregelmäßigen Abständen. Das letzte mal vor 2 Tagen.

Ich habe pcap Dateien über die gesamte Zeit und schaue mir das mal an. Dieses Wochenende bin ich bei dem Anschluss vor Ort (ist bei meinen Eltern). Habe auch remote Zugriff, möchte aber ungern den anderen DUID-Type ausprobieren ohne vor Ort zu sein.

IPv6 Routing funktioniert seit heute! Ich habe nichts geändert. Gestern hat es definitiv noch nicht funktioniert. War auch noch nicht dazu gekommen einen anderen DUID-Type zu testen. Mal schauen ob das prefix jetzt stabil bleibt.

Nach ein paar Tagen geht es jetzt leider weiter mit nicht funktionierenden DHCPv6 renewals. War Tage lang stabil (ohne funktionierendes routing natürlich), jetzt in den letzten 2 Tagen 2 renewals die nicht funktioniert haben.

Werde nochmal einen anderen DUID-Type probieren vielleicht.