Skip to main content
Warum O2
Warenkorb
 Service
Frage

IPv6 Routing probleme zu Microsoft Azure

  • July 31, 2026
  • 6 Antworten
  • 173 Aufrufe
Legende
Forum|alt.badge.img+10

Hallo Zusammen,

Es ist ja schon länger her, dass es mal wieder ein kniffliges Thema gab.

seit inzwischen rund 2 Jahre bin ich ja über das Netz von Telefonica online, bis auf ein paar Details (die z.T. in der Adressierung sind) recht zufrieden (das gute Peering ist nach >10 Jahre AS3320 ein Segen!).

Aber ich habe leider auch Punkte zu bemängeln, diesmal IPv6.

Zugegeben, die Fehlerbeschreibung ist schwer über den normalen Support zu vermitteln, jedoch hatte ich es heute versucht. Nach etwas mehr als eine Stunde (mit kurzen Wartezeiten, das ist löblich, kenne ich von anderen Anbietern anders), musste ich unverrichteter Dinge auflegen, es ist wohl nicht möglich einen Ticket aufzunehmen und in einem Textfeld das Fehlerbild zu notieren, so dass die eigentliche Technik dahinter verstehen kann wo der Schuh drückt.

Über den Kontaktformular lässt sich die Störung auch nicht melden, nur “andere Anliegen”.

Der Fehler lässt sich wie folgt beschreiben:

Einige Dienste die über die Microsoft Infrastruktur (ich nehme hier einfach mal Azure an) bereitgestellt werden, lassen sich über IPv6 nicht verwenden. Simple Beispiele wären Webseiten wie z.B. www.michelin.de, www.amundietf.de, die Login-Seite der Bausparkasse Schwäbisch-Hall (login.schwaebisch-hall.de), oder auch z.B. den Updater von Microsoft VisualStudio Code, oder den Microsoft Store in Windows, der keine Updates laden kann.

Das lässt sich in verschiedenen Varianten umgehen. Man kann z.B. über den Handy auf diese Dienste (auch über IPv6!) zugreifen, ebenso funktionieren diese bei einem o2 Kabelanschluss im Bekanntenkreis einwandfrei. Das problem war bisher lediglich an meinem Anschluss, seit mindestens 1 Jahr (vermutlich seit Vertragsbeginn) feststellbar.

Zuerst wollte ich tiefer analysieren mithilfe von TCPDump was genau passiert, aber langsam ist die Einschränkung etwas unangenehm (weil ich immer wieder IPv6 deaktivieren muss um die oben genannte Sachen zu verwenden) deshalb skippe ich einfach mal diesen Schritt und eröffne dieses Thema hier.

Natürlich wäre es zu einfach, wenn mein o2 Community Konto mit dem betroffenen o2 Kunden Konto verknüpft wäre, aber mein böser Zwilling ​@almightyloaf2 war so fleissig und hat sich für solche Sachen einen (hoffentlich temporären, ich hab ja die Hoffnung dass es irgendwann wirklich sauber läuft) Konto erstellt. Falls unbedingt nötig kann er auch hier nochmal ein kurzes “Hello” von sich geben :)

Da sicherlich mehr Kunden betroffen sind (letztendlich kriege ich ja jede Nacht einen neuen IPv6 präfix, andere o2 Kunden kriegen “meinen alten” irgendwann ja auch), hoffe ich aber auch dass ein Moderator (selbstverständlich wenn er dazu kommt und Zeit für hat) mal intern nachfragen kann, ob die Routen hier mal überprüft werden könnten. Es gab ja auch mal in der Vergangenheit, allerdings nicht auf Microsoft Azure bezogen, würde meiner Ansicht nach aber zum Fehlerbild recht gut passen.

Der Unterschied ist allerdings, es scheitern nicht 30% oder 50% der Verbindungsversuche, sondern immer 100% (wobei irgendwann habe ich auch aufgegeben, ich werde die Seiten nicht 200x aufrufen :D )

Wenn jemanden Ahnung hat und mit diesem Output was anfangen kann (oder bessere Tipps hat, teste ich gerne), hier mal als Beispiel mit der Webseite www.michelin.de (oder falls ein Moderator das mal intern weiterleiten möchte ;) )

Mit Curl sieht es so aus (der connection reset am Ende kommt nach einer halben Ewigkeit) 

curl -v -s https://www.michelin.de/ -o /dev/null
* Host www.michelin.de:443 was resolved.
* IPv6: 2603:1061:14:133::1
* IPv4: 150.171.110.56
*   Trying [2603:1061:14:133::1]:443...
* Connected to www.michelin.de (2603:1061:14:133::1) port 443
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [88 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* Recv failure: Connection reset by peer
* OpenSSL SSL_connect: Connection reset by peer in connection to www.michelin.de:443
* Closing connection

TCPdump liefert folgendes:

sudo tcpdump ip6
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
20:38:32.777380 IP6 dynamic-2a02-3100-IPv6-ac2e.310.pool.telefonica.de.46058 > 2603:1061:14:135::1.https: Flags [S], seq 2922770860, win 64800, options [mss 1440,sackOK,TS val 496973713 ecr 0,nop,wscale 7], length 0
20:38:32.789075 IP6 2603:1061:14:135::1.https > dynamic-2a02-3100-IPv6-ac2e.310.pool.telefonica.de.46058: Flags [S.], seq 3029751708, ack 2922770861, win 65535, options [mss 1400,sackOK,TS val 3398689301 ecr 496973713,nop,wscale 9], length 0
20:38:32.789143 IP6 dynamic-2a02-3100-IPv6-ac2e.310.pool.telefonica.de.46058 > 2603:1061:14:135::1.https: Flags [.], ack 1, win 507, options [nop,nop,TS val 496973724 ecr 3398689301], length 0
20:38:32.800001 IP6 dynamic-2a02-3100-IPv6-ac2e.310.pool.telefonica.de.46058 > 2603:1061:14:135::1.https: Flags [P.], seq 1:518, ack 1, win 507, options [nop,nop,TS val 496973735 ecr 3398689301], length 517
20:38:32.811879 IP6 2603:1061:14:135::1.https > dynamic-2a02-3100-IPv6-ac2e.310.pool.telefonica.de.46058: Flags [.], ack 518, win 131, options [nop,nop,TS val 3398689324 ecr 496973735], length 0
20:38:32.812102 IP6 2603:1061:14:135::1.https > dynamic-2a02-3100-IPv6-ac2e.310.pool.telefonica.de.46058: Flags [P.], seq 1:100, ack 518, win 131, options [nop,nop,TS val 3398689324 ecr 496973735], length 99
20:38:32.812123 IP6 dynamic-2a02-3100-IPv6-ac2e.310.pool.telefonica.de.46058 > 2603:1061:14:135::1.https: Flags [.], ack 100, win 507, options [nop,nop,TS val 496973747 ecr 3398689324], length 0
20:38:32.909126 IP6 dynamic-2a02-3100-IPv6-ac2e.310.pool.telefonica.de.46058 > 2603:1061:14:135::1.https: Flags [P.], seq 518:1041, ack 100, win 507, options [nop,nop,TS val 496973844 ecr 3398689324], length 523
20:38:32.921405 IP6 2603:1061:14:135::1.https > dynamic-2a02-3100-IPv6-ac2e.310.pool.telefonica.de.46058: Flags [P.], seq 2956:4196, ack 1041, win 133, options [nop,nop,TS val 3398689434 ecr 496973844], length 1240
20:38:32.921451 IP6 dynamic-2a02-3100-IPv6-ac2e.310.pool.telefonica.de.46058 > 2603:1061:14:135::1.https: Flags [.], ack 100, win 507, options [nop,nop,TS val 496973857 ecr 3398689324,nop,nop,sack 1 {2956:4196}], length 0
20:38:32.924481 IP6 2603:1061:14:135::1.https > dynamic-2a02-3100-IPv6-ac2e.310.pool.telefonica.de.46058: Flags [P.], seq 7052:7428, ack 1041, win 133, options [nop,nop,TS val 3398689437 ecr 496973844], length 376
20:38:32.924507 IP6 dynamic-2a02-3100-IPv6-ac2e.310.pool.telefonica.de.46058 > 2603:1061:14:135::1.https: Flags [.], ack 100, win 507, options [nop,nop,TS val 496973860 ecr 3398689324,nop,nop,sack 2 {7052:7428}{2956:4196}], length 0
^C
14 packets captured
14 packets received by filter
0 packets dropped by kernel

Meine IPv6 ist natürlich zensiert.

Hoffentlich lässt sich das geradebiegen (aber ich bin auch etwas erstaunt dass sowas solange nicht auffällt...)

Jedenfalls freue ich mich auf dem Input der Community und auf die vielen verschiedenen Tests die man so machen kann um das Problem besser zu verstehen

    6 Antworten

    o2_Giulia
    • o2_GiuliaModeratorin
    • Moderatorin
    • August 7, 2026

    Hallo ​@almightyloaf,

    bitte entschuldige die späte Rückmeldung!

    Ich kenne mich leider nicht so gut aus, und kann hier leider auch nur mutmaßen. Schade, dass dir unsere Mitarbeiter von der Störungshotline nicht weiterhelfen konnten. 

    Die Adresse wird ja offenbar richtig erkannt und ein klassisches Routing-Problem scheint es nicht zu sein, oder? Allerdings gehen hier wohl größere Pakete verloren oder werden verworfen oder es gibt hier Lücken, das sollte nicht so sein. 

    Toll wäre es, wenn du uns ein Traceroute erstellen könntest, das wir dann ggf. weiterleiten können. 

    Viele Grüße

    Giulia

    Hat ein Beitrag deine Frage beantwortet? Dann markiere ihn gerne als Lösung und hinterlasse ein Gefällt mir
      Legende
      Forum|alt.badge.img+10
      • almightyloafLegende
      • Autor
      • Legende
      • August 7, 2026

      Hi ​@o2_Giulia,

      kein Thema, ich weiss dass viel los ist und dass ihr primär zum Moderieren da seit :) (und das Problem habe ich ja seit (mutmasslich) 2 Jahre, also ein paar Wochen mehr oder weniger macht auch nicht viel)

      Ich kenne mich leider nicht so gut aus, und kann hier leider auch nur mutmaßen. Schade, dass dir unsere Mitarbeiter von der Störungshotline nicht weiterhelfen konnten.

      Auch das ist nicht wild, mir ist schon bewusst dass die Störungsart jetzt nicht besonders leicht zu vermitteln ist und nicht zu den üblichen zählt. Alles können muss man auch nicht, sonst kann man nichts richtig.

      Wobei ein Freitextfeld für solche komische Meldungen sicherlich nicht verkehrt wäre.

      Die Adresse wird ja offenbar richtig erkannt und ein klassisches Routing-Problem scheint es nicht zu sein, oder?

      Das wäre eher DNS, also Namensauflösung (z.B. www.michelin.de → 2603:1061:14:137::1). Routing wäre dann eben nachgelagert, also wenn mein Client (den PC) dann zu dieser IP(v6) Adresse bzw. den Server den diese Adresse hat kommunizieren möchte. Ich habe auch www.pitstop.de als weiteren Ziel entdeckt der auch betroffen ist (und auch bei Microsoft Azure gehosted zu sein scheint).

      Allerdings gehen hier wohl größere Pakete verloren oder werden verworfen oder es gibt hier Lücken, das sollte nicht so sein.

      Genau. Ob es jetzt nur Pakete einer bestimmten Grösse betrifft oder was genau passiert ist mir jetzt nicht klar, ich habe das auch nicht so genau getestet (wollte ich ursprünglich, aber diesen Schritt habe ich nun erstmal geskippt zugunsten einen rohen Output mit TCPdump und cURL, den ich im Eingangspost im Spoiler versteckt hatte zur Übersichtlichkeit).

      Das Thema mit den fragmentierten Pakete lässt sich leider nicht mehr so einfach testen, da wohl die Webseite die den Test ermöglichte nun offline ist, so muss ich zuerst eine neue Testmethode finden, bevor ich hier meckern kann :) (aber der Fachbereich darf trotzdem natürlich auch ohne mein “Meckern” im dazugehörigen Thema darüber schauen)

      Toll wäre es, wenn du uns ein Traceroute erstellen könntest, das wir dann ggf. weiterleiten können.

      Selbstverständlich, da hätte ich eigentlich auch selbst dran denken sollen, statt nur TCPdump und cURL. Macht auch Sinn. Das witzige ist ja, man sieht im TCPdump dass die Kommunikation zumindest beginnt, aber irgendwie dann nur beginnt und nicht endet und nicht (genügend) Daten transmittiert werden damit die genannten Webseiten (und weitere Dienste, OSI Schichtenmodell ist hier einen guten Punkt zu Verständnis falls das Thema dich interessiert). Ich vermute auch dass es bei dem Thema (daher hatte ich das auch als Test vorgeschlagen, auch wenn es nicht dazu kam und nun wohl über Teredo IPv6 verwendet wird so wie ich das interpretiere) die selbe Problematik gibt:

      Nun, lange Rede kurzer Sinn, anbei ein paar Traceroutes zu den Webseiten die betroffen sind (Microsoft Store Server IP und so könnte ich auch noch versuchen rauszufischen, aber ich denke das muss jetzt nicht unbedingt sein :D )

      www.michelin.de

      C:\Users\AnonUser>tracert www.michelin.de

      Détermination de l’itinéraire vers mr-a03.tm-azurefd.net [2603:1061:14:135::1]
      avec un maximum de 30 sauts :

        1    <1 ms    <1 ms    <1 ms  dynamic-2a02-3100-6547-c207-021e-c9ff-feb8-e7a9.310.pool.telefonica.de [2a02:3100:6547:c207:21e:c9ff:feb8:e7a9]
        2     7 ms     6 ms     6 ms  2a02:3001::23c
        3     *        *        *     Timeout.
        4     *        *        *     Timeout.
        5     8 ms    15 ms    28 ms  ae22-0.mil30-96cbe-1a.ntwk.msn.net [2a01:111:2000:2:8000::130e]
        6     *        *        *     Timeout.
        7     *        *        *     Timeout.
        8    13 ms    13 ms    14 ms  2a01:111:2000:6::54bd
        9    12 ms    12 ms    12 ms  2603:10a0:c02:2200::2e
       10    12 ms    12 ms    12 ms  2603:10a0:c02:2105::a6
       11    12 ms    12 ms    12 ms  2603:10a0:c0d:ba::
       12    12 ms    12 ms    12 ms  2603:10a0:c0d:ba::52
       13     *        *        *     Timeout.
       14     *        *        *     Timeout.
       15     *        *        *     Timeout.
       16     *        *        *     Timeout.
       17     *        *        *     Timeout.
       18     *        *        *     Timeout.
       19     *        *        *     Timeout.
       20     *        *        *     Timeout.
       21     *        *        *     Timeout.
       22     *        *        *     Timeout.
       23     *        *        *     Timeout.
       24     *        *        *     Timeout.
       25     *        *        *     Timeout.

      login.schwaebisch-hall.de 

      C:\Users\AnonUser>tracert login.schwaebisch-hall.de

      Détermination de l’itinéraire vers mr-a03.tm-azurefd.net [2603:1061:14:135::1]
      avec un maximum de 30 sauts :

        1    <1 ms    <1 ms    <1 ms  dynamic-2a02-3100-6547-c207-021e-c9ff-feb8-e7a9.310.pool.telefonica.de [2a02:3100:6547:c207:21e:c9ff:feb8:e7a9]
        2     6 ms     6 ms     6 ms  2a02:3001::23c
        3     *        *        *     Timeout.
        4     *        *        *     Timeout.
        5    10 ms    55 ms     7 ms  ae22-0.mil30-96cbe-1a.ntwk.msn.net [2a01:111:2000:2:8000::130e]
        6     *        *        *     Timeout.
        7     *        *        *     Timeout.
        8    14 ms    13 ms    14 ms  2a01:111:2000:6::54bd
        9    12 ms    12 ms    12 ms  2603:10a0:c02:2200::2e
       10    12 ms    12 ms    12 ms  2603:10a0:c02:2105::a6
       11    12 ms    16 ms    12 ms  2603:10a0:c0d:ba::
       12    12 ms    12 ms    12 ms  2603:10a0:c0d:ba::52
       13     *        *        *     Timeout.
       14     *        *        *     Timeout.
       15     *        *        *     Timeout.
       16     *        *        *     Timeout.
       17     *        *        *     Timeout.
       18     *        *        *     Timeout.
       19     *        *        *     Timeout.
       20     *        *        *     Timeout.
       21     *        *        *     Timeout.
       22     *        *        *     Timeout.
       23     *        *        *     Timeout.
       24     *        *        *     Timeout.
       25     *        *        *     Timeout.

      amundiprodcdn2.azureedge.net (liefert den Content der Webseite www.amundietf.de)

      C:\Users\AnonUser>tracert amundiprodcdn2.azureedge.net

      Détermination de l’itinéraire vers mr-afd-azuredge.tm-azurefd.net [2603:1061:14:133::1]
      avec un maximum de 30 sauts :

        1    <1 ms    <1 ms    <1 ms  dynamic-2a02-3100-6547-c207-021e-c9ff-feb8-e7a9.310.pool.telefonica.de [2a02:3100:6547:c207:21e:c9ff:feb8:e7a9]
        2     6 ms     7 ms     7 ms  2a02:3001::23c
        3     *        *        *     Timeout.
        4     *        *        *     Timeout.
        5     7 ms     7 ms     7 ms  ae22-0.mil30-96cbe-1a.ntwk.msn.net [2a01:111:2000:2:8000::130e]
        6    26 ms    26 ms    26 ms  ae123-0.icr02.ams21.ntwk.msn.net [2603:1060:1:12::f231]
        7    26 ms    26 ms    26 ms  2603:1060:1:10::f7e1
        8    26 ms    26 ms    27 ms  po12.yto20-0100-0001-01sw.ntwk.msn.net [2a01:111:201:f200::8da]
        9    27 ms    26 ms    26 ms  po8.dub08-0100-0002-01sw.ntwk.msn.net [2a01:111:201:f200::be]
       10    27 ms    26 ms    27 ms  2a01:111:201:f200::1d41
       11    26 ms    26 ms    26 ms  2a01:111:2000:6::4671
       12    25 ms    25 ms    25 ms  2a01:111:2000:2:8000::291d
       13    25 ms    25 ms    25 ms  2a01:111:223:1cf::6e
       14     *        *        *     Timeout.
       15     *        *        *     Timeout.
       16     *        *        *     Timeout.
       17     *        *        *     Timeout.
       18     *        *        *     Timeout.
       19     *        *        *     Timeout.
       20     *        *        *     Timeout.
       21     *        *        *     Timeout.
       22     *        *        *     Timeout.
       23     *        *        *     Timeout.
       24     *        *        *     Timeout.
       25     *        *        *     Timeout.

      www.pitstop.de

      C:\Users\AnonUser>tracert www.pitstop.de

      Détermination de l’itinéraire vers mr-a03.tm-azurefd.net [2603:1061:14:133::1]
      avec un maximum de 30 sauts :

        1    <1 ms    <1 ms    <1 ms  dynamic-2a02-3100-6547-c207-021e-c9ff-feb8-e7a9.310.pool.telefonica.de [2a02:3100:6547:c207:21e:c9ff:feb8:e7a9]
        2     7 ms     7 ms     9 ms  2a02:3001::23c
        3     *        *        *     Timeout.
        4     *        *        *     Timeout.
        5     6 ms     7 ms     7 ms  ae22-0.mil30-96cbe-1a.ntwk.msn.net [2a01:111:2000:2:8000::130e]
        6    26 ms    26 ms    26 ms  ae123-0.icr02.ams21.ntwk.msn.net [2603:1060:1:12::f231]
        7    26 ms    27 ms    27 ms  2603:1060:1:10::f7e1
        8    28 ms    26 ms    26 ms  po12.yto20-0100-0001-01sw.ntwk.msn.net [2a01:111:201:f200::8da]
        9    27 ms    26 ms    26 ms  po8.dub08-0100-0002-01sw.ntwk.msn.net [2a01:111:201:f200::be]
       10    26 ms    26 ms    26 ms  2a01:111:201:f200::1d41
       11    26 ms    26 ms    26 ms  2a01:111:2000:6::4671
       12    25 ms    25 ms    25 ms  2a01:111:2000:2:8000::291d
       13    25 ms    25 ms    25 ms  2a01:111:223:1cf::6e
       14     *        *        *     Timeout.
       15     *        *        *     Timeout.
       16     *        *        *     Timeout.
       17     *        *        *     Timeout.
       18     *        *        *     Timeout.
       19     *        *        *     Timeout.
       20     *        *        *     Timeout.
       21     *        *        *     Timeout.
       22     *        *        *     Timeout.
       23     *        *        *     Timeout.
       24     *        *        *     Timeout.
       25     *        *        *     Timeout.

      wcpstatic.microsoft.com (liefert den Content der Webseite learn.microsoft.com)

      C:\Users\AnonUser>tracert wcpstatic.microsoft.com

      Détermination de l’itinéraire vers mr-azurefd.tm-azurefd.net [2603:1061:14:174::1]
      avec un maximum de 30 sauts :

        1    <1 ms    <1 ms    <1 ms  dynamic-2a02-3100-6547-c207-021e-c9ff-feb8-e7a9.310.pool.telefonica.de [2a02:3100:6547:c207:21e:c9ff:feb8:e7a9]
        2     6 ms     7 ms     6 ms  2a02:3001::23c
        3     *        *        *     Timeout.
        4     *        *        *     Timeout.
        5    11 ms    14 ms    10 ms  ae22-0.mil30-96cbe-1a.ntwk.msn.net [2a01:111:2000:2:8000::130e]
        6    15 ms    15 ms    15 ms  ae101-0.icr01.ams30.ntwk.msn.net [2603:1060:1:12::f235]
        7    15 ms     *       15 ms  2603:1060:1:10::f669
        8    15 ms    16 ms    16 ms  2603:1060:1:10::f815
        9    97 ms    15 ms    15 ms  be1.ibr02.par30.ntwk.msn.net [2603:1060:1:10::f00e]
       10    16 ms    19 ms    14 ms  ae120-0.icr01.par30.ntwk.msn.net [2603:1060:1:12::f029]
       11    14 ms    14 ms    14 ms  2603:10a0:700:8100::6
       12    15 ms    14 ms    14 ms  2603:10a0:700:8000::216
       13    14 ms    14 ms    14 ms  2603:10a0:700:8203::1b2
       14    14 ms    15 ms    14 ms  2603:10a0:715:472::
       15    14 ms    14 ms    14 ms  2603:10a0:715:472::2a
       16     *        *        *     Timeout.
       17     *        *        *     Timeout.
       18     *        *        *     Timeout.
       19     *        *        *     Timeout.
       20     *        *        *     Timeout.
       21     *        *        *     Timeout.
       22     *        *        *     Timeout.
       23     *        *        *     Timeout.
       24     *        *        *     Timeout.
       25     *        *        *     Timeout.

       

      Man erkennt auch gut, alle 5 getesteten Ziele haben in deren DNS Namen (und deren IPv6 Adresse) einen Bezug zu Microsoft Azure.

      Ah ja, was ich auch getestet habe, ist diese Ziele über Mobilfunk (mit aktivem und funktionalem IPv6, sonst wäre das ja Quatsch) und über einen o2 Cable Anschluss im Bekanntenkreis (natürlich auch mit aktivem und funktionalem IPv6) zu testen, dort funktionierte es problemlos, also eben wie es halt sein sollte.

      Legende
      Forum|alt.badge.img+10
      • almightyloafLegende
      • Autor
      • Legende
      • August 8, 2026

      Zufällig fiel auch ein weiterer Ziel auf, der diesmal keinen (für mich erkennbaren) Bezug auf Microsoft Azure hat.

      www.kfz-werkstatt-ernst.de

      C:\Users\AnonUser>tracert www.kfz-werkstatt-ernst.de

      Détermination de l’itinéraire vers www.kfz-werkstatt-ernst.de [2a02:2350:5:10a:807b:fed1:eb40:6aba]
      avec un maximum de 30 sauts :

        1    <1 ms    <1 ms    <1 ms  dynamic-2a02-3100-5dc8-5907-021e-c9ff-feb8-e7a9.310.pool.telefonica.de [2a02:3100:5dc8:5907:21e:c9ff:feb8:e7a9]
        2     6 ms     6 ms     6 ms  2a02:3001::23c
        3     7 ms     *        *     80.81.193.89xp.decix.fra.de.net.telefonica.de [2001:7f8::1a95:0:2]
        4     7 ms     6 ms     6 ms  decix.cr1-fra1.net.one.com [2001:7f8::c90c:0:1]
        5     *        *        *     Timeout.
        6    19 ms    19 ms    19 ms  lo0-1.cr2-cph3.pub.network.one.com [2a02:2350:1::16]
        7    19 ms    19 ms    19 ms  et-0-0-48-200.dr6-cph3.pub.network.g1i.one [2a02:2350:4:72::1]
        8    19 ms    19 ms    19 ms  xe-1-0-47-200.ar1-webpod12-cph3.pub.network.g1i.one [2a02:2350:4:56::1]
        9    19 ms    19 ms    19 ms  2a02:2350:5:10a:807b:fed1:eb40:6aba

      cURL

      curl -v -s https://www.kfz-werkstatt-ernst.de/ -o /dev/null
      * Host www.kfz-werkstatt-ernst.de:443 was resolved.
      * IPv6: 2a02:2350:5:10a:807b:fed1:eb40:6aba
      * IPv4: 46.30.213.47
      *   Trying [2a02:2350:5:10a:807b:fed1:eb40:6aba]:443...
      * Connected to www.kfz-werkstatt-ernst.de (2a02:2350:5:10a:807b:fed1:eb40:6aba) port 443
      * ALPN: curl offers h2,http/1.1
      } [5 bytes data]
      * TLSv1.3 (OUT), TLS handshake, Client hello (1):
      } [512 bytes data]
      *  CAfile: /etc/ssl/certs/ca-certificates.crt
      *  CApath: /etc/ssl/certs
      * Recv failure: Connection reset by peer
      * OpenSSL SSL_connect: Connection reset by peer in connection to www.kfz-werkstatt-ernst.de:443
      * Closing connection

      TCPdump

      sudo tcpdump ip6
      tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
      listening on enp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
      20:46:14.407899 IP6 dynamic-2a02-3100-IPv6-53b3.310.pool.telefonica.de.59876 > 2a02:2350:5:10a:807b:fed1:eb40:6aba.https: Flags [S], seq 3825016501, win 64800, options [mss 1440,sackOK,TS val 2388477852 ecr 0,nop,wscale 7], length 0
      20:46:14.426767 IP6 2a02:2350:5:10a:807b:fed1:eb40:6aba.https > dynamic-2a02-3100-IPv6-53b3.310.pool.telefonica.de.59876: Flags [S.], seq 2916494635, ack 3825016502, win 64260, options [mss 1440,sackOK,TS val 188601682 ecr 2388477852,nop,wscale 7], length 0
      20:46:14.426793 IP6 dynamic-2a02-3100-IPv6-53b3.310.pool.telefonica.de.59876 > 2a02:2350:5:10a:807b:fed1:eb40:6aba.https: Flags [.], ack 1, win 507, options [nop,nop,TS val 2388477871 ecr 188601682], length 0
      20:46:14.432792 IP6 dynamic-2a02-3100-IPv6-53b3.310.pool.telefonica.de.59876 > 2a02:2350:5:10a:807b:fed1:eb40:6aba.https: Flags [P.], seq 1:518, ack 1, win 507, options [nop,nop,TS val 2388477877 ecr 188601682], length 517
      20:46:14.451734 IP6 2a02:2350:5:10a:807b:fed1:eb40:6aba.https > dynamic-2a02-3100-IPv6-53b3.310.pool.telefonica.de.59876: Flags [.], ack 518, win 501, options [nop,nop,TS val 188601706 ecr 2388477877], length 0
      20:46:14.454424 IP6 2a02:2350:5:10a:807b:fed1:eb40:6aba.https > dynamic-2a02-3100-IPv6-53b3.310.pool.telefonica.de.59876: Flags [P.], seq 2857:4097, ack 518, win 501, options [nop,nop,TS val 188601709 ecr 2388477877], length 1240
      20:46:14.454433 IP6 dynamic-2a02-3100-IPv6-53b3.310.pool.telefonica.de.59876 > 2a02:2350:5:10a:807b:fed1:eb40:6aba.https: Flags [.], ack 1, win 530, options [nop,nop,TS val 2388477899 ecr 188601706,nop,nop,sack 1 {2857:4097}], length 0
      20:46:14.454653 IP6 2a02:2350:5:10a:807b:fed1:eb40:6aba.https > dynamic-2a02-3100-IPv6-53b3.310.pool.telefonica.de.59876: Flags [P.], seq 4097:5229, ack 518, win 501, options [nop,nop,TS val 188601709 ecr 2388477877], length 1132
      20:46:14.454658 IP6 dynamic-2a02-3100-IPv6-53b3.310.pool.telefonica.de.59876 > 2a02:2350:5:10a:807b:fed1:eb40:6aba.https: Flags [.], ack 1, win 549, options [nop,nop,TS val 2388477899 ecr 188601706,nop,nop,sack 1 {2857:5229}], length 0
      20:48:14.801971 IP6 dynamic-2a02-3100-IPv6-53b3.310.pool.telefonica.de.59876 > 2a02:2350:5:10a:807b:fed1:eb40:6aba.https: Flags [.], ack 2916494636, win 571, options [nop,nop,TS val 2388598247 ecr 188601706,nop,nop,sack 1 {2857:5230}], length 0
      20:48:14.820940 IP6 2a02:2350:5:10a:807b:fed1:eb40:6aba.https > dynamic-2a02-3100-IPv6-53b3.310.pool.telefonica.de.59876: Flags [R], seq 2916494636, win 0, length 0
      ^C
      ^C
      11 packets captured
      11 packets received by filter
      0 packets dropped by kernel

       

      Selbstverständlich gegengeprüft mit anderen Anschlüssen (beinhaltet auch Mobilfunk, mit funktionalem IPv6).

      Bei diesem Ziel kann man sehen, dass ICMP durchgeht, ein Echo Request wird (über IPv6) beantwortet (ICMP ist aber nur bedingt aussagekräftig).

      Da es wohl augenscheinlich doch ein wenig weiter geht als “nur” Microsoft Azure, habe ich die Befürchtung dass ich nun eventuell nicht alle Probleme dieser Art im Zusammenhang mit IPv6 erfasst habe. Aber eins nach dem anderen. Ggf. ist das problematische Netzelement sowohl für die Einschränkungen bei Azure als auch bei “one.com” (laut ipinfo.io) verantwortlich. Naja und wenn alles funktionieren würde wäre es ja auch langweilig ;) (wobei mir langweilig recht wäre...)

      o2_Matze
      • o2_MatzeModerator
      • Moderator
      • August 14, 2026

      ​@almightyloaf Kurzes Update: Wir haben deinen Beitrag weiter auf dem Plan, aktuell ist es aber sehr herausfordernd, für dieses doch sehr ungewöhnliche Fehlerbild an die entsprechenden Kollegen zu kommen (Ferienzeit etc), die ganz tief im Serverkellern nach falsch abgebogenen Datenpakten forschen können. Wir bleiben da weiter am Ball. 

      VG Matze 

      „Was Du mit guter Laune tust, fällt Dir nicht schwer.“- ungarische Weisheit
        5G_Tester
        Legende
        • 5G_TesterLegende
        • Legende
        • August 14, 2026

        entsprechenden Kollegen zu kommen (Ferienzeit etc), die ganz tief im Serverkellern

        ​@o2_Matze hoffentlich tut den Kollegen Sonne gut wenn sie sonst dauerhaft im Keller kein Tageslicht abbekommen. 😆

        Ich bin nur ein o2 Nutzer und kein Mitarbeiter. Meine Beiträge können zudem auch meine eigene Meinung enthalten und sind somit nicht objektiv gültig. Wenn dir meine Antwort geholfen hat, freue ich mich, wenn du sie als Lösung markierst.
        Legende
        Forum|alt.badge.img+10
        • almightyloafLegende
        • Autor
        • Legende
        • August 14, 2026

        Hi ​@o2_Matze,

        danke für das Update. Kein Ding, die paar wenigen Experten in diesem Bereich den ihr habt sollen sich ausruhen und erstmal ihr Urlaub geniessen. Ihr braucht sie schliesslich fit, ausgeruht und zufrieden (und ein paar mehr Hände und Köpfe täten sicherlich auch nicht schaden ;) ).

        Dazu wie gesagt, das Problem besteht im Prinzip (mutmasslich) seit Vertragsbeginn, also die paar Wochen mehr oder weniger machen nicht mehr viel aus. Hauptsache es ist mal eingetütet.

        Ich denke mir nur, gut dass es z.B. den MedUX programm gibt, damit auch solche Probleme nicht auffallen (oder auffallen und jahrelang nicht angegangen werden) ;) (Ich habe natürlich darauf geachtet, dass in der VLAN wo dieses Teil sich austobt IPv6 auch funktional bereitliegt)

         

        Allgemeine Nutzungsbedingungen der O₂ CommunityAccessibility statement
        © Telefónica Germany GmbH & Co. OHG Telefónica