IPv6 zu Cloudflare kaputt
vor 7 Jahren
Hallo zusammen!
Seit Monaten fällt mir auf, dass regelmäßig Verbindungen wenigstens zu Cloudflare basierten IPv6-Adressen (z.B. 2606:4700:20::681a:7cb, 2606:4700:20::681a:6cb (https://www.ip-phone-forum.de), 2606:4700::6813:c397, 2606:4700::6813:c597 (n-tv Sport 1. Bundesliga Live Ticker), 2606:4700:30::6812:3dfa (https://www.phoronix.com)) Probleme machen. Tiefere Analyse gestern und heute hat obiges ergeben. Selbst heute morgen(!) sind vereinzelte SYN retries zu beobachten. V.a. am Samstag Mittag z.B., wenn die BL aktiv kickt, ist der Zugriff teilweise gar nicht mehr möglich auf den n-tv-Liveticker. Der SYN timed nach x vergblichen Versuchen aus.
Dies gilt auch regelmäßig zur Internet prime time abends.
Via IPv4 sind alle genannten Ziele zur jeweils gleichen Zeit problemlos erreichbar (oder auch über einen freien Proxy z.B.).
Als Workaround habe ich nun im Squid bei mir die Option dns_v4_first = on aktiviert, damit IPv6 nur noch dann verwendet wird, wenn das Ziel nicht anders zu erreichen ist. Damit ist IPv6 de facto weitgehend deaktiviert.
Des weiteren ist mir bei dieser Gelegenheit aufgefallen, dass die IPv6-Verbindungen zu den genannten Zielen bei cloudflare z.B., selbst wenn sie funktionieren, eine stark reduzierte MSS von 1360 bzw. auch 1220 Bytes verwenden. Hier sollten 1432 Bytes zum Einsatz kommen (20 Bytes weniger als IPv4 wg. größerem IP-Header)! Vielleicht nicht so viele Tunnels verwenden?
Zu heise (2a02:2e0:3fe:1001:7777:772e:2:85) oder golem (2a00:13c8:f5::f:4b3d:175) funktioniert es ja auch, wie es soll!
Bitte den IPv6-Verkehr reparieren!
Hinweis:
Hinweis:
653
0
0
Das könnte Ihnen auch weiterhelfen
740
2
7
1014
2
10
1584
2
2
vor 4 Jahren
2086
2
3
vor 2 Jahren
980
0
5
Beliebte Tags letzte 7 Tage
Das könnte Sie auch interessieren
Kaufberatung anfragen
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Angebote anzeigen
Informieren Sie sich über unsere aktuellen Internet-Angebote.
vor 7 Jahren
Hallo @user347 ,
- Des weiteren ist mir bei dieser Gelegenheit aufgefallen, dass die IPv6-Verbindungen zu den genannten Zielen bei cloudflare z.B., selbst wenn sie funktionieren, eine stark reduzierte MSS von 1360 bzw. auch 1220 Bytes verwenden. Hier sollten 1432 Bytes zum Einsatz kommen (20 Bytes weniger als IPv4 wg. größerem IP-Header)! Vielleicht nicht so viele Tunnels verwenden?
Das solltest du dem Betreiber des Server mitteilen. Wie man unschwer sieht möchte der Server nur eine MSS von 1360.
0
0
von
vor 7 Jahren
Hallo @user347 , - Des weiteren ist mir bei dieser Gelegenheit aufgefallen, dass die IPv6-Verbindungen zu den genannten Zielen bei cloudflare z.B., selbst wenn sie funktionieren, eine stark reduzierte MSS von 1360 bzw. auch 1220 Bytes verwenden. Hier sollten 1432 Bytes zum Einsatz kommen (20 Bytes weniger als IPv4 wg. größerem IP-Header)! Vielleicht nicht so viele Tunnels verwenden? Das solltest du dem Betreiber des Server mitteilen. Wie man unschwer sieht möchte der Server nur eine MSS von 1360.
Hallo @user347 ,
- Des weiteren ist mir bei dieser Gelegenheit aufgefallen, dass die IPv6-Verbindungen zu den genannten Zielen bei cloudflare z.B., selbst wenn sie funktionieren, eine stark reduzierte MSS von 1360 bzw. auch 1220 Bytes verwenden. Hier sollten 1432 Bytes zum Einsatz kommen (20 Bytes weniger als IPv4 wg. größerem IP-Header)! Vielleicht nicht so viele Tunnels verwenden?
Das solltest du dem Betreiber des Server mitteilen. Wie man unschwer sieht möchte der Server nur eine MSS von 1360.
Das könnte natürlich sein - glaube ich aber nicht, da es mit IPv4 ja auch passt. Jedes aktive Device auf dem Weg kann diesen Wert anpassen, wie es lustig ist. Siehe hier als Beispiel. Für mich riecht das nach tunnel.
0
Uneingeloggter Nutzer
vor 7 Jahren
@user347
Bis wohin ist der Traceroute in Ordnung?
0
0
von
vor 7 Jahren
@user347 Bis wohin ist der Traceroute in Ordnung?
@user347
Bis wohin ist der Traceroute in Ordnung?
Das bringt leider nicht viel. Ich weiß ja nicht, ob meine Pakete bis zu einem gewissen System überhaupt kommen oder ob die Rückantwort den Bach runtergeht. Wie auch immer, alle genannten Destinations gehen zumindest aktuell über
4 2003:0:1304:800d::2 (2003:0:1304:800d::2) 19.813 ms 19.845 ms 19.846 ms
5 lo0.franco71.fra.seabone.net (2001:41a8:600::47) 10.900 ms 10.912 ms 10.987 ms
6 2001:41a8:600:2::19e (2001:41a8:600:2::19e) 11.492 ms 10.804 ms 11.008 ms
ins jeweilige Ziel. Der vierte Hop ist auch derjenige, der mit Abstand am meisten Zeit verbrät (auch 40 ms habe ich da gesehen gerade) - und der gehört der Telekom. (tracereoute6 via icmpv6 oder udp). Alle anderen liegen bei 10-11 ms.
0
vor 7 Jahren
0
0
vor 7 Jahren
Golem?
Die haben doch gar kein ipv6. Ich bin verwirrt.
0
0
von
vor 7 Jahren
Golem? Die haben doch gar kein ipv6. Ich bin verwirrt.
Golem?
Die haben doch gar kein ipv6. Ich bin verwirrt.
Ein Teil der Hauptseite schon - einfach mal aufrufen und einen Trace mitlaufen lassen. Ist im TLS Key-Austausch eindeutig zu erkennen. Ich darf nochmal dran erinnern, dass ich Golem als Postivbeispiel genannt habe, wo es funktioniert, wie es soll.
von
vor 7 Jahren
Hey
am besten meldest du dich hier nochmal dazu:
Peering /m-p/4164558#M1145755" target="_blank">https://telekomhilft.telekom.de/t5/Telefonie-Internet/IPv6-Cloudflare-Packet-Loss-Telecom-Italia-Seabone- Peering /m-p/4164558#M1145755
Gebündelt haben wir sicherlich mehr Chance auf Aufmerksamkeit.
0