• Der Fragesteller hat diesen Beitrag als gelöst markiert.
  • Geschlossen

IPv6: 6rd MTU

SkyBeam
Level 4
1 von 7

Ich hab' jetzt auch mal eine Frage die ich mit den IPv6 Experten hier diskutieren möchte.

 

Mein Setup:

  • Internet Box 2 (IPv6 deaktiviert)
  • LAN Router mit 6rd tunnel
    • 6rd Prefix: 2a02:1200::/28
    • 6rd Gateway: 6rd.swisscom.com (193.5.29.1
  • LAN Router weist mehrere /64 prefixe an die LAN-Schnittstellen zu
  • SLAAC (radvd) und DHCPv6 auf den LAN Schnittstellen für die Clients (Link MTU: 1480)
  • 6rd Tunnel MTU: 1480 Bytes

Wenn der 6rd Tunnel mit Standardeinstellungen erzeugt wird, dann wird die MTU für den Tunnel auf 1480 Bytes festgelegt (1500 Bytes - 20 Bytes IPv4 Encapsulation header).

 

Das funktioniert zunächst auch prima und IPv6 auf allen Clients scheint vollständig zu funktionieren.

 

Mir ist dabei nur aufgefallen, dass ich scheinbar alle Webseiten erreiche ausser swisscom.ch und andere Swisscom-Dienste wie MyCloud etc. Die Verbindungen enden immer im Timeout und ich bekomme überhaupt keine Antwort von https://www.swisscom.ch/. Bisher konnte ich damit leben, dass ich halt mit IPv6 nicht ins Kundencenter komme und auf MyCloud und weiteres verzichten muss. Allerdings wollte ich dem mal auf den Grund gehen. Zunächst hatte ich den Verdacht eines Routing Problems mit meinen Subnetzen oder ähnliches. Konnte aber kein Problem einkreisen.

 

Bis ich dann festgestellt habe, dass es scheinbar an der MTU liegt. Wenn ich die 6rd Tunnel MTU manuell auf 1472 Bytes ändere funktionieren auch die Swisscom Dienste.

Auch die Internet Box verschikt RA messages mit einer MTU von 1472 weshalb wohl auch Swisscom Kunden die IPv6 über die IB nutzen kein Problem haben. Wenn diese aber über andere Provider mit einer grösseren MTU angebunden sind könnte das gleiche problem auch auftreten.

 

Lösung gefunden aber die Ursache ist mir noch nicht 100% klar. Eigentlich sollte ja nach meinem Verständnis Path-MTU Discovery auch mit kleineren MTUs im Übertragungspfad zurecht kommen. Natürlich funktioniert das nur mit ICMP und ICMP scheint bei den Swisscom-Services komplett gefiltert zu werden. Vielleicht ist das schon die Ursache, dass gar keine Verbindung zustande kommt aber ich frage mich gerade wo der Konfigurationsfehler vorliegt.

 

Vielleicht kann jemand etwas dazu sagen. Ich bin definitiv (noch) kein IPv6 Experte.

Mein Verständnis war einfach, dass die MTU des 6rd Tunnels maximal 1480 sein sollte (und das auch so funktioniert) und bei anderen Internet-Verbindungen (Native IPv6) die MTU auch höher sein kann und frage mich gerade ob man mit solchen Internet-Anschlüssen auch die Swisscom-Dienste nicht erreichen kann (ich habe hier leider keinen Anschluss mit nativem IPv6 zum testen).

HILFREICHSTE ANTWORT1

Akzeptierte Lösungen
SkyBeam
Level 4
2 von 7

Jetzt hab' ich gerade noch das hier gefunden.

Darin wird Martin Gysi zitiert:


We advertise an MTU of 1472 in the RA Options. We still have a small
number of PPPoE users and the max-payload-tag is not working reliably
enough on third-party devices.

Hence: 1500 Bytes - 20 Bytes IPv4 - 8 Bytes PPPoE = 1472 Bytes

\Martin

Siehe hier.

Wobei mir immer noch nicht klar ist warum ich als non-PPPoE-User davon betroffen sein soll und warum ich die Swisscom Dienste nur mit 1472 Bytes MTU erreiche.

 

Vermutlich hat es damit zu tun:


@TuxOne:

Security through obscurity bis man (Swisscom zB.) einen black hole router hat: https://de.m.wikipedia.org/wiki/Black_Hole_Router?wprov=sfla1


Das wäre dann wie schon von mir vermutet.

  • Irgendwo gibt es im Pfad Systeme die den Traffic über weitere Tunnel Routen und deswegen nur 1472 Bytes übertragen können
  • Die Systeme Antworten mit einem ICMP Paket um das anfragende System zu informieren
  • Diese Antwort kommt nie an weil man irgendwo im Pfad jegliches ICMP blockiert

Wann lernt man eigentlich, dass ICMP nix böses ist sondern durchaus nützliche Informationen transportiert?

Editiert
6 Kommentare 6
SkyBeam
Level 4
2 von 7

Jetzt hab' ich gerade noch das hier gefunden.

Darin wird Martin Gysi zitiert:


We advertise an MTU of 1472 in the RA Options. We still have a small
number of PPPoE users and the max-payload-tag is not working reliably
enough on third-party devices.

Hence: 1500 Bytes - 20 Bytes IPv4 - 8 Bytes PPPoE = 1472 Bytes

\Martin

Siehe hier.

Wobei mir immer noch nicht klar ist warum ich als non-PPPoE-User davon betroffen sein soll und warum ich die Swisscom Dienste nur mit 1472 Bytes MTU erreiche.

 

Vermutlich hat es damit zu tun:


@TuxOne:

Security through obscurity bis man (Swisscom zB.) einen black hole router hat: https://de.m.wikipedia.org/wiki/Black_Hole_Router?wprov=sfla1


Das wäre dann wie schon von mir vermutet.

  • Irgendwo gibt es im Pfad Systeme die den Traffic über weitere Tunnel Routen und deswegen nur 1472 Bytes übertragen können
  • Die Systeme Antworten mit einem ICMP Paket um das anfragende System zu informieren
  • Diese Antwort kommt nie an weil man irgendwo im Pfad jegliches ICMP blockiert

Wann lernt man eigentlich, dass ICMP nix böses ist sondern durchaus nützliche Informationen transportiert?

Editiert
cram87CH
Level 1
3 von 7

und ich dachte schon, ich bin der einzige mit dem Problem.

habe es nun mit MTU 1480 geschafft auf swisscom.ch zu kommen

Zyxel AX7501 Broadcast 1.JPG

 

Zyxel AX7501 Broadcast 2.JPG

 

guybrush82
Level 2
4 von 7

Ich konnte jetzt mit der Einstellung MTU 1472 endlich mein IPv6 fixen (vorher mit MTU="" konnte ich gar keine IPv6 Seite aufrufen), doch nun erreiche ich auch die Seite swisscom.ch nicht mehr... Auch mit MTU 1480 nicht.

 

Hat da jemand noch eine Idee?

 

Bildschirmfoto 2021-02-27 um 01.07.57.pngBildschirmfoto 2021-02-27 um 01.08.15.png

georgemv
Level 1
5 von 7

Set MSS to 1472 as well and you should be good to go.

guybrush82
Level 2
6 von 7

Currently, with MSS 1472, I can still not reach the site "*.swisscom.ch", whereas all other IPv6 sites work and also "IPv6 testers" (like: https://ipv6test.google.com/ ) show, that everything is ok... Very weird… 🤔

GrandDixence
Level 1
7 von 7

Wenn die Path-MTU < 1500 Byte ist, aber Server ODER Client eine Ethernet-MTU verwenden (1500 Byte) muss in beiden Richtungen (Uplink + Downlink) der entsprechende Router, welcher in Senderichtung die Datenpakete eine Netzwerkleitung mit MTU < 1500 Byte verwenden will, ein ICMP-Mitteilung, Type 3, Code 4 an den Sender (Client oder Server) zurücksenden ("Fragmentation required, and DF flag set").

https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol

 

=> Mit Ping- und Wireshark kontrollieren, ob diese ICMP-Mitteilung in dieser Netzwerkverbindung bis zum Server UND Client durchgelassen wird.

https://de.wikipedia.org/wiki/Maximum_Transmission_Unit

 

Diese ICMP-Mitteilung muss von allen in der Netzwerkverbindung liegenden Firewalls und Routern durchgelassen werden (-> Black hole router-Thematik), ansonsten funktioniert ein "Path-MTU Discovery Verfahren mit ICMP" nach RFC 1191 (IPv4), RFC 8201 (IPv6; ehemals RFC 1981) nicht korrekt. Praktisch alle Server und Clients verwenden heute ein "Path-MTU Discovery Verfahren mit ICMP" und setzen für TCP-Verbindungen das DF-Flag (don't fragment). Siehe für mehr Informationen:

https://community.upc.ch/d/5848-citrix-und-upc-verbindung-sehr-schlecht/17

 

=> Besser man lässt die Finger von allen IPv6-Tunnellösungen, wie 6rd. Und verzichtet auf den Einsatz von IPv6, bis ordentliches Dual Stack vom ISP (hier: Swisscom) angeboten wird:

https://www.elektronik-kompendium.de/sites/net/2010211.htm

 

https://en.wikipedia.org/wiki/IPv6_rapid_deployment

 

Wenn der Internetanschluss für IPv4 keine Path-MTU von 1500 Byte aufweist, den Internetanschlussanbieter (ISP) wechseln (falls möglich)!

Editiert
Nach oben