I am fighting an interesting issue which prevents my internal hosts from talking SSH with external IPv6 hosts. My setup is: piper - an internal host (2001:41e0:ff12:0:211:2fff:fe6b:c869), connected via IPv6 to wall - my gateway (2001:41e0:ff12::1), connected by sixxs heartbeat tunnel to a PoP (chzrh01) pulse - my external host (2001:41e0:ff1a::1), connected by sixxs static tunnel to the same PoP Both wall and pulse have a pMTU of 1500 to the PoP, so I set it all up to use MTUs of 1480. To be exact: - both tunnels have MTU==1480 on sixxs.net's webpage - both machines have MTU==1500 on their external IPv4 ifaces - both machines have tunnel ifaces with MTU==1480 I can (and you can) ping6 all machines. Furthermore, I can pull hundreds of megabytes from pulse to piper (or wall) (using HTTP) and push them back (using FTP). There's a bit of a curious thing happening when I push: the FTP application sends about 80k of data and then the transfer rate drops to 0 for 10 seconds with an occasional ACK packet; after the 10 seconds, the transfer continues at maximum rate through the end. tcpdump capture file follows: http://scratch.madduck.net/.tmp__cdt.XoV25955__tcpdump.ftp Possibly related is that I I cannot establish SSH IPv6 connections from piper to pulse, while they work fine the other way, and also between wall to pulse and wall and piper. However, IPv4 SSH connections between piper and pulse work fine. Here is what happens when I try to ssh -6 from piper to pulse: piper:~|master|% ssh -6vSnone pulse OpenSSH_4.7p1 Debian-12, OpenSSL 0.9.8g 19 Oct 2007 debug1: Reading configuration data /home/madduck/.ssh/config debug1: Applying options for pulse debug1: Applying options for * debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to pulse.madduck.net [2001:41e0:ff1a::1] port 22. debug1: fd 3 clearing O_NONBLOCK debug1: Connection established. debug1: identity file /home/madduck/.ssh/id_rsa type 1 debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3p2 Debian-9etch2 debug1: match: OpenSSH_4.3p2 Debian-9etch2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-12 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-sha1 none debug1: kex: client->server aes128-cbc hmac-sha1 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'pulse.madduck.net' is known and matches the RSA host key. debug1: Found key in /home/madduck/.ssh/known_hosts:73 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering public key: /home/madduck/.ssh/id_rsa packet_read: Setup timeout expired, giving up The tcpdump captures on both sides are identical: http://scratch.madduck.net/.tmp__cdt.XoV25955__tcpdump.ssh.piper I have tried lowering the MTUs to 1280, and I have also verified with tracepath6 that connectivity is there. I have no idea what's causing this problem, which was not present a few weeks ago. Until a few days ago it was only one of the machines on my network that couldn't connect to pulse; now none of them can. Any help/tips appreciated!