Beiträge von glandulin

    Hier nun ein kurzer Erfahrungsbericht: Im Zusammenspiel mit einem kostenlosen Account bei dem DynDNS Anbieter "selfhost.de" klappt das mit IPv6 ziemlich gut. Insbesondere da es hier auch eine Möglichkeit gibt, für die vom Client übermittelte IPv6 Adresse ein "Static Suffix" (die 4 letzten Blöcke der Adresse) zu setzen.

    Das ist in meinem Falle erforderlich, denn ich kann dem Router zwar sagen, für welches Interface er den DynDNS Client ausführen soll, aber nicht welche der zugewiesenen Adressen (static, anycast, etc.) er hierbei an den Service übermitteln soll... Mithilfe dieser Funktion verarbeitet der Service also die übertragene IPv6 Adresse und ersetzt die 4 letzten Blöcke (in meinem Falle durch "::1", was dann "immer" dem richtigen Interface entspricht).

    Noch ein Hinweis an Nachahmer: Generell funktioniert als VPN Endpoint nur eine Adresse aus dem dynamischen Präfix (IA_PD). Die von der DG für das WAN Interface des Routers via DHCPv6 zugewiesene IPv6 Adresse (IA_NA) funktioniert nicht.

    Da brauchst du natürlich noch einen Dienst, der mit IPv6 umgehen kann, und zwar am besten einen, der eine Prefix-Aktualisierung erlaubt.

    Bei IPv6 muss man ja bedenken, dass man eine Freigabe auf dem Server und nicht auf dem Router anspricht. Das ist komplett anders, als bei IPv4. D.h., entweder muss der Server selber ein dyndns Update seiner Adresse machen, was bei Webcams oder ähnlichen Geräten oft nicht möglich ist, oder der Router macht ein Prefix Update bei einem Dienst, der dann mit den Interface-IDs der Geräte die komplette Adresse zusammenbaut. myfritz, dynv6 oder feste-ip sind Dienste, bei denen das möglich ist.

    Das ist bei mir vermutlich einfacher: Der Router hat ein Bridge Interface (quasi mein LAN) das eine routbare IPv6 (::1) aus dem dynamische Präfix erhält (das ist aktuell mein VPN Endpoint). Auf dieses Interface lauscht der lokale DynDNS Dienst und kann daher diese Adresse an den externen DynDNS Provider übermitteln. Ddnss.de (und andere) können ja v6… Um die einzelnen Geräte im LAN muss ich mich nicht kümmern, die erhalten ja automatisch neue Adressen bei Präfixänderung. Bei mir ist es ausreichend, wenn ich einen VPN Tunnel auf das Bridge Interface am Router aufbauen kann. Der Router „kennt“ die anderen Geräte ja. Wird sicher etwas Gebastel aber sollte eigentlich funktionieren…

    HubeBube  frank_m Danke, komischerweise hatte ich schon 3 Präfix Änderungen in den letzten 3 Jahren… Der Router kann damit umgehen, das ist kein Problem. Allerdings ist es für die VPN Einwahl problematisch, wenn man gerade unterwegs ist, und der VPN Endpoint plötzlich eine andere Adresse hat (die man dann ja noch nicht kennt). Dummerweise kann der Router DynDNS nur für IPv4, sonst wäre das kein Problem.

    Hallo Forum,

    vermutlich wurde das schon mehrfach gefragt, aber die Suche innerhalb des Forums war für mich nicht so zielführend...

    Welche Möglichkeiten gibt es, bei der Deutschen Glasfaser entweder eine feste IPv4 Adresse oder alternativ ein festes IPv6 Präfix zu erhalten? Laut DG Website ist eine feste IPv4 Adresse wohl nur in den "Business" Tarifen (monatliche Kosten 350 EUR oder mehr) möglich, über ein dauerhaftes festes IPv6 Präfix finde ich keine Informationen... Das Präfix in den (günstigen) "Basic" Tarifen bleibt zwar einige Monate gleich, aber leider nicht dauerhaft...

    Kennt jemand eine Möglichkeit, entweder eine feste IPv4 Adresse oder ein festes IPv6 Präfix zu "akzeptablen" Preisen (Privatanweder) zu erhalten?

    Losgelöst davon, weiß jemand wann es möglich sein wird, über einen DG Glasfaseranschluss einen Tarif eines anderen Providers (Telekom o.ä.) zu nutzen? Es wurde hier und da mal was "gemunkelt", dass dies in absehbarer Zeit wohl machbar sein sollte...

    Viele Grüße!

    Solange es nicht dasselbe Gerät ist, brauchen wir nicht weiterdiskutieren. Es ist bei bintec elmeg quasi unmöglich, eine identische Konfiguration manuell erzeugen.

    frank_m Wir haben die Konfiguration bei dem Gerät am funktionierenden Anschluss exportiert und bei meinem Gerät importiert. Bist du sicher dass das nicht ausreichend ist?

    HubeBube Nein, das neue Release hat das Problem leider auch nicht gelöst.

    Hallo Forum,

    ich bekomme mit einem kundeneigenen Router seit Monaten keine IPv6 Konnektivität (am Anschluss der Deutschen Glasfaser) und die Reise nimmt kein Ende. Es handelt sich um einen Router von Bintec Elmeg, Modell RS123 bzw. be.IP (mit beiden klappt es nicht).

    Reguläre Anfragen an den Support wurden (wie so oft) mit „aktivieren Sie IPv6 in der FritzBox“ (da kann, will oder darf jemand nicht richtig lesen) oder „wenden Sie sich an den Hersteller des Routers“ abgespeist.

    Eine Anfrage über die Social Media Kanäle erschien zunächst vielversprechend und man war hier auch sehr motiviert mir zu helfen, letztendlich konnte man den Fehler aber auch nicht finden.

    Das interessante und zugleich frustrierende ist nun:

    Das gleiche Gerät (be.IP) funktioniert in einem anderen Ausbaugebiet der DG problemlos und erhält dort volle IPv6 Konnektivität. Um das zu validieren habe ich ein identisches Gerät mit identischer Firmware und identischer Konfiguration an meinem Anschluss installiert. Dort läuft es hingegen nicht!

    Diese Tatsache sollte eigentlich ausreichend belegen, dass das Problem nicht auf Kundenseite liegt sondern auf Seite der DG. Da der DG auch beide Anschlüsse bekannt sind (meiner und der im anderen Ausbaugebiet), sollte sich die Ursache des Problems doch eigentlich leicht identifizieren lassen, zum Beispiel durch Vergleich der Konfiguration der beiden Anschlüsse oder Knoten. Jedoch ist aber auch das scheinbar nicht möglich :(

    Hat jemand noch eine Idee oder einen Ansatz, wie man dieses leidige Thema endlich klären kann?

    VG, glandulin

    Danke für deine Mühe, frank_m ! Aus meiner Sicht lässt sich das Problem demnach ganz klar lokalisieren:

    # Falls die DG "Rapid Commit" voraussetzt

    Der Router fragt beim SOLICIT zwar nach "Rapid Commit" an, dieser wird aber seitens der DG nicht aktzeptiert und es kommt kein REPLY. Womöglich beinhaltet die Anfrage falsche oder fehlende Parameter.

    # Im Falle eines regulären Ablaufs

    Beim regulären Ablauf (SOLICIT, ADVERTISE, REQUEST, REPLY) übermittelt der Router im REQUEST nicht die in der vorausgegangenen ADVERTISE Message enthaltenen Adressen, deshalb kommt kein gültiges REPLY zurück.

    Danke euch beiden.

    @alfalfa Unterscheidet sich mein Solicit (der ja ebenfalls Rapid Commit versucht) denn inhaltlich von deinem? Da muss ja irgendwas anders sein, sonst müsste ich ebenfalls als Antwort ein Reply anstatt Advertise erhalten…


    frank_m Da würde mich tatsächlich interessieren, ob lediglich im Renew die konkreten Adressen angefragt werden oder auch im Request.

    Danke für die Aufklärung, @alfalfa ! Ist es wirklich der Router, der "akzeptieren" muss. Für mich sieht das so aus:

    SOLICIT -> Router gibt bekannt, was er gerne mitgeteilt bekommen würde: DNS, IA_NA, IA_PD

    ADVERTISE -> DG antwortet: Ich hätte diese beiden DNS, diese IA_NA (mit der IAID 123) und dieses IA_PD (mit der IAID 456) im Angebot

    REQUEST -> Router sagt: Dann gibt mit bitte ein Lease sowie die IA_NA (mit IAID 123) und dieses IA_PD (mit IAID 456)

    ...danach (erst nach mehreren Requests) kommt entweder...

    ADVERTISE -> DG antwortet "Unspec Fail"

    Oder...

    REPLY -> DG antwortet "No Binding"

    ...und alles beginnt wieder von vorne.

    Hier mal ein Auszug aus der Kommunikation:

    1 SOLICIT Solicit mit Anfrage nach Präfix (Länge 56)

    2 ADVERTISE Advertise übermittelt das korrekte Präfix sowie 2 Nameserver

    3 REQUEST Es folgen mehrere Requests mit den Optionen DNS, IA_PD, DS

    4 REQUEST ...

    5 REQUEST ...

    6 REQUEST ...

    7 REQUEST ...

    8 REQUEST ...

    9 REQUEST ...

    10 ADVERTISE Plötzlich ein Advertise mit Fehler "UnspecFail"

    11 REQUEST Request wie 3

    12 REPLY Reply mit Fehler "NoBinding"

    13 SOLICIT Solicit wie 1

    14 SOLICIT ...

    15 SOLICIT ...

    16 ADVERTISE Advertise mit Fehler "UnspecFail"

    17 Ab hier wiederholen sich immer wieder 13 - 16

    Macht hier der Router was falsch oder der Server? Mich wundert das fehlerhafte Advertise (10) zwischen den Requests...

    @alfalfa ich vermute stark, dass es nicht am Router liegt, da dieser wohl auf der gleichen Software wie der vorherige basiert. Auch interpretiere ich die Logeinträge (zugegeben, mit gefährlichem Halbwissen) eher so, dass der DHCPv6 Server einfach nicht das herausgeben möchte was der Client korrekt angefragt hat.


    Ich werde mal versuchen, den DHCPv6 Client bzw. überhaupt IPv6 für das Interface für einen Tag oder länger zu deaktivieren.