networkd: Implement ipv6-address-generation: stable-privacy

[tatokis]

Description

The relevant systemd pull request has long been merged, so add support for IPv6Token=prefixstable in the networkd generator.

systemd/systemd#16618

Checklist

• Runs make check successfully.
• Retains 100% code coverage (make check-coverage).
• New/changed keys in YAML format are documented.
• (Optional) Adds example YAML for new feature.
• (Optional) Closes an open bug in Launchpad.

[slyon]

Thank you very much for your contribution to Netplan!

I very much like this PR and the fact that you're fixing an existing TODO. Kudos!

When checking the context of this PR, I found that the [Network].IPv6Prefix= setting isn't listed anymore in the most recent man-page. It seems like the logic was shuffled a little to make use of a Token= setting instead, see: https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html (and systemd/systemd#20778)

There might still be some legacy-fallback, which might keep this PR totally valid!
Are we certain that it actually works, though? Would you mind creating an integration test around it, e.g. similar to tests/integration/ethernets.py:test_dhcp6, but then checking for the stable prefix?

[tatokis]

Thank you very much for your contribution to Netplan!

I very much like this PR and the fact that you're fixing an existing TODO. Kudos!

Thanks! Apologies for the super late reply; I haven't abandoned this.

When checking the context of this PR, I found that the [Network].IPv6Prefix= setting isn't listed anymore in the most recent man-page. It seems like the logic was shuffled a little to make use of a Token= setting instead, see: https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html (and systemd/systemd#20778)

There might still be some legacy-fallback, which might keep this PR totally valid! Are we certain that it actually works, though? Would you mind creating an integration test around it, e.g. similar to tests/integration/ethernets.py:test_dhcp6, but then checking for the stable prefix?

Indeed. I did not notice that it was removed from the documentation. I am 100% sure it still works though since I am actively using it myself on noble.

That said, I think I should re-do this with the Token setting under [IPv6AcceptRA] instead. It was added in systemd v250 systemd/systemd@a73628e which I believe to be okay. (Unless you explicitly want jammy (systemd v249) support. Focal and earlier was always out of the question.)

Please let me know what you'd prefer.

I'll look into adding an integration test either way, although it might be difficult as I can not for the life of me get the tests and the coverage checks to run correctly locally. I'll let you know how it goes.

[tatokis]

Note: IPv6AcceptRA.Token now accepts eui64 explicitly since systemd 250, so that should be added too. systemd/systemd@140bf8d

[slyon]

When checking the context of this PR, I found that the [Network].IPv6Prefix= setting isn't listed anymore in the most recent man-page. It seems like the logic was shuffled a little to make use of a Token= setting instead, see: https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html (and systemd/systemd#20778)
There might still be some legacy-fallback, which might keep this PR totally valid! Are we certain that it actually works, though? Would you mind creating an integration test around it, e.g. similar to tests/integration/ethernets.py:test_dhcp6, but then checking for the stable prefix?

Indeed. I did not notice that it was removed from the documentation. I am 100% sure it still works though since I am actively using it myself on noble.

@tatokis Great! That's good to know. systemd usually has pretty good backwards compatibility, so I was expecting it to work, even though it's not document for the most recent version.

That said, I think I should re-do this with the Token setting under [IPv6AcceptRA] instead. It was added in systemd v250 systemd/systemd@a73628e which I believe to be okay. (Unless you explicitly want jammy (systemd v249) support. Focal and earlier was always out of the question.)

Please let me know what you'd prefer.

Yes and no... I'd suggest a 2-step approach (3 steps, actually):

1. Let's get the minor comments fixed and the unit- & coverage-test green on this PR as-is. So we can get it landed soon and potentially integrate for the upcoming Netplan 1.1 release (planned for August). Those commits would also allow for easier backporting to Jammy (if needed), as you mentioned above (no need to worry about Focal or earlier).
2. Optionally: Provide an integration test (see below), as this would make refactoring easier afterwards
3. Prepare a new PR, building on top of this to refactor stuff, using the new Token= setting. If we don't have an integration test, yet, get one ready for this new PR.

I'll look into adding an integration test either way, although it might be difficult as I can not for the life of me get the tests and the coverage checks to run correctly locally. I'll let you know how it goes.

Yeah, it needs some setup to run it locally, but the GitHub actions workflow from our CI, can be used as a template for step-by-step instructions of how to run the autopkgtests inside a local LXD container, see: https://github.com/canonical/netplan/blob/main/.github/workflows/autopkgtest.yml#L34

Furthermore, you should be able to confirm the commands & resulting IP addresses on your local machine natively and then the CI will run the new tests on this PR for you. It's OK if you need to push multiple fixups to make the test work ;-)

[slyon]

Thank you very much for addressing my remarks!

This is ready to be merged, as in step (1) is done.
I'm looking forward to seeing step (2) & (3) addressed in follow-up PR(s). Keep up the good work, thanks!