Deutsche Glasfaser: Keine IPv6-Adresse

    Hallo zusammen,

    gestern habe ich testweise auf derselben Hardware (MAC-Adressen blieben also unverändert) ein OPNsense Live ISO gebootet. Prompt waren IPv6-Adresse und Standardroute da. Da kommt natürlich sofort die Frage auf, warum VyOS von heute auf morgen nicht mehr funktionierte und die OPNsense sofort...

    Nach längerer Debugging-Session fand ich heraus, dass Deutsche Glasfaser offenbar keine DUID-UUID (Type 4) mehr akzeptiert. FreeBSD bzw. OPNsense verwendet dagegen offenbar DUID-LLT (Type 1)

    Der Vollständigkeithalber:
    DUID-LLT (Type 1): using Link-Layer address plus Time
    DUID-EN (Type 2): using vendor assigned Enterprise Number
    DUID-LL (Type 3): using Link-Layer address
    DUID-UUID (Type 4): using a Universally Unique Identifier (UUID)

    Nachdem ich die DUID in VyOS ebenfalls auf Type 1 umgestellt habe, kam dann auch sofort eine DHCPv6-Antwort - samt Präfix; aber immer noch keine Default-Route. Zehn Minuten später traf dann zwar ein Router-Advertisement ein, doch dessen Router Lifetime war auf 0 Sekunden gesetzt und wird damit natürlich nicht in die Routing Table installiert, vermutlich vom standby Router in dem Segment...

    Irgendwann dann endlich das richtige RA

    tcpdump -s0 -vvv -n -i eth2 -c 1 'icmp6 && ip6[40]==134'
    tcpdump: listening on eth2, link-type EN10MB (Ethernet), snapshot length 262144 bytes
    10:04:48.177385 IP6 (class 0xe0, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::ff:fe01:101 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 32
    hop limit 64, Flags [managed], pref medium, router lifetime 1800s, reachable time 0ms, retrans timer 0ms
    source link-address option (1), length 8 (1): 02:00:00:01:01:01
    0x0000: 0200 0001 0101
    mtu option (5), length 8 (1): 1500
    0x0000: 0000 0000 05dc
    1 packet captured
    1 packet received by filter

    Fazit: Deutsche Glasfaser bastelt und macht Changes ohne das irgendwie zu Dokumentieren und Leute mit Kundeneigenem Router dürfen im Nebel rumgeistern. Support weiss von garnichts. Von Heute auf Morgen: Type 4 DUID = wir reagieren garnicht mehr. Das ganze Setup war 1 Jahr lang stabil vorher, bis auf eine Outage in Januar die sich von Heute auf Morgen in Luft aufgelöst hatte. Erschwertes Troubleshooting: Solange der DHCPv6 Handshake in die Hose geht (und es kommt ja überhaupt gar kein Reply auf die DHCPv6 SOLICITS mit falscher DUID) + eine v4 auf dem Interface aktiv ist, schickt Deutsche Glasfaser dann auch keine UNSOLICITED RAs mehr und man sucht sich einen Wolf was überhaupt los ist - es sieht dann aus als wird sämtlicher IPv6 Traffic verschluckt.


    *seufz* - normalerweise muss der Support sowas sofort in den Logs sehen und nicht 2 Wochen den Kunden vertrösten mit ERLOGENEN Status Mails.

    Zitat von pufferueberlauf

    Ich wuerde ja naiverweise erwarten, dass ein ISP so etwas in seiner Schnittstellenbeschreibung dokumentieren muesste... aber ich vermute, die BNetzA duerfte das anders sehen...

    Wenn es einstellbare Parametrierungen sind, die bei unterschiedlichen OS unterschiedlich vorab eingestellt sind, gehört das wohl in die Dokumentation. Sonst fängt sich auch die BNetzA etwas ein. Das TKG nennt nämlich keine Abhängigkeit von bestimmten User-OS.

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

    Hallo zusammen,

    gestern habe ich testweise auf derselben Hardware (MAC-Adressen blieben also unverändert) ein OPNsense Live ISO gebootet. Prompt waren IPv6-Adresse und Standardroute da. Da kommt natürlich sofort die Frage auf, warum VyOS von heute auf morgen nicht mehr funktionierte und die OPNsense sofort...

    Nach längerer Debugging-Session fand ich heraus, dass Deutsche Glasfaser offenbar keine DUID-UUID (Type 4) mehr akzeptiert. FreeBSD bzw. OPNsense verwendet dagegen offenbar DUID-LLT (Type 1)

    Gute Analyse. Vielleicht hilft es einem anderen Betroffenen.

    Zitat von mbo77

    Gute Analyse. Vielleicht hilft es einem anderen Betroffenen.

    Wenn dieses denn auch wirklich der Grund ist, ist ja auch alles nur Theorie auf Basis des beobachteten Verhaltens. Was mich ärgert ist, dass man bei der Deutsche Glasfaser niemanden aus dem 3rd Level mal zu greifen bekommt und einfach mal ein paar Fakten schafft. Die Anleitung für Kundeneigene Router ist der total Witz, bezieht sich natürlich auch nur auf Fritzboxen und enthält 0 hilfreiche Angaben.

    Witzigerweise, in https://datatracker.ietf.org/doc/html/rfc6355 ": IANA has assigned the value 4 for use by the DHCPv6 DUID-UUID type.
    Sollte also als Standard auch Unterstützt werden; welchen Grund sollte es geben diese Requests abzublocken?


    Pest vs. Cholera - aber ich ziehe wirklich in betracht zu Vodafon Glasfaser im Business Tarif zu wechseln, da ist immerhin noch feste public IPv4 und statischer IPv6 Prefix gegen 5 Euro Aufpreis möglich - und ehrlich, ich war früher da als Kabelkunde (auch Business); so schlecht wie der DG Support ist der Vodafon Support dann auch nicht.

    Zitat von CruxTheFirst

    welchen Grund sollte es geben diese Requests abzublocken?

    Vielleicht blocken sie alle DUID-types (also 2 und 4), die _nicht_ die Link-Layer address enthalten. Evtl. weil sie auf Basis der DUID-types 1 und 3 und der darin enthaltenen Link-Layer address künftig ihre Sperr-Logik für MAC-Adressen am Kundenanschluss realisieren wollen,

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

    Gute Analyse. Vielleicht hilft es einem anderen Betroffenen.

    Leider verstehe ich bei der Analyse nur Bahnhof. Kann mir vielleicht einer der Experten erklären, ob ich bei einer Standard-Fritzbox die Möglichkeit habe, per geänderter Einstellung eine IPv6-Adresse zu bekommen?

    Was ich soeben getestet habe: Ich habe die Option "Nur IPv6 verwenden" ausgewählt, um zu verhindern, dass zunächst per IPv4 kommuniziert wird. Das hat aber nicht geklappt: ich hatte dann gar keine Internet-Verbindung mehr und bin daher auf die Option "Native IPv6-Anbindung verwenden" zurückgewechselt.

    Im übrigens wurde gestern mein 3. Ticket zu dem IPv6-Problem geschlossen mit dem Hinweis, dass kein IPv6-Problem erkannt wurde.

    Zitat von UschiM

    Leider verstehe ich bei der Analyse nur Bahnhof. Kann mir vielleicht einer der Experten erklären, ob ich bei einer Standard-Fritzbox die Möglichkeit habe, per geänderter Einstellung eine IPv6-Adresse zu bekommen?

    Die Analyse bezog sich auf die Art und Weise, welche Variante (da gibt es 4 Stück) der sog. DUID im Rahmen der DHCPv6-Kommunikation zwischen Router und dem DHCPv6-Server der DG zum Einsatz kommt. Mit einer Fritzbox als Router ist das für dich irrelevant, weil die Fritzbox eine Variante verwendet, die durch den DHCPv6-Server der DG unterstützt wird (du könntest den DUID-Typ in der Fritzbox auch gar nicht konfigurieren).

    Zitat von UschiM

    Was ich soeben getestet habe: Ich habe die Option "Nur IPv6 verwenden" ausgewählt, um zu verhindern, dass zunächst per IPv4 kommuniziert wird. Das hat aber nicht geklappt: ich hatte dann gar keine Internet-Verbindung mehr und bin daher auf die Option "Native IPv6-Anbindung verwenden" zurückgewechselt.

    Ja, das ist klar: Wenn du nur IPv6 anforderst, das DG dir nicht liefert, dann endet das eben im Nichts.

    Du solltest aber besser die Option "Native IPv4-Anbindung verwenden" verwenden: Die beiden Einstellungen bestimmen nur die Reihenfolge, mit der IPv4 und IPv6 angefordert werden:

    • "Native IPv4-Anbindung verwenden": Es wird zuerst IPv4, dann IPv6 angefordert - das führt bei DG erfahrungsgemäß deutlich schneller zum Erfolg und ist deshalb die empfohlene Variante.
    • "Native IPv6-Anbindung verwenden": Es wird zuerst IPv6, dann IPv4 angefordert - dauert bei DG erfahrungsgemäß deutlich länger, deshalb nicht zu empfehlen - insbesondere in deinem Fall nicht, wo du gar kein IPv6 bekommst.
    Zitat

    Im übrigens wurde gestern mein 3. Ticket zu dem IPv6-Problem geschlossen mit dem Hinweis, dass kein IPv6-Problem erkannt wurde.

    Hier im Forum wird von bis zu 10 Versuchen gesprochen, um dort den Einäugigen zu finden, der in der Lage ist mehr zu erkennen.

    Muss ich bei OPNsense irgendwas einrichten? Ich habe ALLES probiert und bekomme kein IPv6 Prefix. Interfaces -> Settings -> Insert a new LLT DUID habe ich probiert und beim Interface zb. dhcp6.client-id 00:00:00...;

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

    Ich bin seit ein paar Monaten mit einem neuen Anschluss bei der Deutschen Glasfaser und nutze eine alte APU von PC-Engines mit Linux als Router.

    Ich habe ipv6 immer auf SLAAC "automatisch" laufen lassen und so eine ipv6 Konfiguration erhalten, mit Präfix, der an fünf interne Netzwerke weitergegeben wurde (Wohngemeinschaft). edit: Ich habe Router Advertisements erhalten mit managed flag, dann DHCPv6 abgerufen, inklusive Prefix Delegation. edit

    Das lief gut, wobei es zu Anfang einige Zeit gedauert hat, bis die ipv6 Konfiguration eintraf. Es lief gut, bis zum 24. Juni um 23:00 Uhr.

    Ab dem 25. Juni um 01:00 Uhr gab es keine ipv6 Konfiguration mehr. Ich habe per Paketmitschnitt nachgesehen, es gab keine Router Advertisements als Antwort auf meine Router Solicitation Nachrichten.

    Der Kommentar RE: Deutsche Glasfaser: Keine IPv6-Adresse hat mir geholfen.

    Ich habe die Leitung auf DHCP (anstatt SLAAC automatisch) konfiguriert, das DUID auf LLT gestellt und dann die Verbindung neu aufgebaut. Im trace konnte ich sofort Router Advertisements sehen. Meine Router Software (NetworkManager) nimmt aber keine RA an, wenn die Verbindung auf DHCP steht.

    Nachdem ich alles wieder zurückgebaut hatte (zurück von DHCP auf SLAAC automatisch und von DUID-LLT auf NetworkManager-Standard DUID Einstellung) und den Router neu gestartet habe, lief die Verbindung auch wieder mit SLAAC der Einstellung automatisch (inklusive Präfix-Auslieferung).

    Ich werde das jetzt beobachten und mich gegebenenfalls nochmal melden. Ich weiß halt nicht, ob man jetzt dauerhaft mit DUID-LLT arbeiten sollte, oder ob das wechseln der DUID nun das Problem behoben hat.

    Vielen Dank an CruxTheFirst !

    3 Mal editiert, zuletzt von topas-rec (27. August 2025 um 22:15)

    Zitat von topas-rec

    Nachdem ich alles wieder zurückgebaut hatte (zurück von DHCP auf SLAAC und von DUID-LLT auf NetworkManager-Standard DUID Einstellung) und den Router neu gestartet habe, lief die Verbindung auch wieder mit SLAAC (inklusive Präfix-Auslieferung).

    Verstehe ich das richtig (?):

    Dein Router am DG-Anschluss benutzt für die Konfiguration einer WAN-Port-Adresse SLAAC? Und dein Präfix für das LAN fordert er per DHCPv6-PD (IA_PD) an? Ich wusste bisher nicht, dass DG für die WAN-Port-Konfiguration überhaupt SLAAC unterstützt. Das widerspräche auch den Informationen, die DG in einem RA sendet: Dort steht das M-Flag auf 1 (=heißt: mach bitte DHCPv6), und es enthält auch keine PIO-Option, aus der dein Router per SLAAC eine globale IPv6-Adresse generieren könnte.

    Oder ist es so, dass dein Router gar keine globale WAN-Port-IPv6-Adresse hat, sondern dort nur über eine link-lokale fe80-Adresse verfügt? Das wäre ja auch denkbar. Globale IPv6-Adressen hättest du dann nur auf der LAN-Seite, und wenn dein Router selbst ins Internet spricht, verwendet er seine LAN-Adresse als Source.

    Einmal editiert, zuletzt von ::1 (27. August 2025 um 20:28) aus folgendem Grund: Type

    Ja, aber das ist wohl nicht richtig. Ich dachte "nicht DHCP" ist dann (bei mir - also NetworkManager) ja automatisch und dann ist es SLAAC, auch wenn dabei (managed flag) ja noch DHCP passiert.

    Habe meinen Beitrag korrigiert, danke für die Kontrolle.

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

    Meine Router Software (NetworkManager) nimmt aber keine RA an, wenn die Verbindung auf DHCP steht.

    Das wäre allerdings nicht standard-konform: Bei einer dynamischen Interface-Konfiguration per DHCPv6 müssen auch RA angenommen werden, denn das wäre die einzige Möglichkeit, dem Interface ein IPv6-Standardgateway und ggf. per PIO-Option (ohne gesetztes A-Flag) eine Prefix-Länge mitzuteilen. Für diese beiden Werte gibt es bei DHCPv6 (im Gegensatz zu DHCPv4) keine entsprechenden Optionen: Sie müssen aus RA gelernt werden, DHCPv6 vergibt nur IPv6-Host-Adressen (=/128).

    Vielleicht nimmt NetworkManager (NM) auch Router Advertisements an bei dhcp und ich habe das nicht gesehen, da ich eine default route einstellen musste, um bei dhcp-Betrieb überhaupt die Prefix Delegation abzustoßen.

    Letzteres ist bereits als Problem gemeldet: https://gitlab.freedesktop.org/NetworkManager…r/-/issues/1121

    Da werde ich mich Mal dazu melden. Das ist ja das tolle bei open source Software - man kann etwas tun und in Notfall selbst Hand anlegen.

    Ich möchte die Unterhaltung aber nicht mit NM-Verbesserungen sprengen. Mich würde noch interessieren, was ihr zu der Aussage der DG-Hotline sagt:

    Zitat

    Die Einrichtung findet per DHCP an Ihrem Anschluss statt.

    Stellt ihr DHCP ein, oder wartet ihr auf die RA und dann passiert die DHCP Abfrage automatisch (weil das managed Bit gesetzt ist)?

    edit: Man kann ja eigentlich auf die RA warten, vorher ist ja eh keine Kommunikation möglich, da keine default Route vorhanden. Obwohl, wenn durch die DHCP-Anfrage die RA starten, dann geht es mit DHCP sicher schneller eine funktionierende Konfiguration zu bekommen, als auf die RA zu warten.

    Einmal editiert, zuletzt von topas-rec (28. August 2025 um 09:34)

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

    Stellt ihr DHCP ein, oder wartet ihr auf die RA und dann passiert die DHCP Abfrage automatisch (weil das managed Bit gesetzt ist)?

    Das ist genau die Kernfrage!

    Laut Theorie sollte eine IPv6-Initialisierung eines Netz-Interfaces in etwa so erfolgen:

    • Es wird zunächst eine linklokale IPv6-Adresse (fe80...) generiert: fe80::[IID]/64. Für die Generierung einer Interface-ID [IID] gibt es mehrere Varianten, die älteste lautet "modified EUI64". Es folgt noch eine DAA (duplicate address detection) für diese Adresse.
    • Falls das Interface statisch mit einer globalen IPv6-Adresse und einem Standard-Gateway versehen ist, erfolgt auch für die globale IPv6-Adresse eine DAA. Der Prozess ist hier dann aber (im Gegensatz zu einer statischen IPv4-Konfiguration) nicht zu Ende (IPv6-Adressierungsverfahren sind additiv!):
    • Das Interface sendet in kurzer Abfolge mehrere RS (Router Solicitation). Kommen keine RA-Antworten (kein Router im angeschlossenen Netz oder Router ist nicht für das Senden von RA konfiguriert), ist der Vorgang hier zu Ende.
    • Andernfalls werden erhaltene RA (solicited als Antworten auf RS, oder unsolicited - sendet der Router periodisch in gewissen Zeitabständen) ausgewertet:
    • Je nach Inhalt des RA (M-Flag, O-Flag, enthaltene PIO mit L-Flag und A-Flag) entscheidet sich, ob, und wenn ja, wie weitere globale IPv6-Adressen (zusätzlich!) generiert werden. Da gibt es jetzt viele Varianten. Ich erwähne hier nur die DG-Variante:
    • DG-RA:

      Es ist das M-Flag gesetzt (was implizit auch O=1 bedeutet, auch wenn das O-Flag nicht explizit gesetzt ist): Heißt: Frag per DHCPv6 nach einer IPv6-Host-Adresse (.../128!) und nach weiteren DHCPv6-Optionen (hier die IPv6-DNS-Resolver-Adressen).

      Es ist keine PIO enthalten: Es wird kein LAN-Präfix für den WAN-Link (d.h. hier: keine Präfix-Länge) passend zur DHCPv6-Adresse mitgegeben. Das WAN-Interface hat somit nur eine IPv6-Hostadresse .../128 (was in einer Fritzbox z.B. falsch als .../64 dargestellt wird).

      Die Router-Lifetime ist >0 (z.B. 1800s): Das bedeutet: Verwende die linklokale Quell-Adresse des RA (diese werden immer von der linklokalen Adresse des Routers gesendet) als IPv6-Standardgateway.

    In der Praxis verhalten sich die IPv6-Implementierungen allerdings häufig nicht standardkonform: Eine Fritzbox versucht z.B. bereits auch dann eine dynamische Konfiguration per DHCPv6, wenn sie noch gar kein RA erhalten hat, das sie (per gesetztem M-Flag) dazu angewiesen hätte. Auch Windows hat da so seine Eigenheiten.

    2 Mal editiert, zuletzt von ::1 (28. August 2025 um 11:16) aus folgendem Grund: Typo