Broken IPv4 support on IPv6-preferring networks (v255)

[Florian Bach]

I noticed a bug in systemd version 255 which is currently available in noble-proposed (255.2-3ubuntu1).

I have already reported to upstream at https://github.com/systemd/systemd/issues/30891 but there's no fix available yet as of today.

I'm still reporting the bug here anyways because this bug can, under some conditions, result in the loss of IPv4 network connectivity in a completely standard Ubuntu 24.04 installation just by updating to systemd 255. I'm hoping that that's okay even though it's a bug caused by upstream not by Ubuntu; just because it could have a bad impact if this version ends up in 24.04 as it is.

---

In systemd version 255, a feature has been added to "support" the IPv6-only DHCP option 108 defined in RFC8925. I'm putting "support" in quotation marks because one functionality that this RFC marks as a requirement is not implemented in systemd yet.

To summarize: Option 108 can be sent by a DHCPv4 client to signal to the DHCPv4 server: "Hey, if (and only if) your network has proper IPv6 support and a working NAT64 gateway, I don't really need my own IPv4 address, I can handle it using 464XLAT and NAT64". The point of that option is to be able to run a Dual Stack network, where only clients that really need IPv4 (older Linux, Windows, etc.) will receive an IPv4 from DHCP, and clients that don't need IPv4 (Android, MacOS, Linux with systemd >=255, etc.) won't receive one from DHCP and instead set up a 464XLAT for outgoing IPv4 connectivity.

This new code in systemd is enabled by default (the option "IPv6OnlyMode" defaults to "yes"). However, systemd does not actually have code to set up a 464XLAT yet (which violates the RFC).

This means that systemd signals to the DHCPv4 server "Hey, I don't need IPv4, I'll just use 464XLAT and NAT64" but then it doesn't actually do that. Updating systemd on an Ubuntu 24.04 installation (where systemd-networkd is used) will result in the loss of the DHCP-assigned IPv4 address, breaking network connectivity for all IPv4-only applications.

---

Information on how to reproduce this issue can be found in detail in the github bug report linked above, but to summarize:

1. Have a Dual Stack network that announces a NAT64 through RAs or through DNS (or, ideally, both)
2. Configure your DHCPv4 server to hand out option 108 ("v6-only-preferred")
3. Connect an Ubuntu machine with systemd < 255.
4. Notice that IPv4 connectivity is working fine.
5. Update to systemd = 255.
6. Notice that there's no IPv4 connectivity anymore and IPv4-only apps break.

---

The proper fix for this issue to make systemd conform to the RFC would be to implement a 464XLAT. However that's not an easy task and most certainly not something that would end up as a hotfix / patch release. A good workaround for this bug would be, in my opinion, to change the default value for the "IPv6OnlyMode" to "no" when compiling systemd.

That way, the RFC-violating code doesn't run by default, and if a user does set up a 464XLAT on their machine in some other way (outside of systemd) they can just change their config to include "IPv6OnlyMode=yes" and it'll be working as intended.

ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: systemd 255.2-3ubuntu1
ProcVersionSignature: Ubuntu 6.6.0-14.14-generic 6.6.3
Uname: Linux 6.6.0-14-generic x86_64
ApportVersion: 2.27.0-0ubuntu6
Architecture: amd64
CasperMD5CheckResult: pass
Date: Sat Jan 13 07:05:42 2024
InstallationDate: Installed on 2024-01-12 (0 days ago)
InstallationMedia: Ubuntu-Server 23.10 "Mantic Minotaur" - Release amd64 (20231011)
Lsusb:
 Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet
Lsusb-t:
 /: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=ohci-pci/12p, 12M
     |__ Port 001: Dev 002, If 0, Class=Human Interface Device, Driver=usbhid, 12M
MachineType: {report['dmi.sys.vendor']} {report['dmi.product.name']}
ProcEnviron:
 LANG=C.UTF-8
 PATH=(custom, no user)
 SHELL=/bin/bash
 TERM=linux
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.6.0-14-generic root=UUID=b5e6aabf-881a-4589-85ae-688f41df0be7 ro
SourcePackage: systemd
UpgradeStatus: Upgraded to noble on 2024-01-12 (0 days ago)
dmi.bios.date: 12/01/2006
dmi.bios.vendor: innotek GmbH
dmi.bios.version: VirtualBox
dmi.board.name: VirtualBox
dmi.board.vendor: Oracle Corporation
dmi.board.version: 1.2
dmi.chassis.type: 1
dmi.chassis.vendor: Oracle Corporation
dmi.modalias: dmi:bvninnotekGmbH:bvrVirtualBox:bd12/01/2006:svninnotekGmbH:pnVirtualBox:pvr1.2:rvnOracleCorporation:rnVirtualBox:rvr1.2:cvnOracleCorporation:ct1:cvr:sku:
dmi.product.family: Virtual Machine
dmi.product.name: VirtualBox
dmi.product.version: 1.2
dmi.sys.vendor: innotek GmbH

[Florian Bach (leseratte10)]

Upstream has fixed this for v256 and has indicated the fix will be backported to v255.

https://github.com/systemd/systemd/commit/7dc431839eeeffe6ed65acbe9bfe2a6e89422086

[Florian Bach (leseratte10)]

Given that systemd-v255 has just migrated from noble-proposed to noble yesterday, this bug is now present in Ubuntu 24.04 as-is, without the proposed repo enabled. Can this fix be backported before 22.04 releases so people don't run into network issues with a newly-installed 22.04?

[Nick Rosbrook (enr0n)]

We *should* get this via normal stable update processes relatively soon. If for some reason it doesn't land in systemd-stable in time (unlikely since the upstream PR is tagged for stable backport), then we will backport it in Ubuntu directly.

[Nick Rosbrook (enr0n)]

The referenced patch was included in v255.4, which has now landed in noble.