Hallo neisbe,
genau das Problem hatte ich bei Wechsel von Telekom zu DG auch. Es war aber einfach möglich, die bestehenden T-Online-Mailadressen ohne Klimmzüge zu behalten und direkt in Freemail-Adressen umwandeln zu lassen.
Hier kann man das anstoßen: https://www.telekom.de/hilfe/f…-sicherheit/e-mail-erhalt
Hat zuverlässig geklappt.
Vielleicht meint IPv6 PD Interface das LAN-Interface, das einen /64 aus dem /56-PD-Block bekommen soll. Und da gäbe es 256 Möglichkeiten 0x00 - 0xFF (oder dezimal 0-255) die ID XX für das LAN zu wählen.
Also vielleicht mal LAN statt WAN auswählen und als ID z.B, die 1 probieren.
ob ggf. in der FB konfiguriert ist, dass DHCPv6 IPv4 Transport benutzen soll
Laut Definition von DHCPv6 ist so etwas nicht vorgesehen. Wie sollte man also in der FB etwas konfigurieren können, für das es keine technische Spezifikation gibt?
Habe mal interessiert mitgelesen ...
Changelog müsste wohl dies sein.
Speziell die Passage
"Fehlerbehebung in der IPv6-Adresszuweisung via DHCPv6 (ER#5971) –
Im DHCPv6-Client wurden im Non-Rapid-Commit-Fall die IANA- und IAPD-
Sektion (die zuvor mit der DHCPv6-Solicit-Nachricht empfangen wurden)
nicht in die darauf folgende ausgehende DHCPv6-Request-Nachricht
umkopiert. Dies verursachte IPv6-Verbindungsprobleme bei manchen
Providern wie „Deutsche Glasfaser“."
Das passt doch ganz gut zu #25, wo auffiel, dass im Request die im Advertise angebotenen Daten fehlten.
Hm, ich habe gerade in einem 8 Monate alten Thread gelesen, das die XG keine Prefix Delegation (DHCPv6-PD) beherrscht.
Das wird sich auf die Weitergabe von Prefixes an Router im LAN beziehen, nicht auf die WAN-Schnittstelle.
Letzteres würde ich nicht so folgern. Wenn die erste Aussage generell richtig ist, wird die XG insbesondere auch nicht die Rolle eines "requesting routers" (siehe Definition im DHCP-PD-RFC3633 bzw. in RFC8415) erfüllen, um ein Präfix für das LAN via "option request"-Option 25 vom "delegating router" beim Provider anzufordern. Somit erhält man keine IPv6-Adressen für das LAN.
Wenn ich Nur DHCP anklicke muss ich ein Gateway angeben. Welches?
Das ist schon merkwürdig, denn mit Wahl von "Nur DHCP" sollte man weder eine IPv6-Adresse (kommt via DHCPv6 als /128-Adresse), noch eine Präfix-Länge (kommt aus dem PIO-Abschnitt des RA, sofern PIO im RA vorhanden, andernfalls bleibt es bei /128), noch eine Gateway-IP (=linklokale Quelladresse erhaltener RA, sofern im RA eine Router lifetime >0 gesetzt ist) konfigurieren müssen.
Übrigens interessant: Die RA, die die DG sendet, enthalten keinen PIO-Abschnitt - hier aus einem Trace am WAN-Port meiner FB:
Die am WAN-Port gelernte IPv6-Adresse müsste folglich als /128 in der FB angezeigt werden. Tatsächlich dichtet die FB hier allerdings ein /64 dran - streng genommen ein Implementierungsfehler.
ich wüsste jetzt auch nicht wie ich eine fehlerhafte IPv6 konfiguration finden könnte
Hilfreich ist hier https://test-ipv6.com/ - wenn's da irgendwo hakt (< 10/10), gibt der Reiter "Durchgeführte Tests" weitere Hinweise.
Zitat von ParnoidXBei Linux hatte ich im Kernel IPv6 deaktiert, nach rausnahme und neustart bekam ich zwar wieder eine IPv6, jedoch wollten die Tests mit IPv6 nicht.
IPerf3 gibt es hier auch als Windows-Version, um es unter Windows 10 mit IPv6 zu testen.
Evtl. könnte helfen, in den Treiber-Einstellungen für den GBit-Adapter des PC unter "Geschwindigkeit und Duplex" die Standard-Einstellung "Automatische Aushandlung" auf "1,0 Gbit/s Vollduplex" umzustellen.
Nur zum Vergleich, so sieht der DG-Speedtest für meinen DG-Classic-Anschluss aus:
Die Ping-Ergebnisse für google.com sind bei mir (je etwa 20 Pings pro Protokoll):
IPv4: Minimum = 6ms, Maximum = 10ms, Mittelwert = 7ms
IPv6: Minimum = 5ms, Maximum = 9ms, Mittelwert = 6ms
ich 7.12.22 21:30 - no Email whatsoever
Vielleicht ist die Mail im Spamordner gelandet ...
Habe jetzt mal den Internettraffic mitgeschnitten und mir mit WireShark angeschaut.
Das unten müsste doch eine entsprechende Anfrage für ne IP-Adresse sein oder?
Was mir auffällt, ist, das von der DG-Gegenstelle (MAC-Adresse 02:00:00:02:07:02) alle paar Sekunden "Gratuitous ARP" gesendet werden, die die IP-Adresszuordnung von
100.87.0.1 (scheint die IP-Gateway-Adresse zu sein)
100.124.1.57 (vermutlich die IP-Adresse des DHCPv4-Servers)
zu eben dieser MAC-Adresse announced.
Sowas habe ich in meinen Paket-Mitschnitten am WAN-Port der Fritzbox noch nicht gesehen.
Schadet m.E. zwar nichts, aber trotzdem ungewöhnlich.
Nein, das ist sie nicht, sie ist der Client.
Ok, in dem verlinkten Text steht:
"Die praktische Erfahrung ist, dass SIP hinter CGNAT funktioniert, wenn man die Keep-Alives im Client einschaltet."
Aber das dürfte doch nur
relevant sein?
Aber ok, ich bin jetzt kein VoIP-Experte. Ich kann nur sagen, dass meine Telefonie mit der FRITZ!Box als SIP-Client (mit DECT-Telefonen an der FRITZ!Box-DECT-Basis) und DG als SIP-Provider ohne aktive Option "Portweiterleitung des Internet-Routers für Telefonie aktiv halten" einwandfrei funktioniert, und zwar egal, ob ich sie nun für IPv4 oder IPv6 konfiguriere.
Nachtrag: Das sagt die Hilfeseite dazu:
Diese Einstellung ist nur vorhanden, wenn die FRITZ!Box über einen anderen Router ins Internet gelangt. Wenn die Einstellung aktiviert ist, sendet die FRITZ!Box in regelmäßigen Abständen IP-Pakete, damit die Portweiterleitung des Internetrouters für die Internettelefonie aktiv bleibt.
Das ist bei mir aber nicht der Fall ...
Telefonie > Eigene Rufnummern > Anschlusseinstellungen -> Telefonieverbindung - "Einstellungen ändern" aufklappen
Die Option "Portweiterleitung des Internet-Routers für Telefonie aktiv halten" ist bei mir nicht aktiv.
Die Erklärung "Diese Option kann dann erforderlich werden, wenn der Internet-Router ankommende Telefonate nicht mehr an FRITZ!Box weiterleitet. FRITZ!Box hält die Portweiterleitungen des Internet-Routers für Telefonie aktiv." ist nicht besonders intuitiv.
Ich dachte immer, meine FRITZ!Box ist identisch mit dem "Internet-Router".
Kannst du bitte erklären, was die Option bewirkt?
Du hast aber sicherlich "Portweiterleitung aktiv halten alle" auf 30 Sekunden gesetzt?
das sagt mit nichts ... wofür sollte ich Portweiterleitungen brauchen? Ich habe auch keine IP-Telefone im LAN, nur DECT-Schnurlosteile
Da die Telefonie nur über IPv4 läuft
... also bei mit läuft sie über IPv6. Sehe ich in den Packet-Traces für SIP-Register, die meine Rufnummer der IPv6-WAN-Portadresse zuordnet. Und schmerzlich auch daran, dass nach Ablauf einer DHCPv6-Lease (soll bei DG gerüchteweise hin und wieder auftreten) die Telefonie nicht mehr geht.
Hier meine FRITZ!Box 7590 - Einstellungen, die bei mir (WAN-Port am ONT) funktionieren:
Internetanbieter: weitere Internetanbieter | Deutsche Glasfaser
IPv6-Unterstützung aktiv mit "Native IPv6-Anbindung verwenden" (DS-Lite _nicht_ aktiviert!) und "Globale Adresse automatisch aushandeln" ("DHCPv6 Rapid Commit verwenden" _nicht_ aktiviert).
Aber gut, das stundenlange Warten auf IPv4 und/oder IPv6 von deren "zickigen" DHCP/DHCPv6-Server kenne ich auch (siehe hier).
Noch eine Idee:
Unter Heimnetz | Netzwerk | Netzwerkeinstellungen:
Ist für den WAN-Port der "PowerMode" (1GBit/s) aktiviert?
Kaum zu glauben, aber wahr, ich hatte gestern die gleichen Meldungen im Log:
Etwa 2,5h ohne IPv6. Wäre nett, das ebenfalls bei DG zu bemängeln. Damit ich nicht so als Einzelkämpfer dastehe.
Ok, dann hat sich der Verdacht erledigt. Dann liegt es meines Erachtens an der DHCP Infrastruktur.
Das sehe ich auch so, und ich meine, jeder Netzwerk-Spezialist, der sich mit Netzprotokollen auskennt und Paket-Mitschnitte lesen kann, sollte auch zu diesem Ergebnis kommen. Insofern danke für die Bestätigung hier im Forum!
Unsere Erfahrung mit 3 Business-Anschlüssen, die zuerst auch fehleranfällig waren, haben gezeigt, dass der Support so gut wie nichts kann und man den Punkt erreichen muß, an dem sich ein wirklich technisch versierter MA, der auch meistens nicht im Support angesiedelt ist, des Problems annimmt.
Das ist auch meine Intention - in meinen Anfragen bitte ich jedes Mal freundlich erneut darum, die Analyse zum 2nd-Level-Support weiterzuleiten. Vielleicht klappt's ja irgendwann.
Aber richtig ist, dass die alle 30 Minuten stattfinden. Bei DHCPv6 sind es alle 18,75 Minuten (1125 Sekunden, halbe Preferred Lifetime).
Hier die T1/T2-Werte für DHCPv6 und DHCPv4, die ich erhalte:
