TS-419P II sammelt IPv6 Adressen!

  • Ich habe auch ein Problem mit IPV6, mein TS-419P II sammelt IPV6 Adressen!


    qnp.png


    Ich habe einen DSL Anschluss, und bei jeder unerwarteten Trennung der bekomme ich ein neues Präfix. Das delegierte Präfix wird dann per Router Advertisement im LAN verteilt, und die Geräte erhalten globale (zustandslose) Adressen... soweit so gut...


    ...bis auf das NAS... hier bleiben "alten" IPv6 Adressen aus irgendwelchen Gründen erhalten.


    Andere Geräte im Netzwerk haben dieses Phänomen nicht, dort wird innerhalb von Sekunden die "alte" IPV6 verworfen, und es ist nur noch die "neue" gültig...

    (z.B. Macbook, Homepod, iPhone...)


    Über iPV6 / UPnP (mDNS) ist das NAS dann nicht mehr zuverlässig erreichbar, da die IPV6 Adressen (bis auf die eine aktuelle) ja ins leere führen...


    Kennt die Problematik jemand?

  • Moin,

    ...bis auf das NAS... hier bleiben "alten" IPv6 Adressen aus irgendwelchen Gründen erhalten.

    Was meinst Du damit? Woher stammt dieser Screenshot?

    Ich jedenfalls habe keinerlei Probleme, allerdings auch ein aktuelleres NAS mit aktuellerer Firmware... IPv6 wird ja so stiefmütterlich behandelt, dass ich mir vorstellen könnte, dass einiges in der alten FW noch nicht richtig funktioniert hat.

    ist das NAS dann nicht mehr zuverlässig erreichbar

    Verwendest Du intern IPv6 für den Zugriff? Wenn nur aufgrund mDNS IPv6 verwendet wird, dann ist es doch eher dessen Problem, dass alte IPs nicht verworfen werden?!

  • ... der mDNS Name ändert sich, mit jeder neuen IPv6... und zwar wird ein Index z.B. (1) hinzugefügt.


    Der Screenshoot stammt von iNet (ein Netzwerkscanner)


    Mod: Nicht deklariertes Zitat ohne Quellenangabe ... korrigiertt! :handbuch::arrow: Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

    Zustandslose Adresse

    Eine solche Adresse wird automatisch anhand der MAC-Adresse des Geräts und des Netzwerkpräfixes generiert, das vom Router bekannt gemacht wird. Zustandslose Adressen werden beim Neustart (oder Einschalten) des Geräts verworfen.

    (Quelle: Handbuch Canon MFC645Cx)


    Muss ich das jetzt so verstehen, dass ich nach einer Präfixänderung immer alle Geräte neu starten muss? - Weil nach einem Neustart ist alles wieder O.K., bis zur nächsten Trennung vom DSL Modem...

    2 Mal editiert, zuletzt von sasch () aus folgendem Grund: Quellenangabe nachgereicht

  • Hm, bei mDNS bin ich raus, ich nutze seit jeher IPv4 Adressen um meine Geräte anzusprechen und vermeide die Verwendung von mDNS.

    Habe so ein Verhalten aber auch noch nicht beobachten können...

  • ... alles gut... ich glaube die mDNS Namensänderung, ist auch nur aufgrund dessen, das der ursprüngliche Name bereits für eine der "alten" Adressen vergeben ist...


    Ich verstehe nicht, warum die nicht rausfliegen... sie tun es bei den anderen Geräten ja auch...


    ...bei einem Anschluss kann auch nicht sein, das zwei unterschiedliche Präfixe gleichzeitig vorhanden sind. Der Router schnallt es auch immer direkt, und das Präfix Objekt wird sofort aktualisiert... Beim QNAP NAS wird die Neue Adresse einfach nur hinzugefügt... somit hat das Gerät irgendwann einen ganzen Arsch voll Adresse (wie auf dem Bild zu sehen)... Alle anderen haben max. zwei, die Link Lokale + die "aktuelle" IPv6 welche aus dem "aktuellen" Präfix erzeugt wird...


    Aber sowas wie Lease-Times kann man für IPv6 (zumindest da nicht) einstellen...


    IPv4 vergebe ich mit MAC Binding immer die selben aus einer DHCP Tabelle... bei IPv6 geht das ja nicht, da sich die Adressen, dank der Deutschen Telekom ständig ändern...

  • somit hat das Gerät irgendwann einen ganzen Arsch voll Adresse

    Naja dass der QNAP selbst so viele Adressen (mit unterschiedlichen Präfixen) hat geht ja (eigentlich) nicht, das wird glaube ich echt ein Ding von dem IP Scanner sein, der selbst checken müsste, dass der Hostteil immer identisch ist und sich nur das /56 Präfix ändert. Dann müsste er auch nicht jedes neue Präfix wie ein neues Gerät behandeln. Aber warum das dann nur bei dem QNAP so ist?!?!


    Hast Du schonmal versucht die IPs mit DHCP6 zu verteilen statt mit SLAAC? Ich meine mich vage zu erinnern, dass ich mit SLAAC am QNAP auch mal irgendwelche Probleme hatte.

  • ich verwende SLAAC im LAN nicht... sondern die DHCPv6 Prefix Delegation...


    Ich habe jetzt mal einen DSL Abbruch provoziert (Kabel gezogen)

    ... und siehe da;


    ... die Hütte hat zwei Globale IPv6 (sch***e!)

  • ich verwende SLAAC im LAN nicht... sondern die DHCPv6 Prefix Delegation...

    Ok, hatte ich wegen "zustandslos" so verstanden.

    die Hütte hat zwei Globale IPv6

    Zwei, aber nicht zwanzig :)

    Wie sieht es denn jetzt ein paar Minuten nach der Präfixänderung aus? Irgendwann muss die alte IP ja mal verschwinden. Kann mir durchaus vorstellen, dass das dann an der alten Firmware liegt.

  • Das Teil sollte maximal 3 v6 IPs haben, da ist der Netzwerkstack defekt, bitte ein Ticket an QNAP.


    Und hier sieht man mal wieder, warum IPv6 sich nicht durchsetzen wird, denn mit jeder Einwahl einen neuen Prefix zu erhalten ist mal mega scheiße.

    Ja privacy usw. aber wie will ich die 32 oder mehr intern sauber nutzen.


    Bekomme hier zwar selten ein neues Prefix, aber es kommt schon mal vor und dann kann ich das leider nicht für meine VPN Clients nutzen, weil was soll ich da eintragen? Track Int geht hier leider nicht, aber das müsste ich haben.

    Und dann ist man wieder beim Problem mit dem Regelwerk, da kann ich dann nur mit dem VPN Netz als globales Objekt arbeiten.


    v6 muss wohl erst 100 Jahre alt werden, denn auch 25 Jahre später ist es noch in einer Niesche!

  • Das Teil sollte maximal 3 v6 IPs haben, da ist der Netzwerkstack defekt, bitte ein Ticket an QNAP.

    Das wird bei dem 419 PII wohl nicht viel bringen...

    warum IPv6 sich nicht durchsetzen wird, denn mit jeder Einwahl einen neuen Prefix zu erhalten ist mal mega scheiße.

    Das ist ja eigentlich auch nicht Sinn und Zweck von v6... Warum das noch so gemacht wird bzw. sich die IP/ der Präfix überhaupt ändert erschließt sich mir nicht... wahrscheinlich weil "haben wir schon immer so gemacht".

    Track Int geht hier leider nicht, aber das müsste ich haben.

    Schön dass ich damit nicht alleine dastehe :)

  • Mittlerweile hat sich die Entwicklungsabteilung von Zyxel damit beschäftigt... Es ist tatsächlich ein Problem des Clients (4919-P II)...


    ...nach einer Präfixänderung (z.B. durch einen Verbindungsabbruch) versucht das NAS mit der alten, nicht mehr gültigen IPV6 Adresse zu kommunizieren.


    Der Router gibt das neue Präfix per RA weiter, und dieses kommt auch beim NAS an... es lässt sich jedoch vom Router her nicht steuern, welche Adresse der Client dann tatsächlich dann nutzt...



    Der Präfix ändert sich bei jedem Verbindungsaufbau und zwangsweise nach 180 Tagen bei der Telekom.


    Mittlerweile wurde das Problem in einer Testumgebung nachgestellt...


    Ich gebe die Information von der Entwicklungsabteilung von Zyxel mal weiter:


    Mod: Zitat ohne Quellenangabe ... korrigiert! :handbuch::arrow: Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

    ... in der Hoffnung das es jemand liest, der damit was anfangen kann...

  • Das Problem ist hier beschreiben:


    klick


    Mod: Nicht deklariertes Zitat ohne Quellenangabe ... korrigiert! :handbuch::arrow: Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

    If the CPE knows that the delegated prefix has changed, it should send out RA packets with a prefix valid lifetime of 0 to tell all devices that the old addresses are no longer valid.

    Der Router (Zyxel USG 110) sendet entsprechende Pakete, aber das 419P II scheint diese zu ignorieren :(

  • Der Router (Zyxel USG 110) sendet entsprechende Pakete, aber das 419P II scheint diese zu ignorieren

    Ist das 419P II das einzige Gerät in Deinem Netzwerk, dass dieses Problem der Adress-Akkumulation hast?

    Falls ja, dann spricht es dafür das der USG 110 wirklich sauber arbeitet.

    In dem Fall würde ich einfach in der crontab des 419P II, jede Nacht einen Netzwerk-Reset machen.