containers / netavark

Container network stack
Apache License 2.0
534 stars 84 forks source link

Provide option or IPAM method to enable SLAAC #783

Open lemmi opened 1 year ago

lemmi commented 1 year ago

434 has been a rather annoying change for me. Since I don't have the luxury of a stable IPv6 prefix, I'm relying on SLAAC, fixed MAC addresses along with MACVLAN to get predictable addresses in my containers.

While I can add --sysctl net.ipv6.conf.eth0.autoconf=1 for most containers, this relies on consistent naming and gets very verbose the moment multiple networks are used. I'd love to have a way to enable SLAAC for networks again. Either through an option or maybe a dedicated IPAM method to make it very explicit.

Luap99 commented 1 year ago

I think having a opt in option for that sounds good, we can use the generic IPAMOptions map for this (not yet exposed via podman cli). I could imagine something like ipv6_autoconf=true/false which defaults to false when unset.

Are you interested in contributing a PR for that?

lemmi commented 1 year ago

Thank you for the fast response. I'd love to contribute, but I'm not that fluent with rust and the earliest I can take a closer look is in about a week. Not having the option available through the podman cli is a little inconvenient, but I can live with editing the file for the moment.

Luap99 commented 1 year ago

Thanks. Adding the podman support for podman network create is likely much easier. All the infrastructure is already there it would only be single cli option and I would make that it is implemented that once the option is added here.

jsonn commented 1 year ago

Just FYI, I'm using default_sysctls from containers.conf for this purpose, but an option in the network config would certainly be appreciated.

Luap99 commented 1 year ago

The problem with default_sysctls or --sysctl is that it does not work when a custom user namespace is used, i.e. --userns keep-id. In this case the netns will be configured after the oci runtime applies the sysctl's so we would overwrite it regardless in such case.

lemmi commented 1 year ago

So now that I can finally come back to this, I noticed that the original issue with enabling autoconf was for IPv4-only setups. Wouldn't it make more sense to couple this to the --ipv6 or ipv6_enabled option? I'd assume a lot of people reaching for macvlan or similar and deliberately enabling IPv6 do so for SLAAC. If they didn't want to use SLAAC, they probably also don't provide router advertisements in that network. There could still be an option to override the default. Thoughts?

Luap99 commented 1 year ago

The reason we explicitly disable autoconf is because other users explicitly did not want SLAAC when they already configured a subnet in the network config. Gating this via --ipv6 is certainly an option but what would it mean if there is already a static ipv6 subnet in the config? Does the user also want the SLAAC address in this case or only the static address?

Having an ipv6_autoconf option makes such configurations explicit and any user can tweak as they need it.

lemmi commented 1 year ago

https://bugzilla.redhat.com/show_bug.cgi?id=2126243 concerns IPv4-only networks. Personally I see little harm in extra IPv6 addresses, but again, if a network is not supposed to be configured via SLAAC, maybe the better solution is to not provide RAs to begin with. Still, I'm fine with adding the option. It's now more about the default. I absolutely see the case for disabling autoconf in an IPv4-only network, but I don't quite see a strong argument to do the same for a IPv6 network. I rather have a convenient default.

bjo81 commented 6 months ago

i stumbled now also upon this issue, using macvlan and set --ipv6 and was wondering why the container didn't get an autoconfigured IPv6 like with cni before.

nickles95 commented 6 months ago

I am also being hit by this, and would love for it to be fixed.