Mal wieder: Kein IPv6 bei Deutsche Glasfaser

    Zitat von fiberv6

    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.

    Zitat von fiberv6

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

    IPv6 Privacy Extensions erfordern keine kaputten Konfigurationen.

    Für den Datenschutz bei IPv6 sind Endgerät und CPE zuständig, nicht der ISP.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von Funker

    Für den Datenschutz bei IPv6 sind Endgerät und CPE zuständig, nicht der ISP.

    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.

    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

    Niemand identifiziert Haushalte oder Endgeräte mit IP-Präfixen, es ist ja schließlich nicht mehr 1999. Dafür verwendet man heute Fingerprinting, weil Endgeräte heutzutage üblicherweise multi-homed sind dann noch wild durcheinander über mehrere Protokollversionen und CGNs hinweg kommunizieren.

    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.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von fiberv6

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

    Der Cargo Cult geht von einer IP-Protokollversion mit einer globalen Adresse an einer Leitung in einem Haushalt des Jahres 1999 aus.

    Die meisten Endgeräte für Privatkunden haben heute mehrere Funkschnittstellen und sprechen zwei IP-Protokollversionen. Es ist daher absolut sinnlos, diese auf Transportebene identifizieren zu wollen.

    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.

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

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Nur so als kurzen Schnipsel zum Thema identifizieren:

    AliExpress belauscht Nutzer nicht direkt über das Mikrofon, sondern nutzt ein unhörbares „Audio-Fingerprinting“ im Browser, um Geräte ohne Cookies wiederzuerkennen. Wie heise online im August 2026 berichtete, flog diese Tracking-Methode durch den puren Zufall auf, als ein Software-Entwickler Verbindungsprobleme mit seinen Bluetooth-Kopfhörern bemerkte, sobald ein AliExpress-Tab geöffnet war.

    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.

    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.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    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.

    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
  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    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

    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 fiberv6

    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.

    Ich vermute der OLT war gemeint... so etwas wuerde ich eher auf der OLT Seite vermuten also unter direkterer Kontrolle des ISP als in einem ONT. Aber wissen tue ich das nicht!

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von fiberv6

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

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