Es kann auch sinnvoll sein, aus Platzgründen oder weil die Editier-Möglichkeiten im Kontaktformular für die Ticket-Erfassung recht "elementar" sind, das Problem ausführlich in einem Word-Dokument zu beschreiben, das man als PDF speichert und als Attach beifügt. So kann man den Beschreibungstext des Tickets sehr kurz halten und auf die ausführliche Beschreibung im angehängten PDF verweisen.
Beiträge von ::1
-
-
(Packet Captures kann man ja nicht anhängen)
müsste als komprimierte ZIP-Datei schon möglich sein.
-
Seit wann die Telefonie ebenfalls via IPv6 möglich ist, weißt Du nicht zufällig?
Mein ältester Paketmitschnitt, in dem ich das verifiziert hatte, stammt vom 01.09.2022. Den Anschluss habe ich seit 10/2021.
Ich vermute mal, die Aussage "geht nur via IPv4" resultiert daraus, dass "dg.voip.dg-w.de" nur nach IPv4 auflöst (185.22.44.186).
Ich habe auch erst durch Paketmitschnitte mitbekommen, dass der SIP-Service via SRV-RR erfragt wird, siehe meine NSLOOKUP-Ausgabe im letzten Post, die das Verhalten der Fritzbox (wie per Paketmitschnitt ermittelt) nachbildet.
-
Telefonie bei Deutsche Glasfaser ist nach aktuellem Kenntnisstand IPv4-only.
Das wird durch ständige Wiederholung nicht wahrer:
Code
Alles anzeigenC:\>nslookup Standardserver: localhost Address: ::1 > set q=SRV > _sip._udp.dg.voip.dg-w.de Server: localhost Address: ::1 Nicht autorisierende Antwort: _sip._udp.dg.voip.dg-w.de SRV service location: priority = 20 weight = 1 port = 5060 svr hostname = sip20.voip.dg-w.de _sip._udp.dg.voip.dg-w.de SRV service location: priority = 10 weight = 1 port = 5060 svr hostname = sip10.voip.dg-w.de > set q=A+AAAA > sip10.voip.dg-w.de Server: localhost Address: ::1 Nicht autorisierende Antwort: Name: sip10.voip.dg-w.de Addresses: 2a00:6020:100:603::186 185.22.44.186 > sip20.voip.dg-w.de Server: localhost Address: ::1 Nicht autorisierende Antwort: Name: sip20.voip.dg-w.de Addresses: 2a00:6020:200:603::165 185.22.45.165Meine Fritzbox führt als SIP-Client die SIP-Registrierungen per IPv6 durch, auch die Sprachübertragung eines Telefongesprächs via RTP läuft bei mir via IPv6 - alles auch per Paketmitschnitt verifiziert.
In der Rufnummern-Konfiguration der DG-Rufnummern kann man das gewünschte Protokoll (IPv4 und oder IPv6) einstellen.
-
Sehr merkwürdig - ab und zu ist die Verbindung da und ping bring zurück eine richtige und korrekte Rückmeldung, siehe Anhang - die Datei habe ich archiviert, da sie sonst zu lang ist.
Das hatte ich als Möglichkeit in #329 schon in Betracht gezogen - ich kopiere es mal:
"
Noch ein Nachtrag:Zumindest für kurze Zeit scheint dein IPv6-Access (inbound + outbound) zu funktionieren. Ich vermute immer dann, wenn deine Fritzbox einen RA von der DG-Gegenstelle erhält und daraus die MAC-Adresse 20:00:00:00:20:38 der Gegenstelle lernt. Solange sie diese in ihrem Neighbor-Cache speichert (dürfte allerdings nur ein paar Sekunden sein), kann IPv6-Kommunikation erfolgen. Das könnte man per Dauer-Ping bei gleichzeitigem Langzeit-Paketmitschnitt (~ 2 Stunden) , der ein paar erhaltene RA umfasst, evtl. verifizieren. Zur Ansicht in Wireshark den Filter "icmpv6" setzen.
Nachtrag 2:Gemäß deinem ersten Mitschnitt empfängst du etwa alle 30 Minuten einen RA (die Router-Lifetime im RA ist mit 4500s recht lang, deshalb auch die großen RA-Zeitabstände). Auch ohne Paketmitschnitt: Wenn Du mal einen IPv6-Dauerping machst, könnte es sein, dass du etwa alle 30 Minuten für ein paar Sekunden Antworten bekommst, wenn meine Annahme zutreffend ist.
"Deine Datei zeigt Ping-Antworten, z.B. im Zeit-Intervall: 2025-08-12 15:51:59 - 2025-08-12 15:54:55, also für 176 Sekunden - solange hat die Fritzbox vermutlich die MAC-Adresse 20:00:00:00:20:38 der DG-Gegenstelle im Neigbor-Cache des WAN-Ports gespeichert, kurz zuvor hat sie diese wohl über ein von DG erhaltenes RA gelernt. Ich vermute, der Zeitabstand zwischen Ping-Erfolgen entspricht dem Abstand zwischen zwei erhaltenen RA:
2025-08-12 15:51:59
2025-08-12 16:21:58
2025-08-12 16:51:58
2025-08-12 17:21:57
:Kommt ganz gut hin: RA-Empfang so etwa alle 30 Minuten.
Noch ein Nachtrag:
Ich ergänze nochmal folgenden Auszug aus #372:
"Deine Paketmitschnitte zeigten, dass dein Router outbound keinerlei IPv6-Pakete mit globalen IPv6-Zieladressen senden kann, weil die MAC-Adressauflösung (per NS/NA) der DG-Defaultgateway-Adresse (fe80::22) scheitert: Dein Router sendet ständig NS an die zu fe80::22 gehörende SNMA = ff02::1:ff00:22 ("solicited node mulitcast addess"), die von der Gegenstelle jedoch nicht per NA beantwortet werden. Ausgehende IPv6-Pakete können deshalb nicht in Ethernet-Frames eingepackt werden - dein Router muss sie verwerfen."
Somit hast du nun eine schlüssige Diagnose, die du mit einem deiner Paketmitschnitte (derjenige, der die vielen NS an ff02::1:ff00:22 zeigt, die von der DG-Gegenstelle nicht beantwortet werden) und deiner Textdatei mit dem Ping-Log technisch belegen kannst.
Schön wäre noch ein langer Paketmitschnitt (~2h) am WAN-Port, der die erfolgreichen Pings, die kurz zuvor erhaltenen RA und die dazwischen liegenden NS an ff02::1:ff00:22 bei entsprechender Filtersicht (icmpv6) zeigt.
-
... die in #1 -#3 erläuterten Verfahren nicht mehr funktionieren.
Der Link aus #3 (https://www.telekom.de/hilfe/apps-die…dresse-behalten) führt auf eine Telekom-Hilfeseite mit dem Hinweis "In den ersten 150 Tagen nach der Kündigung können Sie über die Seite "Wechsel auf Freemail" Ihre E-Mail-Adresse selbst umstellen." Der enthaltene Link führt dich dann zum Login deines Telekom-Kundencenters, wo du den "Wechsel auf Freemail" beauftragen können solltest (ich kann's nur halt nicht mehr verifizieren, weil ich nach meiner Umstellung nun in meinem Freemail-Kundencenter lande, wo mir die Meldung "Die Vertragsumstellung ist nicht mehr möglich" und weiterer Erklärungstext angezeigt wird).
-
neisbe :
Du könntest dich ja hier erst Mal bei Freemail registrieren und eine noch freie E-Mail-Adresse anlegen.
Dann gehst du in die Mail-Verwaltung deines noch bestehenden Telekom-Vertrags, legst dort einen Mail-Alias an und wandelst diesen in die Hauptadresse des Kontos um. Dadurch wird deine bisherige Hauptadresse ihrerseits zum Alias.
Den gibst du im Anschluss frei, und zwar mit sofortiger Wirkung (ohne Sperre!)
Jetzt wechselst du in deine Freemail-Verwaltung und legst dort die eben freigegebene Adresse sofort als Alias wieder an. Anschließend machst du sie zur Hauptadresse deines Freemail-Kontos, wodurch die bisher dort definierte Adresse zum Alias wird - den kannst du dann auch ggf. löschen.
Im Endeffekt hättest du so deine bestehende T-Online-Adresse aus dem alten Vertrag herausgelöst und in eine Freemail-Adresse umgewandelt.
Das war die Alternativ-Variante, die ich mir seinerzeit überlegt hatte, bevor ich die elegantere Methode gemäß #3 entdeckte.
-
Das Problem ist, dass man auf dem FB die IPv6 (Präfix) Adresse schon sieht, nur die Anfragen von FB gehen ins Nirvana, aber DG wäscht ihren Händen mit dem "eigenen" Router Entschuldigung.
Das Problem ist, es DG zu beweisen.
Deine Paketmitschnitte zeigten, dass dein Router outbound keinerlei IPv6-Pakete mit globalen IPv6-Zieladressen senden kann, weil die MAC-Adressauflösung (per NS/NA) der DG-Defaultgateway-Adresse (fe80::22) scheitert: Dein Router sendet ständig NS an die zu fe80::22 gehörende SNMA = ff02::1:ff00:22 ("solicited node mulitcast addess"), die von der Gegenstelle jedoch nicht per NA beantwortet werden. Ausgehende IPv6-Pakete können deshalb nicht in Ethernet-Frames eingepackt werden - dein Router muss sie verwerfen.
Wenn du der DG so einen Paketmitschnitt schickst, wird der 1st-Level-Support damit allerdings nichts anfangen können, weil ... (such dir einen passenden Grund aus). Er diente vor allem dem Zweck, dass du dir sicher sein kannst, dass das Problem nicht bei deinem Router liegt.
-
DG muss das leisten, was in seiner Leistungsbeschreibung steht, siehe insbesondere 5.2:
ZitatDeutsche Glasfaser richtet einen Internet-Zugang mit IPv6 IP-Ad-
ressen ein. Für IPv4 stellt Deutsche Glasfaser eine private Netz-
werkadresse bereit die von Carrier Grade Network Address Trans-
lation (CGN) auf eine öffentliche Adresse umgeschrieben wird. ... -
Ich meinte die Kombi aus Mobil IP (RFC 6275) und IPSec.
Achso - ja, da gebe ich dir Recht! Es gibt im IPv6-Bereich einige Fehlentwicklungen, die sich ein der Praxis nicht durchgesetzt haben. Mobile IPv6 scheint dazuzugehören, weshalb ich mich auch nie näher damit befasst habe.
Andere Fehlentwicklungen sind bspw. SeND und CGA - aber vielleicht wird das in den Netzen von Geheimdiensten verwendet - ich habe so etwas in freier Wildbahn jedenfalls noch nie gesehen.
-
O2 macht IPv4 via PPPoE und dann IPv6 ueber DHCPv6
Jo, liegt in der Natur der Sache: Das in PPP enthaltene NCP (Network Contol Protocol) kann nur im Falle von IPv4 (NCP = IPCP) auch eine globale IP-Adresse zuweisen, nicht jedoch im Fall von IPv6 (NCP = IPV6CP). Wozu IPV6CP gut ist, kann man hier nachlesen (in Kurzform: Es wird nur ein 64-Bit Interface-Identifer ausgehandelt, mit dem der Router dann seine eine linklokale fe80-Adresse am WAN-Port bildet).
Für die dynamische Zuweisung einer IPv6-GUA am WAN-Port des Heim-Routers braucht es dort also entweder SLAAC oder DHCPv6. Ein IPv6-Präfix für's LAN geht dynamisch ohnehin nur via DHCPv6-PD. Da man um DHCPv6 also nicht herumkommt, wird man naheliegenderweise also auch den WAN-Port per DHCPv6 mit einer IPv6-GUA beglücken, beides kann man innerhalb desselben DHCPv6-Requests durch Anforderung von IA_NA (WAN-Port) und IA_PD (LAN-Präfix) erledigen.
weshalb Firewalls wohl oft nur den RFC Bereich fc00::/6 fuer DHCPv6
Hä? Also fc00::/7 ist der Range für ULA, in der Praxis fd00::/8 (fc00::/8 ist "special"). Und ja, Home-Router, wie die Fritzbox, vergeben zusätzlich zum LAN-Präfix des ISP noch ULA-Adressen (per DHCPv6 oder eher SLAAC), die dann sogar bevorzugt für die LAN-interne Kommunikation genutzt werden und auch dann noch funktionieren, wenn der IPv6-Internetzugang und damit das LAN-Präfix des ISP wegbricht.
Anfang des Jahres als die DHCP Antwort von Prefix 0:80fe:: kam statt des erwarteten Prefix fe80:: *
Also "fe80::*" wird niemals via DHCPv6 angeboten.
-
Beispiel: Ein für Firmen/Universitäten möglicherweise interessante Teil ist, dass man mit einer IPv6 Adresse aus seinem "Heimat"-Netz überall in der Welt sich in anderen IPv6-Netzen anmelden kann und damit automatisch ein verschlüsselter Tunnel ins heimische Netz aufgebaut wird, ohne weiteres dazutun, ist ja Teil des Protokolls.
Ähm - nein. Ich weiß nicht genau, wovon du bei "automatisch ein verschlüsselter Tunnel" sprichst, ich vermute du meinst IPsec-im Transport Modus. Das ginge im Übrigen prinzipiell auch mit IPv4, allerdings nicht " überall in der Welt", denn leider haben wir mit IPv4 ja kein Ende-zu-Ende.
Der Unterschied bzgl. IPsec ist hier: Bei IPv4 war IPsec nur ein optionales Addendum. Bei IPv6 ist es integraler Bestandteil der Protokoll-Definition. Die Funktionsweise von IPsec ist für beide Protokolle gleich.
Aber ich gebe dir Recht: IPsec im Transport-Modus ist "mal nicht eben einfach so" und schon gar nicht automatisch verfügbar. Man muss hier nämlich u.a. was für die gegenseitige Authentisierung der IPsec-Peers tun, und das bedeutet einigen Aufwand (unabhängig davon, ob man das für IPv4 oder IPv6 umsetzen will). Will man hier nicht "pre shared key" verwenden, gilt es, stattdessen zertifikats-basiert zu arbeiten und dafür (zumindest Unternehmens-intern) eine PKI-Struktur zu betreiben.
Generell:
IPv6 macht funktional genau dasselbe wie IPv4, nur mit verbesserten Möglichkeiten. Bei einigen Dingen, wie bspw. dynamischer Adress-Konfiguration (SLAAC gibt es bei IPv4 nicht, DHCPv6 arbeitet anders als DHCPv4, Adresszuweisungsmethoden sind bei IPv6 additiv, bei IPv4 "one of", die Existenz mehrerer IP-Adressen auf einem Netz-Interface ist bei IPv4 zumindest unüblich, temporäre IP-Adressen gibt es bei IPv4 nicht, ...) muss man halt umdenken - viele machen hier den Fehler, ihr IPv4-Wissen 1 zu 1 auf IPv6 zu übertragen und beklagen sich im Falle des Scheiterns über dessen "Komplexität".
Nachtrag zu Unterhaltung: Hier trifft "alte IPv4-Denke" auf IPv6:
Externer Inhalt www.youtube.comInhalte von externen Seiten werden ohne deine Zustimmung nicht automatisch geladen und angezeigt.Durch die Aktivierung der externen Inhalte erklärst du dich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt. -
Eingehende Verbindungen sind ebenfalls auf IPv6 angewiesen, da man nur eine private Adresse bei DG erhält.
Das machen doch nur ein paar Freaks, die sich dann in Foren wie bspw. diesem hier miteinander unterhalten. Und ISP-seitig sieht man das an Privat-Anschlüssen auch nicht so gerne, möchte man das doch lieber den hochpreisigen Business-Anschlüssen vorbehalten.
Die große Mehrheit will doch bloß Videos streamen, Social Media nutzen und online shoppen - und denen ist auch egal, ob das via IPv4 oder IPv6 (IP was ...?) erfolgt, dafür hat sie ohnehin keine Awareness.
-
Was wäre, wenn IPv6-only Dienste gäbe?
Davon sind wir zumindest in Deutschland noch einigermaßen weit entfernt:
Den zwar aktuell etwa 75% IPv6-sprechenden Clients (Link) steht service-seitig nur ein ziemlicher Flickenteppich IPv6-fähiger Web-Services (Auswahl aus Alexa-Liste) gegenüber (Link). Ein deutscher IPv6-only-Dienst wäre aktuell für 25% der deutschen Nutzer nicht erreichbar, das kann sich kein Dienste-Anbieter leisten.
Auf der Internationalen Bühne haben wir gar nur etwa 45% IPv6-sprechender Clients (Link) - ein IPv6-only-Dienst wäre folglich für 55% der Internet-nutzenden Weltbevölkerung nicht erreichbar.
-
Aktuell hoffe ich einfach, dass die Routing-Regeln gesetzt aber nicht aktiv geschaltet haben und das bei der nächsten Wartung in der Region passiert, bei Einigen scheint eine solche Problematik ja nach einer Wartung der DG verschwunden zu sein.
Das ist wahrscheinlich die nerven-schonendste Variante - glücklicherweise kommt man als reiner Internet-Konsument noch ohne IPv6 aus, ohne IPv4 wäre es umgekehrt allerdings eine Katastrophe.
Problematisch ist allerdings die Situation für deine LAN-Clients, denn die gehen von einem funktionierenden IPv6 aus.
Schau dir dazu mal die Ergebnisse dieser Seite an: http://he.test-ipv6.com/
Ich würde empfehlen, die IPv6-Unterstützung der Fritzbox vorerst abzuschalten. Du kannst sie ja ab und zu aktivieren, um zu testen, ob es irgendwann funktioniert.
-
Leseratte10 : Wie du ja auch schon erwähnt hast, ist für mich die Frage, wie sich dein Smartphone im Sleep-Modus verhält: Empfängt und verarbeitet es in diesem Zustand keinerlei WLAN-Traffic, insbesondere auch keine IPv6-RA, dann wird es nach hinreichend langem Schlaf beim Aufwachen natürlich keine valide IPv6-Adresse (Timeout VL bei Konfiguration via SLAAC) bzw. auch keine valide IPv4-Adresse (Timeout der DHCP-Leasedauer) mehr haben.
In dem Fall muss das Interface halt neu initialisiert werden. Das scheint dem Phone per IPv4 offenbar schnell zu gelingen, nicht jedoch für IPv6. Für mich sieht das nach einem Bug in deinem Phone aus. Lange VL/PL stellen hier nur einen Workaround dar, lösen das grundsätzliche Problem aber nicht.
Vielleicht kannst du das Problem mittels Paketmitschnitt in der Fritzbox (WLAN-Schnittstelle), durchgeführt während einer Aufwachphase deines Phones, näher analysieren? Dein Phone sollte nach dem Aufwachen IPv6-RS (Router Solicitations) senden - tut es das nicht, dann liegt das Problem beim Phone.
-
Was auch sehr interessant ist:
Der folgende Screenshot stammt aus einem Paketmitschnitt, der irrtümlich am LAN-Port der Fritzbox aufgezeichnet wurde:
Man sieht hier in den LAN-RA der Fritzbox, dass diese zwei GUAs (2a00:6020:bb40:f00::/64 und 2a00:6020:bb40:1000::/64) mit unterschiedlichen Lifetimes (1h, 0.5h) announced, die aus unterschiedlichen PD-Blöcken (2a00:6020:bb40:f00::/56 und 2a00:6020:bb40:1000::/56) stammen.
Sieht irgendwie kaputt aus.
Eine weitere Auffälligkeit sehe ich in den folgenden "ICMPv6 Destination Unreachables", die die FB an den LAN-Client 2a00:6020:bb40:1000:50f4:7e02:b8ec:2a73 sendet:
Das aus meiner Sicht Merkwürdige ist die Quelladresse der ICMPv6 Destination Unreachables: Diese kommen von der WAN-Adresse der Box und nicht von deren LAN-Adresse, wie ich es erwarten würde. Aber gut, muss nichts heißen.
-
Die per DHCPv6 von DG zugewiesenen IPv6-Adressen scheinen auch öfter zu wechseln:
LAN: 2a00:6020:bb40:f00::/56 + WAN: 2a00:6020:bb00::6
LAN: 2a00:6020:bb40:1000::/56 + WAN: 2a00:6020:bb00::5
LAN: 2a00:6020:bb40:1300::/56 + WAN: 2a00:6020:bb00::?Das scheint mir inzwischen auch ein relativ sicheres Indiz dafür zu sein, dass die DG-seitige IPv6-Konfiguration des Kundenanschlusses fehlerhaft ist.
-
Das bedeutet, der DHCP6-Server der DG nutzt merkwürdig kurze Lease-Zeiten sowohl für die WAN-IPv6 als auch für das Präfix, die Fritzbox übernimmt diese Lease-Zeiten dann für das Router Advertisement, und die (meiner Meinung nach standardkonformen) Endgeräte verwerfen diese dann, weil die verbleibende Laufzeit zu kurz ist; und verlieren dementsprechend dann irgendwann ihre IPv6-Verbindung.
Nein, die LAN-seitigen VL- und PL-Werte in RA für SLAAC sind standardkonform und werden von standardkonformen Geräten auch nicht verworfen. Die Leasezeiten sind auch nicht "merkwürdig" - im Grunde sind die absoluten Werte ziemlich irrelevant. Entscheidend ist, dass die Refresh-Mechanismen hinreichend oft funktionieren. Das tun sie aber, weil die Refresh-Raten mit den absoluten Leasedauer-Werten bzw. VL/PL-Werten skalieren.
Schau dir an einem Windows-PC in deinem LAN mal eine halbe Stunde (z.B. alle 5 Minuten) lang den Output des folgenden Kommandos an:
netsh int ipv6 sh addr
Sieht bei mir so aus:
Code
Alles anzeigenC:\>netsh int ipv6 sh addr Interface 1: Loopback Pseudo-Interface 1 Addr Type DAD State Valid Life Pref. Life Address --------- ----------- ---------- ---------- ------------------------ Other Preferred infinite infinite ::1 Interface 10: Ethernet Addr Type DAD State Valid Life Pref. Life Address --------- ----------- ---------- ---------- ------------------------ Public Preferred 50m54s 50m54s 2a00:6020:47XX:XXXX:692:26ff:feYY:YYYY Temporary Preferred 50m54s 50m54s 2a00:6020:47XX:XXXX:6010:f5db:c80a:f8ae Public Preferred 1h59m40s 59m40s fd0d:cf1e:63ee:0:692:26ff:feYY:YYYY Temporary Preferred 1h59m40s 59m40s fd0d:cf1e:63ee:0:6010:f5db:c80a:f8ae Other Preferred infinite infinite fe80::692:26ff:feYY:YYYY%10Da kannst du wunderschön die VL- und PL-Werte anschauen, wie sie abnehmen und etwa alle 10 Minuten durch empfangene RA aktualisiert werden. Die VL/PL-Werte der GUA (2a00:6060...) sinken dabei minimal auf ~30 Minuten und werden dann wieder auf 60 Minuten hochgesetzt (dies im Rhythmus der DHCPv6-Renews am WAN-Interface der FB, die alle 30 Minuten die Leasedauer wieder auf 60 Minuten hochsetzen). Die ULA werden hingegen ~ alle 10 Minuten (Intervall zwischen 2 RA) wieder auf ihren Maximalwert (~ 2h) gesetzt - dort ist die FB selbst der Herr der Dinge.
Du kannst dabei parallel im Windows einen Wireshark mitlaufen lassen und dir die empfangenen RA mit dem Anzeigefilter icmpv6.type==134 darstellen lassen - du siehst dann sehr gut, wie die per RA gelieferten PL/VL-Timer mit der Anzeige der PL/VL-Werte der Adressen korrespondieren.
-
Ein Home-Router ist nach der reinen Lehre weder "Fisch noch Fleisch" sprich weder ein reiner Router noch ein reiner Host, sondern von jedem etwas (am WAN-Port ist er z.B. eher ein Host, LAN-seitig ein Router - bei IPv6 kommt noch der Mechanismus DHCPv6 PD hinzu, der eigens für dynamisch konfigurierte Home-Router ersonnen wurde).
Deshalb gibt es auch eine gesonderte Beschreibung für diese Zwitterwesen: RFC7084 in Verbindung mit RFC6092.
