[GELÖST] Ladeprobleme bei Webseiten und Medien mit aktiviertem IPv6

[Karl.]

Interessant wäre ob du eine IPv6 Adresse hast und ob der Router ein Prefix erhalten hat.

Sieht so aus, als würde der Microsoft Edge benutzt, der mit IPv6 Tests nicht klarkommt...

[Flole]

Also bei mir kommt Microsoft Edge 44.18362.449.0 mit diesem Test klar und zeigt korrekt an das eine v6 Verbindung besteht und ein Fallback dauert 14 Sekunden beim ersten Versuch und 1 Sekunde beim zweiten.

[Karl.]

Also bei mir kommt Microsoft Edge 44.18362.449.0 mit diesem Test klar und zeigt korrekt an das eine v6 Verbindung besteht und ein Fallback dauert 14 Sekunden beim ersten Versuch und 1 Sekunde beim zweiten.

Der Edge war nur ein Beispiel, da klappt nicht jeder v6 Test immer.

[maik005]

@Flole
MS Edge 44.19041.1.0
direkt beim ersten Versuch Fallback auf IPv4 nach <1 Sekunde.
Nutze den sonst nie

[j.mue]

Moin,

Der Thread ist schon sehr lang und ich habs daher nur überflogen und hoffe, jetzt nichts übersehen zu haben. Aber jedenfalls:
Ich glaube, ich kann diese Probleme in etwa bestätigen. Ich denke jedoch, das Problem ist auch ein wenig komplex.

Ich konnte es ein wenig eindämmen - ich hatte nämlich sowieso schon diverse Probleme und auch massiv Probleme mit meinem Philips Hue bekommen, nachdem sie irgend ein Firmware-Update einspielten. MAngels Changelog weiß ich nicht genau was ,aber nach der Analyse sah es so aus: Die haben da irgend ein IPv6-Interface dazugebastelt...
Aber noch mal einen Schritt zurück:

Mein Setup:
Kabel Modem: Technicolor TC4400
WifiRouter: Asus RT-AC88U
Verschiedene Windows, Apple, Linux Devices/Wlan Clients

ehemalige Probleme:
- Websessions mit höheren Privilegien und höheren Sicherheits-Features (IP-gebundene Sessions) unterbrechen unregelmäßig aber sehr oft innerhalb 1h - auch bei aktiver Nutzung.
- Philips Hue DIngens verliert ständig Verbindung ins Internet und umgekehrt, steht noch im Internet, aber ist nicht intern im "LAN" nutzbar (letzteres bedeutet, haus/app-steuerung/smarte schalter/alexa funzen nicht)

Diagnostik:
- Verschiedene Dinge, aber es stellte sich letztendlich heraus: DIE IPv6-Adresse der Clients Wechselt(e) ständig und sehr/zu oft. Bislang Ursache unbekannt.
- Korrigiert mich ,wenn ich falsch liege, aber Vodafone vergibt ja offenbar via DHCP-PD (Prefix Delegation) einen /64 IPv6-Adressbereich. Das kann mein Router genau so weiterreichen.
- Das HUE-Dingens hat zudem die PD-Parameter im Stateless-Modus IGNORIERT und versucht, mit einer fremden Adresse zu agieren und hat offenbar viele meiner Geräte verwirrt und sich oft selbst ausgesperrt (die v6er Adresse war quasi nicht routbar in meinem Netzwerk).

IPv6 hat so ein nices Feature, dass man einen Router massiv entlasten kann - auch in einem "prefix delegierten" Netz - indem man den "stateless"-Modus der "Adressvergabe" nutzt. Aufgrund der in der Regel massiven Menge an Adressen, nimmt sich ein Device da einfach eine Adresse im Bereich und wenn es damit durchkommt (Verbindungen), behält es diese, bis irgendwas ist und probiert da eine neue Adresse.

Joah. Sollte jetzt schon klick machen - Genau - Wenn im OT Beschriebenes Problem offenbar existiert und du Stateless Config fährst, erklären sich die ständigen random Adresswechsel. Besonders nervig, wenn man ssh-verbindungen offen hat - ja, bei AKTIVER Session wurde da schon Adresse gewechselt.

Ich habe jetzt auf Stateful gewechselt und lass meinen Router Adressen verteilen und mit einem recht moderaten lease auslaufen. Da habe ich bislang erstmal nix mehr gespürt, außer eben auch ab und zu paar Hänger von Seiten, wenn ich im Bett liege, aber da habe ich nur schlechten WLAN-Empfang

Folgendes: Bis ich DAS herausgefunden habe, habe ich aber auch massiv getuned:
- Ich nutze jetzt nextdns // also einen DNS-Drittanbieter - der auch DoT (DNS over TCP) unterstützt.
- Erweiterte WIFI-Settings nutzen jetzt noch nicht so die fancy neuen Features (mimo und co.), weil das auch eher zu störungen geführt hatte

Ich habe mir auch ein "schönes" ICMP-Monitoring aufgesetzt, wo ein Script permanent die öffentlichen IPs meines Routers an einen dyn-DNS meldet und das Tool glücklicherweise Dual-Stack kann und somit Interessante Interpretationen möglich waren. Hier dürft ihr gucken:
https://www.thinkbroadband.com/broadban ... ba66200bb8
Aktuell sieht es eigentlich sehr gut aus. Wer mein Posting heute liest, sieht gg.f noch einen Reboot meines Routers .
Aber folgendes:
Es war laaange Zeit immr so, dass die gelben zacken viel höher waren und teilweise auch massiv "verzackt". Auch sind sehr oft am oberen Rand rote kleine "stalaktiten" zu sehen. Ich interpretiere das so: die Gelben Zacken deuten an, dass das Routing zum Gerät teilweise richtig mies und verschmutzt ist, Vielleicht keine Pingverluste (wäre sonst rot), aber echt unnötig hohe Latenzen. DIe roten Zacken interpretiere ich aktuell als Indiz dafür, dass eventuell auch die öffentliche ipv6-adresse vom Router wechselt, der macht ja vermutlich wirklich nur stateless Adressvergabe, weil ihm ja kein anderes Device was anderes "sagt". Ich werde mir wohl mal was basteln, wo ich diese Adresse mal logge zum Auswerten.

Also mein bisheriger Stand ist also, dass wohl irgendwie die Adressvergabe noch nicht so richtig funktioniert, ob das nun am Provider liegt, an den Endgeräten oder am Protokoll selbst... Da bin ich noch überfragt.
Vielleicht hilt's euch ja weiter beim grübeln.

Grüße

[Flole]

Wechselnde Adressen klingt sehr nach Privacy extensions.... Da baut der Webseitenbetreiber Mist wenn er versucht ein v6 Gerät an einer Adresse zu identifizieren, das kann nicht funktionieren.

[hobbes444]

Hab das selbe Problem. Google DNS IPv6 kann ich immer pingen, CloudFlare funktioniert nur 50% der Zeit, sipgate funktioniert nie...

Code: Alles auswählen

[9:01]:ping6 one.one.one.one | while read line; do echo `date` - $line; done
Tue Aug 18 09:01:06 CEST 2020 - PING6(56=40+8+8 bytes) 2a02:8109:a1c0:5495:64ed:4a9b:1066:7d73 --> 2606:4700:4700::1001
Tue Aug 18 09:01:06 CEST 2020 - 16 bytes from 2606:4700:4700::1001, icmp_seq=0 hlim=55 time=21.108 ms
Tue Aug 18 09:01:11 CEST 2020 - 16 bytes from 2606:4700:4700::1001, icmp_seq=5 hlim=55 time=20.815 ms
Tue Aug 18 09:01:12 CEST 2020 - 16 bytes from 2606:4700:4700::1001, icmp_seq=6 hlim=55 time=18.556 ms
Tue Aug 18 09:01:18 CEST 2020 - 16 bytes from 2606:4700:4700::1001, icmp_seq=12 hlim=55 time=21.506 ms
Tue Aug 18 09:01:19 CEST 2020 - 16 bytes from 2606:4700:4700::1001, icmp_seq=13 hlim=55 time=21.896 ms
Tue Aug 18 09:01:20 CEST 2020 - 16 bytes from 2606:4700:4700::1001, icmp_seq=14 hlim=55 time=20.584 ms
Tue Aug 18 09:01:21 CEST 2020 - 16 bytes from 2606:4700:4700::1001, icmp_seq=15 hlim=55 time=18.689 ms
Tue Aug 18 09:01:24 CEST 2020 - 16 bytes from 2606:4700:4700::1001, icmp_seq=18 hlim=55 time=20.693 ms
Tue Aug 18 09:01:26 CEST 2020 - 16 bytes from 2606:4700:4700::1001, icmp_seq=20 hlim=55 time=20.007 ms
^CTue Aug 18 09:01:26 CEST 2020 -
Tue Aug 18 09:01:26 CEST 2020 - --- one.one.one.one ping6 statistics ---
Tue Aug 18 09:01:26 CEST 2020 - 21 packets transmitted, 9 packets received, 57.1% packet loss
Tue Aug 18 09:01:26 CEST 2020 - round-trip min/avg/max/std-dev = 18.556/20.428/21.896/1.092 ms

[robert_s]

Hab das selbe Problem. Google DNS IPv6 kann ich immer pingen, CloudFlare funktioniert nur 50% der Zeit, sipgate funktioniert nie...

Code: Alles auswählen

[9:01]:ping6 one.one.one.one | while read line; do echo `date` - $line; done

Probier doch stattdessen mal:

Code: Alles auswählen

mtr -6 -z one.one.one.one

Lass das eine Weile laufen, halte es dann mit der Taste 'P' an und Copy&Paste das mal in einen Beitrag. Daran kann man vielleicht erkennen, ab welchem Hop die Verluste auftreten, und in welchem AS der liegt.

[hobbes444]

Code: Alles auswählen

myComputer (2a02:8109:a1c0:5495:bce2:1b62:xxxx:xxxx)                                     2020-08-18T21:38:27+0200
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                              Packets               Pings
 Host                                                                       Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. (waiting for reply)
 2. AS3209   2a02:8109:8001:43::1                                           17.9%   123   11.0  16.2  10.2 101.8  13.2
 3. AS3209   2a02:8100:6:2::103:221                                         17.9%   123   25.1  19.4   9.6  93.3  14.9
 4. AS3209   2a02:8100:6:2::103:231                                         17.9%   123   58.1  16.9   9.2  72.1  10.4
 5. AS3209   2a02:8100:6:2::6:b8a                                           91.7%   122   13.1  14.7  12.8  24.2   3.4
 6. AS3209   2a00::5fff:1000:c02:c01:1                                      69.7%   122   16.1  23.2  11.8  93.2  23.0
 7. (waiting for reply)
 8. (waiting for reply)
 9. AS13335  one.one.one.one                                                74.6%   122   27.7  22.4  18.5  28.8   2.9

[robert_s]

Code: Alles auswählen

myComputer (2a02:8109:a1c0:5495:bce2:1b62:xxxx:xxxx)                                     2020-08-18T21:38:27+0200
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                              Packets               Pings
 Host                                                                       Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. (waiting for reply)
 2. AS3209   2a02:8109:8001:43::1                                           17.9%   123   11.0  16.2  10.2 101.8  13.2
 3. AS3209   2a02:8100:6:2::103:221                                         17.9%   123   25.1  19.4   9.6  93.3  14.9
 4. AS3209   2a02:8100:6:2::103:231                                         17.9%   123   58.1  16.9   9.2  72.1  10.4
 5. AS3209   2a02:8100:6:2::6:b8a                                           91.7%   122   13.1  14.7  12.8  24.2   3.4
 6. AS3209   2a00::5fff:1000:c02:c01:1                                      69.7%   122   16.1  23.2  11.8  93.2  23.0
 7. (waiting for reply)
 8. (waiting for reply)
 9. AS13335  one.one.one.one                                                74.6%   122   27.7  22.4  18.5  28.8   2.9

Das sieht ja übel aus. Könntest Du zum Vergleich noch "mtr -4 -z one.one.one.one" machen, damit man sieht, was durch IPv6 kommt und was durch möglicherweise andere Störungen?