[Bug 2049247] Re: Broken IPv4 support on IPv6-preferring networks (v255)

[Bug Watch Updater]

** Changed in: systemd
       Status: Unknown => New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, 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:
  New
Status in systemd package in Ubuntu:
  New

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