> Well, would that enable automatic, correcting routing between the
> container and the host's external network? That's kinda what this all
> is about...
> 
> Lennart
> 

In case we know, which interface provides the external network, it is also 
possible to use proxy ndp 
to give containers routeable ips:

sysctl -w net.ipv6.conf.<if>.proxy_ndp=0
ip -6 neigh add proxy <ip> dev <if>

where <if> is the external interface and <ip> is the container ip.
Proxy NDP will reply with Neighbor Advertisement on the interface in
question if somebody has sended a Neighbor Solicitation messages for an added 
ip (similar to ARP Requests/Response).

To give a container an ip from the subnet advertised on the external interface, 
it would be required to proxy router advertisements between external interface 
and bridge (or veth pair).
Afaik their is no such proxy for router advertisements, so it would required to 
bridge the external interface with the bridge (or the host side of the veth 
pair), 
which would break the isolation between external and internal network. (Maybe 
somebody has a better solution on how to get an ip via router advertisement)

The cool thing of having 1 routeable ip per container is, you have no longer 
conflicts with port numbers and can actually bind port 80 multiple times for 
example. About security concerns:
why not whitelist ports forwarded from external with the --port parameter of 
systemd-nspawn and block everything else. 
The only thing port forwarding hides, is the destination ip source, but does 
not expose if the ip addressed is assigned to the host, a container or even a 
complete different host, which uses this host as a router.
Also private addresses would still require to NAT traffic from container to the 
external network, which requires a lot nasty protocol hacks (ipsec, ftp, SIP, 
...)

Ideally nspawn could rely on a service which would either forward router 
advertisements of an external interface or fallback to private addresses in 
case, the host does not have external network configured.

About ULA addresses (fd00::/8): couldn't these be generated using the 
machine-id of a container (does every container has a machine-id? is the mac 
address stable for containers)? 
We have 128 - 8 = 120 bit free, however it is recommend to not use the hole ULA 
address space but limit it to a prefix.
What also always works is using link-local addresses (not for the containers, 
because link local addresses are awkward to type, because they always needs to 
include the interface, but it could be used for the host part in the default 
gateway)

Attachment: pgpvFMhaOr5as.pgp
Description: OpenPGP digital signature

_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to