[systemd-devel] Setting up network interfaces for containers with --private-network

[Spencer Baugh]

Lennart Poettering <lennart at poettering.net> writes:
> On Tue, 21.04.15 15:22, Spencer Baugh (sbaugh at catern.com) wrote:
>
>> > Also, trivial static IP configuration is seldom sufficient, you at
>> > least need to also provide DNS configuration, and if you don't use
>> > DHCP or something similar then you need to configure that inside the
>> > container anyway. But if you do that you might as well configure the
>> > static IP addresses in it too, so what is gained by doing this from a
>> > networkd outside of the cotnainer?
>> >
>> >> Or am I misunderstanding the role of networkd? It seems like if I am
>> >> writing a service that represents "the network interface and namespace
>> >> for this container", I am doing something that networkd should
>> >> ultimately do.
>> >
>> > Sure, absolutely. But our idea so far was that networkd should run
>> > inside the container to configure the container's network, and on the
>> > host to configure the host's network, but not to cross this boundary
>> > and have the host networkd configure the container's network.
>> 
>> Hmm, yes, but I think the problem is the configuration done at
>> interface-creation-time. It seems to me that that configuration
>> currently does not fit naturally in either the host networkd or the
>> container networkd.
>
> Well, again, I doubt that configuration exclusivel at
> interface-creation-time will be useful for more than the most trivial
> cases, already because as mentioned it would not cover DNS server
> configuration and thelike.

Sure, I'm in agreement, but there are things that can only be
"configured" at interface-creation-time. As a trivial example, the type
of the interface. And it looks like for ipvlan you can only choose L2 or
L3 mode at creation-time.

Additionally, it seems to me that the MAC address, at least, is
something that you might want to configure only at creation-time and not
change later.

The earlier two examples are necessary, the third example, the MAC
address, is just nice-to-have. But since there are things that actually
really must be configured at creation-time, it seems that eventually it
will be necessary to figure out a best practice or mechanism for such
configuration. And that method might as well also allow the nice-to-have
of configuring the MAC address at creation time.

> If you really want fixed IP addresses, I think this could work:
>
> We add configurability for the DHCP server address range in networkd,
> including taking ranges that contain a single IP address. You could
> then assign fixed addresses to your containers simply by dropping a
> .network snippet for them, that only contains a single dhcp range IP
> address for it. THat should work, no?

This would be a nice feature and would work for many use cases.

My problem with this solution is that I'm using IPv6. With IPv6, I can
set up stateless autoconfiguration to "assign" IPs to interfaces.  In
that case the IP is directly determined by the MAC address, so it is not
possible (AFAIK?) to specify a range of IPs of length 1 to force that
single IP to be assigned to a specific interface.

I would somewhat prefer to be using this feature of IPv6, rather than
using DHCPv6; and anyway, networkd doesn't support DHCPv6 right now,
right? So this doesn't necessarily work for me.

The mapping from MAC address to IPv6 address is just a matter of
encoding the MAC address in the last 64 bits of the IPv6 address.  So if
I know the MAC address of the container, and maybe listen a little on
the network interface to see what routing prefix is being advertised, I
know the IPv6 address that the container will get. Maybe something
(networkd, networkctl, machined, machinectl?) could reveal this
information? Just an idea.

The stateless autoconfiguration of IPv6 seems pretty similar to
systemd's own aims, it would be nice if they worked well together.