Mailing-List: contact dev-help@mesos.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@mesos.apache.org
MIME-Version: 1.0
References: <56AE6DF0.9090600@yandex-team.ru>
In-Reply-To: <56AE6DF0.9090600@yandex-team.ru>
From: Vetoshkin Nikita <nikita.vetoshkin@gmail.com>
Date: Tue, 02 Feb 2016 07:35:17 +0000
Message-ID: 
 <CAFkxUYVLrUdz93sOtn1071Mvvw_RVQuJkJQOdbRYx_mSrDcBcA@mail.gmail.com>
Subject: Re: Some initial thoughts on IPv6
To: dev@mesos.apache.org
Content-Type: multipart/alternative; boundary=001a11c3ec10970e8f052ac48be4

--001a11c3ec10970e8f052ac48be4
Content-Type: text/plain; charset=UTF-8

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 <bennoe@yandex-team.ru> 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
>

--001a11c3ec10970e8f052ac48be4--