[systemd-devel] systemd-nspawn and IPv6

[Jörg Thalheim]

> 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150429/52b11383/attachment-0001.sig>