Gäbe es weitere Optionen, das zurückkehrende Paket der eigentliche Quelle zuordnen zu können?
Ich verweise hierzu mal auf meinen Beitrag #12, in dem ich auf die Alternativen "6to4-PMT" und "6rd" eingegangen bin. Wissensquellen sind dort entsprechend verlinkt
Es sieht ganz nach der neuem IPv6-Adressvergabe-Systematik der DG aus (vgl. #104), hier für den IPv6-Block 2a00:61e0:aa80::/41 und WAN-Adressen aus 2a00:61e0:aa80::/112.
Auffällig auch, dass du nur den PD-LAN-Präfix 2a00:61e0:aac0:558::/64 anstelle eines üblichen /56 (hier wäre das entsprechend 2a00:61e0:aac0:500::/56) zugewiesen bekommen hast.
Wie die vielen Fälle in diesem Forum zeigen, übt DG beim neuen Konzept noch IPv6, nach Wochen oder Monaten geduldigen Wartens funktioniert es irgendwann vielleicht auch mal.
Sieht nicht so aus, als würde IPv6 funktionieren. Wenn du es testweise mal in der Fritzbox deaktivierst und nur mit IPv4 arbeitest, könnte ich mir vorstellen, dass sich die Android-Probleme in Luft auflösen.
Es kommen hier übrigens IPv6-Adressen aus 2a00:61e0::/32 (statt üblicherweise aus 2a00:6020::/32) zum Einsatz, aber das sollte egal sein.
Wenn ein 6to4-Paket über den CGNAT hinaus käme (tut es nicht) würde es natürlich zur 6to4-Anycast-Adresse eines 6to4-Relays geroutet. Der Rück-Traffic käme sehr wahrscheinlich von einem anderen 6to4-Relay. Aber selbst, wenn es dasselbe Relay wäre, würde es prinzipbedingt immer direkt zum Kundenrouter tunneln wollen, denn es hat keinerlei Zusatzinformationen.
Ok. Also nochmal anders: Ein CGNAT arbeitet dynamisch und erzeugt für ausgehende IP-Pakete NAT-Sessions, in denen es sich zusätzlich zur Quelladresse einen UDP- oder TCP-Quellport für die Rückübersetzung merkt. Nun enthalten ausgehende 6to4-Pakete aber kein UDP oder TCP. Auf den IPv4-Header folgt sofort das getunnelte IPv6-Paket. Folglich kann keine NAT Session generiert werden. Das Paket wird verworfen.
Weshalb nicht? Das NAT-Gateway beim Provider muss doch grundsätzlich die Verbindung kennen, um die Maskierung wieder umzukehren. Ich verstehe gerade den Unterschied zu jeder anderen ausgehenden Verbindung nicht.
Siehe meine letzte Antwort.
Was würde denn der CGNAT für das ausgehende 6to4-Paket in seine NAT-Session Table eintragen wollen? Ist wie mit ESP bei IPsec: An einem CGNAT nicht NAT-fähig. Und einen zu NAT-Traversal analogen Mechanismus gibt es für 6to4 nicht.
Man müsste ein statisches 1:1-NAT am CGNAT einrichten, um das 6to4-Paket raus zu natten...
Aber das wäre ohnehin sinnfrei, denn das Antwort-Paket käme von einem 6to4-Relay ja niemals zurück zum CGNAT, sondern würde von diesem ja direkt zum Kundenrouter geroutet werden wollen, dessen Adresse im 6to4-Präfix einkodiert ist. Das wiederum ist mit einer Router- Adresse aus 100.64.0.0/10 nicht möglich.
Dazu müssten wir mal die zugewiesenen Adressen sehen. Aber theoretisch sollte das sogar gehen. Oder woran scheitert es?
Nun. Es ist ein DG-Anschluss mit CGNAT und somit einer Adresse aus 100.64.0.0/10. Diese Adresse ist in den 6to4-Präfix einkodiert und sagt einem 6to4-Relay, wo es den IPv6-Rücktraffic hintunneln soll. Dazu muss diese Adresse aber öffentlich erreichbar sein. Schon der CGNAT wird ausgehende IPv4-Pakete, die direkt ein getunneltes IPv6-Paket enthalten, verwerfen.
Damit hast du dich über ein 6to4 Relay an IPv6 konnektiert. Damit umgehst du die fehlerhafte IPv6 Anbindung bei DG.
Kann eigentlich mit einer "privaten" WAN-Adresse aus 100.64.0.0/10 nicht funktionieren.
Nachtrag: Aber es kann schon sein, dass es an einem kaputten IPv6 liegt. Insofern wäre eher eine Deaktivierung von IPv6 zu testen.
Komischerweise zeigt mir der Eyeballs Test ab und zu 100% Ipv6 und dann wieder nur 100% Error an.
Das könnte bedeuten, dass IPv6 (seitens DG) nicht stabil läuft.
Möglicherweise verbessert sich deine Situation, wenn du testweise mal IPv6 in deinem LAN deaktivierst und deine Online-Games ausschließlich über IPv4 zockst.
Zum Abschalten von IPv6 nur LAN-seitig müsste es reichen, wenn du die "Router Advertisement im LAN aktiv" deaktivierst (Heimnetz | Netzwerk | Netzwerkeinstellungen | Erweiterte Netzwerkeinstellungen ändern | IPv6). LAN-Client anschließend mal neu starten.
Aber mein eigentliches Problem besteht darin, dass irgendwann im Dezember, vermutlich nach einer Wartung mein Internet aufgehört hat, so zu funktionieren wie es soll(te).
Schau mal bitte unter #104:, ob dein IPv6-LAN-Präfix in einem der dort gelisteten /41-IPv6-Ranges liegt (aus deinen nicht optimalen Schwärzungen würde ich hier den /41-Block 2a00:6020:9400::/41 herauslesen, deine WAN-Adresse müsste dann die Form 2a00:6020:9400::NNNN haben.).
Das würde bedeuten, dass DG auch Bestandsanschlüsse nach altem IPv6-Adresskonzept auf das neue IPv6-Konzept umstellt. In #104 habe ich einen weiteten Fall erwähnt - bei dem geht seit Umstellung IPv6 gar nicht mehr.
Solche Umstellungen sind nach meinen Beobachtungen mit einem BNG-Wechsel verknüpft - dein Anschluss zeigt an dem neuen BNG nun deutlich schlechtere Ergebnisse. Soweit mein Erklärungsversuch.
Um später in der Wireshark-Ansicht der Mitschnittdatei nur den UDP-Traffix von/zu dem LAN-Client anzuzeigen, an dem du den UDP-Traffic während der Messung generiert hast, kannst du in der Filterzeile von Wireshark (oben direkt unter der Symbolleiste) folgende Filter eingeben:
Hierbei natürlich die IPv4 bzw. IPv6-Adresse deines LAN-Clients eintragen.
Über Wireshark nehme ich an?
Du kannst/sollest einen Paketmitschnitt am WAN-Port der Fritzbox machen: Hilfe und Info | FRITZ!Box Support | Paketmitschnitte | 1. Internetverbindung | Start.
Du wirst gefragt, wo die Mitschnittdatei (auf deinem lokalen Rechner) gespeichert werden soll. Zum Ende des Mitschnitts auf "Stopp" klicken (und warten, bis die Mitschnittdatei gespeichert ist!). Die Mitschnittdatei anschließend zur Ansicht mit Wireshark öffnen.
Treten die hohen Paketverluste auch bei iperfs gegen IPv4-Iperf-Server auf?
Hast du denn jetzt wieder IPv6? Und funktioniert es auch?
Bei meinem bisherigen Vodafone Kabelanschluss funktionierte das UniFi Gateway problemlos am Kabel-Router.
Bist du sicher, dass das ein "Kabel-Router" war, oder war es nicht einfach nur ein "Kabel-Modem"? Das wäre ein himmelweiter Unterschied, denn wenn es nur ein Kabel-Modem war, würdest du nun Äpfel mit Birnen vergleichen.
Wenn es zuvor ein Kabel-Modem war, dann hat dein UCG die Internet-Verbindung hergestellt. Da meines Wissens an Vodafone-Kabel-Anschlüssen DS-Lite verwendet wird, dürfte der WAN-Port deines UCG entsprechend für DS-Lite konfiguriert sein. Das passt nun natürlich nicht mehr für die neue Konstellation, in der du den WAN-Port des UCG einfach mit einem LAN-Port des DG-Classic-Routers verbindest.
Wenn du an dieser Konstellation grundsätzlich festhalten möchtest, dann musst du den WAN-Port des UCG entsprechend umkonfigurieren: Du musst ihn grundsätzlich auf DualStack umstellen und ihm beibringen, dass nicht er die Internet-Verbindung herstellt, sondern der vorgelagerte DG-Classic-Router. Ich fürchte ferner, dass du dabei nur mit IPv4 glücklich wirst, nicht jedoch mit IPv6: Für IPv6 müsstest du DHCPv6-Prefix-Delegation konfigurieren, wobei der UCG der PD-Downlink-Router und der DG-Classic-Router der PD-Uplink-Router wäre, den du allerdings für diese Rolle auch konfigurieren können müsstest - ich glaube nicht, dass der DG-Classic-Router das kann.
Mit einer kundeneigenen Fritzbox anstelle des DG-Classic-Routers würde das eben beschriebene Szenario prinzipiell hingegen konfigurierbar sein. Allerdings endest du dann mit einer kaskadierten Router-Konfiguration, bei der die Clients im LAN hinter dem UCG im Falle von IPv4 3x NAT passieren müssen, um das Internet zu erreichen (1: UCG, 2: vorgelagerter Router, 3: CGNAT-Router bei DG). Davon würde ich eher abraten. Natürlich könnte man noch versuchen, das NAT am UCG abzuschalten, und ein reines IPv4-Routing einzurichten wie von mbo77 in #8 angedeutet - aber ich denke, das wäre dann die letzte Raketenstufe der Überforderung.
Die beste Lösung für die Konstellation, in der du am UCG festhalten möchtest, wäre, den UCG als ersten Router direkt an den Internet-Anschluss (ONT(?) der DG) zu hängen. Dafür muss der WAN-Port des UCG entsprechend umkonfiguriert werden. Die Telefonie könntest du dann über eine Fritzbox erledigen, deren WAN-Port du an einem LAN-Port deines UCG hängst (die Fritzbox soll dann nur Telefonie und sonst nichts machen). Aber das ginge alles erst nach Umstellung auf "kundeneigener Router" und Rückgabe des DG-Classic-Routers.
Und als letzte Option: Verzichte auf dein UCG und sei mit einem "Router für Laien" (DG-Classic-Router oder z.B. kundeneigene Fritzbox) zufrieden.
Ok, dann stimmt das Weldbild ja wieder.
Komisch, woraus rekrutieren sich denn die verschiedenen IPv6-/64 pro VLAN, wenn nicht aus einem übergeordneten /56, den man per PD erhalten hat? Und aus jedem dieser VLANs ist das Internet per IPv6 erreichbar?
HubeBube : Naja, für's WAN-Interface braucht's eine einzelne IPv6-Adresse (/128). Ob man die per SLAAC oder DHCPv6 (IA_NA) bekommt, hängt davon ab, was der ISP unterstützt. Das LAN-Präfix (/56) wird hingegen immer per DHCPv6 (IA_PD) angefordert. Rapid Commit hat damit gar nichts zu tun.
Das Phänomen ist recht charakteristisch für eine Konstellation (und die kommt bei DG leider gelegentlich vor), in der DG deinem Router+LAN zwar IPv6-Adressen zuweist, das IPv6-Routing in der DG-Infrastruktur jedoch nicht funktioniert (z.B. nach Umstellung des Anschlusses auf ein neues IPv6-Adresskonzept, vgl. #104). Allerdings müsste das dann Auswirkungen auf alle Clients im LAN haben, für die IPv6 aktiviert ist, und nicht nur dein TV-Gerät.
Du könntest an einem IPv6-aktivierten Client einmal testen, ob der IPv6-Ziele im Internet erreicht.
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
