Ich betreibe einen Node über IPv6 durch einen Tunnel zu Hurricane Electric an ein einem Unitymedia Business-Anschluss. Das klappt soweit sehr gut.
Wir haben in der letzten Woche die MTU von 1426 auf 1406 gesenkt, um mit DS-Lite-Anschlüssen besser zurecht zu kommen. Vielleicht ist dein Node nicht aktuell und verwendet noch den höheren Wert? Bitte schau, ob Version 2014.4-stable-3 oder 2014.4-beta-7 installiert ist. Wenn nicht, bitte aktualisieren!
Ich habe hier auch SixXS-Tunnel und keine Probleme damit. Vielleicht solltest Du mal Deine Tunnel-MTU korrekt einstellen (auf beiden Seiten, bei SixXS und bei Dir):
1500 - 8 (PPPoE) - 20 (6in4) = 1472
Die von SixXS vorgeingestellten 1280 sind die MinimalMTU für IPv6, kleinere Werte sind nicht zulässig.
Wenn Dein Router ein Ethernetframe schickt mit 1406 oder 1426 MTU, Du aber durch Deinen SixXS Tunnel nur 1280 schicken kannst, wird das Frame natürlich weggeworfen.
Ich kann mich erst jetzt wieder melden, da das Forum mich für 24h auf Eis gelegt hat (zu viele Postings am ersten Tag).
Also, die MTU bei mir stand schon auf 1406.
Ich denke mal, die Lösung war doch schon wesentlich weiter oben im Thread genannt, oder muss es jetzt aus Prinzip unbedingt V6 sein?
BTW: Könnte es nicht auch eine „lustige“ fuzzy-firewall in der AVM-FB sein, die da bei heftigem v6-UDP-Traffik hineingrätscht?
Sehr gute Idee, Danke für den Tipp. 1280 ist die Default-MTU bei SixXS. Damit kann man dann in der Tat keinen weiteren IPv6 Tunnel durchtunneln. Da ich kein PPPoE mache, habe ich die MTU des SixXS-Tunnels an beiden Enden auf 1480 gesetzt (FAQ : Connectivity (Tunnels and Subnets) : What is the MTU of a tunnel? :: SixXS - IPv6 Deployment & Tunnel Broker).
Damit hat dann auch das FF VPN per SixXS-IPv6-Tunnel funktioniert. Die Clients hatten jedenfalls keine sichtbaren Probleme. Allerdings habe ich bemerkt, dass ein SSH auf den FF Router von meinem lokalen Netz per IPv6 Probleme machte - hier war bei großer Payload dann auch wieder Schluss mit TCP.
Darum- und weil es m.E. wenig Sinn macht, den FF Tunnel wiederum durch einen anderen IPv6 Tunnel zu leiten - habe ich den FF Tunnel wieder auf IPv4 gestellt. Ist auch sicherlich schneller mit nativem IPv4 und entlastet den SixXS Tunnelprovider.
So, und abschließend gesagt war das die Lösung. Das Kommando hat genau so funktioniert. Ich habe alle 13 konfigurierten Peers so auf IPv4 umgestellt.
Danke nochmal für Eure Hilfe. Eine Spende für unsere örtliche Gruppe ist auch schon rausgegangen 
Hinweis: die Einstellung der Peers wird beim Autoupdate wieder überschrieben! Die Variante das ipv6 auf dem WAN ganz abzustellen (das geht im Config-Mode?) wäre hier nachhaltiger.
Kann nicht sein, da ist noch was anderes fundamental bei Dir defekt. Bei den FF-Routern ist die MTU per RA auf 1280 festgenagelt. Kannst Du so nachkucken:
rdisc6 br-client
Du kannst Dir die MTU eines Pfades auch per tracepath6 anschauen:
$ tracepath6 2a03:2260:115:0:ea94:f6ff:fef3:31c
1?: [LOCALHOST] 0.041ms pmtu 1500
1: no reply
2: 2a01:4f8:d12:3::1 1.373ms
3: hos-tr3.juniper3.rz10.hetzner.de 1.804ms
4: core21.hetzner.de 0.748ms
5: core1.hetzner.de 5.311ms
6: juniper4.ffm.hetzner.de 5.361ms
7: decix.bb-c.act.fra.de.oneandone.net 9.831ms
8: ae-2-0.bb-a.fra3.fra.de.oneandone.net 5.453ms asymm 7
9: 2001:8d8:2:1050::3 5.650ms asymm 8
10: 2001:8d8:2:1050::4 5.700ms asymm 8
11: 2001:8d8:2:1050::4 5.584ms pmtu 1400
11: commander1024.gw.freifunk-muenster.de 6.183ms asymm 8
12: commander1024.gw.freifunk-muenster.de 6.205ms pmtu 1280
12: 2a03:2260:115:0:ea94:f6ff:fef3:31c 158.620ms reached
Resume: pmtu 1280 hops 12 back 55
Gut zu sehen ist, wie zwei Mal die MTU entlang des Pfades verkleinert wird.
Ich habe hier z.B einen Host mit MTU 9000 (jumbo frames) im Netz. Der SSH Verbindungsaufbau sieht so aus:
Flags [SEW], seq 3975103029, win 17880, options [mss 8940,sackOK,TS val 1241731109 ecr 0,nop,wscale 7], length 0
Flags [S.], seq 2972278048, ack 3975103030, win 12080, options [mss 1220,sackOK,TS val 20885865 ecr 1241731109,nop,wscale 4]
Der Host meldet eine Maximum Segment Size von 8940, der FF-Router eine MSS von 1220, der kleinste gemeinsame Wert wird für die Verbindung genutzt. Da stockt nichts, alles klappt, trotz einer MTU von 9000 auf einer Seite.
Ist doch wurstegal, ob der fastd über IPv6 oder IPv4 gegen das Gateway tritt.
Wozu sich mehr Latenz einhandeln? Erst zum Sixxs Provider, und von da zum Verein. Denke nicht, dass das sinnvoll sein kann. Mein Fazit: in diesem Fall ipv4 nutzen.
Schaun wir mal:
ping -c 1 commander1024.gw.freifunk-muenster.de
PING commander1024.gw.freifunk-muenster.de (176.9.88.123) 56(84) bytes of data.
64 bytes from commander1024.gw.freifunk-muenster.de (176.9.88.123): icmp_req=1 ttl=51 time=24.8 ms
ping6 -c 1 commander1024.gw.freifunk-muenster.de
PING commander1024.gw.freifunk-muenster.de(commander1024.gw.freifunk-muenster.de) 56 data bytes
64 bytes from commander1024.gw.freifunk-muenster.de: icmp_seq=1 ttl=51 time=49.6 ms
OK, ca. 25ms zu 50ms, also die doppelte Latenz. Vielleicht ist in dem Szenario legacy IPv4 doch geeigneter.
Nun ja, es ist ja nicht nur die erhöhte Latenz. Auch die Bandbreite könnte durch den SixXS-Tunnel begrenzt sein, denn so ein SixXS-Tunnelprovider terminiert sicherlich dutzende Tunnel und muss diese auch erst wieder an seinen Backbone anbinden. Schließlich bietet der SixXS-Tunnelprovider (die meist auch nicht die „Großen“ sind) seine Dienste für lau an und es gibt keine garantierte Bandbreite. Jedenfalls nicht so „halbwegs garantiert“ wie die native IPv4-Anbindung an Unitymedia.
Meiner Ansicht nach ist das eh alles Käse, wenn man nicht per Zwang IPv6 braucht.
Wenn es nativ zur Verfügung steht ist es tofte, ansonsten kann man noch sehr entspannt und besser mit IPv4 leben…zumal Tunnel durch Tunnel betreiben ohnehin immer sehr ungünstig ist und vermieden werden sollte…
Zum Lernen von IPv6 und „Spielen“ ist so ein IPv6-SixXS-Tunnel schon sehr nützlich, zumal ich nicht auf so eine Krücke wie DS-Lite umsteigen möchte. Und da Freifunk-Router mit Peer-Verbindung ggf. dort vermehrt zum Einsatz kommen, wo Leute gerne mit Netzwerken „spielen“, wird man so eine Konstallation wie bei mir wahrscheinlich öfter antreffen. Von daher ist es gut, dass wir hier einige Aspekte besprochen haben.
Absolut - ich meinte natürlich auch eher produktiven Betrieb 
Ich bin seinerzeit ja auch über das Problem gestolpert und habe damit den @CHRlS nerven müssen. Damit der nächste nicht so lang suchen muss, habe ich Sixxs in der Thread-Titel geschrieben. Und richtig: Tunnel durch Tunnel durch Tunnel nur in der Lehre, nicht im Betrieb 