-
Notifications
You must be signed in to change notification settings - Fork 18.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Preserve kernel-assigned IPv6 link-local addresses on a bridge network's bridge #47787
Preserve kernel-assigned IPv6 link-local addresses on a bridge network's bridge #47787
Conversation
Make the behaviour enabled by env var DOCKER_BRIDGE_PRESERVE_KERNEL_LL the default... - don't remove kernel assigned link-local addresses - or any address in fe80::/64 - don't assign fe80::1 to a bridge Signed-off-by: Rob Murray <[email protected]>
- Remove package variable bridge.bridgeIPv6 - Use netip in more places - Improve error messages from fixed-cidr-v6 checks Signed-off-by: Rob Murray <[email protected]>
Signed-off-by: Rob Murray <[email protected]>
Multicast addresses aren't added by the daemon so, if they're present, it's because they were explicitly added - possibly to a user-managed bridge. So, don't remove. Signed-off-by: Rob Murray <[email protected]>
Oh, thank you - hadn't appreciated that. I think it's mostly here, apart from Vinod's repro steps ...
|
- What I did
Before release 25.0.0, an IPv6-enabled bridge network's bridge was always assigned address
fe80::1
as well as an IPAM-assigned address fromfixed-cidr-v6
or the network's--subnet/--ip-range
. It then deleted any other routable addresses. When the bridge cameup
because a container got linked to it, the kernel assigned a link-local address infe80::/64
.In 25.0.0, #46850 tried to reconcile expected addresses on a bridge network's bridge with addresses with those on the bridge, before deciding which addresses to add/remove. That solved a problem where changes in
fixed-cidr-v6
prevented the daemon from starting, if the new and old subnets overlapped. But, it was more aggressive about removing addresses, and would remove the kernel-assigned link local address. In most circumstances,fe80::1
seems to be used for NDP etc - but, it could cause problems as discussed in this Slack thread (repro steps from that chat are copied into a comment below).In 26.1.1, #47771 added env var
DOCKER_BRIDGE_PRESERVE_KERNEL_LL
which, if set to1
, prevented the daemon from adding thefe80::1
address and from deleting any address infe80::/64
- preserving the kernel-assigned link local address, andfe80::1
(because if an earlier version of the daemon had replaced the kernel-ll address, the bridge wouldn't get a new one). That solved the problem discussed in the Slack thread.This change updates the daemon to use the 26.1.1 env-var controlled behaviour in all cases ... it removes the env-var, never tries to assign
fe80::1
, and doesn't remove addresses infe80::/64
.Please note that not-assigning
fe80::1
is new in this release (apart from the optional behaviour in 26.1.1). All previous releases would assign that address. I don't think there's any reason to add that extra LL address, the kernel will always set one up. Nothing set up by the daemon uses it, and it's not documented.Closes #47778
In separate commits, this PR also:
fixed-cidr-v6
/--subnet
is not a multicast address.- How I did it
Simplified the code a little, now
fe80::1
isn't added, there's only one IPv6 address to add to the bridge (the IPAM assigned address), so there was no longer any need for a map of wanted-addresses.- How to verify it
Updated/added tests.
- Description for the changelog