Thanks for starting the discussion about this Evers! Supporting IPv6 has been a long awaited feature for Mesos, so glad to see that you are interested in working on this.
I would also vote for #1 because it seems to get us far with minimal code changes. There is already a #networking working group <https://cwiki.apache.org/confluence/display/MESOS/Apache+Mesos+Working+Groups> that you might leverage to get feedback (of course you can always post here on the dev list too). @Kapil is this something you want to shepherd? On Mon, Feb 1, 2016 at 11:35 PM, Vetoshkin Nikita < [email protected]> wrote: > All thumbs up for (1). > I think supporting several IP addresses (and thus sockets) can be tricky to > implement in libprocess and will require some machinery for setting things > up and tearing down (what if only one bind() of N will succeed, etc.). It > may also make debugging stuff harder (e.g. firewalls, routes, etc can > result in user complains like "I can successfully connect from this host, > but not this one"). > Not sure though if we need to support (set) IPV6_V6ONLY flag (man 7 ipv6). > I'm a bit worried about MasterInfo.ip attribute. How "deprecated" it is. > Did currently existing frameworks/language bindings already abandon it? > > On Mon, Feb 1, 2016 at 1:27 AM Evers Benno <[email protected]> wrote: > > > Hi all, > > > > after looking through the mesos source code for a while, here are > > some of my initial thoughts. > > > > There seem to be at least two issues that can be tackled separately: > > - Communication between mesos daemons over the network > > - Communication in and out of containers when using network isolation > > > > Having the first one would already be valuable for installations that > > don't use network isolation, so I'll focus on this for now. > > > > If a mesos master daemon runs on say mesos-master.example.org:5050, and > > this host has both A and AAAA addresses configured it seems to be > > desirable that slaves can communicate with this node over both IPv4 and > > IPv6, depending on their own capabilities. > > > > From the client perspective, the problem is solved by the "Happy > > Eyeballs" algorithm, i.e. trying both possibilities and using > > the one where it is possible to connect. The only complication is that > > address resolution should probably be delayed until we actually want to > > connect, to avoid spurious failures. > > > > On the server side it is a bit more subtle, since the server has to > > decide which address it should bind its listening socket to. Some > > possibilities would be: > > > > 1) Do nothing special, just bind to the address that was specified > > 2) Allow specifying multiple listen IP's > > 3) Allow to specify a network interface and port and open two separate > > listening sockets for IPv4 and IPv6 > > > > These are not mutually exclusive. > > > > It seems that (2) and (3) would be desirable anyways, since they would > > also enable running on hosts with multiple network interfaces. > > > > It is however worth noting that (1) already gets us quite far without > > changing the assumption that there is a single IP associated to a mesos > > daemon: If an IPv4 address is specified, things will work the same as > > before, and if there is an IPv6 address specified it will by default > > accept connections from both IPv4 and IPv6 sources. This behaviour can > > even be changed at system-level, if not desired. (via > > /proc/sys/net/ipv6/bindv6only, or the mac/windows equivalent). > > > > So, tl;dr: I believe a lot of of useful progress could already be > > achieved by a relatively small patch series, that: > > > > - Fills in the blanks in stout's net:IP, and gives all functions > > which take an explicit "family"-argument a default value of > > AF_UNSPEC > > - Updates the IPv4-specific parts in libprocess (in particular, the > > parsing of IP literals in URL strings and the constructor > > Socket::create(Kind, Option<int> fd), which should probably be split > > into e.g. Socket::make(sa_family_t, Kind) and > > Socket::wrap(int fd, Kind)) > > - Changes all calling sites to use the new functions > > > > The protobuf IPC format doesn't seem to require any changes, since the > > only IPv4-dependent field (MasterInfo.ip) was already deprecated in > 0.24.0. > > > > After this, the next step would then be to look at network isolation and > > enabling communication in and out of containers. > > > > Thoughts? Comments? Am I missing something? > > > > Best regards, > > Benno > > >
