network-legacy: Change ip=any to mean dual stack DHCP

[chewi]

systemd-network-generator tries to support the same IP configuration syntax as Dracut. One difference is that Dracut supports multiple comma-separated autoconf values (e.g. dhcp,dhcp6) whereas systemd only permits one. Fixing this in systemd may not be straightforward.

This matters because Afterburn can emit dhcp,dhcp6 for KubeVirt, and it is now being adapted to support systemd-network-generator as well as Dracut's network-legacy module.

Even if systemd-network-generator did support multiple values, the behaviour would not be the same. Both systemd-networkd and NetworkManager always try both IPv4 and IPv6, normally requiring just one of them to work, whereas network-legacy will not even try IPv6 if IPv4 works, or vice-versa depending on the order given. It is not currently possible to make network-legacy always try both.

To workaround the lack of multi-value support in systemd and to mirror how systemd and NetworkManager behave, I am changing ip=any to always try DHCPv4, DHCPv6, and SLAAC, requiring just one to work. They are tried in parallel to avoid the cost of a double timeout. Despite the name, this is currently treated by network-legacy as IPv4-only. The history of ifup.sh reveals that any was supported before IPv6 was, and that IPv6 was initially added with "preliminary" support. Perhaps the author didn't want to change the behaviour of any until that support was better established and then forgot, or perhaps it was merely an oversight.

systemd-network-generator also treats ip=on as dual stack, but that would be a more controversial change. Users may not expect IPv6 alone to be considered successful. NetworkManager even treats ip=dhcp as dual stack, but I feel that is wrong. With ip=any, the intent is clearer, and this at least gives us one option where the behaviour is consistent.

Much of this change is adjusting the dhclient PID and lease paths to be protocol-specific so that IPv4 and IPv6 instances can be run simultaneously.

There were no tests for explicit IP configuration at all, but I felt it was important to have this covered, so some have been added. To avoid unnecessary overhead, this spins up just one VM with several differently configured interfaces.

The module changes were mostly written by me with a little help from AI. The tests were entirely written by AI.

Checklist

• I have tested it locally
• I have reviewed and updated any documentation if relevant
• I am providing new code and test(s) for it

[chewi]

CC @dracut-ng/gentoo-maint @dracut-ng/opensuse-maint

[chewi]

I was a little slow to join the dots and realise that Fedora CoreOS now uses NetworkManager rather than network-legacy. With Flatcar migrating to systemd-network-generator, I could probably change this in Afterburn without impacting anybody. Still, I think the fix makes sense for those still using network-legacy in other contexts.

[aafeijoo-suse]

I was a little slow to join the dots and realise that Fedora CoreOS now uses NetworkManager rather than network-legacy.

Same in openSUSE, the default is NetworkManager for some years now, and some people use systemd-networkd. The legacy network module is only still alive (for now) to facilitate maintenance, but I'd not add anything new to it.

[chewi]

Oh well. It's done now, so I think we might as well merge it for Gentoo, if nothing else. I wondered why Alpine wasn't on the list, but it stopped packaging dhclient a while back, so they're limited to NetworkManager. There are presumably other DHCP clients that are still maintained, but I guess no one cares enough to rescue network-legacy.

[bdrung]

I like the idea of the proposed behavior of ip=any.

My problem is that the whole ip= is not standardized and the details are unclear. Different implementation do different things and we have custom behviour in Ubuntu initramfs-tools that causes questions regularly (if you want to look into it, look for ip6). We have ip=dhcp6 and ip=auto6. What does ip=any mean? Does it try auto6 or dhcp6?

Could we create a standard (on freedesktop.org or Linux Userspace API (UAPI) Group) that clarifies the meaning?

[mwilck]

Could we create a standard

As far as dracut is concerned, I think we're pretty much bound by the requirement to remain backward compatible. Lots of scripts out there create ip= command line parameters for dracut. So if we standardize across different initrd generators, we'd probably need to choose a different option name, and error out if both the new and the legacy name were used.

[chewi]

We have ip=dhcp6 and ip=auto6. What does ip=any mean? Does it try auto6 or dhcp6?

This comment made me realised that I hadn't mirrored systemd and NetworkManager closely enough. They also enable SLAAC (i.e. auto6) with any. I have now amended my change to include that.

Most of the time, compatibility here isn't that important. A distro uses one mechanism, and the bootloader gets configured accordingly. It's only tools like Afterburn that need to think cross-distro.

systemd-network-generator(8) defers to dracut.cmdline(7) for details on ip= parameters, so I believe they mostly try to follow Dracut's behaviour. Evidently, they didn't support multiple autoconf values, but to be fair, that wasn't even documented by Dracut until this change. Enabling dual stack for any was also entirely reasonable, hence this change.

We can try to nail down a standard, but I think we would have to agree to disagree on a few points, not least because systemd-networkd and NetworkManager are just so different to the legacy approach. With legacy dying out, I'd be inclined to tell systemd to just explicitly document their own behaviour instead of deferring to Dracut.

@pothos, do you have any thoughts here?