Comment 7 for bug 1671951

On Wed, May 17, 2017 at 1:14 PM, Dimitri John Ledkov <<email address hidden>
> wrote:

> I'm very naive, so please bear with me if this is a silly question. As
> far as I can tell the existing MTU setting in networkd will apply to
> both ipv4 and ipv6 simultaniously. Are you arguing that you want
> specific control of MTU and use different values for ipv4 and ipv6?
>

Yes

AFAICT, the MTUBytes field which is a link property, applies to the device
itself.

IPv6 has a separate *protocol* level MTU where it is used to fragment IPv6
packets
so they can be tunneled (among other things) over IPv4. There's also a
specific
IPv6 MTU setting to prevent IPv6 packets from being to small (I think 1280
is the
minimum MTU allowable for IPv6 packets.

Subsequently, the kernel has *two* MTUs, Device (ethernet, ppp, etc) and
IPv6 protocal

device: /sys/class/net/<interface>/mtu
ipv6: /proc/sys/net/ipv6/conf/<interface>/mtu

Would it not be sufficient to set the appropriatly-lowest/highest common
> denominator value for MTU?
>

It is not. In the case that you want to use 9000 MTU on an ipv6 address,
one
 needs to ensure that the MTU of the underlying device is raised from the
default to 9000
otherwise the V6 MTU means nothing.

In some cases you want to raise the MTU of the underlying device, but *not*
raise the MTU of the IPV6
this is a tunneling case:

eth0 mtu 9000
ipv6 mtu 1480

So, yes, we want independent control over v4 and v6 MTU.

Note, the upstream discussions (IMHO) punt the problem to Router
Advertisements; however what
does remain is that we currently have this control with ifupdown (with some
help of pre/post scripts).

I had a start at getting this working in networkd, however I wasn't able to
achieve the independent control

>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1671951
>
> Title:
> networkd should allow configuring IPV6 MTU
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/
> 1671951/+subscriptions
>