How do you plan Docker's container address space across a fleet of hosts on a corporate network?

### The question behind the question An interviewer asking this wants to see whether you understand what is actually scarce. It is tempting to treat container addresses like datacentre addresses and carve a unique block per host. For the ordinary case that is wasted effort: containers on bridge networks are NAT'd behind the host address on the way out, and nothing outside the host ever addresses them directly. Two hosts can both use 10.207.3.0/24 and never notice each other. Uniqueness only becomes a requirement when container addresses are visible on the wire — a network driver that puts containers directly on the physical LAN, or a routed multi-host scheme — and those are deliberate choices you know you have made. So the design is not "an allocation per host". It is **one identical allocation, applied everywhere**. ### Choosing the block Two properties matter, and only two. **Nothing may route it.** This is the failure that actually happens: a host takes a range that a VPN, a peering link, an acquired company's network or a partner extranet also routes, and every destination in that range becomes unreachable from the host and its containers, because the local connected route beats the remote one. Ask the network team for a block they will keep unrouted, and confirm it against the VPN pools specifically — laptops are where this bites, because a developer creates networks with the VPN down and connects afterwards. **It must have room.** Not room for addresses — a /24 per network is far more than most stacks use — but room for network **count**. A `default-address-pools` entry of `{"base": "10.207.0.0/16", "size": 24}` yields 256 networks. Compare that with the built-in default of roughly 31 and the reason to configure it explicitly is obvious the first time a build host runs many stacks concurrently. The default 172.16.0.0/12 neighbourhood is the single worst place to leave things, because it is the range enterprises most often use themselves. ### Making it stick A correct block that lives in one engineer's notes is not a plan. Ship the configuration: ``` { "bip": "10.206.0.1/24", "default-address-pools": [ { "base": "10.207.0.0/16", "size": 24 } ] } ``` Managed by whatever provisions your hosts, so that a machine built next year is addressed like the machines built today. Two operational details belong in the runbook alongside it. First, the file is read at daemon start, so applying a change means restarting the daemon. Second, and more often missed, the pools govern only **future** allocations: hosts that already carry networks on the old ranges keep them until those networks are removed and recreated, so a migration needs a pass that does exactly that, scheduled when tearing down stacks is acceptable. Developer laptops are part of the fleet even when they are not managed like servers. They are where the VPN collision actually surfaces, so the same file, or a documented equivalent for the desktop engine's settings pane, needs to reach them. ### The IPv6 decision Enable it because you need it, not because it is available. The genuine reasons are an IPv6-only or IPv6-preferred environment, or applications that must be reachable over IPv6 end to end. The costs are real: you need either a delegated prefix or a deliberate unique-local allocation, the daemon's IPv6 firewall and NAT behaviour has changed across engine versions so the semantics differ by version, and every diagnostic habit, firewall rule and monitoring check on the team now has a second address family to cover. Dual-stack is not free, and half-configured dual-stack — addresses assigned but filtering not equivalent — is worse than not enabling it, because it can expose over one family what you carefully restricted on the other. If you enable it, pin the engine version, document the prefix in the same place as the IPv4 pools, and test the filtering path explicitly. ### Living with the decision Add two things to operations. **Monitor the network count per host** and alert well before the pool is exhausted, because exhaustion is not a gentle degradation — the next stack simply fails to start, and the error names address pools while the on-call engineer is looking at disk. **Make automatic creators clean up deterministically**: anything that creates networks per job or per project must remove them in a step that runs even on cancellation, with a periodic sweep as a backstop. The tradeoff to state out loud: this is cheap insurance. Private address space costs nothing, the file is a dozen lines, and the failure it prevents is a whole-machine outage whose cause looks like DNS, firewalls, or the VPN client, and typically consumes a day of the wrong people's time before anyone runs `ip route get` and sees a bridge interface where a tunnel should be.