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?
Beiträge von ::1
-
-
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
- für SIP/RTP via IPv4 (nicht jedoch für IPv6 - da spielt CGNAT keine Rolle)
- und für SIP-Provider ungleich DG (da muss man wohl NAT-Status am CGNAT aktiv halten)
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:
Portweiterleitung des Internetrouters für Internettelefonie aktiv halten
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:
-
Du schreibst in deinem einen Dokument, dass du ein DHCP-Offer für 10.124.1.24 bekommen hast. Das ist ja das völlig falsche Netz. Aus dem 10er Netz bekommen diejenigen eine IP, die im GPON Onboarding Prozess sind und den Aktivierungscode benutzen wollen. Bist du sicher, dass deine physikalische GPON Verbindung stabil stand zu dem Zeitpunkt?
Sorry, das war ein Schreibfehler meinerseits: Richtig ist die Adresse 100.124.1.24. Werde das PDF gleich gegen eine korrigierte Fassung austauschen. Da zu dem Zeitpunkt parallel IPv6-Kommunikation stattfand, bin ich mir auch sicher, dass meine physische GPON-Verbindung stabil stand.
-
DHCP ist meiner Meinung nach bei der Deutschen Glasfaser eine Baustelle. Vielleicht arbeitet gerade mal jemand daran.
Kann ich nur bestätigen! Siehe meine bezügliche Problembeschreibung im angehängten PDF. Bei Bedarf kann ich gerne auch noch die PacketTrace-Dateien (pcap), sowie FritzBox-Eventlog ergänzen. Und das war jetzt bereits das dritte Mal (so alle 2-3 Monate), dass ich stundenlang ohne IPv4- und/oder IPv6-Adressen dastand.
Habe das am 01.10.2022 an die DG per Mail geschickt. Antwort vom 03.10.2022:
"Unsere technische Abteilung hat Ihren Anschluss überprüft und konnte keine Unstimmigkeiten feststellen. Da Sie einen eigenen Router nutzen und wir auf diesen keine Übersicht haben, wenden Sie sich bitte an den Hersteller des Routers."
Diese Antwort war natürlich nicht akzeptabel. Auf meine weiteren Versuche am 03.10. und 18.10 erhielt ich bisher keine Antwort - die stellen sich taub.
Btw: Die Leasedauer ist für beide Protokolle jeweils eine Stunde. Die halbstündigen Renews (nach T1) werden im Eventlog der Fritzbox merkwürdigerweise für IPv6 gar nicht angezeigt und für IPv4 nur alle 12 - 12,5 Stunden.
Ergänzung: Ich denke, das Problem ist PLZ-unabhängig. Mein PLZ-Bereich ist 906xx.
Ergänzung2: Habe auch noch das EventLog der Fritzbox angehängt, das deren Kampf um IPv4- bzw. IPv6-Adressen widerspiegelt
