[Bug 1671951] Re: networkd should allow configuring IPV6 MTU
Launchpad Bug Tracker
1671951 at bugs.launchpad.net
Mon Feb 17 10:07:54 UTC 2020
This bug was fixed in the package systemd - 237-3ubuntu10.39
---------------
systemd (237-3ubuntu10.39) bionic; urgency=medium
[ Dariusz Gadomski ]
* d/p/lp1762391/0001-Call-getgroups-to-know-size-of-supplementary-groups-.patch,
d/p/lp1762391/0002-user-util-tweak-to-in_gid.patch,
d/p/lp1762391/0003-user-util-Add-helper-functions-for-gid-lists-operati.patch,
d/p/lp1762391/0004-execute-Restore-call-to-pam_setcred.patch,
d/p/lp1762391/0005-execute-Detect-groups-added-by-PAM-and-merge-them-wi.patch,
d/p/lp1762391/0006-test-Add-tests-for-gid-list-ops.patch,
d/p/lp1762391/0007-execute-add-const-to-array-parameters-where-possible.patch,
d/p/lp1762391/0008-execute-allow-pam_setcred-to-fail-ignore-errors.patch:
- Restore call to pam_setcred (LP: #1762391)
[ Ioanna Alifieraki ]
* d/p/lp1860548/0001-Revert-Replace-use-of-snprintf-with-xsprintf.patch,
d/p/lp1860548/0002-job-truncate-unit-description.patch:
- use snprintf instead of xsprintf (LP: #1860548)
[ Dan Streetman ]
* d/p/lp1833193-network-update-address-when-static-address-was-alrea.patch:
- Update lft when static addr was cfg by dhcp (LP: #1833193)
* d/p/lp1849261/0001-core-when-we-can-t-enqueue-OnFailure-job-show-full-e.patch,
d/p/lp1849261/0002-core-don-t-trigger-OnFailure-deps-when-a-unit-is-goi.patch:
- Only trigger OnFailure= if Restart= is not in effect (LP: #1849261)
* d/p/lp1671951-network-set-ipv6-mtu-after-link-up-or-device-mtu-cha.patch:
- set ipv6 mtu at correct time (LP: #1671951)
* d/p/lp1845909/0001-networkd-honour-LinkLocalAddressing.patch,
d/p/lp1845909/0002-networkd-fix-link_up-12505.patch,
d/p/lp1845909/0003-network-do-not-send-ipv6-token-to-kernel.patch,
d/p/lp1845909/0004-network-rename-linux_configure_after_setting_mtu-to-linux.patch,
d/p/lp1845909/0005-network-add-link-setting_genmode-flag.patch,
d/p/lp1845909/0006-network-if-ipv6ll-is-disabled-enumerate-tentative-ipv6-ad.patch,
d/p/lp1845909/0007-network-drop-foreign-config-after-addr_gen_mode-has-been-.patch,
d/p/lp1845909/0008-network-drop-IPv6LL-address-when-LinkLocalAddressing.patch:
- if LinkLocalAddressing=no prevent creation of ipv6ll (LP: #1845909)
* d/p/lp1859862-network-Do-not-disable-IPv6-by-writing-to-sysctl.patch:
- enable ipv6 when needed (LP: #1859862)
* d/p/lp1836695-networkd-Add-back-static-routes-after-DHCPv4-lease-e.patch:
- (re)add static routes after getting dhcp4 addr (LP: #1836695)
* d/t/storage:
- fix buggy test (LP: #1831459)
- without scsi_debug, skip test (LP: #1847816)
-- Dan Streetman <ddstreet at canonical.com> Thu, 06 Feb 2020 10:00:49
-0500
** Changed in: systemd (Ubuntu Bionic)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
Matching subscriptions: foundations-bugs
https://bugs.launchpad.net/bugs/1671951
Title:
networkd should allow configuring IPV6 MTU
Status in systemd:
Unknown
Status in cloud-init package in Ubuntu:
Confirmed
Status in netplan.io package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Fix Released
Status in cloud-init source package in Bionic:
Confirmed
Status in netplan.io source package in Bionic:
Fix Released
Status in systemd source package in Bionic:
Fix Released
Status in cloud-init source package in Disco:
New
Status in netplan.io source package in Disco:
Fix Released
Status in systemd source package in Disco:
Won't Fix
Status in cloud-init source package in Eoan:
New
Status in netplan.io source package in Eoan:
Fix Released
Status in systemd source package in Eoan:
Fix Released
Status in cloud-init source package in Focal:
Confirmed
Status in netplan.io source package in Focal:
Fix Released
Status in systemd source package in Focal:
Fix Released
Bug description:
= netplan.io =
[Impact]
* IPv6 traffic failing to send/receive due to incompatible/low MTU
setting. Specifically, IPv6 traffic may have higher MTU requirements
than IPv4 traffic and thus may need to be overridden and/or set to a
higher value than IPv6 traffic.
[Test Case]
* Apply a netplan configuration that specifices ipv6-mtu:
network:
version: 2
ethernets:
eth0:
dhcp4: true
dhcp6: true
ipv6-mtu: 6000
* Check that MTU bytes, is at least IPv6MTUBytes on the interface:
$ sysctl net.ipv6.conf.eth0.mtu
net.ipv6.conf.eth0.mtu = 6000
[Regression Potential]
* This is a future compatible backport of an additional keyword not
used by default. It may result in MTU change to a higher value, which
should not cause loss of connectivity.
[Other Info]
* Original bug report below
= end of netplan.io =
= systemd =
[Impact]
* IPv6 traffic failing to send/receive due to incompatible/low MTU
setting. Specifically, IPv6 traffic may have higher MTU requirements
than IPv4 traffic and thus may need to be overridden and/or set to a
higher value than IPv6 traffic.
[Test Case]
* Use IPv6MTUBytes= setting in a .network unit
* Restart systemd-network
* Check that there no error messages / warnings about not-recognizing this option
* Check that MTU bytes, is at least IPv6MTUBytes on the interface
[Regression Potential]
* This is a future compatible backport of an additional keyword not
used by default. It may result in MTU change to a higher value, which
should not cause loss of connectivity.
[Other Info]
* Original bug report below
= end of systemd =
1) Zesty
2) systemd-232-19
3) I need to configure the IPV6 MTU for tunneling by adding an IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 static address in the [Network] section
4) networkd does not parse or read the value and does not apply this configuration to the interface.
Upstream has discussed this issue here:
https://github.com/systemd/systemd/pull/1533
But it's been closed in favor of only setting via RA.
However, we know of multiple use-case which are currently supported in
ifdupdown where we want to retain control over IPV6 MTU values outside
of PMTU Discovery configurations.
Some context from those discussions
>> Client systems that route their ipv6 packets to a 6in4 router also
>> have to have their ipv6 mtu lowered. They could lower their link mtu,
>> so their ipv6 packets are small enough, but that reduces performance
>> of their ipv4 network.
Yes. Anything that creates a PMTUD black hole can result in
situations where the higher header overhead of IPv6 will cause IPv4 to
pass but IPv6 traffic to be dropped.
One example here is egress from an ipsec tunnel wherein the next
hop MTU is too low for IPv6 datagrams to pass. Another is VM ->
whatever -> host bridge -> tunnel ingress. If the datagram cannot enter
the tunnel due to size, it is dropped, and an ICMP response uses the
tunnel address as a source, which may not be routable back to the
origin. This one is an issue with IPv4 as well, and is one case where
manually setting the IPv6 MTU lower than the (also manually set) device
MTU is of benefit.
In essence, any of these sort of cases that require an explicit
setting of the device MTU will likely require a setting of the IPv6 mtu
as well to account for its larger header overhead.
To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1671951/+subscriptions
More information about the foundations-bugs
mailing list