Hinweis: Geänderte Standardeinstellungen bei ULA-Vergabe im Heimnetz in FritzOS 8.00

    Hallo zusammen,

    tl;dr FritzOS 8.00 hat die Standardeinstellung für die Vergabe von IPv6 ULAs im Heimnetzwerk geändert, was eventuell zu Endnutzerproblemen bei der IPv6-Internetkonnektivität führen kann.

    ----------------------------

    Die längere Version:

    Nach dem automatischen Update auf FritzOS 8.00 habe ich bei meinem Chromebook Probleme bei der IPv6-Konnektivität bemerkt und beim Nachforschen einen Bug in ChromeOS gefunden. Jemand anders war schneller und hat die Problematik bereits hier ausführlich beschrieben.

    Kurzfassung: Wenn im RA (Router Advertisement) GUAs und ULAs verteilt werden, ordnet ChromeOS beide Adressen dem Standardnetzwerkinterface zu. Der Browser und die Systemshell `crosh` (und vielleicht noch weitere Tools) wählen fälschlicherweise immer nur die erstbeste Adresse nichtdeterministisch aus anstatt alle vorhandenen in Betracht zu ziehen. Falls dies die ULA ist, hat man Pech und keine Internetkonnektivität über IPv6.

    Mir kam es komisch vor, dass ich genau einen Tag nach dem FritzOS-Update auf diese Problematik gestoßen bin. Auch kann ich mich nicht entsinnen, vorher ULA-Adressen an den Interfaces meiner Geräte gesehen zu haben.

    Und tatsächlich: Eine Änderung im FritzOS hat den ChromeOS-Fehler erst demaskiert. Das ist auch der Grund für meinen Post hier.

    AVM schreibt im Changelog:
    "Die IPv6-Option "ULA (Unique Local Address) zuweisen, solange keine IPv6-Internetverbindung besteht (empfohlen)" entfällt".

    Im Konfigurationsexport spiegelt sich das wider als ulamode = ulamode_persist. Der default-Wert war vorher ulamode_dynamic.

    Mit FritzOS 8.00 werden nun also standardmäßig immer ULAs zugewiesen. Zuvor geschah dies nur bei fehlender IPv6-Internetkonnektivität.

    Vielleicht hilft dieser Post dem einen oder anderen weiter.

    Der Grund für die Änderung ist die neue Unterstützung für IPv6 im VPN Tunnel. Da man dort nicht mit globalen Adressen arbeiten kann, sorgt AVM dafür, dass alle Geräte ULA Adressen haben.

    Das ist dann aber eigentlich ein Bug im Chrome OS. Eigentlich sollten die Geräte in der Lage sein, die richtige Quelladresse zu setzen.

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

    Zumal die ULA Bereiche auch bekannt sind und WAN-seitig immer dem Global-Scope weichen sollten, ja sogar müssen. Aber was soll's, zumindest bei ChromeOS und damit sicher auch bei Android (durch Analogieschluss bei Google) ist das Problem behoben.

    Zitat von HubeBube

    Zumal die ULA Bereiche auch bekannt sind und WAN-seitig immer dem Global-Scope weichen sollten, ja sogar müssen.

    Mit WAN-seitig meinst Du auf dem Client?

    Denn wenn der Router eine ULA-IP als Quell-IP sieht, kann er nicht mehr viel machen, da IPv6 ja nicht genattet werden soll. Das muss schon der Client richtig machen, sonst ist es zu spät.

    Einem Gerät ULAs und GUAs parallel zu vergeben lässt sich gar nicht immer vermeiden, zum Beispiel wenn man interne Server betreibt und kein IPv6-Netz statisch zugewiesen hat.

    Die Lösung NAT66 gilt ja als "böse" und wird daher nicht überall unterstützt.

    Ich hatte einen Knoten im Hirn, sorry.

    Natürlich muss der Client in der Lage sein je nach Ziel/Kommunikationspartner die richtige IPv6 Adresse zu verwenden. Vor allem dann, wenn mehrere IPv6 Adressen dem Client zugewiesen sind.

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

    Ich hatte einen Knoten im Hirn, sorry.

    Natürlich muss der Client in der Lage sein je nach Ziel/Kommunikationspartner die richtige IPv6 Adresse zu verwenden. Vor allem dann, wenn mehrere IPv6 Adressen dem Client zugewiesen sind.

    Ja. Ist trotzdem nicht trivial, denn wenn das interne Netz aus mehreren Segmenten besteht, muss die Route für diese anderen Segmente an alle Clients verteilt werden, dass diese auch über dessen ULA und nicht über die Defaultroute per GUA geroutet werden (wg. Firewall).

    Alles ziemlicher Mist und hat bei mir dazu geführt, dass ich (hoffentlich vorübergehend) wieder auf IPv4-only zurück bin und es jetzt (wenn ich Zeit finde) über NAT66 versuchen werde.

    Das ist jedem Provider überlassen. Bei Deutsche Glasfaser ist das in "Technical Specification – DG – GPON / XGSPON" beschrieben. In der Version vom 22. Mai 2024 steht folgendes: DHCPv4 und DHCPv6.

    Lease Time ist eine Stunde.

    Das PDF ist abseits dessen ganz interessant, da HÜP, Gf-TA (ja wirklich!) und ONT (verschiedene Formfaktoren, auch SFP Module!) Erwähnung finden.

    Technical_Specification_ DG_xPON_1.2_en_public.pdf

    Für die AON-Topologie gibt es das ebenfalls: Technical_Specification_ DG_P2P_1.2_en_public.pdf

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