On Sun, Jan 03, 2016 at 10:49:34AM +0100, Laurens Blankers wrote:

> Tags: ipv6
> 
> When setting the MTU in a inet6 static section in interfaces the MTU is set 
> on the interface applying to all protocols rather than specific for IPv6.

Hm, that's also true for IPv4, so this maybe isn't IPv6-specific.
Although I don't think there will be many cases where the IPv4 MTU would
be lower than the IPv6 one.

> 1. Add the following option to the 'iface eth0 inet6 static' section in 
> interfaces:
> 
>     mtu 1480
> 
> 2. Reboot
> 
> Expected result:
> The MTU is set to 1480 for the IPv6 protocol on the specified interface using
> a command similar to:
> 
>     sysctl net.ipv6.conf.eth0.mtu=1480

Hm, this is the first time I've heard about a separate MTU setting for
IPv6. I'll see if this can be implemented easily in ifupdown.

> This scenario is quiet common when using tunnels (e.g. Sixxs) to provide IPv6
> connectivity. My IPv6 MTU needs to be 20 bytes smaller than may IPv4 MTU
> because of the tunnel's overhead.

Ok, but the SixXS tunnel itself doesn't transport IPv4 packets, so the
current behaviour is fine for configuring the tunnel itself.

If you have a host on a LAN with a gateway machine that has a SixXS
tunnel, then you shouldn't have to lower the MTU on that host, since the
gateway machine should send the appropriate ICMPv6 packets to the host
if the host sends packets that are too large. If that doesn't work,
check if you have firewall rules on either machine blocking ICMPv6
packets.

> I do realize that changes to this logic might cause existing configurations,
> which rely on this behaviour, to break. However it would be really nice if 
> the behaviour in both 'static' and 'auto' is consistent. Or at least if the
> difference is explicitly documented in the man page.

With "auto", ifupdown doesn't set mtu itself. It has several different
methods to configure the interface in this case. Can you tell me if you
are using RDNSS, DHCPv6 or SLAAC to configure it?

-- 
Met vriendelijke groet / with kind regards,
      Guus Sliepen <g...@debian.org>

Attachment: signature.asc
Description: Digital signature

Reply via email to