There's no point in letting a container perform duplicate address detection as we'll silently discard neighbour solicitations with unspecified source addresses anyway, without relaying them to anybody. And we realised that it's not harmless, see the whole discussion around https://github.com/containers/podman/pull/23561#discussion_r1711639663: we can't communicate with the container right away because of that, which is surely annoying for tests, but it could also be an issue for use cases with very short-lived containers or namespaces. Disabling DAD via procfs configuration would be simpler than all this, but we don't own the namespace (unless we spawn a shell), so we shouldn't mess up with procfs entries, assuming it's even possible. Set the nodad attribute, and prevent DAD from being triggered before on link up, before we can set that attribute. v2: - in 4/7, instead of doing the whole nl_routes_dup()-vendored dance to keep addresses in a single buffer, send NLM_F_REPLACE requests right away, but use nlmsg_send() instead of nl_do(), and check for answers to our further requests later. Use warn() instead of die() if we can't set nodad attributes - in 5/7, make nl_addr_get_ll() get a pointer to struct in6_addr instead of a generic void pointer, and warn(), don't die(), if it fails Stefano Brivio (7): netlink: Fix typo in function comment for nl_addr_get() netlink, pasta: Split MTU setting functionality out of nl_link_up() netlink, pasta: Turn nl_link_up() into a generic function to set link flags netlink, pasta: Disable DAD for link-local addresses on namespace interface netlink, pasta: Fetch link-local address from namespace interface once it's up pasta: Disable neighbour solicitations on device up to prevent DAD netlink: Fix typo in function comment for nl_addr_set() netlink.c | 144 +++++++++++++++++++++++++++++++++++++++++++++++++----- netlink.h | 6 ++- pasta.c | 29 ++++++++++- 3 files changed, 164 insertions(+), 15 deletions(-) -- 2.43.0