You might want to consider letting the various VMs/containers freely communicate with each other, as though they are separate hosts on a LAN.  Especially for IPv6.

For ARC++ we went through a lot of trouble to make inbound connections work.

Multicast / service discovery remains a challenge, though...

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/d239a32c34fd8bb73eb6925898147fd03aea0ee4

commit d239a32c34fd8bb73eb6925898147fd03aea0ee4
Author: Jeffrey Kardatzke <jkardatzke@google.com>
Date: Tue Mar 13 20:05:09 2018

vm_tools: Add iptables rules for garcon gRPC communication

This sets/removes iptables rules in the startup/shutdown of vm_concierge
that allows connections from the containers over TCP/IP to the gRPC
server running inside of concierge on port 8889.

BUG=chromium:818367
TEST=Verify iptables rules appear as expected

Change-Id: I9e189cf0328385c8489d1fbdc9e8220520057620
Reviewed-on: https://chromium-review.googlesource.com/959354
Commit-Ready: Jeffrey Kardatzke <jkardatzke@google.com>
Tested-by: Jeffrey Kardatzke <jkardatzke@google.com>
Reviewed-by: Kevin Cernekee <cernekee@chromium.org>

[modify] https://crrev.com/d239a32c34fd8bb73eb6925898147fd03aea0ee4/vm_tools/init/vm_concierge.conf

 Issue 790876  has been merged into this issue.

Can this be configurable?

If we develop an Android app and want it to be able to talk to a java process running inside a container, I believe we would need/want to be able to pass that traffic.

Will we also be able to make connections from Chrome browser tab to a IP:Service running inside a container?

It won't be configurable initially. A Chrome browser tab will be able to connect to a socket inside the container. For instance, a web server can run inside the container and you could connect to that web server by pointing Chrome at the IP address of the container. However, Android apps will not be able to connect to sockets running inside the container. 

Our initial use case would be a local chrome tab connecting to the socket.

Would a remote system also be able to call my cros host IP+socket to connect to that container?

re: #7

Access to a container from another device on the LAN isn't currently possible. Containers are behind a NAT and there's no means right now to configure port forwarding.

An SSH tunnel might work for your use case though. The Chrome SSH app can set one up.

re #7 and re #8:

When you switch to LXD 3.0 this will be possible.
But we don't simply implement port-forwarding we have
a way more generic concept that is a "proxy" device type:

https://github.com/lxc/lxd/blob/master/doc/containers.md#type-proxy

Proxy devices allow forwarding network connections between host and container.
This makes it possible to forward traffic hitting one of the host's addresses
to an address inside the container or to do the reverse and have an address in
the container connect through the host.
We currently support TCP -> TCP but will generalise this such that you can do UDP -> TCP etc. etc.

The gist is:

lxc config device add <container> <device-name> proxy listen=<type>:<addr>:<port> connect=<type>:<addr>:<port> bind=<host/container>

There's a chrome app using the chrome.sockets that can bind/listen and forward TCP traffic to whatever address you want, until official support lands:
https://chrome.google.com/webstore/detail/connection-forwarder/ahaijnonphgkgnkbklchdhclailflinn