Skip to content
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

Restore deterministic IPv6 from MAC behavior on default bridge network #17890

Merged
merged 2 commits into from Nov 11, 2015
Merged

Conversation

aboch
Copy link
Contributor

@aboch aboch commented Nov 11, 2015

Fixes #17739

@tiborvass
Copy link
Contributor

LGTM

Signed-off-by: Alessandro Boch <aboch@docker.com>
@icecrime
Copy link
Contributor

Thanks @aboch, do we want it for 1.9.1?

if config.Bridge.FixedCIDRv6 != "" {
_, fCIDRv6, err := net.ParseCIDR(config.Bridge.FixedCIDRv6)
if err != nil {
return err
}

ones, _ := fCIDRv6.Mask.Size()
deferIPv6Alloc = ones <= 80
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just two quick questions:

  • What's the meaning of that ones <= 80?
  • Do we need the bool variable or can we just if ones <= 80 { NetworkOptionDeferIPv6Alloc(true) }?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@icecrime
When IPv6 support was added into docker, the IPv6 address assignment could happen in two ways:

  • from MAC address (last 48 bits of the IPv6 address == MAC address)
  • or via ip allocator

The first method was the preferred way, always chosen by bridge driver when the IPv6 network had enough host bits to contain the MAC address. That's from where the 80 (128-48) bits comes from.

This logic gave a backdoor access to configure deterministic IPv6 addresses for containers.
In order to restore that behavior (which got broken) only for the default bridge network, I had to bring the 80 bits in here.
Whenever we support the IPAM options for endpoint (container), we can deprecate the above behavior.

Since the ones are not visible outside of the if scope, I opted for a bool variable outside.
If I had to initialize the NetworkOption setter function inside the if scope, then I'd need to define anyway an extra variable outside, of type libnetwork.NetworkOption. Hence I did not see a difference.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the background, I think it's worth a code comment (or people reading this will definitely scratch their heads).

I don't really understand why you would need a variable if you just called libnetwork.NetworkOptionDeferIPv6Alloc at that point of the code, but I'll trust you with that :-/

@aboch
Copy link
Contributor Author

aboch commented Nov 11, 2015

@icecrime
In my opinion this fix should go in 1.9.1 since it fixes a regression.

@icecrime icecrime added this to the 1.9.1 milestone Nov 11, 2015
@icecrime icecrime added the priority/P0 Urgent: Security, critical bugs, blocking issues. drop everything until this issue is addressed. label Nov 11, 2015
@icecrime
Copy link
Contributor

Adding this to 1.9.1 as P0 (regression). Small nits, otherwise LGTM!

Signed-off-by: Alessandro Boch <aboch@docker.com>
@tiborvass
Copy link
Contributor

thanks, i can see the comment added, looks good, merging.

tiborvass added a commit that referenced this pull request Nov 11, 2015
Restore deterministic IPv6 from MAC behavior on default bridge network
@tiborvass tiborvass merged commit 7a985cf into moby:master Nov 11, 2015
@aboch aboch deleted the b6 branch January 14, 2016 21:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
impact/changelog priority/P0 Urgent: Security, critical bugs, blocking issues. drop everything until this issue is addressed.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants