mirror of
https://github.com/moby/moby.git
synced 2026-01-11 18:51:37 +00:00
c72e458a72
For some time, when adding an interface with no IPv6 address (an interface to a network that does not have IPv6 enabled), we've been disabling IPv6 on that interface. As part of a separate change, I'm removing that logic - there's nothing wrong with having IPv6 enabled on an interface with no routable address. The difference is that the kernel will assign a link-local address. TestAddRemoveInterface does this... - Assign an IPv6 link-local address to one end of a veth interface, and add it to a namespace. - Add a bridge with no assigned IPv6 address to the namespace. - Remove the veth interface from the namespace. - Put the veth interface back into the namespace, still with an explicitly assigned IPv6 link local address. When IPv6 is disabled on the bridge interface, the test passes. But, when IPv6 is enabled, the bridge gets a kernel assigned link-local address. Then, when re-adding the veth interface, the test generates an error in 'osl/interface_linux.go:checkRouteConflict()'. The conflict is between the explicitly assigned fe80::2 on the veth, and a route for fe80::/64 belonging to the bridge. So, in preparation for not-disabling IPv6 on these interfaces, use a unique-local address in the test instead of link-local. I don't think that changes the intent of the test. With the change to not-always disable IPv6, it is possible to repro the problem with a real container, disconnect and re-connect a user-defined network with '--subnet fe80::/64' while the container's connected to an IPv4 network. So, strictly speaking, that will be a regression. But, it's also possible to repro the problem in master, by disconnecting and re-connecting the fe80::/64 network while another IPv6 network is connected. So, I don't think it's a problem we need to address, perhaps other than by prohibiting '--subnet fe80::/64'. Signed-off-by: Rob Murray <rob.murray@docker.com>
libnetwork - networking for containers
Libnetwork provides a native Go implementation for connecting containers
The goal of libnetwork is to deliver a robust Container Network Model that provides a consistent programming interface and the required network abstractions for applications.
Design
Please refer to the design for more information.
Using libnetwork
There are many networking solutions available to suit a broad range of use-cases. libnetwork uses a driver / plugin model to support all of these solutions while abstracting the complexity of the driver implementations by exposing a simple and consistent Network Model to users.
Contributing
Want to hack on libnetwork? Docker's contributions guidelines apply.
Copyright and license
Code and documentation copyright 2015 Docker, inc. Code released under the Apache 2.0 license. Docs released under Creative commons.