Ich würde ihm durchaus die gestern ausgewerteten Paketmitschnitte zeigen. Geeignete Ansichtsfilter siehst du ja in den von mir beigefügten Screenshots. Diese zeigen optimal das wichtigste Problem (neben anderen) mit deinem Anschluss.
Wenn er wirklich "vom Fach" ist und nicht nur "die Leitung durchmessen" kann, muss er das Problem erkennen und bestätigen. Vor Ort wird er es allerdings wohl nicht lösen können - es liegt ja in der DG-Infrastruktur.
dgfeuer :
Ok, hier noch die nachträgliche Analyse zu deinem zweiten Mitschnitt:
IPv6-Ping-Test zu google.de und heise.de:
Die IPv6-Adressen können nur über IPv4 (DG-DNS-Resolver 185.22.44.50) aufgelöst werden. Die ICMPv6 echo-Pakete (Type 128) werden auf Ethernet-Ebene ausgehend korrekt an die MAC-Adresse 20:00:00:00:28:25 des DG-Gateways gesendet. Antworten bleiben jedoch aus (no response found!)
DNS-Queries zu den IPv6-DNS-Resolvern der DG:
Dieses Ergebnis war auch schon im ersten Paketmitschnitt zu sehen: DNS-Queries zu 2a00:6020:100::1 und 2a00:6020:100::2 gehen ordnungsgemäß raus (auf Ethernet-Ebene korrekt an die MAC-Adresse 20:00:00:00:28:25 des DG-Gateways) - es kommen aber keine Antworten zurück.
TCP-Verbindungen zu IPv6-Zielen:
Man sieht nur ausgehende SYN (ggf. mit Retransmissions), die auf Ethernet-Ebene korrekt an die MAC-Adresse 20:00:00:00:28:25 des DG-Gateways gesendet werden. Es kommen jedoch nie SYN/ACK von den angesprochenen Zieladressen zurück.
Zusammenfassung:
Keine wirklich neue Erkenntnis, IPv6 funktioniert nur outbound (dein Router macht alles richtig) - nun aber durch hinreichend viele Beispiele belegt.
Der Fehler liegt klar bei DG.
Dein Router scheint vermutlich auch jede Stunde neue IPv6-Adressen zu bekommen, nachdem die jeweils aktuellen nicht verlängert werden und in einen DHCPv6-Timeout der Leasedauer laufen?
Frage:
Kann die Fritzbox diese IPv6-Werte nach Ablauf von T1 per DHCPv6 Renew bzw. spätestens nach Ablauf von T2 per DHCPv6 Rebind verlängern? Falls nicht, müsstest du spätestens nach 3600 Sekunden einen DHCPv6-Fehler in der Ereignisanzeige der FB wegen DHCPv6-Timeout sehen. Im besten Fall würde die FB sofort eine neue DHCPv6-Lease anfordern, was ebenfalls der Ereignisanzeige zu entnehmen wäre. Falls dem so ist, müsstest du jede Stunde entsprechende Log-Einträge sehen. Und hier wäre dann die Preisfrage, ob du jedes Mal andere IPv6-Werte bekommst (ich vermute mal: Ja)?
dgfeuer : Kannst du bitte diese Frage beantworten? Deinen zweiten Trace habe ich kurz angeschaut. Reiche eine Analyse später noch nach. Es sieht aber so aus, als hättest du jetzt nochmal andere IPv6-Adressen bekommen.
Es ist bekannt, dass sich die Kundenanschlüsse bei der DG gegenseitig erreichen können. Ich sehe bei mir im Log auch Broad- oder Multicastscasts anderer Kundenrouter.
Die hier beobachteten Leaks sind Multicasts an ff02::..., haben also link scope und können sich somit nur vom Sender in dessen WAN-Uplink ausbreiten. Es sind ja NS, also ND-Pakete zur MAC-Adressauflösung (hier der DG-Routeradresse). Wenn die in anderen Netzen als dem eigenen WAN-Uplink auftauchen, ist das ein Fehler.
Ja, die Kundenanschlüsse können sich gegenseitig (per Unicast) erreichen, aber sicherlich nur ordentlich geroutet über die BNG und ggf. die dahinter liegende Infrastruktur (Kundenanschlüsse an verschiedenen BNG).
So, hier nun meine erste Analyse deines Paketmitschnitts:
Das Interessante beginnt im Paket 241 mit einem DHCP Release und in Paket 242 mit einem DHCPv6 Release (Drücken auf den Knopf "Neu verbinden").
Unmittelbar danach (Pakete 244-247) fordert deine FB per DHCP erfolgreich eine IPv4-Adresse für den WAN-Port der FB an (Leasedauer: 1 Stunde).
Auffällig hier: Du bekommst eine andere IPv4-Adresse aus 100.64.0.0/10 als die, die gerade per DHCP Release zurück gegeben wurde. Normalerweise erhält man wieder dieselbe Adresse.
Du bekommst per DHCP-Option das IPv4-Standardgateway der DG mitgeteilt: 100.102.64.1. Deine FB löst in der Folge via ARP (Pakete 255, 258) dessen MAC-Adresse auf: 20:00:00:00:28:25
Bzgl. IPv6 führt die FB zunächst eine DAD (duplicate address detection) für die linklokale Adresse fe80::[...] aus (Pakete 248, 256). Anschließend schickt die FB im Abstand von 4 Sekunden 4x Router Solicitations (RS) (Pakete 257, 294, 320, 351) raus, die aber erst nach 16 Sekunden (gemessen vom ersten RS) vom DG-Gateway (fe80::22, MAC: 20:00:00:00:28:25 wie oben) mit einem RA (Paket 384) beantwortet werden.
Der Inhalt des RA ist soweit ok:
Endlich kann per DHCPv6 (Pakete 379, 380 mit Rapid Commit) erfolgreich IPv6 angefordert werden. Du bekommst eine IPv6-Adresse für den WAN-Port (IA_NA) und ein /56-Präfix für das LAN (IA_PD), beides mit einer Lease-Dauer von 3600 Sekunden und den Renew- bzw. Rebind-Timern (T1, T2) von 1800 bzw. 2880 Sekunden.
Auffällig auch hier: Sowohl die WAN-Port-Adresse, als auch dein LAN-Präfix weichen von den Werten ab, die du vorher zugewiesen bekommen hast (vgl. Werte im DHCPv6-Release, s.o.). Normalerweise bekommt man stets dieselben Werte zugewiesen.
Frage: Kann die Fritzbox diese IPv6-Werte nach Ablauf von T1 per DHCPv6 Renew bzw. spätestens nach Ablauf von T2 per DHCPv6 Rebind verlängern? Falls nicht, müsstest du spätestens nach 3600 Sekunden einen DHCPv6-Fehler in der Ereignisanzeige der FB wegen DHCPv6-Timeout sehen. Im besten Fall würde die FB sofort eine neue DHCPv6-Lease anfordern, was ebenfalls der Ereignisanzeige zu entnehmen wäre. Falls dem so ist, müsstest du jede Stunde entsprechende Log-Einträge sehen. Und hier wäre dann die Preisfrage, ob du jedes Mal andere IPv6-Werte bekommst (ich vermute mal: Ja)?
Sichtbar (Filter ipv6 && ipv6.addr != ff02::1:ff00:22) ist nun folgende Problematik bzgl. outbound bzw. inbound IPv6-Kommunikation zu/von globalen IPv6-Zielen:
Man sieht einzig ausgehende DNS-Requests (nach ipv64.net) von der WAN-Port-Adresse deiner FB (die ist ja DNS-Forwarder für die Clients in deinem LAN) zu den DNS-Resolvern der DG (2a00:6020:100::1 und 2a00:6020:100::1), die auf Ethernet-Ebene auch korrekt an die MAC-Adresse 20:00:00:00:28:25 des DG-Gateway gesendet werden. Gleichwohl sieht man keinerlei IPv6-Inbound-Traffic, insbesondere werden die DNS-Requests an die IPv6-DNS-Resolver der DG nie von diesen beantwortet.
Sämtliche DNS-Auflösungen funktionieren nur über die IPv4-DNS-Resolver der DG (185.22.44.50 und 185.22.45.50), diese liefern dir auch die IPv6-Adressen angefragter Ziele (z.B. www.google.de) zurück. Allerdings sehe ich keine ausgehenden ICMPv6 Echo-Pakete (Ping) zur IPv6-Adresse von www.google.de oder zu irgendwelchen anderen IPv6-Zielen. Aber egal: die DNS-Requests zu den IPv6-DNS-Resolvern der DG, die von denen nicht beantwortet werden, sind hinreichende Indizien, dass es da ein IPv6-Problem seitens DG gibt.
Dann ist mir noch folgende Merkwürdigkeit aufgefallen:
Zu deinem Kundenanschluss werden Fremdpakete (Neigbor Solicitations) von Fremdroutern anderer Kundenanschlüsse "geleakt":
Es werden etwa in Sekunden-Abständen "Neighbor Solicitations" an die aus der Adresse fe80::22 des DG-Gateways abgeleitete SNMA (Solicited Node Mulitast Address) ff02::1:ff00:22 (MAC: 33:33:ff:00:00:22) an deinem Kundenanschluss (Paketmitschnitt im "promiscuous mode" am WAN-Port deiner FB) mitgeschnitten (Filter: icmpv6.type==135 && ipv6.addr==ff02::1:ff00:22). Die haben sich da verirrt und dort nichts verloren!
Ich habe Leaks von insgesamt 14 AVM- und 15 Sagemcom Broadband SAS-Routern gefunden. Eine Liste von deren linklokalen- und MAC-Adressen habe ich dir zugeschickt.
Gerade das letzte Phänomen ist ein gutes Indiz einer DG-seitigen Fehlkonfiguration deines Anschlusses - damit kannst du dort "Druck" aufbauen! Und alles mit Daten belegen.
Mich erinnert das an einen ähnlichen Fall von gordrin , siehe #89. Ich weiß da aber gar nicht, ob dessen Problem inzwischen gelöst ist.
Auch auffällig:
Dein Anschluss liegt im Block 2a00:6020:8f00::/41. Das ist offenbar einer der Ranges, in denen die DG ein neues IPv6-Adressierungskonzept einführt, und in denen es deshalb gelegentlich Probleme mit IPv6 gibt. Andere Beispiele von ähnlich gelagerten und hier im Forum diskutierten Problemfällen liegen in den Ranges 2a00:6020:7380::/41, 2a00:6020:7680::/41 und 2a00:6020:7880::/41 - dort kommt ebenfalls das neue Adressierungskonzept zum Einsatz. Siehe #152 bzw. #10.
Ergänzung:
Die fehlenden (also im Paketmitschnitt nicht gefundenen) IPv6-Pings zu IPv6-Zielen im Internet sind vermutlich nur als IPv4-Pings (ICMP echo request) rausgegangen, weil du nur
ping [Ziel]
verwendet hast. Dummerweise sehe ich die IPv4-Pings nicht, weil der Ansichtsfilter nicht icmp enthält.
Es wäre aber gut, doch noch anhand von Beispielen zu belegen, dass IPv6 nur outbound funktioniert (Forwarding zur MAC-Adresse des DG-Gateways), von dort aber aber nie Antworten zurück kommen.
Mach dazu bitte nochmal einen Paketmitschnitt an der FB, während du an einem Windows-PC im LAN explizit für ein paar Ziele mit IPv6-Adressen
ping -6 [Ziel]
ausführst. Z.B. google.de, heise.de, facebook.com, wikipedia.org
Bitte anschließend den Trace in Wireshark mittels icmpv6 || icmp || dns || arp filtern+exportieren und mir zur Nachanalyse schicken.
so wie du beschrieben hast. Von der FritzBox. Reconnect und nochmal einen ipv6 test von einem laptop aus
wundert mich halt, weil der letzte Stand doch war, dass du an der FB noch gar kein IPv6 bekommen hast. Aber ich schaue mir mal deinen Capture an ...
Sollte ich den ONT auch nochmal zurück setzen ?
Also wenn da alles "grün" leuchtet (falls du den Nokia hast), sehe ich dafür keine Notwendigkeit. Anderseits schadet es auch nicht.
Datei kommt gleich.
Kannst du gerne schicken, nur was hast du denn da genau mitgeschnitten?
durchgeführt. Würde dir das gerne senden aber erlaubt ist nur bis 1 MB.
Du kannst den Mitschnitt verkleinern, indem du in Wireshark nur die relevanten Pakete filterst:
icmpv6 || dhcpv6 || dns || dhcp || arp
Gefilterte Ansicht anschließend speichern: "Datei | Ausgewählte Pakete exportieren..." und unter "Paketbereich" die Default-Einstellungen (Alle Pakete + Angezeigt) belassen. Die PCAP-Datei kannst du anschließend noch zippen, sollte aber auch plain schon klein genug sein.
die aktivierungsseite funktionierte auch nicht
Um die Sache nicht unnötig kompliziert zu machen, würde ich nicht gleich mit Fiber anschließen. Probier doch erst Mal via WAN-Uplink-Port und ONT.
Aber im Heimnetz zu Hause immer noch eher unüblich.
naja, ob dem so ist, wäre ich mir nicht so sicher - in der Fritzbox würde Adressvergabe per DHCPv6 (IA_NA) statt SLAAC mit der folgenden Einstellung bewirkt:
Aber gut, Default-Einstellung ist m.W. seit Fritz-OS V8.03 die zweite Option (DNS-Server und IPv6-Präfix (IA_PD) zuweisen), bei früheren Versionen war es wohl die erste Option (Nur DNS-Server zuweisen).
Wer da DHCPv6 für LAN/WLAN-Geräte wollte, musste schon überhaupt zu diesen Einstellungen vordringen und dann auch noch die Wirkungsweise der einzelnen Optionen verstanden haben.
Hatte gestern noch die FritzBox Fiber zum testen dran.
Naja, zuviele Wechsel Ubiquiti -> Fritzbox -> Win-PC, da ist der DHCPv6-Server der DG schnell mal beleidigt ...
Aber, wenn du schon eine FB zum Testen hast - dann hänge die doch nach gebührlicher Warte-Zeit mal wieder dran. Und wenn die dann wieder IPv6 bekommt, ohne dass IPv6-Kommunikation mit dem Internet anschließend tatsächlich funktioniert, dann mach doch bitte mal einen Paketmitschnitt in der FB (Browser-Tab 1: Hilfe und Info | FRITZ!Box Support | Paketmitschnitt | 1. Internetverbindung - Start), während du in einem Browser-Tab 2 unter "Internet | Online-Monitor | Verbindungsdetails" die Schaltfläche "Neu verbinden" betätigst und nach Erhalt der IPv6-Adresse(-n) noch einen Ping zu einem IPv6-Ziel im Internet von einem LAN-Client aus durchführst.
Mein Angebot, mir den Mitschnitt, den du mir per Privat-Konversation zuschicken kannst, anzuschauen, steht immer noch.
Das ist im Heimnetz ja eher unüblich, da kommen Router-Advertisements zum Einsatz.
<KLUGSCHEISS>
Außer in routerlosen Netzen kommen die immer zum Einsatz, auch wenn man die Clients im Netz ausschließlich per DHCPv6 konfigurieren möchte:
Ob LAN-Clients per SLAAC oder per DHCPv6 IPv6-Adressen bekommen, muss über die Konfiguration der M/O-Flags in den RA gesteuert werden (M=1: DHCPv6, M=0,O=1: SLAAC und zusätzliche Daten (z.B. DNS-Serveradressen) via stateless DHCPv6 + ggf. RA-Optionen, M=0,O=0: SLAAC und zusätzliche Parameter ausschließlich via RA-Optionen)
</KLUGSCHEISS>
Windows würde nach mittels DHCPv6 fragen, wenn es vom DG-Router ein RA erhält, in dem das M-Flag gesetzt ist (Windows versucht das aber nach der ihm eigenen Art auch ohne das).
Es muss nach Abklemmen des Routers aber mindestens eine Stunde gewartet werden, ehe man irgendetwas anderes anklemmt, sei es einen PC oder einen anderen Router.
Wir reden aneinander vorbei: Du redest vom LAN-internen Gateway für deine Clients im LAN - Das ist die fe80-Adresse am LAN-Interface deiner Ubiquiti.
Ich rede vom Gateway der DG. Das ist der Default-Router, den deine Ubiquiti verwendet, um IPv6-Pakete über das WAN-Interface ins Internet zu schicken. Der steht in der Routingtabelle deiner Ubiquiti als next hop für den Default-Eintrag ::/0.
Kannst du den auslesen? Sollte ebenfalls eine fe80-Adresse sein.
DG Gateway ist auch vorhanden 2a00:6020:......./64
Das wäre dann der Fehler: Das DG-Gateway wird dynamisch aus den RA gelernt, die es zu deinem WAN-Port sendet. Es muss folglich eine fe80-Adresse sein. Es gibt lediglich eine globale /128-Adresse 2a00:6020:..../128 für deinen WAN-Port (zugeordnet per DHCPv6) und kein /64-Netz, weil im RA keine PIO vorhanden ist.
Kannst du in deiner Ubiquiti nachschauen, ob eine IPv6-Defaultroute (::/0) vorhanden ist, und wie die DG-Gateway-Adresse lautet (sollte mit fe80 beginnen)?
Kannst du ferner den IPv6-Neighbor-Cache für das WAN-Interface der Ubiquiti anschauen, ob dort ein Eintrag für das DG-Gateway vorhanden ist?
Falls du am WAN-Port ein Packet-Capture machen kannst, während die IPv6-Verbindung zu DG aufgebaut wird (z.B. nach einer Reinitialisierung des WAN-Interface), dann kann ich dir anbieten, mir die Capture-Datei zwecks Analyse per Privat-Konversation zuzuschicken.
Jetzt möchte man mir einen Technikereinsatz für 80€ berechnen sollte dies mein verschulten gewesen sein.
Na, ist doch super! Da es nicht dein Verschulden ist, hast du ja nichts zu befürchten. Und du bekommst dediziert einen Techniker, der sich deines Problems annimmt.
Fragt sich nur, was der macht, wenn er vor Ort kommt - wenn er nur die "Leitung prüft", im Sinne von physischer Konnektivität (die ist ja vorhanden), sich aber nicht weiter für die Prüfung der Verfügbarkeit/Nutzbarkeit von IPv6 interessiert, dann bist du angeschmiert und darfst zahlen. Deshalb würde ich bei Anforderung des Technikers genau definieren, was der prüfen/beheben soll, nämlich deine IPv6-Konnektivität - der Rest funktioniert ja.
Es ist auch hier auffällig, wie in ähnlich gelagerten, im Forum diskutierten Fällen, dass das Problem in einem BNG-IPv6-Range auftritt, in dem DG offenbar ein geändertes IPv6-Adressierungsschema verwendet.
Es handelt sich dabei um Blöcke
2a00:6020:XYZ0::/41 (Z=0 oder Z=8, hier 2a00:6020:8f00::/41), in denen die WAN-Port-Adresse aus 2a00:6020:XYZ0::/112 (hier 2a00:6020:8f00::/112) vergeben wird.
In anderen Bestandsblöcken 2a00:6020:XYZ0::/41 (Z=0 oder Z=8) älterer Art werden WAN-Port-Adressen hingehen stets aus 2a00:6020:1000:PQ::/112 zugeordnet, wobei PQ für jedes XYZ einen separaten Wert hat. Ich hatte das in #10 mal näher beschrieben.
Im neuen Adressierungsschema scheint es gelegentlich noch zu haken.
Auch hier muss ich wieder viel rätseln und mir meinen Reim selbst drauf machen:
Der Traceroute erfolgt also an einem Windows-Client im LAN 2a00:6020:8f41:cd00::/64 hinter einer Fritzbox mit der LAN-Adresse 2a00:6020:8f41:cd00:b6fc:7dff:fe41:cf9b (OUI b4:fc:7d = AVM).
Die Fritzbox hängt aber wohl nicht direkt am DG-Anschluss, sondern hinter deiner Ubiquity an deren LAN-Port mit der Adresse fe80::2870:4eff:ff84:1c22 (OUI 28:70:4e = Ubiquity).
In der Ubiquity hast du für IPv6 eine Prefix-Delegation 2a00:6020:8f41:cd00::/64 an die Fritzbox definiert. (Nebenbei: Existiert in der Ubiquity dafür auch eine Route zur Fritzbox mit next hop = WAN-Interace-IPv6 der Fritzbox? Welches IPv6-Netz ist denn für den WAN-Uplink deiner Fritzbox zur Ubiquity konfiguriert?)
Daraus folgt, dass deine Ubiquity am DG-Anschluss ihrerseits von der DG wohl den PD-Block 2a00:6020:8f41:cd00::/56 zugewiesen bekommen hat. Das liegt im Range 2a00:6020:8f00::/41 - einem der neueren Ranges, bei denen DG auch ein neues IPv6-Adressierungskonzept verwendet. Die WAN-Port-Adresse müsste dort in 2a00:6020:8f00::/112 liegen, bei dir also 2a00:6020:8f00::df, wenn ich es richtig sehe.
Nochmal zum Traceroute: Wenn meine Deutung richtig ist, ist Hop 2 (fc00::1) nicht die DG sondern dein Ubiquity-Router?
Wie wär's, wenn du erstmal die IPv6-Funktion mit einem Client direkt in einem LAN hinter der Ubiquity testest?
Ich wüssete gerne mal wie ihr das Problem beschrieben habt.
Was ist denn genau dein Problem?
Deinen ersten beiden Meldungen (#50, #138)
Bei mir das gleiche Problem ipv6 von extern nicht erreichbar.
...
tracert -6 ipv6.google.com
endet mit dem 2. Hop auf fc00::1
und
Habe ebenfalls Intern keine ipv6 trotz korrekten Einstellungen
Trace 2. Hop fc00::1
würde ich entnehmen, dass bei deinem Anschluss gar keine IPv6-Kommunikation (weder outbound noch inbound) möglich ist. Bzw. hast du evtl. noch nicht mal IPv6-Adressen zugewiesen bekommen (WAN-Adresse + LAN-PD-Block)?
Alles etwas dünn, um hierzu etwas sagen zu können.
Habe außer: Username, Passwort,Registrar nichts zum Eintragen
Ist merkwürdig - in meiner FB7590 (auch aktuelle Version 8.03) sehe ich nach Umstellung eines in der FB vordefinierten Telefonie-Anbieter-Profils (in meinem Fall "Deutsche Glasfaser" und "dus.net") auf "Anders Anbieter" stets die vollständigen Detail-Einstellungen des jeweiligen Anbieters. Nach Vornahme einer Änderung und deren Speicherung wird mir dann wieder die reduzierte Sicht des jeweiligen Telefonie-Anbieters angezeigt.
Vielleicht machst du doch mal einen Werks-Reset deiner Fritzbox und konfigurierst nochmal alles "from the scratch".
So DG hat mir eben mitgeteilt ich soll mal das Modem reseten.
Eine erwartungsgemäße Ansage, dem Problem total angemessen!
Kontrolliere bitte nochmal im DG-Kundenportal unter "Meine Telefonie | Meine Rufnummern", ob dort deine Rufnummer(-n) deinem(-n) SIP-Account(s) (dort ohne die führende "3050" dargestellt) korrekt zugeordnet ist/sind.
Wähle aus, welche Kategorien Du erlaubst. Für jede Kategorie kannst Du über „Details anzeigen“ sehen, welche Cookies und Skripte konkret geladen werden, welche Empfänger beteiligt sind und wie lange gespeichert wird.
Weitere Informationen: Datenschutzerklärung · Impressum
