I could solve this issue for the specific case of VDSL2 with FritzBox 7430 (Broadcom Chip) in modem/bridge mode.
See here:
https://forums.he.net/index.php?topic=3746.msg21104#msg21104

Do know if this could happen with FTTH as well.
Maybe you should check the hardware.
At least in my case, there was no more explanation left then a bug below layer 2.

Hallo all,

indeed, replacing the FritzBox 7430 by the Zyxel VMG1312-B30A as Modem-Bridge solves the problem.
The (in germany) very popular FritzBox seems to mess up TCP-Sessions in IPv6, as described in https://ttlexpired.co.uk/2016/02/12/ipv6-tunnel-and-failing-tcp-sessions/ (here by some other kind of CPE).
It has nothing to do with MTU.

So if you want a static prefix for your ipv6 (which Deutsche Telekom won't give you) over a linux-router using a modem-bridge for vdsl(2), you'd better get something else then a FritzBox.
Don't get the Allnet BM100VDSL2 with Lantiq chipset, either. My specimen did not run stable on the VDSL layer and it's software is really a piece of crap.

The Zyxel VMG1312 does a good job. In fact the best of the 4 products it testet.

Hope that helps everyone having these kind of problems!

Volker



And here's an explantion in german, since the FitzBox is very popular in Germany and this needs to said in german, too, so Google will find it:

Das Problem ist:
eine FritzBox 7430 wird als Modem+Bridge an einem VDSL2-100 Anschluss der Deutschen Telekom AG (DTAG) eingesetzt.
Das wird zwar angeblich offiziell nicht mehr unterstützt, geht aber (Juni 2017) trotzdem, wenn man in den Interneteinstellung als Provider "Sonstige" verwendet, angibt das keine Authentifikation notwendig ist und dann PPPoE-Passthrough einschaltet.
Die FritzBox entfernt dann das VLAN7 der DTAG und stellt PPPoE Pakete auf den LAN-Ports zur Verfügung.

Auf den angeschlossen Router läuft Ubuntu 14.04 mit dem ppp-daemon.
IPv4 läuft einwandfrei stabil.
Legt man über tunnelbroker.net einen IPv6 Tunnel an, so funktioniert Ping sowie einige UDP-Protokolle.
TCP-Session brechen jedoch nach wenigen Paketen ab.
Siehe dazu ältere Beiträge dieses Threads.
An der MTU liegt es nicht.
Der Hinweis auf das eigentliche Problem findet sich hier: https://ttlexpired.co.uk/2016/02/12/ipv6-tunnel-and-failing-tcp-sessions/
Scheinbar macht der Chipsatz der FritzBox 7430 in dieser speziellen Situation Probleme.
Da ein Zugriff auf den Chipsatz - im Gegensatz zu der CPE in dem verlinkten Artikel - nicht möglich ist, blieb nur das Austausch der Box gegen ein Zyxel VMG1312-B30A. Dieses wird von der DTAG an Businesskunden, die eigene  Router ohne Moden einsetzen, veermarktet.
Das Zyxel gerät wird ebenfalls nur als Modem-Bridge mit VLAN-stripping verwendet.
Mit diesem Gerät funktioniert dann alles: VDSL2, IPv4 und IPv6 über he.net einwandfrei.

Hi,

<aol>me too</aol>

I have this problem since a couple of month. Its just that at first I didn't blame the tunnel... I lowered my tunnel MTU to 1280, but it didn't change anything. My endpoint is tserv1.fra1.he.net. I'm connected via GPON/FTTH. So no DSL at all.

Matthias

I did some debugging with wireshark:

What is wrong here?

Well, several packets from the remote server were lost.  The remote webserver tried to end the connection normally after 5 seconds of inactivity.  A TCP retransmission was initiated, and some (but not all) data was successfully resent.  Then (assuming TCP's rules haven't changed since IPv4) either the remote machine was rebooted, or it's TCP stack is broken or at least poorly configured, as those are the only way you get a RST in 120 seconds.  [I wouldn't bother with this issue.] 

Both ends seem to be sending a payload length (inside all the headers) of 1208, with an overall packet length of 1280, and you did receive such a packet.

Well, TCP did always require only a non-zero probability of successful delivery from it's lower level, but it never really behaves well unless it gets a very high probability of successful delivery.  Maybe you have a noisy connection (which seems unlikely with current technology).  Most of the dropped packets appear to be incoming.  If so, you might be able to tune your TCP stack to be more aggressive at sending and requesting retransmissions.  Unfortunately, that is just a workaround.

As for the underling problem?  Your guess is as good as mine, but I would suspect it isn't MTU, as the payload 1208 overall 1280 packets went both ways successfully (#4, #10).

thank you cholzhauer

This issue has work out. 

netsh interface ipv6 add v6v4tunnel interface=IP6Tunnel (used computer's ip  no  internet ip )

Yeah, we're going to need a bunch more information as to what you did, configs, setup, ect.

#1 most likely is that your company is blocking protocol 41, as they should

Maybe the same as this:
https://forums.he.net/index.php?topic=3601.0

which links to this:
https://ttlexpired.co.uk/2016/02/12/ipv6-tunnel-and-failing-tcp-sessions/

So it may be a problem close the the VDSL2 hardware.
The problem description fit's exactly, except hat tcpdump -p doesn't help in my case. But this makes sense, since my router and the modem are different devices.

Right now I'm using a AVM FritzBox as VDSL2 Modem/Bridge. It has a Broadcom Chip. FastPath etc. can not be configured, since this is a consumer router.

Before, I used an Allnet VDSL2 Modem. IPv6 was working stable. It doesn't use a Broadcom but a Lantiq Chipset. Unfortunately, this thing was not running stable on the VDSL2 layer as other products based on this chipset as well so I had to return it.

I now ordered one of these:
http://www.zyxel.com/de/de/products_services/vmg1312_b_series.shtml?t=p&tabOrder=2

This is the product Deutsche Telekom uses at as business customer CPE.
This might fix the problem and be a much better solution than the FritzBox anyway.

I might have the same problem:

https://forums.he.net/index.php?topic=3746.0

I did some debugging with wireshark:

For MTUs > 1280, I get a ICMP6 message "packet to big".
Here's a test with MTU 1284:

5   0.156892   2001:470:1f0a:127b::2   2001:470:1:18::1281   HTTP   236   GET /ip/?size=1600&fill=xx HTTP/1.1
6   0.307349   2001:470:1:18::1281   2001:470:1f0a:127b::2   ICMPv6   1280   Packet Too Big


For MTU==1280, which seems to be the MTU suggested by ICMPv6, my connection get's reset after a some time, even the payload was delivered correctly.
See screenshot.



ssh session and most other TCP-sessions don't work this way.

What is wrong here?

Hi,
I have create regular tunnel for my computer ( os  win7, behind  company's firewall)  and i  had type the command "example configurations  for win 7". but it don't work .  something wrong ?

thanks a lot .