The referenced patch was included in v255.4, which has now landed in
noble.
** Changed in: systemd (Ubuntu)
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2049247
Title:
Broken IPv4 support on IPv6-preferring networks (v255)
Status in systemd:
Fix Released
Status in systemd package in Ubuntu:
Fix Released
Bug description:
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
To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/2049247/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
