Hmmm… also die Ziele die du hier auflistest kann ich problemlos aufrufen, zumindest über mein Browser, kann also das Problem nicht nachstellen.

Aber dein Problem klingt ähnlich/passend zu dem Thread:

Zumindest ein paar der angegebene Ziele lösen IPv6 Adressen auf, die laut ipinfo.io bei Cloudflare sind.

@almightyloaf Dein Browser hat Methoden das zu umgehen, selbst wenn das auftritt. Das sind einmal der Rückfall auf IPv4 und aber auch einfach neu probieren eines Verbindungsaufbaus. Daher ist der Browser weniger ein Problem. Es fällt eher auf mit git, oder aber Einzelverbindungen mittels curl wie oben gezeigt. eine hohe Prozentanzahl nicht durch geht.

Das wirkt jetzt eventuell nicht tragisch, aber wenn du damit arbeiten musst und bei deiner Abfrage über den Versionsstand das hier sieht:

Summary
 ✓ Up-to-date: 18
 x Failure: 39
 ! Out-of-date: 9

Wobei die Failures eben besagte Verbindungsprobleme sind, dann ist damit nicht zu arbeiten.

Das ist durchaus richtig.

Egal ob man damit arbeiten muss, will oder auch nicht, IPv6 sollte funktionieren, ich bin da bei dir.

Hast du dir den anderen Thread angesehen, ist es das gleiche Problem? Dann würde ich empfehlen dich dort (auch) zu melden, damit sich o2 das ansehen kann.

Oder sehe ich etwas falsch und die zwei Themen sind andere Welten?

@almightyloaf Bin am lesen. Danke für den Link :)

Hast du mal geschaut, ob du wirklich IPv6 von o2 bekommst?

Und nicht versehentlich über 6to4?

Bin vermutlich von dem gleichen Problem geplagt.  Bezüglich “Browser hat Methoden das zu umgehen”: in diesem speziellen Fall greifen die üblichen Browser-internen Fallbackmethoden nicht.

Die IPv6 Verbindung scheitert nämlich erst relativ spät, an einem von der Gegenseite zurückgesendeten RST paket (siehe z.B. curl-Fehlermeldung curl: (56) Recv failure: Connection reset by peer).

Das ist nicht die Art von Fehler, wo der Browser einfach einen Fallback auf IPv4 macht, oder das ganze neu versucht. Die TCP Verbindung kommt initial ja zustande, und wird erst, nachdem bereits ein paar Bytes Daten ausgetauscht wurden, von der Gegenseite wieder geschlossen (in diesem Thread gibt’s ein paar detailliertere Analysen zu wahrscheinlich dem gleichen Problem). Das RST Paket hat auch als Absenderadresse die IP-Adresse des Servers. Aus Browser-Sicht ist das kein Verbindungsproblem, sondern ein expliziter Wunsch des Webservers, der sagt “ich kann nicht, lass mich in Ruhe”, da macht der Browser dann keinen zweiten Versuch.

Gut möglich, dass das RST Paket von einer  Middlebox im O2 oder cloudflare-Netz kommt, und gar nicht vom Webserver selbst gesendet wurde (d.h. die Midddlebox hat da eine fremde Source-IP benutzt und den Webserver impersoniert).  Das kann der Browser aber nicht wissen.  Falls das von einer Middlebox kommt, dann heißt sowas offenbar "forged TCP reset".  Üblicherweise von “network security systems” eingesetzt um z.B. automatisch DoS Angriffe abzuwehren.

Ich habe mal je URL (mirror.osbeck.com, gnome.org, gitlab.org) 10 Anfragen über cURL gesendet, dürfte bei 50% Fehlerquote ausreichend viele versuche sein.

Jedoch ist das Problem “hier” nicht nachstellbar, es wird sich bei allen Versuchen erfolgreich verbunden, über IPv6. “Hier” ist nördlicheres BaWü.

Muss also regional sein. Zufällig in der “nähe” Berlins? Das war ja beim anderen Thread eher auch die Richtung.

Südliches Sachsen-Anhalt. Also nicht direkt Nähe, aber eventuell nahe genug. Danke fürs rein schauen!

Suedliches Niedersachsen, meist keine Probleme. Wenn Probleme dann wegen Problemen mit der IPv6 Praefix-Delgation von O2 die seit einigen Monaten immer mal wieder aufmuckt… aber das betrifft dann die gesamte IPv6 Konnektivitaet und hat nichts mit unerwarteten RSTs zu tun.

Liebe Gemeinde,

vielen Dank für den Beitrag. Ich habe das gleiche Problem und war mir nicht sicher, ob es an meiner Installation oder an meinem Provider liegt.

Ich habe einige Tests gemacht:
- Ich habe versucht, meinen Mobilfunkanbieter zu verwenden und habe keine Probleme beim Zugriff auf Websites.
- Ich habe IPv6 an meinem Router deaktiviert und das Problem ist verschwunden.

Es handelt sich also eindeutig um ein Problem mit dem IPv6-Protokoll von O2.

LG
Rust
 

Wenn es sich auch um Webseiten die über Anycast erreicht werden, und das Problem eben auch genau das ist, was hier besprochen wird (ich denke erstmal ja, wobei es ja dann drauf an kommt welche Seiten gemeint sind, du hast “nur” “einige Tests” ohne näheren Angaben gemacht) würde ich dir empfehlen dich auch beim unten genannten Thread mit anzuschliessen um den Impact sichtbarer zu machen.

Wobei der Anbieter an der Stelle auch nicht unbedingt “Schuld” sein muss, wie es dort auch beschrieben ist (und natürlich sofern die Aussage stimmt).

Guten Morgen @almightyloaf, @amureki & @fabiscafe,

ich bin in der Thematik wirklich nicht gut. Ihr unterstützt & helft euch sehr gut gegenseitig 

Gibt es da schon Neuigkeiten bei euch?

Liebe Grüße

Kathi