This is a regression with kernel versions 4.5 or later which causes a
SSH tunnel to drop packets within the receiving end of the OpenSSH
server loop, more exactly: They don't get reinserted into the tun device
after being received via the encrypted stream.

A strace of two ICMPv4 packets coming in (FD 3 is the encrypted socket):

read(3, "Mp-\v[\t\300"..., 16384) = 124
select(14, [3 5 8], [], NULL, NULL)     = 1 (in [3])
read(3, "jm\17t\222"..., 16384) = 124
select(14, [3 5 8], [], NULL, NULL)     = 1 (in [3])

I haven't found the exact culprit on why OpenSSH doesn't send the packet
back into the tun device, but after countless hours of debugging and
doing a bisect against the kernel, I found that the commit which causes
the regression is torvalds/linux@cc9da6c.

The bug has already been reported upstream at:

https://bugzilla.kernel.org/show_bug.cgi?id=121131

While the final fix for this issue is still not clear on the kernel
front, we can do our own part to mitigate this:

We don't use IPv6 for SSH tunnels anyway, so we can safely disable IPv6
address autogeneration for them.

I've switched to iproute instead of nettools because it allows for more
fine-grained control (setting addrgenmode with ifconfing is not possible
AFAIK).

Also, I've linked the commands via && instead of using semicolons to
ensure that we get a unit failure if one of the commands along the chain
should fail.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>